Workspaces and Shell Usage

SCS commands are local and terminal-first. The scs shell function calls the repository wrapper at:

/home/rezriz/github/server-side-program/scs/scripts/scs.sh

It is configured in ~/.bash_aliases/Scs/scs.sh, which is sourced by the existing Bash alias loader. Once loaded, scs works from any current directory. For the current shell, load it with:

source ~/.bash_aliases/Scs/scs.sh

Alternatively, call the wrapper by its absolute path.

Workspace and site are different

• A workspace is a named collection of related content records and files. Create it with scs bs.
• A site is the target website registered in config/sites.csv. The row's site_id points to that site, and its registered prefix determines PID values. A workspace can contain rows for a registered site; the workspace name does not register a site.

config/sites.csv is used by import, sync, PID allocation, and the VisiData integration. If the intended site is not already listed, register it once:

scs add-site client-site --domain client.example --prefix CLI \
  --name "Client Site"

Only register real target sites, and use a unique site ID and PID prefix.

A site folder and a workspace may share a name: add-site creates data/<site_id>/md/ for compatibility, and scs ws <name> initialises the workspace CSVs inside that existing folder instead of refusing.

Create and use a workspace

scs bs

This creates data/bs/ with the workspace README, md/, research/, assets/, and staging/ directories, plus the following header-only CSV templates:

bs-keywords.csv
bs-clusters.csv
bs-briefs.csv
bs-links.csv
bs-publishing.csv
bs-performance.csv
md/                      # brief + article, one file per PID
research/                # one folder per PID
staging/                 # temporary downloads and work-in-progress files

There is no separate briefs/ directory: the brief and the article share md/<pid>--<slug>.md.

Put manually downloaded keyword exports and worksheet files in data/bs/staging/ while reviewing them. When ready, import an export into the workspace's keyword CSV, for example:

scs import-csv --site fundamentalstock --workspace bs --source Writerzen \
  data/bs/staging/writerzen-export.csv

The staging copy is a temporary working input; the workspace's prefixed CSVs remain the operational source of truth.

Run the workflow against that workspace:

scs import-csv --site fundamentalstock --workspace bs --source Writerzen /path/to/export.csv
scs score --workspace bs
scs research --workspace bs --pid FS-0001
scs brief --workspace bs --pid FS-0001
scs brief --workspace bs --pid FS-0001 --check
scs brief --workspace bs --pid FS-0001 --approve
scs sync --workspace bs
scs check --workspace bs
scs links check --workspace bs
scs all --workspace bs
scs aliases --workspace bs

Replace fundamentalstock with a site_id present in config/sites.csv. The CSV rows retain site_id; the legacy column name site is not part of the current schema.

Create each workspace once. Running scs bs again reports that it already exists rather than overwriting it.

Archive a workspace

scs bs --delete

SCS asks for confirmation, then moves the complete workspace into archive/workspaces/. Add --force only when you intentionally want to skip the prompt. This archives that workspace's CSVs, Markdown, assets, and staging files together.

Legacy shared CSVs

The old shared data/*.csv files and per-site data/<site>/md/ directories are a legacy layout. Current processing uses the selected workspace's prefixed CSVs. Run python3 scripts/migrate_schema.py after upgrading, then archive or remove legacy files once you have confirmed the workspace data is complete.