@mmerterden/multi-agent-pipeline 13.0.0 → 13.2.0

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

@@ -367,3 +367,35 @@ bash $HOME/.claude/scripts/phase-tracker.sh tokens 3 <input_count> <output_count
 The tracker accumulates the totals additively, so multiple calls in the same phase compound. The render output then shows live cost on the active phase tile (e.g. `Phase 3  Dev   2m 14s · 12.4k tok`). This satisfies the contract in `$HOME/.claude/multi-agent-refs/tracker-contract.md` and the `smoke-tracker-tokens-invocation.sh` enforcement gate. Skipping this call is the #1 cause of "I can't see how much it cost" complaints.
 
 If you do not have access to the model's reported token counts, pass best-effort estimates derived from input length / output length  -  partial cost data is better than none.
+
+
+#### Generated trees are not yours to edit
+
+Many repos generate part of their source: a service client from an OpenAPI spec, mock
+scenario indexes, localization keys, testing identifiers, design tokens. A generated
+file is regenerated on the next build, so an edit there is lost silently, and the
+matching hand-authored tree is the one that takes the change.
+
+Before writing into any path, check whether it is generated:
+
+```bash
+# a Generated/ segment, or a header saying so, is the signal
+find . -type d -name Generated -not -path './.*' | head
+grep -rl "DO NOT EDIT\|auto-generated\|Generated by" --include="*.swift" --include="*.kt" . | head
+```
+
+The pairing is usually `Generated/<x>` for output and `Custom<X>/` or
+`CustomSources/` for input. Two concrete shapes seen in the wild:
+
+| Want to | Wrong place | Right place |
+|---|---|---|
+| add a mock fixture / named scenario | a `Fixtures/` file under a generated tree | the repo's custom fixture tree, plus registering the scenario in the generated index the build reads |
+| add or change a service endpoint | the generated client method | the OpenAPI source the generator consumes, then regenerate |
+
+One run wrote a mock fixture into the generated fixtures tree; the fix commit moved it
+to the custom tree and registered the scenario in the generated index. Same content,
+wrong side of the generator, and the Debug menu never showed it.
+
+When the analysis doc has not recorded which trees are generated, that is a Phase 1
+gap  -  say so rather than guessing, since guessing wrong is invisible until the next
+regeneration.

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

@@ -272,6 +272,32 @@ Each reviewer inherits the `code-reviewer` agent's focus areas (Security, Archit
 
 Skills are injected into reviewer prompt context  -  the reviewer uses them as reference, not as commands.
 
