Vocion 2.0: your workspace leaves the repo

Until now every vocion-core checkout shipped with a workspace baked into it: workspace/metacto, stale pre-1.0 demo content that every code path silently fell back to whenever WORKSPACE_PATH was unset. Your business context — the layer the whole framework exists to serve — lived inside our repo's git history, tangled into framework upgrades and invisible as the separate thing it is. v2.0.0 breaks that coupling.

What's new

• The bundled workspace is gone. workspace/metacto — agents, operations, objects, missions, evals — is deleted from the repo. Framework code and tenant context no longer share a git history.
• npm run workspace:scaffold -- <name> creates a fresh workspace at ../workspace/<name>, beside the checkout (or anywhere you like with --path <dir>). The scaffold is minimal-but-valid: a workspace.yaml manifest, all nine primitive directories, and a tenant-facing README. workspace:check passes on it as-is.
• WORKSPACE_PATH has no default anymore. With it unset, there is no workspace: dashboard file views show empty state, and workspace:apply and file writes fail with an explicit error that points you at the scaffold command — instead of silently reading demo content.
• Root npm aliases forward flags, so npm run workspace:apply -- <path> --project <slug> works from the repo root, not just inside packages/core.
• Authoring docs consolidated into docs/workspace.md, and the README onboarding now walks scaffold → WORKSPACE_PATH → apply.

Why we built it

A workspace is git-backed, version-controlled context for one tenant: agent prompts, operations, playbooks, workflows, object types. The entire point of workspace-as-code is that the client owns it — reviewable in PRs, diffed across versions, portable between deployments. Keeping one inside vocion-core undermined all of that. It couldn't be its own repo, its edits rode along in framework PRs, and the silent workspace/metacto fallback meant a misconfigured deployment looked like a working one — reading prompts you never wrote.

The peer-level layout also matches how real deployments are shaped. When vocion-core is a submodule of a deployment repo, workspaces sit beside it:

<deployment-repo>/
├── vocion-core/              # the framework (submodule)
└── workspace/
    ├── <tenant-a>/
    └── <tenant-b>/

Upgrading the framework is now a submodule bump; changing what an agent knows is a workspace PR. Two repos, two review streams, two owners.

How to upgrade

Fresh install — scaffold, point, apply:

npm run workspace:scaffold -- acme-revenue        # creates ../workspace/acme-revenue
export WORKSPACE_PATH=../workspace/acme-revenue
npm run workspace:apply -- ../workspace/acme-revenue --project <id|slug>

Existing install — your database is untouched by this release; only the file layout moves. Move your workspace directory out of the checkout to the peer level, make it a git repo if it isn't one, and set WORKSPACE_PATH everywhere the app runs:

mv workspace/<org> ../workspace/<org>
export WORKSPACE_PATH=../workspace/<org>          # absolute paths are safest
npm run workspace:check -- ../workspace/<org>     # validate
npm run workspace:apply -- ../workspace/<org> --project <id|slug>

If you were leaning on the deleted demo content (don't — it was pre-1.0 and stale), recover it from history with git show v1.74.0:workspace/metacto before you pull, or scaffold clean and re-author. Two behaviors got stricter along the way: operations with a postprocess scriptFile now error without WORKSPACE_PATH instead of guessing, and the MCP playbook tools do the same. The full step-by-step, env var table, and gotchas are in the upgrade guide below.

Where to find it

• Upgrade guide: v1 to v2 — read it before pulling.
• Authoring guide: Authoring context, plus docs/workspace.md in the vocion-core repo for the full layout and validation rules.
• GitHub release: https://github.com/vocion/vocion-core/releases/tag/v2.0.0
• Code: packages/core/src/libs/workspace/scaffold.ts and packages/core/src/scripts/scaffold-workspace.ts.