📝 Add lean Athanor workpad (goal, journal, research, reports)

Captures the lean-build redesign work: goal, session journal, Athanor usage research from dirigent and spacecraft, and the implementation and review reports.
2026-10-05 22:21:55 +02:00
parent f40cbf5a2a
commit b0b315136e
7 changed files with 794 additions and 0 deletions
@@ -0,0 +1,57 @@
 # Goal: Lean implementation — `implementation` skill and Athanor for Opus 5.5
 **Set**: 2026-10-05, Igor session [2026-10-05-21-athanor](../journals/2026-10-05-21-athanor.md)
 **Evidence**: [dirigent survey](../research/2026-10-05-21-athanor-usage-dirigent.md), [spacecraft survey](../research/2026-10-05-21-athanor-usage-spacecraft.md), [redesign report](../reports/2026-10-05-21-implementation-skill-redesign.md) (input, not law — corrected by this goal where they differ). Primary source: dirigent `docs/workpad/reports/2026-10-01-lean-process-report.md` + 2026-10-05 addendum.
 ## Why
 With Opus 5.5, the per-task ceremony we inherited (many pitstops, review after every task, tests between every agent) costs more than it catches and produces too much output. 5.5 plans are excellent but long; most defects trace back to the plan, not to the drafting model. What worked in dirigent and spacecraft: test the plan against the code before building, build in large chunks, review once per phase.
 ## Success criteria
 ### The skill is lean
 - [ ] `implementation/SKILL.md` states intent and defaults with their reasons, and leaves decision room for the problem at hand. It does not encode single incidents as rules.
 - [ ] It stays short: no longer than today's skill by more than a modest margin; detail lives in references.
 - [ ] Mechanics of the harness (Claude Code) and traits of models live in reference files, not in the skill body. Project-specific choices (worktrees, staging explicit paths, gate/test commands, owner-model defaults) are read from `spire:project`, not fixed in the skill.
 ### Attacking the plan is the quality gate before the build
 - [ ] The cycle has an explicit step after planning: a fresh agent (not the planner) **tests the plan adversarially against the code** (blockers, design errors, missed consumers of changed semantics) and **then reshapes it** into phases that end testable and blocks one owner can finish. One step, not two.
 - [ ] The skill makes clear that this step is what pays for dropping per-task review — it moves quality control upstream.
 - [ ] It is described by intent, not as a checklist of required output fields.
 - [ ] The attack's risk list is not handed to the phase reviewer as its scope.
 - [ ] The step happens outside the Athanor (Igor dispatches it), so the user sees the reshaped plan and pending decisions before the door closes.
 ### Lean build loop
 - [ ] Between blocks: a cheap gate (compile/typecheck), not a review. At phase end: tests once, one adversarial phase review, one fix pass, re-check only for Critical/Important, then stop. Minors are fixed in the pass or logged.
 - [ ] Phase review is dispatched by Igor, by a fresh reviewer, with its model id stamped. It answers every handoff flag and looks specifically for weakened checks and tests that cannot fail.
 - [ ] Extra reviews (e.g. a mid-phase hotspot review) remain possible as a reasoned choice, not a default.
 ### Athanor is a build furnace
 - [ ] One phase per Athanor turn: intake (read build plan + touched code = the trunk; write short trunk notes) → build blocks in the foreground → gate between blocks → tests once → run log with per-block handoff notes → hand back.
 - [ ] Igor resumes the Athanor (safe from the root) for the fix pass and the next phase, or starts a fresh one from run log + trunk notes when its context looks spent.
 - [ ] The plan sets defaults for block size and owner model; the Athanor may deviate with a logged reason.
 - [ ] The Athanor does not plan, attack plans, or review its own output.
 - [ ] Trunk and forks is described as an option, with verified vs. assumed harness behaviour marked: complex blocks in the trunk's area → fork of the Athanor; mechanical or distant blocks → fresh agent with trunk notes. Forks inherit the Athanor's model.
 ### Models
 - [ ] Opus 5.5 (`claude-opus-5-5`) is the default for the Athanor, planning, attack, and review. The Athanor's frontmatter pins it.
 - [ ] Igor's model rule accounts for alias-over-pin: passing `model: "opus"` gives the Athanor whatever Igor runs on (a 4.6 Igor → 4.6 Athanor; the dirigent "Pass" review was such a case). Igor omits `model` for pinned agents unless it deliberately overrides, and stamps the choice.
 - [ ] Model notes are observations with date and source, not law: 5.5 catches more, decides boldly, can replace frequent small reviews (esp. Rust), but can take the user's word as holy or reverse 100%; 4.6 is fast, capable, sometimes better at interpreting intent (useful as a "understanding the human" interpreter; Fable is better still); Sonnet and Haiku observations kept neutral — the Sonnet experiment's defects were largely plan issues.
 - [ ] Stale guidance removed: "prefer Opus 4.6 for implementation", "Opus 5 tends to hallucinate", "review between tasks".
 ### Context sizes are guesstimates
 - [ ] Any context figures (e.g. 5.5 comfortable to ~600k) are labelled as guesstimates from Claude Code experience. The skill gives judgment guidance between the two failed extremes (many tiny fresh implementers; one implementer kept too long), not a rule for either.
 - [ ] Noted as future work: orchestrator introspection of subagent token use / signals into running work (dirigent is working on this).
 ### Superpowers is a toolbox, not the default loop
 - [ ] The Athanor no longer preloads `superpowers:subagent-driven-development` (its per-task review loop). Other superpowers skills remain available as tools; the skill states that lean rules take precedence where they conflict.
 - [ ] Plan-writing skills are swappable (e.g. superpowers writing-plans today, grill-me or our own playbook later).
 ### Journals stay central
 - [ ] Session journals and the run log remain the record of a run. Journals are named as the raw material for later mining (future work, not this change).
 ## Out of scope
 - Building token introspection or signalling between sessions.
 - Running the trunk-and-forks trial itself (separate follow-up; preflight + trial venue TBD).
 - Changing the superpowers plugin.
