@mmerterden/multi-agent-pipeline 18.0.0 → 19.0.0

package/pipeline/multi-agent-refs/phases/{phase-6-commit.md → phase-4-commit.md}

@@ -1,4 +1,4 @@
-### Phase 6: Commit & PR
+### Phase 4: Commit
 
 > **TLDR**  -  Commit with conventional message + ticket ID, push, open PR. Order: (1) identity confirm → (2) commit → (3) push → (4) fetch default reviewers → (5) ask DRAFT-or-READY → (6) build payload with heredoc+rawfile → (7) POST with `reviewers`+`fromRef`+`toRef`+`draft` required on Bitbucket (missing fields wipe defaults).
 
@@ -23,13 +23,13 @@ Progress emission per `$HOME/.claude/multi-agent-refs/progress-contract.md`  -
 
 #### Input contract
 
-Phase 6 consumes the latest Phase 4 triage output object conforming to `$HOME/.claude/schemas/triage-output.schema.json` (`accepted`, `deferred`, `rejected` buckets) plus the working-tree mutations from Phase 3. The commit body cites only `accepted` findings that were resolved; `deferred` items must be linked in the PR description as follow-up work, never silently dropped. If the triage output reports any unresolved blocking accepted finding, Phase 6 refuses to commit  -  the pipeline returns to Phase 3 for rework.
+Phase 4 consumes the latest Phase 3 triage output object conforming to `$HOME/.claude/schemas/triage-output.schema.json` (`accepted`, `deferred`, `rejected` buckets) plus the working-tree mutations from Phase 2. The commit body cites only `accepted` findings that were resolved; `deferred` items must be linked in the PR description as follow-up work, never silently dropped. If the triage output reports any unresolved blocking accepted finding, Phase 4 refuses to commit  -  the pipeline returns to Phase 2 for rework.
 
-The "Build passes" checklist item below is evidence-gated, not self-asserted: Phase 6 trusts the `buildStatus.ok` that Phase 3 / Phase 4 recorded through `$HOME/.claude/scripts/evidence-gate.mjs` (a pass without a substantiating build/test log is treated as unverified and blocks the commit). The secret scanner (`pre-commit-check.sh`) runs on the staged diff as the final pre-commit gate.
+The "Build passes" checklist item below is evidence-gated, not self-asserted: Phase 4 trusts the `buildStatus.ok` that Phase 2 / Phase 3 recorded through `$HOME/.claude/scripts/evidence-gate.mjs` (a pass without a substantiating build/test log is treated as unverified and blocks the commit). The secret scanner (`pre-commit-check.sh`) runs on the staged diff as the final pre-commit gate.
 
 #### Step 0a  -  Plan coverage gate (BLOCKING)
 
