📝 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.
This commit is contained in:
@@ -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.
|
||||
Reference in New Issue
Block a user