Route tasks to the lightest correct methodology instead of defaulting to spec-driven #7

New Issue

2026-06-17T11:45:13+02:00

Brummel commented

2026-06-17 11:45:13 +02:00

Problem

The pipeline forces every task through the heaviest methodology's obligatory critical path regardless of the task's nature. A trivial, behaviour-preserving change — e.g. a carrier/newtype narrowing or a constructor rename propagated across N files, where the type checker enumerates every edit site and the existing suite stays green unchanged — pays the same specify -> planner -> implement -> audit front-half (two prose artefacts, mandatory subagent gates, a human sign-off wait-gate) as a genuinely novel cross-subsystem feature.

The cost to minimise is wall-clock / obligatory per-cycle effort, not tokens. The pain is the lack of proportionality, and it does not scale down with task triviality.

The root is structural, in two coupled places:

The selector has no verification/enumeration axis. The entry-path reflection (boss/SKILL.md:113-167) partitions feature work three ways on a single "design line" — test-specifiable / settled / fork — keyed only on whether the design is settled, never on what verifies or enumerates the work. A behaviour-preserving mechanical change is neither new behaviour (tdd) nor an observed bug (debug), so it falls to specify by elimination (specify/SKILL.md:38-39: specify "sits on every prose-design path — it is not bypassed"). The reflection is asserted to be "always three-way" (boss/SKILL.md:167).
The executor is all-or-nothing. The per-task loop runs three phases sequentially in one orchestrator context (implement/SKILL.md:53: implementer -> spec-compliance -> quality). The documented reason is a platform limit: nested-subagent dispatch is forbidden, so phases are inline role-switches, and a finer-grained invocation is called "a capability Claude Code does not provide" (implement/SKILL.md:211, 242). A lighter path handing work into this loop sheds only specify+planner, not the heaviest node.

Lighter machinery already exists but is unreachable: implement/SKILL.md:41-44 permits trivial mechanical edits inline "without dispatch". The selector routes past it by elimination before it can apply.

Diagnostic anchor: the existing lighter path is never chosen

tdd is a lighter entry path that exists today and is, in practice, never selected — for exactly the two defects above. Its trigger (new behaviour pinnable as one falsifiable assertion) is a narrow subset that behaviour-preserving work cannot satisfy, so such work falls to specify; and even when chosen it funnels its GREEN side into the same 3-phase loop, so it is barely lighter. Any new lighter path added without fixing both defects inherits this fate: present but unreachable, uneconomical if reached.

Direction

Two coupled changes. Either alone reproduces the tdd failure (selector-only -> unreachable; executor-only -> uneconomical).

A. A verification-keyed selector with observe-then-bounce routing

Replace the three-way "design line" with an ordered cascade that adds a verification/enumeration axis before the settled-vs-fork question, so each lighter path carries a positive trigger and is matched by signature rather than reached by elimination.

Design constraint (reasoned): a cascade that routes on predicates which are outcomes of the work — "this change is behaviour-preserving", "the suite will stay green unchanged", "the solution shape is genuinely unknown" — is unsound as a discriminator, because it asks the agent to predict the result before doing the work; determinism then survives only via a conservative tie-break that re-creates the heavy-path gravity well for every borderline task.

The sound form enters on an observable trigger and lets a run settle the verdict:

route(task):
    observed bug                   -> debug          # mandatory RED-first gate, never bypassed
    forces a design choice         -> brainstorm     # the only place doubt resolves "up"
    a type/signature edit at a def  -> compiler-driven:
        make the edit; build; run the suite
        clean build AND suite green unchanged   -> commit
        a hole needs a decision, OR suite not green -> bounce (specify / debug)
    new behaviour as one assertion -> tdd
    else                           -> spec-driven    # the heavy, deliberate fallback

The fallible ex-ante guess becomes a cheap ex-post detection: a mis-routed behaviour change fails the post-condition and bounces, instead of shipping green-but-wrong. This generalises the existing RED-first philosophy — observe, do not predict.

Hazards a future implementation must respect:

The observed-bug check must be a hard gate before the type-edit arm, or a type-level bugfix bypasses the mandatory RED-first discipline.
"Add an enum variant" straddles the type-edit arm and the new-behaviour arm; the line must be a rule (mechanical / forwarding arms -> type-edit path; arms that encode new behaviour -> tdd / spec), not an example.
The largest concrete win is small: give the existing inline mechanical carve-out (implement/SKILL.md:41-44) a positive selector arm plus an explicit done-signal (clean build + suite green unchanged). Do not over-build a heavy new skill where elevating the carve-out suffices.