-Phase 4 answers whether the diff is correct, not whether everything the plan promised landed: the criteria manifest counts rule IDs, Step 1.45 counts planned tests, and the per-step rollup is rendered in Phase 7, after this commit.
+Phase 3 answers whether the diff is correct, not whether everything the plan promised landed: the criteria manifest counts rule IDs, Step 1.45 counts planned tests, and the per-step rollup is rendered in Phase 5, after this commit.
 
 ```bash
 # One --analysis per doc: state.analysis.docPath[] is an array (one per platform),
@@ -43,7 +43,7 @@ node "$HOME/.claude/scripts/plan-coverage-gate.mjs" --state "$STATE_FILE" \
 
 A step is accounted for when it is `completed`, `skipped` + `skipReason`, or `failed` + `failureReason`; a bare `pending` / `in_progress` is what this catches. Every Section 14 row tagged `Add new` must name a file that exists in the tree, and an empty `docPath[]` leaves that half reporting `skipped`, never `passed`.
 
-On exit 1: show the gate's list verbatim, then either return to Phase 3 or have the user mark each step deliberately (`plan-todos.sh` writes the reason). Never proceed without that decision. Exit 2 means the plan was missing or empty: modes without Phase 2 skip this step explicitly.
+On exit 1: show the gate's list verbatim, then either return to Phase 2 or have the user mark each step deliberately (`plan-todos.sh` writes the reason). Never proceed without that decision. Exit 2 means the plan was missing or empty: modes without Phase 1 skip this step explicitly.
 
 #### Step 0  -  Multi-Repo Integration Build
 
@@ -57,7 +57,7 @@ Full contract: `$HOME/.claude/multi-agent-refs/multi-repo-integration-build.md`.
 4. **No match** → learn-once prompt: `[1] register host / [2] mark combo as noHost / [3] skip this run only`. Persist choice. Run immediately if host registered.
 5. **Autopilot** refuses to prompt on unknown combos  -  logs a visible skip and proceeds. Teach via a normal-mode run once.
 
-Tracker: `phase-tracker.sh sub 6 0 "Integration build" <status>`  -  visible in live tracker. Progress line `→ integrating <host-scheme> with <N> submodules`.
+Tracker: `phase-tracker.sh sub 4 0 "Integration build" <status>`  -  visible in live tracker. Progress line `→ integrating <host-scheme> with <N> submodules`.
 
 Why: codegen mismatches (nested vs flat keys, missing entries) only surface when the full dependency chain builds together. Building repos in isolation gives false confidence and produces post-merge fix PRs.
 
@@ -78,7 +78,7 @@ Branch **deterministically**, no implicit fallback. Read `agent-state.json` and
 | `instructionDriven` | `instructionFiles.commit` exists on disk | Action                              |
 | ------------------- | ---------------------------------------- | ----------------------------------- |
 | `true`              | **yes** (file readable)                  | → Instruction-driven path           |
-| `true`              | **no** (missing / unreadable)            | → **Log error, fall back to standard** + set `state.instructionDrivenFallback: true` for Phase 7 audit. Do NOT silently ignore. |
+| `true`              | **no** (missing / unreadable)            | → **Log error, fall back to standard** + set `state.instructionDrivenFallback: true` for Phase 5 audit. Do NOT silently ignore. |
 | `false`             |  -                                         | → Standard path                     |
 
 **Instruction-driven path:**
@@ -86,34 +86,34 @@ Branch **deterministically**, no implicit fallback. Read `agent-state.json` and
 1. Ask: "Want to commit?" (skip in autopilot)
 2. Read commit instruction file (e.g. `.instructions/figma/figma-iteration-commit/SKILL.md`)
 3. Follow its flow (build validation, test, submodule commits, push, PR, issue management)
-4. Log: "Phase 6: instruction-driven commit  -  file={instructionFiles.commit}"
+4. Log: "Phase 4: instruction-driven commit  -  file={instructionFiles.commit}"
 
 **Standard path (also used as fallback when instructionDriven=true but file missing):**
 
-1. **Local checkout test prompt** (skip in autopilot): If still in worktree AND Phase 5 was skipped, ask the user. Per `$HOME/.claude/multi-agent-refs/rules.md` Language Application matrix: `question`, `label` and `description` follow `outputLanguage`; only `header` stays English (<=12-char chip). Render the picker accordingly:
+1. **Local checkout test prompt** (skip in autopilot): If still in worktree AND Phase 3 was skipped, ask the user. Per `$HOME/.claude/multi-agent-refs/rules.md` Language Application matrix: `question`, `label` and `description` follow `outputLanguage`; only `header` stays English (<=12-char chip). Render the picker accordingly:
    - `question` (in `outputLanguage`)  -  semantically: "Run a quick WIP-checkout test before commit?"
    - `header` (English, ≤12 chars): `"WIP checkout"`
    - `options` (label + description both in `outputLanguage`; the semantics below, not these English strings, are what to render):
      - option 1  -  semantically "No, continue to commit" marked `(Recommended)`; description: proceed straight to commit + push + PR
      - option 2  -  semantically "Yes, WIP checkout"; description: pause so the user can checkout the branch locally and poke around
    - Default: option 1 (by index, not by label  -  the label is localized)
-   - If the user picks option 2 (WIP checkout): follow Phase 5 Steps 2-6. On `"fix:"` → Phase 3. On `"ok"` → resume Phase 6.
+   - If the user picks option 2 (WIP checkout): follow Phase 3 Steps 2-6. On `"fix:"` → Phase 2. On `"ok"` → resume Phase 4.
 2. Commit confirm prompt (skip in autopilot). Same language matrix:
    - `question` in `outputLanguage` (semantic: "Commit now?")
    - labels in `outputLanguage`, semantically "Commit" and "Pause and resume later"; branch on the option index, not on the rendered string
    - No → Pause, user can `resume` later. Yes → continue:
-3. If WIP commit exists from Phase 5 or Step 1: `git reset HEAD~1` to unstage, then re-commit properly
+3. If WIP commit exists from Phase 3 or Step 1: `git reset HEAD~1` to unstage, then re-commit properly
 4. Stage changes: `git add` with specific files (NOT `git add -A`  -  avoid sensitive files, `.worktrees/`, agent files)
 5. **Multi-submodule check**: If project has submodules (e.g. uicomponents + common):
    - Detect which submodules have changes: `git -C {worktree} diff --name-only | cut -d'/' -f1-3 | sort -u`
    - For EACH submodule with changes: stage, commit, push separately
    - Commit message uses same convention but scope reflects submodule: `{type}({submodule-scope}): {description} [{jiraId}]`
 6. Commit with convention: `{type}({scope}): {description} [{jiraId}]` or `[#{shortId}]`. **Local-only repos** (state field `projects[i].provider == "local"`) carry the same conventional prefix but drop the `[{jiraId}]` suffix  -  there is no tracker to reference. The taskId (`LOCAL-...`) goes in the commit body footer instead: `Local-Task: {taskId}`.
-7. Push to remote  -  **skip per-repo when `projects[i].provider == "local"`** (no `git push`, no upstream config). Log `Phase 6: local-only commit {sha} (no push)` for that repo.
+7. Push to remote  -  **skip per-repo when `projects[i].provider == "local"`** (no `git push`, no upstream config). Log `Phase 4: local-only commit {sha} (no push)` for that repo.
 8. Ask: "Want to open a Pull Request?"
-   - **Skip the prompt entirely when `state.offlineOnly == true`** (all repos local  -  no PR target exists). Proceed to Phase 7 with `pr.status = "skipped-offline"` for each project.
+   - **Skip the prompt entirely when `state.offlineOnly == true`** (all repos local  -  no PR target exists). Proceed to Phase 5 with `pr.status = "skipped-offline"` for each project.
    - In mixed mode (some local, some remote), only prompt for the remote-backed repos; local ones auto-skip.
-   - No -> Phase 7
+   - No -> Phase 5
    - Yes -> Create PR with technical description (see below)
 9. **Worktree finalize (gated by `settings.worktreeAutoRemoveOnPr`, default true)**: run **from the project root**  -  step 3 leaves the shell inside the worktree and the script refuses there.
 
@@ -124,11 +124,11 @@ Branch **deterministically**, no implicit fallback. Read `agent-state.json` and
      --task-id "$TASK_ID" --project "$PROJECT" --branch "$BRANCH")
    ```
 
-   The script salvages before removing, keeps the branch, and does **not** check it out  -  the user's HEAD and uncommitted work stay put. On success it stamps `worktreeRemovedAt`, `artifactsPath` and `worktreePath: null` into the **salvaged** `agent-state.json` itself. Do NOT write those via `write-state.mjs "$STATE_FILE"`: in single-repo mode that path went away with the worktree, so the write fails, the fields land nowhere, and Phase 7 reads a dead path and silently skips the triage ingest. After a removal re-point `STATE_FILE` at `$(jq -r .artifactsPath <<< "$FIN")/agent-state.json`. Exit 3 is a safe skip (uncommitted changes, unpushed or detached HEAD, `--local`, cwd inside the tree, preference off): report and continue. Never `--force`. Contract: [`features/worktree-finalize.md`]($HOME/.claude/multi-agent-refs/features/worktree-finalize.md).
+   The script salvages before removing, keeps the branch, and does **not** check it out  -  the user's HEAD and uncommitted work stay put. On success it stamps `worktreeRemovedAt`, `artifactsPath` and `worktreePath: null` into the **salvaged** `agent-state.json` itself. Do NOT write those via `write-state.mjs "$STATE_FILE"`: in single-repo mode that path went away with the worktree, so the write fails, the fields land nowhere, and Phase 5 reads a dead path and silently skips the triage ingest. After a removal re-point `STATE_FILE` at `$(jq -r .artifactsPath <<< "$FIN")/agent-state.json`. Exit 3 is a safe skip (uncommitted changes, unpushed or detached HEAD, `--local`, cwd inside the tree, preference off): report and continue. Never `--force`. Contract: [`features/worktree-finalize.md`]($HOME/.claude/multi-agent-refs/features/worktree-finalize.md).
 
 10. **Issue body update** (GitHub Issue only): if the issue body has a `### Pull Requests` section and/or a `### Progress` table, fill in the PR URL(s) (one row per submodule  -  e.g. `- **common:** {url}`, `- **uicomponents:** {url}`) and flip the Implementation / Testing / Code Connect flags from Pending to Done using whatever marker the template uses (match in place, do NOT introduce new markers). Apply with `gh issue edit {issueNo} --body "{updated body}"` and preserve every other section unchanged.
 11. **NEVER close or resolve the issue**  -  neither GitHub Issue nor Jira. Issues require team review (4 approvals) before closing. Only post a comment with commit/PR URLs.
-12. Log: "Phase 6: Commit {sha}  -  PR #{number}, worktree {removed|kept: <reason>}"
+12. Log: "Phase 4: Commit {sha}  -  PR #{number}, worktree {removed|kept: <reason>}"
 
 #### Step 2.9  -  Resolve the evidence host (UI changes only)
 
@@ -151,15 +151,15 @@ git -C "$TMP_EV" push -u origin "$EVB"
 
 Stills only. On a GitHub-hosted run no video is recorded (Step 3.55), and an mp4 behind a blob link is a download rather than something a reviewer opens. A failed push is not a phase failure: drop to `host: none` with the error as `hostReason`.
 
-Log: `Phase 6 Step 2.9: evidence host = {jira|github-public|github-private|none} ({reason})`
+Log: `Phase 4 Step 2.9: evidence host = {jira|github-public|github-private|none} ({reason})`
 
 #### Step 3  -  PR Description (technical detail for reviewers)
 
