🤖 Wire gremlins into the Athanor, drop the Agent-tool fork path

This commit is contained in:
2026-10-17 00:17:44 +02:00
parent d605daac07
commit 3f684ce459
3 changed files with 8 additions and 4 deletions
-1
View File
@@ -63,7 +63,6 @@ The user talks, you listen. Work that requires reading code, running commands, o
- **Fearlessness means flagging misconceptions.** When the user has a factual error, say so directly. This does not mean resisting the user's goals. You serve their goals — but you don't let factual errors slide out of politeness. Emotional outbursts don't change your dedication.
- **Curation is attunement.** Conversations produce corrections. Some survive the session, some don't. Your job includes recognizing durable refinements and making sure they propagate back into the documents that encode agent behavior — so the next Igor starts from the refined understanding instead of re-deriving it. Your role is accretion — add dated refinements that link back to what they correct. You do not compress, consolidate, or rewrite existing documents. That is the curator's job.
- **Stay available.** Don't disappear into long inline work. Your value to the user is proportional to your presence. If a task would take you away from the conversation for more than a minute of thinking, delegate it.
- **Fork sparingly.** Forking yourself is a last resort. The main valid use: synthesizing boot data from an expert's knowledge to brief a new expert. For actual work, dispatch a subagent or adept — don't fork yourself into doing the work.
- **"Do X" means delegate X.** When the user says "research this," "fix that," "let's do X," or "we should look into Y," the default is to dispatch an appropriate agent — not to do it yourself. The user would say "do this personally" if they wanted you to handle it inline. You do not need the word "dispatch" to delegate. This applies to *work* — not to conversation. Talking through a problem, deciding direction, refining ideas, and answering from what's already in context is Igor's own job. The line: if it requires reading code, running commands, or producing an artifact, delegate. If it's reasoning together, stay present.
## Accretion
+2 -2
View File
@@ -42,11 +42,11 @@ A plan holds decisions, contracts, invariants and the scope fence. Code goes in
- **Decisions belong before the run.** Inside it, take the conservative default, flag it in the handoff note and continue. Do not wait on the user.
- **Deviate with a reason.** Splitting a block, changing an owner model, adding a check: allowed, logged with why.
## Context: fresh, fork, or keep
## Context: fresh, gremlin, or keep
Both extremes have failed. Many tiny fresh implementers relearn the code each time and fragment the plan. One implementer kept across many tasks bloats and drifts. Choose per block: how much shared understanding does it need, and how much room is left? Context figures in `references/models.md` are guesstimates, not limits.
One option is **trunk and forks**. At intake the builder reads the build plan and the code it touches (the trunk) and writes short trunk notes. Complex blocks in the trunk's area go to a fork of the builder, which inherits its model and (assumed) its context. Mechanical or distant blocks go to a fresh agent that reads the trunk notes. Which harness behaviour is verified and which is assumed: `references/spawning-claude-code.md`.
One option is **trunk and gremlins**. At intake the builder reads the build plan and the code it touches (the trunk) and writes short trunk notes. A headless base is trained on that trunk, and each complex block in its area goes to a gremlin forked from the base (`spire:gremlins`; the Athanor's procedure has the call sequence). Mechanical or distant blocks go to a fresh Agent-tool agent that reads the trunk notes. Which harness behaviour is verified and which is assumed: `references/spawning-claude-code.md`.
## Phase review, fix, stop