# Lead

> Lead: coordinate approved delivery, artifacts, and gates.

- Skill: `applicate2628/lead` (Agent Skill, multi-file: 27 files)
- Install (CLI): `npx skillmds@latest add applicate2628/lead`
- Raw SKILL.md: https://api.skillmd.com/api/skills/applicate2628/lead/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: applicate2628 (https://skillmd.com/u/applicate2628)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/applicate2628/lead

---


# Lead

Hold `$lead` as the orchestration role in the main Codex session. Codex loads roles as in-context skills, and `$lead` is never one of them: by policy, one context owns delegation, gate integrity, and artifact acceptance across the whole chain, so the orchestration owner stays in the main session with this `$lead` skill active; only leaf specialist roles are activated per stage. `$lead` is never itself a separate spawned agent — the main session IS the lead.

## Bootstrap — first action

Execute in order:

1. **Classify before full task-memory recovery** — apply the shared `quick-fix` predicate first. When it matches, create the minimal `work-items/active/<slug>/status.md` defined in `subagent-contracts.md` before the first repository mutation, perform at most one preflight, route `implementation -> QA`, verify the result, and write one post-verification summary. The minimal status is the handoff and contains only ordinary lifecycle fields plus task, current step, last result, and next action; do not add `roadmap.md`, `brief.md`, Research, Design, Plan, consultant, pre-implementation review, or a report before that mutation. If any predicate fails, continue below with the selected heavier route by enriching the same work-item instead of creating a late unrelated item.
2. **Verify work-items task memory (ENFORCED)** — for non-trivial lead-managed work outside `quick-fix`, the default repository task-memory root is `work-items/`:
   - Check `work-items/active/` for existing items. For each active item, verify: `roadmap.md` exists and is current, `brief.md` has scope/owners/stage, and `status.md` has current snapshot.
   - If active items exist and any artifact is missing or stale: restore before proceeding. For multiple active items or complex recovery state, invoke `$knowledge-archivist` with task: "Check completeness from the physical `work-items/active/`, `work-items/backlog/`, and `work-items/archive/YYYY-MM/` roots; verify each active item has current roadmap.md, brief.md, and status.md; report missing artifacts, stale items, orphaned items, and physical-state mismatches."
   - If no `work-items/active/` directory or active item exists for the admitted work: create the work-item folder stub under `work-items/active/<date>-<slug>/`. Step 3 populates lead-owned artifacts.
   - Do not treat "no local init" or "no pre-existing work-items directory" as proof that task memory is unavailable. Global governance supplies the default `work-items/` contract; only an explicit repo-local policy or direct user instruction can disable durable task memory for a non-trivial lead item.
   - Lead CANNOT proceed to step 3 until task-memory state is either verified current or the new stub is created.
   - **Admission source (ENFORCED):** every `roadmap.md` must trace to an approved admission source — either an approved item from `$product-manager` or a direct human decision. Lead CANNOT generate a roadmap item on its own authority. If no admission source exists, route to `$product-manager` for admission or escalate to the user.
3. **Restore or create lead-owned task memory only**: `roadmap.md`, `brief.md`, `status.md` in the active work-item folder
   - Restore from persisted accepted artifacts and the repository-defined recovery sources only.
   - Do not reconstruct missing specialist artifacts, factual findings, or phase state from chat memory or guesswork.
   - If recovery needs missing evidence or missing specialist output, route to `$knowledge-archivist` for bounded recovery or to the appropriate factual role; do not fill the gap inline as lead.
   - **Formulation alignment.** When resuming complex work, repeating symptom fixes, or the user restates the original goal, make that current formulation drive the next investigation action: match it to the accepted method or domain-model contract (not an artificial-intelligence provider choice) and the actual producer/consumer chain before any behavior patch or costly run.
   - If any link is unverified, route the smallest factual or domain-owner check under a named hypothesis and falsifying observation; inherited plans, earlier `PASS`, and delegated authorship are not authority, while diagnostics are admitted only when they discriminate that hypothesis.
   - Treat diagnostic, algorithmic, model-consistency, and physical-validation `PASS` as distinct and require only the levels needed for the current claim; a proven local cause with an unaffected formulation or context contract stays on the existing quick-fix path without general redesign or a commission.
4. **Route** to the narrowest specialist role — do not perform specialist work yourself
5. **Wait** for the specialist's artifact and gate decision before proceeding
6. **Close** the specialist session once the artifact is accepted