-**Section set + markup dialect: `channels/pr.md`  -  read it first.** Phase 7 channels replaces this body with that section set, so build to it. Required reading: `payload-contracts.md`.
+**Section set + markup dialect: `channels/pr.md`  -  read it first.** Phase 5 channels replaces this body with that section set, so build to it. Required reading: `payload-contracts.md`.
 
 Generate a structured PR description based on task type. The PR body targets **code reviewers**  -  it should be technical: what changed, why, architecture decisions, how to verify.
 
-Two inputs are read from state and the worktree before writing, not recalled from the conversation: `$WORKTREE/.pipeline/scope-check.json` (Phase 3 Step 3.7) supplies the `## Technical Explanation` bullets from `files[].reason` and the "Follow-ups not done in this PR" list under `## Related` from `notDone[]`; `state.diffRisk.signals` (Phase 4 Step 1.75) decides whether the conditional `## Risk and Security` section is required. When a high-stakes signal is present and the section is missing, this step blocks until it is written; a placeholder answer ("TBD") counts as missing. `state.visualEvidence.required` blocks the same way: every required artefact is either attached or carries a recorded reason in `gaps[]` - the gate is against silence, not against an honest "no image on the ticket".
+Two inputs are read from state and the worktree before writing, not recalled from the conversation: `$WORKTREE/.pipeline/scope-check.json` (Phase 2 Step 3.7) supplies the `## Technical Explanation` bullets from `files[].reason` and the "Follow-ups not done in this PR" list under `## Related` from `notDone[]`; `state.diffRisk.signals` (Phase 3 Step 1.75) decides whether the conditional `## Risk and Security` section is required. When a high-stakes signal is present and the section is missing, this step blocks until it is written; a placeholder answer ("TBD") counts as missing. `state.visualEvidence.required` blocks the same way: every required artefact is either attached or carries a recorded reason in `gaps[]` - the gate is against silence, not against an honest "no image on the ticket".
 
 **required**: Run all generated text (PR body, commit message) through the `humanizer` skill before posting. This removes AI-generated patterns (inflated language, filler phrases, repetitive structure) and makes the output sound like a developer wrote it.
 
@@ -254,7 +254,7 @@ Active when `state.projects[].length > 1`. The single-repo flow above is preserv
 
 ##### Per-repo commit (shared message, per-repo scope)
 
-For each repo in `state.projects[]` (sequentially, in dependency order from Phase 2):
+For each repo in `state.projects[]` (sequentially, in dependency order from Phase 1):
 
 1. `cd "$WT_PATH"`  -  switch into the repo's worktree.
 2. Build the commit message using the **shared subject** + **per-repo scope** rule:
@@ -291,10 +291,10 @@ For each repo (sequentially), per push attempt:
      [1] Resolve conflict manually in $WT_PATH, then resume #{taskId}
      [2] Switch to a different base branch (re-prompt baseBranch, restart push loop)
      [3] Skip this repo  -  leave commit local, mark state.projects[i].pushStatus = "skipped"
-     [4] Pause Phase 6, exit cleanly
+     [4] Pause Phase 4, exit cleanly
 ```
 
-Persist `state.projects[i].pushStatus` ∈ `"pushed" | "rebase-pushed" | "skipped" | "paused"`. A `"skipped"` repo must be reported in Phase 7 with explicit "manual push required" note.
+Persist `state.projects[i].pushStatus` ∈ `"pushed" | "rebase-pushed" | "skipped" | "paused"`. A `"skipped"` repo must be reported in Phase 5 with explicit "manual push required" note.
 
 The legacy single-repo path uses the same loop with `state.projects[].length === 0`; semantics unchanged.
 
@@ -361,7 +361,7 @@ done
 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 6 multi_repo.completed repos=$REPOS skipped=$SKIPPED
 ```
 
-**Token forwarding:** the commit-message and PR-body generators run on a model. Forward those calls into the tracker so Phase 7's Cost Breakdown captures Phase 6:
+**Token forwarding:** the commit-message and PR-body generators run on a model. Forward those calls into the tracker so Phase 5's Cost Breakdown captures Phase 4:
 
 ```bash
 LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 6 commit.message_generated \

package/pipeline/multi-agent-refs/phases/{phase-7-report.md → phase-5-report.md}

@@ -1,4 +1,4 @@
-### Phase 7: Report
+### Phase 5: Report
 
 > **TLDR**  -  Close the loop in two halves: **External delivery** delegated to `/multi-agent:channels` (multi-select kanal + content  -  always pauses in autopilot, 30-min timeout ends session). **Internal capture** stays inline: `agent-log.md` finalization, telemetry emission, knowledge base + memory update. Channels command is the single source of truth for Jira/Confluence/Wiki/PR-description delivery  -  full contract in `commands/multi-agent/channels/SKILL.md`.
 
@@ -7,32 +7,32 @@ Progress emission per `$HOME/.claude/multi-agent-refs/progress-contract.md`  -
 
 ## Sub-step Tracking (required)
 
-Phase 7 has **3 ordered sub-steps** (reduced from 5 in v5.7  -  external delivery consolidated under channels). Register all of them in the tracker at Phase 7 entry.
+Phase 5 has **3 ordered sub-steps** (reduced from 5 in v5.7  -  external delivery consolidated under channels). Register all of them in the tracker at Phase 5 entry.
 
 ```bash
-bash ~/.claude/scripts/phase-tracker.sh update 7 in_progress
+bash ~/.claude/scripts/phase-tracker.sh update 5 in_progress
 for s in 1:Channels-Dispatch 2:Log+Telemetry 3:Knowledge+Memory; do
