@mmerterden/multi-agent-pipeline 12.11.0 → 13.1.0

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

@@ -218,11 +218,42 @@ Launch Agent instances **in parallel** using the shared `code-reviewer` subagent
 
 **Scope from Step 1.77.** `$REVIEW_SCOPE == "single"` → dispatch **Reviewer 1 only**, and skip Step 2.5 + 3.6 (both no-ops with one reviewer). `"full"` (default + fail-safe) → the whole set below. Either way record the count in `consensus.reviewerCount`.
 
-| Reviewer   | subagent_type     | Model               | Focus                             | Skills Referenced                             | Where it runs        |
-| ---------- | ----------------- | ------------------- | --------------------------------- | --------------------------------------------- | -------------------- |
-| Reviewer 1 | `code-reviewer`   | `claude-fable-5` (Claude Code) / `claude-opus-4-8` (Copilot CLI) | Deep security + architecture      | `api-security-best-practices`, `architecture` | Both CLIs            |
-| Reviewer 2 | `code-reviewer`   | `gpt-5.4`           | Edge cases, different perspective | cross-model diversity                         | **Copilot CLI only** |
-| Reviewer 3 | `code-reviewer`   | `claude-sonnet-4-6` | Quality + correctness + naming    | `clean-code`, stack-specific skill            | Both CLIs            |
+| Reviewer   | subagent_type   | Claude Code | Copilot CLI | Codex CLI | Focus | Skills Referenced |
+| ---------- | --------------- | --- | --- | --- | --- | --- |
+| Reviewer 1 | `code-reviewer` | `claude-fable-5` | `claude-opus-4-8` | `gpt-5.6` @ `xhigh` | Deep security + architecture | `api-security-best-practices`, `architecture` |
+| Reviewer 2 | `code-reviewer` | (not dispatched) | `gpt-5.4` | `gpt-5.4` @ `high` | Edge cases, different perspective | cross-model diversity |
+| Reviewer 3 | `code-reviewer` | `claude-sonnet-4-6` | `claude-sonnet-4-6` | `gpt-5.6` @ `medium` | Quality + correctness + naming | `clean-code`, stack-specific skill |
+| Triage     | triage persona  | `claude-fable-5` | `claude-opus-4-8` | `gpt-5.6` @ `max` | Filter false positives + out-of-scope | - |
+
+Reviewer count per host: **Claude Code 2, Copilot CLI 3, Codex CLI 3**.
+
+#### Codex CLI  -  two constraints that fail silently
+
+Both were measured against Codex 0.145, not inferred. Getting either wrong produces
+a review that looks like it ran.
+
+1. **Every `spawn_agent` that sets `model` or `reasoning_effort` MUST pass
+   `fork_turns: "none"`** (or a positive integer). Codex states that a full-history
+   fork "inherits the parent model and reasoning effort and does not accept
+   overrides"  -  so omitting `fork_turns` silently collapses the whole panel onto
+   the orchestrator's model, with three reviewers reporting from one perspective
+   and no error anywhere.
+2. **Three concurrent children is the ceiling.** Codex advertises 4 concurrency
+   slots *including the orchestrator*, so a 3-reviewer panel saturates it and a 4th
+   child queues instead of running in parallel. The reviewer count on Codex is
+   capability-derived, not a preference.
+
+Codex also refuses to spawn sub-agents at all unless instructions ask for it
+explicitly; the pipeline's `~/.codex/AGENTS.md` managed block carries that
+authorization. Without it Phase 4 degrades to a single in-thread review.
+
+**Single-vendor caveat.** Every Codex reviewer is an OpenAI model, so the
+cross-vendor disagreement that Claude Code and Copilot CLI get for free is absent.
+The diversity budget shifts to reasoning effort and persona focus: Reviewer 1 runs
+`xhigh` on security and architecture, Reviewer 2 runs a different model family
+member on edge cases, Reviewer 3 runs `medium` on quality. Treat consensus among
+them as weaker evidence than the same consensus on a two-vendor host, and say so
+in the triage note when all three agree on a borderline finding.
 
 Each reviewer inherits the `code-reviewer` agent's focus areas (Security, Architecture, Quality, Performance) and output contract. The orchestrator overrides only the model and the stack-specific skill per-reviewer  -  no prompt duplication.
 
@@ -241,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/multi-agent-refs/progress-contract.md

@@ -129,7 +129,7 @@ Every phase that dispatches a billable LLM agent MUST forward the call's token t
 
 ```bash
 LOG_METRIC_FORWARD_TO_TRACKER=1 pipeline/scripts/log-metric.sh "$TASK_ID" <phase-id> <event> \
-  model=<fable|opus|sonnet|haiku|gpt-5.4> \
+  model=<fable|opus|sonnet|haiku|gpt-5.4|gpt-5.6|gpt-5.6-terra> \
   tokens_in=$IN tokens_out=$OUT duration_ms=$DUR
 ```
 

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

@@ -24,7 +24,8 @@ The agent detects which CLI it's running in and uses the appropriate visual mech
 ```
 1. system prompt mentions "Claude Code"             → claude-code
 2. system prompt mentions "Copilot" / "GitHub Copilot" → copilot
-3. None of the above                                 → generic (bash stdout)
+3. system prompt mentions "Codex"                    → codex
+4. None of the above                                 → generic (bash stdout)
 ```
 
 Visual mechanism per CLI:
@@ -33,12 +34,27 @@ 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. |
+| **codex** | The native `update_plan` tool: one plan step per phase, `status: pending \| in_progress \| completed`. Rewrite the whole step list on each boundary  -  the tool takes the full plan, not a delta. |
 | **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.
 
 **Claude Code only**: in addition, `TaskCreate` / `TaskUpdate` native tool calls → the sticky widget pins the phase stack in the user's view.
 
+### Codex specifics
+
+Two constraints on `update_plan`, both of which fail quietly if ignored:
+
+- **Never call it in parallel with another tool.** Codex states this explicitly. A
+  phase boundary that batches `update_plan` alongside other calls loses the update.
+- **It is unavailable in Codex plan mode.** Fall back to
+  `bash phase-tracker.sh render` there rather than skipping the visual channel.
+
+The plan step is the phase label, not a restatement of the work: `Phase 4  -  Review`
+in the step list, with detail going to the agent log. A plan that mirrors the phase
+list is legible; one that mirrors the task list duplicates what the log already
+holds.
+
 ## Call pattern
 
 At every phase boundary the agent takes **two steps**: