🤖 Apply lean Athanor review fixes

Adept dispatches no longer pass a model alias over the pin. Igor checks
the stamped model id of plan, attack and phase-review outputs before
acting on them. Implementation work no longer goes to the Athanor as an
unplanned brief. The spawning reference says plainly that "verified"
means read from the schema, marks fork availability unverified, and
cites the 184/184 evidence for alias-over-pin. Minor consistency fixes:
trunk notes, re-check failure path, staging, fallout diffs, run-log
timing.

plugins/spire/agents/athanor.md

@@ -29,9 +29,9 @@ The `spire:implementation` skill is how you work. Its references hold the run-lo
 The plan you receive has already been attacked and reshaped into phases and blocks. Each turn you build one phase and hand back.
 
 1. **Intake.** Read the build plan, the run log so far, and the code the phase touches. That reading is your trunk. Check you are on the branch the brief names; stop if not. Write short trunk notes next to the run log so fresh agents, and a successor Athanor, can start from them.
-2. **Build the blocks** in the plan's order, in the foreground. Each block goes to its owner. A complex block in the area you just read can go to a fork of yourself (it inherits your context and model). A mechanical or distant block goes to a fresh agent that reads the trunk notes. Fork behaviour is partly unverified; see the spawning reference.
+2. **Build the blocks** in the plan's order, in the foreground. Each block goes to its owner. A complex block in the area you just read can go to a fork of yourself (it inherits your model and, assumed, your context). A mechanical or distant block goes to a fresh agent that reads the trunk notes. Fork behaviour is partly unverified; see the spawning reference.
 3. **Gate between blocks.** The cheap check the plan or project config names (compile, typecheck). Not a review.
-4. **Tests once**, at phase end. Fix the fallout in that last block.
+4. **Tests once**, at phase end. Fix the fallout in that last block. A child's "tests pass" is a claim: read the fix's diff for loosened assertions or deleted checks before you report green.
 5. **Run log.** One handoff note per block, then the phase close with every deviation and flag listed for the reviewer.
 6. **Hand back.** Igor dispatches the phase review.
 
@@ -52,7 +52,7 @@ When Igor resumes you with review findings: one fix pass over all of them, commi
 - **Closed door.** Undecided points get the conservative default, flagged in the handoff note. Never block on the user.
 - **Goals are read-only.** Never write, modify, or delete anything in the workpad `goals/` folder — only the user and Igor author goals. Your outputs go to `reports/`, `research/`, `plans/`.
 - **Agents write their own reports.** Every subagent gets an explicit output file path in the workpad. You read the finished files; you are not a copy-paste bottleneck.
-- **Stay in your lane.** Work only within the brief's scope and the branch or worktree the brief and project config name. Stage explicit paths. Never open pull requests; push if instructed, never force-push.
+- **Stay in your lane.** Work only within the brief's scope and the branch or worktree the brief and project config name. Stage per project config (default: explicit paths). Never open pull requests; push if instructed, never force-push.
 - **Igor holds the queue.** One plan at a time. If another plan is waiting, Igor dispatches it after you hand back.
 
 ## Tools, not the loop

plugins/spire/skills/igor/SKILL.md

@@ -81,16 +81,16 @@ Pick the tier by task type (details in `references/model-tiers.md`). Prefer proj
 | Planned implementation | implementer agent | project-pinned or `model: "opus"` (needs write access) |
 | Complex summaries, git fixes, small code changes | Sonnet subagent | `model: "sonnet"` (needs write access) |
 | Test runs, compiles, commits, linear-data summaries | Haiku subagent | `model: "haiku"` (needs Bash access) |
-| Domain knowledge, repeated consultation on a subsystem | `adept` agent (long-lived, domain-scoped) | `subagent_type: "adept"`, `model: "opus"` |
+| Domain knowledge, repeated consultation on a subsystem | `adept` agent (long-lived, domain-scoped) | `subagent_type: "adept"` (`model` omitted; pinned) |
 | Building a reshaped plan; large multi-part jobs needing their own subagent fan-out | `athanor` | `subagent_type: "athanor"`, `model` omitted (pinned to Opus 5.5) |
 
 The `athanor` is the forge — your heavy lifter. A build furnace pinned to Opus 5.5 that may use the Agent (Task) tool itself and runs its own subagents. Load it with the reshaped build plan (for non-build jobs: a brief with scope, output paths, completion criteria), close the door, and let it cook. It builds one phase per turn and hands back.
 
-**Model must be explicit — and deliberate.** The per-call `model` is an alias and it overrides an agent's pinned model: `model: "opus"` gives the agent the Opus that alias resolves to, not its pin (a 4.6 Igor passing `opus` got a 4.6 Athanor). So: for agents pinned in their frontmatter (e.g. athanor) omit `model` unless you deliberately override the pin; for unpinned agents (general-purpose) always pass `model` (`"opus"`, `"sonnet"`, `"haiku"`), since omitting it inherits your model, which may be Fable. Note the choice in the journal, and have the agent stamp the model id it ran on. Subagents are Opus or lower; never dispatch a Fable-tier subagent unless the user explicitly asks. Model traits: the implementation skill's `references/models.md`.
+**Model must be explicit — and deliberate.** The per-call `model` is an alias and it overrides an agent's pinned model: `model: "opus"` gives the agent the Opus that alias resolves to, not its pin (in spacecraft it overrode 4.6 pins in 184 of 184 spawns). So: for agents pinned in their frontmatter (e.g. athanor) omit `model` unless you deliberately override the pin; for unpinned agents (general-purpose) always pass `model` (`"opus"`, `"sonnet"`, `"haiku"`), since omitting it inherits your model, which may be Fable. Note the choice in the journal, and have the agent stamp the model id it ran on. For the plan, the attack and the phase review, check the stamped id before acting on the result; if it is not the intended model (Opus 5.5 by default), re-dispatch or tell the user. Subagents are Opus or lower; never dispatch a Fable-tier subagent unless the user explicitly asks. Model traits: the implementation skill's `references/models.md`.
 
 ## Development Cycle
 
-Igor routes work through six stages. Not every task enters the cycle — one-off fixes, ad-hoc questions, and maintenance stay outside it. The line: if writing the plan would take longer than doing the work, it is not in the cycle.
+Igor routes work through the stages below. Not every task enters the cycle — one-off fixes, ad-hoc questions, and maintenance stay outside it. The line: if writing the plan would take longer than doing the work, it is not in the cycle.
 
 **Stages:** (1) Brainstorm — Igor with user or Pinky; skip when direction is clear. (2) Research — researcher/adept answers open questions. (3) Design — independent Opus agent produces one buildable approach. (4) Plan — independent Opus 5.5 agent (never the designer) produces steps with completion criteria. (4b) Attack the plan — Igor dispatches a fresh Opus 5.5 agent (never the planner) that tests the plan adversarially against the code (blockers, design errors, missed consumers of changed semantics), then reshapes it into a build plan: phases that end testable, blocks one owner can finish. One step. It is what pays for dropping per-task review. Show the user the build plan and its open decisions before the door closes. (5) Build — the Athanor builds one phase per turn: blocks, a cheap gate between them, tests once, a run log. (6) Phase review — Igor dispatches a fresh Opus 5.5 reviewer per phase, without the attack's risk list as its scope; it answers every handoff flag, hunts weakened checks and tests that cannot fail, and stamps its model id. Details in `spire:implementation`.
 
@@ -98,7 +98,7 @@ Igor routes work through six stages. Not every task enters the cycle — one-off
 
 **Review decision tree:** Igor routes the outcome:
 1. No Critical or Important findings — the phase is done. Minors are fixed in a fix pass if one runs, otherwise logged; never loop for minors.
-2. Critical or Important — one fix pass (resume the Athanor), then a fresh reviewer re-checks only those findings. Then stop and go to the next phase. Findings too large for a fix pass go into a new plan (stage 4).
+2. Critical or Important — one fix pass (resume the Athanor), then a fresh reviewer re-checks only those findings. Then stop and go to the next phase; a Critical or Important that survives the re-check goes to the user or into a new plan, not into the next phase. Findings too large for a fix pass go into a new plan (stage 4).
 3. Approach is wrong, not the code — back to design (stage 3). Append a dated amendment.
 4. Unresearched unknown surfaced — back to research (stage 2). Only for a genuinely new problem space.
 5. Goal is wrong — stop. User's call.
@@ -130,7 +130,7 @@ Adepts are domain-scoped knowledge agents that persist within a session. They ac
 
 When the roster shows the domain slug (successor):
 ```
-Agent(subagent_type: "adept", name: "<slug>-adept", model: "opus",
+Agent(subagent_type: "adept", name: "<slug>-adept",
       prompt: "Your domain is <Name>. Your folder is <workpad>/adepts/<slug>/ — you are a
                successor; it has a handoff.md. We are on branch <branch>. Session journal:
                <journal-path>.
@@ -139,7 +139,7 @@ Agent(subagent_type: "adept", name: "<slug>-adept", model: "opus",
 
 When the domain is new (slug not in roster — founding):
 ```
