feat(pipeline): route to the lightest correct methodology; move execution loops onto the Workflow substrate

The selector forced every task through the heaviest methodology's
critical path: a behaviour-preserving, type-enumerable change paid the
same specify -> planner -> implement front-half as a novel feature,
because it was neither new behaviour (tdd) nor an observed bug (debug)
and so fell to specify by elimination. Two coupled defects — a selector
with no verification axis, and an all-or-nothing executor — kept the
existing lighter path unreachable and uneconomical. This fixes both.

Part A — verification-keyed selector (boss/SKILL.md):
- Replace the three-way "design line" with an ordered cascade that adds
  a verification/enumeration axis ahead of the settled-vs-fork question.
  Each lighter arm carries a positive trigger matched by signature, not
  reached by elimination.
- New `compiler-driven` arm: a type/signature edit at a definition site
  that propagates mechanically. Observe-then-bounce — make the edit,
  build, run the suite; clean build AND suite green unchanged commits;
  a hole bounces up (specify for a design choice, tdd for discovered
  test-specifiable new behaviour); a regression bounces to debug.
- The observed-bug RED-first gate is first in the cascade, so a
  mechanical-looking fix cannot bypass it.
- The straddle rule ("add an enum variant") is codified as a rule:
  mechanical/forwarding -> compiler-driven; encodes new behaviour ->
  tdd/spec; doubt routes up.
- The executor is the elevated inline carve-out plus a shipped workflow,
  not a heavy new skill ("the largest concrete win is small").

Part B — Workflow substrate (implement/workflows/):
- implement-loop.js: the per-task loop as a deterministic script. Each
  phase (implementer -> spec-compliance -> quality, + tester for E2E) is
  a separate top-level agent() call, so a single phase is independently
  invokable and inter-phase aggregation/re-loop is code. Retires the
  implement-orchestrator agent's inline-role-switch workaround (the four
  phase agents survive as the agent-types the script dispatches).
- compiler-driven-edit.js: the observe-then-bounce loop.
- install.sh / uninstall.sh symlink shipped workflows into
  ~/.claude/workflows/.
- specify and brainstorm stay prose + interactive (human-intent oracle);
  only the autonomous/mechanical loops moved. try-and-error is deferred.

Docs (pipeline taxonomy, design, agent-template, migration, README) and
all selector<->executor cross-references updated; the arm and its
executor are co-located so a future re-route through the full loop is a
visible regression.

Verified by an adversarial multi-agent pass: PASS on all six acceptance
criteria; two coherence concerns fixed. The shipped scripts are
syntax-validated but exercised only in a downstream target project (the
skills repo is not itself a pipeline target).

closes #7

docs/agent-template.md

@@ -76,8 +76,7 @@ plugin's agent path is enough disambiguator).
 
 Examples: `architect`, `bencher`, `debugger`, `implementer`,
 `tester`, `fieldtester`, `docwriter`, `grounding-check`,
-`spec-skeptic`, `plan-recon`, `spec-reviewer`, `quality-reviewer`,
-`implement-orchestrator`.
+`spec-skeptic`, `plan-recon`, `spec-reviewer`, `quality-reviewer`.
 
 ### `description`
 
@@ -98,9 +97,13 @@ Common tool sets:
   grounding-check, spec-skeptic, plan-recon): `Read, Glob, Grep, Bash`
 - Implementation (implementer, tester, debugger, docwriter,
   fieldtester, bencher): `Read, Edit, Write, Bash, Glob, Grep`
-- Orchestrator (implement-orchestrator): `Read, Edit, Write,
-  Bash, Glob, Grep` — same as implementer; the orchestration
-  happens via sequential role-switches within its own context
+
+The autonomous execution loops are **Workflow scripts**, not agents
+(`implement/workflows/`): they orchestrate the implementation phase
+agents from the top level via `agent()` calls. The agents they
+dispatch still carry no `Agent` tool — the no-nested-dispatch rule is
+unchanged; the workflow simply does the orchestration the retired
+`implement-orchestrator` agent used to fake with inline role-switches.
 
 ## Sections in detail
 

docs/design.md

@@ -29,8 +29,13 @@ genuinely-varying parts moved into each project's `CLAUDE.md`.
 The plugin owns:
 
 - **Pipeline form** — the directed graph of phases:
-  `design → plan → execute → review → close`, with the
-  bug-driven side path `debug → execute (mini)`.
+  `design → plan → execute → review → close`, entered through a
+  **selector cascade** of entry paths walked on a verification /
+  enumeration axis (observed bug → `debug`; design fork →
+  `brainstorm`; behaviour-preserving type/signature edit →
+  `compiler-driven`; test-specifiable → `tdd`; else → spec-driven).
+  The taxonomy of paths and their oracles lives in
+  `pipeline.md` § The methodology taxonomy.
 - **Hard-gates** — spec before plan, plan before implement,
   audit before cycle-close. Skipping rules are codified per
   skill.
