@mmerterden/multi-agent-pipeline 19.1.4 → 20.1.0

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

@@ -104,13 +104,13 @@ Persist the totals as `state.diffRisk` (Phase 4 `risk` section, Phase 5, `run-me
 **Gate behavior**: this step is **never blocking**. If risk scoring fails (git error, parse error, validator rejection), continue with no priority hint  -  reviewers receive the full diff in their default order. Failures are logged via metrics:
 
 ```bash
-[ -z "$RISK_JSON" ] && $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 review.diff_risk_skipped reason=$REASON
+[ -z "$RISK_JSON" ] && $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 review.diff_risk_skipped reason=$REASON
 ```
 
 On success, emit a single summary metric:
 
 ```bash
-$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 review.diff_risk \
+$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 review.diff_risk \
   top_files=$(jq '.files | length' <<< "$RISK_JSON") \
   max_score=$(jq '.totals.max_score' <<< "$RISK_JSON") \
   loc_added=$(jq '.totals.loc_added' <<< "$RISK_JSON") \
@@ -127,7 +127,7 @@ Step 1.75 uses `test_lines_removed` as an advisory hint only  -  too weak for wh
 ```bash
 TEST_INTEGRITY_JSON=$(printf '%s' "$RISK_FULL" | node $HOME/.claude/scripts/test-integrity-gate.mjs 2>/dev/null || echo "")
 TI_COUNT=$(jq -r '.count // 0' <<< "${TEST_INTEGRITY_JSON:-{\}}" 2>/dev/null || echo 0)
-[ "$TI_COUNT" -gt 0 ] && $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 review.test_integrity findings="$TI_COUNT"
+[ "$TI_COUNT" -gt 0 ] && $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 review.test_integrity findings="$TI_COUNT"
 ```
 
 `findings[]` are reviewer-shaped (`test_integrity`, `blocking`), so they merge into the reviewer findings at Step 3.0 and need no triage-prompt or `validate-triage.mjs` change. Triage keeps each blocking unless the removal is justified per the immutable-test rule (spec changed AND commit body names the test) → `deferred[]`.
@@ -142,7 +142,7 @@ On a trivial diff every reviewer agrees and the extra models plus triage are pai
 SCOPE_JSON=$(printf '%s' "$RISK_FULL" | node $HOME/.claude/scripts/review-scope.mjs 2>/dev/null \
   || echo '{"scope":"full","reason":"no risk report - failing safe"}')
 REVIEW_SCOPE=$(jq -r '.scope // "full"' <<< "$SCOPE_JSON")
-$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 review.scope scope="$REVIEW_SCOPE"
+$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 review.scope scope="$REVIEW_SCOPE"
 ```
 
 `single` (Reviewer 1 only) requires **all** of: churn <= 20 lines, `totals.max_score` < 3.0, and no `security_path` / `migration` / `public_api` / `no_test_change` / `test_lines_removed` on any file. Anything else → `full`.
@@ -159,7 +159,7 @@ node $HOME/.claude/scripts/skill-conformance.mjs \
   --repo "$WORKTREE" --out "$WORKTREE/.pipeline/criteria-manifest.json"
 CRIT_RC=$?
 CRITERIA=$(cat "$WORKTREE/.pipeline/criteria-manifest.json" 2>/dev/null || echo '{}')
-$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 review.criteria \
+$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 review.criteria \
   rules="$(jq -r '.selectedRuleCount // 0' <<< "$CRITERIA")" \
   ledger="$(jq -r '.ledger.source // "derived"' <<< "$CRITERIA")"
 [ "$CRIT_RC" != "0" ] && HALT "criteria could not be resolved (rc=$CRIT_RC)  -  see resolutionFailure / unparseableRegistries"
@@ -175,7 +175,7 @@ Output conforms to `$HOME/.claude/schemas/criteria-manifest.schema.json`. The fo
 
 #### Step 1.8  -  Figma visual-fidelity context (when task carries a Figma reference)
 
-**Short-run inputs.** Phases 1 and 2 do not run in a Short run, so three inputs this phase was written around are absent. Substitute them and RECORD the substitution  -  a step that could not run and a step that passed must not read the same, or the completeness claim cannot be checked:
+**Missing inputs.** A section the evidence did not support is absent from the analysis document, so three inputs this phase was written around can be missing. Substitute them and RECORD the substitution  -  a step that could not run and one that passed must not read the same, or the completeness claim cannot be checked:
 
 | Absent input | Substitute |
 |---|---|
@@ -260,7 +260,7 @@ Each reviewer inherits the `code-reviewer` agent's focus areas (Security, Archit
 | Python | `ai-backend-toolkit:api-security-best-practices` | `ai-backend-toolkit:fastapi-pro` | `ai-backend-toolkit:python-patterns` |
 | Node.js | `ai-backend-toolkit:api-security-best-practices` | `ai-backend-toolkit:nodejs-backend-patterns` | `ai-frontend-toolkit:typescript-patterns` |
 | Docker | `ai-backend-toolkit:docker-expert` | `ai-backend-toolkit:docker-expert` | `ai-backend-toolkit:ci-cd-pipelines` |
-| Generic | `security-review` | `ai-backend-toolkit:clean-code` | `ai-backend-toolkit:clean-code` |
+| Generic | `ai-common-toolkit:security-review` | `ai-backend-toolkit:clean-code` | `ai-backend-toolkit:clean-code` |
 
 ##### 2.1 Previous-round findings (iteration >= 2) and 2.2 scope self-check (every iteration)
 
@@ -298,6 +298,10 @@ Skip only when the diff has no UI change. Record the outcome in
 
 Step 2 produces N reviewer-output objects (one per dispatched reviewer), each conforming to `$HOME/.claude/schemas/reviewer-output.schema.json`. They are persisted to `state.reviewIterations[<iteration>].reviewers[]` and consumed by Step 3 (Fable triage)  -  never by Phase 4 directly. The triage step (below) is the producer of the only review artifact Phase 4 reads, conforming to `$HOME/.claude/schemas/triage-output.schema.json`.
 
+#### Step 2.7  -  Security audit (conditional, produces reviewer-shaped findings)
+
+Runs when Step 1.75 scored `security_path`, on a release branch, or when `/multi-agent:security-review` dispatches here. The `security-auditor` returns reviewer `findings[]`, each with a `security` envelope (`security-finding.schema.json`) and severity from the CVSS band, held in `$SECURITY_AUDIT_JSON` for the merge so a `blocking` one reaches triage and blocks Phase 4. Mechanics: `~/.claude/multi-agent-refs/features/security-audit.md`.
+
 **Subagent return format**  -  each reviewer returns JSON conforming to `$HOME/.claude/schemas/reviewer-output.schema.json`:
 
 ```json
@@ -371,14 +375,14 @@ 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 Step 1.76 test-integrity findings, so they are adjudicated rather than never seen:
+Then append the Step 1.76 test-integrity and Step 2.7 security-audit findings, so they are adjudicated rather than never seen:
 
 ```bash
-MERGED=$(jq -s '.[0] + (.[1].findings // [])' \
-  <(printf '%s' "$ANON") <(printf '%s' "${TEST_INTEGRITY_JSON:-{\}}"))
+MERGED=$(jq -s '.[0] + (.[1].findings // []) + (.[2].findings // [])' \
+  <(printf '%s' "$ANON") <(printf '%s' "${TEST_INTEGRITY_JSON:-{\}}") <(printf '%s' "${SECURITY_AUDIT_JSON:-{\}}"))
 ```
 
-Deterministic findings keep `tag: test_integrity` and carry no `foundBy`: a reviewer finding may be a hallucination, a gate finding is a fact.
+Deterministic findings keep `tag: test_integrity` and no `foundBy`: a reviewer finding may hallucinate, a gate finding is a fact. Security-audit findings carry their `security` envelope and `foundBy: "security-auditor"`; an empty `$SECURITY_AUDIT_JSON` contributes nothing.
 
 ##### 3.1 Short-circuit: no findings
 
@@ -426,8 +430,8 @@ Exit 2 (empty ledger) skips silently. The `## Rejected review preferences` secti
 **Recall telemetry.** Log what was injected, then what triage cited. Zero cited is a legitimate answer; `learning-curve.mjs` trends the ratio:
 
 ```bash
-bash $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 memory.injected kind=prior-art rows=$N
-bash $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 memory.hit rows=$CITED_COUNT
+bash $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 memory.injected kind=prior-art rows=$N
+bash $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 memory.hit rows=$CITED_COUNT
 ```
 
 **Bulky payloads (opt-in via `prefs.global.contextOffload.enabled`).** Test output and whole-file diffs go through the offload filter, which leaves a `[[ref:<node_id>]]` line plus the tail in context and the full text under `.multi-agent/refs/`. Read that file when the tail is not enough; with the pref off it is a pass-through.
@@ -513,7 +517,7 @@ One `review.reviewer_call` per dispatched reviewer, one `review.triage_call`, on
 ```bash
 M=$HOME/.claude/scripts/log-metric.sh
 emit() {  # $1=event $2=model $3=duration $4=tokens_in $5=tokens_out
-  LOG_METRIC_FORWARD_TO_TRACKER=1 bash "$M" "$TASK_ID" 4 "$1" \
+  LOG_METRIC_FORWARD_TO_TRACKER=1 bash "$M" "$TASK_ID" 3 "$1" \
     model="$2" duration_ms="$3" tokens_in="$4" tokens_out="$5"
 }
 emit review.reviewer_call fable  "$R1_DURATION"     "$R1_IN"     "$R1_OUT"      # opus on Copilot CLI
@@ -525,7 +529,7 @@ else
 fi
 emit review.reviewer_call sonnet "$SONNET_DURATION" "$SONNET_IN" "$SONNET_OUT"
 emit review.triage_call fable "$TRIAGE_DURATION" "$TRIAGE_IN" "$TRIAGE_OUT"
-bash "$M" "$TASK_ID" 4 review.completed raw_count=$RAW accepted=$ACC \
+bash "$M" "$TASK_ID" 3 review.completed raw_count=$RAW accepted=$ACC \
   deferred=$DEF rejected=$REJ approved=$APPROVED duration_ms=$DURATION
 ```
 
@@ -614,7 +618,7 @@ Log: "Phase 3: Review  -  raw={N1+N2+N3} accepted={Na} deferred={Nd} rejected={N
 ## Token telemetry  -  invoke after every LLM call
 
 ```bash
-bash $HOME/.claude/scripts/phase-tracker.sh tokens 4 <input_count> <output_count> [cached_count]
+bash $HOME/.claude/scripts/phase-tracker.sh tokens 3 <input_count> <output_count> [cached_count]
 ```
 
 The optional 4th `cached_count` is the prompt-cache-read token count when the host reports it (Anthropic `cache_read_input_tokens`); it defaults to 0 and is priced at the cheaper `cacheReadPerMtok` rate in the Phase 5 cost ledger. The tracker accumulates the totals additively, so multiple calls in the same phase compound. The render output then shows live cost on the active phase tile (e.g. `Phase 2  Dev   2m 14s · 12.4k tok`). This satisfies the contract in `$HOME/.claude/multi-agent-refs/tracker-contract.md` and the `smoke-tracker-tokens-invocation.sh` enforcement gate. Skipping this call is the #1 cause of "I can't see how much it cost" complaints.
@@ -623,15 +627,12 @@ Contract and rationale: `progress-contract.md` -> Token telemetry forwarding.
 
 ---
 
-## User test (was Phase 3 until v19.0.0)
-
-Optional test gate, now the tail of Review rather than a phase of its own: it
-judges work that already exists, which is what Review does. Needs an interactive
-prompt AND a worktree checkout, so it is skipped where either is missing. If
-issues are found, the run returns to Phase 1 Dev.
+## User test
 
+The tail of Review rather than a phase of its own: it judges work that already
+exists, which is what Review does.
 
-> **TLDR**  -  Optional test gate. Offers to boot the simulator/emulator (UI Bug Hunter) or hand off to the user for manual QA. Needs an interactive prompt AND a worktree checkout, so it is in the phase set of `/multi-agent` alone and dropped by every `autopilot` or `--local` entry. Depth does not affect it: a Short run still reaches Phase 3. If issues found, loops back to Phase 2.
+> **TLDR**  -  Optional test gate. Offers to boot the simulator/emulator (UI Bug Hunter) or hand off to the user for manual QA. Needs an interactive prompt AND a worktree checkout, so it runs on an attended `/multi-agent` whose workspace is a worktree, and is skipped on `autopilot` or when the user chose to work locally. If issues found, loops back to Phase 2.
 
 <!-- progress-contract: applied -->
 Progress emission per `$HOME/.claude/multi-agent-refs/progress-contract.md`  -  lines for local-test prompt render, user-answer capture, repo checkout (if selected).
@@ -682,7 +683,7 @@ fi
 **Telemetry**:
 
 ```bash
-LOG_METRIC_FORWARD_TO_TRACKER=0 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 5 test_gap.scanned \
+LOG_METRIC_FORWARD_TO_TRACKER=0 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 test_gap.scanned \
   stack=$SCAN_STACK \
   sources=$(jq '.totals.sourcesScanned' <<< "$GAP_JSON") \
   gaps=$(jq '.totals.gapCount' <<< "$GAP_JSON")
@@ -702,7 +703,7 @@ Figma evidence (tier=<n>):
 
 Tier 1 / Tier 2 records print `screenshotUrl` from the captured evidence (Tier 2 URLs expire after 30 days, re-fetch on the spot if needed). Tier 3 records print the local path to the user-attached screenshot. The block is informational; it never blocks the prompt.
 
-1. Ask with a native `AskUserQuestion` picker (never a typed y/N prompt). The options MUST make the local-checkout side effect explicit  -  testing removes the worktree and checks the branch out into the main repo:
+1. Ask with a native `AskUserQuestion` picker (never a typed y/N prompt), per `$HOME/.claude/multi-agent-refs/picker-contract.md`. The options MUST make the local-checkout side effect explicit  -  testing removes the worktree and checks the branch out into the main repo:
    - `question`: "Check out locally to test now?" (rendered in `outputLanguage`)
    - `header`: "Test" (English, <=12 chars)
    - `options`:
@@ -733,7 +734,7 @@ Tier 1 / Tier 2 records print `screenshotUrl` from the captured evidence (Tier 2
    bash $HOME/.claude/scripts/phase-tracker.sh now 3 "awaiting local test (user)"
    bash $HOME/.claude/scripts/phase-tracker.sh render
    ```
-   The waiting state persists in `tracker-state.json` across the handoff; `/multi-agent:resume-local` and `/multi-agent:manual-test` CONTINUE this state file and never re-init it (`$HOME/.claude/multi-agent-refs/tracker-contract.md` "Continuation runs").
+   The waiting state persists in `tracker-state.json` across the handoff; `/multi-agent:resume` and `/multi-agent:manual-test` CONTINUE this state file and never re-init it (`$HOME/.claude/multi-agent-refs/tracker-contract.md` "Continuation runs").
 
    **"ok" is a structured result, not a word.** Before "ok" is accepted, the run writes `$WORKTREE/.pipeline/manual-test.json`: one entry per acceptance criterion, the criteria taken from the analysis doc test plan (Section 15 / 20), the plan tasks, and the user's own words in the reply. Every criterion records what was seen; a criterion that was not tried says so with a reason.
    ```json
@@ -791,22 +792,12 @@ Results included in Phase 5 report. MCP tools preferred when available  -  conci
 
 **Snapshot regression flow (optional):** when the task changes a stable component, capture a screenshot before the change (baseline) and after (current), then call `ios_visual_diff({baseline, current, max_diff_pct: 1.0})`. Threshold can be relaxed for animated / non-deterministic regions  -  keep `max_diff_pct ≤ 1.0` for static layouts.
 
-#### Security Audit (store-readiness)
-
-When the task touches authentication, keychain, network, or is scheduled for an imminent release, launch the `security-auditor` subagent to run an OWASP Mobile Top 10 pass plus App Store / Play Store compliance checks:
-
-```
-Agent(subagent_type: "security-auditor", prompt: "<diff + context>")
-```
-
-Returns severity-tagged findings (Critical / High / Medium). Critical items block Phase 4 just like Phase 3 blockers; High items are logged and surfaced in Phase 5 report. Skipped by default  -  opt-in for release branches or on explicit `/multi-agent "<task>" --audit` flag.
-
 #### Telemetry  -  token forwarding
 
 When the security-auditor or any other Phase 3 sub-agent runs, forward its token totals so Phase 5's Cost Breakdown captures Phase 3:
 
 ```bash
-LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 5 audit.completed \
+LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 3 audit.completed \
   model=opus tokens_in=$IN tokens_out=$OUT duration_ms=$DUR
 ```
 

package/pipeline/multi-agent-refs/phases/phase-4-commit.md

@@ -354,19 +354,19 @@ A task ending with one or more `pushStatus === "skipped"` repos does NOT bump `r
 
 ```bash
 for proj in $(jq -r '.projects[].name' "$STATE_FILE"); do
-  $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 6 commit.created   repo=$proj sha=$SHA
-  $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 6 push.attempted   repo=$proj attempts=$N status=$STATUS
-  $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 6 pr.opened        repo=$proj url=$URL number=$N
+  $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 commit.created   repo=$proj sha=$SHA
+  $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 push.attempted   repo=$proj attempts=$N status=$STATUS
+  $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 pr.opened        repo=$proj url=$URL number=$N
 done
-$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 6 multi_repo.completed repos=$REPOS skipped=$SKIPPED
+$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 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 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 \
+LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 commit.message_generated \
   model=<sonnet|opus> tokens_in=$IN tokens_out=$OUT duration_ms=$DUR
-LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 6 pr.body_generated \
+LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 4 pr.body_generated \
   model=<sonnet|opus> tokens_in=$IN tokens_out=$OUT duration_ms=$DUR
 ```
 

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

@@ -25,7 +25,7 @@ On entry: `phase-tracker.sh sub 5 <N> "<name>" in_progress`. On exit: `completed
 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.
+- **Resumable**  -  state written as `{status: "awaiting_input", phase: 5, 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 5: channels menu timeout (30 min)  -  session ended, resume with /multi-agent:resume {taskId}`.
 
 ---
@@ -188,9 +188,9 @@ Skipped sections: when `planTodos.enabled` is false or no `plan.todos[]` was emi
 **Telemetry emission** (mandatory): forward the phase's own LLM spend (humanizer + report compose calls) to the tracker, then emit the final event:
 
 ```bash
-LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 7 report.compose \
+LOG_METRIC_FORWARD_TO_TRACKER=1 $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 5 report.compose \
   model=$REPORT_MODEL tokens_in=$R_IN tokens_out=$R_OUT duration_ms=$R_DUR
-$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 7 task.completed \
+$HOME/.claude/scripts/log-metric.sh "$TASK_ID" 5 task.completed \
   phases=$PHASE_COUNT review_cycles=$CYCLES lang=$PROMPT_LANG \
   channels_pr=$PR_STATUS channels_jira=$JIRA_STATUS \
   channels_confluence=$CONF_STATUS channels_wiki=$WIKI_STATUS \

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

@@ -15,7 +15,7 @@
 
 | Phase                             | File                                                                 |
 | --------------------------------- | -------------------------------------------------------------------- |
-| Modes (depth picker, autopilot, --local) | `$HOME/.claude/multi-agent-refs/phases/modes.md`            |
+| Modes (autopilot, analysis) | `$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: Plan                     | `$HOME/.claude/multi-agent-refs/phases/phase-1-plan.md`     |
@@ -28,11 +28,11 @@
 ## Pipeline Flow
 
 ```
-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
+           0-Init -> 1-Plan -> 2-Dev -> 3-Review -> 4-Commit -> 5-Report
+Local:     The same set with no worktree  -  Phase 0 Step 5b answered local, so
+           work happens directly on a branch in the project root
 
-Full or Short is the Phase 0 Step 7.5 question, not a command name. Autopilot never asks and always runs Full.
+One pipeline: every mode runs its whole phase set, and no answer during the run adds or removes a phase.
 ```
 
 ## Phase entry  -  pending steer (every phase, every mode)
@@ -99,10 +99,8 @@ done
 
 This produces an initial card stack printed by both CLIs.
 
-`/multi-agent` and `/multi-agent:local` are the exception: they do not know their
-set here, because depth decides it at Step 7.5. They register `0:Init` alone, then
-the rest once the answer lands, and call `tiles --new` for the second batch. Full
-contract: `tracker-contract.md`, "Deferred registration".
+No mode is an exception: the phase set is a property of the command, so every
+tile is created in this one batch. Full contract: `tracker-contract.md`.
 
 ### Tracker updates (every phase boundary)
 
@@ -114,7 +112,7 @@ $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress    # phase starts
 $HOME/.claude/scripts/phase-tracker.sh update <N> completed      # phase ends OK
 # or:
 $HOME/.claude/scripts/phase-tracker.sh update <N> failed         # phase failed
-$HOME/.claude/scripts/phase-tracker.sh update <N> skipped        # e.g. 1 and 2 in a Short run
+$HOME/.claude/scripts/phase-tracker.sh update <N> skipped        # e.g. 2 in analysis mode
 ```
 
 After every LLM call (counts are additive; skipping this is why runs end with durations but no cost  -  nothing reconstructs spend afterwards):
@@ -165,7 +163,7 @@ 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 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.
+A phase outside the command's set gets no TaskCreate at all, and the set is known before the tracker boots.
 
 **(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)".
 

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

@@ -69,7 +69,7 @@ Emit a progress line **at least** at every one of these moments:
 
 ### Phase 2 (Planning)
 - plan draft start, plan render, user-approval prompt.
-- **v5.3.0 Plan Approval Gate (Full + interactive only  -  a Short run has no plan, autopilot may not ask):**
+- **v5.3.0 Plan Approval Gate (interactive only  -  autopilot may not ask):**
   - `clarification-ask` per round  -  orchestrator writes structured questions when Phase 1 flagged ambiguity (missing acceptance criteria, no Figma/endpoint link, vague language, parent-story scope drift)
   - `clarification-answer` per round  -  user reply captured into `state.phases["2"].clarificationAnswers`
   - `plan-edit-request` per free-text edit  -  user-supplied revision instruction captured into `state.phases["2"].planEditRequests`

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

@@ -1,5 +1,7 @@
 # Readiness Review (shared flow for review-jira + review-issue)
 
+> **Pickers follow** `$HOME/.claude/multi-agent-refs/picker-contract.md`: never a one-option call, and branch on the option selected, not on its text.
+
 Assess whether a tracker item (Jira issue or GitHub issue) is READY to hand to the multi-agent pipeline, list the concrete gaps, and - after confirmation - post them back as a comment on the item so the reporter can fix it. Read-only on code: no worktree, no branch, no commits, no dev chaining. This is the inverse of `/multi-agent:create-jira` (which authors a well-formed item); here we grade an existing one.
 
 Both `/multi-agent:review-jira` and `/multi-agent:review-issue` execute this flow; only the provider (fetch + comment endpoint + picker) differs.

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

@@ -44,7 +44,7 @@ This is the single source of truth. When a contributor or model is unsure where
 3. `AskUserQuestion` `question`, `options[].label` and `options[].description` all follow `OUTPUT_LANG`. Only `header` stays English: a <=12-char chip Turkish overflows. Callers branch on which option was picked, never on its literal text, and pass `default` / `ASK_CHOICE_DEFAULT` as a 1-based index. The host's own **Other** row is always English. Caller rules: `picker-contract.md`.
 4. Always English regardless of either axis: commit messages, PR titles, branch names, code identifiers, agent-state.json values, agent-log.md, reviewer/triage system prompts.
 
-**Failure mode this prevents.** Entering `/multi-agent`, `/multi-agent:autopilot`, `/multi-agent:local`, etc. and switching the assistant's conversational text or picker question copy to English while `outputLanguage="tr"` is set. The user sees a half-English half-Turkish dialogue, flagged as a pipeline bug, not a stylistic choice.
+**Failure mode this prevents.** Entering `/multi-agent`, `/multi-agent:autopilot`, etc. and switching the assistant's conversational text or picker question copy to English while `outputLanguage="tr"` is set. The user sees a half-English half-Turkish dialogue, flagged as a pipeline bug, not a stylistic choice.
 
 ## Code & Commit Rules
 

package/pipeline/multi-agent-refs/threat-model.md

@@ -0,0 +1,39 @@
+# Threat model contract
+
+The run-scoped threat model is the frame every security finding is calibrated against. It is produced by the security-auditor at Phase 3 Step 2.7 (or by `/multi-agent:security-review` running standalone), read by any later step that revisits security, and mirrored to `state.threatModel.path` so a resume re-uses it instead of re-deriving it.
+
+## Where it lives
+
+`.pipeline/threat-model.md` in the run's worktree, keyed to repo + branch. One per run. If a fresh one already exists for this repo+branch (a prior step or a Phase 1 pass wrote it), read it; do not overwrite. If it is absent, produce it before emitting any finding.
+
+Mirror the resolved path and a content hash to `state.threatModel = { path, sha, producedAt, producedBy }` so resume and Phase 5 can find it without re-reading the tree.
+
+## The four sections (all required, in order)
+
+A threat model with a missing section is not a threat model; the auditor treats a missing section as "produce it," not "skip it."
+
+### 1. Attacker
+
+The one realistic adversary for THIS change. Name it concretely: an unauthenticated internet caller, an authenticated low-privilege user, a malicious or compromised dependency, a co-located app on the device, a user with physical access. Not "attackers" in the abstract - the specific actor whose capability makes this diff interesting. If the diff has no plausible attacker, say so; that is a valid, short threat model and most findings then cap at `suggestion`.
+
+### 2. Trust boundaries
+
+Where untrusted data crosses into trusted code within the changed surface: a request body or query parameter, a deep link or universal link, a WebView `postMessage`, a file the app did not write, an environment variable an attacker can set, a response from a third-party service treated as safe. List the boundaries the diff touches, each with the `file:line` where the crossing happens.
+
+### 3. Attack surface
+
+What this diff actually added or touched: a new endpoint, a new query or ORM call, a new deserialization, a new permission, a new dependency, a new crypto usage, a new storage write. A finding outside this surface is out of scope unless the diff made it reachable - and if it did, say how. This section is what keeps the audit anchored to the change instead of drifting into a whole-repo review.
+
+### 4. Severity calibration
+
+The assumption each severity rests on, stated so a reader disputes the assumption rather than the number. "Critical assumes this route is unauthenticated in production; if it is admin-only the same finding is medium." "High assumes the secret reaches a log that ships off-device." Every `blocking` finding must trace to an assumption named here; a blocker resting on an unstated assumption is miscalibrated.
+
+## Shape
+
+Plain Markdown, four `##` sections with those names, human-readable. It is evidence for a person and context for the auditor, not a machine artifact - no schema. Keep it short: a page, not a report. Cite `file:line` where a boundary or surface item has one.
+
+## What it is not
+
+- Not a whole-repo model. It is scoped to the diff under review.
+- Not a dynamic test plan. This is a static, read-only posture: no live target, no payloads, no exploitation. `fixVerification` on a finding names the empirical check a human or a later dynamic pass would run; the threat model does not run it.
+- Not embedded in the analysis document. The security-review command must run standalone, so the model lives in its own file and is produced on demand.

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

@@ -90,11 +90,11 @@ Phases by mode:
 | Mode | Phases |
 |---|---|
 | `/multi-agent` | 0,1,2,3,4,5 |
-| `/multi-agent:local` | 0,1,2,3,4,5 (the user test needs a worktree checkout and local has none, so that STEP inside Review is skipped - the phase is not) |
-| `/multi-agent:autopilot`, `/multi-agent:local-autopilot` | 0,1,2,3,4,5 (always Full; autopilot drops the interactive user test inside Review) |
+| answered local at Step 5b | 0,1,2,3,4,5 (the user test needs a worktree checkout and local has none, so that STEP inside Review is skipped - the phase is not) |
+| `/multi-agent:autopilot` | 0,1,2,3,4,5 (autopilot drops the interactive user test inside Review) |
 | `/multi-agent:analysis` | 0,1,3,4,5 (no code is written, so Dev is not in the set) |
 
-The two picker entries (`/multi-agent`, `:local`) register in two batches, because at Step -1 they do not yet know which set is theirs: see "Deferred registration" below. Every other mode registers its whole set at Step -1.
+Every entry registers its whole set in one batch: the set is a property of the command, known before the tracker boots.
 
 Register each phase:
 
@@ -171,7 +171,7 @@ report's cost-unavailable list.
 
 > **All TaskCreate calls for the active mode's phase set MUST fire in strict phase-number order BEFORE any TaskUpdate is applied. No "pre-mark skipped phases as completed before Phase 0" reasoning is permitted  -  even when the agent knows in advance that a phase will be skipped.**
 
-Why: an agent reasoning "the user picked Short, so phases 1/2 will be skipped  -  let me TaskCreate them as completed first" produces tile IDs `1, 2, 3, ...` for phases 1/2/4, then the Phase 0 tile gets ID `4` and visually drops below them. The user sees `1, 2, 4 ✓ · 0 ▶ · 3 ☐ · ...` instead of `0 ▶ · 1 ✓ · 2 ✓ · 3 ☐ · 4 ✓ · ...`.
+Why: an agent reasoning "analysis mode skips Dev  -  let me TaskCreate it as completed first" produces tile IDs `1, 2, 3, ...` for phases 1/2/4, then the Phase 0 tile gets ID `4` and visually drops below them. The user sees `1, 2, 4 ✓ · 0 ▶ · 3 ☐ · ...` instead of `0 ▶ · 1 ✓ · 2 ✓ · 3 ☐ · 4 ✓ · ...`.
 
 The correct sequence is **always**:
 
@@ -197,44 +197,13 @@ Mode-specific phase sets:
 
 | Mode | TaskCreate set (in order) |
 |---|---|
-| `/multi-agent` | 0 at Step -1; then at Step 7.5 either 1 → 2 → 3 → 4 → 5 (Full) or 2 → 3 → 4 → 5 (Short) |
-| `:local` | same two batches; nothing is dropped, because the user test that needs a worktree checkout is a step inside Review rather than a phase of its own |
-| `:autopilot`, `:local-autopilot` | 0 → 1 → 2 → 3 → 4 → 5 (6 phases  -  always Full; the user test is inside Review now, so no phase is dropped) |
+| `/multi-agent` | 0 → 1 → 2 → 3 → 4 → 5 (6 phases) |
+| answered local | the same set; nothing is dropped, because the user test that needs a worktree checkout is a step inside Review rather than a phase of its own |
+| `:autopilot` | 0 → 1 → 2 → 3 → 4 → 5 (6 phases  -  the user test is inside Review now, so no phase is dropped) |
 | `:analysis` | 0 → 1 → 3 → 4 → 5 (5 phases  -  no code is written, so Dev is not in the set) |
 
 A phase outside the mode's set gets no TaskCreate at all; the `[SKIPPED]` pattern applies only to a phase that IS in the set and short-circuits at runtime. Phase 3 is in every mode's set as of v14.0.0. The authoritative per-mode set is the `for p in ...` init block in each mode's own entry doc, generated by `gen-mode-dispatch.mjs`; this table mirrors those blocks.
 
-#### Deferred registration  -  the depth picker
-
-`/multi-agent` and `:local` cannot know their phase set at Step -1. Depth decides it, and the depth picker cannot run before Step 7.5: its recommendation needs `taskType`, which needs the fetched issue and the branch.
-
-Until v17.5.0 they registered all eight anyway and flipped 1 and 2 to `skipped` at 7.5. That put a widget reading "8 tasks, 7 open  -  Phase 1 Plan, Phase 1 Plan, ..." on screen *beside* the question asking whether to run Analysis and Planning at all, and a Short answer then contradicted a list the user had just been shown. The widget was asserting a shape the run had not chosen.
-
-So registration splits at the moment the shape is known:
-
-```text
-# Step -1, first thing in the run: Phase 0 only. It is the one phase that is
-# certain, and the run is never silent while Phase 0 does its work.
-bash $HOME/.claude/scripts/phase-tracker.sh add 0 Init
-bash $HOME/.claude/scripts/phase-tracker.sh tiles        # -> TaskCreate(Phase 0)
-bash $HOME/.claude/scripts/phase-tracker.sh update 0 in_progress
-
-# Step 7.5, immediately after the depth answer:
-#   Full  -> 1 2 3 4 5            Short -> 2 3 4 5
-#   :local drops nothing - the user test lives inside Review now, so there is
-#   no separate phase for it to skip
-for p in "1:Plan" "2:Dev" "3:Review" "4:Commit" "5:Report"; do
-  bash $HOME/.claude/scripts/phase-tracker.sh add "${p%%:*}" "${p#*:}"
-done
-bash $HOME/.claude/scripts/phase-tracker.sh tiles --new   # -> TaskCreate for the new tiles only
-```
-
-`tiles --new` emits `TaskCreate` only for phases that carry no `tasklist_id` yet, so the Phase 0 tile is not created twice. It is the same ordering rule, applied per batch: every tile in a batch is created in ascending phase order, and a deferred batch only ever appends phases numbered above everything already registered. Nothing is pre-marked, and a phase the run will not execute never gets a tile at all.
-
-A phase that IS registered and short-circuits later still flips with `[SKIPPED]` - autopilot suppressing the Phase 3 user test, for instance. That is a runtime outcome, not an unknown set.
-
-**Enforcement**: `smoke-tasklist-ordering.sh` scans the dispatcher (`commands/multi-agent/SKILL.md`) and every mode entry point doc (`commands/multi-agent/{autopilot,local,local-autopilot,analysis,resume-local}/SKILL.md` + the Copilot full-inline orchestrator mirror) for the explicit "in phase-number order" rule. Inventory drift fails the smoke.
-
 ### Other CLIs  -  call render after every state change
 
 There is no TaskList outside Claude Code. Instead, after each state change the agent calls:
@@ -299,7 +268,7 @@ Throttling rules: mirror only canonical-set lines (`verbose`-tier internals are
 
 ### Delegated phases  -  mirror limitation + chunked dispatch (required)
 
-When a phase's work is delegated to a subagent (Phase 2 Dev on Opus in a Short run, `create-component` plugin dispatch, Phase 1 explorers, Phase 3 reviewers), the visual channel freezes for the duration of the Agent call: the orchestrator is blocked while the call is in flight, so it cannot fire `TaskUpdate` / `now` / `tokens`, and a subagent cannot drive the parent session's TaskList (its own TaskCreate/TaskUpdate calls land on an invisible child list). The progress-line mirror above can therefore only fire while the orchestrator holds control. Rules:
+When a phase's work is delegated to a subagent (`create-component` plugin dispatch, Phase 1 explorers, Phase 3 reviewers), the visual channel freezes for the duration of the Agent call: the orchestrator is blocked while the call is in flight, so it cannot fire `TaskUpdate` / `now` / `tokens`, and a subagent cannot drive the parent session's TaskList (its own TaskCreate/TaskUpdate calls land on an invisible child list). The progress-line mirror above can therefore only fire while the orchestrator holds control. Rules:
 
 1. **Pre-dispatch marker.** Immediately before every Agent call, set the active-phase line to the delegation itself, so the frozen interval at least states what is running and on which model:
    - Claude Code: `TaskUpdate({activeForm: "Dev subagent (opus): <task subject>"})`
@@ -434,7 +403,7 @@ The `tasklist_id` meta from the previous session is replaced with the new IDs du
 
 ## Continuation runs (finish / manual-test)
 
-A pre-existing `tracker-state.json` for the task is never re-initialized. Rules for any command that continues an earlier run (`/multi-agent:resume-local`, `/multi-agent:manual-test`, resume):
+A pre-existing `tracker-state.json` for the task is never re-initialized. Rules for any command that continues an earlier run (`/multi-agent:resume`, `/multi-agent:manual-test`):
 
 1. `init` runs ONLY when no state file exists for the task. Otherwise the existing file is kept - phase history (elapsed, tokens, model, meta) survives.
 2. The continuing command re-declares its phase set with `add` - `add` is idempotent, so existing phases keep their name, status, and token history; only genuinely new phases are appended. The card renders phases sorted by numeric id, so mixed sets stay in order.

package/pipeline/multi-agent-refs/wiki-capture.md

@@ -11,6 +11,8 @@
 - [Cross-CLI parity](#cross-cli-parity)
 <!-- /toc -->
 
+> **Pickers follow** `$HOME/.claude/multi-agent-refs/picker-contract.md`: never a one-option call, and branch on the option selected, not on its text.
+
 > **TLDR**  -  Component tasks can auto-generate wiki docs + Figma screenshots. The Wiki adapter is invoked from `/multi-agent:channels` (Phase 5 delegates, or user invokes post-hoc). Four layouts supported (`submodule`, `in-repo`, `github-wiki`, `separate-repo`)  -  adapter picked from `figmaConfig.wiki.mode`. Non-blocking: failures log a warning and channels continues to other adapters. The Wiki adapter supports scope multi-select (Case A) and a precondition-failure menu (Case B)  -  see below.
 
 This doc is referenced from `commands/multi-agent/channels/SKILL.md` (Wiki adapter) and indirectly from `$HOME/.claude/multi-agent-refs/phases/phase-5-report.md` (which delegates all external delivery to channels). Keeping it separate keeps both files under their token budgets and gives the contract a stable location for Claude-side + Copilot-side implementations.
@@ -75,7 +77,7 @@ Autopilot in Phase 5 pauses at the channels menu (per modes.md contract)  -  if
 
 ## Legacy prompt + preference flow (pre-v5.7, still supported for backward compat)
 
-Interactive path (any interactive run, Full or Short), ONLY when the schema lacks `wikiScope`  -  ask with a native `AskUserQuestion` picker (never a typed y/n):
+Interactive path (any interactive run), ONLY when the schema lacks `wikiScope`  -  ask with a native `AskUserQuestion` picker (never a typed y/n):
 
 - `question`: "Generate component wiki docs?" (rendered in `outputLanguage`)
 - `header`: "Wiki" (English, <=12 chars)
@@ -103,7 +105,6 @@ Explicit logs help the developer understand why wiki did or did not run:
 - `figmaConfig` missing entirely → log `Phase 5: wiki skipped (no figma-config for this project)`.
 - User declined at prompt → log `Phase 5: wiki skipped by user`.
 - Autopilot with `wikiDefault=false` → log `Phase 5: wiki skipped (autopilot + wikiDefault=false)`.
-- Short run: DO prompt  -  wiki is cheap and keeps docs fresh on the fast path; skip only if the user says no.
 
 ## Success log
 

package/pipeline/preferences-template.json

@@ -1,5 +1,5 @@
 {
-  "schemaVersion": "2.7.0",
+  "schemaVersion": "2.8.0",
   "global": {
     "identities": [],
     "keychainMapping": {
@@ -101,7 +101,7 @@
     "skillConformance": {
       "blockOnCoverageGap": false
     },
-    "resumeLocal": {
+    "resume": {
       "autoFix": false
     }
   },

package/pipeline/rules/figma-pipeline.md

@@ -75,7 +75,7 @@ The 3-tier fallback chain above governs Figma access in `/multi-agent:analysis`
 | Phase | Sub-command examples | Figma MCP allowed | Figma REST allowed | Reason |
 |---|---|---|---|---|
 | Analysis Phase 1 | `/multi-agent:analysis` Phase 1 fetch | yes | yes (Tier 2 fallback) | Single source of design ground truth |
-| Plan (Phase 1) | `/multi-agent`, `/multi-agent:local`, `/multi-agent:autopilot`, `/multi-agent:local-autopilot` | no | no | Plan reads analysis doc Section 14 + Section 6 |
+| Plan (Phase 1) | `/multi-agent`, `/multi-agent:autopilot` | no | no | Plan reads analysis doc Section 14 + Section 6 |
 | Dev (Phase 2) | every mode that runs Phase 2 (8 modes total) | no | no | Reads analysis doc + Code Connect mapping |
 | Review (Phase 3) | `/multi-agent:review`, every full-pipeline mode | no | no | Reviewer cites analysis doc Section 21 References |
 | Test (inside Phase 3) | `/multi-agent:test`, `/multi-agent:manual-test`, every full mode | no | no | Variant list comes from analysis Section 13.6 + 15.2 |

package/pipeline/schemas/agent-state.schema.json

@@ -66,7 +66,7 @@
     },
     "worktreePath": {
       "type": ["string", "null"],
-      "description": "Absolute path to the task worktree. Null in --local mode."
+      "description": "Absolute path to the task worktree. Null when the Step 5b picker answered local."
     },
     "branch": {
       "type": "string",
@@ -274,7 +274,7 @@
     "workspaceSource": {
       "type": "string",
       "enum": ["asked", "command", "autopilot"],
-      "description": "Who decided where the branch lives. asked = the user answered the Step 5b workspace picker; command = :local / --local / :local-autopilot stated it up front, or a flow that only ever builds worktrees; autopilot = resolved to a worktree without asking, because an unattended commit in the user's own checkout is what worktrees prevent. localMode alone cannot say: false is both a chosen worktree and one nothing asked about."
+      "description": "Who decided where the branch lives. asked = the user answered the Step 5b workspace picker; command = a flow that only ever builds worktrees stated it up front; autopilot = resolved to a worktree without asking, because an unattended commit in the user's own checkout is what worktrees prevent. localMode alone cannot say: false is both a chosen worktree and one nothing asked about."
     },
     "remoteType": {
       "type": "string",
@@ -476,15 +476,10 @@
       "type": "boolean",
       "default": false
     },
-    "onlyDevelop": {
-      "type": "boolean",
-      "default": false,
-      "description": "Short pipeline  -  phases 1 and 2 are skipped. Set by the Phase 0 Step 7.5 depth picker as of v16.0.0; the key and every reader of it are unchanged. Phase 3 Review still runs (v14.0.0+). Always false in an autopilot run, which never asks the depth question."
-    },
     "localMode": {
       "type": "boolean",
       "default": false,
-      "description": "--local flag  -  no worktree, direct branch in projectRoot."
+      "description": "Step 5b answered local  -  no worktree, direct branch in projectRoot."
     },
     "instructionDriven": {
       "type": "boolean",
@@ -498,7 +493,7 @@
     "analysis": {
       "type": ["object", "null"],
       "additionalProperties": true,
-      "description": "Phase 1 analysis-document outcome. Absent in Short runs, which produce no document by design.",
+      "description": "Phase 1 analysis-document outcome. Phase 1 runs in every mode, so a document is always produced; what varies is how many of its sections the evidence supported.",
       "properties": {
         "docStatus": {
           "type": "string",
@@ -862,6 +857,29 @@
         }
       }
     },
+    "threatModel": {
+      "type": "object",
+      "additionalProperties": true,
+      "description": "The run-scoped threat model produced at Phase 3 Step 2.7 (or by /multi-agent:security-review), mirrored here so a resume reuses it instead of re-deriving it. Contract: multi-agent-refs/threat-model.md.",
+      "properties": {
+        "path": {
+          "type": "string",
+          "description": "Path to .pipeline/threat-model.md in the worktree."
+        },
+        "sha": {
+          "type": "string",
+          "description": "Content hash, so a later step can tell whether the model changed."
+        },
+        "producedAt": {
+          "type": "string",
+          "format": "date-time"
+        },
+        "producedBy": {
+          "type": "string",
+          "description": "Which step or command wrote it (e.g. 'phase-3-step-2.7', 'security-review')."
+        }
+      }
+    },
     "reviewIterations": {
       "type": "array",
       "items": {
@@ -1530,7 +1548,7 @@
               }
             }
           },
-          "description": "Captured in Phase 2 after the build+test gate, because the user test is dropped by every autopilot and --local entry."
+          "description": "Captured in Phase 2 after the build+test gate, because the user test is dropped by every autopilot entry and by any run whose workspace is local."
         },
         "host": {
           "type": ["string", "null"],