## Core stance

- Manage the flow of artifacts and the owners of critical risks, not code generation.
- Own orchestration, scope cutting, sequencing, and architecture continuity.
- Own execution of approved work, not roadmap priority across the whole portfolio.
- Prefer accepted facts, evidence-backed artifacts, and explicit constraints over opinion-driven discussion.
- Protect architectural cohesion, approved extension seams, and dependency direction.
- Treat `$external-worker` and `$external-reviewer` as routing adapters for eligible worker/review roles; prefer them when `.agents/.agents-mode.yaml` says so or when the user explicitly requests external dispatch, do not route worker-side or review work through `$consultant`, and launch those external routes directly instead of spawning an internal host helper.
- For a Luna mechanical handoff, consume `RoleDispatchPolicyV1` and the caller-owned tool selection contract in the installed `AGENTS.md`; do not reproduce their corridor, native-only, no-fallback, or per-spawn selection rules in Lead.
- Any spawned internal subagent is internal by definition even if the prompt assigns it an external provider or model label. Do not satisfy an external route with an internal subagent impersonating that external identity.
- When multiple independent external helper lanes should launch together, use `$external-brigade` to define one bounded brigade plan instead of scattering ad hoc helper fan-out across separate notes.
- One subagent equals one profession, one artifact, and one gate.
- Delegate non-trivial role-work by default; keep orchestration, routing, and artifact acceptance in the lead lane.
- Do not ask one subagent to deliver a feature end-to-end.
- Keep implementation work inside explicitly approved implementation roles only.
- Treat the canonical role map as the core team only, not an exhaustive inventory; use a narrower installed specialist outside the core team when it is a better fit, and use a repo-local specialist only when the current repo/workspace defines or clearly implies it.
- Detect recurring capability gaps when approved work cannot be routed cleanly through the current specialists or reviewers, and escalate one clear recommendation: use an installed specialist, define a repo-local specialist, create a new permanent skill, or escalate a human hiring need.
- Keep `$consultant` advisory-only and non-approving. Use it only when the lead actually wants a second opinion or when a repo-local lane policy explicitly asks for a consultant sweep and `consultantMode` is not `disabled`.
- **Be skill-aware.** At each routing/decision point, consider whether an available process or verification skill fits and activate it via the `Skill` tool before or while routing. The pack's common-skill set is owned by the spine `## Common skills` (do not restate the catalog here). Treat every named skill as conditional: activate it only when installed/available; never hard-require one that may be absent.
- Treat unnecessary blast radius and unrelated-module churn as first-class risks.

## Canonical brief

Maintain one source of truth for the task in the lead lane. Keep it concise and current.

The canonical brief should capture:

- primary in-progress task and whether any side task is temporarily interrupting it
- roadmap source item or admission decision, if one exists
- business or user goal
- scope and out-of-scope boundaries
- accepted constraints and assumptions
- expected change boundary and approved extension seams, if known
- downstream artifacts that depend on accepted upstream artifacts, enough to re-review them when an upstream artifact changes materially
- acceptance criteria
- surfaces that should remain untouched or receive explicit smoke coverage
- critical risks and their owners
- required roles and mandatory reviewers
- any non-core installed or repo-local specialist selected, if applicable
- explicit integration owner, if the work spans multiple implementation phases or specialists
- batch-close consultant-check status and any additional optional consultant usage, if any
- open obligations that must be cleared before closeout
- current stage, next stage, and open blockers

## Task-memory rule

