@mmerterden/multi-agent-pipeline 19.1.4 → 20.1.0

package/pipeline/multi-agent-refs/phases/modes.md

@@ -1,18 +1,16 @@
-> **TLDR**  -  four entry commands, two axes, and depth is no longer one of them:
+> **TLDR**  -  four entry commands, one pipeline, two axes:
 >
-> - **Depth** is a picker, not a flag. Phase 0 Step 7.5 asks Full or Short and sets `state.onlyDevelop`. Short strips to Init → Dev(Opus self-contained) → Review → Test → Commit → Report. Review is never stripped.
-> - **`autopilot`** skips confirmations (Plan, Test, Commit, PR prompts) and therefore skips the depth question too, always running Full. Still fails safe on review blockers and build retries.
-> - **`--local`** means no worktree: work happens in `$PROJECT_ROOT` on a local branch.
+> - **`autopilot`** skips confirmations (Plan, Test, Commit, PR prompts). Still fails safe on review blockers and build retries.
+> - **Workspace** is the one question the run asks about its own shape: a worktree, or the project root on a local branch. Phase 0 Step 5b asks it; autopilot resolves it to a worktree and never asks.
 >
-> Fastest path is `/multi-agent:local` then Short. There is no fast-and-unattended combination any more, and that is deliberate  -  see "Pipeline depth".
+> There is one pipeline and every mode runs its whole phase set. What a run costs follows the evidence the task carries, not an answer taken before the evidence exists.
 
 ## Autopilot Mode
 
 <!-- toc -->
 - [Autopilot Mode](#autopilot-mode)
-- [Pipeline depth (Full / Short)](#pipeline-depth-full-short)
 - [Analysis Mode (`/multi-agent:analysis`)](#analysis-mode-multi-agentanalysis)
-- [Local Mode (`--local`)](#local-mode---local)
+- [Local Mode](#local-mode)
 <!-- /toc -->
 
 Autopilot mode skips interactive confirmations and runs the pipeline end-to-end autonomously.
@@ -27,15 +25,19 @@ Autopilot mode skips interactive confirmations and runs the pipeline end-to-end
 /multi-agent "LoginView dark mode fix" autopilot
 ```
 
-**What changes in autopilot (Tablo 1  -  Full pipeline modes):**
+**What changes in autopilot (Tablo 1)**
 
-| Phase               | Normal (full)                                           | autopilot (full)                            | local (full)                                | local autopilot (full)                      |
-| ------------------- | ------------------------------------------------------- | ------------------------------------------- | ------------------------------------------- | ------------------------------------------- |
-| Phase 1 (Plan Approval Gate) | Clarification (max 2 rounds) + approval loop  -  user: approve/abort/free-text edit | **Gate skip**  -  log the plan, proceed directly to Phase 2 (autopilot contract: zero interaction) | Same as Normal | Same as autopilot |
-| Phase 3 (User Test) | Interactive prompt ("Want to test?" -> wait)            | Skip (autopilot suppresses interactive prompts) -> proceed directly to Phase 4 | **Not in the phase set** (the gate checks the change out of a worktree; local has none) | Not in the phase set |
-| Phase 4 (Commit)    | "Want to commit?" -> wait                               | Auto commit + push                          | "Want to commit?" -> wait                   | Auto commit + push                          |
-| Phase 4 (PR)        | "Want to open a PR?" -> wait                            | Auto create PR                              | "Want to open a PR?" -> wait                | Auto create PR                              |
-| **Phase 5 (Channels)**  | Multi-select channel + content menu                 | **STILL PAUSES**  -  see "Phase 5 autopilot exception" below | Multi-select (same as Normal) | **STILL PAUSES** (same as autopilot) |
+Two axes, and only the first is a command: whether anything is confirmed
+(`autopilot`), and where the work happens (the Step 5b answer). An autopilot run
+always gets a worktree, so there is no unattended-local column.
+
+| Phase | Interactive, worktree | Interactive, local | autopilot (always worktree) |
+| --- | --- | --- | --- |
+| Phase 1 (Plan Approval Gate) | Clarification (max 2 rounds) + approval loop  -  user: approve/abort/free-text edit | Same as worktree | **Gate skip**  -  log the plan, proceed directly to Phase 2 (autopilot contract: zero interaction) |
+| Phase 3 (User Test step) | Interactive prompt ("Want to test?" -> wait) | **Not offered**  -  the step checks the change out of a worktree and there is none; the phase itself still runs | Skip (autopilot suppresses interactive prompts) -> proceed directly to Phase 4 |
+| Phase 4 (Commit) | "Want to commit?" -> wait | "Want to commit?" -> wait | Auto commit + push |
+| Phase 4 (PR) | "Want to open a PR?" -> wait | "Want to open a PR?" -> wait | Auto create PR |
+| **Phase 5 (Channels)** | Multi-select channel + content menu | Multi-select (same) | **STILL PAUSES**  -  see "Phase 5 autopilot exception" |
 
 **What NEVER skips (even in autopilot):**
 
@@ -51,90 +53,20 @@ Autopilot mode skips interactive confirmations and runs the pipeline end-to-end
 
 The generic "zero-interaction" contract covers Phases 0-4 only. Phase 5 channels dispatch is the **single exception**:
 
-- ALL modes (`autopilot`, `--local autopilot`, and a Short run reaching Phase 5) pause at the channels multi-select menu.
+- ALL modes, `autopilot` included, pause at the channels multi-select menu.
 - Menu pre-ticks from `prefs.global.reportChannels` + `prefs.global.reportContent`  -  user can accept with one keypress if prefs are stable.
 - **30-minute timeout**  -  if user does not respond, session ends cleanly:
   - External delivery aborted (no silent apply  -  prevents accidental Jira comments / Confluence pages).
   - Internal capture (`agent-log.md`, telemetry, knowledge base) STILL runs.
-  - State persisted as `{phase: 7, waitingFor: "user-channels-choice", channelsTimeout: true}`.
+  - State persisted as `{phase: 5, waitingFor: "user-channels-choice", channelsTimeout: true}`.
   - Resume: `/multi-agent:resume <task-id>` re-opens menu with same inputs.
 - Post-hoc `/multi-agent:channels <task>` never times out  -  user invoked it explicitly.
 
 Full contract: `$HOME/.claude/multi-agent-refs/phases/phase-5-report.md` (Autopilot pause contract) + `commands/multi-agent/channels/SKILL.md`.
 
----
-
-## Pipeline depth (Full / Short)
-
-Short strips the pipeline to what an already-scoped task needs: no deep analysis, no planning phase. The **Opus** dev agent reads the task scope and implements, and Phase 3 then reviews what it produced. Review is deliberately NOT part of the strip: analysis and planning shape work that has not happened yet, so a task the user has already scoped can skip them, while review judges work that now exists and has no substitute.
-
-**How it is chosen.** Phase 0 Step 7.5, after `taskType` is known:
-
-```
-Bu is icin hangi pipeline? / Which pipeline for this task?
-  1. Tam / Full    Analysis -> Plan -> Dev -> Review -> Test -> Commit -> Report
-  2. Kisa / Short  Dev (self-contained, Opus) -> Review -> Test -> Commit -> Report
-```
-
-`bugfix` and `chore` recommend Short; `feature`, `refactor` and `component` recommend Full. The recommendation is presented first and passed as `ASK_CHOICE_DEFAULT` on hosts without a native picker, because `ask-choice.sh` picks the first option on a non-TTY and option order is not a contract. Pass it as the **1-based index** (Full = 1, Short = 2), not as the label: labels render in `outputLanguage`, so a label-valued default matches nothing on a `tr` run.
-
-**Who is asked.** `/multi-agent` and `/multi-agent:local`. Both autopilot entries always run Full without asking.
-
-**Why there is no fast-and-unattended combination.** It existed until v16.0.0, and removing it was a real behaviour change, not a rename. Autopilot may not ask, so something has to choose, and unattended is the worst place to drop analysis and planning: nobody is watching to notice what the shortcut lost. A cron job or script that wants both now has to pick - stay unattended and pay for the full pipeline, or stay fast and have a person present.
-
-**Pipeline in a Short run:**
-
-```
-Phase 0: Init -> Phase 2: Dev (self-contained) -> Phase 3: Review -> Phase 3: Review (user test) -> Phase 4: Commit -> Phase 5: Report
-```
-
-**What changes (Tablo 2  -  Short runs):**
-
-| Phase               | Full                                            | Short                                                                              | Short + `--local`                             |
-| ------------------- | ----------------------------------------------- | ---------------------------------------------------------------------------------- | --------------------------------------------- |
-| Phase 0 (Init)      | Full setup                                      | Same  -  worktree, branch, state, and the depth question itself                      | Same  -  no worktree, branch on `$PROJECT_ROOT` |
-| Phase 1 (Analysis)  | Parallel Explore agents + analysis document     | **SKIP**  -  no tile is ever drawn for it (registration is deferred to Step 7.5)     | **SKIP**                                      |
-| Phase 1 (Planning)  | TaskCreate + architecture review + **Plan Approval Gate** | **SKIP** (no plan means no plan gate)                                    | **SKIP**                                      |
-| Phase 2 (Dev)       | Follows the Phase 1 plan, TDD cycle (Sonnet)    | **Self-contained** (Opus): agent scans relevant files, implements with TDD, builds | Same, on the local branch                     |
-| Phase 3 (Review)    | Parallel review + Fable triage (3 reviewers on every host: Claude Code Fable + Opus + Sonnet, Copilot GPT-5.4 + Opus + Sonnet) | **Same**  -  gates, parallel review, triage; blocking findings return to Phase 2 (cap 3) | **Same**, on the local branch diff |
-| Phase 3 (User Test) | Interactive prompt                              | **Interactive prompt**                                                             | Not in the set  -  no worktree to check out    |
-| Phase 4 (Commit)    | Commit + PR                                     | Same  -  still asks                                                                  | Same                                          |
-| Phase 5 (Report)    | Full report + channels multi-select             | Simplified  -  no analysis section, review section IS present, channels menu still pauses | Same                              |
-
-**Phase 2 in a Short run (self-contained):**
-
-The **Opus** agent receives the task description (from Jira, GitHub issue, or free-text) and:
-
-1. Quickly scans relevant files in the codebase (lightweight, not full Explore)
-2. Implements the change following TDD cycle (test -> code -> build)
-3. Runs build verification (max 3 retries on failure)
-
-No separate task breakdown  -  the agent handles scope autonomously.
-
-**State tracking**: `agent-state.json` gets `"onlyDevelop": true`. The tracker boots at Step -1 with Phase 0 alone and the rest of the tiles are registered at Step 7.5, once this answer says which phases the run actually has - so a Short run never draws an Analysis tile it will not use. Full contract: `$HOME/.claude/multi-agent-refs/tracker-contract.md` section "Deferred registration".
-
-### Intake warnings for a Short run
-
-**An analysis document was supplied.** Because Phase 1 and Phase 1 are skipped, no phase turns that document into a task breakdown. The doc becomes raw context for one Dev pass, and work comes out ordered by whatever the model read first: the bottom of the dependency chain lands, the screen wiring does not.
-
-The depth picker is where this is caught. When the intake carried an analysis document or a Figma reference, say so in the question itself rather than after the choice:
-
-```
-This task carries an analysis document. Short skips Analysis and Planning, so
-the document will not be turned into a task breakdown.
-  1. Tam / Full    (recommended here)
-  2. Kisa / Short  (doc as context only)
-```
-
-Autopilot never sees this: it runs Full.
-
-**The branch already carries the work.** When the change was developed outside the pipeline, or by hand, Short is still the wrong entry point: it will try to develop again. `/multi-agent:resume-local` puts the existing diff through the same review, adds a build+test success gate, opens the PR, and posts the Jira technical-analysis + test-scenario comment  -  without re-developing. Offer it when the working tree or branch is already ahead of the base with the task's changes.
-
----
-
 ## Analysis Mode (`/multi-agent:analysis`)
 
-Not a depth permutation - a different **output kind**. It produces the analysis document and stops; no code, no branch, no PR. The 6-phase contract holds, with four phases reinterpreted the same way a Short run reinterprets Phase 2.
+A different **output kind**, not a shorter pipeline. It produces the analysis document and stops; no code, no branch, no PR. The 6-phase contract holds, with four phases reinterpreted the same way a Short run reinterprets Phase 2.
 
 ```
 Phase 0: Init -> Phase 1: Plan (analysis) -> Phase 1: Plan -> Phase 3: Review -> Phase 4: Publish -> Phase 5: Report
@@ -151,18 +83,19 @@ Phase 0: Init -> Phase 1: Plan (analysis) -> Phase 1: Plan -> Phase 3: Review ->
 | 6 Commit | **Publish** instead: Local file / Confluence / Jira. Locked 6 still forbids `git add` and `git commit` |
 | 7 Report | Channels, same as every mode |
 
-**No `local` or `autopilot` variant.** Worktree isolation buys nothing when no code is written, and the intake, the Pass B convention preview and the open-question resolution are interactive by nature; a zero-interaction analysis would be a document nobody agreed to.
+**No `autopilot` variant.** Worktree isolation buys nothing when no code is written, and the intake, the Pass B convention preview and the open-question resolution are interactive by nature; a zero-interaction analysis would be a document nobody agreed to.
 
 **Where the document lands.** Drafts go to `/tmp/analysis-<slug>-<ts>/` first, then the Phase 4 picker decides: Local writes `<repo>/analysis/<feature>-<platform>.md` uncommitted, Confluence posts the page, Jira updates the description. In the full pipeline the same engine writes into the worktree instead and `prefs.global.analysisPhase.commitDoc` decides whether it rides along with the commit.
 
 ---
 
-## Local Mode (`--local`)
+## Local Mode
 
 Local mode skips worktree creation  -  works directly on a local branch in the project root. Useful for single-task workflows or when worktrees cause issues.
 
-**Activation**: answer the Phase 0 Step 5b workspace question, or state it up
-front so the question resolves without being asked.
+**Activation**: answer the Phase 0 Step 5b workspace question. There is no flag
+and no command name for it - the answer is the only way in, which is why the
+question carries what the choice costs.
 
 ```
 Bu is nerede kossun? / Where should this task run?
@@ -171,25 +104,16 @@ Bu is nerede kossun? / Where should this task run?
 ```
 
 Two genuine options, so it meets the two-option floor in `picker-contract.md` on
-its own. **Say what local costs inside the question**: Phase 3 is not in a local
-run's set (the user-test gate checks the change out of a worktree, and there is
-none), and uncommitted work in the project root is in the way of the checkout. A
-user choosing local should learn both before choosing, not after.
-
-The ways to state it up front:
-
-```
-/multi-agent:local "PROJ-12345"
-/multi-agent:local "#316"
-/multi-agent:local "LoginView dark mode fix"
-/multi-agent:local-autopilot "PROJ-12345"
-/multi-agent "PROJ-12345" --local
-```
+its own. **Say what local costs inside the question**: the user-test STEP inside
+Phase 3 checks the change out of a worktree, so a local run does not get that
+offer (the phase itself still runs), and uncommitted work in the project root is
+in the way of the checkout. A user choosing local should learn both before
+choosing, not after.
 
 Every autopilot entry resolves this to **worktree** and never asks. That is not a
 skipped question: an unattended run commits and pushes from wherever it stands,
-and doing that in the user's own checkout is what worktrees exist to prevent.
-`:local-autopilot` is the explicit opt-out.
+and doing that in the user's own checkout is what worktrees exist to prevent. An
+unattended run therefore always gets its own checkout.
 
 **What changes in local mode:**
 
@@ -221,4 +145,4 @@ git -C $PROJECT_ROOT config user.email "{identity.email}"
 - Uncommitted changes in PROJECT_ROOT may conflict  -  pipeline warns if dirty
 - Build queue lock still applies for xcodebuild
 
-**Combinable**: `/multi-agent:local-autopilot` is the no-worktree unattended path; `/multi-agent:local` then Short is the no-worktree fast path.
+Fast path.

package/pipeline/multi-agent-refs/phases/operations.md

@@ -17,6 +17,8 @@
 - [Phase Pipeline](#phase-pipeline)
 <!-- /toc -->
 
+> **Pickers follow** `$HOME/.claude/multi-agent-refs/picker-contract.md`: never a one-option call, and branch on the option selected, not on its text.
+
 Every task gets an auto-incremented short ID. Counter stored at `$HOME/.claude/logs/multi-agent/{project}/.counter` (persists across sessions).
 
 ```

package/pipeline/multi-agent-refs/phases/phase-0-init.md

@@ -14,23 +14,21 @@ $HOME/.claude/scripts/phase-tracker.sh tiles
 $HOME/.claude/scripts/phase-tracker.sh update 0 in_progress
 ```
 
-**Phase 0 only.** `/multi-agent` and `:local` do not know their phase set yet -
-depth decides it, and depth is Step 7.5 - so they register the rest there rather
-than drawing eight tiles the user has not chosen. Every other mode registers its
-whole set here, in phase-number order. Contract: `tracker-contract.md`,
-"Deferred registration".
+**Every mode registers its whole set here**, in phase-number order. The phase
+set is known at Phase 0 because there is one pipeline: no answer later in the
+run can add or remove a phase. Contract: `tracker-contract.md`.
 
 `tiles` prints this host's widget-registration calls: **make them before continuing.** The card alone lands in collapsed tool output, so a run that skips them runs in silence. Contract: `tracker-contract.md`, "The card is not the widget".
 
 If `INPUT_TASK_ID` isn't known yet (free-text, project not selected), use a placeholder; rename later via `mv` once parsed in Step 1.
 
-Every subsequent phase (1-7) MUST call `phase-tracker.sh update <N> in_progress` on entry and `phase-tracker.sh update <N> completed|failed|skipped` on exit. Each `update` prints a `-- NEXT (required) --` block: act on it. Sub-phase milestones use `phase-tracker.sh sub <N> <subN> "<name>" <status>`. See `$HOME/.claude/multi-agent-refs/phases.md` "Visual Phase Tracker" for the full contract.
+Every subsequent phase (1-5) MUST call `phase-tracker.sh update <N> in_progress` on entry and `phase-tracker.sh update <N> completed|failed|skipped` on exit. Each `update` prints a `-- NEXT (required) --` block: act on it. Sub-phase milestones use `phase-tracker.sh sub <N> <subN> "<name>" <status>`. See `$HOME/.claude/multi-agent-refs/phases.md` "Visual Phase Tracker" for the full contract.
 
-`update <N> completed` **exits 3** for phases 1-4 with no recorded spend: record `model` + `tokens`, or pass `--no-llm`, then re-run it. Contract: `tracker-contract.md`, "Accounting is a gate".
+`update <N> completed` **exits 3** for phases 1-5 with no recorded spend: record `model` + `tokens`, or pass `--no-llm`, then re-run it. Contract: `tracker-contract.md`, "Accounting is a gate".
 
 ##### TaskCreate ordering on Claude Code (strict)
 
-On Claude Code, fire every `TaskCreate` in a registration batch in strict phase-number order BEFORE any `TaskUpdate` in that batch - which is the order `tiles` prints them in - and never register a phase whose number is below one already registered. A deferred batch (Step 7.5) therefore appends, it does not interleave. Full contract: `$HOME/.claude/multi-agent-refs/tracker-contract.md` section "TaskCreate ordering (strict)".
+On Claude Code, fire every `TaskCreate` in a registration batch in strict phase-number order BEFORE any `TaskUpdate` in that batch - which is the order `tiles` prints them in - and never register a phase whose number is below one already registered. Full contract: `$HOME/.claude/multi-agent-refs/tracker-contract.md` section "TaskCreate ordering (strict)".
 
 ---
 
@@ -46,6 +44,13 @@ OUTPUT_LANG=$(jq -r '.global.outputLanguage // "en"' "$PREFS_FILE" 2>/dev/null |
 
 From this point on, everything the user reads renders in `$OUTPUT_LANG`: conversational lines, `AskUserQuestion` `question`/`label`/`description`, and external payload bodies (PR/Jira/Confluence). English stays only on `header`, commit messages, branch names, PR title prefixes, identifiers. Full matrix: `rules.md` "Language Application".
 
+**Every picker in this phase prints its breadcrumb.** Phase 0 is one chain -
+account, repos, base branch, maturity, dev-context, workspace - and each step
+emits the narrator line `<localized: "Step i/n: what this step decides">` above
+its question, per `picker-contract.md` "Step narration". A step that resolves
+without asking (one account, no siblings) still prints its line with the
+resolution noted, so the numbering reads continuously instead of jumping.
+
 **Model tier resolution** (same step, once per run): read `prefs.global.modelFallback`. If `fableEnabled` is `false`, every `preferredModel: fable` persona resolves to `opus` for this run and the Phase 3 Claude Code panel is 2 reviewers, not 3; print the one-line INFO. Then, if `premiumTierUntil` is set and in the past, apply the date-gate trigger - `preferredModel` personas dispatch on `fallbackModel`, with the one-line WARN. Both lines and the exact ordering: `$HOME/.claude/multi-agent-refs/features/model-fallback.md`. Dispatch-error and budget triggers apply per-dispatch later; nothing else to do here.
 
 **First-run guard**: After loading prefs, check if `keychainMapping` has at least one non-null value. If ALL values are null (template defaults  -  setup never ran), show:
@@ -323,8 +328,7 @@ above, recorded as `baseBranchSource: "input"`. Everything else asks, and
 One row is a normal outcome of the rule-5 filter and is **still asked**, with a
 real second option - `picker-contract.md`, "Two options or it is not a question".
 
-This holds in every mode. A Short run skips the *LLM* phases (Analysis, Planning); it
-does not skip Phase 0's pickers. Autopilot resolves them without prompting, which still
+This holds in every mode. Autopilot resolves them without prompting, which still
 writes the fields; its base-branch resolution order is in `features/base-branch-evidence.md`.
 
 **TTL filter for recent branches**:
@@ -412,11 +416,11 @@ Branch name is deterministic  -  no user confirmation needed.
 #### Step 5b  -  Workspace (worktree or local)
 
 Ask where the branch lives - the wording, the two options and what local costs
-are in `modes.md`, "Local Mode". Here because Step 4 named the branch, Step 6b
-acts on the answer, and Step 7.5 needs the phase set it implies.
+are in `modes.md`, "Local Mode". Here because Step 4 named the branch and Step
+6b acts on the answer.
 
-**Who is asked.** `/multi-agent` only (`workspaceSource: "asked"`). `:local` and
-`--local` state it up front (`command`).
+**Who is asked.** Every interactive entry (`workspaceSource: "asked"`). There is
+no flag and no command name that pre-answers it.
 Every autopilot entry resolves it to a worktree and never asks (`autopilot`).
 
 **Persist** `state.localMode` (semantics unchanged) and `state.workspaceSource`,
@@ -448,7 +452,7 @@ Log: `Identity: {identity.name} <{identity.email}>`
 
 1. `git -C $PROJECT_ROOT fetch origin`
 
-**If local** (Step 5b answered local, by question, by `:local` / `--local`):
+**If local** (Step 5b answered local):
 
 ```bash
 if [ -n "$(git -C $PROJECT_ROOT status --porcelain)" ]; then
@@ -464,7 +468,7 @@ git -C $PROJECT_ROOT config user.email "{identity.email}"
 
 **If worktree** (Step 5b answered worktree, or autopilot resolved it): 2. Worktree path: Jira → `.worktrees/{jiraId}/`, GitHub → `.worktrees/GH{issueNo}/`, free-text → `.worktrees/task-{shortId}/` 3. **Heal stale admin state first** (see "Worktree stale-lock heal" below) and **apply the residue guard** (see "Worktree residue guard" below), then `git -C $PROJECT_ROOT worktree add {path} -b {branch} origin/{baseBranch}` (if exists: enter, pull) 4. Set identity: `git -C {worktree-path} config user.name/email` 5. Create log dir + `agent-log.md` + `agent-state.json` at `$HOME/.claude/logs/multi-agent/{project}/{task-id}/`, never inside the worktree:
 
-**Worktree location convention (cited by every other command):** always `{projectRoot}/.worktrees/{taskId}`, inside the repo, never under `$HOME`. `{taskId}` is the directory name from the rule above (`DC-<shortId>` for `/multi-agent:design-check`). `.worktrees` is fixed, not a preference: no `worktreeBasePath` key exists, and `gc-worktrees.sh`, `purge.sh`, the cost renderers and `usage-report.mjs` resolve `<repo>/.worktrees/` by name. Multi-repo tasks get one worktree per repo (the loop below); `--local` creates none and `worktreePath` is `$PROJECT_ROOT`.
+**Worktree location convention (cited by every other command):** always `{projectRoot}/.worktrees/{taskId}`, inside the repo, never under `$HOME`. `{taskId}` is the directory name from the rule above (`DC-<shortId>` for `/multi-agent:design-check`). `.worktrees` is fixed, not a preference: no `worktreeBasePath` key exists, and `gc-worktrees.sh`, `purge.sh`, the cost renderers and `usage-report.mjs` resolve `<repo>/.worktrees/` by name. Multi-repo tasks get one worktree per repo (the loop below); a local answer creates none and `worktreePath` is `$PROJECT_ROOT`.
 
 **Worktree stale-lock heal (required before every `worktree add`):** a run killed mid-`worktree add` (OOM, SIGTERM, disk full) leaves a locked or broken admin entry under `.git/worktrees/{id}/`, so the retry fails with `fatal: '<path>' already exists`. Always run the heal first  -  it is a no-op on a clean repo:
 
@@ -584,30 +588,6 @@ Persist: `"taskType": "component" | "bugfix" | "feature" | "refactor" | "chore"`
 
 Log: `Phase 0 Step 7: taskType = {component|bugfix|feature|refactor|chore}`
 
-#### Step 7.5  -  Pipeline depth (Full / Short)
-
-Ask the depth question from `$HOME/.claude/multi-agent-refs/phases/modes.md` "Pipeline depth" - it carries the wording, the per-`taskType` recommendation and the mode tables. Here because the recommendation needs `taskType` (Step 7), which needs the fetched issue (Step 1) and the branch (Step 3).
-
-**Who is asked.** `/multi-agent` and `/multi-agent:local` only. Both autopilot entries and analysis mode skip it; autopilot always runs Full.
-
-When the intake carried an analysis document or a Figma reference, say so **inside** the question: Short skips the only two phases that would turn that document into a task breakdown, and the user should learn that before choosing, not after.
-
-**Pass the default as a 1-based index, never a label.** `ask-choice.sh` takes the first option on a non-TTY, and a label-valued default matches nothing once the options render in `outputLanguage`. Reasoning: `modes.md`, "Pipeline depth".
-
-```bash
-# Full is option 1, Short is option 2 (modes.md "Pipeline depth")
-DEPTH_DEFAULT_INDEX=1; [ "$DEPTH_RECOMMENDATION" = "short" ] && DEPTH_DEFAULT_INDEX=2
-ASK_CHOICE_DEFAULT="$DEPTH_DEFAULT_INDEX" \
-  $HOME/.claude/lib/ask-choice.sh "<localized: 'Which pipeline for this task?'>" \
-  "<localized: 'Full'>" "<localized: 'Short'>"
-```
-
-**Persist.** Short sets `state.onlyDevelop = true`; Full leaves it `false`. The key is unchanged - only who sets it changed - so every downstream reader keeps working.
-
-**Now register the rest of the widget.** This answer is the first moment the phase set is known, so the remaining tiles are created here and not before - Full `1 2 3 4 5 6 7`, Short `3 4 5 6 7`, `:local` dropping 5 from either. `add` each, then `phase-tracker.sh tiles --new`, which emits TaskCreate only for phases that carry no tile yet. Contract: `tracker-contract.md`, "Deferred registration".
-
-Log: `Phase 0 Step 7.5: depth = {full|short} (recommended {full|short}, source {user|autopilot|default})`
-
 #### Step 7.6  -  Test baseline (opt-in, `prefs.global.testBaseline.enabled`, default `false`)
 
 Phase 3 Gate 3 cannot tell an inherited red suite from one this run broke, so it blocks on someone else's bug or the agent "fixes" tests it never touched. Runs after Step 6, only when the stack has a test command; skipped in analysis mode.
@@ -644,7 +624,8 @@ Persist that file as `state.evidenceCapability`, then build the menu from it, ne
 
 A closed option keeps its row and prints the probe's reason verbatim. No `uiTestTargets` closes 2; `mcp` false closes 3; a missing `device` or `recorder` closes both. Targets present with no `matchingTests` leaves 2 open, warning that the whole UI suite will run. **When only option 1 is open, do not ask**: `testDepth = unit`, `testDepthSource = forced`, and the tier 3 gap is written.
 
-Default as a 1-based index, never a label - same rule and same reason as Step 7.5:
+Default as a 1-based index, never a label: `ask-choice.sh` takes the first
+option on a non-TTY, so a label-valued default silently becomes option 1.
 
 ```bash
 DEPTH_DEFAULT_INDEX=1
@@ -653,7 +634,7 @@ DEPTH_DEFAULT_INDEX=1
 ASK_CHOICE_DEFAULT="$DEPTH_DEFAULT_INDEX" $HOME/.claude/lib/ask-choice.sh ...
 ```
 
-Asked by `/multi-agent` and `:local`; autopilot reads `prefs.global.testDepth.default` and degrades to the best open option. Asked here, not Phase 3, which four of the eight modes drop.
+Asked by every interactive entry; autopilot reads `prefs.global.testDepth.default` and degrades to the best open option. Asked here, not Phase 3, which four of the eight modes drop.
 
 Log: `Phase 0 Step 7.7: testDepth = {unit|unit+ui|unit+mcp} (source {user|autopilot|default|forced}), tier1/tier2 = {open|closed}`
 

package/pipeline/multi-agent-refs/phases/phase-1-plan.md

@@ -1,6 +1,8 @@
 ### Phase 1: Plan (Opus)
 
-> **TLDR**  -  One phase, two halves. First the codebase is explored and the analysis document written (the design contract the rest of the run reads); then that document is decomposed into concrete tasks with file-level targets, risk grading and architecture review. The phase ends at the **Plan Approval Gate**: in normal mode the orchestrator asks structured clarification questions when scope is ambiguous (max 2 rounds), renders the plan, and loops on free-text edits until the user approves or aborts. The gate is **skipped entirely** for a Short run and for `autopilot`. Analysis and planning were Phases 1 and 2 until v19.0.0; the depth picker already skipped them as one unit (`state.onlyDevelop`), which is why they are one phase now.
+> **TLDR**  -  One phase, two halves. First the codebase is explored and the analysis document written (the design contract the rest of the run reads); then that document is decomposed into concrete tasks with file-level targets, risk grading and architecture review. The phase ends at the **Plan Approval Gate**: in normal mode the orchestrator asks structured clarification questions when scope is ambiguous (max 2 rounds), renders the plan, and loops on free-text edits until the user approves or aborts. The gate is **skipped entirely** for `autopilot`, which has no one to ask.
+
+> **Pickers follow** `$HOME/.claude/multi-agent-refs/picker-contract.md`: never a one-option call, and branch on the option selected, not on its text.
 
 <!-- progress-contract: applied -->
 Progress emission per `$HOME/.claude/multi-agent-refs/progress-contract.md`  -  lines for each Explore dispatch, each finish, analyst synthesis start, `analysis.json` write.
@@ -441,10 +443,6 @@ Log: "Phase 1: Consistency  -  requirements:{N/N mapped} anchors:{ok|M unanchore
 - `state.autopilot === true` (autopilot contract: zero interaction)
 - Autopilot safety classifier returns `recommendPause: false` (see Step 5c below)
 
-OR:
-
-- `state.onlyDevelop === true` (Short pipeline: direct to Phase 2, no plan)
-
 In the skipped case, log `🧠 Phase 1: Plan  -  gate skipped ({mode}), proceeding to Phase 2` and go to Phase 2.
 
 ##### 5c  -  Autopilot safety classifier (runs before 5a/5b skip decision)
@@ -571,9 +569,8 @@ The pipeline shapes interact with the gate as follows. This table is the source
 
 | Mode | Clarification | Approval Loop | Safety Classifier | Notes |
 |---|---|---|---|---|
-| Full, interactive (`/multi-agent`, `:local`) | ✅ (max 2 rounds) | ✅ |  -  (redundant when a human approves) | Full gate |
-| Short (depth picker answered Short) | ❌ | ❌ |  -  | Phase 1-2 skipped at Step 7.5; Phase 2 starts immediately |
-| `autopilot`, `:local-autopilot` | ❌ | ❌ conditional | ✅ (if `autopilotSafetyGate !== false`) | Always Full, so a plan exists. Safe plans proceed silently; high-risk plans trigger a one-time manual approval. Log records the score. |
+| Interactive (`/multi-agent`) | ✅ (max 2 rounds) | ✅ |  -  (redundant when a human approves) | Full gate |
+| `/multi-agent:autopilot` | ❌ | ❌ conditional | ✅ (if `autopilotSafetyGate !== false`) | A plan always exists. Safe plans proceed silently; high-risk plans trigger a one-time manual approval. Log records the score. |
 
 **Why autopilot now has an escape hatch:** the old "zero interaction  -  fully trust the scope" contract held well for tightly-scoped batch workflows (figma component iteration over known-safe components) but broke in edge cases  -  schema migrations auto-merging, security-path drift going silent, delete-without-test sprawls. The safety classifier (Step 5c) is opt-out so the default protects against the edge-case cost; users running known-safe workflows can flip `prefs.global.autopilotSafetyGate = false` to restore pre-v7.0 behavior.
 
@@ -582,18 +579,10 @@ The pipeline shapes interact with the gate as follows. This table is the source
 After plan generation (and after each edit-loop iteration), forward the planning model's call totals so Phase 5's Cost Breakdown captures Phase 1 (`model=` names the rung that actually ran: `fable`, or `opus` after a fallback step):
 
 ```bash
-LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 2 plan.generated \
+LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 1 plan.generated \
   model=fable tokens_in=$IN tokens_out=$OUT duration_ms=$DUR iteration=$N
 ```
 
 Best-effort. See `$HOME/.claude/multi-agent-refs/progress-contract.md#token-telemetry-forwarding`.
 
----
-
-## Token telemetry  -  invoke after every LLM call
-
-```bash
-bash $HOME/.claude/scripts/phase-tracker.sh tokens 2 <input_count> <output_count>
-```
-
-Contract and rationale: `progress-contract.md` -> Token telemetry forwarding.
+Both halves of this phase report into the same counter: see "Token telemetry" above.

package/pipeline/multi-agent-refs/phases/phase-2-dev.md

@@ -1,6 +1,6 @@
 ### Phase 2: Dev (Sonnet)
 
-> **TLDR**  -  Sonnet executes the plan task-by-task with TDD (red→green→refactor). Required: issue-tracker status moved to "In Progress" before any code, with a post-mutation verify step (re-reads the field, retries once on silent VALIDATION failures). Build verification after each task (up to 3 retries). Build-queue lock serializes concurrent xcodebuild. A Short run (`state.onlyDevelop`) uses Opus self-contained, with no Phase 1 plan. `taskType === component` **short-circuits the TDD path** and delegates the whole phase to the enabled `ai-<platform>-toolkit` marketplace plugin's component skill (`create-component`, fallback `create-ui-component`)  -  see next subsection.
+> **TLDR**  -  Sonnet executes the plan task-by-task with TDD (red→green→refactor). Required: issue-tracker status moved to "In Progress" before any code, with a post-mutation verify step (re-reads the field, retries once on silent VALIDATION failures). Build verification after each task (up to 3 retries). Build-queue lock serializes concurrent xcodebuild. `taskType === component` **short-circuits the TDD path** and delegates the whole phase to the enabled `ai-<platform>-toolkit` marketplace plugin's component skill (`create-component`, fallback `create-ui-component`)  -  see next subsection.
 
 ## Phase 2 Pre-flight (BLOCKING, v9.0.0)
 
@@ -8,11 +8,11 @@ Per Locked decision 30, Phase 2 Dev consumes the analysis document as the sole d
 
 Pre-flight steps (run in order, abort on failure).
 
-**Steps 1, 2, 3, 5 and 6 apply only when Phase 1 ran.** In a Short run (`state.onlyDevelop === true`) there is no analysis doc by design, so they are recorded `not-applicable (no Phase 1 in this mode)` and skipped  -  an unconditional abort there would make every fast mode impossible. Steps 4, 7, 8 and 9 apply in every mode.
+**Steps 1, 2, 3, 5 and 6 read the analysis document.** Phase 1 always runs, so the document always exists; what varies is how much evidence it carries. A section the evidence did not support is absent by the Locked 2 omission rule, and a step whose section is absent is recorded `not-applicable (no <section> in this document)` rather than aborting. Steps 4, 7, 8 and 9 read nothing from it and apply always.
 
 1. **Analysis document presence** (Phase 1 modes only): read `state.analysis.docStatus` and `state.analysis.docPath[]`, both set by Phase 1 Step 4.
    - `produced` | `reused` -> read the active platform's file; multi-repo runs need one per selected repo.
-   - `not-applicable` -> no document by design; record it for steps 1, 2, 3, 5, 6 and skip them, as a Short run does.
+   - `not-applicable` -> the analysis mode exported a document this run does not consume; record it for steps 1, 2, 3, 5, 6 and skip them.
    - **Abort**: `produced` but unreadable -> `ERR: analysis doc at <path> unreadable. Resume with /multi-agent:resume #N.` Producing it is Phase 1's job.
 
 2. **Parse YAML front-matter** into `state.analysis.frontMatter`: `feature`, `platform`, `language`, `mode`, `evidence_digest`, `template_version`. **Abort** when `template_version` < `v3`; there is no degraded mode.
@@ -49,7 +49,7 @@ The analysis document is the SOLE design source in Phase 2. Variant choices, pad
 
 #### Input contract
 
-Phase 2 consumes the Phase 1 output object conforming to `$HOME/.claude/schemas/planning-output.schema.json`  -  the task graph (`tasks[]` with `id`, `title`, `type`, `files`, and optional `dependsOn` / `acceptanceCriteria`) plus the architecture review notes. Tasks execute in dependency order; the schema's `dependsOn` field drives the ready-task picker. In a Short run (no Phase 1), Opus generates the equivalent task list inline before entering the loop below.
+Phase 2 consumes the Phase 1 output object conforming to `$HOME/.claude/schemas/planning-output.schema.json`  -  the task graph (`tasks[]` with `id`, `title`, `type`, `files`, and optional `dependsOn` / `acceptanceCriteria`) plus the architecture review notes. Tasks execute in dependency order; the schema's `dependsOn` field drives the ready-task picker.
 
 **Plan Todo iteration (opt-in)**: gated by `prefs.global.planTodos.enabled` (default: `false`). When enabled and Phase 1 Step 11 emitted a `plan.todos[]`, Phase 2 iterates via `$HOME/.claude/lib/plan-todos.sh next/start/complete/fail` instead of walking `tasks[]` directly. When disabled, the loop walks `tasks[]` from `planning-output`  -  TDD contract is unchanged. Full helper loop + state semantics: `$HOME/.claude/multi-agent-refs/features/plan-todos.md`. A todo with `sourceTag: Reuse` binds the file analysis already found; `Modify` edits in place. Writing a new file over a `Reuse` step is a Locked 11 violation and Phase 3 flags it.
 
@@ -57,7 +57,7 @@ Phase 2 consumes the Phase 1 output object conforming to `$HOME/.claude/schemas/
 
 #### Component tasks  -  delegated dispatch (taskType === "component")
 
-When Phase 0 Step 7 classified the task as `component`, Phase 2 delegates the entire phase to the enabled `ai-<platform>-toolkit` marketplace plugin's component skill (`create-component`, fallback `create-ui-component`) via the Skill tool and does NOT run the TDD loop below. The dispatch layer passes the plugin skill the analysis Section 6 (Bileşen Envanteri) entry + Section 13.1 conventions for the named component as context. Because plugin skills do not write pipeline state, the **dispatch layer** (not the skill) owns `state.phases["2"].subphases[]`, recording a coarse component-build row - multi-agent's `phase-tracker` reads that array with no special case. Plugin resolution (dual-name), dispatch call, failure/resume, multi-repo, Short-run elisions, and the intentional cross-CLI divergence live in `$HOME/.claude/multi-agent-refs/component-dispatch.md` - read it before editing component-task behaviour here. Phase 2 still owns: progress line `-> dispatching create-component <name>`, `retryCount` cap at 3, and fallthrough to the TDD path when dispatch prerequisites are missing (`taskType` absent OR the plugin is not enabled in this repo -> log anomaly, halt or run TDD per component-dispatch.md).
+When Phase 0 Step 7 classified the task as `component`, Phase 2 delegates the entire phase to the enabled `ai-<platform>-toolkit` marketplace plugin's component skill (`create-component`, fallback `create-ui-component`) via the Skill tool and does NOT run the TDD loop below. The dispatch layer passes the plugin skill the analysis Section 6 (Bileşen Envanteri) entry + Section 13.1 conventions for the named component as context. Because plugin skills do not write pipeline state, the **dispatch layer** (not the skill) owns `state.phases["2"].subphases[]`, recording a coarse component-build row - multi-agent's `phase-tracker` reads that array with no special case. Plugin resolution (dual-name), dispatch call, failure/resume, multi-repo, and the intentional cross-CLI divergence live in `$HOME/.claude/multi-agent-refs/component-dispatch.md` - read it before editing component-task behaviour here. Phase 2 still owns: progress line `-> dispatching create-component <name>`, `retryCount` cap at 3, and fallthrough to the TDD path when dispatch prerequisites are missing (`taskType` absent OR the plugin is not enabled in this repo -> log anomaly, halt or run TDD per component-dispatch.md).
 
 For non-component taskTypes (`bugfix`, `feature`, `refactor`, `chore`), continue with the standard TDD section below.
 
@@ -92,7 +92,7 @@ If the latest iteration has `triage.approved === true` AND `accepted === []`, Ph
 **Telemetry**: at the start of every re-entry, emit:
 
 ```bash
-$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 rework.started \
+$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 2 rework.started \
   iteration=$ITERATION accepted_blocking=$BLOCKING accepted_important=$IMPORTANT
 ```
 
@@ -275,12 +275,12 @@ After the build/test green step and BEFORE Phase 3 handoff, run one diff-shrink
 5. **Record tokens in the cost ledger** so Phase 5's Cost Breakdown captures the pass:
 
 ```bash
-LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 dev.simplifier_pass \
+LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 2 dev.simplifier_pass \
   model=sonnet tokens_in=$IN tokens_out=$OUT duration_ms=$DUR \
   edits_returned=$RET edits_applied=$APPLIED edits_skipped=$SKIPPED
 ```
 
-Scope guard: a single pass, never looped. Runs in a Short run too; component tasks (`taskType === "component"`) skip it (the figma skill owns its own checklist).
+Scope guard: a single pass, never looped. Component tasks (`taskType === "component"`) skip it (the figma skill owns its own checklist).
 
 ---
 
@@ -297,37 +297,6 @@ Exit 1 lists `unjustified[]`: complete the record once and re-run. A second exit
 
 ---
 
-#### Short pipeline (`state.onlyDevelop === true`)
-
-Set by the Phase 0 Step 7.5 depth picker, or by autopilot never (autopilot always runs Full). When it is true, Phase 2 runs self-contained with **Opus** (not Sonnet). No Phase 1 plan exists  -  the agent creates its own scope.
-
-**Flow:**
-1. Read task description (from Jira, GitHub issue, or free-text)
-2. Lightweight file scan  -  grep/glob for relevant code (not full Explore agents)
-3. Determine scope autonomously  -  no task breakdown, no user confirmation
-4. Implement with TDD cycle (same RED→GREEN→REFACTOR as normal mode)
-5. Build verification (same lock, same retry logic)
-6. Intermediate commits (same WIP pattern)
-
-**Key differences from normal mode:**
-
-| Aspect | Full | Short |
-|--------|--------|----------|
-| Model | Sonnet | **Opus** |
-| Plan source | Phase 1 task list | Self-determined |
-| Task granularity | Per-plan-item | Agent decides |
-| Status updates | Per task item | Single in_progress → completed |
-| Scope confirmation | Phase 1 user approval | None (agent autonomous) |
-| Review of the result | Phase 3 | Phase 3 (same) |
-
-Because the agent determines its own scope here, Phase 3 is the only place that checks the result against anything external. Record every skill, plugin skill and guide consulted during this phase into `state.telemetry.skillCalls[]` with the files it was applied to  -  Phase 3 resolves the criteria set independently, and this record is what lets it tell "applied and honoured" from "never opened".
-
-**Never combined with autopilot.** Autopilot skips the depth question and runs Full, so `onlyDevelop` is false in every unattended run. "Fast plus unattended" was removed in v16.0.0 and no longer exists: something has to choose when nobody is asked, and unattended is the worst place to drop analysis and planning.
-
-**Tracker visibility during Opus dispatch**: on Claude Code the model switch to Opus happens via subagent dispatch, and the parent widget cannot move while an Agent call is in flight. Dispatch per task from the self-generated task list (never one monolithic call for the whole phase), set the pre-dispatch `activeForm` marker, and record tokens between chunks  -  full rules in `$HOME/.claude/multi-agent-refs/tracker-contract.md` section "Delegated phases".
-
----
-
 #### v2.1.0+ Multi-Repo Mode
 
 Active when `state.projects[].length > 1` (set by Phase 0 multi-select). Single-repo flow above is preserved verbatim  -  this section adds the deltas.
@@ -372,26 +341,26 @@ This closes the gap where an agent records "built" without ever producing build
 
 **Telemetry**: Per-repo metrics in addition to per-task metrics:
 ```bash
-$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 build.completed repo=common duration_ms=$D status=ok
-$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 build.completed repo=uicomponents duration_ms=$D status=ok
+$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 2 build.completed repo=common duration_ms=$D status=ok
+$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 2 build.completed repo=uicomponents duration_ms=$D status=ok
 ```
 
 **Token forwarding:** every TDD round (red, green, refactor) that hits the dev model MUST forward token totals into the tracker so Phase 5's Cost Breakdown captures Phase 2:
 
 ```bash
-LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 dev.tdd_round \
+LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 2 dev.tdd_round \
   model=<sonnet|opus> step=<red|green|refactor> \
   tokens_in=$IN tokens_out=$OUT duration_ms=$DUR
 ```
 
-Model resolves from the active mode: a Full run uses Sonnet, a Short run uses Opus. Best-effort. See `$HOME/.claude/multi-agent-refs/progress-contract.md#token-telemetry-forwarding`.
+Model is Sonnet unless routing names another rung (`multi-agent-refs/features/model-fallback.md`). Best-effort. See `$HOME/.claude/multi-agent-refs/progress-contract.md#token-telemetry-forwarding`.
 
 ---
 
 ## Token telemetry  -  invoke after every LLM call
 
 ```bash
-bash $HOME/.claude/scripts/phase-tracker.sh tokens 3 <input_count> <output_count>
+bash $HOME/.claude/scripts/phase-tracker.sh tokens 2 <input_count> <output_count>
 ```
 
 Contract and rationale: `progress-contract.md` -> Token telemetry forwarding.