@mmerterden/multi-agent-pipeline 15.16.0 → 16.0.0

package/pipeline/commands/multi-agent/analysis-resolve/SKILL.md

@@ -21,24 +21,13 @@ Companion command to `/multi-agent:analysis`. Takes an `analysis/<feature>-<plat
 - **Locked 24 (Pass B footnote).** When a resolution overrides a convention cell in Section 13 (or any per-platform projection), the cell's footnote is rewritten to `^[user-override: resolved via analysis-resolve <date>]`.
 - **Locked 30 (no MCP outside analysis phase).** This command makes NO Figma MCP calls, no `api.figma.com` requests, no `figma.com/design/...` fetches. A row that genuinely needs new design information gets only `Defer` plus a printed recommendation to re-run `/multi-agent:analysis` for that input. Repo reads and `~/.claude/lib/extract-conventions.sh` re-runs are allowed (they are local evidence, not design fetches).
 
-## New Locked decisions (this command)
-
-1. **One question per `AskUserQuestion` call.** Never batch Section 20 rows. Sequential resolution keeps each decision explicit and traceable.
-2. **Up to 3 source-labeled candidates plus Defer = 4 options max.** Each candidate's `description` carries its source label: `From evidence - <doc section / citation>`, `From repo - <file:line>`, `AI reasoned - <one-line rationale>`. The auto-provided Other accepts free text and stop tokens.
-3. **Three sources, never blended.**
-   - **From evidence**: the answer is already derivable from the doc's own sections and their citations (Sections 5, 6, 9, 13, 21) or from cached `state.analysisSpec.evidence.*` when the session still holds it. Cite the section or evidence bucket.
-   - **From repo**: the batched Phase 1 repo lookup (one Explore subagent) returned an answer with a `file:line` citation.
-   - **AI reasoned**: contextual reasoning grounded in the loaded doc (feature scope, platform, surrounding sections). Requires a one-line rationale; skip if the basis is no stronger than guessing.
-4. **Never invent.** If no source produces a credible candidate, offer only Defer and Other.
-5. **Stop tokens** (case-insensitive, typed into Other): `stop`, `pause`, `dur`, `kes`. Halt immediately, save current state, jump to the Finalize phase.
-6. **Follow-up questions surface immediately.** If an answer creates a new question ("use a new endpoint" leads to "endpoint name?"), insert a new `Acik / Open` row into Section 20 directly after the current row and process it next, not at queue end.
-7. **Save after every answer.** Each resolution writes the full doc to disk atomically before the next question. Interruption loses nothing.
-8. **Status enum is fixed:** `Acik / Open`, `Girdi bekleniyor / Pending input`, `Karar verildi / Decided` (render the side matching the doc's `language`). Only the Status cell and a trailing `[Cozum: <value> - <source>]` / `[Resolved: <value> - <source>]` fragment on the question cell are edited in Section 20; Owner is never synthesized or changed.
-9. **Sibling propagation is explicit, never silent.** Per-platform sibling files (front-matter `siblings:`) are touched only in the Finalize phase, only for rows whose question text matches verbatim, and only after the user approves one summary question. Platform-specific rows (convention fallbacks, per-platform reuse rows) never propagate.
-10. **`evidence_digest` stays untouched.** Resolving questions does not change the evidence inputs; the front-matter digest and `generated` timestamp are preserved. Only the Section 23 changelog records the revision.
+## Engine
 
-## Input
+The resolution engine - this command's own Locked decisions, the batched repo lookup, the sequential resolution loop and the finalize pass - lives in `$HOME/.claude/multi-agent-refs/analysis/resolve.md`. Pipeline Phase 4 (analysis mode) and Phase 2 (full pipeline) mount the same file, so there is one walk with three entry points.
+
+Inherited decisions: `$HOME/.claude/multi-agent-refs/analysis/locked.md`.
 
+## Input
 - `$ARGUMENTS` - optional doc path. If empty, auto-glob at Phase 0.
 - `--autonomous` - auto-pick the strongest candidate where exactly one source is credible; Defer otherwise. No per-row prompts; final report still printed.
 
@@ -60,59 +49,6 @@ Companion command to `/multi-agent:analysis`. Takes an `analysis/<feature>-<plat
 
 **Echo** one line: `Resolve: <doc> | repo: <path> | mode: <interactive|autonomous>. Parsing Section 20.`
 