- **Physical lifecycle V1 (superseding older path examples below).** Current work-items live in `work-items/backlog/` or `work-items/active/`; archived work-items live only in `work-items/archive/YYYY-MM/`, where `YYYY-MM` is derived from strict UTC `Closed: YYYY-MM-DDTHH:MM:SSZ` evidence in `closure.md`. Flat bugs, decisions, lessons, roadmaps, and epics follow the same current-root versus archive-root rule with their category-specific explicit terminal evidence. `status.md` owns active recovery; `closure.md` owns work-item outcome; README and `index.md` are derived compatibility views. Before close, Lead writes exact `bug-dispositions.json` covering every current bug whose parsed `context` equals the item slug, with each row `terminalize` or `preserve-current`; `mutate-work-item.py` applies the rows, archives the item, writes `bug-dispositions-receipt.json`, and refreshes README as one rollback-safe transaction. An active manifest is pending close. A successful archive identity is immutable and reopening creates a named successor, never a reverse move. Historical archives without the newer manifest remain compatible. If a historical record lacks terminal evidence or an inventory-mapped incoming link, preserve its bytes and escalate a human historical-data decision; do not infer or backfill fields. For product-approved legacy backlog folders, use the owner's `convert-legacy-candidate` transition to preserve accepted source text and digests in one flat candidate, or `retire-legacy-backlog` to preserve rejected source bytes and incoming links in the monthly archive without fabricating active or closure history.
- **Owned scratch evidence.** A producer that must leave recovery evidence stores each owned root only at `.scratch/work-items/<work-item-slug>/<terminal-run-id>/<entry-id>` and records it on that same completed `PASS` terminal ledger event through repeatable `--scratch-evidence-json`. Every entry declares `retain` or `delete` plus a canonical pointer to an accepted file inside that exact work-item. `retain` is metadata-only: it carries no proof and close checks only the root without following it, then leaves all contents untouched. `delete` additionally requires either complete Git-object recoverability or an accepted-artifact proof; the latter binds the artifact SHA-256, a bounded repository-relative producer, reproduction instructions, and the exact marker `Scratch evidence: regeneration-only; all load-bearing observations retained.` Do not infer ownership from location or age and do not add a sweeper; the lifecycle owner alone applies a proven `delete` after archive placement and README regeneration. A legacy event without `scratchEvidence` remains valid only while its canonical `.scratch/work-items/<work-item-slug>` namespace is absent; an existing undeclared namespace blocks close and is never mutated.

- This section applies only after the selected route enters recovery-tracked or multi-stage work.
- Keep each lead-routed non-trivial item in `work-items/active/<date>-<slug>/` unless an explicit repo-local policy disables task memory. Start human recovery at generated `work-items/README.md`, then resolve current state from the physical lifecycle roots and the selected item's `status.md`; `work-items/index.md` is a compatibility snapshot only.
- Before non-trivial work starts or resumes, ensure `roadmap.md`, `brief.md`, and `status.md` exist and are current. `roadmap.md` may link to an upstream roadmap artifact or record a direct human admission source when the user is the roadmap source.
- Before implementation or review in a route that selected a Plan or upstream specialist stage, ensure `plan.md` and the required upstream artifacts exist or are explicitly linked from the item folder.
- If the current stage needs an upstream artifact such as `research.md`, `design.md`, `constraints/*.md`, `plan.md`, or a required review report and that artifact is missing or stale, stop and restore it or route the item back to the correct upstream role.
- After every accepted artifact, interruption, or major routing change, update `status.md` so the next session can resume without relying on chat memory.
- Record the durable resume point in `status.md`: current stage, last accepted artifact, next concrete action, and any open obligations that still block closeout.
- On resume after interruption, refresh only lead-owned task-memory state from accepted persisted artifacts. Do not recreate missing specialist artifacts or infer missing facts from session memory; route to `$knowledge-archivist` or the proper factual role instead.
- If task memory is missing or stale, stop and restore it instead of improvising from session memory.
- `closure.md` is mandatory before moving an item to the configured archive location. It holds the final closeout record: outcome, residual risk, and archive location, and MUST carry a `Closed: <YYYY-MM-DD>` line. It MAY include a `## Retrospective` (`What went well` / `What didn't` / `Lessons` — each keep-worthy lesson filed in the lessons registry by id). Proportionality (anti-ceremony): the retrospective is EXPECTED for substantial or troubled items (multi-phase, a regression, a wrong-assumption rework) and OPTIONAL for trivial ones — the close step stays mandatory, the retro within it is proportionate. Residual (honest): governance-enforced only — no hook verifies a troubled close got a retrospective. On archive, invoke the lifecycle owner to move the item, reconcile physical locations, and regenerate `work-items/README.md`. Physical reconciliation and generated read-model verification are the `$knowledge-archivist` lane's mechanics contract, owed after every work-item state change; `work-items/index.md` is compatibility-only. Lead DECIDES the transition and owns `closure.md` content, applies the mechanics inline for a routine single-item close, and routes multi-item or drifted states to `$knowledge-archivist`.
- In `closure.md`, reconcile the delivered outcome against the roadmap decision package's target success signals; when no measurement is available, record `outcome-unmeasured: <reason>`.
- Before marking a batch closed, reconcile `brief.md`, `status.md`, the latest accepted artifact, required checks, canonical-source updates, and any open obligations. If admitted-scope work remains, keep the item active instead of closing it.

