@mmerterden/multi-agent-pipeline 8.6.1 → 10.0.6

package/pipeline/commands/multi-agent/refs/knowledge.md

@@ -7,10 +7,10 @@ An incrementally growing knowledge system for each project, enabling knowledge t
 ```
 $HOME/.claude/knowledge/
   my-app/
-    architecture.md    — module map, file relationships, dependency graph
-    patterns.md        — naming, conventions, recurring structures
-    gotchas.md         — build errors, edge cases, workarounds
-    decisions.md       — architectural decisions and rationale (ADR-lite)
+    architecture.md     -  module map, file relationships, dependency graph
+    patterns.md         -  naming, conventions, recurring structures
+    gotchas.md          -  build errors, edge cases, workarounds
+    decisions.md        -  architectural decisions and rationale (ADR-lite)
   another-project/
     architecture.md
     patterns.md
@@ -39,7 +39,7 @@ Each task teaches the project a bit more. Token cost decreases over time.
 | Auto Memory (`~/.claude/projects/`)         | Claude (automatic)    | User preferences, feedback                 | Persistent (global)      |
 | **Knowledge Base** (`~/.claude/knowledge/`) | Multi-agent (Phase 7) | Architecture, patterns, gotchas, decisions | Persistent (per-project) |
 
-They all complement each other — no conflicts.
+They all complement each other  -  no conflicts.
 
 ### Knowledge in --dev Mode
 
@@ -53,11 +53,11 @@ In `--dev` mode Phase 1 is skipped but knowledge **is still read**:
 Knowledge files grow over time. Maintenance rules:
 
 - Every entry has a `<!-- captured: {date}, task: {id} -->` tag
-- 90-day-old entries are considered "stale" — not used without verification
+- 90-day-old entries are considered "stale"  -  not used without verification
 - Stale check: orchestrator checks file mtime during Phase 1 knowledge injection
-- Stale entries are added to the prompt with a "STALE — verify before relying" tag
-- `clear-logs` does not touch knowledge — only deletes logs and state
-- `purge` does not touch knowledge either — separate command: `/multi-agent clear-knowledge {project}`
+- Stale entries are added to the prompt with a "STALE  -  verify before relying" tag
+- `clear-logs` does not touch knowledge  -  only deletes logs and state
+- `purge` does not touch knowledge either  -  separate command: `/multi-agent clear-knowledge {project}`
 
 ---
 

package/pipeline/commands/multi-agent/refs/multi-repo-integration-build.md

@@ -1,6 +1,6 @@
-# Multi-Repo Integration Build — Learn Once, Auto-Apply
+# Multi-Repo Integration Build  -  Learn Once, Auto-Apply
 
-> **TLDR** — When a task touches ≥2 repos that have a producer→consumer dependency (e.g. shared codegen library + consuming UI library), the pipeline MUST build the **host project** that integrates them before commit/PR. Codegen mismatches (nested vs flat keys, missing entries, overwritten files) only surface when the full dependency chain builds together. Building repos in isolation gives false confidence.
+> **TLDR**  -  When a task touches ≥2 repos that have a producer→consumer dependency (e.g. shared codegen library + consuming UI library), the pipeline MUST build the **host project** that integrates them before commit/PR. Codegen mismatches (nested vs flat keys, missing entries, overwritten files) only surface when the full dependency chain builds together. Building repos in isolation gives false confidence.
 >
 > The pipeline **learns** the host per repo-combo once, persists to `prefs.global.multiRepoIntegrationHosts`, and auto-applies on subsequent runs.
 
@@ -21,7 +21,7 @@ In Phase 6 (Commit & PR), **before** the pre-commit local checkout prompt, if `s
 3. Match found → **auto-run** the learned build (steps below).
 4. No match → **learn-once prompt** (below), then run.
 
-Single-repo tasks skip this step entirely — no prompt, no overhead.
+Single-repo tasks skip this step entirely  -  no prompt, no overhead.
 
 ---
 
@@ -32,14 +32,14 @@ This task touched N repos: <name>, <name>, <name>
 Do any of these need a host project (submodule consumer) built together
 to verify codegen / interface integration?
 