-  bash ~/.claude/scripts/phase-tracker.sh sub 7 "${s%%:*}" "${s#*:}" pending
+  bash ~/.claude/scripts/phase-tracker.sh sub 5 "${s%%:*}" "${s#*:}" pending
 done
 ```
 
-On entry: `phase-tracker.sh sub 7 <N> "<name>" in_progress`. On exit: `completed` / `failed` / `skipped` / `timeout`.
+On entry: `phase-tracker.sh sub 5 <N> "<name>" in_progress`. On exit: `completed` / `failed` / `skipped` / `timeout`.
 
 ---
 
 ## Autopilot pause contract
 
-Phase 7 is the single exception to the autopilot zero-interaction rule: every mode, Full or Short, attended or autopilot, pauses at the channels multi-select menu. Full contract in `$HOME/.claude/multi-agent-refs/phases/modes.md`:
+Phase 5 is the single exception to the autopilot zero-interaction rule: every mode, Full or Short, attended or autopilot, pauses at the channels multi-select menu. Full contract in `$HOME/.claude/multi-agent-refs/phases/modes.md`:
 
 - **30-min timeout**  -  if user does not respond, session ends cleanly. External delivery is aborted (no silent apply of defaults  -  prevents accidental Jira comments / Confluence pages). Internal capture (Steps 2 + 3 below) STILL runs so `agent-log.md` + knowledge base are persisted.
 - **Resumable**  -  state written as `{status: "awaiting_input", phase: 7, waitingFor: "user-channels-choice", channelsInput: <state-bundle>}`. User can `/multi-agent:resume <task-id>` any time later; channels menu re-opens with same inputs.
-- **Timeout log line:** `Phase 7: channels menu timeout (30 min)  -  session ended, resume with /multi-agent:resume {taskId}`.
+- **Timeout log line:** `Phase 5: channels menu timeout (30 min)  -  session ended, resume with /multi-agent:resume {taskId}`.
 
 ---
 
 ## Step 1  -  External Delivery (delegated to channels)
 
-Phase 7 builds a state bundle and invokes `/multi-agent:channels` (Claude Code) or `multi-agent-channels` (Copilot CLI). This is the ONLY external-delivery step  -  no inline Jira/Confluence/Wiki/PR-description logic lives in Phase 7 any more.
+Phase 5 builds a state bundle and invokes `/multi-agent:channels` (Claude Code) or `multi-agent-channels` (Copilot CLI). This is the ONLY external-delivery step  -  no inline Jira/Confluence/Wiki/PR-description logic lives in Phase 5 any more.
 
 > **Local-only short-circuit**: when `state.offlineOnly == true` (all repos
 > are local  -  see Phase 0), Step 1 is **skipped entirely**. No channels menu,
@@ -79,7 +79,7 @@ Kanallar: [x] PR  [x] Jira  [ ] Confluence  [ ] Wiki
 
 Pre-ticks from `prefs.global.reportChannels` + `prefs.global.reportContent`. Greyed-out rules (pipeline context, PR linked, taskType=component, wiki.enabled) per `channels.md` Step 3.
 
-**User selects → channels dispatches → returns per-adapter results. Phase 7 records outcomes into tracker + summary block.**
+**User selects → channels dispatches → returns per-adapter results. Phase 5 records outcomes into tracker + summary block.**
 
 ### Per-adapter outcomes (from channels return)
 
@@ -92,7 +92,7 @@ Pre-ticks from `prefs.global.reportChannels` + `prefs.global.reportContent`. Gre
 }
 ```
 
-Tracker: `phase-tracker.sh sub 7 1 "Channels dispatch" completed` (or `failed` if ALL adapters failed; `skipped` if user declined all).
+Tracker: `phase-tracker.sh sub 5 1 "Channels dispatch" completed` (or `failed` if ALL adapters failed; `skipped` if user declined all).
 
 ---
 
@@ -106,15 +106,15 @@ Two paired actions, in order:
 
 ```bash
 # 1. Post the canonical comment (template per refs/channels/issue-comment.md).
-bash ~/.claude/scripts/phase-tracker.sh sub 7 1.5 "Issue comment" in_progress
+bash ~/.claude/scripts/phase-tracker.sh sub 5 1.5 "Issue comment" in_progress
 gh issue comment "$ISSUE_NUMBER" --repo "$ORG/$REPO" --body-file /tmp/channels-${TASK_ID}-issue.md
-bash ~/.claude/scripts/phase-tracker.sh sub 7 1.5 "Issue comment" completed
+bash ~/.claude/scripts/phase-tracker.sh sub 5 1.5 "Issue comment" completed
 
 # 2. Sync the Progress flag table from agent-state.json. Idempotent  -  the
 #    script no-ops if the body already matches.
-bash ~/.claude/scripts/phase-tracker.sh sub 7 1.6 "Progress flag sync" in_progress
+bash ~/.claude/scripts/phase-tracker.sh sub 5 1.6 "Progress flag sync" in_progress
 bash ~/.claude/scripts/update-issue-progress.sh "$TASK_ID"
-bash ~/.claude/scripts/phase-tracker.sh sub 7 1.6 "Progress flag sync" completed
+bash ~/.claude/scripts/phase-tracker.sh sub 5 1.6 "Progress flag sync" completed
 ```
 
 Order matters: comment first (timestamp marks the run), flags second (one logical body diff). If the comment fails, do NOT update flags  -  the channel is incomplete and the user needs to retry.
@@ -128,7 +128,7 @@ The Progress flag values come from `state.flags`:
 | `codeConnect`    | Code Connect   |
 | `wiki`           | Wiki           |
 
-Each value renders as `done` (`true`), `partial` (`"yellow"`), or `pending` (`false`/missing). Phase 3 / 5 / 6 are responsible for setting these honestly  -  Phase 7 only mirrors what's already in state.
+Each value renders as `done` (`true`), `partial` (`"yellow"`), or `pending` (`false`/missing). Phase 2 / 5 / 6 are responsible for setting these honestly  -  Phase 5 only mirrors what's already in state.
 
 **Hard rule (per `$HOME/.claude/multi-agent-refs/channels/issue-comment.md`):** never run only one of the two actions. The comment is the human-readable audit; flags are the machine-readable status. Either both or neither.
 
@@ -148,7 +148,7 @@ Write `agent-log.md` with ALL sections:
 
 Rendered via `$HOME/.claude/lib/plan-todos.sh list "$TASK_ID"`. Inline the resulting markdown checklist verbatim  -  one line per todo with status marker ([x] / [~] / [/] / [!]), ID, task text, and notes when present. Status summary one-liner ("4/6 done, 1 skipped, 1 failed") goes at the top from `plan-todos.sh status`.
 
-Skipped sections: when `planTodos.enabled` is false or no `plan.todos[]` was emitted, the Plan Todo block is omitted (no empty header). Phase 3 task-by-task progress still appears in the Timeline section either way.
+Skipped sections: when `planTodos.enabled` is false or no `plan.todos[]` was emitted, the Plan Todo block is omitted (no empty header). Phase 2 task-by-task progress still appears in the Timeline section either way.
 
 ## Timeline
 
@@ -165,7 +165,7 @@ Skipped sections: when `planTodos.enabled` is false or no `plan.todos[]` was emi
 | Iteration | Blocking | Important | Suggestion | Decision | Still present | Resolved | New |
 | --------- | -------- | --------- | ---------- | -------- | ------------- | -------- | --- |
 
-(the last three columns come from `reviewIterations[i].delta.counts` (Phase 4 Step 3.8) and read `-` on iteration 1 and on runs that predate the delta; a tripped circuit-breaker is one extra line under the table: `Circuit-breaker tripped: trigger {n}, {detail}`)
+(the last three columns come from `reviewIterations[i].delta.counts` (Phase 3 Step 3.8) and read `-` on iteration 1 and on runs that predate the delta; a tripped circuit-breaker is one extra line under the table: `Circuit-breaker tripped: trigger {n}, {detail}`)
 
 ## Files Changed
 
