Workspace Studio

Workspace Studio gives each identity one personal workbench per workspace. Edit source, scripts, and custom skills without allocating a database; build one exact disposable Preview only when you need to run the result.

one identity + one workspace
              │
              ▼
    ┌─────────────────────┐
    │    My workbench     │  source · personal scripts · custom skills
    │   no database       │
    └──────────┬──────────┘
               │ Preview
               ▼
    migration generated and editable
    lint · typecheck · repository health · bundle
               │ all green
               ▼
    ┌─────────────────────┐
    │       Preview       │  exact commit · persistent route · one Neon fork
    └──────────┬──────────┘
               │  one-shot workers only while invoked
               │ Request review
               ▼
    ┌─────────────────────┐
    │        Review       │  every reviewer opens the same Preview
    └──────────┬──────────┘
               │ approve
               ▼
             Live          fast-forward only

The authoring flow

The primary Studio surface has two tabs and two forward actions. Preview saves every current draft automatically.

1. Edit My workbench. Drafts remain personal and every source-writing agent uses the same identity-owned workbench.
2. Choose Preview. Studio commits the current drafts, runs every gate, and opens the exact resulting commit.
3. Choose Request review. Reviewers open that same Preview; Review provisions neither another database nor a resident execution worker.
4. An administrator approves the exact reviewed Preview. Live advances by fast-forward and the disposable Preview is retired.

What Preview does

Preview is the only operation that allocates runtime resources, and it is associated with one immutable workbench commit.

1. Generate the migration before provisioning anything. If DDL changed, Studio opens the generated migration for review or editing and asks you to Preview again.
2. Require lint, typecheck, repository health, and the committed migration to be clean.
3. Build the portable workspace bundle and bind its artifact identity to the workbench commit.
4. Persist the Preview route metadata and provision one Neon fork based on Live, with autosuspend enabled. Preview owns no worker; inspection and invocation each use a fresh one-shot worker.
5. Reuse that exact Preview for its author and every reviewer until the commit changes, Live advances, Review ends, or it expires.

Editable DDL. The generated migration is ordinary committed workspace source. Edit it before Preview; release applies the exact reviewed schema plan.

Rebase is the only conflict mechanism

Live history stays linear. Studio never creates merge commits and never offers a second conflict-resolution mode.

Live advances
      │
      ├── retire old Preview (route metadata · Neon fork)
      ▼
Update workbench
      │
      ├── no conflict ───────────────► Preview again
      │
      └── conflict ─► edit named file ─► Update workbench again ─► Preview

• When Live advances, the existing Preview is immediately retired because it no longer represents a releasable base.
• Update workbench replays the personal workbench onto the latest Live commit.
• If a file conflicts, Studio opens it. Edit the intended result, then choose Update workbench again.
• After a successful rebase, build a new Preview for the new exact commit.

Resource lifecycle

The durable authoring state is source metadata outside Bolt. Bolt bundles are stateless and all runtime state comes from facilities.

• My workbench owns no database, route, or execution worker.
• Build trees are temporary and removed after migration generation or compilation; only the shared package store remains.
• Preview owns at most one Neon fork and persistent route metadata per personal workbench. It never owns a resident worker: inspection and invocation workers exist only while running, so tenant worker count returns to zero when idle.
• Replacing, rebasing, rejecting, releasing, or expiring a Preview removes its route metadata, deployment state, and database fork. There is no worker lifecycle to tear down between invocations.

Studio surfaces

• Workbench — manifest and source editor, with Preview and Request review as the only forward actions.
• Review — the exact file diff, exact schema plan, shared Preview, decisions, and linear history.
• Operations — administrator-only runtime diagnostics and rollback, kept out of the normal contributor flow.

Guarantees

• One identity and one workspace resolve to exactly one personal workbench; callers cannot choose another key.
• A Review names one exact commit, artifact, checksum, schema plan, and Preview environment.
• Reviewers allocate no additional runtime resources.
• Changing source or rebasing invalidates the old Preview and any open Review.
• No browser polling is used. Tenant automation progress and agentic chat state live in the database and propagate through the sync engine.