B. Move the autonomous methodology loops onto the Workflow substrate

The system predates the Workflow feature; the Skill/Agent split and the inline-role-switch workaround are artefacts of orchestrating by prose-interpreted dispatch (implement/SKILL.md:242 documents the missing capability explicitly). The Workflow primitive now provides it. Migrating the autonomous loops dissolves the executor defect:

The 3-phase loop becomes individual agent calls in a deterministic script — a single phase (e.g. a pure-refactor verify) is now independently invokable, which implementer.md's pure-refactor exception cannot be today.
Inter-phase aggregation becomes code (filter, route, decide commit shape) instead of natural-language reasoning between dispatches.
The routing branch keys on real build/test exit codes — i.e. exactly the observe-then-bounce form from (A).

Split line, along the interactivity boundary:

Autonomous / mechanical -> Workflow script: the compiler-driven loop, the implement per-task loop, the GREEN side of tdd/debug.
Interactive / judgement -> stays a prose skill: spec sign-off, brainstorm approval, the collaborative non-orchestrator mode. Workflows run to completion non-interactively and nest one level only; the spec path's oracle is human intent and requires a human in the loop.
Agents survive as agent-type definitions reused by the workflow's agent calls; what is retired is the dispatch/aggregation prose in the skill bodies.

Pilot scope: the compiler-driven loop and the implement loop, where the substrate gain is largest and the interactivity risk is zero.

The methodology taxonomy

Development paths differ on two irreducible axes — first artefact written, and 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
try-and-error	throwaway code	an observed run	attempt budget exhausted

Scope and non-goals

specify and brainstorm stay prose-driven and interactive — not migrated to the Workflow substrate.
try-and-error is deferred. Claim (reasoned): it is not a co-equal path but 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 the selector and substrate work lands.
No change to the closes #N commit convention, the standing reading (docs/conventions.md:56-61), or the main-sacrosanct / orchestrator-only-commit discipline.

Acceptance checklist

The entry-path selector carries a verification/enumeration axis with a positive trigger per lighter path; a behaviour-preserving, type-enumerable change is reached without falling through to spec-driven by elimination.
Routing for the mechanical / type-edit path is observe-then-bounce: entry on a syntactic trigger, verdict from an actual build + suite run, bounce on the post-condition.
The observed-bug RED-first gate precedes the type-edit arm.
The compiler-driven and implement loops run as Workflow scripts; a single per-task phase is independently invokable.
specify / brainstorm remain prose and interactive.
The selector arm and its executor wiring (which phases each path sheds) are co-located / cross-referenced, so a future edit re-routing a lighter path back through the full loop is a visible regression.