-  [1] Yes — register host project now (will auto-run on future runs)
-  [2] No  — this combo is independent (save as "no host" so we don't re-ask)
+  [1] Yes  -  register host project now (will auto-run on future runs)
+  [2] No   -  this combo is independent (save as "no host" so we don't re-ask)
   [3] Skip this run only (no learning)
 
 Select [1-3]:
 ```
 
-**On [1]** — ask follow-ups:
+**On [1]**  -  ask follow-ups:
 
 ```
 Host project path (absolute): _______________________
@@ -75,13 +75,13 @@ Persist to `prefs.global.multiRepoIntegrationHosts[]`:
 }
 ```
 
-**On [2]** — persist a negative entry so the combo never re-asks:
+**On [2]**  -  persist a negative entry so the combo never re-asks:
 
 ```json
 { "repoSet": ["<repo-a>", "<repo-b>"], "noHost": true, "lastUsed": "..." }
 ```
 
-**On [3]** — no write, re-ask next time.
+**On [3]**  -  no write, re-ask next time.
 
 ---
 
@@ -114,11 +114,11 @@ BUILD_ERRORS=$(eval "$BUILD_CMD" 2>&1 | grep -E "error:|FAILURE:|error FS" || tr
 # 4. Evaluate + decide
 if [ -z "$BUILD_ERRORS" ]; then
   phase-tracker.sh sub 6 0 "Integration build" completed
-  log "Phase 6.0: Integration build — clean"
+  log "Phase 6.0: Integration build  -  clean"
   # proceed to pre-commit checkout prompt + commit
 else
   phase-tracker.sh sub 6 0 "Integration build" failed
-  log "Phase 6.0: Integration build — NEW errors detected"
+  log "Phase 6.0: Integration build  -  NEW errors detected"
   # show errors, ask user
 fi
 ```
@@ -138,8 +138,8 @@ Three outcomes after the build:
    Phase 3 to fix, or you can fix manually and tell the pipeline to retry.
 
    [1] Return to Phase 3: Dev with these errors as input (auto-fix attempt)
-   [2] Pause — I'll fix manually, then /multi-agent resume
-   [3] Override — proceed to commit anyway (logs a warning in Phase 7 report)
+   [2] Pause  -  I'll fix manually, then /multi-agent resume
+   [3] Override  -  proceed to commit anyway (logs a warning in Phase 7 report)
 
    Select [1-3]:
    ```
@@ -149,9 +149,9 @@ Three outcomes after the build:
 
 ## Autopilot behavior
 
-Autopilot skips the "Override / pause" prompt. If `count` < 3 on this combo (new / low-confidence), autopilot treats a build failure as BLOCKING and returns to Phase 3 automatically (option 1). If `count >= 3` and `lastResult == success`, a new failure is treated as blocking the same way — but with lower surprise since we've seen this combo succeed before.
+Autopilot skips the "Override / pause" prompt. If `count` < 3 on this combo (new / low-confidence), autopilot treats a build failure as BLOCKING and returns to Phase 3 automatically (option 1). If `count >= 3` and `lastResult == success`, a new failure is treated as blocking the same way  -  but with lower surprise since we've seen this combo succeed before.
 
-The learn-once prompt itself also skips under autopilot: instead, autopilot logs `"Phase 6.0: SKIPPED — no learned host for this combo, autopilot refuses to prompt. Run in normal mode once to teach."` and proceeds. This is explicit and recoverable.
+The learn-once prompt itself also skips under autopilot: instead, autopilot logs `"Phase 6.0: SKIPPED  -  no learned host for this combo, autopilot refuses to prompt. Run in normal mode once to teach."` and proceeds. This is explicit and recoverable.
 
 ---
 
@@ -161,13 +161,13 @@ When a learn-once prompt writes a new entry, Phase 7 Step 5 (knowledge + memory)
 
 ```
 Type: reference
-Name: multi-repo integration host — {combo}
+Name: multi-repo integration host  -  {combo}
 Body: For tasks touching {repoA} + {repoB}, the integration build runs in {hostPath} via
       scheme {hostScheme}. Established {date}. Full config lives in
       prefs.global.multiRepoIntegrationHosts.
 ```
 
-Memories that reference integration hosts NEVER get auto-pruned — even if a combo goes many runs without firing, the knowledge is stable and worth keeping indexed for future teammates.
+Memories that reference integration hosts NEVER get auto-pruned  -  even if a combo goes many runs without firing, the knowledge is stable and worth keeping indexed for future teammates.
 
 ---
 
@@ -175,7 +175,7 @@ Memories that reference integration hosts NEVER get auto-pruned — even if a co
 
 > **Post-Development Integration Build (Multi-Repo)**
 >
-> When a task touches multiple repositories that have a producer→consumer dependency (e.g. shared library + consuming component library), the pipeline MUST build the **consumer/host project** after all changes are complete — before commit/PR.
+> When a task touches multiple repositories that have a producer→consumer dependency (e.g. shared library + consuming component library), the pipeline MUST build the **consumer/host project** after all changes are complete  -  before commit/PR.
 >
 > **When this applies:**
 > - Code generation outputs (identifiers, localization keys, tokens) in Repo A are referenced by source code in Repo B
@@ -183,7 +183,7 @@ Memories that reference integration hosts NEVER get auto-pruned — even if a co
 > - Changes in Repo A or B can silently break Repo C if key structures diverge (e.g. nested enum vs flat access pattern)
 >
 > **Required steps (after dev, before commit):**
-> 1. Identify the host project — the project that integrates all touched repos as submodules or package dependencies. Check `prefs.global.multiRepoIntegrationHosts` first; ask the user once if unknown.
+> 1. Identify the host project  -  the project that integrates all touched repos as submodules or package dependencies. Check `prefs.global.multiRepoIntegrationHosts` first; ask the user once if unknown.
 > 2. Update submodules to point at the latest feature branch / merged commit.
 > 3. Resolve package dependencies (flush stale SPM/Gradle/CocoaPods cache).
 > 4. Build the host project's relevant scheme / target.
@@ -195,7 +195,7 @@ Memories that reference integration hosts NEVER get auto-pruned — even if a co
 
 ## Schema
 
-`prefs.schema.json` adds `global.multiRepoIntegrationHosts` — see `pipeline/schemas/prefs.schema.json` for the authoritative definition. Required fields: `repoSet` (array ≥2), one of `(hostPath + platform)` OR `(noHost: true)`. Optional: `hostScheme`, `submodulePaths`, `resolveCommand`, `buildCommand`, `lastUsed`, `count`, `lastResult`.
+`prefs.schema.json` adds `global.multiRepoIntegrationHosts`  -  see `pipeline/schemas/prefs.schema.json` for the authoritative definition. Required fields: `repoSet` (array ≥2), one of `(hostPath + platform)` OR `(noHost: true)`. Optional: `hostScheme`, `submodulePaths`, `resolveCommand`, `buildCommand`, `lastUsed`, `count`, `lastResult`.
 
 ## Smoke coverage
 

package/pipeline/commands/multi-agent/refs/phases/log-format.md

@@ -1,11 +1,11 @@
 ## Log File Format (Detailed)
 
-> **TLDR** — Canonical shape of `agent-log.md`: header block (task id, branch, status), Timeline table (phase by phase), Agent Activity Report (calls + duration per agent), ASCII phase-duration distribution, Review Iterations, Files Changed (`git diff --stat`), Review Consensus, Cost Breakdown, and Test Scenarios. Every pipeline run must produce this file at the global log path.
+> **TLDR**  -  Canonical shape of `agent-log.md`: header block (task id, branch, status), Timeline table (phase by phase), Agent Activity Report (calls + duration per agent), ASCII phase-duration distribution, Review Iterations, Files Changed (`git diff --stat`), Review Consensus, Cost Breakdown, and Test Scenarios. Every pipeline run must produce this file at the global log path.
 
 Create at `$HOME/.claude/logs/multi-agent/{project}/{task-id}/agent-log.md`:
 
 ```markdown
-# {task-id} — {Task Title}
+# {task-id}  -  {Task Title}
 
 **Branch**: {branch-name}
 **Project**: {project}
@@ -19,7 +19,7 @@ Create at `$HOME/.claude/logs/multi-agent/{project}/{task-id}/agent-log.md`:
 | #   | Phase | Agent | Model | Duration | Tokens (in/out) | Status | Detail |
 | --- | ----- | ----- | ----- | -------- | --------------- | ------ | ------ |
 
-> `Tokens (in/out)` is sourced from `phase-tracker.sh tokens` accumulators. Empty cell renders as `—` when no telemetry was captured for that row.
+> `Tokens (in/out)` is sourced from `phase-tracker.sh tokens` accumulators. Empty cell renders as ` - ` when no telemetry was captured for that row.
 
 ## Agent Activity Report
 
@@ -52,6 +52,14 @@ Phase 7: Report █░░░░░░░░░░░░░░░ 2s
 
 ## Review Consensus
 
+(emit from the last iteration's `triage.consensus` block, schema v3.1.0. One line stating `verdict` + `reviewerCount`; when `verdict` is `split` or `unverified`, list each `disagreements[]` entry so a human can confirm what the reviewers did not independently agree on. Omit the section when triage produced no consensus block.)
+
+```
+Verdict: unverified (2 reviewers)
+- Auth/KeychainStore.swift:40  -  token persisted without access-control flag
+  (both approved a keychain change  -  agreement unverified, confirm manually)
+```
+
 ## Cost Breakdown
 
 (emit by Phase 7 via `pipeline/scripts/render-agent-log-cost.sh <task-id>`. Renders unconditionally on every run. If the renderer exits 2 (no tracker data + no OTel spans), Phase 7 omits this section without failing the run.)
@@ -59,12 +67,14 @@ Phase 7: Report █░░░░░░░░░░░░░░░ 2s
 | Phase | Model | Tokens in | Tokens out | Est. USD |
 | ----- | ----- | --------- | ---------- | -------- |
 
+(Below the Total row the renderer appends a `*Top cost driver: <phase>  -  $X (Y% of total).*` line so the reader sees WHERE the spend went, not just the sum. When the tracker recorded `tokens_cached` for any phase, a `*Cache reads: N tokens billed at the discounted cache-read rate.*` line follows  -  this makes resume / prompt-cache reuse visible instead of hidden in the input total.)
+
 ## Test Scenarios (Jira)
 
 (User perspective: Precondition -> Steps -> Expected result)
 ```
 
-### Cost Breakdown — emission contract
+### Cost Breakdown  -  emission contract
 
 Phase 7 MUST attempt to render the Cost Breakdown section as part of the agent-log compose step:
 
@@ -73,17 +83,27 @@ COST_BLOCK=$(bash pipeline/scripts/render-agent-log-cost.sh "$TASK_ID" 2>/dev/nu
   printf '%s\n' "$COST_BLOCK" >> "$AGENT_LOG"
 ```
 
-Emission is best-effort — exit 2 (no data) is silently skipped. Never fail the pipeline on a missing cost block. The renderer reuses `cost-table.json` so any `cost-table` price update flows through to both PR-body and agent-log surfaces.
+Emission is best-effort  -  exit 2 (no data) is silently skipped. Never fail the pipeline on a missing cost block. The renderer reuses `cost-table.json` so any `cost-table` price update flows through to both PR-body and agent-log surfaces.
 
-### Tokens telemetry — phase responsibility
+### Tokens telemetry  -  phase responsibility
 
 Every phase that dispatches a billable LLM agent MUST forward its token totals to the tracker. The minimal contract (already enforced via `smoke-tracker-contract.sh` for Phase 4):
 
 ```bash
 pipeline/scripts/log-metric.sh "$TASK_ID" <phase-id> <event> \
-  model=<opus|sonnet|haiku|gpt-5.4> tokens_in=$IN tokens_out=$OUT duration_ms=$DUR
+  model=<opus|sonnet|haiku|gpt-5.4> tokens_in=$IN tokens_out=$OUT tokens_cached=$CACHED duration_ms=$DUR
 LOG_METRIC_FORWARD_TO_TRACKER=1 pipeline/scripts/log-metric.sh "$TASK_ID" <phase-id> tokens \
-  model=<...> tokens_in=$IN tokens_out=$OUT
+  model=<...> tokens_in=$IN tokens_out=$OUT tokens_cached=$CACHED
 ```
 
-Setting `LOG_METRIC_FORWARD_TO_TRACKER=1` makes `log-metric.sh` mirror the same `tokens_in`/`tokens_out` into `phase-tracker.sh tokens <phase> <in> <out>` — so JSONL metrics and tracker accumulators stay in sync from a single call site. Without this flag the JSONL line is written but the tracker is not updated; that mode is reserved for one-off analytics events that should not affect the cost block.
+Setting `LOG_METRIC_FORWARD_TO_TRACKER=1` makes `log-metric.sh` mirror the same `tokens_in`/`tokens_out`/`tokens_cached` into the tracker  -  so JSONL metrics and tracker accumulators stay in sync from a single call site. Without this flag the JSONL line is written but the tracker is not updated; that mode is reserved for one-off analytics events that should not affect the cost block.
+
+**Token-count contract (cache-exclusive).** The three counts are disjoint and map directly onto the host's usage report:
+
+| Field | Host usage field | Meaning | Priced at |
+|-------|------------------|---------|-----------|
+| `tokens_in` | `input_tokens` | freshly-billed input, NOT including cache reads | `inPerMtok` |
+| `tokens_cached` | `cache_read_input_tokens` | input served from the prompt cache | `cacheReadPerMtok` |
+| `tokens_out` | `output_tokens` | generated output | `outPerMtok` |
+
+Total input processed = `tokens_in + tokens_cached`. Never fold the cached count into `tokens_in`, and never subtract one from the other  -  both `render-agent-log-cost.sh` (pricing) and `aggregate-metrics.mjs` (cache-reuse ratio = `cached / (in + cached)`) assume this disjoint convention. `tokens_cached` is optional and defaults to 0: a phase whose host does not surface a cache-read count omits it and is priced exactly as before, so this stays backward-compatible with any tracker that predates the field.

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

@@ -1,7 +1,7 @@
-> **TLDR** — Three orthogonal modifier flags that can combine freely:
+> **TLDR**  -  Three orthogonal modifier flags that can combine freely:
 >
 > - `autopilot` → skips confirmations (Plan, Test, Commit, PR prompts), still fails safe on review blockers and build retries.
-> - `--dev` → strips to Init → Dev(Opus self-contained) → Commit → Report. No Phase 1/2/4/5.
+> - `--dev` → strips to Init → Dev(Opus self-contained) → Test → Commit → Report. No Phase 1/2/4. Phase 5 Test is an interactive prompt (suppressed only by `autopilot`).
 > - `--local` → no worktree, works directly in `$PROJECT_ROOT` on a local branch.
 >
 > Combined: `--dev --local autopilot` = fastest, least-friction path.
@@ -20,15 +20,15 @@ Autopilot mode skips interactive confirmations and runs the pipeline end-to-end
 /multi-agent "LoginView dark mode fix" autopilot
 ```
 
-**What changes in autopilot:**
+**What changes in autopilot (Tablo 1  -  Full pipeline modes):**
 
-| Phase               | Normal                                                  | Autopilot                                   |
-| ------------------- | ------------------------------------------------------- | ------------------------------------------- |
-| Phase 2 (Plan Approval Gate) | Clarification (max 2 rounds) + approval loop — user: approve/abort/free-text edit | **Gate skip** — log the plan, proceed directly to Phase 3 (autopilot contract: zero interaction) |
-| Phase 5 (User Test) | "Want to test?" -> wait                                 | Skip -> proceed directly to Phase 6         |
-| Phase 6 (Commit)    | "Want to commit?" -> wait                               | Auto commit + push                          |
-| Phase 6 (PR)        | "Want to open a PR?" -> wait                            | Auto create PR                              |
-| **Phase 7 (Channels)**  | Multi-select kanal + content menu                   | **STILL PAUSES** — see "Phase 7 autopilot exception" below |
+| Phase               | Normal (full)                                           | autopilot (full)                            | local (full)                                | local autopilot (full)                      |
+| ------------------- | ------------------------------------------------------- | ------------------------------------------- | ------------------------------------------- | ------------------------------------------- |
+| Phase 2 (Plan Approval Gate) | Clarification (max 2 rounds) + approval loop  -  user: approve/abort/free-text edit | **Gate skip**  -  log the plan, proceed directly to Phase 3 (autopilot contract: zero interaction) | Same as Normal | Same as autopilot |
+| Phase 5 (User Test) | Interactive prompt ("Want to test?" -> wait)            | Skip (autopilot suppresses interactive prompts) -> proceed directly to Phase 6 | Interactive prompt (same as Normal  -  no worktree to remove, code already in `$PROJECT_ROOT`) | Skip (same as autopilot) |
+| Phase 6 (Commit)    | "Want to commit?" -> wait                               | Auto commit + push                          | "Want to commit?" -> wait                   | Auto commit + push                          |
+| Phase 6 (PR)        | "Want to open a PR?" -> wait                            | Auto create PR                              | "Want to open a PR?" -> wait                | Auto create PR                              |
+| **Phase 7 (Channels)**  | Multi-select channel + content menu                 | **STILL PAUSES**  -  see "Phase 7 autopilot exception" below | Multi-select (same as Normal) | **STILL PAUSES** (same as autopilot) |
 
 **What NEVER skips (even in autopilot):**
 
@@ -44,13 +44,13 @@ Autopilot mode skips interactive confirmations and runs the pipeline end-to-end
 The generic "zero-interaction" contract covers Phases 0-6 only. Phase 7 channels dispatch is the **single exception**:
 
 - ALL modes (`autopilot`, `--dev autopilot`, `--local autopilot`) pause at the channels multi-select menu.
-- Menu pre-ticks from `prefs.global.reportChannels` + `prefs.global.reportContent` — user can accept with one keypress if prefs are stable.
-- **30-minute timeout** — if user does not respond, session ends cleanly:
-  - External delivery aborted (no silent apply — prevents accidental Jira comments / Confluence pages).
+- Menu pre-ticks from `prefs.global.reportChannels` + `prefs.global.reportContent`  -  user can accept with one keypress if prefs are stable.
+- **30-minute timeout**  -  if user does not respond, session ends cleanly:
+  - External delivery aborted (no silent apply  -  prevents accidental Jira comments / Confluence pages).
   - Internal capture (`agent-log.md`, telemetry, knowledge base) STILL runs.
   - State persisted as `{phase: 7, waitingFor: "user-channels-choice", channelsTimeout: true}`.
   - Resume: `/multi-agent:resume <task-id>` re-opens menu with same inputs.
-- Post-hoc `/multi-agent:channels <task>` never times out — user invoked it explicitly.
+- Post-hoc `/multi-agent:channels <task>` never times out  -  user invoked it explicitly.
 
 Full contract: `refs/phases/phase-7-report.md` (Autopilot pause contract) + `commands/multi-agent/channels.md`.
 
@@ -74,21 +74,21 @@ Dev-only mode strips the pipeline to minimum: no deep analysis, no planning phas
 **Pipeline in dev-only mode:**
 
 ```
-Phase 0: Init -> Phase 3: Dev (self-contained) -> Phase 6: Commit -> Phase 7: Report
+Phase 0: Init -> Phase 3: Dev (self-contained) -> Phase 5: Test -> Phase 6: Commit -> Phase 7: Report
 ```
 
-**What changes in dev-only:**
+**What changes in dev-only (Tablo 2  -  Dev-Only modes):**
 
-| Phase               | Normal                                          | Dev-Only                                                                           |
-| ------------------- | ----------------------------------------------- | ---------------------------------------------------------------------------------- |
-| Phase 0 (Init)      | Full setup                                      | Same — worktree, branch, state                                                     |
-| Phase 1 (Analysis)  | Parallel Explore agents                         | **SKIP**                                                                           |
-| Phase 2 (Planning)  | TaskCreate + architecture review + **Plan Approval Gate** (clarification max 2 rounds + approval loop) | **SKIP** (plan gate not applicable — fast path) |
-| Phase 3 (Dev)       | Follows Phase 2 plan, TDD cycle (Sonnet)        | **Self-contained** (Opus): agent scans relevant files, implements with TDD, builds |
-| Phase 4 (Review)    | Parallel review + Opus triage (Claude: 2-model / Copilot: 3-model) | **SKIP**                                                                           |
-| Phase 5 (User Test) | Ask user to test                                | **SKIP**                                                                           |
-| Phase 6 (Commit)    | Commit + PR                                     | Same — still asks (unless autopilot)                                               |
-| Phase 7 (Report)    | Full report + channels multi-select             | Simplified — no review/analysis sections, BUT **channels menu still pauses** |
+| Phase               | Normal (full)                                   | `--dev`                                                                            | `--dev autopilot`                            | `--dev local`                                 | `--dev local autopilot`                       |
+| ------------------- | ----------------------------------------------- | ---------------------------------------------------------------------------------- | -------------------------------------------- | --------------------------------------------- | --------------------------------------------- |
+| Phase 0 (Init)      | Full setup                                      | Same  -  worktree, branch, state                                                     | Same                                         | Same  -  no worktree, branch on `$PROJECT_ROOT` | Same as `--dev local`                         |
+| Phase 1 (Analysis)  | Parallel Explore agents                         | **SKIP**                                                                           | **SKIP**                                     | **SKIP**                                      | **SKIP**                                      |
+| Phase 2 (Planning)  | TaskCreate + architecture review + **Plan Approval Gate** (clarification max 2 rounds + approval loop) | **SKIP** (plan gate not applicable  -  fast path) | **SKIP** | **SKIP** | **SKIP** |
+| Phase 3 (Dev)       | Follows Phase 2 plan, TDD cycle (Sonnet)        | **Self-contained** (Opus): agent scans relevant files, implements with TDD, builds | Same as `--dev`                              | Same as `--dev`                               | Same as `--dev`                               |
+| Phase 4 (Review)    | Parallel review + Opus triage (Claude: 2-model / Copilot: 3-model) | **SKIP**                                                       | **SKIP**                                     | **SKIP**                                      | **SKIP**                                      |
+| Phase 5 (User Test) | Interactive prompt (ask user to test)           | **Interactive prompt** (ask user to test)                                          | **Skip** (autopilot suppresses interactive prompts) | **Interactive prompt** (same as `--dev`)      | **Skip** (same as `--dev autopilot`)          |
+| Phase 6 (Commit)    | Commit + PR                                     | Same  -  still asks (unless autopilot)                                               | Auto commit + push + PR                      | Same as `--dev`                               | Auto commit + push + PR                       |
+| Phase 7 (Report)    | Full report + channels multi-select             | Simplified  -  no review/analysis sections, BUT **channels menu still pauses** | Channels menu **STILL PAUSES** | Same as `--dev` | Channels menu **STILL PAUSES** |
 
 **Phase 3 in dev-only mode (self-contained):**
 
@@ -98,17 +98,17 @@ The **Opus** agent receives the task description (from Jira, GitHub issue, or fr
 2. Implements the change following TDD cycle (test -> code -> build)
 3. Runs build verification (max 3 retries on failure)
 
-No separate task breakdown — the agent handles scope autonomously.
+No separate task breakdown  -  the agent handles scope autonomously.
 
-**State tracking**: `agent-state.json` gets `"onlyDevelop": true`. Phases 1, 2, 4, 5 are marked `"skipped"` instead of `"pending"`.
+**State tracking**: `agent-state.json` gets `"onlyDevelop": true`. Phases 1, 2, 4 are marked `"skipped"` instead of `"pending"`. Phase 5 stays `"pending"` and runs interactively unless `autopilot` is also set, in which case it is marked `"skipped"`.
 
-**Combinable with autopilot**: `--dev autopilot` = fastest path. Init -> Dev -> auto-commit -> auto-PR -> Report. Zero user interaction (except build failures after 3 retries).
+**Combinable with autopilot**: `--dev autopilot` = fastest path. Init -> Dev -> auto-commit -> auto-PR -> Report (Phase 5 skipped). Zero user interaction (except build failures after 3 retries).
 
 ---
 
 ## Local Mode (`--local`)
 
-Local mode skips worktree creation — works directly on a local branch in the project root. Useful for single-task workflows or when worktrees cause issues.
+Local mode skips worktree creation  -  works directly on a local branch in the project root. Useful for single-task workflows or when worktrees cause issues.
 
 **Activation**: Append `--local` to any pipeline command:
 
@@ -125,7 +125,7 @@ Local mode skips worktree creation — works directly on a local branch in the p
 | -------------- | ------------------------------------------------ | -------------------------------------------------------------- |
 | Phase 0 Step 8 | Creates worktree at `.worktrees/{id}/`           | `git checkout -b {branch}` directly in `$PROJECT_ROOT`         |
 | Phase 3        | Works in worktree path                           | Works in `$PROJECT_ROOT`                                       |
-| Phase 5        | WIP commit -> remove worktree -> checkout branch | No worktree removal — code already in place, just build & test |
+| Phase 5        | WIP commit -> remove worktree -> checkout branch | No worktree removal  -  code already in place, just build & test |
 | Phase 6        | Commit in worktree, push                         | Commit in project root, push                                   |
 | All paths      | `{worktreePath}` references                      | All paths use `$PROJECT_ROOT` directly                         |
 
@@ -141,7 +141,7 @@ git -C $PROJECT_ROOT config user.email "{identity.email}"
 
 **Phase 5 in local mode:**
 
-- No worktree to remove — user tests directly in project
+- No worktree to remove  -  user tests directly in project
 - No WIP commit needed (code is already on the branch in PROJECT_ROOT)
 - "fix" goes back to Phase 3 in same directory
 
@@ -150,7 +150,7 @@ git -C $PROJECT_ROOT config user.email "{identity.email}"
 **Limitations:**
 
 - Cannot run parallel tasks on same project (no worktree isolation)
-- Uncommitted changes in PROJECT_ROOT may conflict — pipeline warns if dirty
+- Uncommitted changes in PROJECT_ROOT may conflict  -  pipeline warns if dirty
 - Build queue lock still applies for xcodebuild
 
 **Combinable**: `--local --dev autopilot` = simplest path with no worktree overhead.

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

@@ -1,4 +1,4 @@
-> **TLDR** — Pipeline operational primitives:
+> **TLDR**  -  Pipeline operational primitives:
 >
 > - **Task IDs** auto-increment from `$HOME/.claude/logs/multi-agent/{project}/.counter` (persistent).
 > - **Kill/Purge/Clear-logs** require explicit user confirm; destructive ops never chain.
@@ -12,7 +12,7 @@ Every task gets an auto-incremented short ID. Counter stored at `$HOME/.claude/l
 
 ```
 /multi-agent "PROJ-12345"
--> Task #1 started — PROJ-12345
+-> Task #1 started  -  PROJ-12345
 ```
 
 ---
@@ -24,7 +24,7 @@ Every task gets an auto-incremented short ID. Counter stored at `$HOME/.claude/l
 3. `git worktree remove .worktrees/{jiraId} --force`
 4. `git branch -D {branch-name}`
 5. Remote branch delete ONLY if user explicitly confirms
-6. Logs are preserved in `$HOME/.claude/logs/multi-agent/{project}/{task-id}/` — not deleted with worktree
+6. Logs are preserved in `$HOME/.claude/logs/multi-agent/{project}/{task-id}/`  -  not deleted with worktree
 7. Log: "Task #2 killed (logs preserved at global path)"
 
 ---
@@ -34,15 +34,15 @@ Every task gets an auto-incremented short ID. Counter stored at `$HOME/.claude/l
 1. Confirm with user
 2. Scan global log directory: `$HOME/.claude/logs/multi-agent/`
 3. Delete all `agent-log.md` and `agent-state.json` files across all projects
-4. **Do NOT reset counter** (`$HOME/.claude/logs/multi-agent/{project}/.counter`) — prevents ID collision
+4. **Do NOT reset counter** (`$HOME/.claude/logs/multi-agent/{project}/.counter`)  -  prevents ID collision
 5. Confirm count deleted
 
 ---
 
 ## Purge (Full Reset)
 
-1. First confirm: list what will be deleted
-2. Second confirm: "Type 'purge' to continue"
+1. First confirm: list what will be deleted, then a native `AskUserQuestion` picker (`Continue` / `Cancel`)
+2. Second confirm (paranoia gate): a second `AskUserQuestion` picker (`Purge permanently` / `Cancel`)  -  anything other than `Purge permanently` cancels
 3. Remove all worktrees, branches, logs, counter
 4. Do NOT delete remote branches without explicit user approval
 
@@ -53,7 +53,7 @@ Every task gets an auto-incremented short ID. Counter stored at `$HOME/.claude/l
 1. Find state file: `$HOME/.claude/logs/multi-agent/{project}/{task-id}/agent-state.json`
 2. Read `agent-log.md` for previous findings
 3. Resume from `currentPhase + 1`
-4. **Always run Phase 7** on resume completion — ensures knowledge capture even if task was paused mid-pipeline
+4. **Always run Phase 7** on resume completion  -  ensures knowledge capture even if task was paused mid-pipeline
 5. Log: "Resumed {jiraId} from Phase {N}"
 
 ---
@@ -61,7 +61,7 @@ Every task gets an auto-incremented short ID. Counter stored at `$HOME/.claude/l
 ## Phase Pipeline
 
 Run phases sequentially. Log every step to `agent-log.md`.
-If any phase fails, mark task as `paused` and stop — user can `resume` later.
+If any phase fails, mark task as `paused` and stop  -  user can `resume` later.
 Update `agent-state.json` at EVERY phase transition.
 
 ### Pipeline Best Practices
@@ -74,9 +74,9 @@ Update `agent-state.json` at EVERY phase transition.
 
 This keeps orchestrator context lean and enables programmatic routing.
 
-**Context discipline**: Send subagents ONLY what they need — the diff + relevant files, not the whole repo context. High signal-to-noise ratio > large context.
+**Context discipline**: Send subagents ONLY what they need  -  the diff + relevant files, not the whole repo context. High signal-to-noise ratio > large context.
 
-**Retry reflection**: Before each retry, force reflection: "What failed? What specific change fixes it? Am I repeating the same approach?" — prevents infinite loops on broken strategies.
+**Retry reflection**: Before each retry, force reflection: "What failed? What specific change fixes it? Am I repeating the same approach?"  -  prevents infinite loops on broken strategies.
 
 **Semantic revert**: Track which files each phase produces in `agent-state.json`. If Phase 5 (testing) fails, revert only Phase 4 (implementation) outputs, not Phase 2 (artifacts):
 
@@ -86,6 +86,6 @@ This keeps orchestrator context lean and enables programmatic routing.
 }
 ```
 
-**Proactive compaction**: If conversation context exceeds ~60%, dump progress to `agent-log.md` and summarize state before continuing. Don't wait for auto-compaction at 83% — it's lossy.
+**Proactive compaction**: If conversation context exceeds ~60%, dump progress to `agent-log.md` and summarize state before continuing. Don't wait for auto-compaction at 83%  -  it's lossy.
 
 **3-iteration hard kill**: Any retry loop (build fix, review fix) MUST stop after 3 attempts. On 4th failure -> pause, ask user. No exceptions.