📝 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.

docs/workpad/goals/lean-athanor.md

@@ -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.