@@ -224,12 +224,12 @@ This is independent of the channels-side `reportContent.costSummary` (which gate
 bash $HOME/.claude/scripts/capture-flush.sh --state "$STATE_FILE"
 ```
 
-Every phase boundary already made this call (`operations.md`), so by Phase 7 it usually writes 0 rows - and that is the point. These writes used to live ONLY here, in the phase a run is least likely to reach: a run killed in Phase 3 lost every finding it had established. Phase 7 is now the last flush, not the only one.
+Every phase boundary already made this call (`operations.md`), so by Phase 5 it usually writes 0 rows - and that is the point. These writes used to live ONLY here, in the phase a run is least likely to reach: a run killed in Phase 2 lost every finding it had established. Phase 5 is now the last flush, not the only one.
 
 What it does, so this doc stays inspectable:
 
-- **Triage ingest** (`triage-memory.mjs ingest`). accepted/deferred/rejected rows into the per-repo corpus, so Phase 1 enrichment and Phase 4 prior-art recall them later. Idempotent. Reads the salvaged copy under `artifactsPath` FIRST: Phase 6 removes the worktree, and a worktree-first reader degrades silently for exactly the runs worth rescuing. JSONL at `~/.claude/memory/multi-agent/<repo-slug>/triage-corpus.jsonl`, per-repo, never cross-leaking. Off when `prefs.global.priorArtEnrichment.ingestOnComplete = false`.
-- **Ledger distill** (`learnings-ledger.mjs from-triage`). Rejected findings become durable `rejected-preference` entries so reviewers stop re-raising them. Idempotent. Safety: blocking-severity rejections are NOT distilled - a wrong rejection must never permanently suppress that class; `learnings-ledger.mjs forget` clears a stale one. JSONL beside the corpus; its brief replays into Phase 1 and Phase 4. On by default via `prefs.global.learningsLedger.enabled`.
+- **Triage ingest** (`triage-memory.mjs ingest`). accepted/deferred/rejected rows into the per-repo corpus, so Phase 1 enrichment and Phase 3 prior-art recall them later. Idempotent. Reads the salvaged copy under `artifactsPath` FIRST: Phase 4 removes the worktree, and a worktree-first reader degrades silently for exactly the runs worth rescuing. JSONL at `~/.claude/memory/multi-agent/<repo-slug>/triage-corpus.jsonl`, per-repo, never cross-leaking. Off when `prefs.global.priorArtEnrichment.ingestOnComplete = false`.
+- **Ledger distill** (`learnings-ledger.mjs from-triage`). Rejected findings become durable `rejected-preference` entries so reviewers stop re-raising them. Idempotent. Safety: blocking-severity rejections are NOT distilled - a wrong rejection must never permanently suppress that class; `learnings-ledger.mjs forget` clears a stale one. JSONL beside the corpus; its brief replays into Phase 1 and Phase 3. On by default via `prefs.global.learningsLedger.enabled`.
 
 No model runs in the flush - it derives everything from `triage-output.json` plus `agent-state.json`, which is what lets a hook call it. The model-dependent parts of this phase (Step 3 knowledge capture, memory synthesis) stay here, because a hook cannot think.
 
@@ -257,7 +257,7 @@ Commit: abc1234 | PR: #87
 Full report: $HOME/.claude/logs/multi-agent/{project}/{task-id}/agent-log.md
 ```
 
-Tracker: `phase-tracker.sh sub 7 2 "Log+Telemetry" completed`.
+Tracker: `phase-tracker.sh sub 5 2 "Log+Telemetry" completed`.
 
 ## Step 3  -  Knowledge Capture (incremental learning)
 
@@ -266,9 +266,9 @@ Extract reusable knowledge from this task and **append** to `$HOME/.claude/knowl
 | File              | What to Add                                     | Source                            |
 | ----------------- | ----------------------------------------------- | --------------------------------- |
 | `architecture.md` | Newly discovered modules, relationships, deps   | Phase 1 Explore                   |
-| `patterns.md`     | Conventions, naming, recurring structures       | Phase 1 + Phase 4                 |
-| `gotchas.md`      | Build errors/solutions, edge cases, workarounds | Phase 3 retries, Phase 4 blocking |
-| `decisions.md`    | Architectural decisions + rationale             | Phase 2 plan + Phase 4            |
+| `patterns.md`     | Conventions, naming, recurring structures       | Phase 1 + Phase 3                 |
+| `gotchas.md`      | Build errors/solutions, edge cases, workarounds | Phase 2 retries, Phase 3 blocking |
+| `decisions.md`    | Architectural decisions + rationale             | Phase 1 plan + Phase 3            |
 
 **Rules:** Only save reusable knowledge (task-specific details stay in agent-log). Read existing files before appending  -  no duplicates. Add date: `<!-- captured: {date}, task: {jiraId} -->`. Conflicting info → update old entry, don't delete.
 
@@ -286,7 +286,7 @@ Extract reusable knowledge from this task and **append** to `$HOME/.claude/knowl
 
 **Code graph refresh:** when `prefs.global.codeGraph.enabled` and `prefs.global.codeGraph.autoRefresh` are both true, rebuild the graph and re-render `GRAPH_REPORT.md`  -  the branch just changed the code the Phase 1 graph described. Costs no API tokens, never fails the run. Commands: `$HOME/.claude/multi-agent-refs/features/code-graph.md`.
 
-**Save preferences**: Update prefs with Phase 7 selections (via channels return: `reportChannels`, `reportContent`, `confluenceUrls` per-project LRU).
+**Save preferences**: Update prefs with Phase 5 selections (via channels return: `reportChannels`, `reportContent`, `confluenceUrls` per-project LRU).
 
 **Per-repo memory synthesis (opt-in via `prefs.global.perRepoMemory`):**
 
@@ -310,9 +310,9 @@ done
 
 Zero new memories is normal and expected. A typical run produces one or none.
 
-Tracker: `phase-tracker.sh sub 7 3 "Knowledge+Memory" completed`.
+Tracker: `phase-tracker.sh sub 5 3 "Knowledge+Memory" completed`.
 
-Log: "Phase 7: Knowledge captured ({N} entries to {files})"
+Log: "Phase 5: Knowledge captured ({N} entries to {files})"
 
 ---
 
@@ -321,7 +321,7 @@ Log: "Phase 7: Knowledge captured ({N} entries to {files})"
 If user does not respond at the channels multi-select menu within 30 minutes (wall clock from menu render):
 
 1. Channels command aborts its interactive prompt, returns `{status: "timeout"}`.
-2. Phase 7 records `phase-tracker.sh sub 7 1 "Channels dispatch" timeout`.
+2. Phase 5 records `phase-tracker.sh sub 5 1 "Channels dispatch" timeout`.
 3. **Internal capture still runs**  -  Steps 2 + 3 write `agent-log.md` (with `channels: timeout` in summary), emit telemetry, update knowledge base.
 4. Session exits cleanly. State persisted: `state.currentPhase=7, state.waitingFor="user-channels-choice", state.channelsTimeout=true`.
 5. Resume contract: `/multi-agent:resume <task-id>` re-opens the channels menu with the original state bundle (pipeline log, PR metadata, prefs pre-ticks).
@@ -332,7 +332,7 @@ Rationale: silently posting defaults to Jira / Confluence after a timeout would
 
 #### Output Quality + Metrics Section
 
-Append to every Phase 7 report (knowledge-capture pass) a **Quality & Metrics** block built from `metrics.jsonl` and the latest task's artifacts:
+Append to every Phase 5 report (knowledge-capture pass) a **Quality & Metrics** block built from `metrics.jsonl` and the latest task's artifacts:
 
 ```
 ## Quality & Metrics

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

@@ -18,20 +18,18 @@
 | Modes (depth picker, autopilot, --local) | `$HOME/.claude/multi-agent-refs/phases/modes.md`            |
 | Operations (kill, purge, resume)  | `$HOME/.claude/multi-agent-refs/phases/operations.md`       |
 | Phase 0: Init                     | `$HOME/.claude/multi-agent-refs/phases/phase-0-init.md`     |
-| Phase 1: Analysis                 | `$HOME/.claude/multi-agent-refs/phases/phase-1-analysis.md` |
-| Phase 2: Planning                 | `$HOME/.claude/multi-agent-refs/phases/phase-2-planning.md` |
-| Phase 3: Dev              | `$HOME/.claude/multi-agent-refs/phases/phase-3-dev.md`      |
-| Phase 4: Review                   | `$HOME/.claude/multi-agent-refs/phases/phase-4-review.md`   |
-| Phase 5: Test                | `$HOME/.claude/multi-agent-refs/phases/phase-5-test.md`     |
-| Phase 6: Commit & PR              | `$HOME/.claude/multi-agent-refs/phases/phase-6-commit.md`   |
-| Phase 7: Report                  | `$HOME/.claude/multi-agent-refs/phases/phase-7-report.md`  |
+| Phase 1: Plan                     | `$HOME/.claude/multi-agent-refs/phases/phase-1-plan.md`     |
+| Phase 2: Dev                      | `$HOME/.claude/multi-agent-refs/phases/phase-2-dev.md`      |
+| Phase 3: Review                   | `$HOME/.claude/multi-agent-refs/phases/phase-3-review.md`   |
+| Phase 4: Commit & PR              | `$HOME/.claude/multi-agent-refs/phases/phase-4-commit.md`   |
+| Phase 5: Report                   | `$HOME/.claude/multi-agent-refs/phases/phase-5-report.md`   |
 | Log format                        | `$HOME/.claude/multi-agent-refs/phases/log-format.md`       |
 
 ## Pipeline Flow
 
 ```
-Full:      0-Init -> 1-Analysis -> 2-Planning -> 3-Dev -> 4-Review -> 5-Test -> 6-Commit -> 7-Report
-Short:     0-Init -> (1,2 skipped) --------------> 3-Dev -> 4-Review -> 5-Test -> 6-Commit -> 7-Report
+Full:      0-Init -> 1-Plan -> 2-Dev -> 3-Review -> 4-Commit -> 5-Report
+Short:     0-Init -> (1 skipped) -> 2-Dev -> 3-Review -> 4-Commit -> 5-Report
 --local:   Either of the above with no worktree  -  works directly on a local branch
 
 Full or Short is the Phase 0 Step 7.5 question, not a command name. Autopilot never asks and always runs Full.
@@ -94,7 +92,7 @@ Phase 0 MUST initialize the tracker and register the active mode's phase set:
 
 ```bash
 $HOME/.claude/scripts/phase-tracker.sh init "$TASK_ID"
-for p in 0:Init 1:Analysis 2:Planning 3:Dev 4:Review 5:Test 6:Commit 7:Report; do
+for p in 0:Init 1:Plan 2:Dev 3:Review 4:Commit 5:Report; do
   $HOME/.claude/scripts/phase-tracker.sh add "${p%%:*}" "${p#*:}"
 done
 ```
@@ -125,7 +123,7 @@ After every LLM call (counts are additive; skipping this is why runs end with du
 $HOME/.claude/scripts/phase-tracker.sh tokens <N> <in> <out> [cached]
 ```
 
-For sub-phase progress (e.g. Phase 1's parallel Explore agents, Phase 4's reviewer dispatch + triage + validator gate, Phase 6's commit + push + PR sub-steps):
+For sub-phase progress (e.g. Phase 1's parallel Explore agents, Phase 3's reviewer dispatch + triage + validator gate, Phase 4's commit + push + PR sub-steps):
 
 ```bash
 $HOME/.claude/scripts/phase-tracker.sh sub <N> 1 "<sub name>" pending      # register
@@ -149,7 +147,7 @@ Banner status enum on `end`: `done` | `failed` | `skipped`. Anything else exits
 
 ### TaskCreate registration (Claude Code  -  required)
 
-In Claude Code the agent MUST register one TaskCreate tile per phase at Phase 0 startup (one per phase the current COMMAND runs  -  `/multi-agent` = 0..7, `:local` and the autopilot entries = 0/1/2/3/4/6/7, `:analysis` = 0/1/2/4/6/7). Capture the returned `taskId`, persist it via `phase-tracker.sh meta <N> tasklist_id "<taskId>"` so `:resume` can rebuild the widget.
+In Claude Code the agent MUST register one TaskCreate tile per phase at Phase 0 startup (one per phase the current COMMAND runs  -  `/multi-agent` = 0..5, `:local` and the autopilot entries = 0..5, `:analysis` = 0/1/3/4/5). Capture the returned `taskId`, persist it via `phase-tracker.sh meta <N> tasklist_id "<taskId>"` so `:resume` can rebuild the widget.
 
 Per phase boundary:
 
@@ -167,9 +165,9 @@ TaskUpdate({ taskId: <saved>, status: "completed" })
 bash phase-tracker.sh update <N> completed
 ```
 
-A phase outside the command's set gets no TaskCreate at all. Depth is different: it is not known at registration time, because the tracker boots at Step -1 and the depth question runs at Step 7.5. So registration splits - Phase 0 alone at Step -1, the rest at Step 7.5 once the answer says which phases the run has. A Short run never draws an Analysis tile it will not use. Registering all eight and flipping 1 and 2 to `skipped` is what this replaced, in v17.5.0: it put an eight-tile widget on screen beside the question asking whether to run two of them  -  see the ordering rule below.
+A phase outside the command's set gets no TaskCreate at all. Depth is different: it is not known at registration time, because the tracker boots at Step -1 and the depth question runs at Step 7.5. So registration splits - Phase 0 alone at Step -1, the rest at Step 7.5 once the answer says which phases the run has. A Short run never draws a Plan tile it will not use. Registering every phase and flipping the skipped one to `skipped` is what this replaced, in v17.5.0: it put a full-width widget on screen beside the question asking whether to run part of it  -  see the ordering rule below.
 
-**(strict) TaskCreate ordering**: All TaskCreate calls MUST fire in strict phase-number order BEFORE any TaskUpdate is applied. The native widget renders by creation order, not by phase number  -  out-of-order calls produce visually scrambled tile stacks (e.g. `1 ✓ · 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 with default `pending` status, then flip status via TaskUpdate when the phase actually short-circuits. Full contract in `$HOME/.claude/multi-agent-refs/tracker-contract.md` section "TaskCreate ordering (strict)".
+**(strict) TaskCreate ordering**: All TaskCreate calls MUST fire in strict phase-number order BEFORE any TaskUpdate is applied. The native widget renders by creation order, not by phase number  -  out-of-order calls produce visually scrambled tile stacks (e.g. `1 ✓ · 3 ✓ · 4 ✓ · 0 ▶ · 2 ☐`) even when the underlying state is correct. Pre-marking phases as completed/skipped before Phase 0 starts is FORBIDDEN  -  register the tile in order with default `pending` status, then flip status via TaskUpdate when the phase actually short-circuits. Full contract in `$HOME/.claude/multi-agent-refs/tracker-contract.md` section "TaskCreate ordering (strict)".
 
 **Copilot CLI / plain shell**: do NOT call TaskCreate  -  the tool does not exist on these CLIs. Instead, after every state update, call `bash phase-tracker.sh render` so the bordered ANSI card prints as the last tool result. That's the equivalent visual signal there.
 
@@ -197,55 +195,53 @@ For operations (status, kill, resume, purge): read operations.md.
 
 Each phase doc is lazy-loaded  -  only the current phase's spec is in context. Budget enforced by `smoke-token-budget.sh`.
 
-| Phase       | File                | Max Tokens | Warn  |
-| ----------- | ------------------- | ---------- | ----- |
-| 0: Init     | phase-0-init.md     | 4,000      | 3,500 |
-| 1: Analysis | phase-1-analysis.md | 1,500      | 1,200 |
-| 2: Planning | phase-2-planning.md | 1,000      | 800   |
-| 3: Dev      | phase-3-dev.md      | 1,800      | 1,500 |
-| 4: Review   | phase-4-review.md   | 2,200      | 1,800 |
-| 5: Test     | phase-5-test.md     | 800        | 600   |
-| 6: Commit   | phase-6-commit.md   | 2,800      | 2,400 |
-| 7: Report  | phase-7-report.md  | 3,200      | 2,700 |
-| **Total**   |                     | **17,000** |       |
+The live ceilings are in the repo's `schemas/token-budget.json`, derived from
+its `schemas/phases.json`. **They are deliberately not repeated here.**
 
-Token estimate: `ceil(chars / 4)`. Budget covers phase-\*.md files only. Guides, rules, and agents are loaded separately on demand.
+A table of the same numbers stood in this spot for most of the project's life and
+said the total was 17,000 tokens. The file the gate actually reads said 63,150.
+Nothing compared the two, so the copy drifted by a factor of four and stayed
+wrong through every release. A second copy of an enforced number is not
+documentation; it is a claim with no gate behind it.
+
+Token estimate: `ceil(chars / 4)`. The budget covers `phase-*.md` files only.
+Guides, rules, and agents are loaded separately on demand. The repo's
+token-budget gate prints each doc's measurement next to its ceiling, which a
+table here could never do  -  that is where to look for a current number.
 
 **Prompt caching (token learning-curve):** assemble each phase prompt as a stable, cacheable prefix (phase instructions + repo learnings brief + conventions + repo evidence) followed by the volatile task suffix, so repeated runs on a known repo pay cache-read price on the prefix. Full contract: `$HOME/.claude/multi-agent-refs/prompt-assembly.md`. The effect (rising cache ratio, falling tokens/task) is what `learning-curve.mjs` trends.
 
 ## SubPhase Convention
 
-When a specialized skill takes over a main pipeline phase, progress is reported as **SubPhases** nested under the parent. Top-level stays 8 phases (0-7); specialized flows get sub-phase detail.
+When a specialized skill takes over a main pipeline phase, progress is reported as **SubPhases** nested under the parent. Top-level stays 6 phases (0-5); specialized flows get sub-phase detail.
 
 **Visual example:**
 
 ```
 ■ Phase 0: Init              completed
-■ Phase 1: Analysis          completed
-■ Phase 2: Planning          completed
-* Phase 3: Dev (figma)       in progress
-  ■ SubPhase 3.0: Init            completed
-  ■ SubPhase 3.1: Gather          completed
-  ■ SubPhase 3.4A: Configuration  completed
-  ■ SubPhase 3.4B: View           completed
-  * SubPhase 3.4F: Wiki           writing wiki pages...
-  □ SubPhase 3.5A: ViewInspector  pending
-  □ SubPhase 3.6: Code Connect    pending
-  □ SubPhase 3.7: Issue Update    pending
-□ Phase 4: Review            pending
-□ Phase 5: Test              pending
-□ Phase 6: Commit            pending
-□ Phase 7: Report           pending
-  □ SubPhase 7.1: Jira comment      pending
-  □ SubPhase 7.2: Wiki + screenshots pending
-  □ SubPhase 7.3: Confluence        pending
-  □ SubPhase 7.4: Report + log      pending
-  □ SubPhase 7.5: Knowledge capture pending
+■ Phase 1: Plan              completed
+* Phase 2: Dev (figma)       in progress
+  ■ SubPhase 2.0: Init            completed
+  ■ SubPhase 2.1: Gather          completed
+  ■ SubPhase 2.4A: Configuration  completed
+  ■ SubPhase 2.4B: View           completed
+  * SubPhase 2.4F: Wiki           writing wiki pages...
+  □ SubPhase 2.5A: ViewInspector  pending
+  □ SubPhase 2.6: Code Connect    pending
+  □ SubPhase 2.7: Issue Update    pending
+□ Phase 3: Review            pending
+□ Phase 4: Commit            pending
+□ Phase 5: Report            pending
+  □ SubPhase 5.1: Jira comment      pending
+  □ SubPhase 5.2: Wiki + screenshots pending
+  □ SubPhase 5.3: Confluence        pending
+  □ SubPhase 5.4: Report + log      pending
+  □ SubPhase 5.5: Knowledge capture pending
 ```
 
 **TaskCreate pattern:** Parent phase + SubPhases linked via `addBlockedBy`. SubPhases block parent from completing.
 
 **Why SubPhases, not separate phases:**
 
-- Main pipeline stays a fixed 8-phase contract (0-7) regardless of task type. Wiki, Confluence, and Figma screenshots all live as SubPhases under Phase 7 Report  -  external delivery grouped logically, internal report + knowledge after.
+- Main pipeline stays a fixed 6-phase contract (0-5) regardless of task type. Wiki, Confluence, and Figma screenshots all live as SubPhases under Phase 5 Report  -  external delivery grouped logically, internal report + knowledge after.
 - Conditional phases are a code smell  -  they force every reader to learn which phase runs when.

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

@@ -160,6 +160,6 @@ asked anything, so the only thing that keeps it accountable is being readable af
 
 ## Deterministic gates note
 
-Claude Code's `PreToolUse` exit-2 hooks are the HARD blocking gates. Three ship, none needing run-specific arguments so they are naturally hookable: (1) `pre-commit-check.sh` scans the staged diff on every `git commit` and blocks on a detected secret; (2) `agent-guard.sh` runs on `git commit` + `git push` and blocks AI/assistant attribution in a commit message and force-push to a protected branch (main/master/develop); (3) `check-read-size.sh` runs on `Read` and on the shell commands that read a file whole, and routes an oversized read to a cheap worker (`bulk-read.sh`) instead of the caller's own rung. The first two inspect what a run WRITES; the third inspects what it pays to READ, and it is inert until `bulkRead.mode` is set to `observe` or `enforce`, so merging the block changes nothing until the user opts in. Its `observe` mode blocks nothing and only logs, which is how the baseline is measured before anything is routed. All three are self-contained, fail-open on internal error, and never execute the inspected command. Three capture hooks ship in the same block and block nothing: `SessionEnd` runs `capture-flush.sh --if-stale` (writing a killed run's findings into the per-repo stores, since every durable write used to live in Phase 7 - the phase a run is least likely to reach) plus `note-session.sh` (the mechanical shape of a non-pipeline session: tools used, commands that failed, calls the user refused - never an argument, never any output), `PreCompact` runs `capture-flush.sh` without `--if-stale` (a compaction summarizes a long phase mid-flight, so it is the moment unflushed findings are at risk; the staleness test exists only so a session exit does not re-flush a finished run, and both store writes are idempotent), and `SessionStart` runs `capture-resume.sh`, at most two lines about an unfinished run and a stale observation queue. None of them calls a model; all exit 0 on every path. The recommended hook block ships at `install/templates/claude-hooks.json`; `multi-agent:setup` offers to merge it into `~/.claude/settings.json`. The other deterministic gates (evidence, consensus, intent, learnings) are invoked by the pipeline phases with per-run arguments (a build-log path, the triage JSON, the free-text input), so they are phase-enforced by contract, not OS-hookable.
+Claude Code's `PreToolUse` exit-2 hooks are the HARD blocking gates. Three ship, none needing run-specific arguments so they are naturally hookable: (1) `pre-commit-check.sh` scans the staged diff on every `git commit` and blocks on a detected secret; (2) `agent-guard.sh` runs on `git commit` + `git push` and blocks AI/assistant attribution in a commit message and force-push to a protected branch (main/master/develop); (3) `check-read-size.sh` runs on `Read` and on the shell commands that read a file whole, and routes an oversized read to a cheap worker (`bulk-read.sh`) instead of the caller's own rung. The first two inspect what a run WRITES; the third inspects what it pays to READ, and it is inert until `bulkRead.mode` is set to `observe` or `enforce`, so merging the block changes nothing until the user opts in. Its `observe` mode blocks nothing and only logs, which is how the baseline is measured before anything is routed. All three are self-contained, fail-open on internal error, and never execute the inspected command. Three capture hooks ship in the same block and block nothing: `SessionEnd` runs `capture-flush.sh --if-stale` (writing a killed run's findings into the per-repo stores, since every durable write used to live in Phase 5 - the phase a run is least likely to reach) plus `note-session.sh` (the mechanical shape of a non-pipeline session: tools used, commands that failed, calls the user refused - never an argument, never any output), `PreCompact` runs `capture-flush.sh` without `--if-stale` (a compaction summarizes a long phase mid-flight, so it is the moment unflushed findings are at risk; the staleness test exists only so a session exit does not re-flush a finished run, and both store writes are idempotent), and `SessionStart` runs `capture-resume.sh`, at most two lines about an unfinished run and a stale observation queue. None of them calls a model; all exit 0 on every path. The recommended hook block ships at `install/templates/claude-hooks.json`; `multi-agent:setup` offers to merge it into `~/.claude/settings.json`. The other deterministic gates (evidence, consensus, intent, learnings) are invoked by the pipeline phases with per-run arguments (a build-log path, the triage JSON, the free-text input), so they are phase-enforced by contract, not OS-hookable.
 
 Copilot CLI has no `PreToolUse` equivalent, so the secret scan there is workflow-enforced (run as a phase step, not OS-blocked) plus a CI smoke-gate step.

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

@@ -12,13 +12,13 @@
 
 > **TLDR**  -  Every non-trivial pipeline action emits an inline "I'm doing X right now" line so the user always knows what's happening. Immediate flush, no batching. One line per action, standard shape. Autopilot prefers verbose. Low overhead. Mirrored in telemetry as `progress.step` events.
 
-This contract is consumed by every phase (0-7) and every dispatched sub-skill (including the marketplace component toolkits when enabled). It is enforced by `smoke-progress-contract.sh`  -  any phase doc that drops the contract marker or diverges from the line shape fails CI.
+This contract is consumed by every phase (0-5) and every dispatched sub-skill (including the marketplace component toolkits when enabled). It is enforced by `smoke-progress-contract.sh`  -  any phase doc that drops the contract marker or diverges from the line shape fails CI.
 
 ---
 
 ## Why
 
-Today pipeline users see a phase banner (`→ Phase 3: Dev`) and then silence for 30 s-3 min while subagents churn. Users lose trust, hit ⌃C, or retry identical work. A single-line "current action" fixes it without adding noise: you see exactly what is happening, where, and for how long.
+Today pipeline users see a phase banner (`→ Phase 2: Dev`) and then silence for 30 s-3 min while subagents churn. Users lose trust, hit ⌃C, or retry identical work. A single-line "current action" fixes it without adding noise: you see exactly what is happening, where, and for how long.
 
 ## Line shape
 
@@ -88,10 +88,10 @@ Emit a progress line **at least** at every one of these moments:
 ### Phase 5 (User Test)
 - local-test prompt render; user-answer capture; if local-test selected: repo checkout, build instructions print.
 
-### Phase 6 (Commit & PR)
+### Phase 4 (Commit & PR)
 - squash per repo, commit per repo, push per repo (each retry attempt), PR body generate (humanizer call), PR create per repo, Jira comment post.
 
-### Phase 7 (Report)
+### Phase 5 (Report)
 - humanizer summary, wiki write (if enabled), Jira comment post (if enabled), Confluence publish (if enabled), metrics rollup, summary render.
 
 ### Sync / Setup / Utility commands
@@ -122,7 +122,7 @@ Every emitted progress line also writes one `metrics.jsonl` event:
   "ts": "2026-04-16T17:22:04Z",
   "event": "progress.step",
   "taskId": "T-0042",
-  "phase": "phase-3-dev",
+  "phase": "phase-2-dev",
   "step": "run-test RED",
   "ms": 2318,
   "ok": true
@@ -145,7 +145,7 @@ LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" <
 
 `LOG_METRIC_FORWARD_TO_TRACKER=1` mirrors the same `tokens_in` / `tokens_out` / `model` into `phase-tracker.sh` so the JSONL metrics line and the tracker's per-phase accumulator stay in sync from one call site. The forward path is best-effort  -  if the tracker is missing or its file is unwritable, the JSONL write still succeeds. Without the flag the line is purely analytic and the cost block stays empty for that phase.
 
-This contract is enforced by `smoke-agent-log-cost.sh` (forwarder unit test) and `smoke-tracker-contract.sh` (Phase 4 reviewer/triage emission).
+This contract is enforced by `smoke-agent-log-cost.sh` (forwarder unit test) and `smoke-tracker-contract.sh` (Phase 3 reviewer/triage emission).
 
 ### Cost budget gate (v9.2+)
 

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

@@ -61,7 +61,7 @@ Provider dispatch:
 - **Jira** (`review-jira`): convert markdown to wiki markup, then post it with
   `bash "$HOME/.claude/lib/jira-publish.sh" --issue "$KEY" --body-file "$F" --target comment`,
   per `channels/jira.md` - that file owns the Jira posting contract and this is
-  the same write path a Phase 7 report takes.
+  the same write path a Phase 5 report takes.
   That script escapes the body and resolves the token itself; do not build the
   `curl`. A readiness comment quotes the ticket's own text back at it, so it is
   the body most likely to contain a `:)` sequence Jira would render as a smiley.