## Problem The pipeline forces every task through the heaviest methodology's obligatory critical path regardless of the task's nature. A trivial, behaviour-preserving change — e.g. a carrier/newtype narrowing or a constructor rename propagated across N files, where the type checker enumerates every edit site and the existing suite stays green unchanged — pays the same `specify -> planner -> implement -> audit` front-half (two prose artefacts, mandatory subagent gates, a human sign-off wait-gate) as a genuinely novel cross-subsystem feature. The cost to minimise is wall-clock / obligatory per-cycle effort, not tokens. The pain is the lack of proportionality, and it does not scale down with task triviality. The root is structural, in two coupled places: 1. **The selector has no verification/enumeration axis.** The entry-path reflection (`boss/SKILL.md:113-167`) partitions feature work three ways on a single "design line" — test-specifiable / settled / fork — keyed only on whether the *design is settled*, never on what *verifies or enumerates* the work. A behaviour-preserving mechanical change is neither new behaviour (tdd) nor an observed bug (debug), so it falls to `specify` by elimination (`specify/SKILL.md:38-39`: specify "sits on every prose-design path — it is not bypassed"). The reflection is asserted to be "always three-way" (`boss/SKILL.md:167`). 2. **The executor is all-or-nothing.** The per-task loop runs three phases sequentially in one orchestrator context (`implement/SKILL.md:53`: implementer -> spec-compliance -> quality). The documented reason is a platform limit: nested-subagent dispatch is forbidden, so phases are inline role-switches, and a finer-grained invocation is called "a capability Claude Code does not provide" (`implement/SKILL.md:211, 242`). A lighter path handing work into this loop sheds only `specify`+`planner`, not the heaviest node. Lighter machinery already exists but is unreachable: `implement/SKILL.md:41-44` permits trivial mechanical edits inline "without dispatch". The selector routes past it by elimination before it can apply. ## Diagnostic anchor: the existing lighter path is never chosen `tdd` is a lighter entry path that exists today and is, in practice, never selected — for exactly the two defects above. Its trigger (new behaviour pinnable as one falsifiable assertion) is a narrow subset that behaviour-preserving work cannot satisfy, so such work falls to `specify`; and even when chosen it funnels its GREEN side into the same 3-phase loop, so it is barely lighter. Any new lighter path added without fixing both defects inherits this fate: present but unreachable, uneconomical if reached. ## Direction Two coupled changes. Either alone reproduces the `tdd` failure (selector-only -> unreachable; executor-only -> uneconomical). ### A. A verification-keyed selector with observe-then-bounce routing Replace the three-way "design line" with an ordered cascade that adds a verification/enumeration axis *before* the settled-vs-fork question, so each lighter path carries a **positive** trigger and is matched by signature rather than reached by elimination. Design constraint (reasoned): a cascade that routes on predicates which are *outcomes of the work* — "this change is behaviour-preserving", "the suite will stay green unchanged", "the solution shape is genuinely unknown" — is unsound as a discriminator, because it asks the agent to predict the result before doing the work; determinism then survives only via a conservative tie-break that re-creates the heavy-path gravity well for every borderline task. The sound form enters on an **observable** trigger and lets a **run** settle the verdict: ``` route(task): observed bug -> debug # mandatory RED-first gate, never bypassed forces a design choice -> brainstorm # the only place doubt resolves "up" a type/signature edit at a def -> compiler-driven: make the edit; build; run the suite clean build AND suite green unchanged -> commit a hole needs a decision, OR suite not green -> bounce (specify / debug) new behaviour as one assertion -> tdd else -> spec-driven # the heavy, deliberate fallback ``` The fallible ex-ante guess becomes a cheap ex-post detection: a mis-routed behaviour change fails the post-condition and bounces, instead of shipping green-but-wrong. This generalises the existing RED-first philosophy — observe, do not predict. Hazards a future implementation must respect: - The observed-bug check must be a hard gate before the type-edit arm, or a type-level bugfix bypasses the mandatory RED-first discipline. - "Add an enum variant" straddles the type-edit arm and the new-behaviour arm; the line must be a **rule** (mechanical / forwarding arms -> type-edit path; arms that encode new behaviour -> tdd / spec), not an example. - The largest concrete win is small: give the existing inline mechanical carve-out (`implement/SKILL.md:41-44`) a positive selector arm plus an explicit done-signal (clean build + suite green unchanged). Do not over-build a heavy new skill where elevating the carve-out suffices. ### B. Move the autonomous methodology loops onto the Workflow substrate The system predates the Workflow feature; the Skill/Agent split and the inline-role-switch workaround are artefacts of orchestrating by prose-interpreted dispatch (`implement/SKILL.md:242` documents the missing capability explicitly). The Workflow primitive now provides it. Migrating the autonomous loops dissolves the executor defect: - The 3-phase loop becomes individual agent calls in a deterministic script — a single phase (e.g. a pure-refactor verify) is now independently invokable, which `implementer.md`'s pure-refactor exception cannot be today. - Inter-phase aggregation becomes code (filter, route, decide commit shape) instead of natural-language reasoning between dispatches. - The routing branch keys on real build/test exit codes — i.e. exactly the observe-then-bounce form from (A). Split line, along the interactivity boundary: - **Autonomous / mechanical -> Workflow script:** the compiler-driven loop, the implement per-task loop, the GREEN side of tdd/debug. - **Interactive / judgement -> stays a prose skill:** spec sign-off, brainstorm approval, the collaborative non-orchestrator mode. Workflows run to completion non-interactively and nest one level only; the spec path's oracle is human intent and requires a human in the loop. - **Agents survive as agent-type definitions** reused by the workflow's agent calls; what is retired is the dispatch/aggregation prose in the skill bodies. Pilot scope: the compiler-driven loop and the implement loop, where the substrate gain is largest and the interactivity risk is zero. ## The methodology taxonomy Development paths differ on two irreducible axes — first artefact written, and 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 | | try-and-error | throwaway code | an observed run | attempt budget exhausted | ## Scope and non-goals - `specify` and `brainstorm` stay prose-driven and interactive — not migrated to the Workflow substrate. - `try-and-error` is deferred. Claim (reasoned): it is not a co-equal path but 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 the selector and substrate work lands. - No change to the `closes #N` commit convention, the standing reading (`docs/conventions.md:56-61`), or the main-sacrosanct / orchestrator-only-commit discipline. ## Acceptance checklist - [ ] The entry-path selector carries a verification/enumeration axis with a positive trigger per lighter path; a behaviour-preserving, type-enumerable change is reached without falling through to spec-driven by elimination. - [ ] Routing for the mechanical / type-edit path is observe-then-bounce: entry on a syntactic trigger, verdict from an actual build + suite run, bounce on the post-condition. - [ ] The observed-bug RED-first gate precedes the type-edit arm. - [ ] The compiler-driven and implement loops run as Workflow scripts; a single per-task phase is independently invokable. - [ ] `specify` / `brainstorm` remain prose and interactive. - [ ] The selector arm and its executor wiring (which phases each path sheds) are co-located / cross-referenced, so a future edit re-routing a lighter path back through the full loop is a visible regression.