+#### Step 2.8  -  Visual conformance gate (component / screen work only)
+
+Runs when `state.taskType == "component"` **or** the diff touches SwiftUI UI files
+AND the task carried a Figma reference. Two checks, in order:
+
+1. **`ai-ios-engineering-toolkit:figma-review`** over the implemented frames  -  the
+   plugin's own component review, including the 14-item checklist that covers design
+   tokens, accessibility identifiers, previews and Code Connect.
+2. **`/multi-agent:design-check`** for pixel + spacing + typography + colour
+   conformance against the Figma variants, with its coverage gate: a variant that is
+   neither audited nor skipped-with-a-reason fails the run.
+
+**Code Connect must be published, not merely written.** A `*.figma.swift` file on
+disk with `Code Connect: Not published` in Figma means the binding does not exist for
+anyone but the author. Assert the publish step ran; an unpublished binding is a
+blocking finding.
+
+Why this is a gate and not advice: `design-check` existed as a command for a while
+with **no phase invoking it**, so the only thing standing between a build and visual
+drift was the user opening the app and looking. On one run that produced 16pt padding
+where the frame said `Spacing/12`, and a full sheet rebuild afterwards. A reviewer
+reading a diff cannot see spacing; something has to compare against the design.
+
+Skip only when the diff has no UI change. Record the outcome in
+`consensus.visualConformance` so Phase 7 reports whether it ran.
+
 **iOS/Swift  -  interaction & convention checks (conditional).** When the diff touches SwiftUI UI files (`*View.swift`, `*Screen.swift`, `*Configuration.swift`, `*+Modifiers.swift`), the iOS reviewers additionally apply the component/interaction conventions documented in the analysis doc (Section 14 Code Connect mapping) and, where the repo has the marketplace component toolkit enabled (`ai-ios-engineering-toolkit`), that plugin's navigation / overlay / bottom-sheet conventions (interaction: emit-intent vs self-route/self-present; native-SwiftUI-first vs the project's `ui.*` custom system) plus the component accessibility rules (minimalism). These back the Step 1.5 iOS convention checks. Generic across SwiftUI projects  -  not tied to any one app. Omit when the diff has no SwiftUI UI changes (keeps the reviewer prompt lean).
 
 **Module review guides (conditional, all stacks).** A module in the repo may carry its own CLAUDE guide  -  a convention/checklist file living somewhere in the module's directory tree that the host CLI never auto-loads. When a changed file's module has such a guide, the review must consult it. Discovery is deterministic, from the diff's changed paths: for each changed file, walk its directory chain up to the repo root and collect `CLAUDE.md`, `*-CLAUDE.md`, and `AGENTS.md` files (root-level ones excluded  -  the host CLI already loads those). Dedupe, cap at 5 (log any dropped). Inject into every reviewer prompt with the directive: read each guide before reviewing and apply its rules/checklist to the changed files under its directory  -  a guide governs only its own subtree, and guide violations are findings triaged by severity like any other. No guides found → no-op, prompt stays lean. Same contract as `/multi-agent:review` Step 2b.

package/pipeline/scripts/phase0-exit-gate.mjs

@@ -0,0 +1,185 @@
+#!/usr/bin/env node
+/**
+ * phase0-exit-gate.mjs  -  Phase 0 may not be marked completed until it has
+ * actually produced its own output.
+ *
+ * Why this exists. Phase 0 Step 7 says to classify the task and "persist to
+ * `agent-state.json.taskType`", and Phase 3 branches on that field to route a
+ * Figma-driven task to the component skills (`create-screen` / `create-component`
+ * in the stack plugin) instead of generic development. On a real run the tracker
+ * showed Phase 0 `completed` while the task directory held only
+ * `tracker-state.json`  -  no `agent-state.json` at all. With no `taskType`, the
+ * dispatch could not fire, so a Figma-driven screen was built as generic work: no
+ * token-compliance check, no Code Connect publish, no 14-item component review,
+ * and spacing guessed at 16 where the frame said `Spacing/12`. Half the commits on
+ * that branch were rework.
+ *
+ * A phase that reports success without its output is worse than one that fails:
+ * every later phase then reasons from a field that is not there. So this is a
+ * gate, not a lint  -  the spec already said what to write, and prose alone did
+ * not make it happen.
+ *
+ * Usage:
+ *   node phase0-exit-gate.mjs <task_id> [--input "<original user input>"] [--json]
+ *
+ * Exit codes: 0 = pass, 1 = gate failure (Phase 0 must not be closed), 2 = usage
+ *
+ * @module pipeline/scripts/phase0-exit-gate
+ */
+
+import { existsSync, readFileSync } from "fs";
+import { join } from "path";
+import { homedir } from "os";
+
+const FIGMA_URL = /figma\.com\/(design|make|file)\//i;
+
+/** Fields that can carry the user's original request text. */
+const INPUT_TEXT_FIELDS = [
+  ["input", "summary"],
+  ["input", "raw"],
+  ["issue", "body"],
+  ["issue", "title"],
+  ["jira", "summary"],
+  ["jira", "description"],
+  ["task", "description"],
+];
+
+/**
+ * Pull a nested value without throwing on a missing branch.
+ * @param {object} obj
+ * @param {string[]} path
+ * @returns {unknown}
+ */
+function at(obj, path) {
+  return path.reduce((acc, k) => (acc && typeof acc === "object" ? acc[k] : undefined), obj);
+}
+
+/**
+ * Collect every string in the state that could hold the original request, so a
+ * Figma reference is found wherever the input parser happened to store it.
+ *
+ * @param {object} state
+ * @returns {string}
+ */
+export function inputTextOf(state) {
+  const parts = [];
+  for (const path of INPUT_TEXT_FIELDS) {
+    const v = at(state, path);
+    if (typeof v === "string") parts.push(v);
+  }
+  // evidence[].url / figmaFrames[] are where the analysis phase parks references.
+  for (const key of ["figmaFrames", "designRefs"]) {
+    const v = state[key];
+    if (Array.isArray(v)) parts.push(v.map((x) => (typeof x === "string" ? x : JSON.stringify(x))).join(" "));
+  }
+  return parts.join("\n");
+}
+
+/**
+ * Evaluate the gate against a parsed state object.
+ *
+ * Kept pure and exported so the smoke can drive it without laying down a task
+ * directory: a gate that can only be tested by reproducing a full run does not
+ * get tested.
+ *
+ * @param {object|null} state - parsed agent-state.json, or null when absent
+ * @param {string} extraInput - input text supplied on the command line
+ * @returns {{ok: boolean, failures: string[], taskType: string|undefined, figmaSeen: boolean}}
+ */
+export function evaluate(state, extraInput = "") {
+  const failures = [];
+
+  if (state === null) {
+    return {
+      ok: false,
+      failures: [
+        "agent-state.json is missing. Phase 0 owns this file; without it taskType, " +
+          "maturity, account and repo resolution are all unreadable by later phases.",
+      ],
+      taskType: undefined,
+      figmaSeen: FIGMA_URL.test(extraInput),
+    };
+  }
+
+  const taskType = typeof state.taskType === "string" ? state.taskType.trim() : "";
+  if (!taskType) {
+    failures.push(
+      "agent-state.json has no taskType. Phase 3 branches on it: without the field " +
+        "a component task is dispatched as generic development (Step 7 of phase-0-init).",
+    );
+  }
+
+  const haystack = `${inputTextOf(state)}\n${extraInput}`;
+  const figmaSeen = FIGMA_URL.test(haystack);
+
+  if (figmaSeen && taskType && taskType !== "component") {
+    failures.push(
+      `the input carries a Figma URL but taskType is "${taskType}". Step 7 rule 1 makes ` +
+        `"component" mandatory here  -  otherwise the run skips the stack plugin's ` +
+        `token-compliance check, Code Connect publish and component review.`,
+    );
+  }
+
+  // The Figma access chain records which tier answered. A component task with no
+  // recorded tier means nothing verified that the design was actually reachable,
+  // which is how a run ends up guessing spacing.
+  if (figmaSeen) {
+    const tier = at(state, ["figmaAccess", "tier"]);
+    if (tier === undefined || tier === null || tier === "") {
+      failures.push(
+        "the input carries a Figma URL but state.figmaAccess.tier is unset. The 3-tier " +
+          "access chain must record which tier answered, so a later phase can tell " +
+          "'design confirmed' from 'design never fetched'.",
+      );
+    }
+  }
+
+  return { ok: failures.length === 0, failures, taskType: taskType || undefined, figmaSeen };
+}
+
+/** @param {string} taskId */
+function statePathFor(taskId) {
+  return join(homedir(), ".claude", "logs", "multi-agent", taskId, "agent-state.json");
+}
+
+function main(argv) {
+  const args = argv.slice(2);
+  const taskId = args.find((a) => !a.startsWith("--"));
+  if (!taskId) {
+    console.error("usage: phase0-exit-gate.mjs <task_id> [--input \"<text>\"] [--json]");
+    return 2;
+  }
+  const inputIdx = args.indexOf("--input");
+  const extraInput = inputIdx >= 0 ? (args[inputIdx + 1] ?? "") : "";
+  const asJson = args.includes("--json");
+
+  const path = statePathFor(taskId);
+  let state = null;
+  if (existsSync(path)) {
+    try {
+      state = JSON.parse(readFileSync(path, "utf-8"));
+    } catch (e) {
+      console.error(`phase0-exit-gate: ${path} is not valid JSON: ${e.message}`);
+      return 1;
+    }
+  }
+
+  const result = evaluate(state, extraInput);
+
+  if (asJson) {
+    console.log(JSON.stringify({ taskId, statePath: path, ...result }, null, 2));
+  } else if (result.ok) {
+    console.log(
+      `phase0-exit-gate: PASS (taskType=${result.taskType}${result.figmaSeen ? ", figma reference present" : ""})`,
+    );
+  } else {
+    console.error("phase0-exit-gate: FAIL  -  Phase 0 must not be marked completed");
+    for (const f of result.failures) console.error(`  - ${f}`);
+    console.error(`  state: ${path}`);
+  }
+  return result.ok ? 0 : 1;
+}
+
+if (import.meta.url === `file://${process.argv[1]}`) {
+  process.exit(main(process.argv));
+}

