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
This commit is contained in:
+23
-9
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user