Brummel added the feature label 2026-06-17 11:45:13 +02:00

Brummel commented

2026-06-17 12:26:50 +02:00

Design decisions — #7 implementation (full Part A + Part B, single pass)

Implemented directly against the skill/agent/doc surface (this is the meta-repo that defines the pipeline; it does not dogfood its own specify → planner → implement, so the change lands as a direct commit, per the user's instruction to use none of the plugin's own skills for the work). Every load-bearing decision below is recorded so a future reader can see why, not just what.

Part A — verification-keyed selector

DD1 — ordered cascade, first match wins. boss/SKILL.md "Entry-path reflection" replaces the three-way design line with an ordered cascade that puts a verification/enumeration axis ahead of the settled-vs-fork question. Order: observed bug → debug · forces a design choice → brainstorm · type/signature edit at a def, propagating mechanically → compiler-driven · new behaviour as one assertion → tdd · else → spec-driven. Each lighter arm carries a positive trigger matched by signature; the prose twice rejects reach-by-elimination.
DD2 — straddle rule as a rule, not an example. "Add an enum variant" is decided by what the edit encodes: mechanical/forwarding (type checker enumerates the sites, behaviour preserved) → compiler-driven; encodes new behaviour (new code path, new observable output) → tdd/spec-driven. Doubt = the change carries behaviour → route up.
DD3 — observe-then-bounce. Entry on the observable/syntactic trigger; a real build + suite run is the oracle, not an ex-ante "this is behaviour-preserving" guess. Done-signal = clean build AND suite green unchanged (no test added/removed/weakened). A mis-routed behaviour change fails the post-condition and bounces instead of shipping green-but-wrong.
DD4 — the executor is the elevated inline carve-out, not a heavy new skill. Per the issue's "the largest concrete win is small". The existing implement "trivial mechanical edits … without dispatch" carve-out got a positive selector arm + the explicit done-signal. This is why Part A alone already yields a reachable AND economical light path — the arm routes to a path that bypasses the full per-task loop, not into it.

Part B — Workflow substrate

