dirigence/reliquary
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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:
g4borg
2026-10-05 22:21:55 +02:00
parent f40cbf5a2a
commit b0b315136e
7 changed files with 794 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/workpad/reports/2026-10-05-21-implementation-skill-redesign.md
+202
View File
@@ -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?