@@ -50,13 +55,22 @@ The plugin owns:
   the working tree, never commit. Only the orchestrator commits.
 - **main HEAD sacrosanct** — no reset, no revert, by any actor.
   main moves forward only via orchestrator commits.
-- **No nested subagent dispatch** — a hard Claude Code
-  platform constraint; the implement-orchestrator runs phases
-  as sequential role-switches inside its own context. Opus 4.8
-  added Workflows as an orthogonal top-level fan-out mechanism
-  but did not lift this constraint — a workflow script
-  orchestrates from the top level, yet the agents it spawns
-  still cannot spawn further agents.
+- **No nested subagent dispatch** — a hard Claude Code platform
+  constraint: an agent cannot spawn further agents. Workflows do not
+  lift it; a workflow script orchestrates from the **top level**, and
+  the agents it spawns still cannot spawn further agents. This is
+  exactly why the autonomous execution loops moved onto the Workflow
+  substrate: the `implement-loop` and `compiler-driven-edit` scripts
+  (`implement/workflows/`) run the per-phase agents as their own
+  top-level `agent()` calls, so a single phase is independently
+  invokable — which retired the former `implement-orchestrator`
+  agent's inline-role-switch workaround (it had to absorb the three
+  phases into one context precisely because it could not nest). The
+  four phase agents survive as the agent-types the scripts dispatch;
+  what was retired is the dispatch/aggregation prose. The interactive
+  paths (`specify`, `brainstorm`) stay prose skills — their oracle is
+  human intent and needs a human in the loop, which a
+  run-to-completion workflow cannot host.
 - **No orphan agents** — every agent lives under the skill
   that dispatches it.
 - **Output budget discipline** — agents have word budgets on

docs/migration.md

@@ -30,6 +30,16 @@ it into `~/.claude/skills/<name>`; if the skill has an
 discovery still finds everything while the source tree keeps
 the structural binding.
 
+A skill that ships executable **Workflow scripts** keeps them in a
+`workflows/` subdirectory beside its `SKILL.md` (e.g.
+`implement/workflows/implement-loop.js`). `install.sh` symlinks each
+`*.js` there into the flat `~/.claude/workflows/` directory — where the
+Workflow tool resolves named workflows from — keeping the same
+structural binding (the script lives with its dispatching skill) as
+agents do. `uninstall.sh` removes those symlinks too. A workflow script
+is the deterministic form of an autonomous execution loop; it dispatches
+the skill's agent-types via top-level `agent()` calls (no nesting).
+
 ## Migration checklist per skill
 
 1. Strip project-specific paths (`docs/specs`, `docs/plans`,

docs/pipeline.md

@@ -1,14 +1,15 @@
 # Pipeline
 
 ```
-[new cycle]               [test-specifiable feature]      [bug observed]
-       |                            |                            |
-       v                            v                            v
- brainstorm  ->  specify  ->  plan  ->  implement             debug -> implement (mini)
-       ^            ^               |
-       |            |              tdd -> implement (mini)
-       |       specify -> plan  (design settled in sources)
-       +----(design fork)----------/   (specify/tdd bounce here; RED executable-spec -> GREEN)
+        ENTRY PATHS — the selector cascade, walked top to bottom (see boss/SKILL.md)
+  bug observed ........... debug ........................ implement (mini)   # RED-first; FIRST in the cascade
+  design fork ............ brainstorm -> specify -> plan -> implement
+  type/signature edit .... compiler-driven  -> commit (clean build + suite green unchanged)
+                                           -> bounce: specify | tdd (a hole) | debug (suite red)
+  test-specifiable ....... tdd -> implement (mini)        # RED executable-spec -> GREEN
+  settled prose design ... specify -> plan -> implement
+
+       (specify / tdd bounce to brainstorm on a design fork)
        (per iteration loop)
                   |
        [cycle close — a loop step, not a milestone close]
@@ -33,6 +34,30 @@
                                              next cycle
 ```
 
+## The methodology taxonomy
+
+Development paths differ on two irreducible axes — the **first artefact
+written**, and the **correctness oracle**. (Error-recovery is not a
+third axis: whole-attempt discard is the plugin's universal containment,
+not a per-path signature.) The top-level cut — ratified prose intent
+before code (spec-driven) vs. machine / test / run oracles — is the hard
+boundary; the paths cannot be centralised in one skill, only share the
+implement executor as a primitive and the cycle-close `audit` tail.
+
+| Path | First artefact | Oracle | Bounce-out when |
+|------|----------------|--------|-----------------|
+| **spec-driven** | ratified prose spec | human intent, judged at the document | (the deliberate heavy sink) |
+| **tdd / debug** | a RED test | the assertion goes green | not test-specifiable → `brainstorm` |
+| **compiler-driven** | a type / signature edit | clean build + suite green unchanged | a hole needs a decision → `specify` (or `tdd` if it is test-specifiable new behaviour); suite red → `debug` |
+| **try-and-error** | throwaway code | an observed run | attempt budget exhausted |
+
+`try-and-error` is **deferred** — listed for completeness, not yet a
+live path. It is an exploration front-end terminating in a tdd-style
+handoff, and its attempt tail is structurally unbounded (it can cost
+more wall-clock than the spec-driven baseline it is meant to beat, and
+its attempt-budget is a magic number the selector cannot derive). Out of
+scope until it is given a bounded form.
+
 ## Cycle vs. milestone
 
 These are two distinct axes, and conflating them is a bug.
@@ -130,12 +155,35 @@ the plan-recon agent for read-only file-structure mapping.
 
 ### implement
 
-Dispatches the implement-orchestrator agent, which runs the
-entire per-task loop (implementer phase → spec-compliance check
-→ quality check) as sequential role-switches inside its own
-context. Writes code, tests, and stats files directly in the
-working tree as unstaged changes. On `PARTIAL` or `BLOCKED`,
-also writes `BLOCKED.md` at the repo root.
+Runs the `implement-loop` Workflow (`implement/workflows/implement-loop.js`),
+a deterministic script that executes the per-task loop —
+implementer → spec-compliance → quality, each a separate
+`agent()` call — and aggregates the verdicts in code. A Workflow
+orchestrates from the top level, so the per-task phases are real,
+independently-invokable agent calls; this retired the former
+`implement-orchestrator` agent's inline-role-switch workaround
+(the four phase agents survive as the agent-types the script
+dispatches). Writes code, tests, and stats files directly in the
+working tree as unstaged changes; never commits. On `PARTIAL` or
+`BLOCKED`, also writes `BLOCKED.md` at the repo root.
+
+### compiler-driven
+
+The lighter executor for a **behaviour-preserving type/signature
+edit at a definition site** — the cascade arm between `debug` and
+`tdd`. Runs the `compiler-driven-edit` Workflow
+(`implement/workflows/compiler-driven-edit.js`): make the edit,
+propagate it mechanically across the sites the build enumerates,
+then let a real build + suite run settle the verdict —
+**observe-then-bounce**. Clean build AND suite green *unchanged* →
+the edit is committed by the orchestrator; a hole that forces a
+design decision → bounce to `specify` (or `tdd` if it turns out to be
+test-specifiable new behaviour, per the straddle rule); the suite not
+green-unchanged (a regression — the edit was not behaviour-preserving)
+→ bounce to `debug`, RED-first. A truly trivial edit may run inline
+without the
+workflow, under the same done-signal. Never skips the
+review-and-commit discipline; the orchestrator inspects and commits.
 
 ### audit
 
@@ -209,14 +257,23 @@ documents what the skill skips and under what conditions:
   before it: skipped when the design is already settled in the sources
   (the work enters through `specify` directly), run when a load-bearing
   decision is still open.
-- `planner` is never skipped at iteration start, except for
-  the bug-driven `debug → implement (mini)` side path.
+- `planner` is never skipped at iteration start, except for the
+  side paths that carry no prose plan: the bug-driven
+  `debug → implement (mini)` path and the `compiler-driven` path
+  (whose "plan" is the type-checker's enumeration of edit sites).
 - `implement` is the iteration body; not skippable.
 - `audit` is mandatory at cycle close.
-- `debug` is mandatory RED-first for any observable bug.
+- `debug` is mandatory RED-first for any observable bug — first in
+  the selector cascade, so a mechanical-looking fix cannot bypass it.
 - `tdd` is a standard alternative entry to `brainstorm` for
   test-specifiable work; it bounces back to `brainstorm` on a
   design fork. Always available — not opt-in.
+- `compiler-driven` is the cascade arm for a behaviour-preserving
+  type/signature edit: it skips `specify` and `planner`, and its
+  done-signal (clean build + suite green unchanged) is the gate. It
+  bounces on a hole to `specify` (a design choice) or `tdd` (discovered
+  test-specifiable new behaviour), and to `debug` on a regression.
+  Always available — not opt-in.
 - `fieldtest` and `docwriter` are optional and orchestrator-
   dispatched.