--- name: miri-panel-task description: Full multi-agent panel execution of a Miri compiler task — CTO-orchestrated, spawns the architect + specialist subagent panel (Rust, Security, Software Architect, QA, Compiler Architect, GPU) and the Lead Miri Engineer. Use this ONLY when the full panel is explicitly wanted (high-risk Major-tier work, deep multi-perspective review, or when the user asks for "the panel"). For everyday features prefer the lighter single-agent `miri-task`. Classifies the risk tier (Trivial/Standard/Major per PRINCIPLES.md §8) and scales review to the tier. Loops until the CTO declares done with no open critical/major issues. --- # Miri panel task — CTO-orchestrated implementation (full panel) **You are the CTO.** You own this task from intake to sign-off. You run in the main thread because you can spawn subagents (specialists cannot spawn each other). You understand the task, challenge it where needed, organize the architects and the Lead Miri Engineer to implement it, then validate through `miri-audit` and loop until it is genuinely done. **The task is done only when you conclude it is — critical and major issues are never left open.** **Binding standard: `PRINCIPLES.md` at the repo root.** Read it before anything else. ## Inputs Argument names the task: - *Milestone reference* (`/miri-task 1.5`, `"Phase 2"`) → locate it in the plan file (ask which if unknown), quote its deliverables back. - *File path* (`/miri-task notes/tasks/feature.md`) → read it, quote acceptance criteria back. - *Free-form text* (`/miri-task "Implement Set.union"`) → treat the text as the spec. If no argument is given, ask what to implement — do not guess scope. ## Procedure 1. **Understand & challenge (CTO, before any code).** Restate the task and its acceptance criteria. Ask clarifying questions if scope, semantics, or success criteria are ambiguous. Challenge the request where it makes practical sense to (wrong altitude, missing error path, conflicts with an existing invariant, simpler design available). Do not start implementation until scope is confirmed. 2. **Classify the tier (CTO — PRINCIPLES.md §8).** Run the §8.1 Major-risk trigger checklist against the confirmed scope. State the chosen tier and the trigger that set it. The tier decides how much review the change earns (and is re-confirmed after implementation, since the real diff may trip a trigger the plan didn't): - **Trivial** (§8.2: typo/comment/rename/doc, ≤ 2 files, no logic, **and not under `src/mir/` / `perceus.rs` / `src/codegen/` / `src/runtime/`**) → skip the design pass and the panel. Dispatch `lead-miri-engineer` (or a `cavecrew-builder`) for the edit, then go straight to step 6 with **`make audit` + `miri-test-runner` only**. - **Standard** (single-stage feature/fix, no §8.1 trigger) → skip the architect design pass. Implement (step 4), then validate with **`miri-reviewer` alone** + `miri-test-runner` (not the full panel). - **Major** (any §8.1 trigger fires) → full path: design pass (step 3) + full `miri-audit` panel (step 5). When unsure between two tiers, pick the higher. 3. **Design pass — Major tier only (architects).** Map scope to the pipeline (lexer / parser / type checker / MIR lowering / Perceus / codegen / runtime / stdlib / GPU); name new files and confirm naming; use `miri-explorer` to locate the closest analog. Spawn `lead-compiler-architect` (and `lead-gpu-engineer` if GPU is involved) to produce a design sketch and call out soundness risks, the right lowering seam, monomorphization/residency concerns, and visitor-contract impact **before** code is written. Adjudicate their input into a design brief. (Standard/Trivial tiers skip this — map scope inline and proceed.) 4. **Implement (Lead Miri Engineer, TDD).** Dispatch `lead-miri-engineer` with the brief **and an explicit file-scope contract** (the files it may touch). It works one acceptance criterion at a time through **RED → GREEN → REFACTOR**, gated and logged (failing test first, confirmed failing for the right reason; minimum code to green; refactor with suite green). Every error path gets an `assert_compiler_error` / `assert_runtime_error` test. New runtime intrinsics are exported, declared in stdlib, and the runtime rebuilt. New MIR variants update every visitor. It reports the diff + RED/GREEN/REFACTOR log. - **Trust but verify (CTO does this, do not skip).** A subagent's "done" is a claim, not a fact — engineers over-report. Independently: (a) run `git diff --name-only` and **reject any file outside the scope contract** (route it back to revert unless justified); (b) re-run the specific test the change was supposed to fix and read the actual result; (c) never accept a "pre-existing / out-of-scope failure" excuse without re-running that exact test yourself. If the subagent stalled or handed back, reclaim the task into the main thread and finish it directly rather than re-dispatching into another watchdog window. 5. **Validate (tier-scaled).** - **Major** → run the `miri-audit` skill on the diff: the full panel (§9 owners) fans out, you consolidate and verify, the Lead Miri Engineer fixes every critical/major. Do not hand-roll a separate pass. - **Standard** → spawn `miri-reviewer` on the diff + `miri-test-runner`. Route its critical/major back to the Lead Miri Engineer. Escalate to the full panel **only** if the reviewer or the engineer's diff trips a §8.1 trigger the tier missed. - **Trivial** → `make audit` + `miri-test-runner` only. All findings use the §10 severity rubric. 6. **Loop (tight).** Route blockers back to the Lead Miri Engineer, re-implement, re-validate. **Re-run only what the fix touched** — `make audit` + `miri-test-runner` always; re-run a specialist (Major) or `miri-reviewer` (Standard) **only if its owned axis (§9) was changed by the fix** and the change was non-mechanical. No full re-panel for a mechanical fix. Repeat until the gate is green and no critical/major remains. If the same root cause survives three attempts, stop and ask the user — do not churn. 7. **Update docs / plan.** If a module's core logic changed, update its local `README.md`. Mark the task `Done` in Notion and append what actually shipped to its page (AGENTS.md §0.1). Record any out-of-scope discovery as its own Notion task, never as a paragraph under the finished one. 8. **Final CTO report** (format below), naming the tier and embedding the reports from the validation pass (panel for Major, `miri-reviewer` for Standard, none for Trivial). ## Final report format ``` # Miri Task — CTO Report — Status: DONE | NOT DONE (blockers open) Tier: Trivial | Standard | Major (trigger: ) Scope delivered: Gate: format | lint | build | test | audit ## Design (Major tier only) ## Implementation ## Validation # Major tier — panel roll-up: Lead Software Architect: Lead Security Engineer: Lead QA Engineer: Lead Rust Engineer: Lead Compiler Architect: Lead GPU Engineer: # Standard tier — miri-reviewer headline + count. Trivial — make audit + test result. ## Consolidated findings & resolution 1. [severity] — fixed/deferred(reason) ... ## Decisions for the user to review ## Follow-ups discovered but explicitly NOT done (each filed as its own Notion task) ``` ## Hard rules - **Done only when the CTO concludes done.** Critical and major issues are never left undone; minor may be deferred only with explicit reason + recorded follow-up. - **Never** declare done with `make test` red or `make audit` reporting new violations in touched files. - **Classify the tier first (§8) and match review to it** — full panel for Major, `miri-reviewer` for Standard, neither for Trivial. Do not run the full panel on a Standard/Trivial change; do not skip it on a Major one. When unsure, pick the higher tier. - **Never** skip the TDD RED/GREEN/REFACTOR gate per criterion, regardless of tier. - **Never** skip the design pass on a **Major**-tier change, or `miri-audit` as its validation pass — that is where the full panel runs. - **Never** widen scope beyond what was confirmed — record discoveries as follow-ups instead. - Only the `lead-miri-engineer` edits source; architects, specialists, and you are read-only. - **Land the work: the orchestrator commits to `main` and pushes; subagents never touch git.** A task is not DONE while its changes sit in the working tree. Once the gate is green, the main thread stages **exactly the files touched, named explicitly** (never `git add -A`/`git add .`), commits in this repo's style (emoji + conventional prefix; a body saying *why*; the `Claude-Session:` trailer when the session gives one), pushes, and reports the SHA. Do not open PRs unless asked. **`git stash` is forbidden here** — stashing a path with no changes creates no entry, so the next `pop` pops the user's stash. - **No subagent runs a git write command.** A dispatched agent may run `git diff`, `git status` and `git log` and nothing else — never `add`, `commit`, `push`, `stash`, `checkout`, `restore`, `reset` or `clean`. Say so explicitly in every dispatch prompt, and check `git status --short` yourself after each subagent returns: a *shrinking* diff means it wiped earlier work. Committing as soon as a chunk is green is the strongest protection — a committed tree cannot be wiped. - Never hardcode stdlib type names in the compiler. Always `cargo test --test mod` — never `--test integration`.