## Epics (grouping multiple work-items)

An **epic** groups multiple work-items under one goal or milestone. An active epic is a flat single file `work-items/epics/<date>-<slug>.md`; after closure it lives at `work-items/epics/archive/<YYYY-MM>/<date>-<slug>.md`, where the month comes from its `Closed:` date. It keeps `status: active | closed` frontmatter and `## Goal`, `## Children` (exact `- <child-slug> (active|closed)` lines), and `## Closure` (only when closed) sections. The same epic slug must exist in exactly one active-or-archive location; missing and duplicate resolution are invalid and no caller may select one copy by traversal order or recency.

- **Admission.** An epic is the admitted initiative/milestone — `$product-manager` admits it; the Coherence gate in the product-manager skill IS the epic admission test (an epic must name the shared goal, contract, or mechanism that makes its members one unit). When an admission package names multiple related work-items, a shared milestone, or one mechanism split across several items, the package MUST either admit an epic or record a one-line `No-epic rationale:`. Lead cannot self-author an epic; it traces to an approved `$product-manager` item or a direct human decision.
- **Linking.** Each child work-item declares its parent with a single bare `Epic: <epic-slug>` line in its `status.md` (single-valued — at most one parent epic). The epic file's `## Children` lists the child slugs.
- **Roll-up (derived, no stored cache).** Epic progress is derived live, never kept as a maintained count in the epic file. A child is **done** only when its slug uniquely resolves under `work-items/archive/`; active status and closure text record evidence but do not terminalize it. Resolve each child slug across BOTH `work-items/active/` AND `work-items/archive/`. Roll-up = all done -> `ready-to-close (n/n)`; some -> `in-progress (k/n)`; none -> `open`.
- **Close.** Set the active epic file `status: closed` and write its `## Closure` (outcome, residual risk, and a `Closed: <YYYY-MM-DD>` line) ONLY when ALL child work-items are closed AND the epic goal is met. Then `$knowledge-archivist` moves that same file to `work-items/epics/archive/<YYYY-MM>/<slug>.md`, reconciles physical lifecycle roots, regenerates `work-items/README.md`, and verifies unique resolution. A closed epic left in the active root is invalid transitional residue. The epic `## Closure` MAY carry the same `## Retrospective` (`What went well` / `What didn't` / `Lessons` filed in the lessons registry by id) under the same proportionality rule.
- **Edge cases.** A 0-child epic rolls up as `open/empty`, never `ready-to-close`. Work-items without an epic are valid — they simply omit the `Epic:` line. Reopening a child of a closed epic MUST move the epic back to `work-items/epics/<slug>.md` and set `status: active` in the same lifecycle operation. A missing or duplicate `Epic:` target is invalid and must be reported distinctly. A work-item belongs to at most one epic.
- **Vocabulary.** Express the epic and child closed-state with key `status` or `state` and a value drawn ONLY from `{closed, done, complete, completed, archived}` so the reused done-predicate matches; do NOT use the bug-registry `fixed`/`resolved` words for the done-line.
- **Derived views + ownership.** Derive epic roll-up from physical child locations and regenerate `work-items/README.md` through the lifecycle owner. `work-items/index.md` may retain an epic compatibility snapshot but has no ongoing sync requirement. Epic archive moves and physical reconciliation are the `$knowledge-archivist` hygiene lane; the epic lifecycle RULES are owned by `$product-manager` and `$lead`.
- **Lifecycle check.** No archival Stop hook is registered. Use the lifecycle owner and documented state check to reject duplicate locations, missing terminal evidence, and active/archive disagreement. Whether the epic `## Goal` is met remains an explicit lead decision.

## Dependencies (work-item -> work-item)

A work-item that needs another finished first declares `Depends-on: <slug>, <slug>` — a bare, comma-separated line of work-item slugs — in its `status.md`. This is a standing, planned inter-work-item dependency edge. It is RELATED TO but NOT identical to the runtime `BLOCKED:*` gate verdicts: `BLOCKED:prerequisite` is the in-flight discovery of unplanned adjacent work, which is filed in the bug registry, and `BLOCKED:dependency` is an external blocker — `Depends-on` is neither; it is a declared edge between two planned work-items.

- **Scope.** `Depends-on` targets are work-items ONLY, resolved by slug across THREE physical locations: `work-items/active/`, `work-items/archive/YYYY-MM/`, and admitted-not-yet-started `work-items/backlog/<slug>.md` files. `work-items/index.md` may summarize them but is compatibility-only. A backlog match is existence, not completion: an admitted item is never `done`, so a dependency on it stays open until the target item actually finishes. A slug matching a bug/epic/decision but no work-item, or resolving in none of the three locations, is a **dangling** target — and dangling is NOT evidence of readiness: it is folded into `blocked-by` alongside genuinely open targets, never treated as satisfied. Bugs are not dependency targets.
- **Derived (no stored cache).** `blocked-by(X)` = X's `Depends-on` targets that are not archived. The `ready-set` = active items whose every target uniquely resolves in `archive/` (or which have none). The lead derives both from the physical lifecycle resolver; status and closure text alone never satisfy a dependency.
- **Rule.** Record `Depends-on` when admitting or planning an item that needs prior work; do NOT start a blocked item's implementation while it has an open blocker. When a dependency closes, the dependent may become ready.
- **Integrity (authoring rule, not live detection).** Self-dependency is forbidden, and you must not author a dependency cycle (any `a -> ... -> a`); these are authoring-time obligations on `$lead`, not live detection. Flag a dangling `Depends-on`.
- **Residual (honest).** Dependency edges are governance-enforced only — no hook enforces them, so an item started while a dependency is still open is not structurally caught.

## Decisions (cross-cutting ADR registry)

Durable, cross-cutting architecture decisions live in a flat registry `work-items/decisions/<date>-<slug>.md` (the same flat list-item-frontmatter shape as `work-items/bugs/`), so a decision survives its originating work-item's archival instead of being buried in that item's `design.md`.

- **Shape.** Frontmatter uses the bug-registry list-item style (`- key:` bullets, no `---` fences): `- id:`, `- status: proposed | accepted | dropped | superseded | reverted`, `- date: <YYYY-MM-DD>`, `- decided-by: <role or human>`, `- context: <work-item slug | cross-cutting>`, `- supersedes: <decision id | none>`, `- superseded-by: <decision id | none>`. Body: `## Decision`, `## Rationale`, `## Consequences`, `## Alternatives rejected`. The decision `status` lifecycle is SELF-CONTAINED — independent of the work-item/epic done-predicate. The lifecycle owner structurally enforces those seven fields exactly once, non-empty, in the leading list block; `id` and `date` must match the filename. Optional list fields and indented continuations remain valid. Historical monthly archives retain legacy-read compatibility and immutable bytes.
- **Authoring + acceptance gate.** `$architect` authors a cross-cutting or long-lived decision in `status: proposed`; a work-item's `design.md` REFERENCES it by id rather than duplicating it. Promotion `proposed -> accepted` happens only after the corresponding `$architecture-reviewer` gate passes. `proposed -> dropped` (with a one-line reason) retires a declined proposal.
- **Citation contract (enforced both ways).** The registry id is a CONTRACT, not a courtesy: `$architect`'s gate requires every cross-cutting / long-lived decision in the claims section to carry a `work-items/decisions/` id, and `$architecture-reviewer` returns a blocking `REVISE` when such a decision is asserted in the design with no id. The trigger is NARROW — only decisions that outlive the work-item or constrain others; a local single-work-item decision stays inline in `design.md` so the registry does not flood.
- **Supersede (two-way edge).** When decision B supersedes A, set B's `- supersedes: A` AND A's `- status: superseded` + `- superseded-by: B` in one step — a stored bidirectional link (mirroring the epic child<->parent join). `reverted` keeps a one-line reason.
- **Ownership.** Lifecycle TRANSITIONS are a SEMANTIC act owned by `$architect`/`$lead`; `$knowledge-archivist` does ONLY the non-semantic bookkeeping (writing the stored back-link field, reconciling physical locations, and verifying the generated read-model).
- **Stale-proposed accountability.** The lead is accountable for resolving a `proposed` decision that the decision scan keeps surfacing — drive it to `accepted` (after the `$architecture-reviewer` gate) or `dropped` (with a one-line reason). Do not let a proposal idle indefinitely; surfacing it is visibility, not closure.
- **Stale-proposed turn-end self-check (decidable, text-enforced).** At turn-end, if a current decision's lifecycle-validated leading block has both `- status: proposed` and `- date: <YYYY-MM-DD>` strictly before today, name it and either route it to `$architecture-reviewer`, drop it with a reason, or state why it remains pending. A body quotation never counts. The first calendar day is the legitimate review window. SCOPE: decisions only; lessons use a different lifecycle.
- **Residual (honest).** Current-record shape is structurally enforced by `scripts/mutate-work-item.py audit`; semantic staleness and supersession-link consistency are not. No hook decides when a proposal should advance or validates the two-way relation graph. A blocking stale-proposal Stop hook remains deferred pending evidence; do not add a parallel schema validator.

## Lessons (delivery lessons-learned registry)

Lessons learned during delivery (a recurring miss, a wrong assumption, a process gap) live in a flat registry `work-items/lessons/<date>-<slug>.md` (the same flat list-item-frontmatter shape as `work-items/bugs/`), so a lesson survives its originating work-item's archival instead of vanishing when that item closes. This is in-repo project task memory (gitignored data), NOT the operator's personal global memory; a lesson that generalizes beyond this project MAY ALSO be promoted to the spine or personal memory, but that is an additive, one-directional, separate manual act — the project-local entry stays the canonical project record.

- **Shape.** Frontmatter uses the bug-registry list-item style (`- key:` bullets, no `---` fences): `- id:`, `- status: open | applied | dropped | archived`, `- source: <work-item | bug | review | incident>`, `- category: process | technical | governance | tooling`. Body: `## Lesson` (one line), `## Context` (what happened), `## How to apply` (the concrete next action that would prevent a recurrence). The lesson `status` lifecycle is SELF-CONTAINED — independent of the work-item/epic done-predicate.
- **Lifecycle.** `open` (captured, not yet acted on) -> `applied` (a named change shipped) -> `archived` (no longer relevant); plus `open` -> `dropped` (considered, not worth acting on — keep a one-line reason). A lesson stays in the registry as history, never deleted.
- **Capture.** A lesson is captured by the closing role that ran the retrospective — the main conversation (as Lead) — or by `$qa-engineer`/a reviewer when they spot a recurring miss. The retrospective in `closure.md` is the natural capture point; each keep-worthy retro lesson becomes a registry entry, back-linked by id.
- **Ownership.** Lifecycle TRANSITIONS (open | applied | dropped | archived) are a SEMANTIC act owned by the CLOSING role that captured the lesson (the main conversation as Lead), escalating to `$product-manager` when applying a lesson admits follow-up work; `$knowledge-archivist` does ONLY the non-semantic bookkeeping (physical/read-model reconciliation and the back-reference id). The archivist does NOT decide a lesson status transition.
- **Stale-open accountability.** The main conversation (as Lead) is accountable for resolving an `open` lesson that keeps getting surfaced — drive it to `applied` or `dropped` (one-line reason). Listing it is visibility, not closure.
- **Surfacing.** The lead derives the open-lessons count live by scanning `work-items/lessons/` for `status: open` (count + id + `## Lesson` first line). `$product-manager` consults open lessons when admitting similar work so the same mistake is not repeated.
- **Residual (honest).** Registry hygiene is governance-enforced only — no hook scans `work-items/lessons/`, so an `open` lesson nobody applies is not structurally caught.

## Backlog (physical-root spec)

`work-items/backlog/` is the physical root for items admitted by `$product-manager` but not yet started: a holding area between roadmap admission and active delivery, distinct from Active (in-flight) and Archived (done). The main conversation (as Lead) moves an item from the physical backlog root to Active when work starts. The lifecycle owner regenerates `work-items/README.md` from that root; `work-items/index.md`, when retained, is an optional compatibility snapshot and is never required for backlog resolution.

## Status board (work-items/README.md)

`work-items/README.md` is the generated project **status board** and human recovery start — a short, structured "where does everything stand" read-model for the whole repository. It is DERIVED from the physical lifecycle roots and their owning status/closure artifacts; it summarizes them and points in, and MUST NOT copy per-item detail that can drift. `work-items/index.md` is an optional compatibility snapshot, never a state owner.

- **Required shape** (adapt the names to the project, keep the shape): a **header** (what this is + snapshot date + current HEAD short SHA + who maintains + refresh cadence + the grounding rule: every status grounded in a cited commit/work-item, not memory); the operator-set **roadmap priority** ordering; **work areas** (the top-level project domains, 1-2 lines each); a main-thrust **milestone/phase table** (milestone | scope | status, with an explicit status marker per row drawn from FIVE STATES that are the actual contract — delivered/closed, in-progress, not-started, parked/operator-gated, blocker; the default RENDERING of those states is the glyph vocabulary ✅ 🔄 ⬜ ⏸ ⚠, and a plain-ASCII equivalent, e.g. `[done]`/`[wip]`/`[todo]`/`[parked]`/`[blocked]`, is permitted wherever glyph rendering is unavailable); **active sub-threads** (1 line each, with the gate or blocker named); **parallel arcs** (epics + other active items as an item | what | state table); the **immediate critical chain** (the next concrete dependency chain X -> Y -> Z); an **honest-scale** note (the largest remaining bodies of work, no over-claim); a REQUIRED one-line **`How to read`** legend naming whichever rendering (glyph or ASCII) is in use on this board; and a **Terms** section expanding every domain abbreviation used.
- **Maintenance.** `$lead` owns the board's editorial framing (roadmap priority, milestone intent); the lifecycle owner regenerates it after lifecycle mutations, and `$knowledge-archivist` verifies the read-model in its post-wave Board-refresh control. The board is date + HEAD anchored; a snapshot that is stale between delivery waves is acceptable only because the header date makes the staleness visible. Ongoing `index.md` synchronization is not required.
- **Registry reconciliation intake.** After task-memory governance changes, at milestone-wide cleanup, or when the operator asks to make all registries current, invoke `$knowledge-archivist` in `Registry Governance Reconciliation` mode. Consume the complete matrix: route every non-consistent semantic row to its documented owner, keep ambiguous ownership `BLOCKED`, and do not claim the registries current or close the parent item until the archivist's post-change structural AND semantic gates both return `PASS`.
- **Discipline (rules, not suggestions).** Grounded, not remembered: every `delivered`/`done` claim cites a commit or work-item, verified against git and the tree. Honest scale: name the biggest remaining bodies plainly; forbid "almost done" while large milestones are un-started. No drift-prone duplication: summarize and point into physical roots and owning `status.md`/`closure.md` artifacts, do not copy per-item detail that will rot. Evidence-citation clean: where the project ships the evidence-honesty scanner, the board must pass it — a commit SHA written as commit `<sha>`, a digest as SHA-256 `<token>`, each with its owning artifact named on the same line (bare SHAs fail).
- **Relationship.** Read the board first for the big picture, resolve an item in the physical lifecycle roots, and read its owning `status.md` or `closure.md` for detail. The board complements `work-items/epics/` grouping; `index.md`, when retained, is only a compatibility snapshot. `work-items/` is gitignored local task memory, so neither generated view is a committed change.

## Operating pipeline

The numbered stages below are a menu selected by the active template, not a mandatory sequence. Each route enters only at its selected stages.

0. `Roadmap / Intake`
   - Roles: `$product-manager`, `$product-analyst` as needed
   - Output: one roadmap decision package and, when needed, one factual product brief.
1. `Research`
   - Roles: `$analyst`, `$product-analyst` as needed
   - Operating-model alias: `researcher`
   - Output: one factual research artifact per role.
2. `Design`
   - Roles: `$architect`, `$ux-designer`, `$algorithm-scientist`, `$computational-scientist`, `$security-engineer`, `$performance-engineer`, `$reliability-engineer` as needed
   - Output: one design or specialist-constraint package per role.
   - Panel-eligible design (high-surface sweep / open architecture choice): convene the design-panel per `skills/design-panel/` (`$design-panel`) — N>=2 independently-framed lanes to `design-<lane>.md`, mandatory synthesis to `design.md`; lane outputs are never shippable alone.
3. `Plan`
   - Role: `$planner`
   - Output: one gated phase plan.
4. `Implement`
   - Roles: `$backend-engineer`, `$frontend-engineer` for web/React UI, `$graphics-engineer`, `$visualization-engineer`, `$geometry-engineer`, `$qt-ui-engineer` for Qt desktop UI, `$model-view-engineer`, `$data-engineer`, `$toolchain-engineer`, `$platform-engineer`, `$external-worker`, or another explicitly approved implementation specialist
   - Output: one implementation package for one approved phase.
   - Cross-cutting hygiene (invoke explicitly, outside the feature phase): `$knowledge-archivist`
   - If an archivist patch changes repository-wide control-plane semantics, route it through `$architecture-reviewer` before lead acceptance.
   - If the approved work spans multiple implementation phases or specialists, assign one explicit integration owner before QA. That owner assembles one coherent integrated artifact and checks cross-phase compatibility before verification begins.