@@ -0,0 +1,56 @@
 # Athanor — Igor Session Journal
 **Date**: 2026-10-05
 **Topic**: athanor — adjusting the development system (Athanor) for Opus 5.5
 **Worktree/branch**: main
 ## Log
 <!-- Append-only. This journal is the testimony of one path through the problem: record the tangents and dead ends, not only the results. The path can't be walked again; the record can be read. -->
 - 21:00 — Session start. `spire:igor` skill not registered in this remote session (`/reload-plugins` unavailable remotely); loaded skill from `plugins/spire/skills/igor/SKILL.md` directly. Spire agent types (athanor, researcher, search, adept…) not available as subagent_types — using general-purpose with explicit model.
 - 21:00 — Pulled main: f1de89e..08e22a7 (codex plugin icons/metadata, no Athanor changes).
 - 21:00 — Read `plugins/spire/agents/athanor.md` (pinned `claude-opus-4-6`; skills: spire:project, spire:workpad, spire:implementation, superpowers:*) and `plugins/spire/skills/implementation/SKILL.md`. There is no separate athanor skill.
 - 21:00 — Dispatched two search agents (Sonnet): ../spacecraft and ../dirigent, looking for recent reports about Athanor usage. User notes dirigent definitely has one.
 - 21:10 — Dirigent search back → `research/2026-10-05-21-athanor-usage-dirigent.md`. Primary source: dirigent `reports/2026-10-01-lean-process-report.md` + 2026-10-05 addendum addressed to spire authors. Key: athanor's internal end review (pinned 4.6) found 0 issues; independent Opus 5.5 review found 6 Important (incl. archive data loss). Proposals: model-id guard rails, plans/reviews outside athanor, per-block owner model, foreground-only grandchildren, athanor's job ends at blocks+tests+run log. Secondary: `2026-09-23-14-stalled-agents-forensics.md` (rate-limit kill, unclosed state).
 - 21:12 — Spacecraft search back → `research/2026-10-05-21-athanor-usage-spacecraft.md`. Spacecraft's "athanor" = superpowers `dispatching-orchestrator` (model: opus), not Spire's agent — same role, so findings transfer. Primary: `reports/2026-09-29-13-orchestration-overhead-attribution.md`, `reports/2026-09-27-13-strategy-mvp-retrospective/report.md`. Converges with dirigent: lean review (per hotspot/phase), foreground dispatch (bg grandchildren stall orchestrator), never carry implementer across tasks (960k tokens), `model: opus` alias silently overrode 4.6 pins (184/184 → 5.5), 5.5 plans ~11× oversized, weaken-check reflex, tests that can't fail.
 - 21:20 — User direction: overhaul/rewrite implementation skill + athanor for lean implementation. Points: superpowers ceremony (many pitstops) is the problem with 5.5; 5.5 plans excellent but long; review/test runs slow dev; build larger chunks, review once per phase; "attack the plan" after it is written; Sonnet experiment was partly plan issues, not only model; spawning rails per harness and per model; trunk-and-forks idea (adept-like trunk implementer, forks per task, updated by orchestrator, may live a whole phase); 5.5 fine to ~600k, both extremes (tiny implementers / keep-implementer) failed; skill must be lean and leave decision room — don't encode incidents as law. Dirigent lean report named as most mature source.
 - 21:20 — Dispatched Opus general-purpose agent → `reports/2026-10-05-21-implementation-skill-redesign.md` (diagnosis, principles, lean cycle, trunk-and-forks feasibility, classification principle/reference/project-setting/not-encoded, proposed SKILL.md outline + athanor changes, open questions).
 - 21:30 — Redesign report back → `reports/2026-10-05-21-implementation-skill-redesign.md` (author stamped claude-opus-5-5). Lean loop with explicit "attack the plan" step producing a separate build plan; athanor → build furnace pinned 5.5, superpowers dropped; reviews Igor-side. Trunk/forks: `fork` copies the caller → athanor itself must be the trunk; variant A (trunk notes) as baseline, B (athanor forks per complex block) as trial; preflight proposed. Classification table separates principle/reference/project/not-encoded. 7 open questions. Igor's notes: proposed SKILL grows 95→130-160 lines + 3 references + 2 new role agents — check against user's "lean skill" demand.
 - 21:40 — User: sizes are guesstimates for now (dirigent will work on orchestrator token introspection / signals into running work); Igor must own the design direction it delegates, not relay agent output. Asked how Igor understands "attacking the plan". Checked dirigent lean report: origin is the ~10-min step "plan comparison (adversarial, against the code, ~6 min) → amendment (fold blockers into plan B, cut into 6 blocks, ~4 min)" — "cheapest quality gate of the day". Igor's reading: the attack is the upstream counterweight that makes dropping per-task pitstops safe; the redesign report weighted it as restructuring and left the adversarial-against-code half as an optional merge — inverted emphasis. Also: athanor end review merely replayed the comparison's risk checklist → attack output must not become the reviewer's scope.
 - 21:50 — User corrections: superpowers not abandoned — rules changed (reports agree: spacecraft kept it, overrode via CLAUDE.local.md/templates/memories; dirigent kept athanor + lean brief). Redesign report's "drop superpowers" was the agent's proposal, not evidence. Model: `opus` alias passes Igor's model to the athanor; the "Pass" review was a 4.6 session (user's attribution; dirigent report could only say "unknown"). Model traits per user: 4.6 fast, capable, sometimes better at intent; 5.5 catches more, bolder decisions, can replace frequent small reviews (esp. Rust), but tends to take user's word as holy or reverse 100%. Igor gave its own athanor-process restructure in chat (see next entries).
 - 21:55 — Igor proposed Athanor restructure (Igor-side plan → attack → brief with deliberate model; Athanor phase turns: intake=trunk + trunk notes → foreground blocks, forks for complex trunk-area blocks, fresh for mechanical → gate → tests once → run log; Igor-side phase review with stamped id → resume Athanor for fix → next phase or fresh Athanor). User: fully agreed. 5.5 is the default; 4.6 to be replaced eventually but useful as "understanding the human" interpreter (Fable better). Keep superpowers as tools, drop subagent-driven-development preload. Future: grill-me or own playbook for plans; journals helped and are worth mining; dirigent now writes properly sized plans.
 - 22:00 — Wrote goal `goals/lean-athanor.md`. Decided to skip separate design+plan stages: markdown-only change, goal is precise — the goal is the spec. Dispatched one Opus implementer (general-purpose, model opus) → commits on main + `reports/2026-10-05-22-lean-athanor-implementation.md`. Fresh reviewer against the goal to follow.
 - 22:05 — User: bump the plugin version once the work is finished (Codex will also report how it performs). Told the implementer to skip its version bump; Igor bumps after review.
 - 22:12 — Implementer back (stamped claude-opus-5-5): commits `e515207`, `146a48c` on main, not pushed; report `reports/2026-10-05-22-lean-athanor-implementation.md` (uncommitted). SKILL.md 85 lines + 3 references; athanor pinned 5.5, preloads project/workpad/implementation; Igor stage 4b + phase review; harness-notes → pointer. No version bump. Flags: adept dispatch examples pass `opus` over 4.6 pin; igor/adept/zathras still pinned 4.6; harness "verified" = schema only; spire:project template lacks build-setting fields.
 - 22:12 — Dispatched fresh Opus reviewer against the goal → `reports/2026-10-05-22-lean-athanor-review.md`.
 - 22:20 — Review back (stamped claude-opus-5-5): pass with fixes, C0/I3/M8, 22/25 goal boxes met. I1 adept examples pass `opus` over pin; I2 nothing ensures plan/attack/review run on 5.5; I3 model-tiers routes research+impl to athanor as one brief. Notable minors: alias evidence confounded (use spacecraft 184/184); athanor pin lacks `[1m]` unlike other pins; fork availability itself unverified. Decision: one fix pass by resuming the implementer (≈150k ctx, resume from root is safe) — our own lean loop. Re-pin question stays with user.
 - 22:35 — Fix pass back: commit `5909221` (I1–I3 fixed, cheap minors fixed, `[1m]` left for user; fix-pass section appended to implementation report). Dispatched fresh Opus scoped re-check of I1–I3 only → appends to review report. Pending user: re-pin igor/adept/zathras; `[1m]` on athanor pin; then version bump 0.2.0, commit reports+journal, push on approval.
 - 22:40 — Re-check back (stamped claude-opus-5-5): I1–I3 confirmed fixed, no new Critical/Important. Loop stops here per stop rule. Logged minor: "Planned implementation" row (igor/SKILL.md:81, model-tiers.md:11) doesn't say the plan must be attacked first. Awaiting user decisions on pins before version bump.
 - 22:45 — User: athanor pin → `claude-opus-5-5[1m]`; zathras too. Igor and adept not re-pinned (stay `claude-opus-4-6[1m]`) — not decided, left as is. Dispatched Sonnet for pins + version bump 0.2.0 (both plugin.json) + commit of goal, reports, research, journal (explicit paths; user's own goal/spec edits untouched). No push yet.
 ## Adepts
 - Roster empty at boot (no adepts in this workpad).
 ## Artifacts
 - `docs/workpad/research/2026-10-05-21-athanor-usage-dirigent.md`
 - `docs/workpad/research/2026-10-05-21-athanor-usage-spacecraft.md`
 - `docs/workpad/reports/2026-10-05-21-implementation-skill-redesign.md`
 - `docs/workpad/goals/lean-athanor.md`
 - `docs/workpad/reports/2026-10-05-22-lean-athanor-implementation.md`
 - `docs/workpad/reports/2026-10-05-22-lean-athanor-review.md`
 - Commits `e515207`, `146a48c`, `5909221` (main, unpushed)
 ## Open threads
 - Version bump (Claude + Codex plugin.json, marketplace if it carries one) after review passes.
 - Trunk-and-forks preflight + trial (venue TBD).
 - Mine journals for deeper insights (future).
 - Minor: "Planned implementation" delegation row should note plan must be attacked first.
 - Follow-up: build-setting fields in `spire:project` template; pinned 5.5 planner/reviewer role agents (user decision).
 ## Graduation candidates
 - Attacking the plan = adversarial check against the code + reshape into build chunks, ~10 min; it is what pays for removing per-task review. (Rationale: easy to misread as mere regrouping; the misreading loses the quality gate.)
@@ -0,0 +1,202 @@
 # Redesign: `implementation` skill and `athanor` for lean building
 **Date**: 2026-10-05
 **Author**: Opus 5.5, model id `claude-opus-5-5` (from my system prompt; knowledge cutoff June 2026). I ran as a general-purpose subagent dispatched by Igor. This is a read-only proposal; no plugin files were changed.
 **Session journal**: [2026-10-05-21-athanor](../journals/2026-10-05-21-athanor.md)
 **Evidence**: dirigent [lean process report + 2026-10-05 addendum](/home/g4b/Projects/dirigent/docs/workpad/reports/2026-10-01-lean-process-report.md), dirigent memory (`feedback_review_by_risk`, `feedback_sonnet_first_draft`, `feedback_planner_agents`), spacecraft [overhead attribution](/home/g4b/Projects/spacecraft/docs/workpad/reports/2026-09-29-13-orchestration-overhead-attribution.md), spacecraft mindset ("Lean pipelines"), and the two survey notes [dirigent](../research/2026-10-05-21-athanor-usage-dirigent.md) / [spacecraft](../research/2026-10-05-21-athanor-usage-spacecraft.md).
 ---
 ## 1. Summary
 - The current skill and athanor load superpowers' subagent-driven development, which requires a review after every task ("Never skip the task review", up to 5 fix rounds). With Opus 5.5 this ceremony costs more than it catches. Dirigent measured lean as about 35–40% faster with about 40% of the fix churn. Spacecraft halved time per task once it dropped per-task review.
 - Proposal: rewrite `implementation` as a short **lean build loop**: plan, **attack the plan**, build in chunks, cheap gate between blocks, test and review once per phase, one fix pass, stop. It gives judgment guidance, not a rule set.
 - The athanor becomes a **build furnace**. It takes a reshaped plan whose blocks name their owner, builds a phase, runs the gate and tests once, and writes a run log with handoff notes. Planning, plan attack and phase review run outside it, dispatched by Igor, with model ids stamped.
 - Superpowers is no longer preloaded. Harness and model mechanics (background routing, alias-over-pin, fork, resume) move to reference files. Per-project choices (worktrees, staging, gate commands) move to `spire:project`.
 - **Trunk and forks** is feasible in Claude Code with one catch: `fork` copies the *caller*, so the athanor itself must be the trunk. I propose a two-arm trial.
 ## 2. Diagnosis
 | What is there today | What it causes | Evidence |
 |---|---|---|
 | Athanor preloads `superpowers:subagent-driven-development` and is told to "use the preloaded skills" | A per-task implement, review, fix, re-review loop by default. Lean has to be restated in every brief, and the skill still pulls the other way. | Dirigent A.10 #9: the brief "must spell out the process because athanor's defaults don't". Spacecraft: 1.8 verification seats per build seat. 11 of 13 re-reviews only confirmed the fix. |
 | Implementation skill: "Run tests between agents, not just at the end" | One test run per agent | Dirigent lean: compile gate only between blocks, one test run in block 6. That single run caught both real fallout problems. |
 | Implementation skill: "verify the fix yourself… read the diff, re-run tests" | The orchestrator becomes a verifier. Its context fills with diffs, and nothing is aimed at the real failure modes. | The real failure modes were weakened checks (3 times in spacecraft) and tests that cannot fail (Sonnet, skipped RED). A phase review aimed at those catches them better. |
 | Implementation skill: "Plan first … confirm with the user before touching code" | Fine for an interactive implementer. Wrong inside a closed-door furnace, and it invites a mid-run gate. | Dirigent memory `no_midway_smoke_gates`: "Why do I yet again need to check so much stuff manually?" |
 | Athanor: "Decompose first… Model tiers" (it picks the models), "Commit per plan step" | The athanor re-plans and re-assigns models. Plans with many steps produce many pitstops. | Dirigent A.2: "athanor should not pick or change the model itself". Spacecraft retrospective: 5.5 plans about 11× larger, with per-task cost rising from 10 to 70 min. |
 | Athanor pinned `claude-opus-4-6`; Igor tells it to use `model: "opus"` | Nobody can tell which model ran. The aliases override pins. | Dirigent: the athanor's end review found 0 findings, "model unknown". An independent 5.5 review found 6 Important, including archive data loss. Spacecraft: `model: "opus"` overrode the 4.6 pin in 184 of 184 spawns. |
 | Neither file says anything about notification routing, foreground or background, or context budgets | Orchestrator stalls. Implementers run to 500k–960k tokens. | Spacecraft E5: "athanor stalled twice … nudged". Spacecraft B3: one implementer reached about 960k. Dirigent: Sonnet implementers reached 500k–750k. |
 | Igor: "User conventions. Subagent-driven execution with review between tasks." | Igor writes per-task review into every brief | Superseded by the user's lean direction (2026-10-05). |
 | `igor/references/model-tiers.md`: "Prefer Opus 4.6 for implementation… Opus 5 tends to hallucinate" | Points implementation at the model whose plans broke archive compat | Dirigent §4.3: the 4.6 plan misidentified the root cause. The 5.5 plan traced it in code. |
 **What the current skill gets right and should keep:** sequence by default; one agent owns each coherent change; hand over as commits, not descriptions; for bugs, prove with a failing test and explore before focusing; journal hard bugs. These are durable and short.
 ## 3. Design principles (for the new skill)
 1. **The plan is the main lever.** Most defects trace to the plan. In dirigent, about 4 of the 6 Important findings were plan gaps that any implementer would have carried out faithfully. Spend effort attacking the plan before building, not reviewing after every step.
 2. **Build in large chunks, check once per phase.** Between blocks, run only a cheap gate (compile or typecheck). Run tests and one adversarial review when a phase reaches a testable state.
 3. **Review by risk, outside the build.** A fresh reviewer that did not write the code and did not set the checklist looks for bugs. It answers every flag in the handoff notes and looks specifically for weakened checks and tests that cannot fail.
 4. **Context is a budget, not a rule.** Neither relearn per task nor carry an agent forever. Choose by how much shared understanding the next block needs and how much budget is left.
 5. **Know what ran.** Pin models by full id where the harness allows it, and every output stamps the model id it ran on. A review without a stamped id does not count.
 6. **Closed door.** Decisions are made before the run. Inside the run: take the conservative default, flag it, continue.
 7. **Judgment over procedure.** The skill gives defaults and the reason for each. It does not try to anticipate every incident.
 ## 4. The lean cycle
 ```
 Igor:     plan (5.5) ──► attack the plan (fresh 5.5) ──► [user sees reshaped plan; non-blocking unless asked]
 Athanor:  phase N: block → gate → block → gate → … → tests once → run log (handoff notes, flags)
 Igor:     phase review (fresh, pinned/stamped, adversarial) ──► fix pass ──► scoped re-check if Critical/Important ──► next phase
 ```
 | Step | Who | What it produces | Judgment left open |
 |---|---|---|---|
 | **Plan** | Igor dispatches a write-capable 5.5 planner, never the athanor | Plan file with decisions made, consumers of every changed semantic, completion criteria | Depth. 5.5 plans are good but long, so scope is trimmed in the next step rather than capped up front. |
 | **Attack the plan** | Fresh agent, not the planner (the separation rule holds). Can be the same pass as the plan review. | A new **build plan** file (the original plan is not changed): regrouped into **phases** (each ends testable) and **blocks** (one owner's chunk, cut by crate or layer). Each block has an owner model, a gate command and its expected-broken areas. Each phase has review points placed by risk. Scope is trimmed back to the goal. Open user decisions are listed. | How big the blocks are, how many phases, whether a hotspot earns a mid-phase review, what to cut. Its output must say *why* it placed reviews where it did. |
 | **Build a phase** | Athanor. Each block goes to a fresh implementer, a fork of the trunk, or a phase-resident implementer (see §5), always in the foreground. | Commits per block. One handoff note per block: done / deviations / flagged-for-review / left-for-later / expected-broken / model id / start and end from `date` / tokens. | Splitting a block that grows. Choosing a fresh agent or a fork. Picking defaults on small undecided points. |
 | **Gate** | The block's owner runs it | Cheap check (compile, typecheck) on the areas the block owns. It may leave the rest of the workspace broken if the plan says so. | Which command to use. That comes from the project config. |
 | **Tests once** | Last block of the phase, or a cheap-tier runner | Full relevant suite, with fallout fixed in the same block | Whether a targeted fail-first test belongs in a block. Yes for bugs. Suites wait for phase end. |
 | **Phase review** | Igor dispatches a fresh reviewer with a stamped id | Findings by severity, each in a plain sentence. It answers every handoff flag. It checks explicitly for weakened assertions, downgraded checks and tests that cannot fail. | Review depth by phase risk. A mechanical-only phase may get a light review or just the tests. |
 | **Fix pass** | One fixer for all findings | One commit or a few commits | A fresh fixer or the phase's resident or trunk agent, depending on its budget (open question, §8). |
 | **Scoped re-check** | Fresh reviewer, only for Critical or Important findings | Confirmed / not confirmed | Then **stop**. Minor findings go to a follow-up list. |
 **Why reviews stay outside the athanor for now:** independence, and because the user sees phase boundaries without being asked to gate them. Once a reviewer role is pinned by full id in an agent definition, the athanor *could* dispatch it safely. That option is §8 Q3.
 **Small jobs:** if the build plan has one phase and one or two blocks, skip the athanor. Igor dispatches the implementer and the review directly. The athanor is worth its cost only when there is something to orchestrate.
 ## 5. Trunk and forks
 ### 5.1 The idea, made concrete
 A **trunk** is an agent that has read the code relevant to the plan: the key files, seams, conventions and the consumers of the semantics that change. A **fork** starts from the trunk's context. It gets a short orientation ("you are now the detail implementer for block X") and a **delta** (commits since the trunk oriented, handoff notes of earlier blocks, which block it takes over). It does not relearn the codebase. It can stay for a whole phase while its budget lasts.
 ### 5.2 What Claude Code offers
 | Mechanism | Status | Source / note |
 |---|---|---|
 | `Agent(subagent_type: "fork")` exists. Forks **always inherit the parent's model**; the `model` parameter is ignored. | **Verified** | The `Agent` tool schema available to me in this session |
 | A fork copies **the caller**, not an arbitrary child | **Verified in substance.** The Igor skill describes it as "forking yourself", and no parameter names a fork source. | Consequence: only the agent that holds the trunk context can fork it. |
 | A fork inherits the caller's full transcript as context, so the fork starts at the trunk's token count | **Assumed** (implied by the name and by Igor's "synthesizing boot data" use). Not measured. | Prompt caching probably makes this cheap. Unverified. |
 | `Agent` calls run in the **background by default**; `run_in_background: false` makes them foreground | **Verified** | Tool schema: "Subagents run in the background by default" |
 | Background grandchildren notify the **session root**, not their parent | **Verified by incident** | Spacecraft E5. Dirigent memory (settled 2026-09-29). `igor/references/harness-notes.md` |
 | `SendMessage` to a completed agent's name resumes it from its transcript | **Verified** | SendMessage schema: "a send resumes it from its transcript" |
 | A resume issued from inside a subagent runs asynchronously, and its completion goes to the root, so the parent stalls | **Observed once, mechanism assumed** | Spacecraft 2026-10-05: "orchestrator resumed its C.1 implementer via SendMessage → bg → yielded". Resumes from Igor (the root) are safe, because Igor *is* the root. |
 | The per-call `model` takes only aliases (`opus`/`sonnet`/`haiku`/`fable`) and **overrides** the agent definition's frontmatter pin | **Verified** | Agent schema: "Takes precedence over the agent definition's model frontmatter". Matches 184/184. |
 | A full-id pin is possible only in the agent definition (`model: claude-opus-5-5`), and only if the caller **omits** `model` | **Verified by inference** from the line above. The pin itself works (athanor and adept use it). | So owner model by full id means pinned role agents, not per-call ids. |
 | Agents see their exact model id in their system prompt | **Verified for this harness** (mine shows `claude-opus-5-5`) | Makes stamping reliable |
 | Can a fork fork again? Does a foreground fork block the caller and return its result? Does a fork see the caller's preloaded skills? | **Unknown.** Must be checked in the preflight below. | |
 | Plugin agent types (`athanor`, `adept`, …) may not be registered in a remote session | **Observed** (this session's journal, 21:00) | Fallback: general-purpose, with the agent file's body pasted into the brief |
 ### 5.3 Three variants
 - **A. Trunk notes (no harness risk).** The first block's implementer, or a short orientation agent, writes `trunk.md` next to the run log: key files, seams, invariants touched, how to run the gate, consumers. Every later implementer, fresh or Sonnet, reads it first. This works today, works with any owner model, and is the baseline the others must beat. It is a phase-local, throwaway cousin of the adept handoff.
 - **B. Athanor as trunk, forks per block.** At intake the athanor reads the build plan and the code the plan names, roughly 100–250k tokens. It then forks itself per complex block, in the foreground, with the delta brief. Forks inherit the athanor's model, so the athanor must be pinned to the build model (5.5). Blocks owned by Sonnet go to fresh agents with variant A's trunk notes. The athanor's own context grows only by fork *results*, which are short final reports. This is the closest match to the user's idea, and the athanor's intake read also makes it a better judge of handoff flags.
 - **C. Phase-resident implementer.** One implementer per phase receives block after block. Inside the athanor this requires SendMessage resumes, which hit the routing hazard, so C is safe only with Igor as the resumer, and Igor then becomes the orchestrator. Not recommended as the default. It is the shape that reached about 960k in spacecraft.
 ### 5.4 When to use what (guidance for the skill, not rules)
 - **Fresh agent with trunk notes:** mechanical blocks, Sonnet-owned blocks, and blocks in a different area from the trunk's orientation.
 - **Fork of the trunk:** complex blocks in the area the trunk read, where relearning would cost more than the inherited context. This is the case where the fork's shared understanding pays for its tokens.
 - **Keep an agent for the next block** (via fork-of-trunk, or by giving one fork two adjacent blocks): only when the blocks share a seam *and* the agent will stay under budget.
 **Context budget (Opus 5.5, user-observed):** comfortable to about 600k. Aim to keep a worker below about 400k so it has room for fallout. Plan a handoff around 500k. A trunk worth forking is about 100–250k, so a fork starts there. If a block's estimate pushes a fork past about 450k, use a fresh agent with trunk notes instead. Agents cannot see their own size, so the athanor reads usage from completion results and records tokens per block. (I assume the results carry usage, because dirigent's run log recorded per-block tokens. Verify in the preflight.) Sonnet and Opus 4.6 limits go in the model reference as observed figures, not laws.
 ### 5.5 Trial proposal
 1. **Preflight (about 10 min, throwaway branch, foreground only, under the host's memory cap).** A pinned 5.5 test athanor reads 3 files, then forks once with `run_in_background: false`. Check: (a) the call blocks and returns the fork's result to the parent; (b) the fork can quote a detail only the parent read; (c) the fork stamps `claude-opus-5-5`; (d) the token count the fork starts at; (e) whether the fork can call `Agent` again; (f) what happens with `run_in_background: true` (expected: notifies the root). Write the results into the spawning reference.
 2. **Trial (next real multi-phase plan in dirigent or spacecraft, at least 4 blocks, at least 2 hotspot blocks).** Phase 1 uses variant A. Phase 2 uses variant B for complex blocks. If the phases differ too much, run B on one plan and A on a comparable one.
 3. **Measure:** wall clock from git; tokens per block including inherited context; relearning, counted as file reads before the first edit; Important findings per kLOC at phase review; whether handoff flags were accurate; stalls; any fork that drifted (worked from stale inherited assumptions after earlier blocks changed the code). That last one is B's specific risk, and the delta brief exists to counter it.
 4. **Decide:** B becomes the default for complex blocks only if it is at least as clean and measurably cuts relearning or time. Otherwise A stays the default and B becomes an option.
 ## 6. Classification of lessons
 | Item | Class | Where it goes / why |
 |---|---|---|
 | Build in chunks; gate cheaply between blocks; tests and review once per phase | **Principle** | SKILL.md |
 | Attack the plan after it is written (regroup, place reviews by risk, trim scope, owner per block) | **Principle** | SKILL.md + Igor cycle |
 | Plans list every consumer of a changed semantic | **Principle** | SKILL.md (one line, part of the attack) |
 | Reviewer is fresh, adversarial, answers every handoff flag, hunts weakened checks and tests that cannot fail | **Principle** | SKILL.md |
 | Re-check only Critical or Important, by a fresh reviewer; minors fixed in the pass or logged; then stop | **Principle** | SKILL.md |
 | Context is a budget; choose fresh / fork / keep by shared understanding versus remaining budget | **Principle** | SKILL.md (figures go in the reference) |
 | Stamp model ids; a review without one does not count | **Principle** | SKILL.md |
 | Closed door: decide before the run, default and flag inside it | **Principle** | SKILL.md + athanor |
 | Handoff note fields; run-log table; times from `date`, durations from git | **Reference** (template) | `references/run-log.md` |
 | Background children notify the root; foreground for sequential work; Igor resumes, the athanor does not | **Reference** (harness) | `references/spawning-claude-code.md` |
 | Alias overrides frontmatter pin; full id only via agent definition; omit `model` for pinned roles | **Reference** (harness) | same |
 | Fork semantics (copies the caller, inherits model), resume semantics, `ListAgents`, `TaskStop`, `TaskOutput` is not for agents | **Reference** (harness) | same (absorb `igor/references/harness-notes.md`) |
 | Plugin agent types missing in remote sessions; fallback | **Reference** (harness) | same |
 | Model traits: 5.5 good to about 600k, plans thorough but long; Sonnet clean on mechanical work, wrote tests that cannot fail, ran out of context at 500–750k on complex blocks; Haiku self-reports are claims | **Reference** (models) | `references/models.md`, as observations with date and source |
 | Worktrees on/off; branch ownership; explicit-path staging (`git add <file>`) | **Project setting** | `spire:project` |
 | Gate command(s), test command(s), feature-combo compile | **Project setting** | `spire:project` |
 | Host rules: TMPDIR, memory caps, no background loops, PATH additions (fnm) | **Project/host setting** | `spire:project` or user CLAUDE.md (already there) |
 | Standing brief constraints by area (e.g. archive backward compatibility) | **Project setting** | `spire:project` ("inject into every brief touching X") |
 | Default owner models per block kind; reviewer role agent name | **Project setting** with a plugin default | `spire:project` |
 | Sequential versus parallel blocks default; whether the user wants to see the build plan | **Project setting** | `spire:project` |
 | No external writes (issues, PRs upstream) | **Project setting** (already a user convention for PRs) | `spire:project` |
 | "Sonnet is not good for complex work" | **Not encoded as law** | About 4 of 6 findings were plan gaps (dirigent §3.2). It becomes a model observation plus "owner by block nature". |
 | "Never carry an implementer across tasks" | **Not encoded** | One 960k drift. Replaced by the budget guidance; the opposite extreme also failed. |
 | Journal clock drifted 2.5× | **Not encoded** (beyond "times from `date`" in the template) | A one-off measurement bug |
 | OAuth expiry / 429 spend limit killed agents | **Not encoded** | Environmental. "Re-dispatch fresh from last commit + handoff" is already what handoff notes enable. |
 | Mutation checks in fresh `CARGO_TARGET_DIR`s; golden re-bless policy; oracle ceremony | **Not encoded** | Project- and plan-specific test tooling. A reviewer may choose mutation on hotspots. |
 | Plan size cap (≤60KB), block size 10–40 min / "2–3 h" | **Not encoded as numbers** | Situational. The attack step owns scope and sizing. 10–40 min goes in the models reference as one observation. |
 | 5-round fix cap, minors ledger, ruling format, preflight table | **Not encoded** | Superpowers ceremony this redesign removes |
 | Overnight `AskUserQuestion` blocked 5.9 h | **Not encoded** | Covered by the closed-door principle |
 | "Opus 5 hallucinates" in model-tiers | **Remove** | Stale. Contradicted by 5.5 evidence. |
 | Mid-run hotspot review (dirigent change 5) | **Not a rule** | The attack step may place one, with a reason. That is the judgment room. |
 | "One at a time, review between each" (dirigent 2026-09-19) | **Not encoded** | Superseded by lean |
 ## 7. Proposed changes
 ### 7.1 New `skills/implementation/SKILL.md` (budget about 130–160 lines; today about 95)
 **Frontmatter description:** "Drive implementation lean: shape the plan into phases and blocks, build in chunks with cheap gates, test and review once per phase, fix once, stop. Use when executing a plan, building a feature, or fixing non-trivial bugs. Harness and model mechanics are in references/."
 1. **What this is (5 lines).** How to drive building, not how to write code. Default: lean. Ceremony is opt-in and needs a stated reason. *"Every check re-reads the same code. One strong check sized to the risk beats several small ones."*
 2. **Lean loop (about 20 lines).** The diagram from §4 plus one line per step. *"Between blocks: a gate, not a review. At phase end: tests once, one adversarial review, one fix pass, a re-check only for Critical/Important, then stop. Minors are fixed in the pass or logged."*
 3. **Attack the plan (about 20 lines).** *"A good plan is the cheapest quality gate. Before building, a fresh agent that did not write the plan reshapes it: group steps into phases that end testable and blocks one owner can finish; give each block an owner model, a gate and its expected-broken areas; place review points where the risk is and say why; list every consumer of each changed semantic; cut what the goal does not need; list decisions the user must make before the run. Write it as a new build-plan file; never edit the original."* Hint: owner by block nature (hotspot → strongest model; mechanical → cheaper), *"and remember that most defects that look like weak drafting were plan gaps."*
 4. **Building (about 20 lines).** Sequence by default (keep the current wording, shortened). One owner per coherent change. Hand over via commits plus a handoff note (template in `references/run-log.md`). *"Stage only your own paths."* Bugs: keep the prove-first and explore-first section, shortened to about 8 lines.
 5. **Context: fresh, fork, or keep (about 15 lines).** The §5.4 guidance in prose. *"Both extremes have failed: many tiny fresh agents relearn and fragment the plan; one agent kept too long drifts. Pick per block: how much shared understanding does it need, and how much budget is left? Budgets per model are in references/models.md."* Pointer to the trunk-and-forks option, marked experimental until the trial lands.
 6. **Review (about 15 lines).** Fresh, adversarial, not the author, does not get the builder's checklist as its scope. *"Answer every deviation and flagged line in the run log. Look specifically for weakened or downgraded checks, tests that cannot fail, and consumers the plan missed. Run the gates yourself. Stamp your model id."* This replaces "verify the subagent's test fix yourself".
 7. **Closed door (about 6 lines).** *"Decisions belong before the run. Inside it: take the conservative default, flag it in the handoff note, continue. Never block on the user."* (For an interactive implementer outside the athanor: confirm the build plan with the user only if the project config asks.)
 8. **Spawning and models (about 6 lines).** *"Read references/spawning-<harness>.md before dispatching. Pin roles by full model id where the harness allows; stamp ids in every output."*
 9. **Writing things down (about 8 lines).** Keep the current workpad section, minus "confirm with the user". Add the run log as the run's single record.
 10. **Project settings this skill reads (about 6 lines).** Worktrees, staging, gate and test commands, owner-model defaults, standing brief constraints. These come from `spire:project`; a brief overrides the skill's defaults.
 11. **Composition (about 4 lines).** `workpad`, `research-tree`. *"Superpowers' per-task loops are not the default here; use them only when a plan explicitly asks for per-task review."*
 **Remove:** "Run tests between agents", "verify the fix yourself" (replaced by §6), "Plan first … confirm with the user", "runs alongside superpowers".
 ### 7.2 New reference files
 - `skills/implementation/references/spawning-claude-code.md` (about 70–90 lines). The §5.2 table, written as rules of thumb: foreground for sequential work; background only for independent leaves whose result goes to the root; resume from the root only; fork copies the caller and inherits its model; per-call `model` overrides pins (omit it for pinned roles); missing plugin agent types (fallback); `ListAgents` / `TaskStop`; leaf briefs say "do not dispatch". It absorbs and replaces `igor/references/harness-notes.md` (Igor points to it). Add a "Verified on" date and Claude Code version line per claim. Other harnesses (e.g. Codex) get their own `spawning-<harness>.md` when needed.
 - `skills/implementation/references/models.md` (about 40 lines). One block per model with full id, strengths, observed weaknesses, observed comfortable context, and source plus date. Each observation is labelled observed, not law. It replaces the model sections of `igor/references/model-tiers.md`, which keeps only the agent-type table.
 - `skills/implementation/references/run-log.md` (about 30 lines). Run-log header (plan path, branch, start commit). Per-block table (block, owner, stamped id, start and end from `date`, tokens, commit). Handoff-note fields. Closing "flags for the reviewer" list. "Provisional until the phase loop closes."
 ### 7.3 `agents/athanor.md`
 - **Frontmatter:** `model: claude-opus-5-5` (forks inherit it, and the intake judgment needs it). `skills: [spire:project, spire:workpad, spire:implementation]`. Drop all `superpowers:*`. Description: "Build furnace: takes a build plan (phases, blocks, owner per block), builds one phase at a time, runs the gate and tests once per phase, writes the run log. Does not plan, attack plans or review its own output."
 - **Body (about 40 lines, replacing the operating rules):**
  - *Intake:* read the build plan and the project config. Verify the branch named in the brief and stop if it differs. Read the code the plan names; this is the trunk (variant B, behind a brief flag until the trial ends). Write trunk notes (variant A) in any case.
  - *Build:* blocks strictly in the plan's order, always foreground. Dispatch each block with its owner: a pinned role agent with `model` omitted, or a fork for trunk-area complex blocks in trial mode. Never change an owner. If a block's owner model cannot be honoured, record that in the run log.
  - *Do not:* re-plan, reorder phases, review, ask the user, or SendMessage-resume a child.
  - *End of phase:* run tests once, fix fallout in that last block, complete the run log, and return. Igor reviews. On resume with findings: dispatch one fix pass, then return again.
  - Keep: goals read-only, agents write their own reports, stay in your lane, never open PRs, one plan at a time.
  - *Non-build briefs* (research cascades, audits): allowed, but say so in one line. That is a different shape, and the lean loop does not apply.
 - **Role agents to add** (small files): `builder` (pinned `claude-opus-5-5`, write tools, no Agent tool) and `reviewer` (pinned `claude-opus-5-5`, can run commands, writes its report, no Agent tool). For Sonnet-owned blocks, either a `builder-sonnet` pinned by full id or the alias `sonnet` with stamping (the full Sonnet id is not known to me; see Q5).
 ### 7.4 Knock-on changes to Igor
 - **Development Cycle:** add stage **4b Attack the plan** (fresh agent, produces the build plan; may be merged with the plan review). Stage 5 becomes "Build, one phase per athanor turn". Stage 6 becomes "Phase review, dispatched by Igor, reviewer id stamped". Add the stop rule to the decision tree: one fix pass, a re-check only for Critical/Important, minors logged, then the next phase.
 - **Athanor queuing:** add "between phases Igor resumes the same athanor via `SendMessage` (safe from the root) if its context is under budget; otherwise it starts a fresh athanor from the run log and trunk notes".
 - **Rules:** replace "Subagent-driven execution with review between tasks" with "Lean build: review once per phase (see `spire:implementation`)". Replace "Model must be explicit" with: "explicit alias for generic agents; **omit** `model` for pinned role agents (athanor, builder, reviewer, adept). An alias silently overrides their pin."
 - **Delegation table:** "Planned implementation" points to `athanor` (multi-block) or `builder` (single block). The model notes move to `implementation/references/models.md`.
 - **Worktrees:** "Prefer working on main" stays the plugin default. Worktree use moves to project config (Igor currently *suggests* worktrees for code runs; dirigent overrides that).
 ## 8. Open questions for the user
 1. **Should the plan attack be the same pass as the plan review?** I lean yes (dirigent's comparison plus amendment took about 10 minutes and did both). The alternative is two agents.
 2. **Should the user see the build plan before the run?** As a non-blocking notification, or as a project setting that makes it a gate?
 3. **Should the phase review stay with Igor permanently**, or move into the athanor once a pinned `reviewer` role exists? Inside the athanor, the build gets fewer round-trips. With Igor, the build stays independent and the phase boundaries stay visible.
 4. **Who fixes after review:** one fresh 5.5 fixer (dirigent's data favours it), or the trunk or a fork while it is under budget (it knows the code)?
 5. **Sonnet owner blocks:** should we pin a `builder-sonnet` by full id (which id?), or accept the alias plus stamping?
 6. **Trial venue for trunk and forks:** dirigent or spacecraft, and which plan? Is the preflight in §5.5 acceptable on a throwaway branch?
 7. **Athanor scope:** should non-build briefs (research cascades, audits) stay with the athanor, or move to a separate orchestrator so the athanor is purely a build furnace?
@@ -0,0 +1,103 @@
 # Lean Athanor — implementation report
 **Date**: 2026-10-05
 **Author**: Opus 5.5, model id `claude-opus-5-5` (from my system prompt). I ran as a general-purpose subagent dispatched by Igor, and did the work myself without dispatching agents.
 **Goal**: [lean-athanor](../goals/lean-athanor.md)
 **Session journal**: [2026-10-05-21-athanor](../journals/2026-10-05-21-athanor.md)
 **Commits** (on `main`, not pushed): `e515207` 🤖 Rewrite implementation skill and Athanor for lean building; `146a48c` 🤖 Align Igor with the lean build cycle.
 ## Files changed
 | File | Change |
 |---|---|
 | `plugins/spire/skills/implementation/SKILL.md` | Rewritten as the lean loop: intent, defaults and reasons. 85 lines (was 81). |
 | `plugins/spire/skills/implementation/references/spawning-claude-code.md` | New. Harness rules of thumb, plus claim tables marked verified / observed / assumed / unknown, with dates. Absorbs Igor's harness notes. |
 | `plugins/spire/skills/implementation/references/models.md` | New. Model observations per model, with dates and sources. Context figures labelled as guesstimates. Token introspection listed as future work. |
 | `plugins/spire/skills/implementation/references/run-log.md` | New. Run-log header, per-phase table, handoff-note template, phase-close block, trunk notes. |
 | `plugins/spire/agents/athanor.md` | Build furnace. Pinned to `claude-opus-5-5`. Preloads only project, workpad and implementation. Superpowers listed as tools. Keepers kept. Non-build briefs allowed. |
 | `plugins/spire/skills/igor/SKILL.md` | Targeted edits: Athanor table row and paragraph, the model rule, Development Cycle (4b attack, 5 build, 6 phase review, decision tree with the stop rule), Athanor queuing (resume or start fresh), User conventions, and the harness-notes pointer. Voice section not touched. |
 | `plugins/spire/skills/igor/references/model-tiers.md` | Athanor row updated. The stale 4.6 / "Opus 5 hallucinates" rule is gone. Model rules now cover alias-over-pin and point to `models.md`. |
 | `plugins/spire/skills/igor/references/harness-notes.md` | Now a short pointer with a 4-line summary for Igor. |
 | `plugins/spire/README.md` | Rows for `implementation` and `athanor` updated. |
 Checked and left alone: `agents/igor.md`, `plugins/spire/CLAUDE.md` and both `plugin.json` files. None of them contradicts the athanor pin, the superpowers preload or per-task review. Following Igor's mid-task instruction, I did not bump the version.
 ## Goal checkboxes
 **The skill is lean**
 - Intent and defaults with reasons, room for judgment, no single incidents as rules → `implementation/SKILL.md` throughout. Each section gives a default and a "why". Incident evidence sits only in `references/models.md` and `spawning-claude-code.md`, with sources.
 - Short → 85 lines, against 81 before. Detail lives in the three references.
 - Harness mechanics and model traits in references; project choices from `spire:project` → SKILL "Spawning and models" points to the references. SKILL "Project settings" lists worktrees, branch, staging, gate/test commands, owner-model defaults, standing constraints and host rules as read from `spire:project`, with the brief taking precedence.
 **Attacking the plan**
 - Explicit step after planning: fresh agent, adversarial against the code, then reshape, one step → SKILL "Attack the plan", paragraph 1. Igor's Development Cycle stage (4b).
 - It pays for dropping per-task review → SKILL "Attack the plan", paragraph 2; Igor (4b) "It is what pays for dropping per-task review."
 - Intent, not a checklist of output fields → SKILL prose. No required fields.
 - Risk list is not the phase reviewer's scope → SKILL "Attack the plan", paragraph 3; Igor stage (6).
 - Outside the Athanor, user sees the reshaped plan → SKILL cycle diagram and "Under Igor, Igor dispatches the plan, the attack and every phase review"; Igor (4b) "Show the user the build plan and its open decisions before the door closes"; athanor "Keepers": it does not plan or attack.
 **Lean build loop**
 - Gate between blocks; at phase end tests once, one review, one fix pass, re-check only Critical/Important, stop; minors fixed or logged → SKILL "Building a phase" and "Phase review, fix, stop"; Igor decision tree items 1–2.
 - Phase review dispatched by Igor, fresh, model id stamped, answers every flag, hunts weakened checks and tests that cannot fail → SKILL "Phase review, fix, stop"; Igor stage (6).
 - Extra reviews possible as a reasoned choice → SKILL "Attack the plan", paragraph 3, and the last bullet of "Phase review"; Igor "long loops and extra reviews … need a stated reason".
 **Athanor is a build furnace**
 - One phase per turn: intake (trunk and trunk notes), foreground blocks, gate, tests once, run log, hand back → `athanor.md` "One phase per turn", steps 1–6; template in `run-log.md`.
 - Igor resumes for the fix pass and the next phase, or starts fresh from the run log and trunk notes → Igor "Athanor queuing"; `athanor.md` "When Igor resumes you…"; the athanor deliverable reports whether it has room left.
 - Plan sets block size and owner defaults; Athanor may deviate with a logged reason → `athanor.md` paragraph after the steps; SKILL "Deviate with a reason".
 - Does not plan, attack plans, or review its own output → `athanor.md` frontmatter description and the first keeper.
 - Trunk and forks as an option, verified vs. assumed marked, forks inherit the model → SKILL "Context: fresh, fork, or keep", paragraph 2; `athanor.md` step 2; `spawning-claude-code.md` "Fork" table (inherits model: verified; copies the caller and starts at the caller's token count: assumed; nested forks and foreground return: unknown).
 **Models**
 - Opus 5.5 is the default for Athanor, planning, attack and review; Athanor pinned → `athanor.md` `model: claude-opus-5-5`; `models.md` "Defaults"; Igor stages (4), (4b), (6); `model-tiers.md` last rule.
 - Alias-over-pin; omit `model` for pinned agents unless deliberately overriding; stamp → Igor "Model must be explicit — and deliberate"; `model-tiers.md` rules; `spawning-claude-code.md` "Models" table.
 - Model notes are observations, not law, with the user's points → `models.md` (5.5: catches more, bold, replaces small reviews especially in Rust, holy-word / 100% reversal; 4.6: fast, capable, better at intent, "understanding the human" interpreter; Fable better still; Sonnet/Haiku neutral, and the Sonnet experiment's defects are attributed largely to the plan).
 - Stale guidance removed → `model-tiers.md` (4.6 rule gone); Igor User conventions ("review between tasks" gone); old SKILL "Run tests between agents" gone. `models.md` records the withdrawal with its date.
 **Context sizes are guesstimates**
 - Figures labelled as guesstimates; judgment between the two extremes → `models.md` intro and the "Context and block size" section; SKILL "Context: fresh, fork, or keep", paragraph 1.
 - Future work: introspection and signals → `models.md`, the last paragraph.
 **Superpowers is a toolbox**
 - `subagent-driven-development` no longer preloaded; other skills remain tools; lean rules win → `athanor.md` frontmatter (no superpowers) and "Tools, not the loop"; SKILL "Composition".
 - Plan-writing swappable → SKILL "Attack the plan", last paragraph.
 **Journals stay central**
 - Journals and the run log are the record; journals are raw material for later mining (future work) → SKILL "Writing things down"; `run-log.md` intro.
 ## Deviations from the goal or brief
 - **No version bump.** The brief asked for one; Igor withdrew that mid-task. Both `plugin.json` files are untouched.
 - **Igor's Athanor paragraph and delegation-table row changed.** These were not on the list of targeted edits. They said "it decomposes the work itself" and did not mention the pin, which contradicts the build-furnace role and the model rule. I changed only those two lines.
 - **Igor's harness-notes pointer rule changed** to name the new reference. `harness-notes.md` is kept as a short pointer, so both paths work.
 - **Small jobs without the Athanor.** The redesign's "skip the athanor for one or two blocks" is covered by the SKILL's "If one agent can do the whole change in one go, do it inline". I added no separate rule for it.
 ## Flagged for the reviewer
 1. **Adept dispatch still passes `model: "opus"`.** `adept.md` is pinned to `claude-opus-4-6[1m]`, and Igor's adept spawn examples and table row pass `opus`. Under the new rule this counts as a deliberate override, so the adept gets whatever `opus` resolves to, not 4.6. I deliberately did not name adept in the rule's examples, and I left the adept lines alone because they are out of scope. Decide whether adepts should drop the alias or keep the override.
 2. **Igor, adept and zathras are pinned to `claude-opus-4-6[1m]`.** The goal sets 5.5 as the default for the Athanor, planning, attack and review, not for Igor. I left these pins alone. Combined with the alias rule, an Igor on 4.6 that passes `opus` to a general-purpose agent may get 4.6 (the user's observation). For planner, attack and review dispatches that should be 5.5, Igor may need a pinned role agent, or Igor itself on 5.5. I did not add new role agents (out of scope).
 3. **How the alias resolves.** The two observations conflict on the surface. Spacecraft saw `opus` resolve to 5.5 in 184 of 184 cases, probably under a 5.5 caller. The user saw a 4.6 Igor produce a 4.6 Athanor. I recorded both, marked the mechanism as assumed, and wrote the rule so it holds either way: the alias, not the pin, decides.
 4. **"Verified" claims rest on the tool schema** visible to me on 2026-10-05, not on executed tests. Fork behaviour beyond "inherits the model" is assumed or unknown. The trunk-and-forks option is described as such, and the preflight is still pending (out of scope).
 5. **The `spire:project` template** (`igor/references/project.md`, `/spire:init`) has no dedicated fields for the build settings the skill now reads: worktrees, gate commands, owner-model defaults, standing constraints. They fit under "Verification commands" and "Conventions" today. A follow-up could add explicit fields. I left it alone because it was not in scope.
 6. **The Haiku note in `models.md`** ("reported 'no deviations' alongside misplaced edits") is single-incident evidence. It sits in a reference with its source, which the brief allows, but it is the least neutral line in the Sonnet/Haiku section.
 7. **Igor decision tree item 2** sends Critical/Important findings to one fix pass by resuming the Athanor. The goal does not settle who fixes (a fresh fixer or the Athanor). The SKILL leaves it open, and Igor's text defaults to the Athanor because the goal says "Igor resumes the Athanor … for the fix pass".
 ## Fix pass
 **Author**: `claude-opus-5-5`. **Commit**: `5909221` 🤖 Apply lean Athanor review fixes. Review: [2026-10-05-22-lean-athanor-review](./2026-10-05-22-lean-athanor-review.md).
 | Finding | Status | Where / reason |
 |---|---|---|
 | I1 adept `model: "opus"` over the pin | fixed | `igor/SKILL.md`: the table row and the three spawn templates no longer pass `model`. No agent pins changed. |
 | I2 nothing secures 5.5 for plan, attack and review | fixed (guard only) | `igor/SKILL.md` model rule: Igor checks the stamped id of the plan, attack and phase review, and re-dispatches or tells the user if it is not the intended model. Pinned 5.5 role agents remain a follow-up. |
 | I3 research + implementation go to the Athanor as one brief | fixed | `model-tiers.md`: implementation goes plan → attack → build; the Athanor gets only build plans or non-build briefs. |
 | Legend: "verified" means read from the schema | fixed | `spawning-claude-code.md` legend. Fork availability is a separate row, marked unverified. The model-id row is now "observed" for general-purpose agents only. |
 | M2 confounded alias-over-pin evidence | fixed | The dirigent case is marked as fitting both readings; 184/184 is cited instead, in the reference and in Igor's rule. Added an "unknown" row for how the alias resolves. |
 | M1 trunk notes optional vs mandatory | fixed | `run-log.md`: written by the Athanor at intake; the header no longer allows "none". |
 | M3 `[1m]` on the Athanor pin | left, needs decision | Pin unchanged, as instructed. Recorded as an "unknown" row in the spawning reference's Models table. The user decides whether to pin `claude-opus-5-5[1m]`. |
 | M4 re-check failure path | fixed | `SKILL.md` and Igor decision tree: a Critical or Important that survives the re-check goes to the user or into a new plan. |
 | M5 fork context stated as fact | fixed | `SKILL.md` and `athanor.md` now say context inheritance is assumed. |
 | M6 staging hard-coded | fixed | `athanor.md`: "Stage per project config (default: explicit paths)". |
 | M7 "tests pass" is a claim | fixed | `athanor.md` step 4: read the fix diff for loosened assertions or deleted checks before reporting green. |
 | M8 duplicate block times; Haiku line | fixed | Per-phase table no longer has time columns (times stay in the handoff notes). The Haiku line now reads as a plain observation. "Six stages" became "the stages below". |
 | Flag 4: `spire:project` template fields | left | Follow-up, as the review says. |
@@ -0,0 +1,76 @@
 # Lean Athanor — review
 **Reviewer**: Opus 5.5, model id `claude-opus-5-5` (from my system prompt). Fresh general-purpose agent dispatched by Igor; did the work myself, no subagents.
 **Date**: 2026-10-05
 **Scope**: commits `e515207`, `146a48c` on `main`, measured against [goals/lean-athanor.md](../goals/lean-athanor.md). Implementer report: [2026-10-05-22-lean-athanor-implementation.md](./2026-10-05-22-lean-athanor-implementation.md).
 ## Verdict
 **Pass with fixes.** The skill is lean, it reads as judgment rather than a checklist, and the attack step is framed correctly. The skill states the attack as adversarial-against-code first, then a reshape, in one pass, run outside the Athanor, with its risk list kept from the reviewer. Superpowers is demoted correctly and the stale guidance is gone. Three Important gaps remain, all in the model and routing rules on Igor's side: Igor's own examples break the new alias rule; nothing makes sure plan, attack and review actually run on 5.5; and one stale routing rule still hands the Athanor unplanned work.
 Counts: Critical 0 · Important 3 · Minor 8.
 ## Goal checkboxes
 | # | Criterion | Status | Evidence |
 |---|---|---|---|
 | L1 | Intent + defaults with reasons, room for judgment, no incident rules | met | `implementation/SKILL.md:8-12`, `:36-41` (each default carries its why) |
 | L2 | Short; detail in references | met | 85 lines vs 81 before; three references |
 | L3 | Harness/model traits in references; project choices from `spire:project` | met | `SKILL.md:62-66`, `:77-79`. Note: `athanor.md:55` hard-codes "Stage explicit paths" (M6) |
 | A1 | Fresh agent attacks the plan against the code, then reshapes it, in one step | met | `SKILL.md:26`; `igor/SKILL.md:95` (4b) |
 | A2 | This step pays for dropping per-task review | met | `SKILL.md:28`; `igor/SKILL.md:95` |
 | A3 | Described by intent, not by output fields | met | `SKILL.md:26-30` is prose; examples, not required fields |
 | A4 | Risk list is not the reviewer's scope | met | `SKILL.md:30`; `igor/SKILL.md:95` (6) |
 | A5 | Outside the Athanor; user sees reshaped plan | met | `SKILL.md:17`, `:22`; `igor/SKILL.md:95`; `athanor.md:51` |
 | B1 | Gate between blocks; tests once; one review, one fix, C/I re-check, stop | met | `SKILL.md:39`, `:53-54`; `igor/SKILL.md:100-101`. Re-check failure path unclear (M4) |
 | B2 | Igor-dispatched fresh reviewer, stamped id, answers flags, hunts weakened checks | met | `SKILL.md:51-52`; `igor/SKILL.md:95` |
 | B3 | Extra reviews as a reasoned choice | met | `SKILL.md:55`; `igor/SKILL.md:106` |
 | T1 | One phase per turn: intake/trunk notes → blocks → gate → tests → run log → hand back | met | `athanor.md:27-36`. Trunk notes optional elsewhere (M1) |
 | T2 | Igor resumes for fix pass / next phase, or starts fresh | met | `igor/SKILL.md:108`; `athanor.md:40`, `:68` |
 | T3 | Plan sets block/owner defaults; deviation logged | met | `athanor.md:38`; `SKILL.md:41` |
 | T4 | Athanor does not plan, attack, or self-review | met | `athanor.md:10-11`, `:51` (but see I3) |
 | T5 | Trunk and forks as an option, verified vs assumed marked, forks inherit the model | partial | Reference marks it correctly (`spawning-claude-code.md:58-61`). But `SKILL.md:47` and `athanor.md:32` state "inherits its context" as fact (M5) |
 | M1 | 5.5 default for Athanor, plan, attack, review; Athanor pinned | partial | Pin at `athanor.md:13`; defaults at `models.md:11`, `igor/SKILL.md:95`. Nothing secures 5.5 for general-purpose planner/attacker/reviewer (I2) |
 | M2 | Alias-over-pin; omit `model` for pinned agents; stamp | partial | Rule at `igor/SKILL.md:89`, `model-tiers.md:36`. Contradicted by `igor/SKILL.md:84,133,142,151` (I1); its example is confounded (M2) |
 | M3 | Model notes are dated observations, user's points kept | met | `models.md:13-43` |
 | M4 | Stale guidance removed | met | `model-tiers.md:34-37`; `igor/SKILL.md:173`; old "run tests between agents" gone |
 | C1 | Context figures are guesstimates; judgment between extremes | met | `models.md:5`, `:19`, `:49`; `SKILL.md:45` |
 | C2 | Future work: introspection / signals | met | `models.md:51` |
 | S1 | No `subagent-driven-development` preload; lean rules win | met | `athanor.md:15-18`, `:60`; `SKILL.md:84` |
 | S2 | Plan-writing swappable | met | `SKILL.md:32` |
 | J1 | Journals and run log are the record; journals are for later mining | met | `SKILL.md:73` |
 ## Findings
 ### Important
 - **I1. Igor's own adept examples break the new pin rule in the same file.** The rule says pinned agents get no `model` unless Igor deliberately overrides. Yet the delegation table and all three spawn templates pass `model: "opus"` to the 4.6[1m]-pinned adept, with no note that this is an override. An Igor that copies the templates silently overrides the pin, and may also lose the `[1m]` context. Evidence: `igor/SKILL.md:84`, `:133`, `:142`, `:151`. **Fix:** remove `model: "opus"` from the row and the three templates so they match `:89`. Whether adepts should move off 4.6 is the user's call.
 - **I2. Nothing makes sure planning, attack and review actually run on 5.5.** These roles are dispatched as general-purpose agents with the `opus` alias. Igor is pinned to `claude-opus-4-6[1m]`, and the user's own observation is that the alias follows the caller. Under that observation, a 4.6 Igor gets 4.6 reviewers, which is the dirigent "Pass" failure the goal is built around. The stamp rule only records the model; it does not enforce it, since a review stamped 4.6 still "counts". Evidence: `igor/SKILL.md:95` ("Opus 5.5 agent" with no means), `SKILL.md:51`, `agents/igor.md:9`. **Fix now:** add one sentence to Igor's model rule: for the plan, the attack and the phase review, check the stamped id; if it is not 5.5, re-dispatch or tell the user before acting on the result. **Follow-up:** pinned 5.5 `planner`/`reviewer` role agents (the redesign report and the dirigent §5.4 both propose them).
 - **I3. A stale routing rule hands the Athanor unplanned build work.** "Research + implementation combined goes to `athanor` as a single brief" bypasses the plan and the attack. It also makes the Athanor plan, which `athanor.md:51` forbids. Evidence: `igor/references/model-tiers.md:19`. **Fix:** route implementation through the cycle; the Athanor gets reshaped build plans, or non-build briefs (research, audits) only.
 ### Minor
 - **M1. Trunk notes are mandatory in one file and optional in another.** The Athanor must write them, and Igor's fresh-start path depends on them, but the run-log reference calls them optional. Evidence: `athanor.md:31`, `igor/SKILL.md:108` vs `run-log.md:61`. **Fix:** drop "(optional)".
 - **M2. The alias-over-pin example does not prove what it is cited for.** The old Athanor was pinned to `claude-opus-4-6`, so a 4.6 Athanor is equally explained by the pin, and "either way the alias, not the pin, decided" does not follow. The schema (verified) and the spacecraft 184/184 observation do support the rule. Evidence: `spawning-claude-code.md:51`, `igor/SKILL.md:89`. **Fix:** cite 184/184 as the evidence; mark the dirigent case as consistent with both the alias and the pin. This also leaves open whether I2 bites in practice, and the stamp check fixes it either way.
 - **M3. The Athanor pin's context window is unverified.** `claude-opus-5-5` carries no `[1m]`, while every other full-id pin in Spire does, and the notes assume about 600k is comfortable plus a 100k–250k trunk read. If the bare id means a smaller window, trunk and forks breaks. Evidence: `athanor.md:13`, `models.md:19`, `:49`; the question was already raised in `reports/2026-09-14-spire-skill-audit.md:39`. **Fix:** check the window and record the result as a row in the spawning reference's Models table.
 - **M4. The stop rule does not say what happens when the re-check still fails.** "Then stop and go to the next phase" reads as moving on with an open Critical. Evidence: `igor/SKILL.md:101`, `SKILL.md:54`. **Fix:** an unresolved Critical/Important after the re-check goes to the user, or into a new plan, not to the next phase.
 - **M5. A fork "inherits its context" is stated as fact, but the reference marks it assumed.** Evidence: `SKILL.md:47`, `athanor.md:32` vs `spawning-claude-code.md:59-60`. **Fix:** write "(assumed)" inline.
 - **M6. Staging is hard-coded in the Athanor although the goal lists it as a project setting.** Evidence: `athanor.md:55`. **Fix:** "stage per project config (default: explicit paths)".
 - **M7. One durable rule from the old skill was lost: a subagent's "tests pass" is a hypothesis, so read the diff.** Only the phase reviewer holds it now, while the Athanor fixes test fallout through children at phase end. Evidence: old `SKILL.md:23-33` vs `athanor.md:34`. **Fix:** add one line to step 4: check the fallout fix's diff for loosened assertions before claiming green.
 - **M8. The run-log template records each block's timing twice and carries a one-off incident as advice.** The per-phase table and every handoff note both hold block start and end. Separately, the Haiku line turns a single incident into advice. Evidence: `run-log.md:28` and `:38`; `models.md:43`. **Fix:** keep times in the notes only; reword the Haiku line as plain observation. Also trivial: "six stages" now has a 4b (`igor/SKILL.md:93`).
 ## Flagged items
 1. **Adept `model: "opus"` over the 4.6 pin.** Fix now; this is I1. Make the examples follow the rule; the adept pin itself is a separate user decision.
 2. **Igor, adept and zathras pinned to 4.6.** Split. The cheap guard (Igor checks the stamped id for plan, attack and review) is in scope now; this is I2. Re-pinning Igor, or adding pinned 5.5 role agents, is a follow-up for the user, since the goal does not set Igor's model.
 3. **"Verified" means read from the tool schema, not tested at runtime.** The labelling is acceptable; it is a follow-up for the preflight, plus one cheap edit now: the legend at `spawning-claude-code.md:7` should say "read from the tool schema text" explicitly. Two caveats to record: (a) in this reviewer's session, the schema mentions `subagent_type: "fork"`, but `fork` is not among the agent types offered, so the fork's availability is not verified, only its documented behaviour; (b) "every agent sees its exact model id" was checked only for general-purpose agents, not for plugin agents with their own bodies.
 4. **`spire:project` template lacks build-setting fields.** Follow-up. The skill reads them from `spire:project` (`SKILL.md:79`) and they fit under "Verification commands" and "Conventions" today (`igor/references/project.md:20-22`). Add explicit fields to the template and `/spire:init` when the next project adopts the lean loop.
 ## Re-check (commit 5909221)
 **Re-checker**: Opus 5.5, model id `claude-opus-5-5` (from my system prompt). Fresh agent, scoped to I1–I3 plus a Critical/Important scan of the fix diff; did the work myself, no subagents.
 - **I1 — confirmed fixed.** The adept row now reads `subagent_type: "adept"` (`model` omitted; pinned) at `igor/SKILL.md:84`, and the three spawn templates at `:133`, `:142`, `:151` no longer pass `model`. This matches the rule at `:89` and `model-tiers.md:36`. No `model: "opus"` remains for adepts anywhere in `plugins/spire`; the adept pin (`agents/adept.md:11`, `claude-opus-4-6[1m]`) now governs.
 - **I2 — confirmed fixed (the guard part in scope).** `igor/SKILL.md:89` now says to check the stamped id of the plan, the attack and the phase review before acting, and to re-dispatch or tell the user if it is not the intended model (Opus 5.5 by default). `spawning-claude-code.md:52` marks alias resolution as unknown and points to the same check. Nothing contradicts it: `implementation/SKILL.md:51,65` require the stamp, and the planner, attacker and reviewer are general-purpose agents, for which the model id in the prompt is observed (`spawning-claude-code.md:53`). Pinned 5.5 role agents stay a user follow-up, as the review flagged.
 - **I3 — confirmed fixed.** `model-tiers.md:19` now sends implementation through plan → attack → build, gives the Athanor only reshaped build plans, and allows a single brief only for non-build fan-out. This agrees with `athanor.md:8-12` and `:51`, with `model-tiers.md:12`, and with `igor/SKILL.md:85,87`.
 - **New Critical/Important in the fix diff: none.** The other touched files (`athanor.md`, `implementation/SKILL.md`, `models.md`, `run-log.md`, `spawning-claude-code.md`) only took the minor fixes, and none of them contradicts the touched Igor files. Observation, not new and not blocking: the pre-existing "Planned implementation → implementer agent" row (`igor/SKILL.md:81`, `model-tiers.md:11`) does not say the plan must already be attacked. Worth one clause the next time those tables are touched.
@@ -0,0 +1,224 @@
 # Athanor usage reports in dirigent
 Research pass over `/home/g4b/Projects/dirigent` for documents reporting on how athanor
 (the spire orchestration agent, pinned to Opus 4.6, "the oven") has actually been used:
 experience reports, retrospectives, post-mortems, journals discussing athanor runs,
 problems, costs, model behaviour, delegation issues, proposed changes. Read-only; no
 dirigent files were touched.
 Method: `grep -ril -i athanor` under `docs/workpad/` (36 hits, mostly reports/journals/
 plans), ranked by hit density and date, cross-checked against `git log --grep=athanor`
 (no commit *messages* mention athanor — the word only appears in document bodies). Also
 searched for local `.claude/` overrides of an `athanor` agent/skill file (none found by
 name).
 ## 1. Ranked list of relevant files
 **Primary report (read in full):**
 1. `/home/g4b/Projects/dirigent/docs/workpad/reports/2026-10-01-lean-process-report.md`
   (2026-10-01, with an **addendum dated 2026-10-05**) — 41 mentions of athanor. The
   definitive retrospective: compares a step-by-step baseline run against a new "lean
   process" run, both using athanor as implementation orchestrator; the 2026-10-05
   addendum is explicitly addressed "to authors of the spire/reliquary plugin" and lays
   out settled rules, delegation boundaries, and open tensions for athanor's design.
   **This is the report the user is thinking of.**
 **Important secondary reports:**
 2. `/home/g4b/Projects/dirigent/docs/workpad/reports/2026-09-23-14-stalled-agents-forensics.md`
   (2026-09-23) — 9 mentions. A post-mortem on three athanor instances (one implementation,
   two planning) that died mid-run when the session hit a monthly spend/rate limit;
   documents how far each got, what could be resumed, and a dispatcher/preflight decision
   athanor made.
 3. `/home/g4b/Projects/dirigent/docs/workpad/reports/2026-09-29-13-w1c-tasks-1-7-run.md`
   (2026-09-29) — 5 mentions. A run report for tasks executed under the (then-current)
   per-task review flow; useful contrast data point feeding into the 2026-10-01 report's
   baseline comparison.
 **Other files containing "athanor" (lower signal — mostly plans/journals that mention
 athanor only in passing, e.g. naming it as the dispatcher, or copying boilerplate from the
 skill). Listed for completeness, newest first:**
 4. `/home/g4b/Projects/dirigent/docs/workpad/journals/2026-10-05-12-continue-implementations.md`
   (2026-10-05) — source journal behind the lean-process report's addendum; records the
   12:36/12:40 correction about who dispatches blocks (Igor vs athanor).
 5. `/home/g4b/Projects/dirigent/docs/workpad/reports/2026-10-05-w3-run.md` (2026-10-05) — 1 mention.
 6. `/home/g4b/Projects/dirigent/docs/workpad/reports/2026-09-30-10-delivered-and-roadmap.md` (2026-09-30) — 1 mention.
 7. `/home/g4b/Projects/dirigent/docs/workpad/reports/2026-09-30-11-w1c-tasks-8-10-run.md` (2026-09-30) — 1 mention.
 8. `/home/g4b/Projects/dirigent/docs/workpad/reports/2026-09-29-12-w1c-capture-findings.md` (2026-09-29) — 1 mention.
 9. `/home/g4b/Projects/dirigent/docs/workpad/reports/2026-09-24-impl-run6-thoughts-y6-w2b.md` (2026-09-24) — 1 mention.
 10. `/home/g4b/Projects/dirigent/docs/workpad/reports/2026-09-23-15-impl-qw-w4.md` (2026-09-23) — 1 mention.
 11. `/home/g4b/Projects/dirigent/docs/workpad/reports/2026-09-25-roadmap-birds-eye.md` (2026-09-25) — 1 mention.
 12. `/home/g4b/Projects/dirigent/docs/workpad/plans/2026-09-23-01-planning-index-A.md`,
    `.../plans/2026-09-23-01-planning-index-B.md` (2026-09-23) — plan indices written by/for
    planning athanors (subject of report #2 above).
 13. Various journals mentioning athanor in passing (session coordination narration, not
    retrospective analysis): `2026-09-22-09-acp-session-loading-debug.md`,
    `2026-09-22-21-session-system-evaluation.md`, `2026-09-24-14-continue-work.md`,
    `2026-09-25-18-windows-smoke-continue.md`, `2026-09-16-14-session.md`,
    `2026-09-20-meta-harness-bugfixing.md`, `2026-10-01-11-bugfixing-on-main.md`,
    `2026-09-22-split-meta-ui-bugfixes.md`, `2026-09-29-13-w1c-live-acp-tasks-1-7.md`,
    `2026-09-23-14-resume-stalled-planning.md`, `2026-09-21-meta-harness-ui-split.md`,
    `2026-09-21-11-meta-ui-bugfix-round3.md`, `2026-09-18-18-meta-harness-implementation.md`,
    `2026-09-30-10-status-check.md`, `2026-09-28-15-current-branch-efforts.md`.
 14. Goal/design docs naming athanor only as the execution mechanism, not reporting on it:
    `goals/meta-harness-ui-round2.md`, `goals/meta-harness-implementation-run.md`,
    `goals/meta-harness-bugfix-and-completion.md`, `plans/2026-09-23-12-w1c-live-acp-path.md`,
    `plans/2026-09-23-00-session-system-roadmap.md`, `plans/2026-09-23-12-w6-v1-feature-backlog.md`,
    `designs/2026-09-23-w1-message-representation.md`.
 No file or commit message anywhere in the repo is literally named `athanor*`; it is never
 the filename, only content.
 ## 2. Dense summaries of the top documents
 ### 2.1 `2026-10-01-lean-process-report.md` (+ 2026-10-05 addendum) — PRIMARY
 **Core comparison.** Baseline (step-by-step, per-task review, Sonnet implementers + Opus
 review/fix) vs. "lean" (one Opus-5.5 plan → 6 blocks → compile-gate only between blocks →
 one test run → one end review → one fix pass → one re-check). Athanor ran the lean
 blocks and its own end review; Igor ran everything else.
 **Measured result.** Lean was ~35–40% faster in wall clock (3h11m vs ~5–5.7h) for similar
 first-draft size, with far less fix churn (+1,417 fix lines in 1 commit vs +3,439 in 10
 commits). The earlier "5x faster" claim told to the user was wrong — it came from a
 journal clock that drifted ~2.5x from real git timestamps.
 **Athanor's end review failed.** Quote: *"Athanor ran the blocks and the end review.
 Athanor is the spire orchestration agent ('the oven') and is pinned to Opus 4.6."*
 Athanor's internal end review returned **zero findings** ("Pass"). An independent review
 dispatched directly by Igor on verified Opus 5.5 found **6 Important + 11 Minor** findings
 in ~20 minutes, including a data-loss bug (I1, half-streamed messages dropped from the
 archive) that the handoff notes had already flagged and athanor's reviewer still missed.
 Quote: *"The review read like a confirmation of the checklist, not a search for bugs...
 Its model is unknown."* Because athanor is pinned to Opus 4.6, nobody could verify what
 model its internal `opus` alias resolved to when told to use Opus 5.5 — *"the zero-finding
 result is either a 4.6 review or a weak, checklist-bound 5.5 review. Either way, it does
 not count."*
 **Model behaviour / assignment.** The Sonnet-first-draft experiment was ended on this
 evidence: all 6 Important findings sat in complex code Sonnet drafted; Sonnet also hit
 500k–750k token contexts on long single-implementer passes. New settled rule: complex/
 hotspot blocks (state, concurrency, archive format, retention, event handling, read-path
 precedence) go to Opus 5.5; mechanical blocks (field sweeps, renames, wiring, docs) go to
 Sonnet; Haiku stays on compiles/tests/commits/summaries. Plans and all reviews are Opus
 5.5, never athanor's pinned 4.6.
 **Recommended/proposed changes (§5.2, §5.4, and Addendum A.1–A.11), aimed explicitly at
 spire/athanor's design:**
 - End review must be a **verified** Opus 5.5 role dispatched by Igor directly, outside
  athanor's pin, with the exact model id stamped in the report header — "a review without
  a stamped id does not count."
 - End review must be adversarial and must answer every "flagged for review" line in
  implementer handoff notes one by one, not just run a checklist.
 - Every plan block carries an explicit **owner model**; athanor dispatches with that model
  and must not pick or change it itself.
 - Athanor should not write implementation plans — plans come from Igor-dispatched Opus 5.5
  general-purpose (write-capable) agents, never from athanor's own Opus-4.6 default.
 - Athanor's job ends at "blocks done, tests run once, run log complete" — it should not
  run its own end review unless it can be pinned by full model id.
 - Never carry one implementer across blocks; fresh context per block, each block's handoff
  note states done/deviations/flagged-for-review/left-for-later/expected-broken
  crates/model id/start-end times from `date`.
 - **"Background grandchildren" hazard (settled 2026-09-29):** when athanor's subagents run
  in the background, their completion reports go to Igor, not athanor, and athanor stalls
  waiting — sequential steps must run in the foreground inside athanor; if athanor stalls,
  Igor must check the agent list and feed it the result manually. Quote: *"This is a
  harness behaviour athanor should be designed around."*
 - No worktrees for this project (worktree cargo targets hit 83–111 GB on an 88%-full
  `/home`); athanor and implementers must verify the branch named in the brief and stop if
  not on it, and stage explicit paths only (`git add <file>`, never `-A`), since other
  agents may commit concurrently.
 - User's own open remark (§5.4): spire needs **guard rails for pinned models** — pin role
  agents (reviewer, planner) by full model id instead of per-call aliases, forbid model
  aliases in athanor briefs, require reviewers to stamp the exact model id, and update the
  model-tiers reference. Explicitly filed as belonging to "the user or a spire session (the
  reliquary repo), not to dirigent."
 - Open tensions deliberately left unresolved for "the user or spire authors" (§A.10):
  whether a scoped mid-run hotspot review is still allowed under lean; whether fix rounds
  resume the original per-block implementer or go to one fresh Opus fixer; athanor keeps
  orchestrating blocks today only to keep the H0–H3 comparison clean, not as an endorsement
  of Opus 4.6 for orchestration — "if 4.6 also mis-handles handoff flags or model choice,
  the guard rails in §5.4 become urgent."
 **Model versions mentioned:** `claude-opus-5-5` (Opus 5.5, planner/reviewer/fixer, author
 of this report and its addendum), Opus 4.6 (athanor's pin), Sonnet (implementers, generic
 tier), Haiku (housekeeping tier). No "Fable" mention anywhere in dirigent's athanor
 material.
 ### 2.2 `2026-09-23-14-stalled-agents-forensics.md` — secondary
 Post-mortem after the whole session hit a monthly Claude spend limit (HTTP 429) in a
 3-minute window on 2026-09-23, killing six agents mid-task, three of them athanor
 instances (one implementation athanor, two planning athanors). Findings relevant to
 athanor usage:
 - Implementation athanor "QW+W4" got T1–T3 committed and reviewed, but T4's child finished
  writing code and passed its own tests, then died before the **parent athanor** could
  review, commit, or run `just check-all` — so a fully-working diff sat unreviewed/
  uncommitted in the working tree. Quote: *"the athanor died in the same window, right as
  it received the child's truncated hand-back — it never reviewed T4... and never wrote a
  report file."*
 - A dispatcher/preflight ruling by this athanor explicitly deferred a roadmap-status edit
  ("dispatcher applies the listed text edits by hand") rather than doing it inline — an
  example of athanor making its own scoping decisions mid-run.
 - Two planning athanors (A and B) each landed most of their substantive plan edits but
  left "closing loop" steps undone (a re-check that never ran; an index never updated with
  late fixes) when they were cut off — illustrating that athanor runs can leave partially-
  closed process state (ledgers, indices) that a resuming session must reconcile by hand.
 - No model-version commentary here; this report predates the Opus 4.6 pin/Opus 5.5 split
  discussed in the October reports.
 ### 2.3 `2026-09-29-13-w1c-tasks-1-7-run.md` — secondary
 A run log from the per-task review era (pre-lean), one of the baseline data points the
 2026-10-01 report later cites when reconstructing the "~5–6h baseline" figure. Only 5
 athanor mentions; it is primarily a task-by-task execution/review log rather than a
 retrospective on athanor's behaviour, so it is evidentiary input to document #1 rather
 than an independent report. Not separately summarized in depth here; see the 2026-10-01
 report's §2.2–2.3 for the extracted, corrected numbers.
 ## 3. Local overrides vs. the upstream spire plugin
 - No `.claude/agents/athanor*.md` or `.claude/skills/*athanor*` file exists in dirigent —
  i.e., dirigent has **not** forked/overridden athanor's agent definition locally; it
  still runs the upstream spire athanor.
 - Dirigent **does** carry its own pre-spire orchestrator agent at
  `/home/g4b/Projects/dirigent/.claude/skills/orchestrator/SKILL.md` ("Plan Execution
  Orchestrator" / "dirigate of implementation") plus
  `/home/g4b/Projects/dirigent/.claude/agents/rust-task-implementer.md` and
  `/home/g4b/Projects/dirigent/.claude/agents/task-writer.md`. This looks like an earlier,
  parallel orchestration scheme (one-implementer-at-a-time, phase summaries, task
  checklists) that predates/coexists with spire's athanor rather than a modification of
  athanor itself — worth noting as a potential source of the "sequential dispatch,
  one-at-a-time" rule the lean report's addendum (A.8) says is "settled 2026-09-19."
 - Several **project-level behavioural overrides of spire/Igor defaults** are recorded as
  settled rules in the 2026-10-05 addendum (§A.6, §A.8, §A.10) rather than as code changes:
  - No worktrees for code runs, even though "the Igor skill suggests them for code runs;
    this project overrides that" (§A.6).
  - "Don't start work from topic alone" relaxed for read-only research that itself answers
    the session's stated topic (§A.8).
  - These are documented as standing per-project exceptions Igor applies, not as edits to
    the spire plugin's shipped skill files — the addendum explicitly frames this as
    something "skills should make... per-project settings rather than fixed rules" (§A.10
    item 10), i.e. a gap to close upstream in spire, not something dirigent has patched
    locally in plugin files.
 - The dirigent project memory directory `~/.claude/projects/-home-g4b-Projects-dirigent/memory/`
  (outside the dirigent git repo, not inspected directly here but cited extensively by the
  addendum) holds the actual settled/experiment rules (`feedback_review_by_risk`,
  `feedback_sonnet_first_draft`, `feedback_planner_agents`, etc.) that function as de facto
  local overrides of spire defaults for this project.
 ## Summary
 Primary report: `docs/workpad/reports/2026-10-01-lean-process-report.md` (with its
 2026-10-05 addendum) in `/home/g4b/Projects/dirigent`, written for "authors of the spire/
 reliquary plugin." It shows athanor's internal end review (pinned Opus 4.6) missed 6
 Important findings — including an archive data-loss bug — that an independently-dispatched
 Opus 5.5 review caught, and it proposes concrete athanor design changes: model-id guard
 rails, reviews/plans kept outside athanor's pin, per-block owner models, and foreground-
 only sequential subagent dispatch to avoid orchestrator stalls. A secondary post-mortem,
 `docs/workpad/reports/2026-09-23-14-stalled-agents-forensics.md`, documents three athanor
 instances dying mid-run from a rate limit and the unreviewed/unclosed work they left
 behind. Full findings, quotes, and a complete ranked file list are in the output document.
@@ -0,0 +1,76 @@
 # Athanor usage in spacecraft — survey of experience reports
 **Date**: 2026-10-05
 **Scope**: read-only survey of `/home/g4b/Projects/spacecraft` docs/workpad and `.claude/` for documents reporting on Athanor orchestration runs (problems, cost, model behaviour, delegation issues, proposed changes).
 ## 0. Critical disambiguation — spacecraft's "athanor" is not Spire's `athanor` agent
 Spacecraft does **not** use Spire's `athanor.md` orchestration agent as such. Its docs use "athanor" purely as an informal nickname for runs of the **superpowers** plugin's `dispatching-orchestrator` agent (`.claude/agents/dispatching-orchestrator.md`, spawned with `model: "opus"`). This is stated explicitly:
 > "The spire plugin (`athanor.md`) is installed only for `/home/g4b/Projects/dirigent`, so it is not active here. Here, 'athanor' just means our `dispatching-orchestrator`."
 > — `docs/workpad/reports/2026-09-29-13-orchestration-overhead-attribution.md:34`
 As of today, spacecraft's `.claude/settings.json` lists `"spire@reliquary": true` in `enabledPlugins`, and the plugin cache (`~/.claude/plugins/cache/reliquary/spire/0.1.1/agents/athanor.md`) exists and was last updated 2026-10-05. However, `~/.claude/plugins/installed_plugins.json` still shows spire's project-scope install pointed at `/home/g4b/Projects/dirigent`, and spacecraft's own `.claude/agents/` directory contains **no** `athanor.md` override — only `dispatching-orchestrator.md`. The most recent journal (2026-10-05) still refers to dispatches as "dispatching-orchestrator (opus, bg)", not as the Spire agent type. So: **everything below is about the superpowers `dispatching-orchestrator`, colloquially "athanor," not about Spire's athanor agent.** There is no evidence spacecraft has ever run Spire's actual athanor agent, and therefore **no local overrides of the Spire athanor agent or its skills exist in spacecraft.**
 ## 1. Ranked list of relevant files
 1. **`docs/workpad/reports/2026-09-29-13-orchestration-overhead-attribution.md`** (2026-09-29) — **primary report.** Detailed attribution of orchestration overhead across an 11-element pipeline (review loops, model tiers, mutation checks, journals, layering), with ledger evidence and ranked cost-cutting recommendations.
 2. **`docs/workpad/reports/2026-09-27-13-strategy-mvp-retrospective/report.md`** (2026-09-27) — **primary report.** Full retrospective on why Round 1 (~80 tasks, 7 athanor/orchestrator instances) took ~60 hours; quantifies cost per seat, per-model, and gives concrete recommendations.
 3. **`docs/workpad/reports/2026-09-29-23-strategy-igor-handoff-b5.md`** (2026-09-29) — handoff doc summarizing the switch to a "lean review process" after B3 (halved time per task: ~75min → ~40min) and listing recurring problem zones to watch (performance regressions, weakened checks, untestable tests, stalls).
 4. **`docs/workpad/brainstorm/the_assistants_mindset.md`** (section "Lean pipelines: don't stack quality gates", 2026-09-29) — distilled lessons/principles for running athanors, plus meta-lessons about the coordinating assistant (Igor) over-extrapolating user feedback.
 5. **`docs/workpad/journals/2026-09-28-20-strategy-g1b-continue.md`** — session journal recording concrete stall incidents ("B3 athanor stalled twice … nudged with results") that motivated the foreground-dispatch rule.
 6. **`docs/workpad/journals/2026-10-05-00-strategy-mvp-continue.md`** (most recent, 2026-10-05) — latest status: G1-C dispatched with per-phase review (even leaner than B5's per-task-group review), then paused mid-run by the user; notes an orchestrator resumed via SendMessage instead of fresh agents (flagged as a mistake, corrected to "fresh foreground agents").
 7. Supporting/secondary: `docs/workpad/reports/2026-09-26-22-strategy-mvp-r1-delivery-report.md`, the seven `docs/workpad/plans/strategy-mvp/2026-09-24-r1-athanor-handoff*.md` handoff files (raw per-slice handoffs, less synthesized), and the chain of delivery journals under `docs/workpad/journals/` (g1b-b3/b4/b5/b6, g1c) which record ledger-level detail behind reports #1–#2.
 ## 2. Dense summaries of top documents
 ### #1 — Orchestration overhead attribution (2026-09-29)
 Scope: the "assistant → dispatching-orchestrator ('athanor') → leaf agents" pipeline across G1-B slices B1–B3.
 - **Superpowers supplies only the skeleton** (per-task review loop, ledger, 5-round fix cap, ruling format). "Most of the weight is ours": Opus 5.5 on every review/re-review/fix round, a fresh fixer every fix round, mutation checks in fresh `CARGO_TARGET_DIR`s, minors carried forward, a final review per slice (not per plan), three prose records per slice, oracle/golden ceremony, and a third coordination layer (assistant above orchestrator).
 - **First reviews earned their cost**: 12/15 found Important or Critical issues; the only clean ones were Sonnet run-and-record tasks. Mutation checks produced 6–9 of the Important findings — "the most productive single check in the pipeline."
 - **Re-reviews and deferred minors did not pay off**: 11/13 re-reviews only confirmed fixes; of 16 deferred minors none were ultimately must-fix (5 fixed incidentally, 9 still open, 1 promoted to its own task).
 - **Cost of the third layer (E5)**: "Athanor went idle: its background children notify the root session [not it]" (`journals/2026-09-24-10-strategy-game-mvp.md:33`); "B3 athanor stalled twice … Nudged with results" (`journals/2026-09-28-20-strategy-g1b-continue.md:25,28,38`). Each stall cost a user-visible nudge cycle.
 - **Ranked cuts** (all achievable without editing the superpowers plugin, via CLAUDE.local.md / plan execution model / orchestrator-written templates / memories): (1) skip per-task review for run-and-record/gate/metric tasks, (2) re-reviews on Sonnet not Opus 5.5, (3) minors: ledger-only, never fixed/carried, (4) cheaper/narrower mutation runs, (5) batching becomes default, (6) one final review per plan not per slice, (7) drop the delivery journal, (8) collapse layers (run orchestrator as top-level session), (9) resume drafter for fix rounds when drafter was already Opus 5.5, (10) relax re-bless policy.
 - Model mentions: "Opus 5.5" used pervasively for review/fix/plan; "Opus 4.6" for drafts; Sonnet for run-and-record; no mention of Fable or Opus 5.x beyond 5.5 in this doc.
 ### #2 — Strategy MVP retrospective (2026-09-27)
 Scope: why R1 (~80 tasks, 7 orchestrator ("athanor") instances, handoffs 1–7) took ~60 wall-clock hours.
 - Three multipliers identified: **(1) scope** — Opus 5.5 plans were ~11× larger than any earlier plan, driving 77k lines of Rust instead of a plausible 10–20k for a "4.6 just build it" MVP; **(2) per-task pipeline cost doubled mid-run** — active time per task rose from ~10 min (plans A/B) to ~40 min (D2/E1) to ~70 min (E2), driven by "a mandatory fresh Opus 5.5 fixer on every task" whose fixer seat "often cost more than the draft"; **(3) serial execution with long tails** — only 2.7 of 45.8 delivery-session hours had two workers active simultaneously; one unbudgeted balance agent ran 7.1h; one blocking `AskUserQuestion` waited 5.9h overnight.
 - **Housekeeping bug noted**: "the `opus46-*` agent names and the `dispatching-orchestrator` description still say 'pinned to 4.6'. In practice, spawning them with `model: 'opus'` overrides the pin (the alias resolved to 5.5 in 184 of 184 spawns since 2026-09-23)." — i.e., agents believed to run Opus 4.6 were actually all running Opus 5.5; naming is misleading in transcripts/journals.
 - Model-to-seat table: orchestrators ("7 athanors") = Opus 5.5; design/plans = Opus 5.5; drafts (80) = Opus 4.6 (intended); fix rounds = Opus 5.5 (intended); reviews mostly 5.5, some Sonnet 5, **Fable 5.1 used for two design reviews** (the one Fable mention found in this survey).
 - **Recommendations**: give the 5.5 planner a scope budget (cap plan size, e.g. ≤60KB/file); plan coarser (contracts/invariants per phase, not signatures per task); right-size the review loop (cheap review per task, 5.5-with-mutation only per plan file or hotspot; minors batched not upgraded; fixes go to the resumed drafter, fresh 5.5 fixer only for Criticals); budget judgment tasks by count; never block overnight (default + timeout, or park and continue); allow limited parallelism across non-overlapping crates; tie scope strictly to the stated goal bar ("working machinery, not perfect gameplay").
 - Proposes a controlled lean-vs-current-policy experiment (§6) measuring defects-remaining-per-hour rather than trusting the process's own review counts.
 ### #3 — Igor handoff B5 (2026-09-29)
 - Confirms the lean process adopted mid-B3 "halved the time per task (about 75 min → about 40 min) and kept review quality."
 - Lean rules: one Opus 5.5 review per hotspot/design task (combined review for groups of small tasks); run-and-record steps get no review; re-review only for Critical/Important, by a fresh Sonnet; fix rounds resume the implementer **within one task only** — "Never carry an implementer across tasks. In B3 it drove one implementer to about 960k tokens"; minors fixed or dropped same round, no batch/final-slice review; dispatch sequential steps in foreground, no file watchers/Monitor tasks (background grandchildren notify the user/Igor, not the athanor).
 - **Problem zones to watch** (recurring across slices): (1) performance trending wrong way but non-gating, must be recorded as explicit finding with profiling; (2) "the reflex to weaken a check when it fails" happened three times (p1 oracle in B1, R15 in B3, R26 in B4) — each caught and reversed, rule: no check weakened silently, any report-only downgrade needs an explicit ruling; (3) tests that cannot fail recur (Sonnet-authored, and two B4 implementers skipped RED capture) — mutation checks are the backstop; (4) design text lagging behind code via accretion; (5) notification routing — B4 ran with zero stalls once foreground dispatch was enforced.
 ### #4 — Assistant's mindset: "Lean pipelines: don't stack quality gates" (2026-09-29)
 - Core lesson: "Every review layer re-reads the same code … One strong review sized to the risk beats three small ones." The prior additions (mutation checks everywhere, batch reviews on top of per-task reviews, a final whole-slice review, minor carry-lists, briefs restating the ruleset) "cost more time and tokens than they returned."
 - Routing guidance: "Opus for mechanical and design-heavy work. Sonnet for run-and-record and checklist work: it is clean there, but it wrote tests that could not fail and could not finish an open-ended performance task. Haiku for runs and appliers, with its self-reports treated as claims to verify (it has reported 'no deviations' alongside misplaced edits)."
 - Meta-lessons about Igor (the coordinating assistant) itself: don't over-extrapolate a single user remark into multiple new rules; when corrected, don't overcorrect in the opposite direction either — engage with what the remark actually implies; change rules at a clean cut (soft-retire the running athanor with a checkpoint, start fresh on new rules) rather than patching a live run.
 ### #5 — Latest journal, 2026-10-05 (strategy-mvp-continue)
 - G1-C dispatched with an even leaner regime: "review once per phase, not per task; more code first, one fix run later" (explicit user instruction, folded into memory `feedback-lean-review-process`).
 - Notable operational event: "G1-C interim hand-back (orchestrator resumed its C.1 implementer via SendMessage → bg → yielded)... Resumed the orchestrator for C.2+; told it to use fresh foreground agents instead of SendMessage resumes" — i.e., a SendMessage/background-resume pattern was tried and explicitly walked back in favor of fresh foreground agents, consistent with the stall/notification problems in reports #1 and #3.
 - Run was then paused mid-slice by direct user request (not a failure): C.1 done and pushed, C.5 done locally unpushed, C.6 left as uncommitted WIP in the worktree.
 ## 3. Local overrides of athanor/Spire agent or skills
 None found. Specifically:
 - No `athanor.md` exists anywhere under spacecraft's `.claude/` (checked `.claude/agents/`, worktree copies).
 - The only orchestrator agent file present is `.claude/agents/dispatching-orchestrator.md` (from the **superpowers** plugin's convention, not Spire), preloading `superpowers:subagent-driven-development`.
 - Spire (`spire@reliquary`) appears enabled in spacecraft's `.claude/settings.json`, but the installed-plugin record still scopes it to `/home/g4b/Projects/dirigent`, and nothing in spacecraft's docs/workpad or `.claude/skills` references Spire's athanor agent or its skills directly.
 - The steering/override mechanisms spacecraft actually uses for "athanor" behavior are, per report #1: `CLAUDE.local.md`, the plan's "Execution model" section, orchestrator-written templates (`review-common.md`, `implementer-contract.md`), project memories (e.g. `prefer-opus46-for-detail-work`, `feedback-lean-review-process`, `feedback-count-based-agent-budgets`, `one-orchestrator-at-a-time`), and `.claude/skills/assistant/SKILL.md` — none of which are Spire files.
 ## Bottom line
 There is substantial, high-quality material (two deep quantitative reports plus several handoffs/journals), but it is all about the **superpowers `dispatching-orchestrator`** informally nicknamed "athanor" in spacecraft's own vocabulary — not about Spire's actual `athanor` agent, which spacecraft has not been shown to run or override.