reliquary/docs/workpad/goals/lean-athanor.md

Goal: Lean implementation — implementation skill and Athanor for Opus 5.5

Set: 2026-10-05, Igor session 2026-10-05-21-athanor Evidence: dirigent survey, spacecraft survey, redesign report (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.