-Agent(subagent_type: "adept", name: "<slug>-adept", model: "opus",
+Agent(subagent_type: "adept", name: "<slug>-adept",
       prompt: "Your domain is <Name> (<brief scope description>). Your folder is
                <workpad>/adepts/<slug>/ — it does not exist; you are the founding adept.
                We are on branch <branch>. Session journal: <journal-path>.
@@ -148,7 +148,7 @@ Agent(subagent_type: "adept", name: "<slug>-adept", model: "opus",
 
 When the roster shows "(unmigrated: no frontmatter)":
 ```
-Agent(subagent_type: "adept", name: "<slug>-adept", model: "opus",
+Agent(subagent_type: "adept", name: "<slug>-adept",
       prompt: "Your domain is <Name>. Your folder is <workpad>/adepts/<slug>/ — it predates the
                tiered layout (no frontmatter, journals at the root). Migrate it during genesis
                per adepts/CLAUDE.md, then orient. We are on branch <branch>. Session journal:

plugins/spire/skills/igor/references/model-tiers.md

@@ -16,7 +16,7 @@ Prefer a project-pinned agent from `.claude/agents/` when one matches the task;
 Rules of thumb:
 
 - One task -> one subagent with an explicit output file path in the workpad.
-- A job with 3+ independent subtasks, or research + implementation combined, goes to `athanor` as a single brief (scope, output paths, completion criteria).
+- Implementation goes through the cycle (plan → attack the plan → build): the `athanor` gets a reshaped build plan, never an unplanned build brief. A non-build job with 3+ independent subtasks (research cascade, audit) may go to `athanor` as a single brief (scope, output paths, completion criteria).
 - When unsure between tiers, prefer the cheaper tier and escalate on failure.
 
 Write-capability guard:

plugins/spire/skills/implementation/SKILL.md

@@ -44,14 +44,14 @@ Plan-writing tools are swappable (superpowers `writing-plans` today; others late
 
 Both extremes have failed. Many tiny fresh implementers relearn the code each time and fragment the plan. One implementer kept across many tasks bloats and drifts. Choose per block: how much shared understanding does it need, and how much room is left? Context figures in `references/models.md` are guesstimates, not limits.
 
-One option is **trunk and forks**. At intake the builder reads the build plan and the code it touches (the trunk) and writes short trunk notes. Complex blocks in the trunk's area go to a fork of the builder, which inherits its context and model. Mechanical or distant blocks go to a fresh agent that reads the trunk notes. Which harness behaviour is verified and which is assumed: `references/spawning-claude-code.md`.
+One option is **trunk and forks**. At intake the builder reads the build plan and the code it touches (the trunk) and writes short trunk notes. Complex blocks in the trunk's area go to a fork of the builder, which inherits its model and (assumed) its context. Mechanical or distant blocks go to a fresh agent that reads the trunk notes. Which harness behaviour is verified and which is assumed: `references/spawning-claude-code.md`.
 
 ## Phase review, fix, stop
 
 - A **fresh** reviewer that did not build the phase, dispatched outside the build, stamps its model id in its report header. A review without a stamped id does not count.
 - It is adversarial: it runs the gates, traces concrete scenarios, and **answers every deviation and flag in the handoff notes**, one by one. It looks specifically for **weakened checks** (loosened assertions, downgraded errors) and **tests that cannot fail**.
 - **One fix pass** over all findings. Minors are fixed in that pass or logged as follow-ups.
-- **Re-check only Critical and Important**, by a fresh reviewer scoped to those findings. Then stop.
+- **Re-check only Critical and Important**, by a fresh reviewer scoped to those findings. Then stop. A Critical or Important that survives the re-check goes to the user or into a new plan, not into the next phase.
 - Extra reviews (for example a mid-phase review of a hotspot block whose note flags a deviation) are a choice with a stated reason, not a default.
 
 ## Bugs

plugins/spire/skills/implementation/references/models.md

@@ -40,7 +40,7 @@ Full id not recorded here; spacecraft notes mention "Sonnet 5".
 
 ## Haiku
 
-- Fine for runs, compiles, commits and mechanical appliers. Treat its self-reports as claims to check: it once reported "no deviations" alongside misplaced edits (spacecraft, 2026-09-29).
+- Used for runs, compiles, commits and mechanical appliers. In one spacecraft run it reported "no deviations" while edits had landed in the wrong place (spacecraft, 2026-09-29).
 
 ## Context and block size
 

plugins/spire/skills/implementation/references/run-log.md

@@ -16,7 +16,7 @@ Rules:
 
 - Plan: <path>  ·  Build plan: <path>
 - Branch: <branch>  ·  Start commit: <hash>
-- Trunk notes: <path or "none">
+- Trunk notes: <path>
 - Athanor: <model id>  ·  Session journal: <path>
 ```
 
@@ -25,8 +25,8 @@ Rules:
 ```markdown
 ## Phase <N> — <title>
 
-| Block | Owner (model id) | Start | End | Commit | Tokens (if known) |
+| Block | Owner (model id) | Commit | Tokens (if known) |
-|---|---|---|---|---|---|
+|---|---|---|---|
 ```
 
 ## Handoff note (one per block, written by the block's owner)
@@ -58,6 +58,6 @@ Rules:
 
 After the review, Igor (or the fixer) appends the review report path, the fix-pass commits, the re-check result, and the minors logged as follow-ups.
 
-## Trunk notes (optional, written at intake)
+## Trunk notes (written by the Athanor at intake)
 
 Short, for the next agent that has not read the code: key files and seams, invariants the phase touches, every consumer of a changed semantic, the gate command, known traps. A page, not a design document.

plugins/spire/skills/implementation/references/spawning-claude-code.md

@@ -4,7 +4,7 @@ Harness mechanics for dispatching, resuming and forking agents in Claude Code. O
 
 Each claim carries a status and a date:
 
-- **verified**: read from the tool schema or checked directly, on that date.
+- **verified**: read from the tool schema text on that date. Not tested at runtime unless the row says so.
 - **observed**: seen in real runs; the mechanism may be assumed. Source given.
 - **assumed**: inferred, not checked. Treat as a hypothesis.
 - **unknown**: open; check before relying on it.
@@ -48,14 +48,17 @@ The harness changes. When a claim fails, fix it here with a new date.
 | With `model` omitted, a pinned agent runs on its pin; an unpinned agent inherits the caller's model unless a default subagent model is configured. | verified 2026-10-05 (Agent tool schema) |
 | A full model id (e.g. `claude-opus-5-5`) can only be set in the agent definition's frontmatter, so pinning by full id means a pinned agent dispatched without `model`. | verified 2026-10-05 (follows from the alias-only parameter) |
 | The `opus` alias overrode 4.6 pins in 184 of 184 spawns (they ran on 5.5). | observed 2026-09-27 (spacecraft MVP retrospective) |
-| Passing `model: "opus"` gave the Athanor the model Igor was running on: a 4.6 Igor produced a 4.6 Athanor (the dirigent end review that passed with zero findings). | observed 2026-10-05 (user's attribution; the dirigent report recorded the model as unknown). How the alias resolves is assumed, not checked: it may follow the caller's model or a session default. Either way the alias, not the pin, decided. |
+| A 4.6 Igor passing `model: "opus"` to the then 4.6-pinned Athanor got a 4.6 run (the dirigent end review that passed with zero findings). | observed 2026-10-05 (user's attribution; the dirigent report recorded the model as unknown). Consistent with both the alias following the caller and the pin holding, so it is not evidence for alias-over-pin. The 184/184 row and the schema are. |
-| Every agent sees its exact model id in its system prompt. | verified 2026-10-05 (this agent's prompt shows `claude-opus-5-5`) |
+| What the `opus` alias resolves to (the caller's model, a session default, or the newest Opus). | unknown. Check the stamped id of every plan, attack and review instead of relying on it. |
+| Every agent sees its exact model id in its system prompt. | observed 2026-10-05 for general-purpose agents (prompt shows `claude-opus-5-5`); not checked for plugin agents with their own bodies |
+| Context window of the bare `claude-opus-5-5` pin versus a `[1m]` suffix (other Spire pins carry `[1m]`). | unknown; the ~600k guesstimate in `models.md` assumes the larger window |
 
 ## Fork
 
 | Claim | Status |
 |---|---|
-| `subagent_type: "fork"` exists. A fork always inherits the caller's model; the `model` parameter is ignored. | verified 2026-10-05 (Agent tool schema) |
+| The Agent tool schema documents `subagent_type: "fork"`: a fork always inherits the caller's model; the `model` parameter is ignored. | verified 2026-10-05 (schema text) |
+| `fork` is actually offered as an agent type in a given session. | unverified: the schema mentions it, but on 2026-10-05 it was not in the list of agent types offered to the reviewer |
 | A fork copies the **caller**, not an arbitrary agent. Only the agent holding a context (e.g. the Athanor as trunk) can fork it. | assumed (no parameter names a fork source; Igor's skill calls it "forking yourself") |
 | A fork starts with the caller's full transcript, so it starts at the caller's token count. | assumed, not measured |
 | Can a fork fork again? Does a foreground fork return its result to the caller? Does it see the caller's preloaded skills? | unknown; check in a throwaway preflight before relying on trunk and forks |