@mmerterden/multi-agent-pipeline 20.23.1 → 20.24.0

package/pipeline/multi-agent-refs/features/analysis-jira.md

@@ -10,6 +10,7 @@
 - [The story body is document text, escaped](#the-story-body-is-document-text-escaped)
 - [An existing epic, linked the way the site links](#an-existing-epic-linked-the-way-the-site-links)
 - [Channel clones are opt-in](#channel-clones-are-opt-in)
+- [Story dependencies come from the document](#story-dependencies-come-from-the-document)
 - [The document lists its tickets](#the-document-lists-its-tickets)
 - [Every site-specific name is a VALUE, never a schema key](#every-site-specific-name-is-a-value-never-a-schema-key)
 - [Auth](#auth)
@@ -122,6 +123,9 @@ Each part sits in a coloured wiki panel with its `h3.` heading first: the user
 story in `{panel:borderColor=#d4d39e}`, the acceptance criteria in
 `{panel:borderColor=#d4a19e}`, current vs target and links in
 `{panel:borderColor=#9eb6d4}`. The `Sources:` line stays outside the panels.
+`issueTree.storyPanels` replaces any of the three colours (`story`, `criteria`,
+`other`), or turns the panels off with `false`; `/multi-agent:create-jira`
+reads the same setting.
 
 At most 8 criteria. What is missing stays missing and becomes a body warning
 (no user story, fewer than 2 criteria, no negative criterion); nothing is filled
@@ -149,6 +153,46 @@ gets one clone per channel: its own label (the story's identity plus
 the label search, and a link is checked before it is sent, so a re-run doubles
 neither.
 
+## Story dependencies come from the document
+
+A requirement row may carry `Depends on: <ids>` (an extra trailing column, or
+appended to any cell of that row): `| BR-pay-01 | ... | Depends on: BR-cart-01 |`.
+The row's own id is the dependent, the ids after the clause its prerequisites.
+The clause is machine syntax, so it stays English in a Turkish document, as
+`THE SYSTEM SHALL` and Given/When/Then do. Only clauses inside a table row are
+read, and a clause naming no requirement id is left as prose.
+
+The planner reads the clauses first and removes them before it looks for ids,
+because an id is defined by where it appears: a reference left in place would
+define the id it points at, and a dependency on a requirement nobody wrote would
+plan a story for it instead of being reported.
+
+| Clause | Plan |
+|---|---|
+| both ids in one story | no edge |
+| ids in two stories | the dependent story's `dependsOn` gets the prerequisite's label, and `dependencies.edges[]` names the pair of ids behind it |
+| prerequisite id in no story | `dependencies.missing[]`, coverage `incomplete` |
+| stories that wait for each other | `dependencies.cycles[]`, one per strongly connected component (from `lib/task-graph.mjs`); every edge inside one gets `onCycle: true`; coverage `incomplete` |
+
+The preview prints each edge, its requirement pair and each cycle
+prerequisite first, and the problems under the
+coverage line, as `coverage.dependencyProblems`; an incomplete verdict they
+cause carries them in `coverage.reason`. Its heading counts issues and links
+apart (`N issue(s) and M link(s)`); `writeCount` is their sum, without the
+edges on a cycle. A document with no clause plans
+exactly as it did before: no `dependsOn`, no `dependencies`, and
+`prefsUsed.dependencyLinkType` only when the site set it.
+
+The writer links the stories after all of them have keys, one link per edge, of
+`issueTree.dependencyLinkType` (default `Blocks`). The prerequisite is the
+link's source - the POST's `inwardIssue` - so the site reads "prerequisite
+blocks dependent" and lists the link on the prerequisite under `outwardIssue`.
+That entry, same type and same direction, is what the writer checks for before
+sending, so a re-run adds nothing; a link of another type between the same two
+stories does not count. A written link is a `dependency` line in the ledger
+(the dependent's label, the prerequisite's key). An edge with `onCycle` is not
+linked, and the writer says so.
+
 ## The document lists its tickets
 
 After the write, `analysis-tickets-writeback.mjs` puts a `## Tickets` table at
@@ -169,7 +213,11 @@ are values the site fills in:
   channel, the value is the site's own name for it
 - `subtaskRoles` ships **empty**. An empty list is an instruction to look at how
   this board actually splits work; a ready-made list would be the guess most
-  worth avoiding
+  worth avoiding. An attended run asks once, offering the site's own sub-task
+  types (`analysis-jira-write.sh --subtask-types`), and saves the answer
+  (`analysis-story-tree.mjs --save-subtasks`): each chosen type becomes a role
+  mapped to itself, and "no sub-tasks" sets `subtaskRolesDeclined`
+- `cloneLinkType` and `dependencyLinkType` are the site's own link type names
 - `epicLinkFieldId`, when set, is the site's own field id; otherwise it is
   discovered
 - `subtaskIssueType: null` means discover it - `createmeta` returns whichever
@@ -178,8 +226,8 @@ are values the site fills in:
   Center 9 answers, then the classic form). Same rule as
   `features/jira-context.md`: the type travels as it comes from Jira and is
   never a matching criterion in code
-- a site with several sub-task types (Analysis Task, Development Task, Test
-  Task) names them per role: `subtaskIssueType` as a map from a `subtaskRoles`
+- a site with several sub-task types (research, build and QA sub-tasks)
+  names them per role: `subtaskIssueType` as a map from a `subtaskRoles`
   entry to the type, `"*"` for any other role. Without one the first discovered
   type is used and the run prints the types it found
 

package/pipeline/multi-agent-refs/features/autopilot-decisions.md

@@ -0,0 +1,34 @@
+# Feature: Decisions made on your behalf (autopilot)
+
+**Pattern**: an attended run asks; an autopilot run answers its own questions. Every such answer is one entry in `state.decisions[]`, so whoever reads the PR or the Phase 5 report sees each place the run chose for them, why, and what it costs if the choice was wrong:
+
+```json
+{ "what": "Took the default base branch develop", "why": "no remembered branch inside the TTL",
+  "costIfWrong": "the PR targets the wrong base and is retargeted", "at": "<ISO-8601>", "phase": 0 }
+```
+
+Written only while the quality gates are active (`lib/unattended.mjs` `gatesActive`: autopilot, or `MULTI_AGENT_UNATTENDED=1`). In an attended run the person answered, so nothing is recorded. Shape and rendering: `lib/decisions.mjs`; schema: `agent-state.schema.json` `decisions`.
+
+## Writers
+
+| Decision | Written by |
+|---|---|
+| Park (`awaiting-answer`, `verification-failed`) | `gate-ledger.mjs park`, in the same locked write as the park |
+| Blocker lowered to important (waived finding) | `review-decision-gate.mjs`, one entry per downgrade |
+| Rework dispatched one rung up | `rework-escalation.mjs --state` (`features/rework-escalation.md`) |
+| Picker resolved without asking (`remembered` / `default` / `derived`) | the picker step, through `decisions-log.mjs add` (`picker-contract.md`) |
+| Split / unverified consensus taken on the triage verdict | Phase 3 Step 4, through `decisions-log.mjs add` |
+| Date-gate model fallback taken without the question | Phase 0 Step 0, through `decisions-log.mjs add` (`features/model-fallback.md`) |
+
+```bash
+node $HOME/.claude/scripts/decisions-log.mjs add --state "$STATE_FILE" --phase <0-5> \
+  --what "<what was chosen>" --why "<the rule or evidence that chose it>" \
+  --cost-if-wrong "<what a person has to undo if it was the wrong call>"
+```
+
+Exit 0 written or skipped (attended), 2 a missing field, 3 no state. A failed add never stops the run; log `decisions.add_failed`.
+
+## Where it is shown
+
+- **Phase 5 report**: `decisions-log.mjs render --state "$STATE_FILE"` inlined verbatim in `agent-log.md`. It prints its own `## Decisions made on your behalf` heading, and nothing at all for an empty list.
+- **Autopilot PR body**: `autopilot-publish.mjs` appends the same section to the run's PR body before the outbound gate checks the title and body. The entries are passed through `lib/redact.mjs` when rendered, so a credential that reached a gate reason is replaced rather than published; the outbound gate still refuses a body that carries one anywhere else. A body that already holds the heading is not given a second one, and the section is trimmed to the 65536-character body limit with a pointer to the run report.

package/pipeline/multi-agent-refs/features/model-fallback.md

@@ -174,7 +174,8 @@ prints it once instead:
    `WARN: premium tier plan window ended <date>; preferredModel personas will dispatch on <fallbackModel>. Set prefs.global.modelFallback.premiumTierUntil to null to keep the top tier on usage credits.`
    Then export the override for every `preferredModel` persona this run. Interactive modes
    may instead ask once (`Keep top tier (usage credits) / Fall back to <model>`);
-   autopilot never asks - it falls back and logs.
+   autopilot never asks - it falls back, logs, and lists the fallback in `state.decisions[]`
+   (`features/autopilot-decisions.md`).
 2. **Dispatch error (per dispatch).** On a model-unavailable / quota error from a
    top-tier dispatch and `onDispatchError: true`: retry the same persona once with
    `PHASE_MODEL_OVERRIDE=<fallbackModel>`. If that retry also fails with a dispatch
@@ -244,7 +245,8 @@ better internals.
 ## Non-goals
 
 - No automatic re-upgrade mid-run (a run that fell back stays fallen back -
-  deterministic over clever).
+  deterministic over clever). Rework escalation (`features/rework-escalation.md`)
+  moves one rework dispatch up a rung and refuses to on a run that fell back.
 - No edits to `pipeline/agents/*.md` at runtime; frontmatter is install-time
   configuration only.
 - Copilot CLI reviewer set is out of scope: Copilot CLI pins its own three

package/pipeline/multi-agent-refs/features/mutation-probe.md

@@ -0,0 +1,58 @@
+# Mutation probe (Phase 3 Step 1.763, opt-in)
+
+A passing suite says the changed code runs, not that a test checks what it
+decides. `mutation-probe.mjs` inverts a few changed lines one at a time and
+reruns the tests; a mutant that still passes marks a line no test pins down.
+
+Runs only when `prefs.global.mutationProbe.enabled` is true, and only when the
+stack adapter names a test command.
+
+```bash
+MP_FILE="$WORKTREE/.pipeline/mutation-probe-$ITERATION.json"
+STACK=$(node $HOME/.claude/scripts/_stack-adapter.mjs resolve --dir "$WORKTREE" | cut -d' ' -f1)
+TEST_CMD=$(node $HOME/.claude/scripts/_stack-adapter.mjs command --dir "$WORKTREE" --stack "$STACK" --kind test)
+[ -n "$TEST_CMD" ] && node $HOME/.claude/scripts/mutation-probe.mjs --repo "$WORKTREE" \
+  --base "origin/$BASE_BRANCH" --head worktree --test-cmd "$TEST_CMD" --out "$MP_FILE"
+```
+
+`--max-mutants` and `--timeout-sec` default to `mutationProbe.maxMutants` (5)
+and `mutationProbe.timeoutSec` (120 per test run). Each mutant costs one full
+test run, so the bound is the cost bound.
+
+## Mutations
+
+Textual, single-site, and only on lines the diff added or changed (test files
+excluded). The operator needs whitespace on both sides, so generics, arrows and
+unary signs are left alone; comment lines and string contents are skipped.
+
+| Kind | Change |
+|---|---|
+| comparison | `==` `!=` `===` `!==` `<` `<=` `>` `>=` flipped to the opposite |
+| boolean | `true`/`false`, `True`/`False` negated |
+| arithmetic | binary `+` and `-` swapped |
+| return | `return <number>`: 0 becomes 1, anything else 0 |
+
+Mutants are spread across lines: one per changed line in diff order before any
+line gets a second.
+
+## Isolation
+
+`--head worktree` snapshots the uncommitted tree through a private index (the
+caller's index, HEAD and refs are untouched), and every mutant is applied in a
+detached worktree under the system temp directory, removed and pruned on exit,
+SIGINT/SIGTERM included. The checkout is never written.
+
+## Output and merge
+
+| Exit | Meaning | `$MP_FILE` |
+|---|---|---|
+| 0 | every mutant killed or timed out | `findings: []` |
+| 1 | at least one survivor | one finding per survivor |
+| 4 | nothing judged: no mutable changed line, or the tests fail before mutation | `findings: []`, `reason` set |
+| 2 | usage or setup error | not written; the step is skipped |
+
+A finding is reviewer-shaped (`severity: important`, `file`, `line`, `issue`,
+`fix`) plus `mutation`, `testCommand` and `tag: mutation_probe`. Step 3.0
+appends `$MP_FILE` with the other deterministic findings; triage keeps a
+survivor unless the line is genuinely untestable here (logging, a default no
+caller observes) and says so.

package/pipeline/multi-agent-refs/features/plan-checks.md

@@ -0,0 +1,67 @@
+# Feature: Plan checks (Phase 1, after the plan is written)
+
+Two deterministic checks run on `$WORKTREE/.pipeline/plan.json` before the approval gate: the overlap check inside `validate-planning.mjs`, and the complexity score from `plan-complexity.mjs`.
+
+## Overlap check
+
+**Pattern**: a plan contradicts itself at the seams between tasks, not inside one. Two tasks that both create the same file, a rename in one task while another still calls the old name, a consumer that can start before its producer: each task reads fine alone. The check is deterministic and runs inside `validate-planning.mjs`, so it fires on every plan with no extra step.
+
+### What a task may state
+
+Optional per-task lists in `planning-output.schema.json`, next to `files[]`:
+
+| Field | Holds | Role it gives the task |
+|-------|-------|------------------------|
+| `creates` | files the task brings into existence | `creates` |
+| `removes` | files or symbols deleted, or the old name of a rename (a file: a `/`, a known extension, a well-known name such as `Makefile`, or a dotfile; else a symbol, `UserService.fetch` included) | `removes` |
+| `produces` | interfaces / symbols introduced or reshaped | `produces` |
+| `consumes` | interfaces / symbols used unchanged | `consumes` |
+
+A file listed only in `files[]` gives the role `edits`. Fill the lists when Step 8 decided the approach (New file / Modify / Refactor): a New-file task lists its file under `creates`, a rename lists the old name under `removes` and the new one under `produces`, a task that calls an interface another task adds lists it under `consumes`. A plan without them still gets the shared-file rows below. `plan-todos.sh set` carries `creates` onto each todo next to `files[]`, and the per-step drift check (`features/plan-todos.md`, Drift propagation) counts both as planned, along with the test file named after a planned file (`a.test.ts` for `a.ts`, `FooTests.swift` for `Foo.swift`).
+
+### Output
+
+`validate-planning.mjs` adds two fields to its result: `overlaps[]`, one anchored row per pair of tasks naming the same file or symbol, and `warnings[]`, one sentence per suspicious row.
+
+```json
+{ "a": "T1", "b": "T3", "kind": "file", "name": "Sources/FareService.swift",
+  "aRole": "removes", "bRole": "edits", "order": "unordered", "finding": "removes-used" }
+```
+
+`order` comes from `dependsOn`, transitively: `a-first`, `b-first` or `unordered`.
+
+| Finding | When | Effect |
+|---------|------|--------|
+| `double-create` | both tasks create the same file (paths compared normalised, `./a` is `a`) | error, exit 1; unordered: make one depend on the other; ordered: drop it from one task's `creates` |
+| `removes-used` | one task removes what the other edits, consumes, creates or produces | warning |
+| `consumer-not-after-producer` | the user of a created file or produced symbol is not ordered after its producer | warning |
+| `unordered-edit` | both tasks edit one file with no `dependsOn` between them | warning |
+
+An error goes through the validator gate's single rework like any other. Warnings never change the exit code: render them in the Step 13 approval view under `⚠️ Plan overlaps` (autopilot: log `plan.overlaps={n} warnings={m}`), and fix the plan when the warning is real, usually by adding the missing `dependsOn` edge or merging the two tasks.
+
+## Complexity score
+
+**Pattern**: "is this task too big" answered from what the task touches, not from its title. The score is a sum of points over counted factors, so the same plan and graph always give the same score and each point traces to a number.
+
+| Factor | Counted as | Points |
+|--------|-----------|--------|
+| `files` | files in `files[]` | 1 → 0, 2-3 → 1, 4-5 → 2, 6-8 → 3, 9+ → 4 |
+| `fanIn` | non-test files depending on the task's declarations, one ring out in the code graph, the task's own files excluded | 0 → 0, 1-3 → 1, 4-10 → 2, 11+ → 3 |
+| `modules` | modules the task's non-test files span | one point per module past the first, at most 2 |
+| `crossModuleEdges` | fan-in files outside every module the task touches | 0 → 0, 1-3 → 1, 4+ → 2 |
+| `testSurface` | test files listed plus test files depending on the task's files | 0-2 → 0, 3-5 → 1, 6+ → 2 |
+
+`score = 1 + points`, capped at 10. A module is the SPM target (`Sources/<Target>/`, `Tests/<Target>Tests/`), else the directory above the first `src` / `test` / `tests` / `lib` segment (the Gradle module), else the first directory. Without a graph, `fanIn`, `crossModuleEdges` and `notIndexed` are `null` and score nothing, and the output says `graph: absent`. `notIndexed` counts listed files the graph does not know, usually the ones the task creates.
+
+`recommendSplit` is `score > prefs.global.planComplexity.splitAbove` (default 7; `--split-above N` overrides it). Splitting rules, applied before Step 13:
+
+- Split along the factor that scored: files by module first, then producer before consumer, tests with the code they test.
+- Traceability: every requirement id on the original appears on at least one child, and no child carries an id the original did not.
+- Ordering: a task that depended on the original depends on the child that completes the original's output; children chain through `dependsOn` where one consumes another.
+- One round. Re-run the validator and the scorer; a task still above the line is shown at Step 13 with its factors, not split again.
+
+Output: `{splitAbove, graph, split: [ids], tasks: [{id, score, recommendSplit, factors, points}]}`. `--write` stores `{score, recommendSplit, factors}` as each task's `complexity` in the plan file. Autopilot log: `plan.complexity split={ids} graph={used|absent}`.
+
+## Reference
+
+Overlap module: `$HOME/.claude/scripts/_plan-overlap.mjs` (`planOverlaps(tasks)`). Validator: `$HOME/.claude/scripts/validate-planning.mjs`. Unit: `test/plan-overlap.test.mjs`, fixtures under `test/fixtures/plan-overlap/`. Scorer: `$HOME/.claude/scripts/plan-complexity.mjs` (`planComplexity(tasks, {graph, splitAbove})`), reusing `graph-affected.mjs`'s reverse walk. Unit: `test/plan-complexity.test.mjs`, golden fixtures under `test/fixtures/plan-complexity/`.

package/pipeline/multi-agent-refs/features/plan-todos.md

@@ -7,9 +7,14 @@ while next=$(bash "$HOME/.claude/lib/plan-todos.sh" next "$TASK_ID"); [ -n "$nex
   id=$(printf '%s' "$next" | cut -f1)
   task=$(printf '%s' "$next" | cut -f2)
   bash "$HOME/.claude/lib/plan-todos.sh" start "$TASK_ID" "$id"
-  # ... TDD cycle for "$task" ...
+  # ... RED: write the failing test, run it, keep the JUnit XML / .xcresult / log ...
+  bash "$HOME/.claude/lib/plan-todos.sh" tdd-red "$TASK_ID" "$id" "$RED_RESULTS" --tests "$TEST_NAME"
+  # ... GREEN: implement, run the suite ...
+  bash "$HOME/.claude/lib/plan-todos.sh" tdd-green "$TASK_ID" "$id" "$GREEN_RESULTS"
   if build_passed; then
     bash "$HOME/.claude/lib/plan-todos.sh" complete "$TASK_ID" "$id" "${COMMIT_HASH} · tests:${TEST_COUNT}"
+    git -C "$WORKTREE" diff --name-only HEAD~1 HEAD \
+      | bash "$HOME/.claude/lib/plan-todos.sh" drift "$TASK_ID" "$id" --files - --not-done "$NOT_DONE"
   else
     bash "$HOME/.claude/lib/plan-todos.sh" fail "$TASK_ID" "$id" "build failed after 3 retries"
     break
@@ -18,3 +23,37 @@ done
 ```
 
 When disabled, the loop still walks `tasks[]` from `planning-output`  -  `plan-todos.sh` adds visibility (status, notes, deps-respecting `next`) but the underlying TDD contract is unchanged.
+
+## Drift propagation
+
+A step that ends off-plan invalidates the plan of every step built on it. `drift` takes the same two signals the scope self-check records for the whole run (`features/scope-check.md`), per step: files the step changed that its `files[]` does not list, and planned items it did not do (`--not-done N`, the entries that go to `scope-check.json` `notDone[]`). `--reason <text>` records drift the two counts do not show, such as an interface whose shape changed.
+
+On drift the step gets `drift: {outside, notDone, at}` and every **pending** step that depends on it, directly or transitively, gets `needsReplan: {because, at, reason}`; steps that already started or finished keep their state, and steps on other branches of the graph are untouched. Output: `{drifted, outside, notDone, flagged}`.
+
+A flagged step:
+
+- is reported by `next` as waiting (`task-graph.mjs` `reason: "needs-replan"`), and named on stderr when nothing else is ready;
+- is refused by `start` and `complete` (exit 2), which name the drifted step;
+- starts again after `plan-todos.sh confirm-replan "$TASK_ID" <todo-id> [note]`, run once its plan has been re-read against what the drifted step actually did (interactive: ask; autopilot: confirm when the drifted files are not in the flagged step's `files[]` and none of its `files[]` were deleted, otherwise stop the loop and log `plan.replan_needed={ids}`).
+
+A later drift replaces the flag and its confirmation. `files[]` and `creates[]` come from the planning-output task through `set`, and both count as planned; paths are normalised on both sides (`./a`, `a` and `a//b/..` compare equal). A changed test file is planned when its name covers the stem of a planned file: `a.test.ts`, `a.spec.ts`, `a_test.go`, `ATests.swift`, `ATest.kt` and `test_a.py` cover `a.ts` / `A.swift` / `a.py` in any directory. A step with neither list is judged on `--not-done` and `--reason` only.
+
+## TDD evidence
+
+`tdd-red` and `tdd-green` read the runner's own results (`lib/tdd-evidence.mjs`): JUnit XML file or directory (Gradle, Surefire, Jest/Vitest junit, `pytest --junitxml`), an `.xcresult` bundle via `xcrun xcresulttool`, that summary exported to JSON, or the xcodebuild / `swift test` log. They write `plan.todos[].tdd`.
+
+| Call | Holds when | Refused (exit 2) when |
+|------|-----------|------------------------|
+| `tdd-red <task> <todo> <results> [--tests a,b]` | at least one test fails; with `--tests`, one of the failing tests is a named one | nothing failed, nothing ran, or every failure is in another test; under `enforce`, `--tests` on results that name no failing test (use JUnit XML); `warn` records that run with `red.testsUnverifiable` and a warning |
+| `tdd-red ... --already-passing <reason>` | the run has no failure: the behaviour already exists; the run stands for RED and GREEN, the reason is kept | any test fails |
+| `tdd-green <task> <todo> <results>` | RED is recorded (not needed under test policy `tests-after`), the run has no failure, and it is the RED suite: RED's named tests pass in it, or, without names on either side, it ran at least as many tests | a test still fails, nothing ran, no RED, a RED test is missing, fewer tests than RED |
+
+Both refuse results written before the todo's `startedAt`.
+
+`complete` then reads `prefs.global.tddEvidence.mode`:
+
+- `off`: no check.
+- `warn` (default): a todo without both runs completes with a warning and `tdd.outcome: "unverified"`; Phase 3 notes it.
+- `enforce`: `complete` refuses (exit 2) and the todo stays open.
+
+Never blocking, always recorded with `tdd.outcome: "exempt"` and a reason: a `docs` or `chore` todo (type carried from `planning-output`), a `component` task (the component skill short-circuits the TDD path), project test policy `none`, and `complete ... --no-tests "<reason>"` for a repo with no test target. The last one is the todo's own claim, so it is stored with `tdd.selfDeclared: true` and Phase 3 notes it next to the unverified todos.

package/pipeline/multi-agent-refs/features/rework-escalation.md

@@ -0,0 +1,49 @@
+# Feature: Rework model escalation (Phase 2 re-entry, Phase 3 Step 4)
+
+**Pattern**: a rework round that dispatches the same model with the same findings tends to produce the same fix. Two signals say the current rung is not enough: the round is the **last** one the rework cap allows, or `review-delta.mjs` reported findings **still present** after the previous round's fix. On either, the fresh dev agent for the next round runs one rung up the model-fallback ladder (`fable -> opus -> sonnet -> haiku`, `features/model-fallback.md`), and only one. The decision is a pure function in `scripts/rework-escalation.mjs`, never a model's judgement.
+
+## Prefs
+
+`prefs.global.reworkEscalation`:
+
+| Field | Default | Meaning |
+|---|---|---|
+| `reworkEscalation.enabled` | `true` | Master switch. `false` keeps every rework round on the rung the dev dispatch resolved to. |
+| `reworkEscalation.maxTier` | `opus` | Highest rung an escalation may reach. `fable` additionally needs `modelFallback.fableEnabled: true`. |
+
+On by default because it fires at most on the rounds where a failure costs the most (the last one, or one that repeats the previous attempt), moves one rung, and stops at `opus`. Every existing cost control outranks it.
+
+## The call (before each rework dispatch)
+
+```bash
+node $HOME/.claude/scripts/cost-budget-check.mjs --task-id "$TASK_ID" --prefs "$PREFS_FILE" >/dev/null; BUDGET_RC=$?
+STILL=$(jq '.reviewIterations[-1].delta.counts.stillPresent // 0' "$STATE_FILE")
+ESC=$(node $HOME/.claude/scripts/rework-escalation.mjs --iteration "$ITERATION" --max-iterations 3 \
+  --still-present "$STILL" --current-tier "$DEV_TIER" --budget-exit "$BUDGET_RC" \
+  --prefs "$PREFS_FILE" --state "$STATE_FILE" ${FELL_BACK:+--fallen-back})
+```
+
+`ITERATION` is the rework round about to run (1-based, `retryCount + 1`); `DEV_TIER` is the rung the Phase 2 dev dispatch resolves to without this override (persona and routing, `skills/shared/core/multi-agent/SKILL.md`), so escalations never compound; `FELL_BACK` is set when this run emitted a `model_fallback` metric. Pass `BUDGET_RC` on every call: without `--budget-exit` the budget counts as disabled only when `costBudget.enabled` is not `true`, otherwise the rung holds with `budget-unchecked`. Prefs come from `--prefs`, then `$MULTI_AGENT_PREFS`, then `~/.claude/multi-agent-preferences.json`. `--state` records the result as `reviewIterations[-1].reworkEscalation`, including a refusal and its reason, and in an autopilot run lists an escalation in `decisions[]` (`features/autopilot-decisions.md`). Exit 2 or 3: log `rework.escalation_skipped`, dispatch on `DEV_TIER`; it never blocks the rework.
+
+| `reason` | Meaning |
+|---|---|
+| `escalated` | Dispatch on `toTier` |
+| `not-triggered` | Neither the last round nor a still-present finding |
+| `disabled` / `past-cap` | Switch off, or the cap has already stopped Phase 2 |
+| `run-fell-back` | The run degraded; it is never re-upgraded mid-run |
+| `budget-warn` / `budget-exceeded` / `budget-unknown` | `cost-budget-check.mjs` exit 10 / 11 / other |
+| `budget-unchecked` | No `--budget-exit` while `prefs.global.costBudget.enabled` is `true`: an unrun check is no evidence the budget has room |
+| `unknown-tier` / `top-of-ladder` | Not an Anthropic rung, or nothing above it |
+| `fable-off` / `at-ceiling` | The next rung is fable with the rung off, or above `maxTier` |
+
+Telemetry: `log-metric.sh "$TASK_ID" 2 rework.escalation escalate= from= to= reason=`.
+
+## The escalated dispatch
+
+`escalate: true` -> `PHASE_MODEL_OVERRIDE=<toTier>` for that one dev dispatch (the override outranks routing, so the fable and ceiling checks above are the only ones that apply). The agent is **fresh**: no forked history, no conversation. It gets files:
+
+- `$WORKTREE/.pipeline/triage-round-$ITERATION.json`: the persisted findings of the review that sent this round back (accepted, with fingerprints)
+- `$WORKTREE/.pipeline/rework-attempt-$((ITERATION-1)).diff`: the prior attempt's change, written by the orchestrator before the dispatch as `git diff <round start>..HEAD` (round 0 starts at the run's base), so the escalated agent sees what was tried without the conversation that tried it
+- `delta.stillPresent[]` quoted first, as Phase 2 re-entry item 7 already requires
+
+An escalation is per dispatch: the next round asks again from `DEV_TIER`, so the rework never sits more than one rung above the dev dispatch.

package/pipeline/multi-agent-refs/features/scope-check.md

@@ -33,6 +33,7 @@ Output `{ok, justified, unjustified[], unlisted[], notDone}`. Exit 1 lists `unju
 
 ## Consumers
 
+- With plan todos on, Phase 2 applies the same two signals per step as it goes: `plan-todos.sh drift` compares each step's changed files with its planned `files[]` and counts its not-done items, and flags the steps built on a drifted one for re-plan (`features/plan-todos.md`).
 - Phase 3 Step 2.2 renders file reasons, unjustified files and `notDone[]` into the shared reviewer prefix (`features/review-delta.md`).
 - Phase 4 Step 3 builds the PR `## Changes` bullets from `files[].reason` and lists `notDone[]` under `## Related` as "Follow-ups not done in this PR", merged with the final triage `deferred[]` (`channels/pr.md`).
 

package/pipeline/multi-agent-refs/generate-issue.md

@@ -66,7 +66,7 @@ Each type has a standard section skeleton. `A` = always present. `C` = condition
 | Acceptance Criteria | `{panel:borderColor=#d4a19e}` |
 | Every other section | `{panel:borderColor=#9eb6d4}` |
 
-Each panel closes with `{panel}` on its own line. Task and Bug keep plain `h3.` sections.
+Each panel closes with `{panel}` on its own line. Task and Bug keep plain `h3.` sections. The colours are defaults: `prefs.global.issueTree.storyPanels` (`{story, criteria, other}`, `#rrggbb` each) replaces any of them, and `false` writes the Story with plain `h3.` sections. A value that is not a `#rrggbb` colour keeps the default. The `/multi-agent:analysis-jira` stories read the same setting.
 
 Section headings render in `outputLanguage` (e.g. tr: "Detaylı Açıklama", "Kapsam", "Kabul Kriterleri", "Test Senaryoları", "Adımlar", "Beklenen Sonuç", "Gerçekleşen Sonuç", "Ortam", "Ekran Görüntüleri", "API Contract", "Design Reference", "Notlar").
 

package/pipeline/multi-agent-refs/help/en.md

@@ -103,6 +103,7 @@ Post-Hoc & Side-Channel:
   /multi-agent:build-optimize iOS-only Xcode build perf wrapper → benchmark + analyze + recommend-first .build-benchmark/optimization-plan.md
   /multi-agent:create-jira ["desc"] [figma-url] [swagger-url]  Create a Jira Task/Bug/Story matching team conventions (type, sprint, preview + approval)
   /multi-agent:diff-explain   Map a Phase 3 triage finding back to specific diff lines
+  /multi-agent:postmortem [#id|file.jsonl]  Post-mortem of a run from its transcripts: loops, stalls, root-cause hypotheses on file:line (read-only, redacted)
   /multi-agent:estimate <doc|text>  Effort range from similar closed work: P25-P75 per role, with the tickets behind it
   /multi-agent:scenario-audit <csv>  Test scenarios vs the code: PRESENT / PARTIAL / ABSENT / UNCLEAR, each PRESENT on a resolving file:line
   /multi-agent:graph         Build and query the repo code graph (symbols, imports, references), LLM-free

package/pipeline/multi-agent-refs/help/tr.md

@@ -102,6 +102,7 @@ Post-Hoc & Side-Channel:
   /multi-agent:build-optimize iOS-only Xcode build performance wrapper → benchmark + analiz + recommend-first .build-benchmark/optimization-plan.md
   /multi-agent:create-jira ["açıklama"] [figma-url] [swagger-url]  Takım standartlarına uygun Jira Task/Bug/Story oluştur (tip, sprint, önizleme + onay)
   /multi-agent:diff-explain   Phase 3 triage bulgusunu diff satırlarına eşle
+  /multi-agent:postmortem [#id|dosya.jsonl]  Koşunun transkriptlerinden post-mortem: döngüler, takılmalar, dosya:satır dayanaklı kök-neden hipotezleri (salt-okunur, redakte)
   /multi-agent:estimate <doc|metin>  Benzer kapanmış işlerden efor aralığı: rol başına P25-P75, dayandığı ticket'larla
   /multi-agent:scenario-audit <csv>  Test senaryolarını koda karşı denetle: VAR / KISMEN / YOK / BELİRSİZ, her VAR çözülen bir dosya:satır ile
   /multi-agent:graph         Repo kod grafiğini kur ve sorgula (semboller, import'lar, referanslar), LLM'siz

package/pipeline/multi-agent-refs/phases/phase-1-plan.md

@@ -402,6 +402,8 @@ Progress line: `    → checking validator validate-planning`
 
 Non-zero exit fails CLOSED: emit the validator stderr + `errors[]` verbatim, attempt ONE self-correction rework (re-invoke the planner with the errors quoted, overwrite `$PLAN_FILE`), re-run the validator. If it fails again -> HALT the phase (never enter Phase 2 with an invalid plan) with recovery hint: `ERR: plan output failed validate-planning.mjs twice. Inspect $PLAN_FILE against $HOME/.claude/schemas/planning-output.schema.json, then resume with /multi-agent:resume #N.` Record `agent-state.phases["1"].validator` (`pass` | `pass-after-rework` | `halted`).
 
+Then `plan-complexity.mjs "$PLAN_FILE" --graph "$GRAPH_PATH" --write` (`$GRAPH_PATH` as in `features/code-graph.md`; unset, the default graph path); split `split[]` tasks (`features/plan-checks.md`).
+
 Log: "Phase 1: Plan  -  {N} tasks created, {M} with architecture review, validator:pass"
 
 #### Step 10  -  Put the plan on the widget (required)
@@ -423,9 +425,6 @@ and stored, only invisible.
 printf '%s' "$PLAN_JSON" | bash "$HOME/.claude/lib/plan-todos.sh" set "$TASK_ID" -
 ```
 
-`set` converts a planning-output document itself, so the `tasks[]`-to-`todos[]`
-mapping has one definition, the tested one.
-
 Phase 2 (Dev) then iterates with `plan-todos.sh next "$TASK_ID"` until empty, calling `start` before each step and `complete` (with notes) or `fail`/`skip` after. Phase 3 (Review) reads the Todo list to verify all `completed` items map to diff hunks. Phase 5 (Report) renders `list` into the agent-log + PR body.
 
 **Why opt-in:** `planning-output.schema.json` already drives Phase 2 dependency order; `plan.todos[]` adds notes, durations and status transitions at the cost of a state write per step. Flip on for visibility into long features.

package/pipeline/multi-agent-refs/phases/phase-2-dev.md

@@ -47,13 +47,13 @@ The analysis document is the SOLE design source in Phase 2. Variant choices, pad
 
 <!-- progress-contract: applied -->
 
-**Progress (per `$HOME/.claude/multi-agent-refs/progress-contract.md`):** every non-trivial step emits one `→ <verb> <object>` line at immediate flush. Canonical set for standard TDD: `→ reading <file>`, `→ writing test <name>`, `→ running xcodebuild RED`, `→ writing code <file>`, `→ running xcodebuild GREEN`, `→ committing WIP <summary>`. Component-task dispatch emits the line `→ dispatching create-component <componentName>` immediately before the Skill-tool call and then relays the plugin skill's progress lines verbatim under indent `    →`.
+**Progress (per `$HOME/.claude/multi-agent-refs/progress-contract.md`):** every non-trivial step emits one `→ <verb> <object>` line at immediate flush. Canonical set for standard TDD: `→ reading <file>`, `→ writing test <name>`, `→ running xcodebuild RED`, `→ writing code <file>`, `→ running xcodebuild GREEN`, `→ committing WIP <summary>`. Component-task dispatch emits the line `→ dispatching create-component <componentName>` before the Skill-tool call, then relays the plugin skill's progress lines verbatim under indent `    →`.
 
 #### Input contract
 
 Phase 2 consumes the Phase 1 output object conforming to `$HOME/.claude/schemas/planning-output.schema.json`  -  the task graph (`tasks[]` with `id`, `title`, `type`, `files`, and optional `dependsOn` / `acceptanceCriteria`) plus the architecture review notes. Tasks execute in dependency order; the schema's `dependsOn` field drives the ready-task picker.
 
-**Plan Todo iteration (opt-in)**: gated by `prefs.global.planTodos.enabled` (default: `false`). When enabled and Phase 1 Step 11 emitted a `plan.todos[]`, Phase 2 iterates via `$HOME/.claude/lib/plan-todos.sh next/start/complete/fail` instead of walking `tasks[]` directly. When disabled, the loop walks `tasks[]` from `planning-output`  -  TDD contract is unchanged. Full helper loop + state semantics: `$HOME/.claude/multi-agent-refs/features/plan-todos.md`. A todo with `sourceTag: Reuse` binds the file analysis already found; `Modify` edits in place. Writing a new file over a `Reuse` step is a Locked 11 violation and Phase 3 flags it.
+**Plan Todo iteration (opt-in)**: gated by `prefs.global.planTodos.enabled` (default `false`). When enabled and Phase 1 Step 11 emitted `plan.todos[]`, iterate via `$HOME/.claude/lib/plan-todos.sh next/start/complete/fail/drift`; disabled, walk `tasks[]`, same TDD contract. Each todo records RED and GREEN runs (`tdd-red` / `tdd-green`); `complete` checks them per `prefs.global.tddEvidence.mode`. Loop + exemptions: `$HOME/.claude/multi-agent-refs/features/plan-todos.md`. A todo with `sourceTag: Reuse` binds the file analysis already found; `Modify` edits in place. Writing a new file over a `Reuse` step is a Locked 11 violation and Phase 3 flags it.
 
 **Shadow-Git checkpoints (opt-in)**: gated by `prefs.global.shadowGit.enabled` (default: `false`). When enabled, the orchestrator snapshots the worktree via `$HOME/.claude/lib/shadow-git.sh` so sub-phase rollback is possible without touching the project's real `.git` history. Lifecycle: `shadow-git.sh init` (Phase 0 baseline), `shadow-git.sh snapshot` (per step after `plan-todos complete`), `shadow-git.sh restore <sha> --files` (rollback). Modes: `per-todo-step` (default) or `per-tool-call`. Full wiring + storage cap: `$HOME/.claude/multi-agent-refs/features/shadow-git.md`.
 
@@ -88,6 +88,7 @@ When re-entering from Phase 3:
 5. `rejected` items are never touched. Log their IDs + triage reasons for audit only.
 6. After rework, increment `state.phases["2"].retryCount`; hard-kill at `retryCount === 3` and escalate to the user. Do not loop indefinitely. When `prefs.global.autopilotCircuitBreaker.enabled` is true (default), record the hard-kill before escalating as `state.circuitBreaker = {tripped: true, trigger: 3, detail: "rework cycles exhausted", checkpoint: {phase: 3, step: "re-entry", iteration: <n>}, trippedAt, counters: {reworkCycles: <n>}}`: the rework-storm trigger; `autopilotCircuitBreaker.maxReworkCycles` (default 3) is bounded above by this cap.
 7. When `state.reviewIterations[-1].delta` exists, `stillPresent[]` findings come first in the task list, quoted `STILL PRESENT after round N-1's fix`; repeating the previous attempt is the loop the circuit-breaker stops.
+8. Before each rework dispatch, `rework-escalation.mjs` picks the rung; findings and the prior report go as files (`features/rework-escalation.md`).
 
 If the latest iteration has `triage.approved === true` AND `accepted === []`, Phase 2 was entered by mistake  -  log the anomaly and return to Phase 3.
 
@@ -103,7 +104,7 @@ $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 2 rework.started \
 For each task (respecting dependency order), on start and on end: `bash $HOME/.claude/scripts/phase-tracker.sh sub 2 <task_id> "<title>" in_progress|completed|failed`.
 
 1. **Update task status: `in_progress` (required  -  do not skip or defer)**
-   - **Why mandatory**: the board/tracker visually stays in "Todo" until this runs. Skipping it means reviewers and the rest of the team cannot see that work has started, and automations downstream (status reports, kanban swimlanes) will be wrong.
+   - **Why**: the board shows "Todo" until this runs, and status reports and swimlanes read it.
    - **Where it applies**:
      - Jira: transition issue to "In Progress" via REST API (`/rest/api/2/issue/{id}/transitions`)
      - GitHub Projects V2: `updateProjectV2ItemFieldValue` on the Status field (singleSelectOptionId)
@@ -112,10 +113,7 @@ For each task (respecting dependency order), on start and on end: `bash $HOME/.c
      - Re-read the Status field after mutation.
      - If the value is NOT `In Progress` (Jira) / `In Develop` (Projects V2), re-fetch current option IDs and retry ONCE.
      - If verify still fails after retry → log error, do NOT proceed to TDD. The mutation silently failed and continuing would leave the task mis-tracked.
-2. **Multi-submodule awareness**: If the project has submodules (detected in Phase 0 Step 7), development may span multiple submodules. For example, a UI component might need:
-   - New types/tokens in the **common** submodule
-   - The component itself in the **uicomponents** submodule
-   - Work in BOTH submodules in the same task  -  this is normal and expected
+2. **Multi-submodule awareness**: a task may span the submodules Phase 0 Step 7 detected (e.g. tokens in **common**, the component in **uicomponents**); that is expected.
 3. **TDD cycle** (Launch Agent with `model: "sonnet"`)  -  gated by `state.testPolicy`: `tdd` = the loop below; `tests-after` = skip RED, author the same tests once green; `none` = author no tests (existing ones never weakened), report "tests not written - project policy" rather than a gap.
 
    **RED  -  Write ONE failing test first:**

package/pipeline/multi-agent-refs/phases/phase-3-review.md

@@ -100,9 +100,9 @@ Persist the totals as `state.diffRisk` (Phase 4 `risk` section, Phase 5, `run-me
 | `ui_critical` | 1.5 | path matches `*View.swift`, `*Screen.kt`, `*Configuration.swift`, etc. |
 | `loc_changed` | 1.0 | base sensitivity to total `+/-` lines |
 
-**Reviewer prompt injection**: when `$RISK_JSON` is non-empty, the orchestrator builds a `${PRIORITY_FILES}` block (numbered list of top-N files with their score + signals) and injects it once per reviewer. Reviewer prompt template (`code-reviewer.md`) treats it as advisory and does not echo it back. Triage does not see the priority list  -  its job is to filter the merged findings, not the diff.
+**Reviewer prompt injection**: when `$RISK_JSON` is non-empty, the orchestrator builds a `${PRIORITY_FILES}` block (numbered list of top-N files with their score + signals) and injects it once per reviewer. Reviewers (`code-reviewer.md`) treat it as advisory and do not echo it back. Triage does not see the priority list.
 
-**Gate behavior**: **never blocking**. If risk scoring fails (git, parse, validator), continue with no priority hint: reviewers get the full diff in default order. Failures are logged:
+**Gate behavior**: if risk scoring fails (git, parse, validator), continue with no priority hint: reviewers get the full diff in default order. Failures are logged:
 
 ```bash
 [ -z "$RISK_JSON" ] && $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 review.diff_risk_skipped reason=$REASON
@@ -119,11 +119,11 @@ $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 review.diff_risk \
   files=$(jq '.totals.files' <<< "$RISK_JSON")
 ```
 
-**Opt-out**: `prefs.global.diffRiskAdvisory = false` skips this step (no script, no priority block). Default `true`: the cost is bounded and the signal-to-noise is measured against the golden-task fixtures.
+**Opt-out**: `prefs.global.diffRiskAdvisory = false` skips this step. Default `true`.
 
 #### Step 1.76  -  Test-integrity gate (produces BLOCKING findings)
 
-Step 1.75's `test_lines_removed` hint is too weak for what it detects: a suite made green by deleting tests. This makes it blocking findings triage must adjudicate. Pure function of the full report. `--out` always writes the file, the empty result included.
+Step 1.75's `test_lines_removed` hint is too weak for a suite made green by deleting tests, so this makes it blocking findings triage must adjudicate. Pure function of the full report. `--out` always writes the file, the empty result included.
 
 ```bash
 TI_FILE="$WORKTREE/.pipeline/test-integrity.json"
@@ -136,6 +136,8 @@ TI_COUNT=$(jq -r '.count // 0' "$TI_FILE" 2>/dev/null || echo 0)
 
 The gate never blocks the phase; it *emits* blocking findings (unreadable input: zero). Feed it the FULL report: `--top` hides a shrinking test file below the cut. **No opt-out**: a run that can switch off its own anti-reward-hacking control cannot be trusted to report a pass.
 
+**TDD evidence**: `node $HOME/.claude/lib/tdd-evidence.mjs unverified --state "$STATE_FILE"` lists todos closed without RED/GREEN or by `--no-tests`, as reviewer notes, not findings.
+
 #### Step 1.761  -  Owned-path gate (BLOCKING findings)
 
 Phase 2 Gate 0 again, same base:
@@ -146,7 +148,7 @@ node $HOME/.claude/scripts/owned-path-gate.mjs --repo "$WORKTREE" --base "origin
   --state "$STATE_FILE" --out "$OP_FILE"
 ```
 
-`--out` drops the old file; exit 2 writes none. A missing `$OP_FILE` is a gate error, never "no findings" (`review-decision-gate.mjs` exit 3 under the gates). Findings merge at Step 3.0. Contract: `features/repo-profile.md`. Step 1.762: `features/valven.md`.
+`--out` drops the old file; exit 2 writes none. A missing `$OP_FILE` is a gate error, never "no findings" (`review-decision-gate.mjs` exit 3 under the gates). Findings merge at Step 3.0. Contract: `features/repo-profile.md`. Step 1.762: `features/valven.md`; opt-in 1.763: `features/mutation-probe.md`.
 
 #### Step 1.77  -  Reviewer scope (cost gate)
 
@@ -378,11 +380,11 @@ ANON=$(jq -n --argjson r "$REVIEWERS_JSON" --arg t "$TASK_ID" --argjson i "$ITER
 
 `$REVIEWERS_JSON` is `state.reviewIterations[i].reviewers`. Findings come back with `foundBy: "Source A|B|C"` and every identity key removed. Persist the map to `state.reviewIterations[i].anonymizationMap` for Phase 5 per-reviewer telemetry, and **never put the map in a prompt**.
 
-Then append the deterministic findings (Steps 1.76, 1.761, 1.762, 2.7):
+Then append the deterministic findings (Steps 1.76-1.763, 2.7):
 
 ```bash
 SA_FILE="$WORKTREE/.pipeline/security-audit-$ITERATION.json"
-MERGED=$(printf '%s' "$ANON" | cat - "$TI_FILE" "$OP_FILE" "$VG_FILE" "$SA_FILE" 2>/dev/null \
+MERGED=$(printf '%s' "$ANON" | cat - "$TI_FILE" "$OP_FILE" "$VG_FILE" "$MP_FILE" "$SA_FILE" 2>/dev/null \
   | jq -s '.[0] + ([.[1:][] | .findings // []] | add // [])')
 ```
 
@@ -390,7 +392,7 @@ Deterministic findings keep their `tag` (`test_integrity`, `owned_path`, `valven
 
 ##### 3.1 Short-circuit: no findings
 
-If **merged** findings `length === 0`, **skip triage**: write empty result `{"accepted": [], "deferred": [], "rejected": [], "approved": true}`, log, proceed to Phase 3. Note this is the merged count from 3.0: a run with zero reviewer findings but a non-empty test-integrity set must NOT short-circuit.
+If **merged** findings `length === 0`, **skip triage**: write empty result `{"accepted": [], "deferred": [], "rejected": [], "approved": true}`, log, proceed to Phase 3. This is the merged count from 3.0: zero reviewer findings plus any gate finding must NOT short-circuit.
 
 **Autopilot** (or `MULTI_AGENT_UNATTENDED=1`): the triage output, this empty one too, goes through `verify-citations.mjs "$TRIAGE_FILE" --repo "$WORKTREE" --worktree --state "$STATE_FILE"` (every bucket, each `quote` against its line, pre-existing claims against the base commit): `$HOME/.claude/multi-agent-refs/features/unattended-gates.md` section 5. Then `review-decision-gate.mjs` (end of 3.7).
 
@@ -574,11 +576,11 @@ Merge the JSON into `state.reviewIterations[-1].delta` via `write-state.mjs`; em
 
 #### Step 4  -  Consensus + Action (triage-driven)
 
-If `triage.consensus.verdict` is `split` or `unverified`, surface `consensus.disagreements[]` to the user before acting: interactive modes show the split and ask whether to treat the unverified agreement as a pass (picker-contract: Trust / Re-review / Treat-as-blocking); autopilot logs `review.consensus=<verdict>` and proceeds on the triage verdict. Never silently average a split into a pass.
+If `triage.consensus.verdict` is `split` or `unverified`, surface `consensus.disagreements[]` to the user before acting: interactive modes show the split and ask whether to treat the unverified agreement as a pass (picker-contract: Trust / Re-review / Treat-as-blocking); autopilot logs `review.consensus=<verdict>`, proceeds on the triage verdict, recorded per `features/autopilot-decisions.md`. Never silently average a split into a pass.
 
 Act **only on triage.accepted**:
 
-- **accepted.blocking** → back to Phase 2 (max 3 iterations, with reflection prompt citing only accepted items). The reflection prompt names findings by `fingerprint` and quotes `delta.stillPresent` first, marked `STILL PRESENT after round N-1's fix`. When Step 3.7 ran and `state.reviewIterations[-1].verifyByTest.redTests[]` is non-empty, the reflection prompt cites each red test: "a failing repro test already exists at <testRef>; make it green; do not delete or weaken it."
+- **accepted.blocking** → back to Phase 2 (max 3 iterations, rung per `features/rework-escalation.md`, reflection prompt cites only accepted items). The reflection prompt names findings by `fingerprint` and quotes `delta.stillPresent` first, marked `STILL PRESENT after round N-1's fix`. When Step 3.7 ran and `state.reviewIterations[-1].verifyByTest.redTests[]` is non-empty, the reflection prompt cites each red test: "a failing repro test already exists at <testRef>; make it green; do not delete or weaken it."
 - **accepted.important** → fix and re-review
 - **accepted.suggestion** → apply if reasonable
 - **deferred** → append to Phase 5 report as "follow-up items" (do not block)
@@ -595,7 +597,7 @@ node $HOME/.claude/scripts/learnings-ledger.mjs add --kind fact \
   --scope "<file-or-area glob from the finding>" --task "$TASK_ID"
 ```
 
-Statement shape: the durable rule/root cause, not the symptom  -  "force-unwrapped optional in async callback path", not "fixed crash in LoginView". Always pass `--diagnosis` with the causal why (Reflexion: the verbal reason prevents recurrence; a bare outcome does not). Dedup built in (exit 2 = already stored). Lessons re-enter Phase 1 + triage via `learnings-ledger.mjs brief` (renders diagnosis as "(why: ...)").
+Statement: the root cause, not the symptom ("force-unwrapped optional in async callback path", not "fixed crash in LoginView"). Always pass `--diagnosis`, the causal why: a bare outcome does not prevent recurrence. Dedup built in (exit 2 = already stored). Lessons re-enter Phase 1 + triage via `learnings-ledger.mjs brief` (renders diagnosis as "(why: ...)").
 
 Progress line: `    → writing lesson to learnings ledger ({N} entries)`
 

package/pipeline/multi-agent-refs/phases/phase-5-report.md

@@ -170,6 +170,8 @@ Skipped sections: when `planTodos.enabled` is false or no `plan.todos[]` was emi
 
 (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}`)
 
+(autopilot: `decisions-log.mjs render --state "$STATE_FILE"` output verbatim; own heading, nothing when empty)
+
 ## Files Changed
 
 (git diff --stat output)
@@ -317,8 +319,6 @@ bash $HOME/.claude/scripts/memory-save.sh "$PROJECT_ROOT" --from-json memory-syn
 - **user**: only if the user disclosed new context about their role, expertise, or team layout
 - **Otherwise return `[]`**  -  blank is the correct default. Do not save derivable facts (code structure, git history, command outputs).
 
-Zero new memories is normal and expected. A typical run produces one or none.
-
 Tracker: `phase-tracker.sh sub 5 3 "Knowledge+Memory" completed`.
 
 Log: "Phase 5: Knowledge captured ({N} entries to {files})"
@@ -335,7 +335,7 @@ If user does not respond at the channels multi-select menu within 30 minutes (wa
 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).
 
-Rationale: silently posting defaults to Jira / Confluence after a timeout would leak wrong-tone content to external systems. Hard-stop + resume is the safer policy.
+Rationale: posting defaults after a timeout would publish text nobody approved.
 
 ---