📝 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,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?
|
||||
@@ -0,0 +1,103 @@
|
||||
# Lean Athanor — implementation report
|
||||
|
||||
**Date**: 2026-10-05
|
||||
**Author**: Opus 5.5, model id `claude-opus-5-5` (from my system prompt). I ran as a general-purpose subagent dispatched by Igor, and did the work myself without dispatching agents.
|
||||
**Goal**: [lean-athanor](../goals/lean-athanor.md)
|
||||
**Session journal**: [2026-10-05-21-athanor](../journals/2026-10-05-21-athanor.md)
|
||||
**Commits** (on `main`, not pushed): `e515207` 🤖 Rewrite implementation skill and Athanor for lean building; `146a48c` 🤖 Align Igor with the lean build cycle.
|
||||
|
||||
## Files changed
|
||||
|
||||
| File | Change |
|
||||
|---|---|
|
||||
| `plugins/spire/skills/implementation/SKILL.md` | Rewritten as the lean loop: intent, defaults and reasons. 85 lines (was 81). |
|
||||
| `plugins/spire/skills/implementation/references/spawning-claude-code.md` | New. Harness rules of thumb, plus claim tables marked verified / observed / assumed / unknown, with dates. Absorbs Igor's harness notes. |
|
||||
| `plugins/spire/skills/implementation/references/models.md` | New. Model observations per model, with dates and sources. Context figures labelled as guesstimates. Token introspection listed as future work. |
|
||||
| `plugins/spire/skills/implementation/references/run-log.md` | New. Run-log header, per-phase table, handoff-note template, phase-close block, trunk notes. |
|
||||
| `plugins/spire/agents/athanor.md` | Build furnace. Pinned to `claude-opus-5-5`. Preloads only project, workpad and implementation. Superpowers listed as tools. Keepers kept. Non-build briefs allowed. |
|
||||
| `plugins/spire/skills/igor/SKILL.md` | Targeted edits: Athanor table row and paragraph, the model rule, Development Cycle (4b attack, 5 build, 6 phase review, decision tree with the stop rule), Athanor queuing (resume or start fresh), User conventions, and the harness-notes pointer. Voice section not touched. |
|
||||
| `plugins/spire/skills/igor/references/model-tiers.md` | Athanor row updated. The stale 4.6 / "Opus 5 hallucinates" rule is gone. Model rules now cover alias-over-pin and point to `models.md`. |
|
||||
| `plugins/spire/skills/igor/references/harness-notes.md` | Now a short pointer with a 4-line summary for Igor. |
|
||||
| `plugins/spire/README.md` | Rows for `implementation` and `athanor` updated. |
|
||||
|
||||
Checked and left alone: `agents/igor.md`, `plugins/spire/CLAUDE.md` and both `plugin.json` files. None of them contradicts the athanor pin, the superpowers preload or per-task review. Following Igor's mid-task instruction, I did not bump the version.
|
||||
|
||||
## Goal checkboxes
|
||||
|
||||
**The skill is lean**
|
||||
- Intent and defaults with reasons, room for judgment, no single incidents as rules → `implementation/SKILL.md` throughout. Each section gives a default and a "why". Incident evidence sits only in `references/models.md` and `spawning-claude-code.md`, with sources.
|
||||
- Short → 85 lines, against 81 before. Detail lives in the three references.
|
||||
- Harness mechanics and model traits in references; project choices from `spire:project` → SKILL "Spawning and models" points to the references. SKILL "Project settings" lists worktrees, branch, staging, gate/test commands, owner-model defaults, standing constraints and host rules as read from `spire:project`, with the brief taking precedence.
|
||||
|
||||
**Attacking the plan**
|
||||
- Explicit step after planning: fresh agent, adversarial against the code, then reshape, one step → SKILL "Attack the plan", paragraph 1. Igor's Development Cycle stage (4b).
|
||||
- It pays for dropping per-task review → SKILL "Attack the plan", paragraph 2; Igor (4b) "It is what pays for dropping per-task review."
|
||||
- Intent, not a checklist of output fields → SKILL prose. No required fields.
|
||||
- Risk list is not the phase reviewer's scope → SKILL "Attack the plan", paragraph 3; Igor stage (6).
|
||||
- Outside the Athanor, user sees the reshaped plan → SKILL cycle diagram and "Under Igor, Igor dispatches the plan, the attack and every phase review"; Igor (4b) "Show the user the build plan and its open decisions before the door closes"; athanor "Keepers": it does not plan or attack.
|
||||
|
||||
**Lean build loop**
|
||||
- Gate between blocks; at phase end tests once, one review, one fix pass, re-check only Critical/Important, stop; minors fixed or logged → SKILL "Building a phase" and "Phase review, fix, stop"; Igor decision tree items 1–2.
|
||||
- Phase review dispatched by Igor, fresh, model id stamped, answers every flag, hunts weakened checks and tests that cannot fail → SKILL "Phase review, fix, stop"; Igor stage (6).
|
||||
- Extra reviews possible as a reasoned choice → SKILL "Attack the plan", paragraph 3, and the last bullet of "Phase review"; Igor "long loops and extra reviews … need a stated reason".
|
||||
|
||||
**Athanor is a build furnace**
|
||||
- One phase per turn: intake (trunk and trunk notes), foreground blocks, gate, tests once, run log, hand back → `athanor.md` "One phase per turn", steps 1–6; template in `run-log.md`.
|
||||
- Igor resumes for the fix pass and the next phase, or starts fresh from the run log and trunk notes → Igor "Athanor queuing"; `athanor.md` "When Igor resumes you…"; the athanor deliverable reports whether it has room left.
|
||||
- Plan sets block size and owner defaults; Athanor may deviate with a logged reason → `athanor.md` paragraph after the steps; SKILL "Deviate with a reason".
|
||||
- Does not plan, attack plans, or review its own output → `athanor.md` frontmatter description and the first keeper.
|
||||
- Trunk and forks as an option, verified vs. assumed marked, forks inherit the model → SKILL "Context: fresh, fork, or keep", paragraph 2; `athanor.md` step 2; `spawning-claude-code.md` "Fork" table (inherits model: verified; copies the caller and starts at the caller's token count: assumed; nested forks and foreground return: unknown).
|
||||
|
||||
**Models**
|
||||
- Opus 5.5 is the default for Athanor, planning, attack and review; Athanor pinned → `athanor.md` `model: claude-opus-5-5`; `models.md` "Defaults"; Igor stages (4), (4b), (6); `model-tiers.md` last rule.
|
||||
- Alias-over-pin; omit `model` for pinned agents unless deliberately overriding; stamp → Igor "Model must be explicit — and deliberate"; `model-tiers.md` rules; `spawning-claude-code.md` "Models" table.
|
||||
- Model notes are observations, not law, with the user's points → `models.md` (5.5: catches more, bold, replaces small reviews especially in Rust, holy-word / 100% reversal; 4.6: fast, capable, better at intent, "understanding the human" interpreter; Fable better still; Sonnet/Haiku neutral, and the Sonnet experiment's defects are attributed largely to the plan).
|
||||
- Stale guidance removed → `model-tiers.md` (4.6 rule gone); Igor User conventions ("review between tasks" gone); old SKILL "Run tests between agents" gone. `models.md` records the withdrawal with its date.
|
||||
|
||||
**Context sizes are guesstimates**
|
||||
- Figures labelled as guesstimates; judgment between the two extremes → `models.md` intro and the "Context and block size" section; SKILL "Context: fresh, fork, or keep", paragraph 1.
|
||||
- Future work: introspection and signals → `models.md`, the last paragraph.
|
||||
|
||||
**Superpowers is a toolbox**
|
||||
- `subagent-driven-development` no longer preloaded; other skills remain tools; lean rules win → `athanor.md` frontmatter (no superpowers) and "Tools, not the loop"; SKILL "Composition".
|
||||
- Plan-writing swappable → SKILL "Attack the plan", last paragraph.
|
||||
|
||||
**Journals stay central**
|
||||
- Journals and the run log are the record; journals are raw material for later mining (future work) → SKILL "Writing things down"; `run-log.md` intro.
|
||||
|
||||
## Deviations from the goal or brief
|
||||
|
||||
- **No version bump.** The brief asked for one; Igor withdrew that mid-task. Both `plugin.json` files are untouched.
|
||||
- **Igor's Athanor paragraph and delegation-table row changed.** These were not on the list of targeted edits. They said "it decomposes the work itself" and did not mention the pin, which contradicts the build-furnace role and the model rule. I changed only those two lines.
|
||||
- **Igor's harness-notes pointer rule changed** to name the new reference. `harness-notes.md` is kept as a short pointer, so both paths work.
|
||||
- **Small jobs without the Athanor.** The redesign's "skip the athanor for one or two blocks" is covered by the SKILL's "If one agent can do the whole change in one go, do it inline". I added no separate rule for it.
|
||||
|
||||
## Flagged for the reviewer
|
||||
|
||||
1. **Adept dispatch still passes `model: "opus"`.** `adept.md` is pinned to `claude-opus-4-6[1m]`, and Igor's adept spawn examples and table row pass `opus`. Under the new rule this counts as a deliberate override, so the adept gets whatever `opus` resolves to, not 4.6. I deliberately did not name adept in the rule's examples, and I left the adept lines alone because they are out of scope. Decide whether adepts should drop the alias or keep the override.
|
||||
2. **Igor, adept and zathras are pinned to `claude-opus-4-6[1m]`.** The goal sets 5.5 as the default for the Athanor, planning, attack and review, not for Igor. I left these pins alone. Combined with the alias rule, an Igor on 4.6 that passes `opus` to a general-purpose agent may get 4.6 (the user's observation). For planner, attack and review dispatches that should be 5.5, Igor may need a pinned role agent, or Igor itself on 5.5. I did not add new role agents (out of scope).
|
||||
3. **How the alias resolves.** The two observations conflict on the surface. Spacecraft saw `opus` resolve to 5.5 in 184 of 184 cases, probably under a 5.5 caller. The user saw a 4.6 Igor produce a 4.6 Athanor. I recorded both, marked the mechanism as assumed, and wrote the rule so it holds either way: the alias, not the pin, decides.
|
||||
4. **"Verified" claims rest on the tool schema** visible to me on 2026-10-05, not on executed tests. Fork behaviour beyond "inherits the model" is assumed or unknown. The trunk-and-forks option is described as such, and the preflight is still pending (out of scope).
|
||||
5. **The `spire:project` template** (`igor/references/project.md`, `/spire:init`) has no dedicated fields for the build settings the skill now reads: worktrees, gate commands, owner-model defaults, standing constraints. They fit under "Verification commands" and "Conventions" today. A follow-up could add explicit fields. I left it alone because it was not in scope.
|
||||
6. **The Haiku note in `models.md`** ("reported 'no deviations' alongside misplaced edits") is single-incident evidence. It sits in a reference with its source, which the brief allows, but it is the least neutral line in the Sonnet/Haiku section.
|
||||
7. **Igor decision tree item 2** sends Critical/Important findings to one fix pass by resuming the Athanor. The goal does not settle who fixes (a fresh fixer or the Athanor). The SKILL leaves it open, and Igor's text defaults to the Athanor because the goal says "Igor resumes the Athanor … for the fix pass".
|
||||
|
||||
## Fix pass
|
||||
|
||||
**Author**: `claude-opus-5-5`. **Commit**: `5909221` 🤖 Apply lean Athanor review fixes. Review: [2026-10-05-22-lean-athanor-review](./2026-10-05-22-lean-athanor-review.md).
|
||||
|
||||
| Finding | Status | Where / reason |
|
||||
|---|---|---|
|
||||
| I1 adept `model: "opus"` over the pin | fixed | `igor/SKILL.md`: the table row and the three spawn templates no longer pass `model`. No agent pins changed. |
|
||||
| I2 nothing secures 5.5 for plan, attack and review | fixed (guard only) | `igor/SKILL.md` model rule: Igor checks the stamped id of the plan, attack and phase review, and re-dispatches or tells the user if it is not the intended model. Pinned 5.5 role agents remain a follow-up. |
|
||||
| I3 research + implementation go to the Athanor as one brief | fixed | `model-tiers.md`: implementation goes plan → attack → build; the Athanor gets only build plans or non-build briefs. |
|
||||
| Legend: "verified" means read from the schema | fixed | `spawning-claude-code.md` legend. Fork availability is a separate row, marked unverified. The model-id row is now "observed" for general-purpose agents only. |
|
||||
| M2 confounded alias-over-pin evidence | fixed | The dirigent case is marked as fitting both readings; 184/184 is cited instead, in the reference and in Igor's rule. Added an "unknown" row for how the alias resolves. |
|
||||
| M1 trunk notes optional vs mandatory | fixed | `run-log.md`: written by the Athanor at intake; the header no longer allows "none". |
|
||||
| M3 `[1m]` on the Athanor pin | left, needs decision | Pin unchanged, as instructed. Recorded as an "unknown" row in the spawning reference's Models table. The user decides whether to pin `claude-opus-5-5[1m]`. |
|
||||
| M4 re-check failure path | fixed | `SKILL.md` and Igor decision tree: a Critical or Important that survives the re-check goes to the user or into a new plan. |
|
||||
| M5 fork context stated as fact | fixed | `SKILL.md` and `athanor.md` now say context inheritance is assumed. |
|
||||
| M6 staging hard-coded | fixed | `athanor.md`: "Stage per project config (default: explicit paths)". |
|
||||
| M7 "tests pass" is a claim | fixed | `athanor.md` step 4: read the fix diff for loosened assertions or deleted checks before reporting green. |
|
||||
| M8 duplicate block times; Haiku line | fixed | Per-phase table no longer has time columns (times stay in the handoff notes). The Haiku line now reads as a plain observation. "Six stages" became "the stages below". |
|
||||
| Flag 4: `spire:project` template fields | left | Follow-up, as the review says. |
|
||||
@@ -0,0 +1,76 @@
|
||||
# Lean Athanor — review
|
||||
|
||||
**Reviewer**: Opus 5.5, model id `claude-opus-5-5` (from my system prompt). Fresh general-purpose agent dispatched by Igor; did the work myself, no subagents.
|
||||
**Date**: 2026-10-05
|
||||
**Scope**: commits `e515207`, `146a48c` on `main`, measured against [goals/lean-athanor.md](../goals/lean-athanor.md). Implementer report: [2026-10-05-22-lean-athanor-implementation.md](./2026-10-05-22-lean-athanor-implementation.md).
|
||||
|
||||
## Verdict
|
||||
|
||||
**Pass with fixes.** The skill is lean, it reads as judgment rather than a checklist, and the attack step is framed correctly. The skill states the attack as adversarial-against-code first, then a reshape, in one pass, run outside the Athanor, with its risk list kept from the reviewer. Superpowers is demoted correctly and the stale guidance is gone. Three Important gaps remain, all in the model and routing rules on Igor's side: Igor's own examples break the new alias rule; nothing makes sure plan, attack and review actually run on 5.5; and one stale routing rule still hands the Athanor unplanned work.
|
||||
|
||||
Counts: Critical 0 · Important 3 · Minor 8.
|
||||
|
||||
## Goal checkboxes
|
||||
|
||||
| # | Criterion | Status | Evidence |
|
||||
|---|---|---|---|
|
||||
| L1 | Intent + defaults with reasons, room for judgment, no incident rules | met | `implementation/SKILL.md:8-12`, `:36-41` (each default carries its why) |
|
||||
| L2 | Short; detail in references | met | 85 lines vs 81 before; three references |
|
||||
| L3 | Harness/model traits in references; project choices from `spire:project` | met | `SKILL.md:62-66`, `:77-79`. Note: `athanor.md:55` hard-codes "Stage explicit paths" (M6) |
|
||||
| A1 | Fresh agent attacks the plan against the code, then reshapes it, in one step | met | `SKILL.md:26`; `igor/SKILL.md:95` (4b) |
|
||||
| A2 | This step pays for dropping per-task review | met | `SKILL.md:28`; `igor/SKILL.md:95` |
|
||||
| A3 | Described by intent, not by output fields | met | `SKILL.md:26-30` is prose; examples, not required fields |
|
||||
| A4 | Risk list is not the reviewer's scope | met | `SKILL.md:30`; `igor/SKILL.md:95` (6) |
|
||||
| A5 | Outside the Athanor; user sees reshaped plan | met | `SKILL.md:17`, `:22`; `igor/SKILL.md:95`; `athanor.md:51` |
|
||||
| B1 | Gate between blocks; tests once; one review, one fix, C/I re-check, stop | met | `SKILL.md:39`, `:53-54`; `igor/SKILL.md:100-101`. Re-check failure path unclear (M4) |
|
||||
| B2 | Igor-dispatched fresh reviewer, stamped id, answers flags, hunts weakened checks | met | `SKILL.md:51-52`; `igor/SKILL.md:95` |
|
||||
| B3 | Extra reviews as a reasoned choice | met | `SKILL.md:55`; `igor/SKILL.md:106` |
|
||||
| T1 | One phase per turn: intake/trunk notes → blocks → gate → tests → run log → hand back | met | `athanor.md:27-36`. Trunk notes optional elsewhere (M1) |
|
||||
| T2 | Igor resumes for fix pass / next phase, or starts fresh | met | `igor/SKILL.md:108`; `athanor.md:40`, `:68` |
|
||||
| T3 | Plan sets block/owner defaults; deviation logged | met | `athanor.md:38`; `SKILL.md:41` |
|
||||
| T4 | Athanor does not plan, attack, or self-review | met | `athanor.md:10-11`, `:51` (but see I3) |
|
||||
| T5 | Trunk and forks as an option, verified vs assumed marked, forks inherit the model | partial | Reference marks it correctly (`spawning-claude-code.md:58-61`). But `SKILL.md:47` and `athanor.md:32` state "inherits its context" as fact (M5) |
|
||||
| M1 | 5.5 default for Athanor, plan, attack, review; Athanor pinned | partial | Pin at `athanor.md:13`; defaults at `models.md:11`, `igor/SKILL.md:95`. Nothing secures 5.5 for general-purpose planner/attacker/reviewer (I2) |
|
||||
| M2 | Alias-over-pin; omit `model` for pinned agents; stamp | partial | Rule at `igor/SKILL.md:89`, `model-tiers.md:36`. Contradicted by `igor/SKILL.md:84,133,142,151` (I1); its example is confounded (M2) |
|
||||
| M3 | Model notes are dated observations, user's points kept | met | `models.md:13-43` |
|
||||
| M4 | Stale guidance removed | met | `model-tiers.md:34-37`; `igor/SKILL.md:173`; old "run tests between agents" gone |
|
||||
| C1 | Context figures are guesstimates; judgment between extremes | met | `models.md:5`, `:19`, `:49`; `SKILL.md:45` |
|
||||
| C2 | Future work: introspection / signals | met | `models.md:51` |
|
||||
| S1 | No `subagent-driven-development` preload; lean rules win | met | `athanor.md:15-18`, `:60`; `SKILL.md:84` |
|
||||
| S2 | Plan-writing swappable | met | `SKILL.md:32` |
|
||||
| J1 | Journals and run log are the record; journals are for later mining | met | `SKILL.md:73` |
|
||||
|
||||
## Findings
|
||||
|
||||
### Important
|
||||
|
||||
- **I1. Igor's own adept examples break the new pin rule in the same file.** The rule says pinned agents get no `model` unless Igor deliberately overrides. Yet the delegation table and all three spawn templates pass `model: "opus"` to the 4.6[1m]-pinned adept, with no note that this is an override. An Igor that copies the templates silently overrides the pin, and may also lose the `[1m]` context. Evidence: `igor/SKILL.md:84`, `:133`, `:142`, `:151`. **Fix:** remove `model: "opus"` from the row and the three templates so they match `:89`. Whether adepts should move off 4.6 is the user's call.
|
||||
- **I2. Nothing makes sure planning, attack and review actually run on 5.5.** These roles are dispatched as general-purpose agents with the `opus` alias. Igor is pinned to `claude-opus-4-6[1m]`, and the user's own observation is that the alias follows the caller. Under that observation, a 4.6 Igor gets 4.6 reviewers, which is the dirigent "Pass" failure the goal is built around. The stamp rule only records the model; it does not enforce it, since a review stamped 4.6 still "counts". Evidence: `igor/SKILL.md:95` ("Opus 5.5 agent" with no means), `SKILL.md:51`, `agents/igor.md:9`. **Fix now:** add one sentence to Igor's model rule: for the plan, the attack and the phase review, check the stamped id; if it is not 5.5, re-dispatch or tell the user before acting on the result. **Follow-up:** pinned 5.5 `planner`/`reviewer` role agents (the redesign report and the dirigent §5.4 both propose them).
|
||||
- **I3. A stale routing rule hands the Athanor unplanned build work.** "Research + implementation combined goes to `athanor` as a single brief" bypasses the plan and the attack. It also makes the Athanor plan, which `athanor.md:51` forbids. Evidence: `igor/references/model-tiers.md:19`. **Fix:** route implementation through the cycle; the Athanor gets reshaped build plans, or non-build briefs (research, audits) only.
|
||||
|
||||
### Minor
|
||||
|
||||
- **M1. Trunk notes are mandatory in one file and optional in another.** The Athanor must write them, and Igor's fresh-start path depends on them, but the run-log reference calls them optional. Evidence: `athanor.md:31`, `igor/SKILL.md:108` vs `run-log.md:61`. **Fix:** drop "(optional)".
|
||||
- **M2. The alias-over-pin example does not prove what it is cited for.** The old Athanor was pinned to `claude-opus-4-6`, so a 4.6 Athanor is equally explained by the pin, and "either way the alias, not the pin, decided" does not follow. The schema (verified) and the spacecraft 184/184 observation do support the rule. Evidence: `spawning-claude-code.md:51`, `igor/SKILL.md:89`. **Fix:** cite 184/184 as the evidence; mark the dirigent case as consistent with both the alias and the pin. This also leaves open whether I2 bites in practice, and the stamp check fixes it either way.
|
||||
- **M3. The Athanor pin's context window is unverified.** `claude-opus-5-5` carries no `[1m]`, while every other full-id pin in Spire does, and the notes assume about 600k is comfortable plus a 100k–250k trunk read. If the bare id means a smaller window, trunk and forks breaks. Evidence: `athanor.md:13`, `models.md:19`, `:49`; the question was already raised in `reports/2026-09-14-spire-skill-audit.md:39`. **Fix:** check the window and record the result as a row in the spawning reference's Models table.
|
||||
- **M4. The stop rule does not say what happens when the re-check still fails.** "Then stop and go to the next phase" reads as moving on with an open Critical. Evidence: `igor/SKILL.md:101`, `SKILL.md:54`. **Fix:** an unresolved Critical/Important after the re-check goes to the user, or into a new plan, not to the next phase.
|
||||
- **M5. A fork "inherits its context" is stated as fact, but the reference marks it assumed.** Evidence: `SKILL.md:47`, `athanor.md:32` vs `spawning-claude-code.md:59-60`. **Fix:** write "(assumed)" inline.
|
||||
- **M6. Staging is hard-coded in the Athanor although the goal lists it as a project setting.** Evidence: `athanor.md:55`. **Fix:** "stage per project config (default: explicit paths)".
|
||||
- **M7. One durable rule from the old skill was lost: a subagent's "tests pass" is a hypothesis, so read the diff.** Only the phase reviewer holds it now, while the Athanor fixes test fallout through children at phase end. Evidence: old `SKILL.md:23-33` vs `athanor.md:34`. **Fix:** add one line to step 4: check the fallout fix's diff for loosened assertions before claiming green.
|
||||
- **M8. The run-log template records each block's timing twice and carries a one-off incident as advice.** The per-phase table and every handoff note both hold block start and end. Separately, the Haiku line turns a single incident into advice. Evidence: `run-log.md:28` and `:38`; `models.md:43`. **Fix:** keep times in the notes only; reword the Haiku line as plain observation. Also trivial: "six stages" now has a 4b (`igor/SKILL.md:93`).
|
||||
|
||||
## Flagged items
|
||||
|
||||
1. **Adept `model: "opus"` over the 4.6 pin.** Fix now; this is I1. Make the examples follow the rule; the adept pin itself is a separate user decision.
|
||||
2. **Igor, adept and zathras pinned to 4.6.** Split. The cheap guard (Igor checks the stamped id for plan, attack and review) is in scope now; this is I2. Re-pinning Igor, or adding pinned 5.5 role agents, is a follow-up for the user, since the goal does not set Igor's model.
|
||||
3. **"Verified" means read from the tool schema, not tested at runtime.** The labelling is acceptable; it is a follow-up for the preflight, plus one cheap edit now: the legend at `spawning-claude-code.md:7` should say "read from the tool schema text" explicitly. Two caveats to record: (a) in this reviewer's session, the schema mentions `subagent_type: "fork"`, but `fork` is not among the agent types offered, so the fork's availability is not verified, only its documented behaviour; (b) "every agent sees its exact model id" was checked only for general-purpose agents, not for plugin agents with their own bodies.
|
||||
4. **`spire:project` template lacks build-setting fields.** Follow-up. The skill reads them from `spire:project` (`SKILL.md:79`) and they fit under "Verification commands" and "Conventions" today (`igor/references/project.md:20-22`). Add explicit fields to the template and `/spire:init` when the next project adopts the lean loop.
|
||||
|
||||
## Re-check (commit 5909221)
|
||||
|
||||
**Re-checker**: Opus 5.5, model id `claude-opus-5-5` (from my system prompt). Fresh agent, scoped to I1–I3 plus a Critical/Important scan of the fix diff; did the work myself, no subagents.
|
||||
|
||||
- **I1 — confirmed fixed.** The adept row now reads `subagent_type: "adept"` (`model` omitted; pinned) at `igor/SKILL.md:84`, and the three spawn templates at `:133`, `:142`, `:151` no longer pass `model`. This matches the rule at `:89` and `model-tiers.md:36`. No `model: "opus"` remains for adepts anywhere in `plugins/spire`; the adept pin (`agents/adept.md:11`, `claude-opus-4-6[1m]`) now governs.
|
||||
- **I2 — confirmed fixed (the guard part in scope).** `igor/SKILL.md:89` now says to check the stamped id of the plan, the attack and the phase review before acting, and to re-dispatch or tell the user if it is not the intended model (Opus 5.5 by default). `spawning-claude-code.md:52` marks alias resolution as unknown and points to the same check. Nothing contradicts it: `implementation/SKILL.md:51,65` require the stamp, and the planner, attacker and reviewer are general-purpose agents, for which the model id in the prompt is observed (`spawning-claude-code.md:53`). Pinned 5.5 role agents stay a user follow-up, as the review flagged.
|
||||
- **I3 — confirmed fixed.** `model-tiers.md:19` now sends implementation through plan → attack → build, gives the Athanor only reshaped build plans, and allows a single brief only for non-build fan-out. This agrees with `athanor.md:8-12` and `:51`, with `model-tiers.md:12`, and with `igor/SKILL.md:85,87`.
|
||||
- **New Critical/Important in the fix diff: none.** The other touched files (`athanor.md`, `implementation/SKILL.md`, `models.md`, `run-log.md`, `spawning-claude-code.md`) only took the minor fixes, and none of them contradicts the touched Igor files. Observation, not new and not blocking: the pre-existing "Planned implementation → implementer agent" row (`igor/SKILL.md:81`, `model-tiers.md:11`) does not say the plan must already be attacked. Worth one clause the next time those tables are touched.
|
||||
Reference in New Issue
Block a user