package/pipeline/skills/shared/core/multi-agent-dev/SKILL.md

@@ -62,3 +62,24 @@ Phase 7: Report     → Channels (Jira / Confluence / PR / Wiki)
 | Phase 5 User Test | ✅ | ✅ (same) |
 | Phase 7 channels (Jira / Confluence / PR / Wiki) | ✅ | ✅ (same) |
 | Duration | ~10-15 min | ~5-7 min |
+
+## Analysis doc supplied to a fast mode (warn before starting)
+
+The `--dev` family skips Phase 1 (Analysis) and Phase 2 (Planning) by design. So when
+the input references an analysis document  -  a Confluence URL, a local analysis file,
+or the user says "I ran analysis for this"  -  there is **no phase that turns it into a
+plan**. 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.

package/pipeline/skills/shared/core/multi-agent-dev-local/SKILL.md

@@ -34,3 +34,24 @@ Routes to the orchestrator with the `--dev --local` flags. The pipeline contract
 multi-agent-dev-local "PROJ-12345"                             # Jira
 multi-agent-dev-local "Bug: LoginView dark mode"               # Free-text
 ```
+
+## Analysis doc supplied to a fast mode (warn before starting)
+
+The `--dev` family skips Phase 1 (Analysis) and Phase 2 (Planning) by design. So when
+the input references an analysis document  -  a Confluence URL, a local analysis file,
+or the user says "I ran analysis for this"  -  there is **no phase that turns it into a
+plan**. 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.

package/pipeline/skills/shared/core/multi-agent-ios-coding-standard/SKILL.md

@@ -0,0 +1,258 @@
+---
+name: multi-agent-ios-coding-standard
+language: en
+description: "Audit an iOS module against the shared coding-standard registry (95 stable-ID rules), produce a remediation plan, then hand off to dev/dev-local. Use for a standards pass on a module, or when a review needs rule IDs rather than opinions."
+user-invocable: true
+argument-hint: "[module name or path]"
+---
+
+# multi-agent ios-coding-standard — Module audit → plan → dev handoff
+
+**Input**: $ARGUMENTS — optionally a module name or path. When absent, Phase 1 discovers and asks.
+
+This routine is the **procedure**. The rules live in the `ios-coding-standard` skill, whose registry is
+`references/rules.yml` and whose teaching doc is `references/STANDARD.md`. Load that
+skill first; it is installed on every host and carried by the iOS stack plugin, so
+there is one registry rather than a copy per CLI. Never restate a rule here — cite its ID. A rule that is not in the
+registry is not a rule; if the audit needs one, propose it as `status: proposed` and say so.
+
+Read-only + planning. This routine never edits source — the dev pipeline does.
+
+**Goal.** A developer new to the repo can open any file in the module and understand it without a
+guided tour, and nothing sensitive leaks on the way. Rank every finding by "does fixing this
+shorten the time to first productive PR, or close a real risk?"
+
+Render assistant-facing prose in `outputLanguage`. External payloads (branch names, plan file,
+dev task) stay English.
+
+---
+
+## Phase 1 — Discover and pick the module
+
+1. Repo root via `git rev-parse --show-toplevel`.
+2. **Discover module roots** — any directory with a `Package.swift`, a `Sources/` subtree or an
+   `.xcodeproj`. Sweep the container dirs that exist (`Domains/`, `Packages/`, `Modules/`,
+   `Features/`, `Core/`, `Common/`, top-level module dirs) one level deep, then two if empty.
+3. Record per module: name · path · Swift files · lines · governance docs present · SPM targets.
+   Keep this **module registry** for the whole run — `MOD-*` greps every import against it.
+   Classify each module's role, because the role decides which dependency edges are legal:
+   **feature** · **core/common** · **seam** (cross-module contracts/bridges/navigation) ·
+   **composition root** (legitimately knows every module).
+4. If `$ARGUMENTS` resolves to a module, skip the prompt. Otherwise `AskUserQuestion`
+   (single-select, `outputLanguage`), documented modules first, each option showing file/line
+   counts and `docs: yes/no`. If the list exceeds the question limit, group the smallest into an
+   "other" option and ask again — never truncate silently.
+5. Scope = the whole module's sources across all its targets, unless the user narrows it.
+
+## Phase 2 — Resolve what applies to THIS module
+
+### 2a. The registry is the standard — in-module prose docs are NOT consulted
+
+The skill's `references/rules.yml` (+ a project `modules/<Module>.yml` overlay) is the single source of truth. **Do not read, cite, or
+derive rules from a module's own `*-CLAUDE.md`, `docs/` set or any other in-repo prose.** They are
+being retired precisely so there is one place a rule can live; consulting them re-creates the
+split this command exists to remove. If such a file exists and contradicts the registry, that is a
+finding against the file, not against the code.
+
+The only in-repo inputs are **code and manifests**: sources, tests, `Package.swift`, `Info.plist`,
+the specs the generator reads, and the module registry from Phase 1.
+
+### 2b. Per-module overlay, then inference
+
+1. **`modules/<Module>.yml`** beside the project's own config carries what code cannot state: the vocabulary
+   bindings, the module's role, prohibitions that currently have **zero** instances, deliberate
+   carve-outs, name locks, and the real verification command. Registry-backed, so its findings may
+   be `blocking`.
+   *Why prohibitions need to be written down:* inference reads dominant patterns, and a rule
+   obeyed everywhere has no counter-example to infer from. A ban at 100% compliance is invisible
+   to a scan — it survives only if the overlay states it.
+2. **Repo-level rules** (root `CLAUDE.md`, contributing docs) apply to every module.
+3. **The module's own dominant pattern is its de-facto convention.** Count variants per dimension;
+   the minority instances are the finding. Internal consistency beats conformity to a sibling.
+4. No majority (even split, single instance) → not a finding. Record an Open Question.
+
+Findings from step 3 are tagged `inferred` and capped at **suggestion**. Only registry- or
+overlay-backed rules may be `blocking`.
+
+**When the overlay is missing**, generate a draft from code evidence, print it for confirmation,
+and mark every slot it could not derive — a frozen UI target, a name lock, a carve-out and an
+operational constraint all look like ordinary code from the outside. Do not guess them; list them
+as Open Questions.
+
+### 2c. Vocabulary
+
+Bind each slot to a real symbol by grepping the module, then the reference module. **An unbound
+slot disables its rules** — never invent a name, never import a sibling's.
+
+`HandlerName` · `EventParam` · `CoordinatorType` · `ResultType` / `ErrorType` / `ErrorFactory` ·
+`DIResolver` / `DIConfigurator` · `RequestModelSuffix` / `ResponseModelSuffix` / `TransportSuffix` ·
+`MapperShape` · `SafeEnumProtocol` / `UnknownCase` · `CopySurface` · `AnalyticsSurface` ·
+`A11yIdentifierSource` · `GeneratedServiceRoot` · `SharedComponentsDir` / `SharedEntitiesDir` ·
+`MicroComponentLibrary` · `FrozenUITarget` · `DesignTokenNamespaces` · `CalendarDayHelper` ·
+`LoggerAPI` · `FileHeaderShape` · `ScreenRoot` · `ScreenRoleSuffixes` · `AsyncStyle` ·
+`CompositionRoot` · `SeamLayer` · `ModuleEntrySurface` · `ConcurrencyPosture` · `LintToolchain` ·
+`CredentialStore` (the module's Keychain wrapper, if any).
+
+Print the resolved table before scanning so a wrong binding is caught early.
+
+### 2d. Sensitive-data inventory — required before any SEC rule runs
+
+The `SEC-*` rules are written against the **data classes** in `references/rules.yml →
+sensitive_data_classes`, never against one module's field names. Resolve the module's concrete
+instances of each class: grep entities, request/response models, storage calls and analytics
+events for the values the module actually handles, and map each to its class.
+
+Produce the inventory as a table — **class · concrete symbols · where it enters · required
+lifetime (transient / survives-restart / survives-reinstall) · where it is actually stored ·
+where it is logged · where it leaves (network, analytics, pasteboard, another module)**.
+
+The **lifetime column is the one that decides SEC-01**, and it is filled by walking
+`references/rules.yml → persistence_decision`, not by looking at what the code currently does. Compare it
+against the storage column and report both mismatches:
+- required transient but persisted anywhere (including the Keychain) → **over-persistence**;
+- required to survive a restart but stored outside the Keychain → **under-protection**.
+
+Then generate the SEC lint patterns *from this inventory*, so the checks match this module's real
+vocabulary. A class with no instance here yields no finding; a symbol you cannot classify, or one
+whose required lifetime nobody can state, is an Open Question, not a silent pass.
+
+This table is a deliverable in its own right, independent of whether any violation is found.
+
+## Phase 3 — Scan
+
+Apply the rules in `references/rules.yml` that survived Phase 2 binding, plus the module's own `validation`
+gate. Tag every finding: **rule ID · severity · source (`registry` / `doc` / `inferred`) ·
+onboarding impact (high/medium/low)**.
+
+### Coverage gate — on disk, not in memory
+
+Before scanning, write `.<module>-audit-coverage.tsv` to the scratch dir: one row per target
+(every screen under `ScreenRoot`, every shared component, every entity, every file in every
+target) with columns `path · status · rules-applied`. Mark rows as you go.
+
+- Each target is **audited** or **explicitly skipped with a reason** (generated, fixture,
+  vendored). No third state.
+- **The run is incomplete while any row is unmarked** — and the file, not a claim, is the proof.
+  Chunk the module if it is too large for one pass; the checklist survives a context reset.
+- No sampling. A partial audit reported as complete certifies the unscanned screens as clean.
+
+### Grep hygiene
+
+Registry `mechanism` patterns are line-based and match doc comments. Filter
+`^[[:space:]]*//` — BSD grep does not understand `\s`, so a `\s*//` filter silently lets `/// …`
+through — then open each surviving hit and confirm it is real code. Report pre-filter and
+post-verification counts separately; a table padded with comment matches destroys trust.
+
+### Judgement rules need evidence, not assertion
+
+For any rule marked `enforcement: judgement`, a finding must carry the measurement its `check`
+names — a reference count, a call-site count, a consumer count, a file list. **No count, no
+finding.** This is what keeps a subjective rule from becoming an opinion.
+
+Every judgement rule has a worked ✗/✓ pair in `EXAMPLES.md`, keyed by ID. Cite it in the finding's
+proposed fix rather than re-describing the shape — the developer applying the fix should be
+reading the same picture the audit used.
+
+### Module-specific overrides
+
+The module's own docs win over the registry, including where they contradict a sibling module.
+Never apply one module's dialect to another. List every override honoured, so the reader sees why
+a registry rule was not raised.
+
+## Phase 4 — Produce the plan
+
+No findings → report compliant and stop. Otherwise write
+`<ModulePath>/ios-coding-standard-plan-<module>.md` (or the repo's scratch/docs dir if the module
+tree must stay clean), containing, in order:
+
+1. **Coverage ledger** — total targets · audited · skipped with reasons. Not 100% accounted for
+   means the plan is not deliverable.
+2. **Summary** — counts by severity and source, resolved vocabulary, branch to create.
+3. **Sensitive-data inventory** (Phase 2d) — first, because it is the highest-risk content.
+4. **Screen × role matrix** `[STRUCT-02]` — screens as rows, manifest roles as columns, cells
+   `✓ / missing / misplaced`. The structural map a newcomer reads first.
+5. **Type placement table** `[STRUCT-05]` — type · location · consumer count · correct tier ·
+   move required. Paired with the nested-type list `[STRUCT-01]`: owner · nested type · kind ·
+   reference count · verdict.
+6. **Visibility report** `[VIS-01, VIS-02]` — over-exposed declarations per file, non-final
+   classes with no subclass.
+7. **Boundary report** `[MOD-*]` — import graph (allowed vs forbidden, with coupling depth) ·
+   manifest graph (declared vs legal for the role, plus dead edges) · **removability delta**
+   ("removing X touches N files: …") · inbound test (tests compile with no sibling present).
+8. **Testability seam report** `[TEST-*]` — types reaching for the environment, logic requiring a
+   view to execute, doubles whose signatures have drifted.
+9. **Change-cost probe** `[FLEX-*]` — pick two plausible upcoming changes (a new variant of an
+   existing screen; a new field on a shared entity) and state what each costs in files today.
+10. **Findings table** — rule ID · `file:line` · current state · proposed fix · severity · source ·
+    onboarding impact.
+11. **Per-file work** — grouped per file, blocking → important → suggestion; within a severity,
+    highest onboarding impact first.
+12. **Behaviour-preservation guard** — splitting files, adding MARKs, extracting extensions and
+    moving types must not change behaviour. Anything requiring a behaviour change (a missing
+    analytics event, a wrong result type, a timezone fix, a storage migration) goes in a
+    **separate group**, reviewed and tested on its own, never inside a mechanical split commit.
+13. **Tooling delegation & the ratchet** — the section that decides whether any of this survives.
+    - Classify each applied rule by its registry `enforcement`. For every `lint` / `format` /
+      `scan` rule, state the concrete mechanism and whether that toolchain exists in the repo
+      (`LintToolchain`). **When it does not exist, saying so is a finding**, ranked above most
+      individual violations it would have caught.
+    - Recommend **baseline-and-ratchet, never big-bang**: grandfather existing violations, surface
+      only new ones, drain the backlog behind a green build. Order the plan the same way — stop
+      the bleeding, then clean up.
+    - Custom lint rule identifiers **are** the registry IDs (`sec_01_no_plaintext_persistence`,
+      `mod_01_no_sibling_import`) so a violation points straight at the rule entry.
+    - **Linting is local-only by decision** — the skill's `references/lint-local.sh` with `references/swiftlint.draft.yml`, config
+      and baseline kept outside the repository; no committed config, no build phase, no CI job.
+      State this honestly in the plan rather than describing a gate that does not exist: a
+      pre-PR habit catches less than a wall, so the residual risk is real and belongs in the
+      report. Adopting it project-wide remains an open decision — record it as one so it stays
+      visible instead of quietly lapsing.
+    - Never imply the audit substitutes for the linter, or the linter for a gate. The audit finds
+      the debt once; the linter keeps a developer honest; only a gate stops it returning.
+14. **Numeric exit criteria** — target and today's measured value side by side: lint violations
+    per 1k lines (<1) · public-surface ratio, public declarations ÷ externally consumed symbols
+    (≈1) · forbidden cross-module imports (0) · removability delta · files over threshold and
+    files >120 lines with no sectioning (0) · screens missing a manifest role (0) · escape-hatch
+    count `[CONC-03]` (flat or falling) · exception-marker count (flat or falling) · dead code (0)
+    · screens with logic and no mirrored tests (0) · unclassified sensitive symbols (0).
+15. **Exception ledger** — every `// standard:exception(<ID>)` in the module: rule · reason ·
+    expiry · expired yes/no.
+16. **Open Questions** — Phase 2b dimensions with no majority, and unclassifiable symbols.
+17. **Suggested commit slicing** — one commit per file-group / concern.
+18. **Scope guard** — only this module is touched; definition of done is the module's own
+    verification path.
+
+Then write a **separate one-page onboarding summary** beside the plan, aimed at a developer
+joining next week rather than at whoever does the remediation: the ten always/never lines
+specialised to this module, the screen file manifest, the placement ladder, the sensitive-data
+classes in play, and the verification command. Nobody learns a codebase from a 40-finding audit —
+this page is the actual deliverable, and the audit is how you earn the right to write it
+accurately. Derive it from `references/STANDARD.md § 0`, do not re-invent it.
+
+Show a concise version of the plan to the user too.
+
+## Phase 5 — Hand off
+
+`AskUserQuestion` (single-select, `outputLanguage`):
+
+| Option | What it does |
+|---|---|
+| `/multi-agent:dev-local` | No worktree; branches from the main development branch, fixes on the current checkout |
+| `/multi-agent:dev` | Opens a worktree; Opus fixes on a fresh branch + PR |
+
+Invoke the chosen command with the plan file as the task input, branching off the repo's main
+development branch (e.g. `chore/<module>-coding-standard`). The dev pipeline applies the fixes,
+verifies, and commits only when asked. This routine ends at the handoff.
+
+## Notes
+
+- **Verification reality is per-module — establish it, do not assume it.** Some targets cannot be
+  compiled from the CLI (asset symbol generation, UIKit-dependent packages, a dependency failing
+  earlier in the graph); there, verification is Xcode and a manifest dump validates the manifest
+  only. Never trust a piped build's exit code — a pipe reports the tail's status. Record the
+  module's actual verification command in the plan.
+- One module per run. Several modules means several runs and several plans, never one
+  cross-module churn commit.
+- If the audit wants a rule the registry lacks, add it to the skill's `references/rules.yml` as `status: proposed` with a
+  rationale and surface it in Open Questions. Do not enforce an unregistered rule.
+- No AI attribution anywhere (code, commits, PRs). Author = git identity.

