@mmerterden/multi-agent-pipeline 14.2.1 → 15.0.0

package/pipeline/multi-agent-refs/complaint-analysis-template.md

@@ -0,0 +1,99 @@
+# Complaint-Analysis Report Template
+
+Master layout for the report `/multi-agent:complaint-analysis` renders at Phase 4 and dispatches at Phase 5. Single-language body: every heading and prose block is written in `outputLanguage` (`tr` or `en`); the TR / EN heading pairs below show both forms, render ONE. Verdict tokens, Graylog excerpts, and field names in routing entries stay English (SKILL Locked 9). The deterministic gate over an emitted instance is `scripts/validate-complaint-doc.mjs` - keep this file and that validator in sync.
+
+Numbering is fixed 1..8. Section 4 (routing) is rendered only when at least one `core` verdict exists; numbering still re-flows sequentially when it is omitted (same omission style as the analysis template).
+
+## YAML front-matter (required keys)
+
+```yaml
+---
+run_name: complaints-20260810
+generated_at: <UTC ISO8601>
+language: tr | en
+complaint_count: <N>
+repos: "<name>:<layer>, <name>:<layer>, ..."
+verdict_counts: "client=<X> bff=<Y> core=<Z> insufficient=<W>"
+graylog_degraded: true | false
+---
+```
+
+`run_name`, `generated_at`, `language`, `complaint_count`, `graylog_degraded` are validator-required; `repos` and `verdict_counts` are part of the template contract but advisory to the gate.
+
+## 1. Özet / Summary
+
+2-4 sentences: how many complaints, where they came from (source types only - never file contents), the verdict distribution, and whether Graylog was degraded for any of them. Follow with the count table:
+
+```
+| Verdict | Count |
+|---|---|
+| client | X |
+| bff | Y |
+| core | Z |
+| insufficient-evidence | W |
+```
+
+Then the coverage table - every selected repo appears, including the ones that came back clean, so "only the client layer needed a fix" is visible at a glance:
+
+```
+| Repo | Layer | Evidence hits | Verdicts attributed |
+|---|---|---|---|
+| <owner>/my-ios-app | ios | 3 | C-01 |
+| <owner>/my-mobile-bff | mobile-bff | 0 | - (incelendi, temiz / checked, clean) |
+```
+
+## 2. Triage Tablosu / Triage Table
+
+One row per complaint. Verdict tokens are the English enum: `client:ios`, `client:android`, `client:web`, `bff:mobile-bff`, `bff:web-bff`, `core`, `insufficient-evidence`. The validator requires every row carrying a `C-NN` id to contain one of these tokens.
+
+```
+| Id | Özet (redakte) | trx/conv | Verdict | Confidence | Routing |
+|---|---|---|---|---|---|
+| C-01 | <redacted excerpt <= 80 chars> | trx-9f3a | client:ios | high | - |
+| C-02 | ... | conv-77aa | core | medium | payment-core |
+```
+
+`Routing` column: the suspected core service for `core` rows, `-` otherwise.
+
+## 3. Şikayet Detayları / Complaint Details
+
+One `### C-NN` subsection per complaint:
+
+- **Şikayet / Complaint**: the redacted text (full, not the excerpt).
+- **Graylog**: status line (`ok: N messages` / `degraded: <reason>` / `skipped: user choice`), then up to 3 evidence lines, English, shape `timestamp source level message-excerpt`. Redact any PII the log itself carries before quoting.
+- **Repo kanıtı / Repo evidence**: `file:line - signal (matchKind)` rows from the correlation phase; `-` when none.
+- **Elenen katmanlar / Ruled out**: one line listing the repos/layers that were grepped for this complaint's signals and returned nothing (e.g. `mobile-bff, web-bff: sinyal yok`). This is what justifies a single-layer verdict.
+- **Verdict + gerekçe / rationale**: the verdict token, confidence, and 1-3 sentences citing the evidence above (SKILL Locked 10: client/bff needs 1 Graylog + 1 repo citation; core needs the Graylog line naming the upstream).
+- **Geliştirme planı / Fix plan** (client/bff only, SKILL Locked 13; validator-required for every client/bff verdict): 2-5 numbered steps grounded in the existing architecture - each step references a cited `file:line` or component, reuse-first, tests included. Never rendered for core / insufficient-evidence.
+- **Dev prompt** (client/bff only): one fenced English block ready to paste into `/multi-agent:dev` or a Jira description - complaint summary, root cause, cited files, fix plan steps, acceptance check, and the `[C-NN]` id.
+
+## 4. Core Yönlendirme Önerileri / Core Routing Recommendations
+
+Rendered only when `core` verdicts exist. One `### C-NN` subsection per core verdict (the validator checks each core id appears here):
+
+```
+suspectedService: <Graylog source>
+endpoint: <path or -> 
+errorCode: <code or ->
+evidenceExcerpt: <short redacted EN excerpt>
+suggestedQueue: <prefs.projects[*].routing.coreTeamLabel or ->
+confidence: high | medium | low
+```
+
+No fix analysis, no code speculation about the core service (SKILL Locked 5). This block is what gets forwarded to the core team.
+
+## 5. Açık Sorular / Open Questions
+
+One bullet per `insufficient-evidence` verdict (what is missing: id, reproducible log, repo signal) plus any ambiguity worth a human decision (e.g. client-vs-bff attribution at low confidence).
+
+## 6. Metodoloji / Methodology
+
+Fixed short block: source types ingested, redaction applied (`parse-complaints.sh`), Graylog query window/limit actually used, repos + layers grepped, and a **degraded services** list (`graylog: <reason>` when any fetch degraded - a degraded payload is never silently dropped).
+
+## 7. Referanslar / References
+
+Input source names only - file basename + row count, Jira issue keys, Confluence page titles/URLs. Never inline the input contents. Then the repo list with layers.
+
+## 8. (Footer)
+
+One line: `Generated by /multi-agent:complaint-analysis - report only, no branches or commits.` (localized).

package/pipeline/multi-agent-refs/component-dispatch.md

@@ -1,6 +1,6 @@
 # Component Dispatch (Phase 3 short-circuit)
 
