📝 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/research/2026-10-05-21-athanor-usage-dirigent.md

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