package/pipeline/skills/shared/core/multi-agent-sync/SKILL.md

@@ -31,8 +31,8 @@ Run all steps automatically:
 
 ```
 Step 1: DETECT      Compare timestamps, find stale targets
-Step 2: COPILOT     Claude Code -> Copilot CLI (instructions + 43 sub-command skills)
-Step 2b: CODEX      Claude Code -> Codex CLI (1 router skill + 43 specs as refs + 8 agent TOML)
+Step 2: COPILOT     Claude Code -> Copilot CLI (instructions + 44 sub-command skills)
+Step 2b: CODEX      Claude Code -> Codex CLI (1 router skill + 44 specs as refs + 8 agent TOML)
 Step 3: REPO        Claude Code -> pipeline repo (genericized, personal data scrub)
 Step 3d: DEV-TOOLKIT Companion MCP server -> detect movement, ship gates, commit + publish
 Step 4: WEBSITE     Version + phase/model counts -> {website-host} (i18n + projects.ts)
@@ -223,12 +223,12 @@ When invoked with the `release` argument:
 |-------------|-------------|
 | `~/.claude/commands/multi-agent/{cmd}.md` | `~/.copilot/skills/multi-agent-{cmd}/SKILL.md` |
 
-**43 commands are synced** (canonical inventory  -  must match `cross-cli-contract.md` section 1; drift = contract violation):
+**44 commands are synced** (canonical inventory  -  must match `cross-cli-contract.md` section 1; drift = contract violation):
 
 ```
 analysis, analysis-resolve, autopilot, build-optimize, channels, create-jira, design-check, dev,
 dev-autopilot, dev-local, dev-local-autopilot, diff-explain, finish, forget, garbage-collect,
-help, issue, jira, kill, language, local,
+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, stack, status, sync, test, testflight-validation, uninstall, update
 ```