feat(kit)!: the worktree belongs to the operator

CLAUDE.md

@@ -4,7 +4,7 @@ This repo is a Bun monorepo shipping two surfaces: **`plugin/`** — the Claude
 
 The domain glossary lives in [`CONTEXT.md`](./CONTEXT.md) — use those terms exactly.
 
-**The kit runs on a single execution host: the terminal** — a plain interactive `claude` session (incl. ssh, and inside cmux) where Claude Code owns tools, sessions, hooks, worktrees, and background agents. `/dobby:scope` creates+enters the per-goal worktree (native `EnterWorktree`) and brings it up via `bunx dobby up` (which runs the setup phase — install + env-file materialization — probes the workroot, and returns the instructions the model carries out per `plugin/skills/execute/references/bring-up.md`; idempotent, so `/dobby:execute` Step 2 re-runs it without double-starting), and `/dobby:finish` closes the goal — it merges the goal's PR behind an explicit gate (squash, only on the user's "Merge & finish" selection and only once `dobby pr watch` reports merge-ready) when the PR is still open, then tears the worktree down via `bunx dobby down`. **cmux enrichment** (named run/browser panes, cmux-browser UI driver) kicks in when `CMUX_WORKSPACE_ID` is set — the model opens/renames/closes those panes itself, following the instructions `up`/`down` hand back — degrading gracefully to a background `Bash` job otherwise. The mechanical layer is the `@kvnwolf/dobby` CLI — each consumer's single devDependency — which the skills invoke via `bunx dobby`: `env` (environment snapshot), `instructions` (the per-topic instruction catalogue for the detected environment — `start`/`stop`/`browser`/`rename`), `check` (the quality gate + edit-time hook — the hook also reports type errors scoped to the file just edited; `check --fix` is the pre-commit gate, `check --fix --baseline` is the implementor's own Exit gate), `up`/`down`/`dev` (the run lifecycle — `up` folds in worktree setup), and the inferred `db:*` / `update` tasks. The coordinator + QA reach the running app via the devUrl `bunx dobby up` reports. The Architect dispatches the five worker agents directly (Agent tool, named `subagent_type`) following the shared dispatch protocol; Dobby never launches `claude -p`, a native Workflow, or another agent CLI to execute workers. (Conductor, the former second host, was removed; [ADR-0010](./docs/adr/0010-single-terminal-host.md) documents what it did, for a possible future re-add.)
+**The kit runs on a single execution host: the terminal** — a plain interactive `claude` session (incl. ssh, and inside cmux) where Claude Code owns tools, sessions, hooks, worktrees, and background agents. `/dobby:scope` grounds the goal wherever the session already stands — a worktree the operator opened, or a plain checkout on a branch — writes `STATE.md` there, and brings it up via `bunx dobby up` (which runs the setup phase — install + env-file materialization — probes the workroot, and returns the instructions the model carries out per `plugin/skills/execute/references/bring-up.md`; idempotent, so `/dobby:execute` Step 2 re-runs it without double-starting), and `/dobby:finish` closes the goal — it merges the goal's PR behind an explicit gate (squash, only on the user's "Merge & finish" selection and only once `dobby pr watch` reports merge-ready) when the PR is still open, tears the run down via `bunx dobby down`, and — only when the session stands in a worktree — offers to remove it. **cmux enrichment** (named run/browser panes, cmux-browser UI driver) kicks in when `CMUX_WORKSPACE_ID` is set — the model opens/renames/closes those panes itself, following the instructions `up`/`down` hand back — degrading gracefully to a background `Bash` job otherwise. The mechanical layer is the `@kvnwolf/dobby` CLI — each consumer's single devDependency — which the skills invoke via `bunx dobby`: `env` (environment snapshot), `instructions` (the per-topic instruction catalogue for the detected environment — `start`/`stop`/`browser`/`rename`), `check` (the quality gate + edit-time hook — the hook also reports type errors scoped to the file just edited; `check --fix` is the pre-commit gate, `check --fix --baseline` is the implementor's own Exit gate), `up`/`down`/`dev` (the run lifecycle — `up` folds in worktree setup), and the inferred `db:*` / `update` tasks. The coordinator + QA reach the running app via the devUrl `bunx dobby up` reports. The Architect dispatches the five worker agents directly (Agent tool, named `subagent_type`) following the shared dispatch protocol; Dobby never launches `claude -p`, a native Workflow, or another agent CLI to execute workers. (Conductor, the former second host, was removed; [ADR-0010](./docs/adr/0010-single-terminal-host.md) documents what it did, for a possible future re-add.)
 
 ## Structure
 