-### Phase 1 - Parse and batched repo lookup
-
-1. Read the doc end-to-end. Capture:
-   - Front-matter: `feature`, `platform`, `language`, `mode`, `siblings[]`.
-   - The Risks and Open Questions table: ordered rows `{index, question, owner, status}`.
-   - Context for reasoning: Summary, Goals, API Contracts, Architecture Plan (concept table + footnotes), Files to Add, References.
-2. Filter to rows whose status is `Acik / Open` or `Girdi bekleniyor / Pending input`. If zero remain, report `Section 20 has no open rows.` and stop.
-3. **Classify each row** by its auto-population fingerprint:
-
-   | Class | Fingerprint (from analysis.md auto-population rules) | Extra candidate source |
-   |---|---|---|
-   | `convention-fallback` | row text contains `convention fallback applied` or cites `conventions-defaults.md:C<n>-` (Locked 23) | re-run `~/.claude/lib/extract-conventions.sh <repo> <platform>` for that one field; offer the default vs the fresh extraction |
-   | `reuse-vs-new` | row text matches `existing <X> candidate found; reuse or document why a new one is needed` (Locked 11) | repo lookup reads the candidate `file:line` and summarizes its fit |
-   | `citation-tbd` | row originated from a `[label TBD - see Open Questions]` downgrade (Locked 3) | repo localization keys / Figma evidence already cited elsewhere in the doc |
-   | `legacy-decision` | row phrased `current code does X; should the new feature keep, change, or drop this?` (Locked 4) | repo lookup confirms current behavior with `file:line` |
-   | `standards-conflict` | row cites a binding standards source (Locked 8) | quote the binding section verbatim from References |
-   | `design-gap` | row needs new Figma/design information (tier-3 forced questions, missing variants per Locked 12/19) | NONE - Locked 30; offer only Defer + the re-run recommendation |
-   | `generic` | anything else | all three standard sources |
-
-4. **Batched repo lookup** (single Explore subagent, one call regardless of row count; skip if every row classified `design-gap`):
-   > "For the feature `<feature>` on platform `<platform>`, answer the following questions from the repo at `<repo-root>`. Return one entry per question ID with either an answer plus `file:line` citation OR `not-found`. Scope reading to paths the questions name plus their direct dependencies; do not roam, do not propose changes.
-   > Q1: <row 1 text> ..."
-5. Cache per-question answers keyed by row index. These feed the `From repo` candidate in Phase 2.
-
-### Phase 2 - Sequential resolution loop
-
-For each open row in source order:
-
-1. **Generate candidates** per the row's class (max 3). Skip any source with no credible output. For `design-gap` rows, skip candidate generation entirely.
-2. **Ask** (interactive mode) - single AskUserQuestion:
-   - `header`: the target section anchor, max 12 chars (e.g. `S13 Arch`, `S9 API`, `S10 L10n`, `Conventions`)
-   - `question`: the row text verbatim, prefixed `[R-<index>]` (follows the doc, so it may be Turkish; that is correct here - the row IS the doc content)
-   - `options`: up to 3 candidates + `Defer - keep open`. Candidate descriptions carry the source label per New Locked 2.
-   - Autonomous mode: pick the single credible candidate if exactly one source produced one; otherwise Defer. Log each auto-decision as one line.
-3. **Apply**:
-   - **Concrete answer**: locate the target body section from the row's anchor or content (convention rows target the Architecture Plan concept table; reuse rows target Files to Add + Architecture Plan; API rows target API Contracts; etc.).
-     - `From evidence` / `AI reasoned` / user Other: write as primary content in the doc's `language`, ASCII punctuation, citations preserved.
-     - `From repo` describing current behavior: write as `> Legacy reference: <text> (file:line)` under the target entry (Locked 4). A repo answer that the user adopts as the forward decision is primary content WITH its `file:line` citation.
-     - `convention-fallback`: update the convention cell, rewrite its footnote to `^[user-override: resolved via analysis-resolve <YYYY-MM-DD>]` (Locked 24).
-     - Update the Section 20 row: Status to `Karar verildi / Decided`, append ` [Cozum: <one-line> - <source>]` (tr) / ` [Resolved: <one-line> - <source>]` (en) to the question cell. Do not delete the row; the table stays a decision log.
-   - **Defer**: Status to `Girdi bekleniyor / Pending input`. Row otherwise untouched.
-   - **Stop token**: save, jump to Phase 3.
-   - **Follow-up**: insert the new `Acik / Open` row right after the current one (New Locked 6) and process it next.
-4. **Save the full doc to disk** before the next iteration (New Locked 7).
-
-### Phase 3 - Finalize
-
-1. **Sibling propagation** (only if front-matter `siblings[]` is non-empty AND at least one resolved row's question text appears verbatim with an open status in a sibling file on disk): one AskUserQuestion, `header: "Siblings"`, question `<localized: "N resolved rows also appear open in sibling file(s) <list>. Apply the same resolutions there?">`, options `Apply to all listed` / `Skip siblings`. On apply: repeat the Phase 2 apply step per matching row per sibling, then give each touched sibling its own changelog row. Platform-specific classes (`convention-fallback`, `reuse-vs-new`) are excluded from matching (New Locked 9).
-2. **Changelog**: append one row to the Changelog section of every touched file: next version (integer scheme `v1 -> v2`; dotted scheme bumps the minor), today's date, author `analysis-resolve`, change `Resolved <N> of <M> Section 20 rows; <K> deferred`.
-3. **Punctuation gate**: run the Locked 7 verification grep over every touched file; fix any hit before reporting.
-4. **Report** (in `outputLanguage`, max 12 lines): doc path(s) + new version, counts (resolved / deferred / follow-ups created / still open), `design-gap` rows that need a `/multi-agent:analysis` re-run (list inputs to re-supply), and - if open rows remain - a reminder that re-running this command resumes where it left off (state is the doc itself; no separate state file).
-
-**Stop. No commit, no branch, no dispatch.** The user reviews the diff and commits manually (Locked 6).
 
 ## Reusable refs
 

package/pipeline/commands/multi-agent/channels/SKILL.md

@@ -245,7 +245,7 @@ Emitted only when `reportContent.workSummary === true` and at least one of (`age
 1. **Task header**  -  `taskId`, `branch`, `baseBranch`, `prNumber` from `agent-state.json` (or explicit flags for post-hoc invocation).
 2. **Scope delivered**  -  Phase 2 `planTodos[]` / `tasks[]` rendered as `done` (status=done) or `pending` (anything else) rows. Task id + title shown; `(deferred  -  rationale)` appended if the task's `status` is `"deferred"`.
 3. **Changed files**  -  `git -C $WORKTREE diff --numstat $baseBranch...HEAD`. Shows `` `path` (+add / -del) `` per row, capped at 20 with a `_... +N more files not shown_` footer when exceeded. Total adds/dels + file count in section header.
-4. **Review outcome**  -  from `reviewConsensus` (pre-v6.1) or `phases["4"].triage`: `{accepted} accepted · {deferred} deferred · {rejected} rejected · approved={bool}`. Hidden entirely when all three buckets are empty (normal for `--dev` / `dev-autopilot` runs that skip Phase 4).
+4. **Review outcome**  -  from `reviewConsensus` (pre-v6.1) or `phases["4"].triage`: `{accepted} accepted · {deferred} deferred · {rejected} rejected · approved={bool}`. Hidden entirely when all three buckets are empty (normal for a run that never reached Phase 4).
 5. **Phase tick strip**  -  single line from the tracker state (`render-work-summary.sh` resolves worktree/artifacts copies, then `$HOME/.claude/logs/multi-agent/{taskId}/tracker-state.json`): `0 Init [done] · 1 Analysis [done] · 2 Planning [done] · 3 Dev [done] · 4 Review [done] · 5 Test skipped · 6 Commit [done] · 7 Report active`. Marks: `done` completed · `active` in_progress · `failed` failed · `skipped` skipped · `·` pending.
 
 **Output template:**

package/pipeline/commands/multi-agent/complaint-analysis/SKILL.md

@@ -28,7 +28,7 @@ Triage of customer-reported errors across the layers the team owns (client apps
 10. **Verdict citation discipline.** Every `client`/`bff` verdict cites at least one Graylog message (timestamp + source) AND one repo evidence row (`file:line`). Anything less is `insufficient-evidence`. Every `core` verdict cites the Graylog message that names the upstream service.
 11. **One complaint batch per run.** Mixed batches spanning unrelated products are user error: surface it and ask to split.
 12. **No auto-commit.** The local report is written to the working tree; the user commits it themselves if they want.
-13. **Client/bff verdicts carry a development handoff.** Every `client`/`bff` verdict renders a fix plan grounded in the EXISTING architecture (the `repoEvidence[]` files are the reference: name the concrete files/components to touch, reuse-first, no invented structures) plus a ready-to-run dev prompt (English, one fenced block, `/multi-agent:dev`-compatible). The handoff is part of the report - this command still never runs dev itself (Locked 3). Core and insufficient-evidence verdicts never get a fix plan (Locked 5).
+13. **Client/bff verdicts carry a development handoff.** Every `client`/`bff` verdict renders a fix plan grounded in the EXISTING architecture (the `repoEvidence[]` files are the reference: name the concrete files/components to touch, reuse-first, no invented structures) plus a ready-to-run dev prompt (English, one fenced block, `/multi-agent`-compatible). The handoff is part of the report - this command still never runs dev itself (Locked 3). Core and insufficient-evidence verdicts never get a fix plan (Locked 5).
 
 ## Steps
 
@@ -120,7 +120,7 @@ Verdict shape: `verdict: {category, layer, confidence: high|medium|low, rational
 **Development handoff (client/bff only, Locked 13)**: for each `client`/`bff` verdict, derive from the `repoEvidence[]` rows:
 
 - **Fix plan**: 2-5 numbered steps referencing the existing architecture by `file:line` - which service/view/handler to change, what to reuse (reuse-first: prefer extending the cited components over adding new ones), which tests to add. No speculative rewrites.
-- **Dev prompt**: one fenced English block the user can paste into `/multi-agent:dev` (or a Jira description): complaint summary, root cause, the cited files, the fix plan steps, and the acceptance check. Include the complaint id (`[C-NN]`) for traceability.
+- **Dev prompt**: one fenced English block the user can paste into `/multi-agent` (or a Jira description): complaint summary, root cause, the cited files, the fix plan steps, and the acceptance check. Include the complaint id (`[C-NN]`) for traceability.
 
 Set `phase: "drafting"`.
 
@@ -128,7 +128,7 @@ Set `phase: "drafting"`.
 
 1. Render the report per `$HOME/.claude/multi-agent-refs/complaint-analysis-template.md` (8 fixed sections; single-language body in `outputLanguage`; verdict tokens English per Locked 9) to `/tmp/complaint-analysis-<run-slug>-<UTC-iso8601>/report.md`. Store `outputs.draftDir`.
 2. **Humanizer pass (MANDATORY: actually invoke the `ai-common-toolkit:humanizer` skill; the punctuation grep alone does NOT satisfy this)** with `language: <tr|en>`, `tone: technical-explanatory`, `stripFancyPunctuation: true`. Diacritics preserved (Locked 8).
-3. Punctuation gate: `grep -P '[\x{2013}\x{2014}\x{2026}\x{201C}\x{201D}\x{2018}\x{2019}\x{00A7}]'` over the draft returns zero matches.
+3. Punctuation gate: `node $HOME/.claude/scripts/validate-complaint-doc.mjs <draft>` reports no banned-punctuation error. It checks the policy in Node, so the same result holds on macOS, Linux and Windows; `grep -P` is absent from BSD grep and would never run there.
 4. Show the draft path + size to the user. Set `phase: "awaiting_output_decision"`.
 
 ### Phase 4.5 - Output destination picker
@@ -158,7 +158,7 @@ Follow-ups: Confluence -> ask parent page (Other, LRU recents from `prefs.projec
 
 Then print the summary in `outputLanguage`: complaint count, verdict counts (`X client / Y bff / Z core / W insufficient-evidence`), degraded services, output paths/URLs. When any `core` verdict exists, add: <localized: "N complaint(s) route to the core team - see the routing section before forwarding.">
 
-**Stop. Do not chain into `/multi-agent:dev`. Do not open a worktree. Do not create a branch.** Set `phase: "done"`.
+**Stop. Do not chain into a dev run. Do not open a worktree. Do not create a branch.** Set `phase: "done"`.
 
 ### Resume contract
 
@@ -178,6 +178,7 @@ Then print the summary in `outputLanguage`: complaint count, verdict counts (`X
 | `$HOME/.claude/multi-agent-refs/keychain.md` | Phase 1 non-critical credential handling |
 | `$HOME/.claude/multi-agent-refs/complaint-analysis-template.md` | Phase 4 report template (8 sections) |
 | `ai-common-toolkit:humanizer` | Phase 4 tone pass |
+| `ai-analyst-toolkit:signal-community` | Phase 1 corroboration, optional. Advisory only: a matching report outside the company shows the complaint is not one user's device, and lands in the risks section with its link, never as a root cause. |
 | `$HOME/.claude/scripts/validate-complaint-doc.mjs` | Phase 5 pre-dispatch gate |
 | `$HOME/.claude/multi-agent-refs/channels/confluence.md`, `channels/jira.md`, `~/.claude/lib/md2confluence-v3.py` | Phase 5 dispatch |
 | `$HOME/.claude/schemas/complaint-analysis-spec.schema.json` | State contract |

package/pipeline/commands/multi-agent/dev/SKILL.md

@@ -1,289 +1,17 @@
 ---
-description: "Fast development mode: Init → Dev (Opus) → Review → Test → Commit → Report. Analysis and planning are skipped, review is not. Use when the work is already scoped but the result still has to be checked."
-description-tr: "Hızlı geliştirme modu: Init → Dev (Opus) → Review → Test → Commit → Report. Analiz ve planlama atlanır, review atlanmaz."
+description: "Removed in v16.0.0. Depth is a question the run asks, not a command name: start /multi-agent and answer Short. Invoke only to see that redirect."
+description-tr: "v16.0.0'da kaldırıldı. Pipeline derinliği artık komut adı değil: /multi-agent çalıştırıp derinlik sorusunda Kısa seçin."
 ---
 
-# multi-agent dev  -  Fast Development Mode (--dev)
+# multi-agent dev  -  Removed in v16.0.0
 
-**Input**: $ARGUMENTS
+Until v16.0.0, `--dev` and the four `dev-*` commands existed only to express one boolean: skip Analysis and Planning. That boolean is now a question, asked once at Phase 0 Step 7.5, where the recommendation can come from the detected `taskType`.
 
-> **Language (read FIRST)**: Two language axes, independent:
->
-> 1. **`prefs.global.promptLanguage` is always `en`**  -  instructions to the LLM (this file, every skill spec, every slash-command body, agent system prompts) stay in English. Do not translate spec docs.
-> 2. **`prefs.global.outputLanguage` is user-selectable**  -  applies to (a) every conversational line the agent writes back, and (b) every user-facing external payload: PR description body, Jira comment, Confluence body, Wiki body.
->
-> Regardless of `outputLanguage`, these stay English (interop / convention):
->   - `AskUserQuestion` `label` + `header` only (UI contract)  -  the `question` and each option's `description` follow `outputLanguage`; a picker whose question is English on a Turkish run is a bug, not the contract
->   - Commit message subject/body (git convention)
->   - Branch names (`feature/`, `bugfix/`, ...)
->   - Code identifiers, file paths, log lines
->   - PR title prefix (`feat:`, `fix:`, ...)  -  only the body honors `outputLanguage`
->
-> Full contract: `$HOME/.claude/multi-agent-refs/rules.md` "Language Application".
-
-A 6-phase fast pipeline: Init → Dev → Review → Test → Commit → Report. Development runs on the Opus model (top intelligence tier).
-
-## When to use it
-- Small changes, bug fixes, quick features
-- Simple tasks that don't need the full 8-phase pipeline
-- Work that is already scoped, so analysis and planning buy nothing  -  the result is still reviewed
-
-## Pipeline
-
-```
-Phase 0: Init       → project detection, worktree, branch, identity (full picker)
-Phase 3: Dev        → direct development on Opus (TDD optional)
-Phase 4: Review     → deterministic gates + parallel review + triage
-Phase 5: Test       → User Test (interactive simulator)
-Phase 6: Commit     → commit + push + PR
-Phase 7: Report     → channels (Jira / Confluence / PR / Wiki)
-```
-
-`--dev` skips Phase 1 (Analysis) and Phase 2 (Planning + Approval Gate). Phase 3 Dev runs on **Opus**. Phase 0 picker, Phase 4 review, Phase 5 test, Phase 6 commit, and Phase 7 channels are identical to the full pipeline.
-
-## What `--dev` does NOT skip (required)
-
-`--dev` skips the two phases that front-load a task (Phase 1 Analysis, Phase 2 Planning + Approval) and runs Phase 3 Dev on Opus. Phase 0 (Init), Phase 4 (Review), Phase 5 (Test), Phase 6 (Commit), and Phase 7 (Report + channels) are byte-for-byte the same as the full pipeline. User-facing prompts **always run**  -  they exist for audit, not speed.
-
-**Review is not a fast-mode casualty.** Skipping analysis means the run has less context, not that the output deserves less scrutiny: Phase 4 runs its deterministic gates, dispatches the parallel reviewers and triages their findings exactly as the full pipeline does. Accepted blocking findings loop back to Phase 3, capped at 3 iterations. Because Phase 1 never ran, Phase 4 substitutes a deterministic stack classifier for `detectedStack` and records every Phase-1-dependent step as `not-applicable`, so a step that could not run is distinguishable from a step that passed.
-
-### Required user prompts (Phase 0)
-
-The agent CANNOT make these Phase 0 decisions automatically; it suggests, then waits for confirmation:
-
-1. Issue / Jira ID confirm
-2. **Account picker  -  provider-aware**: First detect the git remote provider via `git remote get-url origin`, then list provider-appropriate accounts. Do not default to `gh auth` when the remote is non-GitHub.
-   - `bitbucket.*` → Bitbucket account (parse user from remote URL: `https://USER:TOKEN@host/...`; if multiple stored tokens in OS keychain, pick from those)
-   - `github.com` → `gh auth status` accounts
-   - `gitlab.*` → GitLab account (similar URL parse / keychain)
-   - Unknown host → list all stored credentials and ask
-   - Show the chosen provider in the picker label (e.g. "Bitbucket account?" not "GitHub account?")
-3. Project root (state inheritance is FORBIDDEN  -  picker runs every run)
-4. dev-context picker (extra repos / submodules  -  read `.gitmodules` and suggest)
-5. **Remote reachability gate (run before branch picker)**: Test remote with
-   `git ls-remote --heads origin <baseBranch>` (5s timeout), capturing **stderr**.
-
-   **Classify the failure before naming a cause.** A non-zero exit is not evidence
-   of a network problem, and telling the user to enable a VPN for an auth failure
-   sends them to fix something that was never broken. Match stderr, in this order:
-
-   | stderr contains | Cause | What to offer |
-   |---|---|---|
-   | `could not read Password`, `Authentication failed`, `terminal prompts disabled`, `Invalid username or password`, `403` | **credential**, not network | the remote URL usually embeds a username with no credential-helper entry. Offer: store the PAT in the credential helper (`git credential approve`, or re-run `/multi-agent:setup`), or switch the remote to SSH. A VPN cannot fix this. |
-   | `Could not resolve host`, `Operation timed out`, `Connection refused`, `Network is unreachable`, or the 5s timeout fired with no output | **network** | the VPN/DNS prompt below |
-   | `Repository not found`, `does not appear to be a git repository`, `404` | **wrong remote** | show `git remote -v` and ask which remote is correct |
-   | anything else | **unknown** | print the stderr line verbatim and ask; never assert a cause you did not observe |
-
-   Outcomes:
-   - **Reachable** → proceed to base branch picker, fetch latest, create worktree
-     from `origin/<baseBranch>`
-   - **Credential / wrong remote** → STOP with the matching remedy above. Do **not**
-     offer "continue from the local ref": the base being stale is unrelated to the
-     actual failure, so accepting staleness here trades correctness for nothing.
-   - **Network** → STOP and ask:
-     ```
-     [N/Total] Remote gate
-       Observed: <the stderr line, verbatim>
-       Classified: <host> unreachable (network).
-       Options:
-         1. Enable VPN and retry (recommended  -  branch will be fresh)
-         2. Continue from local origin/<baseBranch> ref (may be stale)
-         3. Cancel
-       Confirm? [1/2/3]
-     ```
-   - User picks `2` → log warning + record `"baseFetchStatus": "cached-stale"` in
-     `agent-state.json`, proceed from local ref. Phase 6 push needs network anyway,
-     so re-prompt there if still unreachable.
-   - Option `1` (fetch succeeded) records `"fresh"`; a local-branch base records
-     `"local-branch"`; option `3` records `"aborted"`. The field name and this
-     four-value vocabulary are what `phase0-exit-gate.mjs` reads, so a run that writes
-     anything else cannot close Phase 0.
-
-   Always show what was **observed** next to what was **classified**. The previous
-   wording asserted `Detected: <host> unreachable (VPN/DNS)` for every failure mode,
-   including a plain missing-credential error that returns in under a second.
-6. Base branch picker (show recents, take an explicit pick)
-7. Branch name (suggest, allow edit)
-8. Maturity flags acknowledge (read from the issue body's Progress table)
-
-### STOP-AND-CONFIRM format
-
-For each decision:
-
-```
-[N/Total] <Decision name>
-  Detected: <suggestion> [+ reason]
-  Recent: <last N values used, if any>
-  Alternatives: <other options, if any>
-
-  Confirm? [y/<number>/other/cancel]
-→ <waiting for user input  -  agent stays SILENT>
-```
-
-**Rules:**
-- Confirmation is required even when there is only one option
-- Empty Enter ≠ confirmation; require an explicit answer (`y`, `yes`, `1`, ...)
-- State inheritance is FORBIDDEN  -  the previous `agent-state.json` of the same task ID is not a template
-- Cancel always halts
-- One prompt per decision  -  bundling is FORBIDDEN
-
-### Required commit / report prompts
-
-- Phase 6 → "Check out locally to test? 1 = Yes (WIP) / 2 = No (continue)" (default 2)
-- Phase 6 → When pushing directly to a shared branch (`iteration/develop`, `develop`, `main`), a final confirm via a native `AskUserQuestion` picker (never a typed y/n): `question` "This pushes to iteration/develop with no CI gate. Push anyway?" (rendered in `outputLanguage`); `header` "Push" (English, <=12 chars); `options`: `{ label: "Push", description: "Push directly to the shared branch with no CI gate" }`, `{ label: "Cancel", description: "Do not push; stop here" }`. Anything other than **Push** cancels.
-- Phase 7 → Channels prompt: Jira comment / Confluence / PR description / (optional) Wiki  -  multi-select
-
-### Phase 6: PR creation contract
-
-When opening a PR, the agent must:
-
-1. **Always add default reviewers**: GET the host's default-reviewers endpoint (Bitbucket Server: `/rest/default-reviewers/1.0/projects/{projectKey}/repos/{repoSlug}/reviewers?sourceRepoId=...&targetRepoId=...&sourceRefId=...&targetRefId=...`; GitHub: `CODEOWNERS` / branch protection required reviewers). Exclude the author from the list. Attach via the create-PR payload's `reviewers` array (Bitbucket Server) or via the `review_requests` API (GitHub) at creation time.
-2. **Never wipe reviewers on update**: Bitbucket Server `PUT /pull-requests/{id}` REPLACES the entire resource. If the payload omits `reviewers`, the field is cleared. Two safe patterns:
-   - **Preferred**: do not PUT-update; pre-render the final description so the create-PR call is one-shot.
-   - **If you must PUT**: re-fetch the current PR, copy the existing `reviewers` array into the PUT payload along with `version` + the field you're changing.
-   - **Or use sub-resource endpoints**: `POST /pull-requests/{id}/participants` (Bitbucket) adds individual reviewers without touching the rest.
-3. **Verify after every PR write**: re-fetch the PR and assert `len(reviewers) >= len(defaultReviewers) - 1` (minus author). If it dropped, re-add via the participants endpoint immediately.
-4. **PR description language**: render in `prefs.global.outputLanguage`. Required sections  -  Summary, Changed Files, Behavior / Flow, Test Plan, Build Verification (or their localized equivalents). Match the Jira comment structure for cross-channel consistency.
-
-### Build "pre-existing" claim rule
-
-Before reporting a build failure as "pre-existing, not my problem", reproduce it on the baseline:
-
-1. `git stash push -u -m "wip-baseline-check"` (stash local changes)
-2. `git checkout <baseline-sha>` (one commit before any of yours)
-3. Run the same build command  -  does the failure repeat?
-4. If it repeats: pre-existing is confirmed, report it as such
-5. If it does not repeat: the bug is YOURS  -  return and fix it
-6. `git checkout -` and `git stash pop`
-
-No "pre-existing" claim is allowed without a baseline reproduce.
-
-## Skipped phases (definitive list)
-
-- Phase 1 (Analysis → Opus deep-think + explore agents)
-- Phase 2 → Plan Approval Gate including clarification + approval
-
-That is the whole list. Phase 0 (Init full picker), Phase 4 (Review), Phase 5 (User Test), Phase 6 (Commit), and Phase 7 (Report + channels) run exactly as in the full pipeline. Phase 3 Dev model is **Opus**.
-
-## Steps
-
-1. **Parse input**  -  same multi-agent input formats (GitHub Issue URL, Jira ID, free-text)
-
-2. **Phase 0: Init**  -  same as the full pipeline (full picker: account, project, dev-context, base branch, branch name, maturity check, identity, worktree, state)
-   - Add `"mode": "dev"` to `agent-state.json`
-
-3. **Phase 3: Dev**  -  on the **Opus model**, with `taskType`-based dispatch:
-
-   **3a. If `state.taskType === "component"` (figma URL detected at Phase 0 Step 7):**
-   - Run the **full figma 17-substep orchestrator**  -  the same one the full pipeline uses. `--dev` does NOT shrink this. Sub-phases:
-     ```
-     3.0-Init → 3.1-Gather → 3.2A-TestingIDs → 3.2B-Localization → 3.2C-Accessibility → 3.2D-Analytics
-     → 3.3-TokenMapping → 3.4A-Configuration → 3.4B-View → 3.4C-Docs → 3.4D-Preview → 3.4E-Modifiers
-     → 3.5A-Structural (ViewInspector) → 3.5B-Snapshot → 3.5C-Unit
-     → 3.6-CodeConnect → 3.7-Wiki → 3.8-Cleanup
-     ```
-   - **Tests are mandatory** (3.5A + 3.5B + 3.5C). The "tests optional in dev mode" exception below applies to non-component tasks only.
-   - Code Connect publish (3.6) is mandatory if `figmaConfig.codeConnect.enabled` (default true).
-   - Wiki page generation (3.7) is mandatory if `figmaConfig.wiki.enabled`.
-
-   **3b. Else (free-text task, bug fix, refactor, generic feature):**
-   - Brief analysis (no explore agent  -  read files directly)
-   - Write code + verify build
-   - Write tests if needed (not mandatory in dev mode for non-component work)
-
-   The dispatch is keyed on `agent-state.taskType`, written by Phase 0 Step 7 (`feedback_phase0_tasktype.md`). If the issue body contains a Figma URL, the type is `"component"` and 3a applies  -  no exception, even in `--dev`.
-
-4. **Phase 4: Review**  -  same as the full pipeline, per `$HOME/.claude/multi-agent-refs/phases/phase-4-review.md`: deterministic gates (build / lint / test / secrets / evidence), the parallel reviewer set (CLI-aware), and triage. Accepted blocking findings return to step 3 for rework, capped at 3 iterations per `operations.md`. Phase-1-dependent steps (1.8 Figma evidence, 2.8 visual conformance) are recorded as `not-applicable (no Phase 1 evidence)` rather than skipped silently.
-
-5. **Phase 5: User Test**  -  same as the full pipeline (interactive simulator / local-test prompt)
-
-6. **Phase 6: Commit**  -  same as the full pipeline (commit + push + PR + shared-branch final confirm). Phase 6 refuses to commit while an accepted blocking finding is unresolved.
-
-7. **Phase 7: Report**  -  same as the full pipeline (channels prompt: Jira / Confluence / PR description / Wiki)
-
-## Differences vs full pipeline
-
-| Aspect | Full (`/multi-agent`) | Dev (`/multi-agent:dev`) |
-|---------|---------------------|------------------------|
-| Phases | 8 (0-7) | 6 (0, 3, 4, 5, 6, 7)  -  1, 2 skipped |
-| Phase 3 Dev model | Sonnet | **Opus** |
-| Phase 1 Analysis (explore agents) | ✅ | ❌ |
-| Phase 2 Planning + Approval Gate | ✅ | ❌ |
-| Phase 4 Review (parallel + triage) | ✅ | ✅ (same) |
-| Phase 4 criteria source | Phase 1 `detectedStack` | deterministic stack classifier |
-| Phase 0 picker (account, repos, branch, ...) | ✅ | ✅ (same) |
-| Phase 5 User Test | ✅ | ✅ (same) |
-| Phase 7 channels (Jira / Confluence / PR / Wiki) | ✅ | ✅ (same) |
-| Duration | ~10-15 min | ~7-10 min |
-## Intake warnings (`--dev` family)
-
-Two checks belong at the top of every `--dev` run and are specified once in `$HOME/.claude/multi-agent-refs/phases/modes.md` "Intake warnings shared by the whole `--dev` family": an analysis document supplied to a mode that skips Analysis and Planning, and a branch that already carries the work (which wants `/multi-agent:resume-local`, not a second Dev pass). Read that section rather than reasoning about it from scratch.
-
-## Required: outward-facing payload contracts
-
-Before writing anything outward-facing  -  PR body, Jira comment, Confluence page, closing report  -  load `$HOME/.claude/multi-agent-refs/payload-contracts.md`. It names the canonical section set for each payload, the markup dialect per surface (PR body is Markdown, Jira is wiki markup  -  mixing them is a defect), and the token/duration numbers the closing report must carry. Improvising a payload shape from memory is the most common failure of the short modes.
-
-## Required: Phase Tracker Contract
-
-**The phase tracker is mandatory**  -  the agent cannot skip it. Full spec: [`$HOME/.claude/multi-agent-refs/tracker-contract.md`]($HOME/.claude/multi-agent-refs/tracker-contract.md).
-
-Two channels run in parallel at every phase boundary:
-
-1. **State channel** (every CLI, identical): `phase-tracker.sh` writes to `tracker-state.json`. Drives `:resume`, `:log`, `:status`.
-2. **Visual channel** (CLI-specific): native widget on Claude Code, ANSI render on every other CLI. Without it the user sees no phase progress.
-
-```bash
-# Phase 0, very first shell call (every CLI):
-bash $HOME/.claude/scripts/phase-tracker.sh init "$TASK_ID"
-for p in "0:Init" "3:Dev" "4:Review" "5:Test" "6:Commit" "7:Report"; do
-  bash $HOME/.claude/scripts/phase-tracker.sh add "${p%%:*}" "${p#*:}"
-done
-bash $HOME/.claude/scripts/phase-tracker.sh update 0 in_progress
-
-# Every phase boundary (every CLI):
-bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress|completed|failed|skipped
-
-# After every LLM call (every CLI):
-bash $HOME/.claude/scripts/phase-tracker.sh tokens <N> <in> <out> [cached]
 ```
-
-### Visual channel  -  Claude Code (native TaskList widget, required)
-
-In Claude Code the agent MUST also drive the native TaskList widget so the user sees a sticky phase tile stack  -  this is the only progress signal Claude Code surfaces. Skipping these calls is the #1 source of "I don't see any phases" complaints.
-
-**TaskCreate ordering (strict)**: All TaskCreate calls 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 ✓ · 2 ✓ · 4 ✓ · 0 ▶ · 3 ☐`) even when the underlying state is correct. Pre-marking phases as completed/skipped before Phase 0 starts is FORBIDDEN  -  register the tile in order, 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)".
-
-```text
-# Phase 0 startup  -  register one tile per phase (0..N), capture the taskId, persist it:
-for each phase in 0:Init, 3:Dev, 4:Review, 5:Test, 6:Commit, 7:Report:
-  TaskCreate({ subject: "Phase <N>: <Name>", activeForm: "<doing-form>" })
-    -> returns taskId
-  bash $HOME/.claude/scripts/phase-tracker.sh meta <N> tasklist_id "<taskId>"
-
-# Phase entry  -  flip the tile to in_progress alongside the state update:
-TaskUpdate({ taskId: <saved>, status: "in_progress" })
-bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress
-
-# Active sub-step inside a phase  -  update activeForm so the spinner header reflects what's happening now:
-TaskUpdate({ taskId: <saved>, activeForm: "Editing TopBarView.swift" })
-
-# Phase exit  -  flip to completed/failed/skipped on both channels:
-TaskUpdate({ taskId: <saved>, status: "completed" })
-bash $HOME/.claude/scripts/phase-tracker.sh update <N> completed
+/multi-agent:dev has been removed. Run /multi-agent and choose Short at the
+depth question - same pipeline, one picker step earlier.
 ```
 
-`--dev` mode does NOT TaskCreate phases 1/2  -  those are not part of the `--dev` phase set (`0:Init 3:Dev 4:Review 5:Test 6:Commit 7:Report`). Only register tiles for the active set.
-
-#### TaskCreate ordering (strict)
-
-**All TaskCreate calls fire in strict phase-number order BEFORE any TaskUpdate is applied.** For `--dev` that means: Phase 0 → Phase 3 → Phase 4 → Phase 5 → Phase 6 → Phase 7. The native widget renders by creation order, not by phase number  -  out-of-order calls produce visually scrambled tile stacks. Full ordering contract in `$HOME/.claude/multi-agent-refs/tracker-contract.md` section "TaskCreate ordering (strict)".
-
-### Visual channel  -  Copilot CLI / plain shell
-
-These CLIs have no TaskList widget. After every state change the agent calls render, which prints a bordered ANSI card as the last tool result so the user sees an updated phase table:
-
-```bash
-bash $HOME/.claude/scripts/phase-tracker.sh render
-```
+Print the line above, then continue at the named entry with the same `$ARGUMENTS`. Do not run any phase from this file: it carries no tracker contract and no phase set.
 
-Do NOT call TaskCreate on these CLIs  -  the tool does not exist and the call fails.
+This stub exists so the old name fails loudly and usefully for one minor release instead of silently doing nothing. It is deleted in the next one.

package/pipeline/commands/multi-agent/dev-autopilot/SKILL.md

@@ -1,135 +1,23 @@
 ---
-description: "Fastest mode: Dev (Opus) plus Autopilot. Init → Dev → Review → Commit → Report with zero confirmations. Review still runs and auto-fixes blocking findings. Use when a change is well understood and should go from start to commit with no questions asked."
-description-tr: "En hızlı mod: Dev (Opus) + Autopilot. Init → Dev → Review → Commit → Report, sıfır onay. Review koşar, blocking bulguları otomatik düzeltir."
+description: "Removed in v16.0.0 and not replaced: an unsupervised run is always the full pipeline now. Invoke only to be pointed at /multi-agent:autopilot or the interactive picker."
+description-tr: "v16.0.0'da kaldırıldı, birebir karşılığı yok: gözetimsiz koşular artık her zaman tam pipeline. /multi-agent:autopilot veya /multi-agent'a yönlendirir."
 ---
 
-# multi-agent dev autopilot  -  Fastest Path
+# multi-agent dev-autopilot  -  Removed in v16.0.0
 
-**Input**: $ARGUMENTS
+This one has no equivalent, and the removal is deliberate rather than a rename.
 
-> **Language (read FIRST)**: Before any status output, read `prefs.global.outputLanguage` and render every conversational line in it. `AskUserQuestion` `label`/`header` stay English, but its `question` and option `description`s render in `outputLanguage`; external payload bodies follow `outputLanguage` too (identifiers, commit messages, branch names stay English). Full contract: `$HOME/.claude/multi-agent-refs/rules.md` "Language Application".
-
-Dev mode + Autopilot combined: a 4-phase pipeline with no confirmations, end-to-end autonomous.
-
-## When to use it
-- Small, trusted, urgent changes
-- Bug fixes, copy updates, config tweaks
-- "Just do it, commit, open the PR" scenarios
-
-## Pipeline
+Depth is a question now, and autopilot may not ask questions. That leaves one choice to make on the user's behalf, and Full is the honest default: skipping analysis and planning in a run nobody is watching is where a wrong shortcut costs the most, because there is no one there to notice what it lost.
 
 ```
-Phase 0: Init       → project detection, worktree, branch, identity
-Phase 3: Dev        → direct development on Opus
-Phase 4: Review     → gates + parallel review + triage, auto-fix
-Phase 6: Commit     → auto commit + push + PR (no confirmations)
-Phase 7: Report     → short terminal summary
+/multi-agent:dev-autopilot has been removed. "Fast plus unattended" no longer
+exists as a combination.
+  1. /multi-agent:autopilot  - unattended, full pipeline (slower, more tokens)
+  2. /multi-agent            - short pipeline, but asks the depth question
 ```
 
-**Skipped phases**: Analysis (1), Planning (2), User Test (5).
-**Skipped confirmations**: Plan Approval Gate (clarification + approval loop), test prompt, commit prompt, PR prompt.
-
-> If you want to talk through the plan, do not use this mode  -  pick `/multi-agent "task"` (normal) or any mode without `autopilot`. The Dev+Autopilot contract is: "ask nothing."
-
-**Review runs here too, and asking nothing does not mean accepting anything.** Autopilot consumes the *confirmation* prompts, not the *quality* gates: Phase 4 reviews the diff and auto-fixes accepted blocking findings without asking. The contract holds because no question is put to the user  -  the run only halts when it cannot converge, which is the rework-storm trigger in `$HOME/.claude/multi-agent-refs/features/autopilot-circuit-breaker.md` (`maxReworkCycles = 3`).
-
-## Steps
-
-1. **Parse input**  -  standard multi-agent input formats (Issue URL, Jira ID, free text)
-2. **Phase 0: Init**  -  set `"mode": "dev", "autopilot": true` in `agent-state.json`
-3. **Phase 3: Dev**  -  write code directly on `claude-opus-5` and verify the build
-4. **Phase 4: Review**  -  gates, parallel reviewers, triage. Accepted blocking findings are fixed automatically (back to step 3), no prompt
-5. **Phase 6: Commit**  -  auto commit + push + PR
-6. **Phase 7: Report**  -  terminal summary
-
-## Safety
-
-- Build failure → 3 retries; if it still fails → **pause** (ask the user)
-- Review rework → 3 cycles; if blocking findings survive → **pause** (circuit breaker, no auto-commit)
-- Kill / Purge → always asks for confirmation (destructive)
-
-## Differences
-
-| | Full | Dev | Autopilot | **Dev+Autopilot** |
-|--|------|-----|-----------|-------------------|
-| Phases | 8 | 6 | 8 | **5** |
-| Model | Sonnet | Opus | Sonnet | **Opus** |
-| Plan Approval Gate | ✅ (clarification + approval) | ❌ | ❌ | **❌** |
-| Confirmations (test / commit / PR) | Yes | Yes | No | **No** |
-| Review | Parallel + triage (CLI-aware) | Parallel + triage (CLI-aware) | Parallel + triage (CLI-aware) | **Parallel + triage, auto-fix** |
-| Blocking finding | Fix loop, then ask | Fix loop, then ask | Auto-fix, breaker at 3 | **Auto-fix, breaker at 3** |
-| Estimated duration | ~12 min | ~7 min | ~10 min | **~5 min** |
-## Intake warnings (`--dev` family)
-
-Two checks belong at the top of every `--dev` run and are specified once in `$HOME/.claude/multi-agent-refs/phases/modes.md` "Intake warnings shared by the whole `--dev` family": an analysis document supplied to a mode that skips Analysis and Planning, and a branch that already carries the work (which wants `/multi-agent:resume-local`, not a second Dev pass). Read that section rather than reasoning about it from scratch.
-
-## Required: outward-facing payload contracts
-
-Before writing anything outward-facing  -  PR body, Jira comment, Confluence page, closing report  -  load `$HOME/.claude/multi-agent-refs/payload-contracts.md`. It names the canonical section set for each payload, the markup dialect per surface (PR body is Markdown, Jira is wiki markup  -  mixing them is a defect), and the token/duration numbers the closing report must carry. Improvising a payload shape from memory is the most common failure of the short modes.
-
-## Required: Phase Tracker Contract
-
-**The phase tracker is mandatory**  -  the agent cannot skip it. Full spec: [`$HOME/.claude/multi-agent-refs/tracker-contract.md`]($HOME/.claude/multi-agent-refs/tracker-contract.md).
-
-> **Autopilot mode:** user confirmations are skipped. The tracker is still mandatory  -  autopilot agent calls cannot skip it; skipping breaks `smoke-tracker-contract.sh`.
-
-Two channels run in parallel at every phase boundary:
-
-1. **State channel** (every CLI, identical): `phase-tracker.sh` writes to `tracker-state.json`. Drives `:resume`, `:log`, `:status`.
-2. **Visual channel** (CLI-specific): native widget on Claude Code, ANSI render on every other CLI. Without it the user sees no phase progress.
+If a cron job or script calls this name it needs editing, and the two options trade differently: option 1 stays unattended and will take longer and cost more per run, option 2 stays fast and needs a person.
 
-```bash
-# Phase 0, very first shell call (every CLI):
-bash $HOME/.claude/scripts/phase-tracker.sh init "$TASK_ID"
-for p in "0:Init" "3:Dev" "4:Review" "6:Commit" "7:Report"; do
-  bash $HOME/.claude/scripts/phase-tracker.sh add "${p%%:*}" "${p#*:}"
-done
-bash $HOME/.claude/scripts/phase-tracker.sh update 0 in_progress
-
-# Every phase boundary (every CLI):
-bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress|completed|failed|skipped
-
-# After every LLM call (every CLI):
-bash $HOME/.claude/scripts/phase-tracker.sh tokens <N> <in> <out> [cached]
-```
-
-### Visual channel  -  Claude Code (native TaskList widget, required)
-
-In Claude Code the agent MUST also drive the native TaskList widget so the user sees a sticky phase tile stack  -  this is the only progress signal Claude Code surfaces. Skipping these calls is the #1 source of "I don't see any phases" complaints.
-
-**TaskCreate ordering (strict)**: All TaskCreate calls 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 ✓ · 2 ✓ · 4 ✓ · 0 ▶ · 3 ☐`) even when the underlying state is correct. Pre-marking phases as completed/skipped before Phase 0 starts is FORBIDDEN  -  register the tile in order, 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)".
-
-```text
-# Phase 0 startup  -  register one tile per phase (0..N), capture the taskId, persist it:
-for each phase in 0:Init, 3:Dev, 4:Review, 6:Commit, 7:Report:
-  TaskCreate({ subject: "Phase <N>: <Name>", activeForm: "<doing-form>" })
-    -> returns taskId
-  bash $HOME/.claude/scripts/phase-tracker.sh meta <N> tasklist_id "<taskId>"
-
-# Phase entry  -  flip the tile to in_progress alongside the state update:
-TaskUpdate({ taskId: <saved>, status: "in_progress" })
-bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress
-
-# Active sub-step inside a phase  -  update activeForm so the spinner header reflects what's happening now:
-TaskUpdate({ taskId: <saved>, activeForm: "Editing TopBarView.swift" })
-
-# Phase exit  -  flip to completed/failed/skipped on both channels:
-TaskUpdate({ taskId: <saved>, status: "completed" })
-bash $HOME/.claude/scripts/phase-tracker.sh update <N> completed
-```
-
-`--dev autopilot` mode does NOT TaskCreate phases 1/2/5  -  those are not part of the `--dev autopilot` phase set (`0:Init 3:Dev 4:Review 6:Commit 7:Report`). Only register tiles for the active set.
-
-#### TaskCreate ordering (strict)
-
-**All TaskCreate calls fire in strict phase-number order BEFORE any TaskUpdate is applied.** For `--dev autopilot` that means: Phase 0 → Phase 3 → Phase 4 → Phase 6 → Phase 7. The native widget renders by creation order, not by phase number  -  out-of-order calls produce visually scrambled tile stacks. Full ordering contract in `$HOME/.claude/multi-agent-refs/tracker-contract.md` section "TaskCreate ordering (strict)".
-
-### Visual channel  -  Copilot CLI / plain shell
-
-These CLIs have no TaskList widget. After every state change the agent calls render, which prints a bordered ANSI card as the last tool result so the user sees an updated phase table:
-
-```bash
-bash $HOME/.claude/scripts/phase-tracker.sh render
-```
+Print the block above and stop. Do not pick an entry on the user's behalf: the two options differ in what gets skipped and who is watching, and that is their call. Autopilot passed to this stub still stops here - a zero-interaction contract does not authorise choosing a different pipeline than the one that was asked for.
 
-Do NOT call TaskCreate on these CLIs  -  the tool does not exist and the call fails.
+This stub exists so the old name fails loudly and usefully for one minor release instead of silently doing nothing. It is deleted in the next one.