@mmerterden/multi-agent-pipeline 19.1.3 → 20.0.0

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.

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
 
@@ -215,7 +215,7 @@ Per Locked decision 30 of `/multi-agent:analysis` and the parallel rule in `$HOM
 
 The ban is **Figma**-shaped, not MCP-shaped: the multi-agent-toolkit MCP (simulator, screenshot, xcodebuild, accessibility) is unaffected in every phase, and `smoke-no-mcp-in-dev-phases.sh` agrees - it matches `figma` in the tool name and nothing else. A bare "MCP forbidden" has been read as banning the screenshot and UI-test tools, which is how a run reaches Phase 5 with no evidence.
 
-The per-phase matrix (which phase may fetch Figma, and what its sole design source is instead) lives in `rules/figma-pipeline.md` "Phase access matrix". It was copied here as a seven-row table for several releases, two paragraphs below this file's own instruction not to duplicate that rule file. Violation of either copy: `smoke-no-mcp-in-dev-phases.sh` fails the run.
+The per-phase matrix (which phase may fetch Figma, and what its sole design source is instead) lives in `rules/figma-pipeline.md` "Phase access matrix". It is not restated here, per this file's own instruction two paragraphs above not to duplicate that rule file. Violation of either copy: `smoke-no-mcp-in-dev-phases.sh` fails the run.
 
 Memory: [[mcp-only-in-analysis]]
 

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 |