CONTEXT.md

@@ -2,8 +2,8 @@
 
 The vocabulary of the dobby kit. Use these terms exactly — in skills, agents, docs, and conversation.
 
-- **Execution host** — WHERE a work session runs. There is a SINGLE host: the **terminal host** (see its own entry). The KIT owns the worktree + run lifecycle; the coordinator and **QA** reach the running app via the devUrl `dobby env` resolves (portless-based, distinct per worktree) plus a curl liveness check — not by reading a run-script terminal — and drive the UI per **instruction catalogue** (`dobby instructions browser`, which is cmux's own ladder — cmux-browser → claude-in-chrome → curl — under cmux, and a different guide under Claude Desktop / t3 code). (Conductor, the former second host, was removed; everything it did is captured for a possible future re-add in [ADR-0010](./docs/adr/0010-single-terminal-host.md).)
-- **Terminal host** — the kit's single execution host: a plain `claude` session (incl. ssh, and inside cmux), where the KIT owns the worktree + run lifecycle. `/dobby:scope` creates+enters the per-goal worktree (native `EnterWorktree`, branch `worktree-<slug>` under `.claude/worktrees/`) and brings it up via `bunx dobby up` (setup phase + probe), which `/dobby:execute` Step 2 re-runs idempotently, and `/dobby:finish` closes the goal — merging its PR behind an explicit gate when it is still open, then tearing it all down via `bunx dobby down`. The kit is OPERATED inside the session; environment mechanics are no longer fully delegated to the CLI — `dobby` detects the environment and hands the model an **instruction catalogue** entry for what it cannot do itself (starting the run, opening a browser, renaming the workspace, stopping the run), while `up`/`down` still execute the setup phase, the liveness probe, pidfile registration, Neon branch provisioning, and config `setup[]`/`teardown[]` extras. See also **cmux enrichment**, **Instruction catalogue**.
+- **Execution host** — WHERE a work session runs. There is a SINGLE host: the **terminal host** (see its own entry). The KIT owns the run lifecycle — the session itself runs inside whatever checkout or worktree the operator opened; the coordinator and **QA** reach the running app via the devUrl `dobby env` resolves (portless-based, distinct per worktree) plus a curl liveness check — not by reading a run-script terminal — and drive the UI per **instruction catalogue** (`dobby instructions browser`, which is cmux's own ladder — cmux-browser → claude-in-chrome → curl — under cmux, and a different guide under Claude Desktop / t3 code). (Conductor, the former second host, was removed; everything it did is captured for a possible future re-add in [ADR-0010](./docs/adr/0010-single-terminal-host.md).)
+- **Terminal host** — the kit's single execution host: a plain `claude` session (incl. ssh, and inside cmux), operated inside whatever checkout or worktree the operator already opened — the KIT owns the run lifecycle, not the worktree itself. `/dobby:scope` grounds the goal where the session stands, writes `STATE.md` there, and brings it up via `bunx dobby up` (setup phase + probe), which `/dobby:execute` Step 2 re-runs idempotently; `/dobby:finish` closes the goal — merging its PR behind an explicit gate when it is still open, tearing the run down via `bunx dobby down`, and, only when the session stands in a linked worktree, offering to remove it. Environment mechanics are no longer fully delegated to the CLI — `dobby` detects the environment and hands the model an **instruction catalogue** entry for what it cannot do itself (starting the run, opening a browser, renaming the workspace, stopping the run), while `up`/`down` still execute the setup phase, the liveness probe, pidfile registration, Neon branch provisioning, and config `setup[]`/`teardown[]` extras. See also **cmux enrichment**, **Instruction catalogue**.
 - **cmux enrichment** — the optional layer that activates when `CMUX_WORKSPACE_ID` is present (auto-set in every cmux pane; cmux = the manaflow-ai native macOS terminal). `bunx dobby up` no longer opens the kit panes itself — its `start`/`rename` **instructions** tell the MODEL to open them (a named run pane `dobby-run-<slug>`, a named browser pane `dobby-browser-<slug>`, and renaming the cmux workspace itself to the goal slug), embedding the refs its `list-panes`/`list-pane-surfaces` discovery found so the model reuses an open pane instead of always opening one; `bunx dobby down`'s `stop` instruction likewise tells the model which panes to close. `bunx dobby env` still surfaces the pane refs (`runPane`/`browserPane`, rediscovered by title) for a caller that only needs to read them. A plain terminal (ssh/tmux, no `CMUX_WORKSPACE_ID`) degrades gracefully: its `start` instruction is a background `Bash` job instead of a cmux pane, and `stop`/`rename` never apply.
 - **Instruction catalogue** — what an **environment adapter** delivers: per-**topic** instructions the MODEL executes because `dobby` cannot act there on its own behalf. This is the "instruction half" of the environment-adapter seam; the "mechanics half" — the setup phase, the liveness probe, pidfile registration, Neon branch provisioning, config `setup[]`/`teardown[]` extras — is what `dobby` still executes itself. `dobby instructions <topic> [--json]` reads one entry directly; `up`/`down` embed the applicable ones in their own `instructions[]`.
 - **Topic** — a unit of the **instruction catalogue**: `start` (bring the run up), `stop` (tear it down), `browser` (drive the UI), or `rename` (retitle the workspace to the goal slug). A topic that does not apply in the detected environment (e.g. `rename` on a plain terminal, which has no workspace to rename) is a valid answer — `applies: false` — never an error.
@@ -15,9 +15,9 @@ The vocabulary of the dobby kit. Use these terms exactly — in skills, agents,
 - **Worker** — one of the five custom hands-on agents: `researcher`, `implementor`, `reviewer`, `qa`, and `test-author`. Each has a fixed role and toolset, with its prompt body authoritative in `plugin/agents/`, and model/effort declared directly in that same frontmatter — there is no external recipe to mirror.
 - **Work session** — one end-to-end run over a single goal, moving through stages: scope → interview → research → spec → execute → wrap.
 - **Stage** — one step of a work session. Each stage is a skill that does its job and ends at a Next-step AskUserQuestion gate (the recommended next `/dobby:*` command, alternatives, Stop here); the chosen skill is invoked on selection. Skills carry no per-skill model/effort — the session's tier applies throughout (ADR-0004).
-- **Finish** — the goal-closing stage (`/dobby:finish`): a manual command run once the PR is merged — or merge-ready, since its confirm gate offers **Merge & finish** on an OPEN PR with a clean tree (a squash `gh pr merge`, fired ONLY on that explicit user selection and only after `dobby pr watch` answers `merge-ready`, then a preflight re-read). It checks the PR is MERGED (confirming before merging or destroying anything otherwise), runs **`bunx dobby down`** (which kills the registered run process, deletes the per-worktree Neon branch, and runs the config's `teardown[]` extras — then hands back the `stop` instruction for the model to close any kit-opened cmux pane with), removes the worktree + branch (native `ExitWorktree` when this session created it, raw-git fallback for orphans), and `git pull`s the main checkout.
-- **One session per goal** — the invariant `/dobby:scope` enforces on the terminal host: each session/pane owns ONE goal plus its kit-created worktree on a goal-named branch. It is NOT "one worktree per machine" — MULTIPLE goals run in PARALLEL worktrees, one per cmux pane/session (the cmux value-prop). Scope guards only NESTING (a session already inside a worktree must start the next goal in a new pane, since the native tool can't nest) and slug collisions — it does NOT refuse merely because other sessions' worktrees exist in `.claude/worktrees/`. Teardown is per goal via `/dobby:finish`.
-- **Goal slug** — the kebab-case token a work session is identified BY, and the only place that identity lives: the worktree directory `.claude/worktrees/<slug>/`, the branch `worktree-<slug>`, the cmux workspace title, the kit pane titles and the per-worktree neon branch all derive from it. A free-text goal slugs its own text; an ISSUE goal LEADS with the tracker's id — `issue-42-add-csv-export`, `von-123-fix-stale-session-cache` — so the issue stays recognizable wherever the name gets clipped.
+- **Finish** — the goal-closing stage (`/dobby:finish`): a manual command run once the PR is merged — or merge-ready, since its confirm gate offers **Merge & finish** on an OPEN PR with a clean tree (a squash `gh pr merge`, fired ONLY on that explicit user selection and only after `dobby pr watch` answers `merge-ready`, then a preflight re-read). It checks the PR is MERGED (confirming before merging or destroying anything otherwise), runs **`bunx dobby down`** (which kills the registered run process, deletes the per-worktree Neon branch, and runs the config's `teardown[]` extras — then hands back the `stop` instruction for the model to close any kit-opened cmux pane with), and then: when the session stands in a linked worktree (whoever made it), offers to remove that worktree + branch (native `ExitWorktree` first, then raw git from the main root for an orphan); on a plain checkout, returns to `main` and deletes the goal's branch instead. `git pull` always runs on the main checkout.
+- **One session per goal** — each session/pane owns ONE goal at a time, worked wherever that session stands. It is NOT "one worktree per machine" — MULTIPLE goals run in PARALLEL worktrees, one per cmux pane/session (the cmux value-prop), each opened by the operator (or the host) rather than by the kit. Teardown is per goal via `/dobby:finish`.
+- **Goal slug** — the kebab-case identity a work session is known BY: `basename(workroot)` — the name of whatever checkout or worktree the session already stands in, never a kit-assigned one. The cmux workspace title, the kit pane titles and the per-worktree neon branch all derive from it. A free-text goal slugs its own text; an ISSUE goal LEADS with the tracker's id — `issue-42-add-csv-export`, `von-123-fix-stale-session-cache` — so the issue stays recognizable wherever the name gets clipped.
 - **Context trim** — the inference-only `/dobby:trim-context` sweep that lowers the token/context cost of human-authored repository guidance and comments without changing behavior. It ranks the whole Git workroot by weight, obtains one up-front approval of scope and aggressiveness, runs unattended lots against that approval, and independently reviews every approved write. It is the sole owner of comment changes. It is not a **Gate** and never adds CLI, configuration, tooling, or executable behavior.
 - **AI slop** — generic AI-writing patterns that weaken a specific prose or user-facing-copy unit's clarity, specificity, voice, or purpose. `/dobby:anti-slop` identifies and makes minimum contextual fixes to AI slop without inferring authorship, assigning scores, banning occurrences, or editing comments. When both inference sweeps apply, **Context trim** runs before AI slop.
 - **Sweep ledger** — the tracked state file `.dobby/sweeps.json` that records reviewed sweep coverage with a rules version and SHA-256 hashes of exact final file bytes, keyed per file **and per skill**: each file's entry may hold a `trim-context` sub-key, an `anti-slop` sub-key, or both, and coverage accrues incrementally — an unresolved file simply carries no sub-key for that skill rather than voiding the sweep. Each skill reads and writes only its own so the two sweeps coexist without one invalidating the other's coverage. It is the deliberate exception to the inference-only/no-Gate boundary: persistent coverage state, not a configurable or executable surface.