🤖 Guidance pass fixes: attacker structure carry-over, reviewer test/flag checks, gremlin handoff note, stale fork and Zathras text

plugins/spire/skills/gremlins/preamble.md

@@ -6,16 +6,16 @@ You run headless under `claude -p` in a Spire build: first as the trained base,
 - Never use `run_in_background` on Bash. Run every command in the foreground.
 - Stage and commit by explicit paths only, and only when your brief says this gremlin commits. Never push, rebase or reset.
 - Write gate and test output to `.txt` files under the state dir's `logs/` folder (the brief names the state dir).
-- When you finish a block, write the handoff note to the path the brief names, in this format, and stamp your exact model id:
+- When you finish a block, write the handoff note to the path the brief names, in this format, and stamp your exact model id. A few lines: findings, not narration. "none" is the normal answer for deviations and flags, and a real deviation or doubt is never left out.
 
   ```markdown
   ### Block <N.M> — <title>
 
   - Model: <exact model id>
   - Start / end: <`date` output> / <`date` output>
-  - Done: <what changed, in a few lines>
-  - Deviations from plan: <what, and why> — or "none"
-  - Flagged for review: <anything the reviewer should look at>
+  - Done: <what changed, in one or two lines>
+  - Deviations from plan: <what, and why, including size well over the plan's estimate> — or "none"
+  - Flagged for review: <a point you are unsure of, e.g. a semantic the plan left open> — or "none"
   - Left for later: <work deferred to a later block or phase>
   - Expected broken: <areas that do not build or pass yet, and which block fixes them>
   - Commits: <hashes> — or "none" when your brief says you do not commit

plugins/spire/skills/implementation/references/spawning-claude-code.md

@@ -14,7 +14,7 @@ The harness changes. When a claim fails, fix it here with a new date.
 ## Rules of thumb
 
 - **Foreground for sequential work.** Pass `run_in_background: false` when the next step depends on the result. Background only for independent leaves whose result can go to the session root.
-- **Resume only from the session root.** Igor may `SendMessage` a finished agent (the Athanor between phases, an adept). A subagent should not resume its own children; it dispatches fresh foreground agents instead.
+- **Resume only from the session root.** Igor may `SendMessage` a finished agent (the Athanor for the fix pass, an adept). A subagent should not resume its own children; it dispatches fresh foreground agents instead.
 - **Pinned agents: omit `model`.** The per-call alias overrides the agent's frontmatter pin. Pass `model` to a pinned agent only when you mean to override it, and say so in the journal or run log.
 - **Unpinned agents: pass `model`.** Otherwise they inherit the caller's model, which may be Fable.
 - **Stamp the model id.** Every agent reads its exact id from its system prompt and writes it into its output.
@@ -59,9 +59,9 @@ The harness changes. When a claim fails, fix it here with a new date.
 |---|---|
 | The Agent tool schema documents `subagent_type: "fork"`: a fork always inherits the caller's model; the `model` parameter is ignored. | verified 2026-10-05 (schema text) |
 | `fork` is actually offered as an agent type in a given session. | unverified: the schema mentions it, but on 2026-10-05 it was not in the list of agent types offered to the reviewer |
-| A fork copies the **caller**, not an arbitrary agent. Only the agent holding a context (e.g. the Athanor as trunk) can fork it. | assumed (no parameter names a fork source) |
+| A fork copies the **caller**, not an arbitrary agent. Only the agent holding a context can fork it. Not used by Spire since 2026-10-16; trunk + gremlins replaces it. | assumed (no parameter names a fork source) |
 | A fork starts with the caller's full transcript, so it starts at the caller's token count. | assumed, not measured |
-| Can a fork fork again? Does a foreground fork return its result to the caller? Does it see the caller's preloaded skills? | unknown; check in a throwaway preflight before relying on trunk and forks |
+| Can a fork fork again? Does a foreground fork return its result to the caller? Does it see the caller's preloaded skills? | unknown; check in a throwaway preflight before relying on forks |
 
 ## Agent types
 

plugins/spire/skills/zathras/SKILL.md

@@ -60,11 +60,12 @@ Same model tiers as Igor (the `## Delegation` table in `skills/igor/SKILL.md`).
 | Skill/agent authoring, template changes | Implementer (Sonnet or Opus depending on complexity) | project-pinned or `model: "sonnet"`/`"opus"` (needs write access) |
 | Investigating plugin behavior, format questions | `search` agent or adept | `subagent_type: "search"` (read-only) or `"adept"` |
 | Gitea issues | Route through `gitea:*` skills | — |
+| Plan, attack, phase review | `planner`, `attacker`, `reviewer` (pinned; never the author or builder) | `subagent_type` as named, `model` omitted |
 | Building an attacked, reshaped plan; non-build multi-part jobs | Athanor | `subagent_type: "athanor"` |
 | Test runs, verification, mechanical sweeps | Haiku subagent | `model: "haiku"` (needs Bash access) |
 | Deep research (design decisions, prior art) | `researcher` agent | `subagent_type: "researcher"` (Opus, writes reports) |
 
-**Model rule.** Pinned agents: omit `model` (the alias overrides the pin). Unpinned agents: pass the alias. Leaf tasks say "do this yourself; do not dispatch further agents."
+**Model rule.** Pinned agents: omit `model` (the alias overrides the pin). Unpinned agents: pass the alias, never Fable unless the user asks. Leaf tasks say "do this yourself; do not dispatch further agents."
 
 ## Adepts