-> **TLDR**  -  When `taskType === "component"` (Figma URL in task description or instruction-driven figma workflow), multi-agent Phase 3 **does not run the TDD loop**. It delegates the entire phase to the enabled `ai-<platform>-engineering-toolkit` **marketplace plugin's** component skill (`create-component`, falling back to `create-ui-component`) via the Skill tool. Implementation lives in the plugin; multi-agent's job is classification, dispatch, and state report. The pipeline no longer bundles its own `figma-to-component` orchestrator  -  component skills live in one place, the plugin marketplace.
+> **TLDR**  -  When `taskType === "component"` (Figma URL in task description or instruction-driven figma workflow), multi-agent Phase 3 **does not run the TDD loop**. It delegates the entire phase to the enabled `ai-<platform>-toolkit` **marketplace plugin's** component skill (`create-component`, falling back to `create-ui-component`) via the Skill tool. Implementation lives in the plugin; multi-agent's job is classification, dispatch, and state report. The pipeline no longer bundles its own `figma-to-component` orchestrator  -  component skills live in one place, the plugin marketplace.
 
 This doc is referenced from `$HOME/.claude/multi-agent-refs/phases/phase-3-dev.md`. Keeping it separate lets `phase-3-dev.md` remain tight (it's already the largest phase doc) and gives the orchestrator-report contract a stable URL for both Claude-side and Copilot-side implementations.
 
@@ -37,8 +37,8 @@ run produced entities and a mapper but left the screen half-wired.
 
 | `state.componentScope` | Meaning | iOS skill | Android skill |
 |---|---|---|---|
-| `screen` (default when the frame is a full screen, or the task names a screen) | Full clean-architecture vertical: Entity → Repository → Mapper → UseCase → LocalizedText → AnalyticsTracking → CoordinatorEvent → ViewModel → Scene → Preview, then verify | `ai-ios-engineering-toolkit:create-screen` | `ai-android-engineering-toolkit:create-screen` |
-| `component` | One reusable UI component (Configuration / View / +Modifiers / Code Connect) | `ai-ios-engineering-toolkit:create-component` (fallback `create-ui-component`) | `ai-android-engineering-toolkit:create-component` (fallback `create-ui-component`) |
+| `screen` (default when the frame is a full screen, or the task names a screen) | Full clean-architecture vertical: Entity → Repository → Mapper → UseCase → LocalizedText → AnalyticsTracking → CoordinatorEvent → ViewModel → Scene → Preview, then verify | `ai-ios-toolkit:create-screen` | `ai-android-toolkit:create-screen` |
+| `component` | One reusable UI component (Configuration / View / +Modifiers / Code Connect) | `ai-ios-toolkit:create-component` (fallback `create-ui-component`) | `ai-android-toolkit:create-component` (fallback `create-ui-component`) |
 | `evolve` | Change an existing component | `evolve-component` (fallback `evolve-ui-component`) | same |
 
 ```
@@ -52,7 +52,7 @@ a single atom is `component`. When it cannot be decided, ask  -  do not default
 omits the wiring.
 
 **Pre-implementation validation is not optional on iOS.** Before the create skill
-runs, dispatch `ai-ios-engineering-toolkit:figma-validate` for the frame. It checks
+runs, dispatch `ai-ios-toolkit:figma-validate` for the frame. It checks
 registry presence, Code Connect strategy, **design token compliance**, dependency
 readiness, atomic scope and already-implemented status in about ten seconds. Those
 are precisely the checks whose absence produced guessed spacing and an unpublished
@@ -60,7 +60,7 @@ Code Connect binding. A `figma-validate` failure halts the dispatch.
 
 **Dual-name resolution.** The public (`multi-agent-plugins`) and a corporate/private marketplace named the same skill differently  -  `create-component` vs `create-ui-component`. Dispatch tries `create-component` first; if it is not available in the current repo, tries `create-ui-component`. (Same dual-name rule applies when `taskType` maps to evolve → `evolve-component`/`evolve-ui-component`, or fix → `fix-bug`.)
 
-If **neither** resolves, the platform's `ai-<platform>-engineering-toolkit` plugin is not enabled in this repo. **Halt with a user-visible error**: "component task requires the ai-<platform>-engineering-toolkit plugin enabled in this repo (`.claude/settings.local.json`)." Do not silently fall back to TDD  -  a component task ran through the bugfix path would produce wrong artefacts.
+If **neither** resolves, the platform's `ai-<platform>-toolkit` plugin is not enabled in this repo. **Halt with a user-visible error**: "component task requires the ai-<platform>-toolkit plugin enabled in this repo (`.claude/settings.local.json`)." Do not silently fall back to TDD  -  a component task ran through the bugfix path would produce wrong artefacts.
 
 ## Dispatch call
 
@@ -119,7 +119,7 @@ Phase 4 runs in `--dev` as it does in the full pipeline, and its reviewer count
 
 Component dispatch is **no longer byte-identical across CLIs** and that is by design (see `cross-cli-contract.md` section 1.1):
 
-- **Claude Code**: dispatches to the enabled `ai-<platform>-engineering-toolkit` marketplace plugin via the Skill tool (this doc).
+- **Claude Code**: dispatches to the enabled `ai-<platform>-toolkit` marketplace plugin via the Skill tool (this doc).
 - **Copilot CLI**: has no plugin loader; it continues to use its standalone `~/.copilot/skills/figma-*` skill copies (frozen fallback). Copilot's resolution + progress lines follow those local skills.
 
 What still MUST match across CLIs: the `taskType === "component"` classification, the `state.phases["3"].subphases[]` shape the dispatch layer writes, and `--dev` elision semantics. Figma-skill *inventory* parity is no longer enforced. `smoke-cross-cli-behavior.sh` asserts only the classification + state-shape axis for components.

package/pipeline/multi-agent-refs/cross-cli-contract.md

@@ -6,14 +6,14 @@
 
 ---
 
-## 1. Command Inventory (49 commands)
+## 1. Command Inventory (51 commands)
 
 ```
-analysis, analysis-resolve, autopilot, build-optimize, channels, create-jira, design-check, dev,
+analysis, analysis-resolve, autopilot, build-optimize, channels, complaint-analysis, create-jira, design-check, dev,
 dev-autopilot, dev-local, dev-local-autopilot, diff-explain, forget, garbage-collect,
 help, ios-coding-standard, issue, jira, kill, language, local,
-local-autopilot, log, manual-test, prune-logs, purge, refactor, resume, review, review-issue, review-jira,
-routines, save, scan, search, setup, ship, stack, status, store-ready, sync, test, test-accessibility,
+local-autopilot, log, manual-test, prune-logs, prune-prompts, purge, refactor, resume, review, review-issue, review-jira,
+routines, save, scan, search, setup, resume-local, stack, status, store-ready, sync, test, test-accessibility,
 test-dark-mode, test-dynamic-type, test-screenshots, testflight-validation, uninstall, update
 ```
 
@@ -23,8 +23,8 @@ Categories:
 - **Issue generator** (one-shot, no worktree, asks type Task/Bug/Story, hard approval gate before create): `create-jira`
 - **Full 8-phase modes**: `autopilot`, `local`, `local-autopilot`
 - **Fast modes** (Init -> Dev(Opus) -> Review -> Commit -> Report): `dev`, `dev-autopilot`, `dev-local`, `dev-local-autopilot`
-- **Tail modes** (run the pipeline tail over already-done local work): `ship`
-- **Ops commands** (one-shot, no worktree): `status`, `log`, `kill`, `purge`, `uninstall`, `resume`, `review`, `review-jira`, `review-issue`, `analysis`, `analysis-resolve`, `build-optimize`, `channels`, `scan`, `search`, `diff-explain`, `garbage-collect`, `prune-logs`
+- **Tail modes** (run the pipeline tail over already-done local work): `resume-local`
+- **Ops commands** (one-shot, no worktree): `status`, `log`, `kill`, `purge`, `uninstall`, `resume`, `review`, `review-jira`, `review-issue`, `analysis`, `analysis-resolve`, `complaint-analysis`, `build-optimize`, `channels`, `scan`, `search`, `diff-explain`, `garbage-collect`, `prune-logs`, `prune-prompts`
 - **Local audits** (worktree only to build; no commit, push, PR or channels): `design-check`, `testflight-validation`, `ios-coding-standard`. `testflight-validation` additionally never invokes `altool --upload-app`  -  a validation run must not be able to ship a build by accident.
 - **Meta-ops**: `setup`, `sync`, `update`, `help`, `refactor`, `test`, `stack`, `manual-test`, `language`
 - **Routines** (user-defined routine registry; the routines they create are local-only and never synced): `save`, `routines`, `forget`
@@ -33,7 +33,7 @@ Categories:
 
 ### 1.1 Figma / component work (plugin-based on Claude Code; NOT parity-enforced)
 
-Component work is **no longer a bundled pipeline skill set**. Claude Code dispatches `taskType === "component"` to the enabled `ai-<platform>-engineering-toolkit` **marketplace plugin** (`create-component`, fallback `create-ui-component`) via the Skill tool  -  full contract in `$HOME/.claude/multi-agent-refs/component-dispatch.md`. The pipeline no longer ships `pipeline/skills/figma-ios|figma-android|figma-common`; the pipeline-unique component skills (iterate loops, performance harness, validate/review, commit, adapters, wiki) were absorbed into the `ai-ios-engineering-toolkit` plugin so component skills live in one place.
+Component work is **no longer a bundled pipeline skill set**. Claude Code dispatches `taskType === "component"` to the enabled `ai-<platform>-toolkit` **marketplace plugin** (`create-component`, fallback `create-ui-component`) via the Skill tool  -  full contract in `$HOME/.claude/multi-agent-refs/component-dispatch.md`. The pipeline no longer ships `pipeline/skills/figma-ios|figma-android|figma-common`; the pipeline-unique component skills (iterate loops, performance harness, validate/review, commit, adapters, wiki) were absorbed into the `ai-ios-toolkit` plugin so component skills live in one place.
 
 **How each host receives the plugin's skills.** Only Claude Code loads the marketplace
 plugin natively. The other two are served by the installer, so all three end up with the
@@ -79,11 +79,11 @@ Two parallel shared/core skills under `pipeline/skills/shared/core/` wrap extern
 | `apple-archive-compliance` | `pipeline/skills/shared/core/apple-archive-compliance/` | `ios_app_store_audit` MCP tool (in `@mmerterden/dev-toolkit-mcp` ≥ v2.9.0) | 18 (Apple ITMS + App Store Review Guidelines) |
 | `google-play-compliance` | `pipeline/skills/shared/core/google-play-compliance/` | bundletool + aapt2 + apksigner | 21 (4 categories: Technical / Security / Privacy / Hygiene) |
 
-Both skills are wired to 4 consumers: `/multi-agent:test "store-ready"` (primary), Phase 4 Security Auditor (`pipeline/agents/security-auditor.md`), `/multi-agent:review` + SKILL.md counterpart, `/multi-agent:channels` PR-body auto-augmentation. Contract enforced by `smoke-compliance-skills.sh` (46 assertions).
+Both skills are wired to 4 consumers: `/multi-agent:test "store-ready"` (primary), Phase 4 Security Auditor (`pipeline/agents/security-auditor.md`), `/multi-agent:review` + SKILL.md counterpart, `/multi-agent:channels` PR-body auto-augmentation. Contract enforced by `smoke-compliance-skills.sh`.
 
 ### 1.3 Figma-skill routing from multi-agent (superseded)
 
-Superseded by section 1.1: Claude Code resolves component dispatch to the marketplace plugin (dual-name `create-component`/`create-ui-component`; full contract in `$HOME/.claude/multi-agent-refs/component-dispatch.md`); Copilot CLI uses its local `~/.copilot/skills/figma-*` copies. No shared filesystem-path routing table or figma-skill frontmatter/inventory parity remains under enforcement.
+Superseded by section 1.1: Claude Code resolves component dispatch to the marketplace plugin (dual-name `create-component`/`create-ui-component`; full contract in `$HOME/.claude/multi-agent-refs/component-dispatch.md`); Copilot CLI receives the enabled plugin's authored skills through `install/copilot.mjs` (section 1.1), not a standalone `figma-*` tree  -  the installer prunes those. No shared filesystem-path routing table or figma-skill frontmatter/inventory parity remains under enforcement.
 
 ---
 
@@ -164,10 +164,10 @@ skills took the block from 11 skills / 4,710 bytes to 83 skills / 22,111 bytes
 only **75 of the 142** surfaced, **and an unrelated user-scope skill was evicted**.
 Removing the plugin brought it back.
 
-So shipping the 43 sub-commands as peer skills on Codex would silently lose
+So shipping every sub-command as a peer skill on Codex would silently lose
 pipeline commands next to any stack toolkit, with no error anywhere. The pipeline
-therefore contributes **exactly one** skill on Codex (`multi-agent`) and keeps the
-43 sub-command specs as reference files that cost nothing until read.
+therefore contributes **exactly one** skill on Codex (`multi-agent`) and keeps every
+sub-command spec as a reference file that costs nothing until read.
 
 **Do not "fix" this by adding per-command skills on Codex.** The layout is
 capability-derived, and `smoke-install-layout.sh` fails if the Codex skills tree
@@ -176,7 +176,7 @@ gains a second pipeline entry.
 ### Parity axis differs per host
 
 Claude Code and Copilot CLI are compared on their **skill directory sets**. Codex is
-compared on its **ref set**: the 43 command specs must all exist under
+compared on its **ref set**: every command spec must exist under
 `~/.codex/multi-agent-refs/commands/<cmd>/SKILL.md`, and
 `smoke-codex-install.sh` asserts the count against the source tree. Comparing Codex
 on skill directories would demand exactly the layout that breaks it.
@@ -312,9 +312,9 @@ For clipboard ops, callers still gate with `if command -v pbpaste >/dev/null; th
 
 This contract is validated by:
 
-- `smoke-cross-cli-behavior.sh`  -  asserts all 38 commands behave identically, pulls from Section 2 (placeholder vocab), Section 5 (argument parsing), Section 6 (output formats); also regression-locks the 6-persona agent deployment
-- `smoke-commands-skills-parity.sh` (50 assertions)  -  enforces colon-form command ↔ dash-form skill directory parity
-- `smoke-compliance-skills.sh` (45 assertions)  -  enforces store-compliance skill catalog + 4 consumer wiring
+- `smoke-cross-cli-behavior.sh`  -  asserts every command behaves identically, pulls from Section 2 (placeholder vocab), Section 5 (argument parsing), Section 6 (output formats); also regression-locks the 8-persona agent deployment
+- `smoke-commands-skills-parity.sh` (two assertions per command)  -  enforces colon-form command ↔ dash-form skill directory parity
+- `smoke-compliance-skills.sh`  -  enforces store-compliance skill catalog + 4 consumer wiring
 - `smoke-personal-data.sh`  -  extended in 0.5.5 to treat deprecated placeholders (`{github-username}`, `{your-website}`, `{website-repo}`) as leaks; adds `mmerterden` to public-handle blocklist for generic docs
 - `pre-push-check.sh`  -  runs the cross-CLI + personal-data smoke tests before any push that touches `pipeline/skills/shared/core/` commands
 - `sync.md` (Section 2 REPO step)  -  genericization lookup table MUST match Section 2 of this contract

package/pipeline/multi-agent-refs/features/external-context-injection.md

@@ -22,7 +22,7 @@ One fetcher per type. Each fetcher emits a normalized JSON view that the analysi
 |---|---|---|
 | `crashlytics` | `~/.claude/lib/fetch-crashlytics.sh <url>` (already invoked in Phase 0 Step 1b.1 for the legacy `state.crashContext` field; Phase 1 reads that field directly) | `state.crashContext` |
 | `fortify` | `~/.claude/lib/fetch-fortify.sh <url>` (already invoked in Phase 0 Step 1b.2 for the legacy `state.fortifyFinding` field; Phase 1 reads that field, Phase 4 reads the full payload for the security gate) | `state.fortifyFinding` |
-| `graylog` | `~/.claude/lib/fetch-graylog.sh --trx <id>` / `--conv <id>` (already invoked in Phase 0 Step 1b.3 for the `state.graylogContext` field; Phase 1 reads that field directly). Diagnostic logs, **advisory only**  -  no Phase 4 gate, no generated task | `state.graylogContext` |
+| `graylog` | `~/.claude/lib/fetch-graylog.sh --trx <id>` / `--conv <id>` (already invoked in Phase 0 Step 1b.3 for the `state.graylogContext` field; Phase 1 reads that field directly). Diagnostic logs, **advisory only**  -  no Phase 4 gate, no generated task. Exception: `/multi-agent:complaint-analysis` consumes Graylog as its **primary evidence** by design (its Locked 1); the advisory-only rule scopes to the dev pipeline | `state.graylogContext` |
 | `swagger` | `~/.claude/lib/fetch-swagger.sh <url>` → endpoints[], request/response examples | `state.fetchedContext.swagger[]` |
 | `confluence` | `~/.claude/lib/fetch-confluence.sh <url>` → page body, code blocks, extracted API contracts | `state.fetchedContext.confluence[]` |
 | `figma` | no standalone fetcher - resolve via the Figma 3-tier chain (Tier 1 MCP tools, Tier 2 `~/.claude/lib/figma-screenshot.sh` + REST) when the task is a component; otherwise advisory only | `state.fetchedContext.figma[]` |

package/pipeline/multi-agent-refs/features/stack-skill-routing.md

@@ -8,7 +8,7 @@ Phase 3 dispatched to the toolkit plugin for exactly one case, `taskType === "co
 
 That is the dev-side half of the gap `features/skill-conformance.md` closes on the review side. Review now asks "was this built to the rules it was supposed to follow"; without this step, the answer for a non-component task was "there were no declared rules, because nobody chose any".
 
-The fix is not a routing table in the pipeline. Each `ai-<platform>-engineering-toolkit` already ships one: an `index` skill whose description says *"Load this first when unsure which skill applies"*, holding a 30-plus row intent-to-skill map maintained alongside the skills it points at. A second copy in this repo would drift the moment the plugin shipped a new skill, and the pipeline's copy would be the stale one.
+The fix is not a routing table in the pipeline. Each `ai-<platform>-toolkit` already ships one: an `index` skill whose description says *"Load this first when unsure which skill applies"*, holding a 30-plus row intent-to-skill map maintained alongside the skills it points at. A second copy in this repo would drift the moment the plugin shipped a new skill, and the pipeline's copy would be the stale one.
 
 So the pipeline's job is to **ask**, not to know.
 
@@ -22,8 +22,8 @@ Platform comes from the same mapping component dispatch uses, so the two cannot
 
 | `state.platform` / detected stack | Toolkit |
 |---|---|
-| ios, swift | `ai-ios-engineering-toolkit` |
-| android, kotlin | `ai-android-engineering-toolkit` |
+| ios, swift | `ai-ios-toolkit` |
+| android, kotlin | `ai-android-toolkit` |
 | anything else | no toolkit  -  step is a recorded no-op |
 
 The toolkit is enabled per repo (`.claude/settings.local.json` / `~/.claude/settings.json` `enabledPlugins`). **Not enabled is not an error here**, unlike component dispatch: a backend or web repo legitimately has no toolkit, and halting would make the pipeline unusable outside mobile. Record the no-op and continue.
@@ -45,9 +45,9 @@ Emit one progress line per loaded skill per `progress-contract.md`, so the user
 Append one `state.telemetry.skillCalls[]` entry per skill actually loaded:
 
 ```json
-{"skill": "ai-ios-engineering-toolkit:reference/architecture", "phase": 3,
+{"skill": "ai-ios-toolkit:reference/architecture", "phase": 3,
  "targetFiles": ["Domains/Checkin/Sources/CheckinScene.swift"],
- "routedBy": "ai-ios-engineering-toolkit:index@0.13.0", "timestamp": "<ISO-8601>"}
+ "routedBy": "ai-ios-toolkit:index@0.13.0", "timestamp": "<ISO-8601>"}
 ```
 
 `routedBy` names the index and version that chose it. That is the difference between "the model happened to read a skill" and "the toolkit said this skill governs this task".

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

@@ -51,7 +51,7 @@ This is why the removal is safe:
 |---|---|---|
 | Phase 7 triage-memory ingest | `triage-output.json` | `[ -f ]`-guarded, so it degrades **silently**: the triage corpus and learnings ledger stop being fed and no error appears |
 | Phase 7 learnings-ledger distill | same file | same silent degradation |
-| `render-work-summary.sh` | `agent-state.json`, `phase-tracker.json` | exits 2, so the Work Summary vanishes from the PR body and the Jira comment |
+| `render-work-summary.sh` | `agent-state.json`, `phase-tracker.json` (falls back to `logs/multi-agent/<task>/tracker-state.json`, which survives removal) | loses the salvaged copies but keeps the tracker via the logs fallback |
 | `:resume` | `agent-state.json` | cannot continue a Phase 7 pause |
 | `:status`, `:log` | `agent-state.json` | the task becomes invisible |
 

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

@@ -2,7 +2,7 @@
 
 > **TLDR**  -  Shared 12-step flow for `/multi-agent:create-jira`. Asks the issue type (Task / Bug / Story), mines the target project's existing same-type issues to learn team conventions, detects the active sprint, drafts a standards-compliant issue from a fixed standard template with auto-sizing sections, asks the user about every genuinely unknown field, renders a full preview, and creates the Jira issue only after explicit approval. Creates exactly one Jira issue per run  -  no branches, no commits, no worktrees.
 
-Consumed by `generate.md`. This ref is never invoked directly.
+Consumed by `create-jira/SKILL.md`. This ref is never invoked directly.
 
 ## Hard rules (must not regress)
 
@@ -10,7 +10,7 @@ Consumed by `generate.md`. This ref is never invoked directly.
 - **Never invent content.** Anything the user did not supply and mining could not derive stays an open question (step [8/12]) or is omitted entirely  -  never fabricated repro steps, environments, acceptance criteria, or test pass/fail results.
 - **Standard template is the baseline.** The description structure comes from the type's standard template (see [7/12]), not from a mined heading set. Mining informs summary prefix, labels, components, priority norm, sprint placement, and test-scenario style  -  never replaces the standard section skeleton.
 - **Auto-sizing.** A conditional section renders only when its trigger is present. No empty placeholder headings  -  if there is nothing to put in a conditional section, it does not appear.
-- **Issue content language follows `prefs.global.outputLanguage`.** Summary and description are written in the user's output language (intentional exception to the "external payloads stay English" default  -  the issue is authored FOR the user's team). Code identifiers, file paths, and URLs stay verbatim. AskUserQuestion `question`/`description` also follow `outputLanguage`; `label`/`header` stay English.
+- **Issue content language follows `prefs.global.outputLanguage`.** Summary and description are written in the user's output language, like every other user-facing payload body (`rules.md` matrix). Code identifiers, file paths, and URLs stay verbatim. AskUserQuestion `question`/`description` also follow `outputLanguage`; `label`/`header` stay English.
 - **UTF-8 verbatim POST path** (same as `$HOME/.claude/multi-agent-refs/channels/jira.md`): description body goes to a file, `jq -n --rawfile` builds the payload, `curl --data-binary @file` ships it. Never round-trip through `unicode_escape`/`latin-1`, never hand-roll a re-encoding helper. Jira wiki markup (`h3.` headings, `[text|url]` links), real newlines, no HTML entities.
 - **Humanizer pass** on the description body after composition, before the preview render.
 - **Read-only until approval.** Steps 1-9 perform only GET requests. The first write of any kind is the `POST /rest/api/2/issue` in step [10/12].
@@ -167,7 +167,7 @@ Write summary + description in `outputLanguage` from the type's **standard templ
   - **Always-present** sections are filled from `FREE_TEXT` (+ mining for Test Scenarios style). If an always-present section has no user content and cannot be derived, it stays an explicit open question for step 8  -  it is not fabricated.
   - **Conditional** sections render only when their trigger fired (see the Standard templates table): Design Reference when `FIGMA_URL` set (`[Figma|{FIGMA_URL}]` + frame name + node id); API Contract when 6b produced a body; Screenshots when images were staged; Notes/Dependencies only with real content. Otherwise the heading is omitted entirely.
   - Bug: logs / stack traces / device+OS mentions from `FREE_TEXT` map into Environment and Screenshots / Logs; anything underivable becomes a step-8 question.
-- Run the humanizer skill on the description body.
+- Run the `ai-common-toolkit:humanizer` skill on the description body.
 - Write the final body to `/tmp/generate-issue-$$.txt` (UTF-8, real newlines) for the `--rawfile` POST.
 
 ### [8/12] Clarifying questions (only genuinely unknown fields)

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

@@ -42,7 +42,7 @@ Decision table:
 2. Resolve Jira token via `keychainMapping.jira`. Token missing → run Token Save Flow from `setup.md` inline (clipboard-based; user can add now or skip). Skip → treat as `never` for this run.
 3. Derive Jira fields from the GitHub issue:
    - `summary` ← GitHub issue title (truncate to 255 chars).
-   - `description` ← GitHub issue body, prefixed with `h3. From GitHub\n[GH{issueNo}|{url}]\n\n`.
+   - `description` ← GitHub issue body run through the markdown → Jira wiki conversion table (`channels/jira.md`)  -  the body is GitHub Markdown (`###`, `- [ ]`, backticks) and Jira's description field renders wiki markup, so an unconverted body arrives as literal text under a correctly-rendered prefix. Prefix the converted body with the two lines `h3. From GitHub` and `[GH{issueNo}|{url}]`, then a blank line (real newlines in the payload file, never literal `\n`).
    - `issueType`  -  infer from labels: `bug` → Bug, `enhancement` → Story, default Task.
    - `project`  -  `figmaConfig.jira.projectKey`, or `prefs.global.defaultJiraKey`, or prompt (cached after first use).
    - `priority`  -  derive from labels if present (`priority:high` → High, etc.); else leave unset (Jira default).
@@ -66,7 +66,7 @@ Flow:
 
 1. Emit `→ posting wiki summary to Jira {jiraId}`.
 2. Read the first N lines of the primary wiki markdown file (the component's overview page  -  one of `writtenPaths[0]`).
-3. Render as Jira comment: title line (`h3. Component docs  -  {componentName}`) + an overview paragraph + a link to the full page (wiki URL, if the adapter returned `pushedRemote`).
+3. Render as Jira comment: title line (`h3. Component docs  -  {componentName}`) + an overview paragraph + a link to the full page (wiki URL, if the adapter returned `pushedRemote`). The overview lines come from a Markdown file  -  convert them via the `channels/jira.md` table before POST, exactly like the title line already is.
 4. **Run through the humanizer skill**  -  same policy as Step 4 Confluence: user-facing content must read naturally.
 5. `POST {jira.baseUrl}/rest/api/2/issue/{jiraId}/comment`.
 6. Log: `Phase 7: wiki summary posted to Jira {jiraId}`.
@@ -96,7 +96,7 @@ Rationale: autopilot is explicit consent for side-effect creation; muting Jira a
 Both Claude Code and Copilot CLI implementations MUST:
 
 - Resolve the `autoJiraFromGithubIssue` enum the same way.
-- Derive Jira fields from GitHub issue metadata identically (title → summary, body → description with `h3. From GitHub` prefix, label → issueType mapping).
+- Derive Jira fields from GitHub issue metadata identically (title → summary, body → description via the markdown → wiki conversion + `h3. From GitHub` prefix, label → issueType mapping).
 - Patch the GitHub issue body with the `Jira: [KEY](url)` line after create.
 - Treat failures as non-blocking with the same log shape.
 - Run the humanizer skill on the wiki-summary Jira comment.

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

@@ -0,0 +1,67 @@
+---
+description: "Canonical required-reading list for outward-facing payloads (PR body, Jira comment, closing report) plus the markup dialect per surface. Loaded by every mode that runs Phase 6 or Phase 7."
+---
+
+# Outward-facing payload contracts
+
+> Every mode that opens a PR, comments on a tracker, or closes out a run reads this file first. It does not restate the contracts  -  it names them, so no mode has to carry its own copy and drift from the others.
+
+## Read before Phase 6
+
+| Read | Before | Governs |
+|---|---|---|
+| [`channels/pr.md`]($HOME/.claude/multi-agent-refs/channels/pr.md) | assembling the PR body | fixed section set (`summary` → `changes` → `architecture` cond. → `verification` → `dependencies` cond. → `related`), Markdown-only rule, reviewer-preserving Bitbucket PUT payload |
+| [`phases/phase-6-commit.md`]($HOME/.claude/multi-agent-refs/phases/phase-6-commit.md) | committing | commit convention, default-reviewer fetch, draft/ready prompt, push-must-succeed loop |
+| [`rules.md`]($HOME/.claude/multi-agent-refs/rules.md) "External System Outputs" | any REST payload | real newlines, no HTML entities, no hand-rolled JSON, markup dialect per surface |
+
+## Read before Phase 7
+
+| Read | Before | Governs |
+|---|---|---|
+| [`channels/jira.md`]($HOME/.claude/multi-agent-refs/channels/jira.md) | posting the Jira comment | fixed section set incl. **Test Scenarios** (Given/When/Then, always present), markdown→wiki conversion table |
+| [`channels/confluence.md`]($HOME/.claude/multi-agent-refs/channels/confluence.md) | writing a Confluence page | storage-format conversion, endpoint flavor |
+| [`phases/phase-7-report.md`]($HOME/.claude/multi-agent-refs/phases/phase-7-report.md) | closing out | Timeline + Agent Activity + Cost Breakdown tables, missing-telemetry disclosure |
+| [`tracker-contract.md`]($HOME/.claude/multi-agent-refs/tracker-contract.md) | every phase boundary | per-phase token narration, completion tile suffix |
+
+## Markup dialect per surface
+
+Language is not the only axis an external payload has. Every surface also has a markup dialect, and they are not interchangeable  -  the same body shipped to the wrong dialect renders as visible garbage, not as a slightly-off style.
+
+| Surface | Dialect | Converter | Section set owned by |
+|---|---|---|---|
+| PR description (GitHub / Bitbucket / GitLab) | **Markdown**, no conversion | none  -  post the assembled markdown verbatim | `channels/pr.md` |
+| GitHub issue body + comment | **Markdown**, no conversion | none | `channels/issue-comment.md` |
+| Jira comment + issue description | **Jira wiki markup** | the table in `channels/jira.md`, applied by the model  -  no program exists | `channels/jira.md` |
+| Confluence page body | **storage format** (XHTML) | `lib/md2confluence-v3.py` | `channels/confluence.md` |
+| Wiki pages (`.md` files in a git repo) | **Markdown** | none | `channels/wiki.md` |
+| Commit message | plain text | none | `rules/git-conventions.md` |
+
+Assemble every body once in Markdown, then convert **only** on the branches that require it. The recurring defect is the reverse: the Jira wiki table is the only text-markup table in the doc set, so it reads like the default and gets applied to a PR body. In a Markdown target, `h2. Title` renders as literal text, `{{identifier}}` keeps its braces, `#` starts an H1 instead of a numbered list, and `*bold*` comes out italic. In a Jira target the mirror-image failure applies: `## Heading` and `**bold**` render literally.
+
+A payload that is in the right language but the wrong dialect is a defect of the same severity as one that never posted. Both need a fix, not a follow-up ticket.
+
+## Closing report (required)
+
+The run ends with the phase tracker glyph block **and** the numbers behind it  -  per-phase duration and token spend, plus totals.
+
+- Record spend as you go: `phase-tracker.sh tokens <N> <in> <out> [cached]` after **every** LLM call, including each Phase 4 reviewer subagent and each Phase 3 chunk. Counts are additive and nothing reconstructs them after the fact.
+- Tag the model once per phase (`phase-tracker.sh model <N> <name>`) or the cost helper cannot price it and prints `-`.
+- Durations come from the phase timestamps and survive a missed `tokens` call; token spend does not.
+- If any phase has no token data, name those phases and say their cost is unavailable. Never print a report whose cost section is simply absent  -  the reader cannot tell "cheap run" from "nobody recorded it".
+
+### Missing-telemetry disclosure (Phase 7, required)
+
+Before composing the report, compute which phases carry no token data:
+
+```bash
+STATE="$HOME/.claude/logs/multi-agent/$TASK_ID/tracker-state.json"
+UNTRACKED=$(jq -r '[.phases[] | select((.tokens_in // 0) + (.tokens_out // 0) == 0) | .id] | join(", ")' "$STATE")
+```
+
+Non-empty `UNTRACKED` → both the agent-log report and the closing chat summary carry one line in `outputLanguage` naming those phase ids as cost-unavailable. Durations come from the phase timestamps and are reported either way.
+
+`smoke-tracker-tokens-invocation.sh` only lints that the phase docs *mention* `phase-tracker.sh tokens`. It cannot observe a run that read the doc and skipped the call, so this run-time disclosure is the only thing between a dropped `tokens` call and an invisible failure.
+
+## Fast modes are not exempt
+
+`--dev`, `--dev --local`, and the autopilot variants skip Analysis, Planning, and the interactive test gate. They run Phase 6 and Phase 7 **unchanged**. A short pipeline is not a licence for an improvised payload shape, a missing Test Scenarios section, or a report without numbers.

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

@@ -105,6 +105,26 @@ No separate task breakdown  -  the agent handles scope autonomously.
 
 **Combinable with autopilot**: `--dev autopilot` = fastest path. Init -> Dev -> Review (auto-fix) -> auto-commit -> auto-PR -> Report (Phase 5 skipped). Zero user interaction (except build failures after 3 retries, and review findings that survive 3 rework cycles).
 
+### Intake warnings shared by the whole `--dev` family
+
+These apply to `--dev`, `--dev autopilot`, `--dev local`, and `--dev local autopilot` alike. A mode entry doc may not carry its own copy  -  it points here.
+
+**An analysis document was supplied.** Because Phase 1 and Phase 2 are skipped, no phase turns that document into a task breakdown. The doc becomes raw context for one Dev pass, and work comes out ordered by whatever the model read first: the bottom of the dependency chain lands, the screen wiring does not.
+
+Say so before starting, once, and offer the choice:
+
+```
+This mode skips Analysis and Planning, so the analysis document will not be turned
+into a task breakdown. For analysis-driven screen work, /multi-agent or
+/multi-agent:local run both phases.
+  1. Continue with --dev (doc as context only)
+  2. Switch to the full pipeline
+```
+
+Autopilot picks 1 and logs the warning rather than asking.
+
+**The branch already carries the work.** When the change was developed outside the pipeline, or by hand, the `--dev` family is the wrong entry point: it will try to develop again. `/multi-agent:resume-local` puts the existing diff through the same review, adds a build+test success gate, opens the PR, and posts the Jira technical-analysis + test-scenario comment  -  without re-developing. Offer it when the working tree or branch is already ahead of the base with the task's changes.
+
 ---
 
 ## Local Mode (`--local`)

package/pipeline/multi-agent-refs/phases/phase-0-init.md

@@ -35,7 +35,7 @@ Read preferences: `PREFS_FILE="$HOME/.claude/multi-agent-preferences.json"` (if
 OUTPUT_LANG=$(jq -r '.global.outputLanguage // "en"' "$PREFS_FILE" 2>/dev/null || echo en)
 ```
 
-From this point on, every assistant-authored conversational line (status updates, findings, phase headers, summaries, error explanations) renders in `$OUTPUT_LANG`. `AskUserQuestion` payloads stay English. External payloads stay English. See `$HOME/.claude/multi-agent-refs/rules.md` "Language Application" for the full contract. Skipping this step is the failure mode where the user sees an English wall of text in a Turkish session.
+From this point on, everything the user reads renders in `$OUTPUT_LANG`: conversational lines, `AskUserQuestion` `question`/`description`, and external payload bodies (PR/Jira/Confluence). English stays only on `label`/`header`, commit messages, branch names, PR titles, identifiers. Full matrix: `rules.md` "Language Application". Skipping this step is why a Turkish session gets an English wall of text  -  or an English picker.
 
 **Model fallback date gate** (same step, once per run): read `prefs.global.modelFallback`. If `premiumTierUntil` is set and in the past, apply the date-gate trigger from `$HOME/.claude/multi-agent-refs/features/model-fallback.md` - `preferredModel` personas dispatch on `fallbackModel` for this run, with the one-line WARN. Dispatch-error and budget triggers in that contract apply per-dispatch later; nothing else to do here.
 
@@ -519,7 +519,7 @@ Persist: `"taskType": "component" | "bugfix" | "feature" | "refactor" | "chore"`
 
 | Phase   | Behavior change                                                                                          |
 | ------- | -------------------------------------------------------------------------------------------------------- |
-| Phase 3 | `component` → dispatch to the enabled `ai-<platform>-engineering-toolkit` plugin's `create-component` skill (fallback `create-ui-component`); else standard TDD |
+| Phase 3 | `component` → dispatch to the enabled `ai-<platform>-toolkit` plugin's `create-component` skill (fallback `create-ui-component`); else standard TDD |
 | Phase 4 | `bugfix` → test coverage; `component` → accessibility+tokens; `refactor` → behavior preservation         |
 | Phase 6 | `bugfix`/`hotfix` → `fix(...)` prefix; `feature`/`component` → `feat(...)`; `refactor` → `refactor(...)` |
 | Phase 7 | `component` → includes SubPhase breakdown                                                                |

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

@@ -114,13 +114,13 @@ Detect the project's tech stack to load appropriate skills and tooling throughou
 
 | Stack          | Marker Files                                    | Skills                                                       |
 | -------------- | ----------------------------------------------- | ------------------------------------------------------------ |
-| iOS/Swift      | `.xcodeproj`, `Package.swift`                   | iOS skills, `swift-testing`                                  |
-| Android/Kotlin | `build.gradle`, `build.gradle.kts`              | `android-jetpack-compose-expert`, `kotlin-coroutines-expert` |
-| Python         | `requirements.txt`, `pyproject.toml`, `Pipfile` | `fastapi-pro`, `api-patterns`                                |
-| Node.js        | `package.json`                                  | `nodejs-backend-patterns`, `api-patterns`                    |
-| Go             | `go.mod`                                        | `api-patterns`, `clean-code`                                 |
-| Docker         | `Dockerfile`, `docker-compose.yml`              | `docker-expert`                                              |
-| Monorepo       | Multiple of above                               | `monorepo-architect`                                         |
+| iOS/Swift      | `.xcodeproj`, `Package.swift`                   | `ai-ios-toolkit:*` skills, `ai-ios-toolkit:swift-testing`    |
+| Android/Kotlin | `build.gradle`, `build.gradle.kts`              | `ai-android-toolkit:android-jetpack-compose-expert`, `ai-android-toolkit:kotlin-coroutines-expert` |
+| Python         | `requirements.txt`, `pyproject.toml`, `Pipfile` | `ai-backend-toolkit:fastapi-pro`, `ai-backend-toolkit:api-patterns` |
+| Node.js        | `package.json`                                  | `ai-backend-toolkit:nodejs-backend-patterns`, `ai-backend-toolkit:api-patterns` |
+| Go             | `go.mod`                                        | `ai-backend-toolkit:api-patterns`, `ai-backend-toolkit:clean-code` |
+| Docker         | `Dockerfile`, `docker-compose.yml`              | `ai-backend-toolkit:docker-expert`                           |
+| Monorepo       | Multiple of above                               | `ai-backend-toolkit:monorepo-architect`                      |
 
 Store in `agent-state.json` → `"detectedStack": ["ios", "python", "docker"]`
 

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

@@ -97,11 +97,11 @@ Store approach in task metadata for Phase 3 agent.
 
 Based on Phase 1 `detectedStack`, assign relevant skills:
 
-- iOS tasks -> SwiftUI skills, iOS patterns
-- Python tasks -> `fastapi-pro`, `api-patterns`
-- Node tasks -> `nodejs-backend-patterns`
-- Security-sensitive -> `api-security-best-practices`
-- Multi-submodule -> `monorepo-architect`
+- iOS tasks -> `ai-ios-toolkit:*` SwiftUI skills, iOS patterns
+- Python tasks -> `ai-backend-toolkit:fastapi-pro`, `ai-backend-toolkit:api-patterns`
+- Node tasks -> `ai-backend-toolkit:nodejs-backend-patterns`
+- Security-sensitive -> `ai-backend-toolkit:api-security-best-practices`
+- Multi-submodule -> `ai-backend-toolkit:monorepo-architect`
 
 #### Output contract
 

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

@@ -1,6 +1,6 @@
 ### Phase 3: Dev (Sonnet)
 
-> **TLDR**  -  Sonnet executes the plan task-by-task with TDD (red→green→refactor). Required: issue-tracker status moved to "In Progress" before any code, with a post-mutation verify step (re-reads the field, retries once on silent VALIDATION failures). Build verification after each task (up to 3 retries). Build-queue lock serializes concurrent xcodebuild. `--dev` mode uses Opus self-contained (no Phase 2 plan required). `taskType === component` **short-circuits the TDD path** and delegates the whole phase to the enabled `ai-<platform>-engineering-toolkit` marketplace plugin's component skill (`create-component`, fallback `create-ui-component`)  -  see next subsection.
+> **TLDR**  -  Sonnet executes the plan task-by-task with TDD (red→green→refactor). Required: issue-tracker status moved to "In Progress" before any code, with a post-mutation verify step (re-reads the field, retries once on silent VALIDATION failures). Build verification after each task (up to 3 retries). Build-queue lock serializes concurrent xcodebuild. `--dev` mode uses Opus self-contained (no Phase 2 plan required). `taskType === component` **short-circuits the TDD path** and delegates the whole phase to the enabled `ai-<platform>-toolkit` marketplace plugin's component skill (`create-component`, fallback `create-ui-component`)  -  see next subsection.
 
 ## Phase 3 Pre-flight (BLOCKING, v9.0.0)
 
@@ -38,7 +38,7 @@ Pre-flight steps (run in order, abort on failure).
 
    `targetFiles` is required  -  without it a skill applied to the wrong files still reads as "applied". Append at the moment of consultation, not at the end of the phase. Phase 4 Step 1.78 treats this as self-report only and resolves criteria independently; it is the one signal separating "applied to the wrong files" from "never opened".
 
-9. **Stack skill routing (every `taskType`, when a stack toolkit plugin is enabled)**: ask the enabled `ai-<platform>-engineering-toolkit`'s own `index` skill which skills govern this task, load them BEFORE writing code, and record each into `state.telemetry.skillCalls[]` with `routedBy: "<toolkit>:index@<version>"`. The routing table stays in the plugin  -  a copy here would be the stale one. No toolkit, or none enabled, is a recorded no-op, not a halt. Contract: [`features/stack-skill-routing.md`]($HOME/.claude/multi-agent-refs/features/stack-skill-routing.md).
+9. **Stack skill routing (every `taskType`, when a stack toolkit plugin is enabled)**: ask the enabled `ai-<platform>-toolkit`'s own `index` skill which skills govern this task, load them BEFORE writing code, and record each into `state.telemetry.skillCalls[]` with `routedBy: "<toolkit>:index@<version>"`. The routing table stays in the plugin  -  a copy here would be the stale one. No toolkit, or none enabled, is a recorded no-op, not a halt. Contract: [`features/stack-skill-routing.md`]($HOME/.claude/multi-agent-refs/features/stack-skill-routing.md).
 
 The analysis document is the SOLE design source in Phase 3. Variant choices, padding values, color tokens, copy strings, accessibility identifiers, and test method names all come from the rendered Pass B cells. If something is missing in the analysis doc, the fix is to re-run `/multi-agent:analysis`, not to fetch from Figma.
 
@@ -56,7 +56,7 @@ Phase 3 consumes the Phase 2 output object conforming to `$HOME/.claude/schemas/
 
 #### Component tasks  -  delegated dispatch (taskType === "component")
 
-When Phase 0 Step 7 classified the task as `component`, Phase 3 delegates the entire phase to the enabled `ai-<platform>-engineering-toolkit` marketplace plugin's component skill (`create-component`, fallback `create-ui-component`) via the Skill tool and does NOT run the TDD loop below. The dispatch layer passes the plugin skill the analysis Section 6 (Bileşen Envanteri) entry + Section 13.1 conventions for the named component as context. Because plugin skills do not write pipeline state, the **dispatch layer** (not the skill) owns `state.phases["3"].subphases[]`, recording a coarse component-build row - multi-agent's `phase-tracker` reads that array with no special case. Plugin resolution (dual-name), dispatch call, failure/resume, multi-repo, `--dev` elisions, and the intentional cross-CLI divergence live in `$HOME/.claude/multi-agent-refs/component-dispatch.md` - read it before editing component-task behaviour here. Phase 3 still owns: progress line `-> dispatching create-component <name>`, `retryCount` cap at 3, and fallthrough to the TDD path when dispatch prerequisites are missing (`taskType` absent OR the plugin is not enabled in this repo -> log anomaly, halt or run TDD per component-dispatch.md).
+When Phase 0 Step 7 classified the task as `component`, Phase 3 delegates the entire phase to the enabled `ai-<platform>-toolkit` marketplace plugin's component skill (`create-component`, fallback `create-ui-component`) via the Skill tool and does NOT run the TDD loop below. The dispatch layer passes the plugin skill the analysis Section 6 (Bileşen Envanteri) entry + Section 13.1 conventions for the named component as context. Because plugin skills do not write pipeline state, the **dispatch layer** (not the skill) owns `state.phases["3"].subphases[]`, recording a coarse component-build row - multi-agent's `phase-tracker` reads that array with no special case. Plugin resolution (dual-name), dispatch call, failure/resume, multi-repo, `--dev` elisions, and the intentional cross-CLI divergence live in `$HOME/.claude/multi-agent-refs/component-dispatch.md` - read it before editing component-task behaviour here. Phase 3 still owns: progress line `-> dispatching create-component <name>`, `retryCount` cap at 3, and fallthrough to the TDD path when dispatch prerequisites are missing (`taskType` absent OR the plugin is not enabled in this repo -> log anomaly, halt or run TDD per component-dispatch.md).
 
 For non-component taskTypes (`bugfix`, `feature`, `refactor`, `chore`), continue with the standard TDD section below.