@mmerterden/multi-agent-pipeline 18.0.0 → 19.0.0

package/pipeline/multi-agent-refs/features/verify-by-test.md

@@ -1,4 +1,4 @@
-# Feature: Verify-by-Test Triage (Phase 4 Step 3.7)
+# Feature: Verify-by-Test Triage (Phase 3 Step 3.7)
 
 **Pattern**: reviewer findings are hypotheses; a failing repro test is proof. Adversarial-review research (Refute-or-Promote, 2026) found that plausible-but-wrong findings survive debate rounds but die on a single empirical test. This step converts the highest-stakes verdicts (accepted blocking) from judgment into evidence before the Phase 3 rework loop fires.
 
@@ -19,7 +19,7 @@
 | Passes on some runs, fails on others | `inconclusive` | Flake, not proof either way. Finding stays accepted blocking, `verification.note = "flaky: passed k/N"`, repro test file deleted, telemetry line gains `flaky=<count>`. |
 | Compile error / timeout / not unit-testable | `inconclusive` | Finding stays accepted blocking (judgment stands). Partial test deleted, cause in `verification.note`. |
 
-Downgrades go to `deferred`, never `rejected`: triage judged the issue real, and deferred items surface in the Phase 7 report for a human eye.
+Downgrades go to `deferred`, never `rejected`: triage judged the issue real, and deferred items surface in the Phase 5 report for a human eye.
 
 ## Red-test handoff to Phase 3
 
@@ -27,7 +27,7 @@ Downgrades go to `deferred`, never `rejected`: triage judged the issue real, and
 
 ## Cleanup invariant
 
-After Step 3.7, the only uncommitted verifier artifacts are the confirmed repro tests listed in `redTests[]` (committed later with the fix) and logs under `$WORKTREE/.pipeline/` (outside Phase 6 commit scope). `not-reproduced` and `inconclusive` test files are always deleted.
+After Step 3.7, the only uncommitted verifier artifacts are the confirmed repro tests listed in `redTests[]` (committed later with the fix) and logs under `$WORKTREE/.pipeline/` (outside Phase 4 commit scope). `not-reproduced` and `inconclusive` test files are always deleted.
 
 ## Telemetry
 