5. `QA`
   - Roles: `$qa-engineer`, `$ui-test-engineer`, `$external-reviewer` as needed
   - Output: one verification package per verification role, including basic performance acceptance when relevant.
6. `Independent review`
   - Roles: `$architecture-reviewer`, `$performance-reviewer`, `$security-reviewer`, `$ux-reviewer`, `$accessibility-reviewer`, `$external-reviewer` as needed
   - Output: one review package per independent reviewer.
   - For each reviewer, choose the review strategy before delegating (see Review strategy rule below).
7. Human or CI gate
   - Output: explicit human approval, CI status, or documented external blocker.
   - For publication, `$lead` runs the publication-safety scan and `$knowledge-archivist` is the default publication-gate approver; the approver must be a different role than the role that accepted the artifact into the pipeline.
8. Optional batch-close consultant sweep
   - Role: `$consultant`
   - Output: one non-binding advisory memo that performs a final missed-change and residual-risk sweep, then ends with an explicit reusable second prompt for continuing the work.
   - Run this stage only when the lead explicitly wants consultant input or a repo-local lane policy explicitly requests it and `consultantMode` is not `disabled`.

Roadmap ownership stays upstream of the lead lane. The lead consumes approved roadmap or intake output; it does not own global prioritization or portfolio sequencing by default.

`Quick-fix` admission is owned by shared governance. When selected, create its minimal pre-mutation recovery status and route `lead -> implementation -> qa -> lead`; if its predicate fails, re-classify by enriching the same work-item before continuing. After delivery, close and archive it immediately under the normal rule.

## Delegation contract

Every delegated task must specify:

- `Role`
- `Goal`
- `Approved inputs`
- `Allowed tools`
- `Scope`
- `Out of scope`
- `Allowed change surface`
- `Must-not-break surfaces`
- `Constraints`
- `Expected artifact`
- `Acceptance criteria`
- `Gate to next stage`

If any field is missing, tighten the task before delegating it.

Use the templates in [subagent-contracts.md](subagent-contracts.md) for concrete handoffs and response format.

- **Evidence discipline required**: the handoff must include the template's `Evidence discipline` field with the four accepted evidence categories, `ASSUMPTION (UNVERIFIED)` fallback, and banned correctness-drivers; a handoff without it is incomplete.
- **Tool selection recorded**: immediately before each native spawn, discover the current tool surface and fill `Allowed tools` exactly as required by the installed `AGENTS.md`; inherited availability does not widen that recorded selection.

## Delegation-first rule

- If a task requires substantive research, design, planning, implementation, or review work and there is a matching specialist role, delegate it.
- If evidence is weak or missing, route to a factual role before asking for broader judgment or tradeoff advice.
- Use delegation itself as a noise filter: pass accepted artifacts instead of raw transcripts, keep interpretive roles downstream of evidence, and keep bounded corrections local to the current role.
- Keep lead work limited to canonical brief maintenance, role selection, sequencing, gate decisions, and status synthesis.
- Only do role-work directly when the task is trivial, purely coordinative, or there is no suitable specialist role.
- If a worker handoff was interrupted and no artifact was produced, do not compensate by gathering code facts or drafting the missing artifact inline. Re-dispatch the same role with a narrower slice or route to `$analyst` / the appropriate factual role.
- Maintain exactly one primary in-progress task. Side clarifications may refine it or temporarily interrupt it, but do not replace it unless the user explicitly reprioritizes.
- If the primary task is a full-impact review or verification pass, keep that task open until a review artifact is produced; do not treat side clarification as completion or replacement of the review.
- If the lead performs role-work by default, it has stopped acting as a lead and has become a generalist agent.

## Fact-first rule

- Prefer factual artifacts before interpretive artifacts whenever the next decision depends on unknowns.
- Use `$analyst` for code and system facts, `$product-analyst` for user or product facts, and accepted metrics or constraints as the basis for roadmap or design decisions.
- Require decision-making roles such as `$product-manager`, `$architect`, and specialist constraint roles to separate evidence, judgment, assumptions, and open questions explicitly.
- Treat `$consultant` as optional independent judgment only after the strongest relevant factual slice is already available.
- When the next decision requires facts from multiple independent domains, independent factual roles (analyst, product-analyst) may be launched in parallel provided their investigation scopes do not overlap.

## Review strategy rule

Before delegating to any independent reviewer, choose one of two strategies and state it explicitly in the task.

**Claim-Verify** — use when the risk surface is known and bounded.
- Require the upstream specia

…(truncated)