DD5 — delivery & discovery. Shipped executable Workflow scripts live under <skill>/workflows/ (implement/workflows/implement-loop.js, compiler-driven-edit.js). install.sh symlinks each *.js into the flat ~/.claude/workflows/ (where the Workflow tool resolves named workflows); uninstall.sh removes them. Same structural binding as agents.
DD6 — per-phase fresh-context model. On the substrate the three per-task phases become separate agent() calls (implementer → spec-reviewer → quality-reviewer), with the working-tree diff + task text as the shared medium and the script threading a reviewer's findings back into a repair dispatch. This strengthens the fresh-eyes property the review phases already wanted (structurally enforced, not a mindset switch) and preserves context-offload (per-task chatter stays inside the workflow's agent contexts).
DD7 — file mutations stay in agents; the script is pure orchestration. Workflow scripts have no fs/shell of their own, so every working-tree mutation (code, stats.json, BLOCKED.md) happens inside an agent() call; routing keys on the structured verdict each agent reports (which encodes the real build/test outcome).
DD8 — sequential tasks, shared tree, no worktree isolation. Plan tasks carry implicit ordering dependencies and the script does not know the graph, so a BLOCKED task stops the loop (no skip-ahead); all agents share one working tree, so no isolation: 'worktree'.
DD9 — implement-orchestrator agent retired; the four phase agents survive. The inline-role-switch orchestrator-agent is deleted — its loop is implement-loop.js now. implementer / spec-reviewer / quality-reviewer / tester survive as the agent-types the script dispatches; their "phase reference, not separately dispatched" notes are flipped to "dispatched as a workflow agent() call". The carrier contract, sub-status/re-loop logic, BLOCKED.md template, stats schema, and end-report shape relocated into the script (the single source).
DD10 — mini-mode on the substrate. The tdd/debug GREEN side runs as implement-loop mode: "mini" (same carrier as before).
DD11 — interactivity boundary preserved. specify and brainstorm stay prose + interactive — their oracle is human intent and needs a human in the loop, which a run-to-completion workflow cannot host. Only the autonomous/mechanical loops moved.
DD12 — try-and-error deferred. Documented as the fourth taxonomy path but out of scope: its attempt tail is structurally unbounded and its budget is a magic number the selector cannot derive.
DD13 — co-location for regression visibility (acceptance #6). The boss selector arm names its executor (../implement "The compiler-driven arm" + compiler-driven-edit) and implement/SKILL.md names the boss selector arm back — a bidirectional cross-reference, so a future edit re-routing the light path back through the full loop changes both anchors and is a visible regression.

One deliberate deviation from the issue's literal text

The issue's taxonomy lists the compiler-driven hole-bounce as → specify. I split it: a hole that forces a design choice → specify, a hole that turns out to be test-specifiable new behaviour → tdd (RED-first). Reason: the straddle rule (DD2) routes new behaviour to tdd/spec; bouncing test-specifiable new behaviour to the heavy specify would re-create exactly the over-routing #7 exists to kill. A regression still bounces to debug. (Surfaced by the adversarial verification pass, lens D3.)

Validation

Both workflow scripts syntax-checked (node --check via the runtime's async-wrapper); install wiring exercised (symlinks created and discovered).
Adversarial 9-agent read-only verification: PASS on all six acceptance criteria + dangling-reference sweep; two CONCERNs (a residual stale orchestrator-agent line in implementer.md, and the specify/tdd coherence gap above) were fixed and re-aligned across all docs.
Honest limitation: the skills repo is not itself a pipeline target (no build/test command, no plan), so the scripts are shipped but not exercised end-to-end here — same status as every other plugin artefact, exercised in a downstream target project.

Acceptance checklist 1–6 all satisfied; non-goals (specify/brainstorm stay prose; try-and-error deferred; closes #N / standing-reading / main-sacrosanct unchanged) respected.

## Design decisions — #7 implementation (full Part A + Part B, single pass) Implemented directly against the skill/agent/doc surface (this is the meta-repo that *defines* the pipeline; it does not dogfood its own `specify → planner → implement`, so the change lands as a direct commit, per the user's instruction to use none of the plugin's own skills for the work). Every load-bearing decision below is recorded so a future reader can see *why*, not just *what*. ### Part A — verification-keyed selector - **DD1 — ordered cascade, first match wins.** `boss/SKILL.md` "Entry-path reflection" replaces the three-way *design line* with an ordered cascade that puts a verification/enumeration axis ahead of the settled-vs-fork question. Order: `observed bug → debug` · `forces a design choice → brainstorm` · `type/signature edit at a def, propagating mechanically → compiler-driven` · `new behaviour as one assertion → tdd` · `else → spec-driven`. Each lighter arm carries a **positive** trigger matched by signature; the prose twice rejects reach-by-elimination. - **DD2 — straddle rule as a *rule*, not an example.** "Add an enum variant" is decided by what the edit *encodes*: mechanical/forwarding (type checker enumerates the sites, behaviour preserved) → `compiler-driven`; encodes new behaviour (new code path, new observable output) → `tdd`/`spec-driven`. Doubt = the change carries behaviour → route **up**. - **DD3 — observe-then-bounce.** Entry on the observable/syntactic trigger; a **real build + suite run** is the oracle, not an ex-ante "this is behaviour-preserving" guess. Done-signal = **clean build AND suite green *unchanged*** (no test added/removed/weakened). A mis-routed behaviour change fails the post-condition and bounces instead of shipping green-but-wrong. - **DD4 — the executor is the elevated inline carve-out, not a heavy new skill.** Per the issue's "the largest concrete win is small". The existing `implement` "trivial mechanical edits … without dispatch" carve-out got a positive selector arm + the explicit done-signal. This is *why Part A alone already yields a reachable AND economical light path* — the arm routes to a path that bypasses the full per-task loop, not into it. ### Part B — Workflow substrate - **DD5 — delivery & discovery.** Shipped executable Workflow scripts live under `<skill>/workflows/` (`implement/workflows/implement-loop.js`, `compiler-driven-edit.js`). `install.sh` symlinks each `*.js` into the flat `~/.claude/workflows/` (where the Workflow tool resolves named workflows); `uninstall.sh` removes them. Same structural binding as agents. - **DD6 — per-phase fresh-context model.** On the substrate the three per-task phases become **separate `agent()` calls** (`implementer` → `spec-reviewer` → `quality-reviewer`), with the working-tree diff + task text as the shared medium and the script threading a reviewer's findings back into a repair dispatch. This *strengthens* the fresh-eyes property the review phases already wanted (structurally enforced, not a mindset switch) and preserves context-offload (per-task chatter stays inside the workflow's agent contexts). - **DD7 — file mutations stay in agents; the script is pure orchestration.** Workflow scripts have no fs/shell of their own, so every working-tree mutation (code, `stats.json`, `BLOCKED.md`) happens inside an `agent()` call; routing keys on the structured verdict each agent reports (which encodes the real build/test outcome). - **DD8 — sequential tasks, shared tree, no worktree isolation.** Plan tasks carry implicit ordering dependencies and the script does not know the graph, so a `BLOCKED` task stops the loop (no skip-ahead); all agents share one working tree, so no `isolation: 'worktree'`. - **DD9 — `implement-orchestrator` agent retired; the four phase agents survive.** The inline-role-switch orchestrator-agent is deleted — its loop *is* `implement-loop.js` now. `implementer` / `spec-reviewer` / `quality-reviewer` / `tester` survive as the agent-types the script dispatches; their "phase reference, not separately dispatched" notes are flipped to "dispatched as a workflow `agent()` call". The carrier contract, sub-status/re-loop logic, `BLOCKED.md` template, stats schema, and end-report shape relocated into the script (the single source). - **DD10 — mini-mode on the substrate.** The `tdd`/`debug` GREEN side runs as `implement-loop` `mode: "mini"` (same carrier as before). - **DD11 — interactivity boundary preserved.** `specify` and `brainstorm` stay prose + interactive — their oracle is human intent and needs a human in the loop, which a run-to-completion workflow cannot host. Only the autonomous/mechanical loops moved. - **DD12 — try-and-error deferred.** Documented as the fourth taxonomy path but out of scope: its attempt tail is structurally unbounded and its budget is a magic number the selector cannot derive. - **DD13 — co-location for regression visibility (acceptance #6).** The `boss` selector arm names its executor (`../implement` "The compiler-driven arm" + `compiler-driven-edit`) **and** `implement/SKILL.md` names the `boss` selector arm back — a bidirectional cross-reference, so a future edit re-routing the light path back through the full loop changes both anchors and is a visible regression. ### One deliberate deviation from the issue's literal text The issue's taxonomy lists the compiler-driven hole-bounce as `→ specify`. I split it: a hole that forces a **design choice → `specify`**, a hole that turns out to be **test-specifiable new behaviour → `tdd`** (RED-first). Reason: the straddle rule (DD2) routes new behaviour to `tdd`/`spec`; bouncing test-specifiable new behaviour to the *heavy* `specify` would re-create exactly the over-routing #7 exists to kill. A regression still bounces to `debug`. (Surfaced by the adversarial verification pass, lens D3.) ### Validation - Both workflow scripts syntax-checked (`node --check` via the runtime's async-wrapper); install wiring exercised (symlinks created and discovered). - Adversarial 9-agent read-only verification: **PASS on all six acceptance criteria** + dangling-reference sweep; two CONCERNs (a residual stale `orchestrator-agent` line in `implementer.md`, and the specify/tdd coherence gap above) were fixed and re-aligned across all docs. - Honest limitation: the skills repo is not itself a pipeline target (no build/test command, no plan), so the scripts are **shipped but not exercised end-to-end here** — same status as every other plugin artefact, exercised in a downstream target project. Acceptance checklist 1–6 all satisfied; non-goals (specify/brainstorm stay prose; try-and-error deferred; `closes #N` / standing-reading / main-sacrosanct unchanged) respected.

Brummel referenced this issue from a commit

2026-06-18 12:01:33 +02:00

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

Brummel closed this issue

2026-06-18 12:01:33 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Brummel/Skills#7