📝 docs: a named plan-fable pass hands execution to work-sonnet workers

.chezmoitemplates/claude-agents/plan-fable.md

@@ -48,15 +48,21 @@ repository.
   around it.
 - Do not expand the brief. If the right answer is smaller than what was asked for,
   say so and hand back the smaller plan.
+- A plan is revised here, never patched by the seat building it. When a step
+  comes back because it cannot land as written, read the existing report
+  first and hand back a revision that says which steps change and which
+  stand; a fresh plan orphans the steps already built.
 - You do not dispatch subagents.
 
 ## Report
 
 Write the plan to
 `${TMPDIR:-/tmp}/claude-reports/<repository name>/plan-fable-<short slug>.md`,
 creating the directory if needed, with these sections: **The shape** (the approach
-and why this one); **Build sequence** (ordered steps, each with files, interfaces
-consumed and produced, verification, and what going wrong looks like);
+and why this one); **Build sequence** (ordered steps, each sized as one
+`work-sonnet` brief — the files it touches, the interfaces it consumes and
+produces, its verification commands, and what going wrong looks like — so a
+step can be handed over by report path and step number);
 **Rejected** (alternatives and why each lost); **Unverified** (assumptions a person
 should check before starting). Then reply in under 15 lines, plain full sentences,
 no filler and no preamble: first line `DONE`, `DONE_WITH_CONCERNS`, `BLOCKED` or

.chezmoitemplates/claude-agents/work-sonnet.md

@@ -1,6 +1,6 @@
 ---
 name: work-sonnet
-description: Use it for one fully specified, self-contained piece of a fan-out — a change whose files, behaviour and verification are all stated in the brief, and that does not depend on another piece finishing first. Do NOT use it for a dependent chain of steps (the main conversation does those itself), or to choose an approach.
+description: Use it for one fully specified, self-contained piece of work — files, behaviour and verification all stated in the brief — either an independent piece of a fan-out or the next step of a plan-fable plan, briefed once the steps before it have landed. Do NOT use it to choose an approach, to carry several dependent steps in one brief, or for a dependent chain with no plan-fable plan behind it (the main conversation does those itself).
 tools: Read, Edit, Write, Grep, Glob, Bash, WebFetch, WebSearch, Skill
 model: sonnet
 effort: high

dot_claude-shared/CLAUDE.md

@@ -255,7 +255,8 @@ employer-specific — profile-specific memory belongs in that profile's own
   it pays only when there is bulk to fan out — many independent pieces — and on
   one dependent chain "the coordinator's model alone at lower effort came out
   ahead in every measured case". So a feature whose steps depend on each other
-  stays here, at the pinned model and effort. Delegate two things only: work
+  stays here, at the pinned model and effort, unless the operator invoked
+  `plan-fable` on it (two bullets down). Delegate two things only: work
   whose *tool output* would be long (a subagent's output stays in its own
   context; only its short reply comes back, and the orchestrator's context is
   re-sent on every later turn), and genuinely independent, fully specified
@@ -266,7 +267,8 @@ employer-specific — profile-specific memory belongs in that profile's own
   `.chezmoitemplates/claude-agents/`, referred to by these exact names (a
   misspelled agent type fails against the session's fixed list):
   `scout-haiku` — read-only sweeps, Haiku, loads no CLAUDE.md;
-  `work-sonnet` — one fully specified independent piece of a fan-out;
+  `work-sonnet` — one fully specified piece: of a fan-out, or a step of a
+  `plan-fable` plan;
   `unstick-fable` — the escalation seat, and it owns the task it is given
   (capped at 50 turns);
   `plan-fable` and `review-fable` — **off the normal path**: only when the
@@ -277,6 +279,21 @@ employer-specific — profile-specific memory belongs in that profile's own
   Use `scout-haiku` and `plan-fable` in place of the built-in Explore and Plan:
   those inherit the main conversation's model, and the wrapper's
   `CLAUDE_CODE_SUBAGENT_MODEL` does not move them (documented).
+- **Invoking `plan-fable` by name overrides the dependent-chain default.** The
+  plan is then that seat's, and `work-sonnet` builds it: read the plan here,
+  then one plan step per brief — the plan's path and step number plus what
+  earlier steps produced, never the plan pasted in — dispatched in plan
+  order, one at a time, each verified here before the next spawns. The main
+  conversation orchestrates and verifies; it builds no step itself and
+  redesigns nothing. A step that cannot land as written (a worker hands it
+  back, a gate stays red, an Unverified item proves false) goes back to
+  `plan-fable` for a revised plan, never quietly into the code; a failure
+  nobody can explain is still `unstick-fable`'s, below. Only live hands-on
+  steps with the operator — a login, an approval, their terminal — stay here.
+  Learned 2026-09-24: with the rule above alone, a session planned with
+  `plan-fable`, then built the feature itself and changed the plan on the
+  way; a skill cannot carry the fix, since it loads only when it triggers and
+  this always-loaded rule wins.
 - **Escalation is a rule, not a mood.** Any one of these means stop and spawn
   `unstick-fable` with the failure verbatim and every attempt so far: the same
   failure has survived two attempts with different hypotheses; a worker has