@mmerterden/multi-agent-pipeline 19.1.4 → 20.0.0

package/pipeline/multi-agent-refs/phases/phase-3-review.md

@@ -104,13 +104,13 @@ Persist the totals as `state.diffRisk` (Phase 4 `risk` section, Phase 5, `run-me
 **Gate behavior**: this step is **never blocking**. If risk scoring fails (git error, parse error, validator rejection), continue with no priority hint  -  reviewers receive the full diff in their default order. Failures are logged via metrics:
 
 ```bash
-[ -z "$RISK_JSON" ] && $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 review.diff_risk_skipped reason=$REASON
+[ -z "$RISK_JSON" ] && $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 review.diff_risk_skipped reason=$REASON
 ```
 
 On success, emit a single summary metric:
 
 ```bash
-$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 review.diff_risk \
+$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 review.diff_risk \
   top_files=$(jq '.files | length' <<< "$RISK_JSON") \
   max_score=$(jq '.totals.max_score' <<< "$RISK_JSON") \
   loc_added=$(jq '.totals.loc_added' <<< "$RISK_JSON") \
@@ -127,7 +127,7 @@ Step 1.75 uses `test_lines_removed` as an advisory hint only  -  too weak for wh
 ```bash
 TEST_INTEGRITY_JSON=$(printf '%s' "$RISK_FULL" | node $HOME/.claude/scripts/test-integrity-gate.mjs 2>/dev/null || echo "")
 TI_COUNT=$(jq -r '.count // 0' <<< "${TEST_INTEGRITY_JSON:-{\}}" 2>/dev/null || echo 0)
-[ "$TI_COUNT" -gt 0 ] && $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 review.test_integrity findings="$TI_COUNT"
+[ "$TI_COUNT" -gt 0 ] && $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 review.test_integrity findings="$TI_COUNT"
 ```
 
 `findings[]` are reviewer-shaped (`test_integrity`, `blocking`), so they merge into the reviewer findings at Step 3.0 and need no triage-prompt or `validate-triage.mjs` change. Triage keeps each blocking unless the removal is justified per the immutable-test rule (spec changed AND commit body names the test) → `deferred[]`.
@@ -142,7 +142,7 @@ On a trivial diff every reviewer agrees and the extra models plus triage are pai
 SCOPE_JSON=$(printf '%s' "$RISK_FULL" | node $HOME/.claude/scripts/review-scope.mjs 2>/dev/null \
   || echo '{"scope":"full","reason":"no risk report - failing safe"}')
 REVIEW_SCOPE=$(jq -r '.scope // "full"' <<< "$SCOPE_JSON")
-$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 review.scope scope="$REVIEW_SCOPE"
+$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 review.scope scope="$REVIEW_SCOPE"
 ```
 
 `single` (Reviewer 1 only) requires **all** of: churn <= 20 lines, `totals.max_score` < 3.0, and no `security_path` / `migration` / `public_api` / `no_test_change` / `test_lines_removed` on any file. Anything else → `full`.
@@ -159,7 +159,7 @@ node $HOME/.claude/scripts/skill-conformance.mjs \
   --repo "$WORKTREE" --out "$WORKTREE/.pipeline/criteria-manifest.json"
 CRIT_RC=$?
 CRITERIA=$(cat "$WORKTREE/.pipeline/criteria-manifest.json" 2>/dev/null || echo '{}')
-$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 review.criteria \
+$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 review.criteria \
   rules="$(jq -r '.selectedRuleCount // 0' <<< "$CRITERIA")" \
   ledger="$(jq -r '.ledger.source // "derived"' <<< "$CRITERIA")"
 [ "$CRIT_RC" != "0" ] && HALT "criteria could not be resolved (rc=$CRIT_RC)  -  see resolutionFailure / unparseableRegistries"
@@ -175,7 +175,7 @@ Output conforms to `$HOME/.claude/schemas/criteria-manifest.schema.json`. The fo
 
 #### Step 1.8  -  Figma visual-fidelity context (when task carries a Figma reference)
 
-**Short-run inputs.** Phases 1 and 2 do not run in a Short run, so three inputs this phase was written around are absent. Substitute them and RECORD the substitution  -  a step that could not run and a step that passed must not read the same, or the completeness claim cannot be checked:
+**Missing inputs.** A section the evidence did not support is absent from the analysis document, so three inputs this phase was written around can be missing. Substitute them and RECORD the substitution  -  a step that could not run and one that passed must not read the same, or the completeness claim cannot be checked:
 
 | Absent input | Substitute |
 |---|---|
@@ -426,8 +426,8 @@ Exit 2 (empty ledger) skips silently. The `## Rejected review preferences` secti
 **Recall telemetry.** Log what was injected, then what triage cited. Zero cited is a legitimate answer; `learning-curve.mjs` trends the ratio:
 
 ```bash
-bash $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 memory.injected kind=prior-art rows=$N
-bash $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 memory.hit rows=$CITED_COUNT
+bash $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 memory.injected kind=prior-art rows=$N
+bash $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 memory.hit rows=$CITED_COUNT
 ```
 
 **Bulky payloads (opt-in via `prefs.global.contextOffload.enabled`).** Test output and whole-file diffs go through the offload filter, which leaves a `[[ref:<node_id>]]` line plus the tail in context and the full text under `.multi-agent/refs/`. Read that file when the tail is not enough; with the pref off it is a pass-through.
@@ -513,7 +513,7 @@ One `review.reviewer_call` per dispatched reviewer, one `review.triage_call`, on
 ```bash
 M=$HOME/.claude/scripts/log-metric.sh
 emit() {  # $1=event $2=model $3=duration $4=tokens_in $5=tokens_out
-  LOG_METRIC_FORWARD_TO_TRACKER=1 bash "$M" "$TASK_ID" 4 "$1" \
+  LOG_METRIC_FORWARD_TO_TRACKER=1 bash "$M" "$TASK_ID" 3 "$1" \
     model="$2" duration_ms="$3" tokens_in="$4" tokens_out="$5"
 }
 emit review.reviewer_call fable  "$R1_DURATION"     "$R1_IN"     "$R1_OUT"      # opus on Copilot CLI
@@ -525,7 +525,7 @@ else
 fi
 emit review.reviewer_call sonnet "$SONNET_DURATION" "$SONNET_IN" "$SONNET_OUT"
 emit review.triage_call fable "$TRIAGE_DURATION" "$TRIAGE_IN" "$TRIAGE_OUT"
-bash "$M" "$TASK_ID" 4 review.completed raw_count=$RAW accepted=$ACC \
+bash "$M" "$TASK_ID" 3 review.completed raw_count=$RAW accepted=$ACC \
   deferred=$DEF rejected=$REJ approved=$APPROVED duration_ms=$DURATION
 ```
 
@@ -614,7 +614,7 @@ Log: "Phase 3: Review  -  raw={N1+N2+N3} accepted={Na} deferred={Nd} rejected={N
 ## Token telemetry  -  invoke after every LLM call
 
 ```bash
-bash $HOME/.claude/scripts/phase-tracker.sh tokens 4 <input_count> <output_count> [cached_count]
+bash $HOME/.claude/scripts/phase-tracker.sh tokens 3 <input_count> <output_count> [cached_count]
 ```
 
 The optional 4th `cached_count` is the prompt-cache-read token count when the host reports it (Anthropic `cache_read_input_tokens`); it defaults to 0 and is priced at the cheaper `cacheReadPerMtok` rate in the Phase 5 cost ledger. The tracker accumulates the totals additively, so multiple calls in the same phase compound. The render output then shows live cost on the active phase tile (e.g. `Phase 2  Dev   2m 14s · 12.4k tok`). This satisfies the contract in `$HOME/.claude/multi-agent-refs/tracker-contract.md` and the `smoke-tracker-tokens-invocation.sh` enforcement gate. Skipping this call is the #1 cause of "I can't see how much it cost" complaints.
@@ -623,15 +623,12 @@ Contract and rationale: `progress-contract.md` -> Token telemetry forwarding.
 
 ---
 
-## User test (was Phase 3 until v19.0.0)
+## User test
 
-Optional test gate, now the tail of Review rather than a phase of its own: it
-judges work that already exists, which is what Review does. Needs an interactive
-prompt AND a worktree checkout, so it is skipped where either is missing. If
-issues are found, the run returns to Phase 1 Dev.
+The tail of Review rather than a phase of its own: it judges work that already
+exists, which is what Review does.
 
-
-> **TLDR**  -  Optional test gate. Offers to boot the simulator/emulator (UI Bug Hunter) or hand off to the user for manual QA. Needs an interactive prompt AND a worktree checkout, so it is in the phase set of `/multi-agent` alone and dropped by every `autopilot` or `--local` entry. Depth does not affect it: a Short run still reaches Phase 3. If issues found, loops back to Phase 2.
+> **TLDR**  -  Optional test gate. Offers to boot the simulator/emulator (UI Bug Hunter) or hand off to the user for manual QA. Needs an interactive prompt AND a worktree checkout, so it runs on an attended `/multi-agent` whose workspace is a worktree, and is skipped on `autopilot` or when the user chose to work locally. If issues found, loops back to Phase 2.
 
 <!-- progress-contract: applied -->
 Progress emission per `$HOME/.claude/multi-agent-refs/progress-contract.md`  -  lines for local-test prompt render, user-answer capture, repo checkout (if selected).
@@ -682,7 +679,7 @@ fi
 **Telemetry**:
 
 ```bash
-LOG_METRIC_FORWARD_TO_TRACKER=0 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 5 test_gap.scanned \
+LOG_METRIC_FORWARD_TO_TRACKER=0 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 test_gap.scanned \
   stack=$SCAN_STACK \
   sources=$(jq '.totals.sourcesScanned' <<< "$GAP_JSON") \
   gaps=$(jq '.totals.gapCount' <<< "$GAP_JSON")
@@ -702,7 +699,7 @@ Figma evidence (tier=<n>):
 
 Tier 1 / Tier 2 records print `screenshotUrl` from the captured evidence (Tier 2 URLs expire after 30 days, re-fetch on the spot if needed). Tier 3 records print the local path to the user-attached screenshot. The block is informational; it never blocks the prompt.
 
-1. Ask with a native `AskUserQuestion` picker (never a typed y/N prompt). The options MUST make the local-checkout side effect explicit  -  testing removes the worktree and checks the branch out into the main repo:
+1. Ask with a native `AskUserQuestion` picker (never a typed y/N prompt), per `$HOME/.claude/multi-agent-refs/picker-contract.md`. The options MUST make the local-checkout side effect explicit  -  testing removes the worktree and checks the branch out into the main repo:
    - `question`: "Check out locally to test now?" (rendered in `outputLanguage`)
    - `header`: "Test" (English, <=12 chars)
    - `options`:
@@ -733,7 +730,7 @@ Tier 1 / Tier 2 records print `screenshotUrl` from the captured evidence (Tier 2
    bash $HOME/.claude/scripts/phase-tracker.sh now 3 "awaiting local test (user)"
    bash $HOME/.claude/scripts/phase-tracker.sh render
    ```
-   The waiting state persists in `tracker-state.json` across the handoff; `/multi-agent:resume-local` and `/multi-agent:manual-test` CONTINUE this state file and never re-init it (`$HOME/.claude/multi-agent-refs/tracker-contract.md` "Continuation runs").
+   The waiting state persists in `tracker-state.json` across the handoff; `/multi-agent:resume` and `/multi-agent:manual-test` CONTINUE this state file and never re-init it (`$HOME/.claude/multi-agent-refs/tracker-contract.md` "Continuation runs").
 
    **"ok" is a structured result, not a word.** Before "ok" is accepted, the run writes `$WORKTREE/.pipeline/manual-test.json`: one entry per acceptance criterion, the criteria taken from the analysis doc test plan (Section 15 / 20), the plan tasks, and the user's own words in the reply. Every criterion records what was seen; a criterion that was not tried says so with a reason.
    ```json
@@ -806,7 +803,7 @@ Returns severity-tagged findings (Critical / High / Medium). Critical items bloc
 When the security-auditor or any other Phase 3 sub-agent runs, forward its token totals so Phase 5's Cost Breakdown captures Phase 3:
 
 ```bash
-LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 5 audit.completed \
+LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 audit.completed \
   model=opus tokens_in=$IN tokens_out=$OUT duration_ms=$DUR
 ```
 

package/pipeline/multi-agent-refs/phases/phase-4-commit.md

@@ -354,19 +354,19 @@ A task ending with one or more `pushStatus === "skipped"` repos does NOT bump `r
 
 ```bash
 for proj in $(jq -r '.projects[].name' "$STATE_FILE"); do
-  $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 6 commit.created   repo=$proj sha=$SHA
-  $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 6 push.attempted   repo=$proj attempts=$N status=$STATUS
-  $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 6 pr.opened        repo=$proj url=$URL number=$N
+  $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 commit.created   repo=$proj sha=$SHA
+  $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 push.attempted   repo=$proj attempts=$N status=$STATUS
+  $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 pr.opened        repo=$proj url=$URL number=$N
 done
-$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 6 multi_repo.completed repos=$REPOS skipped=$SKIPPED
+$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 multi_repo.completed repos=$REPOS skipped=$SKIPPED
 ```
 
 **Token forwarding:** the commit-message and PR-body generators run on a model. Forward those calls into the tracker so Phase 5's Cost Breakdown captures Phase 4:
 
 ```bash
-LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 6 commit.message_generated \
+LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 commit.message_generated \
   model=<sonnet|opus> tokens_in=$IN tokens_out=$OUT duration_ms=$DUR
-LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 6 pr.body_generated \
+LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 pr.body_generated \
   model=<sonnet|opus> tokens_in=$IN tokens_out=$OUT duration_ms=$DUR
 ```
 

package/pipeline/multi-agent-refs/phases/phase-5-report.md

@@ -188,9 +188,9 @@ Skipped sections: when `planTodos.enabled` is false or no `plan.todos[]` was emi
 **Telemetry emission** (mandatory): forward the phase's own LLM spend (humanizer + report compose calls) to the tracker, then emit the final event:
 
 ```bash
-LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 7 report.compose \
+LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 5 report.compose \
   model=$REPORT_MODEL tokens_in=$R_IN tokens_out=$R_OUT duration_ms=$R_DUR
-$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 7 task.completed \
+$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 5 task.completed \
   phases=$PHASE_COUNT review_cycles=$CYCLES lang=$PROMPT_LANG \
   channels_pr=$PR_STATUS channels_jira=$JIRA_STATUS \
   channels_confluence=$CONF_STATUS channels_wiki=$WIKI_STATUS \

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

@@ -15,7 +15,7 @@
 
 | Phase                             | File                                                                 |
 | --------------------------------- | -------------------------------------------------------------------- |
-| Modes (depth picker, autopilot, --local) | `$HOME/.claude/multi-agent-refs/phases/modes.md`            |
+| Modes (autopilot, analysis) | `$HOME/.claude/multi-agent-refs/phases/modes.md`            |
 | Operations (kill, purge, resume)  | `$HOME/.claude/multi-agent-refs/phases/operations.md`       |
 | Phase 0: Init                     | `$HOME/.claude/multi-agent-refs/phases/phase-0-init.md`     |
 | Phase 1: Plan                     | `$HOME/.claude/multi-agent-refs/phases/phase-1-plan.md`     |
@@ -28,11 +28,11 @@
 ## Pipeline Flow
 
 ```
-Full:      0-Init -> 1-Plan -> 2-Dev -> 3-Review -> 4-Commit -> 5-Report
-Short:     0-Init -> (1 skipped) -> 2-Dev -> 3-Review -> 4-Commit -> 5-Report
---local:   Either of the above with no worktree  -  works directly on a local branch
+           0-Init -> 1-Plan -> 2-Dev -> 3-Review -> 4-Commit -> 5-Report
+Local:     The same set with no worktree  -  Phase 0 Step 5b answered local, so
+           work happens directly on a branch in the project root
 
-Full or Short is the Phase 0 Step 7.5 question, not a command name. Autopilot never asks and always runs Full.
+One pipeline: every mode runs its whole phase set, and no answer during the run adds or removes a phase.
 ```
 
 ## Phase entry  -  pending steer (every phase, every mode)
@@ -99,10 +99,8 @@ done
 
 This produces an initial card stack printed by both CLIs.
 
-`/multi-agent` and `/multi-agent:local` are the exception: they do not know their
-set here, because depth decides it at Step 7.5. They register `0:Init` alone, then
-the rest once the answer lands, and call `tiles --new` for the second batch. Full
-contract: `tracker-contract.md`, "Deferred registration".
+No mode is an exception: the phase set is a property of the command, so every
+tile is created in this one batch. Full contract: `tracker-contract.md`.
 
 ### Tracker updates (every phase boundary)
 
@@ -114,7 +112,7 @@ $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress    # phase starts
 $HOME/.claude/scripts/phase-tracker.sh update <N> completed      # phase ends OK
 # or:
 $HOME/.claude/scripts/phase-tracker.sh update <N> failed         # phase failed
-$HOME/.claude/scripts/phase-tracker.sh update <N> skipped        # e.g. 1 and 2 in a Short run
+$HOME/.claude/scripts/phase-tracker.sh update <N> skipped        # e.g. 2 in analysis mode
 ```
 
 After every LLM call (counts are additive; skipping this is why runs end with durations but no cost  -  nothing reconstructs spend afterwards):
@@ -165,7 +163,7 @@ TaskUpdate({ taskId: <saved>, status: "completed" })
 bash phase-tracker.sh update <N> completed
 ```
 
-A phase outside the command's set gets no TaskCreate at all. Depth is different: it is not known at registration time, because the tracker boots at Step -1 and the depth question runs at Step 7.5. So registration splits - Phase 0 alone at Step -1, the rest at Step 7.5 once the answer says which phases the run has. A Short run never draws a Plan tile it will not use. Registering every phase and flipping the skipped one to `skipped` is what this replaced, in v17.5.0: it put a full-width widget on screen beside the question asking whether to run part of it  -  see the ordering rule below.
+A phase outside the command's set gets no TaskCreate at all, and the set is known before the tracker boots.
 
 **(strict) TaskCreate ordering**: All TaskCreate calls MUST fire in strict phase-number order BEFORE any TaskUpdate is applied. The native widget renders by creation order, not by phase number  -  out-of-order calls produce visually scrambled tile stacks (e.g. `1 ✓ · 3 ✓ · 4 ✓ · 0 ▶ · 2 ☐`) even when the underlying state is correct. Pre-marking phases as completed/skipped before Phase 0 starts is FORBIDDEN  -  register the tile in order with default `pending` status, then flip status via TaskUpdate when the phase actually short-circuits. Full contract in `$HOME/.claude/multi-agent-refs/tracker-contract.md` section "TaskCreate ordering (strict)".
 

package/pipeline/multi-agent-refs/progress-contract.md

@@ -69,7 +69,7 @@ Emit a progress line **at least** at every one of these moments:
 
 ### Phase 2 (Planning)
 - plan draft start, plan render, user-approval prompt.
-- **v5.3.0 Plan Approval Gate (Full + interactive only  -  a Short run has no plan, autopilot may not ask):**
+- **v5.3.0 Plan Approval Gate (interactive only  -  autopilot may not ask):**
   - `clarification-ask` per round  -  orchestrator writes structured questions when Phase 1 flagged ambiguity (missing acceptance criteria, no Figma/endpoint link, vague language, parent-story scope drift)
   - `clarification-answer` per round  -  user reply captured into `state.phases["2"].clarificationAnswers`
   - `plan-edit-request` per free-text edit  -  user-supplied revision instruction captured into `state.phases["2"].planEditRequests`

package/pipeline/multi-agent-refs/readiness-review.md

@@ -1,5 +1,7 @@
 # Readiness Review (shared flow for review-jira + review-issue)
 
+> **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.
+
 Assess whether a tracker item (Jira issue or GitHub issue) is READY to hand to the multi-agent pipeline, list the concrete gaps, and - after confirmation - post them back as a comment on the item so the reporter can fix it. Read-only on code: no worktree, no branch, no commits, no dev chaining. This is the inverse of `/multi-agent:create-jira` (which authors a well-formed item); here we grade an existing one.
 
 Both `/multi-agent:review-jira` and `/multi-agent:review-issue` execute this flow; only the provider (fetch + comment endpoint + picker) differs.

package/pipeline/multi-agent-refs/rules.md

@@ -44,7 +44,7 @@ This is the single source of truth. When a contributor or model is unsure where
 3. `AskUserQuestion` `question`, `options[].label` and `options[].description` all follow `OUTPUT_LANG`. Only `header` stays English: a <=12-char chip Turkish overflows. Callers branch on which option was picked, never on its literal text, and pass `default` / `ASK_CHOICE_DEFAULT` as a 1-based index. The host's own **Other** row is always English. Caller rules: `picker-contract.md`.
 4. Always English regardless of either axis: commit messages, PR titles, branch names, code identifiers, agent-state.json values, agent-log.md, reviewer/triage system prompts.
 
-**Failure mode this prevents.** Entering `/multi-agent`, `/multi-agent:autopilot`, `/multi-agent:local`, etc. and switching the assistant's conversational text or picker question copy to English while `outputLanguage="tr"` is set. The user sees a half-English half-Turkish dialogue, flagged as a pipeline bug, not a stylistic choice.
+**Failure mode this prevents.** Entering `/multi-agent`, `/multi-agent:autopilot`, etc. and switching the assistant's conversational text or picker question copy to English while `outputLanguage="tr"` is set. The user sees a half-English half-Turkish dialogue, flagged as a pipeline bug, not a stylistic choice.
 
 ## Code & Commit Rules
 

package/pipeline/multi-agent-refs/tracker-contract.md

@@ -90,11 +90,11 @@ Phases by mode:
 | Mode | Phases |
 |---|---|
 | `/multi-agent` | 0,1,2,3,4,5 |
-| `/multi-agent:local` | 0,1,2,3,4,5 (the user test needs a worktree checkout and local has none, so that STEP inside Review is skipped - the phase is not) |
-| `/multi-agent:autopilot`, `/multi-agent:local-autopilot` | 0,1,2,3,4,5 (always Full; autopilot drops the interactive user test inside Review) |
+| answered local at Step 5b | 0,1,2,3,4,5 (the user test needs a worktree checkout and local has none, so that STEP inside Review is skipped - the phase is not) |
+| `/multi-agent:autopilot` | 0,1,2,3,4,5 (autopilot drops the interactive user test inside Review) |
 | `/multi-agent:analysis` | 0,1,3,4,5 (no code is written, so Dev is not in the set) |
 
-The two picker entries (`/multi-agent`, `:local`) register in two batches, because at Step -1 they do not yet know which set is theirs: see "Deferred registration" below. Every other mode registers its whole set at Step -1.
+Every entry registers its whole set in one batch: the set is a property of the command, known before the tracker boots.
 
 Register each phase:
 
@@ -171,7 +171,7 @@ report's cost-unavailable list.
 
 > **All TaskCreate calls for the active mode's phase set MUST fire in strict phase-number order BEFORE any TaskUpdate is applied. No "pre-mark skipped phases as completed before Phase 0" reasoning is permitted  -  even when the agent knows in advance that a phase will be skipped.**
 
-Why: an agent reasoning "the user picked Short, so phases 1/2 will be skipped  -  let me TaskCreate them as completed first" produces tile IDs `1, 2, 3, ...` for phases 1/2/4, then the Phase 0 tile gets ID `4` and visually drops below them. The user sees `1, 2, 4 ✓ · 0 ▶ · 3 ☐ · ...` instead of `0 ▶ · 1 ✓ · 2 ✓ · 3 ☐ · 4 ✓ · ...`.
+Why: an agent reasoning "analysis mode skips Dev  -  let me TaskCreate it as completed first" produces tile IDs `1, 2, 3, ...` for phases 1/2/4, then the Phase 0 tile gets ID `4` and visually drops below them. The user sees `1, 2, 4 ✓ · 0 ▶ · 3 ☐ · ...` instead of `0 ▶ · 1 ✓ · 2 ✓ · 3 ☐ · 4 ✓ · ...`.
 
 The correct sequence is **always**:
 
@@ -197,44 +197,13 @@ Mode-specific phase sets:
 
 | Mode | TaskCreate set (in order) |
 |---|---|
-| `/multi-agent` | 0 at Step -1; then at Step 7.5 either 1 → 2 → 3 → 4 → 5 (Full) or 2 → 3 → 4 → 5 (Short) |
-| `:local` | same two batches; nothing is dropped, because the user test that needs a worktree checkout is a step inside Review rather than a phase of its own |
-| `:autopilot`, `:local-autopilot` | 0 → 1 → 2 → 3 → 4 → 5 (6 phases  -  always Full; the user test is inside Review now, so no phase is dropped) |
+| `/multi-agent` | 0 → 1 → 2 → 3 → 4 → 5 (6 phases) |
+| answered local | the same set; nothing is dropped, because the user test that needs a worktree checkout is a step inside Review rather than a phase of its own |
+| `:autopilot` | 0 → 1 → 2 → 3 → 4 → 5 (6 phases  -  the user test is inside Review now, so no phase is dropped) |
 | `:analysis` | 0 → 1 → 3 → 4 → 5 (5 phases  -  no code is written, so Dev is not in the set) |
 
 A phase outside the mode's set gets no TaskCreate at all; the `[SKIPPED]` pattern applies only to a phase that IS in the set and short-circuits at runtime. Phase 3 is in every mode's set as of v14.0.0. The authoritative per-mode set is the `for p in ...` init block in each mode's own entry doc, generated by `gen-mode-dispatch.mjs`; this table mirrors those blocks.
 
-#### Deferred registration  -  the depth picker
-
-`/multi-agent` and `:local` cannot know their phase set at Step -1. Depth decides it, and the depth picker cannot run before Step 7.5: its recommendation needs `taskType`, which needs the fetched issue and the branch.
-
-Until v17.5.0 they registered all eight anyway and flipped 1 and 2 to `skipped` at 7.5. That put a widget reading "8 tasks, 7 open  -  Phase 1 Plan, Phase 1 Plan, ..." on screen *beside* the question asking whether to run Analysis and Planning at all, and a Short answer then contradicted a list the user had just been shown. The widget was asserting a shape the run had not chosen.
-
-So registration splits at the moment the shape is known:
-
-```text
-# Step -1, first thing in the run: Phase 0 only. It is the one phase that is
-# certain, and the run is never silent while Phase 0 does its work.
-bash $HOME/.claude/scripts/phase-tracker.sh add 0 Init
-bash $HOME/.claude/scripts/phase-tracker.sh tiles        # -> TaskCreate(Phase 0)
-bash $HOME/.claude/scripts/phase-tracker.sh update 0 in_progress
-
-# Step 7.5, immediately after the depth answer:
-#   Full  -> 1 2 3 4 5            Short -> 2 3 4 5
-#   :local drops nothing - the user test lives inside Review now, so there is
-#   no separate phase for it to skip
-for p in "1:Plan" "2:Dev" "3:Review" "4:Commit" "5:Report"; do
-  bash $HOME/.claude/scripts/phase-tracker.sh add "${p%%:*}" "${p#*:}"
-done
-bash $HOME/.claude/scripts/phase-tracker.sh tiles --new   # -> TaskCreate for the new tiles only
-```
-
-`tiles --new` emits `TaskCreate` only for phases that carry no `tasklist_id` yet, so the Phase 0 tile is not created twice. It is the same ordering rule, applied per batch: every tile in a batch is created in ascending phase order, and a deferred batch only ever appends phases numbered above everything already registered. Nothing is pre-marked, and a phase the run will not execute never gets a tile at all.
-
-A phase that IS registered and short-circuits later still flips with `[SKIPPED]` - autopilot suppressing the Phase 3 user test, for instance. That is a runtime outcome, not an unknown set.
-
-**Enforcement**: `smoke-tasklist-ordering.sh` scans the dispatcher (`commands/multi-agent/SKILL.md`) and every mode entry point doc (`commands/multi-agent/{autopilot,local,local-autopilot,analysis,resume-local}/SKILL.md` + the Copilot full-inline orchestrator mirror) for the explicit "in phase-number order" rule. Inventory drift fails the smoke.
-
 ### Other CLIs  -  call render after every state change
 
 There is no TaskList outside Claude Code. Instead, after each state change the agent calls:
@@ -299,7 +268,7 @@ Throttling rules: mirror only canonical-set lines (`verbose`-tier internals are
 
 ### Delegated phases  -  mirror limitation + chunked dispatch (required)
 
-When a phase's work is delegated to a subagent (Phase 2 Dev on Opus in a Short run, `create-component` plugin dispatch, Phase 1 explorers, Phase 3 reviewers), the visual channel freezes for the duration of the Agent call: the orchestrator is blocked while the call is in flight, so it cannot fire `TaskUpdate` / `now` / `tokens`, and a subagent cannot drive the parent session's TaskList (its own TaskCreate/TaskUpdate calls land on an invisible child list). The progress-line mirror above can therefore only fire while the orchestrator holds control. Rules:
+When a phase's work is delegated to a subagent (`create-component` plugin dispatch, Phase 1 explorers, Phase 3 reviewers), the visual channel freezes for the duration of the Agent call: the orchestrator is blocked while the call is in flight, so it cannot fire `TaskUpdate` / `now` / `tokens`, and a subagent cannot drive the parent session's TaskList (its own TaskCreate/TaskUpdate calls land on an invisible child list). The progress-line mirror above can therefore only fire while the orchestrator holds control. Rules:
 
 1. **Pre-dispatch marker.** Immediately before every Agent call, set the active-phase line to the delegation itself, so the frozen interval at least states what is running and on which model:
    - Claude Code: `TaskUpdate({activeForm: "Dev subagent (opus): <task subject>"})`
@@ -434,7 +403,7 @@ The `tasklist_id` meta from the previous session is replaced with the new IDs du
 
 ## Continuation runs (finish / manual-test)
 
-A pre-existing `tracker-state.json` for the task is never re-initialized. Rules for any command that continues an earlier run (`/multi-agent:resume-local`, `/multi-agent:manual-test`, resume):
+A pre-existing `tracker-state.json` for the task is never re-initialized. Rules for any command that continues an earlier run (`/multi-agent:resume`, `/multi-agent:manual-test`):
 
 1. `init` runs ONLY when no state file exists for the task. Otherwise the existing file is kept - phase history (elapsed, tokens, model, meta) survives.
 2. The continuing command re-declares its phase set with `add` - `add` is idempotent, so existing phases keep their name, status, and token history; only genuinely new phases are appended. The card renders phases sorted by numeric id, so mixed sets stay in order.

package/pipeline/multi-agent-refs/wiki-capture.md

@@ -11,6 +11,8 @@
 - [Cross-CLI parity](#cross-cli-parity)
 <!-- /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.
+
 > **TLDR**  -  Component tasks can auto-generate wiki docs + Figma screenshots. The Wiki adapter is invoked from `/multi-agent:channels` (Phase 5 delegates, or user invokes post-hoc). Four layouts supported (`submodule`, `in-repo`, `github-wiki`, `separate-repo`)  -  adapter picked from `figmaConfig.wiki.mode`. Non-blocking: failures log a warning and channels continues to other adapters. The Wiki adapter supports scope multi-select (Case A) and a precondition-failure menu (Case B)  -  see below.
 
 This doc is referenced from `commands/multi-agent/channels/SKILL.md` (Wiki adapter) and indirectly from `$HOME/.claude/multi-agent-refs/phases/phase-5-report.md` (which delegates all external delivery to channels). Keeping it separate keeps both files under their token budgets and gives the contract a stable location for Claude-side + Copilot-side implementations.
@@ -75,7 +77,7 @@ Autopilot in Phase 5 pauses at the channels menu (per modes.md contract)  -  if
 
 ## Legacy prompt + preference flow (pre-v5.7, still supported for backward compat)
 
-Interactive path (any interactive run, Full or Short), ONLY when the schema lacks `wikiScope`  -  ask with a native `AskUserQuestion` picker (never a typed y/n):
+Interactive path (any interactive run), ONLY when the schema lacks `wikiScope`  -  ask with a native `AskUserQuestion` picker (never a typed y/n):
 
 - `question`: "Generate component wiki docs?" (rendered in `outputLanguage`)
 - `header`: "Wiki" (English, <=12 chars)
@@ -103,7 +105,6 @@ Explicit logs help the developer understand why wiki did or did not run:
 - `figmaConfig` missing entirely → log `Phase 5: wiki skipped (no figma-config for this project)`.
 - User declined at prompt → log `Phase 5: wiki skipped by user`.
 - Autopilot with `wikiDefault=false` → log `Phase 5: wiki skipped (autopilot + wikiDefault=false)`.
-- Short run: DO prompt  -  wiki is cheap and keeps docs fresh on the fast path; skip only if the user says no.
 
 ## Success log
 

package/pipeline/preferences-template.json

@@ -1,5 +1,5 @@
 {
-  "schemaVersion": "2.7.0",
+  "schemaVersion": "2.8.0",
   "global": {
     "identities": [],
     "keychainMapping": {
@@ -101,7 +101,7 @@
     "skillConformance": {
       "blockOnCoverageGap": false
     },
-    "resumeLocal": {
+    "resume": {
       "autoFix": false
     }
   },

package/pipeline/rules/figma-pipeline.md

@@ -75,7 +75,7 @@ The 3-tier fallback chain above governs Figma access in `/multi-agent:analysis`
 | Phase | Sub-command examples | Figma MCP allowed | Figma REST allowed | Reason |
 |---|---|---|---|---|
 | Analysis Phase 1 | `/multi-agent:analysis` Phase 1 fetch | yes | yes (Tier 2 fallback) | Single source of design ground truth |
-| Plan (Phase 1) | `/multi-agent`, `/multi-agent:local`, `/multi-agent:autopilot`, `/multi-agent:local-autopilot` | no | no | Plan reads analysis doc Section 14 + Section 6 |
+| Plan (Phase 1) | `/multi-agent`, `/multi-agent:autopilot` | no | no | Plan reads analysis doc Section 14 + Section 6 |
 | Dev (Phase 2) | every mode that runs Phase 2 (8 modes total) | no | no | Reads analysis doc + Code Connect mapping |
 | Review (Phase 3) | `/multi-agent:review`, every full-pipeline mode | no | no | Reviewer cites analysis doc Section 21 References |
 | Test (inside Phase 3) | `/multi-agent:test`, `/multi-agent:manual-test`, every full mode | no | no | Variant list comes from analysis Section 13.6 + 15.2 |

package/pipeline/schemas/agent-state.schema.json

@@ -66,7 +66,7 @@
     },
     "worktreePath": {
       "type": ["string", "null"],
-      "description": "Absolute path to the task worktree. Null in --local mode."
+      "description": "Absolute path to the task worktree. Null when the Step 5b picker answered local."
     },
     "branch": {
       "type": "string",
@@ -274,7 +274,7 @@
     "workspaceSource": {
       "type": "string",
       "enum": ["asked", "command", "autopilot"],
-      "description": "Who decided where the branch lives. asked = the user answered the Step 5b workspace picker; command = :local / --local / :local-autopilot stated it up front, or a flow that only ever builds worktrees; autopilot = resolved to a worktree without asking, because an unattended commit in the user's own checkout is what worktrees prevent. localMode alone cannot say: false is both a chosen worktree and one nothing asked about."
+      "description": "Who decided where the branch lives. asked = the user answered the Step 5b workspace picker; command = a flow that only ever builds worktrees stated it up front; autopilot = resolved to a worktree without asking, because an unattended commit in the user's own checkout is what worktrees prevent. localMode alone cannot say: false is both a chosen worktree and one nothing asked about."
     },
     "remoteType": {
       "type": "string",
@@ -476,15 +476,10 @@
       "type": "boolean",
       "default": false
     },
-    "onlyDevelop": {
-      "type": "boolean",
-      "default": false,
-      "description": "Short pipeline  -  phases 1 and 2 are skipped. Set by the Phase 0 Step 7.5 depth picker as of v16.0.0; the key and every reader of it are unchanged. Phase 3 Review still runs (v14.0.0+). Always false in an autopilot run, which never asks the depth question."
-    },
     "localMode": {
       "type": "boolean",
       "default": false,
-      "description": "--local flag  -  no worktree, direct branch in projectRoot."
+      "description": "Step 5b answered local  -  no worktree, direct branch in projectRoot."
     },
     "instructionDriven": {
       "type": "boolean",
@@ -498,7 +493,7 @@
     "analysis": {
       "type": ["object", "null"],
       "additionalProperties": true,
-      "description": "Phase 1 analysis-document outcome. Absent in Short runs, which produce no document by design.",
+      "description": "Phase 1 analysis-document outcome. Phase 1 runs in every mode, so a document is always produced; what varies is how many of its sections the evidence supported.",
       "properties": {
         "docStatus": {
           "type": "string",
@@ -1530,7 +1525,7 @@
               }
             }
           },
-          "description": "Captured in Phase 2 after the build+test gate, because the user test is dropped by every autopilot and --local entry."
+          "description": "Captured in Phase 2 after the build+test gate, because the user test is dropped by every autopilot entry and by any run whose workspace is local."
         },
         "host": {
           "type": ["string", "null"],

package/pipeline/schemas/migrations/prefs-2.7.0-to-2.8.0.mjs

@@ -0,0 +1,33 @@
+/**
+ * prefs-2.7.0-to-2.8.0.mjs  -  preferences migration
+ *
+ * v20.0.0 folds `/multi-agent:resume-local` into `/multi-agent:resume`. One
+ * command now asks which unfinished work to pick up: a run that stopped
+ * mid-phase, or a branch carrying work no run ever produced. The preference
+ * that decides whether triage-accepted findings are auto-fixed applies to the
+ * second path, so it moves with it: `global.resumeLocal` -> `global.resume`.
+ *
+ * The value is carried, never reset. Someone who turned auto-fix on for the
+ * tail meant it for exactly the work this path still handles.
+ *
+ * @param {object} data  -  parsed multi-agent-preferences.json
+ * @returns {object}     -  migrated data with schemaVersion "2.8.0"
+ */
+export default function migrate(data) {
+  const out = JSON.parse(JSON.stringify(data));
+
+  out.schemaVersion = "2.8.0";
+
+  if (!out.global || typeof out.global !== "object") return out;
+
+  const legacy = out.global.resumeLocal;
+  if (!out.global.resume || typeof out.global.resume !== "object") {
+    out.global.resume = {};
+  }
+  if (typeof out.global.resume.autoFix !== "boolean") {
+    out.global.resume.autoFix = typeof legacy?.autoFix === "boolean" ? legacy.autoFix : false;
+  }
+  delete out.global.resumeLocal;
+
+  return out;
+}

package/pipeline/schemas/phases.json

@@ -6,7 +6,6 @@
   "phaseSchema": 2,
   "phaseSchemaNote": "The phase vocabulary generation. metrics.jsonl is append-only and v19.0.0 renumbered the phases, so every line written from v19.0.0 on carries this number and a line without the field is generation 1. Aggregators pick their name table from it; without it phase 3 means Dev in old rows and Review in new ones and no reader can tell them apart.",
   "legacyPhaseNames": {
-    "note": "Generation 1 phase names, kept so an aggregator can label a historical metrics.jsonl row correctly instead of printing the current name for a number that meant something else. Read-only history: nothing emits these any more. The generation 1 -> 2 number map is not repeated here, it is the `was` array on each phase above.",
     "0": "Init",
     "1": "Analysis",
     "2": "Planning",
@@ -14,7 +13,8 @@
     "4": "Review",
     "5": "Test",
     "6": "Commit",
-    "7": "Report"
+    "7": "Report",
+    "note": "Generation 1 phase names, kept so an aggregator can label a historical metrics.jsonl row correctly instead of printing the current name for a number that meant something else. Read-only history: nothing emits these any more. The generation 1 -> 2 number map is not repeated here, it is the `was` array on each phase above."
   },
   "phases": [
     {
@@ -64,35 +64,14 @@
   "modes": {
     "full": {
       "phases": [0, 1, 2, 3, 4, 5],
-      "local": false,
-      "autopilot": false,
-      "depth": true
+      "autopilot": false
     },
     "autopilot": {
       "phases": [0, 1, 2, 3, 4, 5],
-      "local": false,
-      "autopilot": true
-    },
-    "local": {
-      "phases": [0, 1, 2, 3, 4, 5],
-      "local": true,
-      "autopilot": false,
-      "depth": true
-    },
-    "local-autopilot": {
-      "phases": [0, 1, 2, 3, 4, 5],
-      "local": true,
       "autopilot": true
     },
-    "full-local": {
-      "phases": [0, 1, 2, 3, 4, 5],
-      "local": true,
-      "autopilot": false,
-      "depth": true
-    },
     "analysis": {
       "phases": [0, 1, 3, 4, 5],
-      "local": false,
       "autopilot": false
     }
   },

package/pipeline/schemas/prefs.schema.json

@@ -14,8 +14,8 @@
   "properties": {
     "schemaVersion": {
       "type": "string",
-      "enum": ["2.0.0", "2.1.0", "2.2.0", "2.3.0", "2.4.0", "2.5.0", "2.6.0", "2.7.0"],
-      "description": "v2.0.0: pre-v3.7. v2.1.0: v3.7+ adds identities[].servicePatMap, platformIdentityRouting, recentGroups, recentBranches, serviceStatus, settings, expanded keychainMapping. v2.2.0: v6.0.0 formalizes v5.7 / v5.8 additions (reportChannels, reportContent with technicalAnalysis, wikiScope, autopilotReportTimeoutSeconds) that had been running as 2.1.0 sub-migrations without a proper version bump. v2.5.0: v14.0.0 adds global.skillConformance (Phase 4 criteria resolution) and declares global.ship.autoFix, which the tail command's spec had referenced as global.finish.autoFix without ever declaring it. v2.6.0: v15.0.0 renames global.ship to global.resumeLocal (/multi-agent:ship -> :resume-local). v2.7.0: v19.0.0 drops the analysis Lite mode (global.analysisPhase.mode keeps a single value 'full') and adds global.modelRouting, which ships disabled."
+      "enum": ["2.0.0", "2.1.0", "2.2.0", "2.3.0", "2.4.0", "2.5.0", "2.6.0", "2.7.0", "2.8.0"],
+      "description": "v2.0.0: pre-v3.7. v2.1.0: v3.7+ adds identities[].servicePatMap, platformIdentityRouting, recentGroups, recentBranches, serviceStatus, settings, expanded keychainMapping. v2.2.0: v6.0.0 formalizes v5.7 / v5.8 additions (reportChannels, reportContent with technicalAnalysis, wikiScope, autopilotReportTimeoutSeconds) that had been running as 2.1.0 sub-migrations without a proper version bump. v2.5.0: v14.0.0 adds global.skillConformance (Phase 4 criteria resolution) and declares global.ship.autoFix, which the tail command's spec had referenced as global.finish.autoFix without ever declaring it. v2.6.0: v15.0.0 renames global.ship to global.resumeLocal (/multi-agent:ship -> :resume-local). v2.7.0: v19.0.0 drops the analysis Lite mode (global.analysisPhase.mode keeps a single value 'full') and adds global.modelRouting, which ships disabled. v2.8.0: v20.0.0 folds :resume-local into :resume and renames global.resumeLocal to global.resume."
     },
     "global": {
       "type": "object",
@@ -1923,15 +1923,15 @@
             }
           }
         },
-        "resumeLocal": {
+        "resume": {
           "type": "object",
           "additionalProperties": false,
-          "description": "/multi-agent:resume-local (formerly :ship, :finish) - the tail that runs review + build/test + PR + report over work already on the branch.",
+          "description": "/multi-agent:resume - picking up unfinished work, either a run that stopped mid-phase or a branch carrying work no run produced. These keys apply to the second path, which runs review + build/test + PR + report over the branch diff.",
           "properties": {
             "autoFix": {
               "type": "boolean",
               "default": false,
-              "description": "When true, resume-local auto-fixes triage-accepted blocking/important findings and re-reviews instead of asking. Equivalent to passing `autopilot` on every run. Default false: resume-local operates on work the user wrote by hand, so silently rewriting it is the surprising option."
+              "description": "When true, the tail path auto-fixes triage-accepted blocking/important findings and re-reviews instead of asking. Equivalent to passing `autopilot` on every run. Default false: this path operates on work the user wrote by hand, so silently rewriting it is the surprising option."
             }
           }
         },

package/pipeline/scripts/cost-table.json

@@ -16,7 +16,7 @@
       "cacheReadPerMtok": 0.5,
       "modelId": "claude-opus-5",
       "provider": "anthropic",
-      "note": "Second tier - dev phase on a Short run, Reviewer 1 and triage on Copilot CLI, and the opus rung of the fable -> opus -> sonnet fallback ladder. Same rate as the Opus 4.8 it replaces, so the ledger needed no reprice on the generation move. Claude Opus 5 draws on a rate-limit pool SEPARATE from the combined Opus 4.x pool - moving traffic here neither frees headroom on the old bucket nor inherits it."
+      "note": "Second tier - Reviewer 1 and triage on Copilot CLI, and the opus rung of the fable -> opus -> sonnet fallback ladder. Same rate as the Opus 4.8 it replaces, so the ledger needed no reprice on the generation move. Claude Opus 5 draws on a rate-limit pool SEPARATE from the combined Opus 4.x pool - moving traffic here neither frees headroom on the old bucket nor inherits it."
     },
     "sonnet": {
       "inPerMtok": 3.0,