@@ -39,4 +39,4 @@ Adds one Sonnet call plus up to `maxFindings` single-test runs (and build-lock c
 
 ## Reference
 
-Wiring: `$HOME/.claude/multi-agent-refs/phases/phase-4-review.md` Step 3.7. Schema: `$HOME/.claude/schemas/triage-output.schema.json` v3.2.0 (`$defs.verification`). Evidence gate: `$HOME/.claude/scripts/evidence-gate.mjs`. Prefs: `prefs.global.verifyByTest` (including `repeatCount`) in `$HOME/.claude/schemas/prefs.schema.json`.
+Wiring: `$HOME/.claude/multi-agent-refs/phases/phase-3-review.md` Step 3.7. Schema: `$HOME/.claude/schemas/triage-output.schema.json` v3.2.0 (`$defs.verification`). Evidence gate: `$HOME/.claude/scripts/evidence-gate.mjs`. Prefs: `prefs.global.verifyByTest` (including `repeatCount`) in `$HOME/.claude/schemas/prefs.schema.json`.

package/pipeline/multi-agent-refs/features/visual-evidence.md

@@ -3,7 +3,7 @@
 <!-- toc -->
 - [1. When it is required](#1-when-it-is-required)
 - [2. Before  -  the reporter's screenshot, or nothing](#2-before---the-reporters-screenshot-or-nothing)
-- [3. After  -  Phase 3, not Phase 5](#3-after---phase-3-not-phase-5)
+- [3. After  -  Phase 2, not the Phase 3 user test](#3-after---phase-2-not-the-phase-3-user-test)
 - [4. Video  -  the recording rides on a test run](#4-video---the-recording-rides-on-a-test-run)
 - [5. Size, and what happens when it does not fit](#5-size-and-what-happens-when-it-does-not-fit)
 - [5b. Where the artefacts live  -  the host](#5b-where-the-artefacts-live---the-host)
@@ -18,10 +18,10 @@ This contract makes the pipeline carry the picture: the state the reporter saw,
 the state the fix produces, and where possible a recording of the flow running.
 
 The artefacts live as **Jira attachments** and are referenced from two places -
-the Phase 7 Jira comment, where the picture belongs next to the work summary and
+the Phase 5 Jira comment, where the picture belongs next to the work summary and
 the test scenarios, and the PR body, which tells the reviewer they exist.
 
-Consumers: Phase 3 (capture), Phase 5 (video, preferred host), Phase 6 (blocker),
+Consumers: Phase 2 (capture), Phase 3 (video, user test), Phase 4 (blocker),
 `channels/jira.md` and `channels/pr.md` (render). Gate: `smoke-visual-evidence.sh`.
 
 ## 1. When it is required
@@ -49,16 +49,16 @@ artefact is absent, the absence is written down with its reason (section 5).
 
 **Phase 0 Step 7.7 writes `required`, `requiredBy` and `platform`**, before it
 probes. Naming the writer is not a formality: five phases read these three fields
-and nothing set them, so `required` was never true, Step 7.7 never ran, Phase 3
-never captured, and Phase 6's blocker never blocked. A contract with readers and
+and nothing set them, so `required` was never true, Step 7.7 never ran, Phase 2
+never captured, and Phase 4's blocker never blocked. A contract with readers and
 no writer reads exactly like a contract that is satisfied.
 
 Phase 0 has no diff, so it decides on what it actually knows - `taskType` and
 whether the intake carried a Figma reference - and that is enough for the whole
 design-work row. The `bugfix` row needs a changed-file list, so Phase 0 records
-it as provisional (`requiredBy: "bugfix (pending diff)"`) and **Phase 3 re-decides
+it as provisional (`requiredBy: "bugfix (pending diff)"`) and **Phase 2 re-decides
 from the real diff** before capturing. A provisional `false` never suppresses the
-Phase 3 decision.
+Phase 2 decision.
 
 ### 1b. The platform, and when there is not one
 
@@ -120,15 +120,15 @@ No image on the ticket means no "before". Record the gap
 (`before_missing: "ticket carries no image attachment"`) and continue. The
 section still renders, saying so.
 
-## 3. After  -  Phase 3, not Phase 5
+## 3. After  -  Phase 2, not the Phase 3 user test
 
-Phase 5 is the natural home: the simulator is already up. It is also **dropped by
-every `autopilot` and `--local` entry** (`phase-5-test.md` TLDR), so a capture
+The user test is the natural home: the simulator is already up. It is also **dropped by
+every `autopilot` and `--local` entry** (`phase-3-review.md` TLDR), so a capture
 that lives only there produces nothing for unattended runs - which are exactly
 the runs where nobody watched the screen.
 
-The capture therefore happens in **Phase 3, after the build+test gate passes**,
-which is in every mode's phase set. Phase 5 may add richer evidence on top; it is
+The capture therefore happens in **Phase 2, after the build+test gate passes**,
+which is in every mode's phase set. The Phase 3 user test may add richer evidence on top; it is
 never the only source.
 
 ```bash
@@ -192,8 +192,8 @@ The recorder itself is `capture-evidence.sh video start|stop`, which writes
 `<task-id>[-<label>]-flow.mp4` into the evidence directory. The label is optional
 because one recording per task is the common case, and both renderers cite the
 unlabelled form. It is shell rather than MCP for three reasons: the sibling still capture already shells out,
-a host with no toolkit MCP registered still produces evidence, and Phase 3 and
-Phase 5 are exactly where an MCP call is contested.
+a host with no toolkit MCP registered still produces evidence, and Phase 2 and
+Phase 3 are exactly where an MCP call is contested.
 
 **iOS UI test targets are not named, they are detected.** A path containing
 `UITests` is not the signal: in the reference app 477 files sit under such a path
@@ -210,8 +210,8 @@ wearing a measurement's clothes.
 
 ### 4.4 Re-check before recording
 
-The probe runs at intake and the recording happens in Phase 3. A simulator booted
-then can be gone by the time the build goes green, so Phase 3 re-measures the
+The probe runs at intake and the recording happens in Phase 2. A simulator booted
+then can be gone by the time the build goes green, so Phase 2 re-measures the
 device row alone and downgrades the tier if it has to, recording the transition
 (`tier 1 -> 3: simulator no longer booted`). A tier taken from a stale
 measurement is a promise the run cannot keep.
@@ -232,7 +232,7 @@ never asserted against wall clock anywhere, because doing so fails a correct
 capture of a static screen.
 
 `visualEvidence.enabled` turns the whole feature off - capture, upload, both
-render sections and the Phase 6 blocker with it.
+render sections and the Phase 4 blocker with it.
 
 ### 4.6 Web - the recorder IS the runner
 
@@ -283,7 +283,7 @@ Never silently attach nothing.
 
 ## 5b. Where the artefacts live  -  the host
 
-Resolved in Phase 6 Step 2.9, recorded as `state.visualEvidence.host`:
+Resolved in Phase 4 Step 2.9, recorded as `state.visualEvidence.host`:
 
 | Order | Host | Condition | Stills | Video |
 |---|---|---|---|---|
@@ -342,7 +342,7 @@ where it lives - the images themselves stay on the ticket:
 ## 7. Blocker
 
 When section 1 says required and `state.visualEvidence` carries neither an
-artefact nor a recorded reason for its absence, **Phase 6 Step 3 blocks** - the
+artefact nor a recorded reason for its absence, **Phase 4 Step 3 blocks** - the
 same shape as the `risk` section blocker. A recorded reason is enough to pass:
 the gate is against silence, not against an honest "no image on the ticket".
 

package/pipeline/multi-agent-refs/features/worktree-finalize.md

@@ -1,6 +1,6 @@
 # Worktree finalize  -  removing a task's worktree once its PR is open
 
-> **TLDR**  -  Phase 6 step 9. Once the PR exists the worktree is dead weight, so it is removed: artefacts are salvaged into the log dir first, the branch is kept and deliberately NOT checked out, and every destructive path is gated. Gated by `prefs.global.settings.worktreeAutoRemoveOnPr` (default **true**). Script: `worktree-finalize.sh`.
+> **TLDR**  -  Phase 4 step 9. Once the PR exists the worktree is dead weight, so it is removed: artefacts are salvaged into the log dir first, the branch is kept and deliberately NOT checked out, and every destructive path is gated. Gated by `prefs.global.settings.worktreeAutoRemoveOnPr` (default **true**). Script: `worktree-finalize.sh`.
 
 ## Why it exists
 
@@ -21,12 +21,12 @@ Removing it at PR-open is only safe because of the salvage, so the two are one s
 | Condition | Why it blocks |
 |---|---|
 | `worktreePath == projectRoot` (`--local` mode) | there is no worktree; removing it would delete the user's checkout |
-| cwd is inside the worktree | a shell left on a deleted inode is worse than a leftover directory, and Phase 6 legitimately `cd`s into the worktree earlier |
+| cwd is inside the worktree | a shell left on a deleted inode is worse than a leftover directory, and Phase 4 legitimately `cd`s into the worktree earlier |
 | not a registered worktree of the project root | a mistyped path must not delete an unrelated directory |
 | real uncommitted changes | never discarded; see the artefact carve-out below |
 | HEAD not on the remote | removing a worktree whose commits exist nowhere else is data loss, not cleanup |
 
-Exit codes: `0` removed, `3` skipped with a reason (report and continue to Phase 7), `1` usage error.
+Exit codes: `0` removed, `3` skipped with a reason (report and continue to Phase 5), `1` usage error.
 
 ### The artefact carve-out, and why `--untracked-files=no` is wrong
 
@@ -49,10 +49,10 @@ This is why the removal is safe:
 
 | Consumer | Reads | Without salvage |
 |---|---|---|
-| Phase 7 triage-memory ingest | `triage-output.json` | `[ -f ]`-guarded, so it degrades **silently**: the triage corpus and learnings ledger stop being fed and no error appears. Since v16.20.0 Phase 4 writes `triage-output.json` itself (Step 3.2.1, the latest copy of `.pipeline/triage-round-<N>.json`), so the salvage is a second copy, not the only bridge |
-| Phase 7 learnings-ledger distill | same file | same silent degradation |
+| Phase 5 triage-memory ingest | `triage-output.json` | `[ -f ]`-guarded, so it degrades **silently**: the triage corpus and learnings ledger stop being fed and no error appears. Since v16.20.0 Phase 4 writes `triage-output.json` itself (Step 3.2.1, the latest copy of `.pipeline/triage-round-<N>.json`), so the salvage is a second copy, not the only bridge |
+| Phase 5 learnings-ledger distill | same file | same silent degradation |
 | `render-work-summary.sh` | `agent-state.json`, `phase-tracker.json` (falls back to `logs/multi-agent/<task>/tracker-state.json`, which survives removal) | loses the salvaged copies but keeps the tracker via the logs fallback |
-| `:resume` | `agent-state.json` | cannot continue a Phase 7 pause |
+| `:resume` | `agent-state.json` | cannot continue a Phase 5 pause |
 | `:status`, `:log` | `agent-state.json` | the task becomes invisible |
 
 `state.worktreeRemovedAt` and `state.artifactsPath` record the outcome. The timestamp is what tells a reader that a worktree-less task was finished-and-tidied rather than killed  -  without it, a missing worktree is indistinguishable from a broken run.

package/pipeline/multi-agent-refs/issue-jira-triad.md

@@ -3,15 +3,15 @@
 <!-- toc -->
 - [The triad at a glance](#the-triad-at-a-glance)
 - [Phase 0 auto-create policy](#phase-0-auto-create-policy)
-- [Phase 7 wiki → Jira comment](#phase-7-wiki-jira-comment)
+- [Phase 5 wiki → Jira comment](#phase-5-wiki-jira-comment)
 - [Autopilot behaviour](#autopilot-behaviour)
 - [Preferences involved](#preferences-involved)
 - [Cross-CLI parity](#cross-cli-parity)
 <!-- /toc -->
 
-> **TLDR**  -  When a GitHub issue triggers the pipeline and has no Jira ID, the `autoJiraFromGithubIssue` policy decides whether to auto-create a Jira task (and patch the GitHub issue body with the new Jira link). Phase 7 then posts a humanizer'd wiki-content summary back as a Jira comment, closing the loop. Autopilot treats `ask` as `always`.
+> **TLDR**  -  When a GitHub issue triggers the pipeline and has no Jira ID, the `autoJiraFromGithubIssue` policy decides whether to auto-create a Jira task (and patch the GitHub issue body with the new Jira link). Phase 5 then posts a humanizer'd wiki-content summary back as a Jira comment, closing the loop. Autopilot treats `ask` as `always`.
 
-This doc is referenced from `$HOME/.claude/multi-agent-refs/phases/phase-0-init.md` Step 1 (GitHub issue input) and `$HOME/.claude/multi-agent-refs/phases/phase-7-report.md` Step 2 (component wiki). Keeps the phase docs tight and gives the triad contract a stable home.
+This doc is referenced from `$HOME/.claude/multi-agent-refs/phases/phase-0-init.md` Step 1 (GitHub issue input) and `$HOME/.claude/multi-agent-refs/phases/phase-5-report.md` Step 2 (component wiki). Keeps the phase docs tight and gives the triad contract a stable home.
 
 ## The triad at a glance
 
@@ -24,7 +24,7 @@ Jira issue (new, linked both ways)
      ▼  Phase 3  -  component implementation
 wiki markdown in pipeline/skills/...
      │
-     ▼  Phase 7 Report Step 2  -  wiki capture + Jira comment post
+     ▼  Phase 5 Report Step 2  -  wiki capture + Jira comment post
 Jira comment (humanizer'd component summary)
 ```
 
@@ -59,13 +59,13 @@ Decision table:
 5. On success: store new Jira key in `state.jiraId`. Emit `→ created Jira {newKey}`.
 6. Patch the GitHub issue body: append a line `Jira: [{newKey}]({jira.baseUrl}/browse/{newKey})` so the bidirectional link is visible on GitHub without refetching the pipeline state.
 
-**Skip path** (`never` or user declined): Branch falls back to `feature/GH{issueNo}-{kebab}`; Phase 7 later emits `→ no Jira linked (policy: {preference})`.
+**Skip path** (`never` or user declined): Branch falls back to `feature/GH{issueNo}-{kebab}`; Phase 5 later emits `→ no Jira linked (policy: {preference})`.
 
 **Failure isolation:** Jira API 5xx or network error → log the error, warn the user, and **continue with no Jira link** (do not halt Phase 0). Rationale: a transient Jira outage should not block code work; user can link manually post-hoc.
 
-## Phase 7 wiki → Jira comment
+## Phase 5 wiki → Jira comment
 
-Runs after Phase 7 Report Step 2 (wiki capture) has produced markdown and only when:
+Runs after Phase 5 Report Step 2 (wiki capture) has produced markdown and only when:
 
 - `state.jiraId` is non-null (from Phase 0 scan or auto-create).
 - `prefs.global.wikiToJiraComment !== false` (default true).
@@ -78,9 +78,9 @@ Flow:
 3. Render as Jira comment: title line (`h3. Component docs  -  {componentName}`) + an overview paragraph + a link to the full page (wiki URL, if the adapter returned `pushedRemote`). The overview lines come from a Markdown file  -  convert them via the `channels/jira.md` table before POST, exactly like the title line already is, then run the whole body through `node "$HOME/.claude/scripts/jira-wiki-escape.mjs"` per that file's *Emoticon escaping* section.
 4. **Run through the humanizer skill**  -  same policy as Step 4 Confluence: user-facing content must read naturally.
 5. `POST {jira.baseUrl}/rest/api/2/issue/{jiraId}/comment`.
-6. Log: `Phase 7: wiki summary posted to Jira {jiraId}`.
+6. Log: `Phase 5: wiki summary posted to Jira {jiraId}`.
 
-On failure: log + continue. Wiki is already written; the Jira comment is an augmentation. Don't regress Phase 7 over a Jira 5xx.
+On failure: log + continue. Wiki is already written; the Jira comment is an augmentation. Don't regress Phase 5 over a Jira 5xx.
 
 ## Autopilot behaviour
 
@@ -96,7 +96,7 @@ Rationale: autopilot is explicit consent for side-effect creation; muting Jira a
 | key | type | default | controls |
 |---|---|---|---|
 | `prefs.global.autoJiraFromGithubIssue` | enum ask/always/never | `ask` | Phase 0 auto-create decision |
-| `prefs.global.wikiToJiraComment` | bool | `true` | Phase 7 wiki → Jira comment post |
+| `prefs.global.wikiToJiraComment` | bool | `true` | Phase 5 wiki → Jira comment post |
 | `figmaConfig.jira.projectKey` | string |  -  | Target project for new issues (falls back to `prefs.global.defaultJiraKey`) |
 | `prefs.global.keychainMapping.jira` | string |  -  | Jira token keychain lookup |
 

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

@@ -30,11 +30,11 @@ $HOME/.claude/knowledge/
 ### How It Works
 
 ```
-Task 1 (first time): Phase 1 -> full Explore -> Phase 7 -> create knowledge
-Task 2:             Phase 1 -> read knowledge -> targeted Explore -> Phase 7 -> update knowledge
-Task 3:             Phase 1 -> read knowledge -> minimal Explore -> Phase 7 -> update knowledge
+Task 1 (first time): Phase 1 -> full Explore -> Phase 5 -> create knowledge
+Task 2:             Phase 1 -> read knowledge -> targeted Explore -> Phase 5 -> update knowledge
+Task 3:             Phase 1 -> read knowledge -> minimal Explore -> Phase 5 -> update knowledge
   ...
-Task N:             Phase 1 -> knowledge sufficient -> SKIP Explore -> Phase 7 -> update knowledge
+Task N:             Phase 1 -> knowledge sufficient -> SKIP Explore -> Phase 5 -> update knowledge
 ```
 
 Each task teaches the project a bit more. Token cost decreases over time.
@@ -45,7 +45,7 @@ Each task teaches the project a bit more. Token cost decreases over time.
 | ------------------------------------------- | --------------------- | ------------------------------------------ | ------------------------ |
 | `$PROJECT_ROOT/CLAUDE.md`                   | User                  | Project rules, build commands              | Persistent (in git)      |
 | 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) |
+| **Knowledge Base** (`~/.claude/knowledge/`) | Multi-agent (Phase 5) | Architecture, patterns, gotchas, decisions | Persistent (per-project) |
 
 They all complement each other  -  no conflicts.
 
@@ -54,7 +54,7 @@ They all complement each other  -  no conflicts.
 A Short run skips Phase 1, but knowledge **is still read**:
 
 - Knowledge files are added to the prompt before the Opus agent starts in Phase 3
-- Knowledge capture is still performed in Phase 7 (simplified report)
+- Knowledge capture is still performed in Phase 5 (simplified report)
 
 ### Knowledge Maintenance
 
@@ -107,18 +107,18 @@ When calling sub-agents, inject task-specific context from previous phases:
 ### Phase -> Agent -> Context Flow
 
 ```
-Phase 1: Analysis
+Phase 1: Plan (analysis)
   -- Explore agents (parallel) -> codebase scan
 
-Phase 2: Planning
+Phase 1: Plan
   -- Architecture review agent
        Context: task description + Phase 1 findings + affected modules
 
-Phase 3: Dev
+Phase 2: Dev
   -- Sonnet agent (TDD)
-       Context: Phase 2 plan + task dependencies
+       Context: Phase 1 plan + task dependencies
 
-Phase 4: Review (CLI-aware parallel + triage)
+Phase 3: Review (CLI-aware parallel + triage)
   Claude Code (3 parallel):
     |-- Reviewer (opus)   -> security + architecture
     +-- Reviewer (sonnet) -> quality + correctness + edge cases

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

@@ -7,7 +7,7 @@
 - [Auto-run steps (when host is learned)](#auto-run-steps-when-host-is-learned)
 - [Error evaluation contract](#error-evaluation-contract)
 - [Autopilot behavior](#autopilot-behavior)
-- [Phase 7 knowledge capture](#phase-7-knowledge-capture)
+- [Phase 5 knowledge capture](#phase-5-knowledge-capture)
 - [Generic rule (for copilot-instructions.md)](#generic-rule-for-copilot-instructionsmd)
 - [Schema](#schema)
 - [Smoke coverage](#smoke-coverage)
@@ -27,7 +27,7 @@ Codegen outputs (identifiers, localization keys, tokens) in Repo A get reference
 
 ## When this rule fires
 
-In Phase 6 (Commit & PR), **before** the pre-commit local checkout prompt, if `state.projects.length >= 2`:
+In Phase 4 (Commit & PR), **before** the pre-commit local checkout prompt, if `state.projects.length >= 2`:
 
 1. Compute `repoSet` = sorted array of touched repo names.
 2. Look up `prefs.global.multiRepoIntegrationHosts` for an entry whose `repoSet` (sorted) equals this combo.
@@ -100,7 +100,7 @@ Persist to `prefs.global.multiRepoIntegrationHosts[]`:
 
 ## Auto-run steps (when host is learned)
 
-Progress-contract line `→ integrating <host-scheme> with <N> submodules`. Tracker sub-step on Phase 6 to show live status: `phase-tracker.sh sub 6 0 "Integration build" in_progress`.
+Progress-contract line `→ integrating <host-scheme> with <N> submodules`. Tracker sub-step on Phase 4 to show live status: `phase-tracker.sh sub 4 0 "Integration build" in_progress`.
 
 ```bash
 HOST="$(jq -r --arg key "$repoSet_sorted_joined" \
@@ -126,12 +126,12 @@ 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"
+  phase-tracker.sh sub 4 0 "Integration build" completed
+  log "Phase 4.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"
+  phase-tracker.sh sub 4 0 "Integration build" failed
+  log "Phase 4.0: Integration build  -  NEW errors detected"
   # show errors, ask user
 fi
 ```
@@ -150,13 +150,13 @@ Three outcomes after the build:
    Integration build failed with N new errors. Pipeline can go back to
    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)
+   [1] Return to Phase 2: 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)
+   [3] Override  -  proceed to commit anyway (logs a warning in Phase 5 report)
 
    Select [1-3]:
    ```
-3. **Pre-existing errors (unrelated to this task)** → if the pipeline has a baseline error count (from a clean pre-change build), compare deltas. When `current_errors <= baseline`, treat as **no new errors** and proceed; log the pre-existing count in Phase 7 Report.
+3. **Pre-existing errors (unrelated to this task)** → if the pipeline has a baseline error count (from a clean pre-change build), compare deltas. When `current_errors <= baseline`, treat as **no new errors** and proceed; log the pre-existing count in Phase 5 Report.
 
 ---
 
@@ -164,13 +164,13 @@ Three outcomes after the build:
 
 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 4.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.
 
 ---
 
-## Phase 7 knowledge capture
+## Phase 5 knowledge capture
 
-When a learn-once prompt writes a new entry, Phase 7 Step 5 (knowledge + memory) ALSO writes a project-scoped memory:
+When a learn-once prompt writes a new entry, Phase 5 Step 5 (knowledge + memory) ALSO writes a project-scoped memory:
 
 ```
 Type: reference

package/pipeline/multi-agent-refs/payload-contracts.md

@@ -1,26 +1,26 @@
 ---
-description: "Canonical required-reading list for outward-facing payloads (PR body, Jira comment, closing report) plus the markup dialect per surface. Loaded by every mode that runs Phase 6 or Phase 7."
+description: "Canonical required-reading list for outward-facing payloads (PR body, Jira comment, closing report) plus the markup dialect per surface. Loaded by every mode that runs Phase 4 or Phase 5."
 ---
 
 # Outward-facing payload contracts
 
 > Every mode that opens a PR, comments on a tracker, or closes out a run reads this file first. It does not restate the contracts  -  it names them, so no mode has to carry its own copy and drift from the others.
 
-## Read before Phase 6
+## Read before Phase 4
 
 | Read | Before | Governs |
 |---|---|---|
 | [`channels/pr.md`]($HOME/.claude/multi-agent-refs/channels/pr.md) | assembling the PR body | fixed section set (`summary` → `changes` → `architecture` cond. → `verification` → `risk` cond. → `dependencies` cond. → `related`), Markdown-only rule, reviewer-preserving Bitbucket PUT payload |
-| [`phases/phase-6-commit.md`]($HOME/.claude/multi-agent-refs/phases/phase-6-commit.md) | committing | commit convention, default-reviewer fetch, draft/ready prompt, push-must-succeed loop |
+| [`phases/phase-4-commit.md`]($HOME/.claude/multi-agent-refs/phases/phase-4-commit.md) | committing | commit convention, default-reviewer fetch, draft/ready prompt, push-must-succeed loop |
 | [`rules.md`]($HOME/.claude/multi-agent-refs/rules.md) "External System Outputs" | any REST payload | real newlines, no HTML entities, no hand-rolled JSON, markup dialect per surface |
 
-## Read before Phase 7
+## Read before Phase 5
 
 | Read | Before | Governs |
 |---|---|---|
 | [`channels/jira.md`]($HOME/.claude/multi-agent-refs/channels/jira.md) | posting the Jira comment | fixed section set incl. **Test Scenarios** (Given/When/Then, always present), markdown→wiki conversion table |
 | [`channels/confluence.md`]($HOME/.claude/multi-agent-refs/channels/confluence.md) | writing a Confluence page | storage-format conversion, endpoint flavor |
-| [`phases/phase-7-report.md`]($HOME/.claude/multi-agent-refs/phases/phase-7-report.md) | closing out | Timeline + Agent Activity + Cost Breakdown tables, missing-telemetry disclosure |
+| [`phases/phase-5-report.md`]($HOME/.claude/multi-agent-refs/phases/phase-5-report.md) | closing out | Timeline + Agent Activity + Cost Breakdown tables, missing-telemetry disclosure |
 | [`tracker-contract.md`]($HOME/.claude/multi-agent-refs/tracker-contract.md) | every phase boundary | per-phase token narration, completion tile suffix |
 
 ## Markup dialect per surface
@@ -44,12 +44,12 @@ A payload that is in the right language but the wrong dialect is a defect of the
 
 The run ends with the phase tracker glyph block **and** the numbers behind it  -  per-phase duration and token spend, plus totals.
 
-- Record spend as you go: `phase-tracker.sh tokens <N> <in> <out> [cached]` after **every** LLM call, including each Phase 4 reviewer subagent and each Phase 3 chunk. Counts are additive and nothing reconstructs them after the fact.
+- Record spend as you go: `phase-tracker.sh tokens <N> <in> <out> [cached]` after **every** LLM call, including each Phase 3 reviewer subagent and each Phase 3 chunk. Counts are additive and nothing reconstructs them after the fact.
 - Tag the model once per phase (`phase-tracker.sh model <N> <name>`) or the cost helper cannot price it and prints `-`.
 - Durations come from the phase timestamps and survive a missed `tokens` call; token spend does not.
 - If any phase has no token data, name those phases and say their cost is unavailable. Never print a report whose cost section is simply absent  -  the reader cannot tell "cheap run" from "nobody recorded it".
 
-### Missing-telemetry disclosure (Phase 7, required)
+### Missing-telemetry disclosure (Phase 5, required)
 
 Before composing the report, compute which phases carry no token data:
 
@@ -64,4 +64,4 @@ Non-empty `UNTRACKED` → both the agent-log report and the closing chat summary
 
 ## Fast modes are not exempt
 
-A Short run skips Analysis and Planning, and the autopilot and local entries skip the interactive test gate. They run Phase 6 and Phase 7 **unchanged**. A short pipeline is not a licence for an improvised payload shape, a missing Test Scenarios section, or a report without numbers.
+A Short run skips Analysis and Planning, and the autopilot and local entries skip the interactive test gate. They run Phase 4 and Phase 5 **unchanged**. A short pipeline is not a licence for an improvised payload shape, a missing Test Scenarios section, or a report without numbers.

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

@@ -33,13 +33,13 @@ Create at `$HOME/.claude/logs/multi-agent/{project}/{task-id}/agent-log.md`:
 ## Phase Duration Distribution
 
 Phase 0: Init ████░░░░░░░░░░░░ 5s
-Phase 1: Analysis ██████░░░░░░░░░░ 12s
-Phase 2: Planning █████░░░░░░░░░░░ 8s
-Phase 3: Dev ████████████████ 2m 35s
-Phase 4: Review ████████░░░░░░░░ 37s
-Phase 5: Test ██░░░░░░░░░░░░░░ (user wait)
-Phase 6: Commit ██░░░░░░░░░░░░░░ 3s
-Phase 7: Report █░░░░░░░░░░░░░░░ 2s
+Phase 1: Plan (analysis) ██████░░░░░░░░░░ 12s
+Phase 1: Plan █████░░░░░░░░░░░ 8s
+Phase 2: Dev ████████████████ 2m 35s
+Phase 3: Review ████████░░░░░░░░ 37s
+Phase 3: Review (user test) ██░░░░░░░░░░░░░░ (user wait)
+Phase 4: Commit ██░░░░░░░░░░░░░░ 3s
+Phase 5: Report █░░░░░░░░░░░░░░░ 2s
 
 ## Review Iterations
 
@@ -62,7 +62,7 @@ Verdict: unverified (3 reviewers)
 
 ## Cost Breakdown
 
-(emit by Phase 7 via `$HOME/.claude/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.)
+(emit by Phase 5 via `$HOME/.claude/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 5 omits this section without failing the run.)
 
 | Phase | Model | Tokens in | Tokens out | Est. USD |
 | ----- | ----- | --------- | ---------- | -------- |
@@ -86,7 +86,7 @@ Verdict: unverified (3 reviewers)
 
 ### Cost Breakdown  -  emission contract
 
-Phase 7 MUST attempt to render the Cost Breakdown section as part of the agent-log compose step:
+Phase 5 MUST attempt to render the Cost Breakdown section as part of the agent-log compose step:
 
 ```bash
 COST_BLOCK=$(bash $HOME/.claude/scripts/render-agent-log-cost.sh "$TASK_ID" 2>/dev/null) && \
@@ -97,7 +97,7 @@ Emission is best-effort  -  exit 2 (no data) is silently skipped. Never fail the
 
 ### 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):
+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 3):
 
 ```bash
 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" <phase-id> <event> \