v3.3.0 — add test-and-verify, and have execute-plan delegate to it

.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "code-idea",
-  "version": "3.2.0",
+  "version": "3.3.0",
   "description": "Turn a plan or idea into an AI-coding-agent-ready docs set, then plan and build the modules it defines.",
   "author": { "name": "Melconcoast Inc" },
   "homepage": "https://github.com/melconcoast/code-idea#readme",

AGENTS.md

@@ -1,6 +1,6 @@
 # code-idea
 
-"Code this idea" — a Claude Code plugin that turns a plan into an AI-coding-agent-ready docs set, then plans and builds the modules it defines. There's no application code in this repo, only markdown. Three skills run in sequence: `scaffold` (`skills/scaffold/SKILL.md`) writes the docs set including `docs/development-roadmap.md`; `plan-module` (`skills/plan-module/SKILL.md`) turns one module of that roadmap into `docs/guides/feature_<module>_plan.md`; and `execute-plan` (`skills/execute-plan/SKILL.md`) builds that plan file task by task, writing real code and tests into the user's project. The chain is complete — no skill name is reserved-but-unbuilt any more.
+"Code this idea" — a Claude Code plugin that turns a plan into an AI-coding-agent-ready docs set, then plans and builds the modules it defines. There's no application code in this repo, only markdown. Four skills: three run in sequence — `scaffold` (`skills/scaffold/SKILL.md`) writes the docs set including `docs/development-roadmap.md`; `plan-module` (`skills/plan-module/SKILL.md`) turns one module of that roadmap into `docs/guides/feature_<module>_plan.md`; and `execute-plan` (`skills/execute-plan/SKILL.md`) builds that plan file task by task. The fourth, `test-and-verify` (`skills/test-and-verify/SKILL.md`), is a service the others call rather than a stage: it runs the tests, fixes what fails within a bounded loop, and returns a verdict. No skill name is reserved-but-unbuilt.
 
 ## Critical rules (read first)
 - **Confirmation must be explicit, never assumed from silence.** A fact that appears in a planning conversation because the assistant proposed it, or because it showed up in a prototype/demo (especially one shaped by the demo environment's own constraints), is NOT the same as something the user explicitly stated or confirmed. Step 2 of `skills/scaffold/SKILL.md` must apply the recommend-and-confirm pattern to both cases the same way — don't let "it's already in the conversation" substitute for a real confirmation.
@@ -16,6 +16,9 @@
 - **`plan-module` never overwrites a plan in flight.** A re-plan preserves every `[x]`, `[~]`, and `[-]` item with its annotation, plus the whole `## Progress Log`. A re-cut task becomes `[~]` with a reason; it never reverts to `[ ]`, which would silently un-do finished work. S48 is the check.
 - **No implementation or test code in a plan file.** *Details* names endpoints, tables, and data shapes; scenarios describe observable behavior in plain English. Writing the code or the assertions decides at plan time what `execute-plan` exists to decide. S47 is the check.
 - **Three skills write to the docs set, and their fields are disjoint.** `scaffold` owns the roadmap's *format*, `plan-module` owns each sub-module's `**Tasks:**` pointer, and `execute-plan` owns `Status:` write-back as phases close. Nothing else updates a roadmap status, so an `execute-plan` that skips it sends the next `plan-module` run at a module that is already built. Never let one skill start writing another's field. S67 is the check.
+- **`test-and-verify` never writes a plan file.** Not a glyph, not a count, not the Progress Log. It returns a verdict; `execute-plan` writes it down. Two writers on one file is how a plan stops being trustworthy, and it's the same disjoint-fields rule the roadmap follows. S89 is the check.
+- **The three-attempt circuit breaker is a ceiling, not a suggestion.** `execute-plan` must not re-invoke `test-and-verify` to get past a failing verdict — that's the same attempt with the safety removed. A red verdict closes nothing and stops the loop. S90 is the check.
+- **`skills/test-and-verify/references/test-commands.md` is expected to age**, like `recommendation-heuristics.md`. Runners and flags shift. A command read out of the project always beats one read out of that table — it's a fallback for when the project is silent, never an override.
 - **`skills/execute-plan/references/progress-updates.md` is subordinate to the two specs it applies.** The checkbox vocabulary and counting rules live in `plan-module`'s `plan-template.md`; the roadmap `Status` vocabulary lives in `scaffold`'s `templates.md`. That file says only how to *apply* them during execution and must never become a third source of truth — if it disagrees with either, it is the bug. S66 is the check.
 - **`[x]` means verified, never merely written.** `execute-plan` may not close an item on inspection, on intent, or on a passing type-check — a test covering that scenario has to have actually run and been read. Behavior that genuinely can't be checked in the environment is `[~]` with what would verify it, never `[x]` on faith. S68 is the check.
 - **A deferred decision is not a placeholder.** "Undecided as of [date], do X meanwhile" is required output when the user defers; `[Project name]` and `TODO` are not. Don't let the no-placeholder rule suppress the pending-decision feature.
@@ -38,4 +41,6 @@
 - `skills/plan-module/references/scenario-writing.md` — what makes a plain-English test scenario checkable
 - `skills/execute-plan/references/verification.md` — finding or bootstrapping a test runner, and what counts as verified
 - `skills/execute-plan/references/progress-updates.md` — the plan-file and roadmap writes execution makes
+- `skills/test-and-verify/references/test-commands.md` — finding and scoping the test command; expected to age
+- `skills/test-and-verify/references/remediation.md` — app-bug vs test-bug, the circuit breaker, and the report formats
 - `examples/test-scenarios.md` — the scenarios a change must be checked against

CHANGELOG.md

@@ -1,5 +1,66 @@
 # Changelog
 
+## [3.3.0] — 2026-08-22
+
+Adds a fourth skill, `test-and-verify`. The first three are a pipeline; this one is a service the
+others call. `execute-plan` no longer runs tests itself — it hands each task and each `Task X.V` gate
+to this skill and acts on the verdict.
+
+Additive for anyone on 3.2.0. No generated file changes shape, and `execute-plan` behaves the same
+way from the outside — it just stops duplicating a job that now has an owner.
+
+### Added
+- **`test-and-verify`** (`skills/test-and-verify/SKILL.md`) — finds the project's test command, runs
+  the tests relevant to the work, **reads the real output rather than the exit code**, and fixes what
+  fails in a bounded diagnose-fix-rerun loop. Every failure gets classified as an *application* bug or
+  a *test* bug before anything is edited, because picking wrong papers over a real defect or bends
+  correct code to satisfy a broken assertion. Invoked as `/code-idea:test-and-verify`, or triggered by
+  "run the tests", "verify this", "check the tests pass", "fix the failing tests", "why is this test
+  failing".
+- **A three-attempt circuit breaker.** Past three remediation attempts the diagnosis is usually what
+  was wrong rather than the fix, so further attempts widen the diff on a false premise. It stops and
+  hands back what failed, what it tried, and what it ruled out. `execute-plan` may not re-invoke it to
+  get around a red verdict — that is the same attempt with the safety removed.
+- **Two boundaries that make it safe to call automatically.** It never writes to a plan file — it
+  returns a verdict and `execute-plan` marks the boxes, because two writers on one plan file is how a
+  plan stops being trustworthy. And it never weakens a test to reach green: no deleted assertions,
+  loosened matchers, added skips, widened timeouts, or expected values rewritten to match whatever the
+  code currently produces. If the honest outcome is "still failing", that is what it reports.
+- **Gate runs widen automatically.** At a `Task X.V` gate it runs the whole module's suite plus the
+  project's type-checker and linter. If the project has neither, it says so — an omitted line reads as
+  a check that passed.
+- `skills/test-and-verify/references/test-commands.md` — the discovery order, targeted-versus-whole-suite
+  invocation per ecosystem, and the type-check and lint commands a gate adds. Includes two traps that
+  cost real time: `npm test -- <path>` misroutes when the `test` script is a chain, and a filter
+  matching nothing usually exits 0. **This file is expected to age**, like `recommendation-heuristics.md`.
+- `skills/test-and-verify/references/remediation.md` — application-bug versus test-bug diagnosis, what
+  a targeted fix may touch, the circuit breaker, and the exact pass and fail report formats.
+- `examples/test-scenarios.md` — Fixture H (a suite with one genuine bug) and S85–S96, covering
+  diagnosis, the no-op on an already-green suite, the chained-script and empty-filter traps, the
+  breaker, test-weakening, the missing-checks report, the plan-file boundary, and the now four-way
+  trigger boundary.
+
+### Changed
+- **Fixture G is now explicitly the false-closure fixture, and Fixture I is the default for execution
+  scenarios.** Fixture G's plan called Phase 1 closed while only one of its tasks had ever been built,
+  so every `execute-plan` run against it correctly stopped at Step 0 and never reached the behavior
+  the scenario was actually testing. That inconsistency is exactly what S84 needs, so it stays — but
+  the sixteen other scenarios keyed to it now name Fixture I, whose closed work is real.
+- **`execute-plan` delegates verification instead of doing it.** Step 3 hands the run to
+  `test-and-verify` and takes its verdict as given; Step 5 hands it the gate. It only runs tests inline
+  if that skill isn't available, and then by its rules.
+- **Test-command discovery has one owner now.** It lived in `execute-plan`'s `verification.md` and
+  would have been duplicated by the new skill. `verification.md` keeps what is genuinely
+  `execute-plan`'s — *bootstrapping* a runner when the project has none, which is a project decision
+  tied to the stack the docs already chose, not a remediation step — and defers the search itself.
+  Its "what counts as green" section narrowed to the question this skill actually owns: not whether
+  the run passed, but whether that pass closes a checkbox.
+
+### Upgrading
+Nothing to do. `test-and-verify` appears once the plugin updates, and `execute-plan` starts using it
+automatically. If you invoke `execute-plan` in an environment where the new skill is unavailable, it
+falls back to running the tests inline.
+
 ## [3.2.0] — 2026-08-22
 
 Adds the plugin's third and final skill, `execute-plan`, and with it the chain closes: `scaffold`

CONTRIBUTING.md

@@ -5,10 +5,11 @@ Thanks for considering a contribution. This plugin is small on purpose — most
 ## Where things live
 
 The repo is a Claude Code plugin. Each skill owns a directory under `skills/`, holding its own
-`SKILL.md` and its own `references/`. Three skills ship — `scaffold`, `plan-module`, and
-`execute-plan` — and they run in that order. No skill name is reserved-but-unbuilt any more; if you
-propose a fourth, it gets no directory until it is written, because git can't track an empty directory
-and a stub `SKILL.md` registers a broken skill for everyone.
+`SKILL.md` and its own `references/`. Four skills ship. Three run in sequence — `scaffold`,
+`plan-module`, `execute-plan` — and the fourth, `test-and-verify`, is a service the others call rather
+than a stage of its own. No skill name is reserved-but-unbuilt; if you propose a fifth, it gets no
+directory until it is written, because git can't track an empty directory and a stub `SKILL.md`
+registers a broken skill for everyone.
 
 - **`.claude-plugin/plugin.json`** and **`marketplace.json`** — the plugin manifest, and the entry that makes this repo its own marketplace (named `melconcoast`, after the owner, so installs read `code-idea@melconcoast`). The version lives in `plugin.json` only and must match the release tag; CI enforces it.
 - **`skills/scaffold/SKILL.md`** — the workflow itself: when the skill triggers, how the interview works, how structure is decided, how content gets drafted and written. Changes here affect behavior directly, so keep edits scoped and explain the reasoning in the PR description.
@@ -22,6 +23,9 @@ and a stub `SKILL.md` registers a broken skill for everyone.
 - **`skills/execute-plan/SKILL.md`** — the micro-loop: how one task is selected, implemented, verified, and written back. It reads the plan file `plan-module` produced rather than restating that file's format, so a vocabulary or counting change belongs in `plan-module`'s `plan-template.md` first.
 - **`skills/execute-plan/references/verification.md`** — finding or bootstrapping a test runner, what counts as green, and what to do with a scenario that's wrong or can't be checked. Guidance on proving a task is done belongs here, not in the SKILL.md.
 - **`skills/execute-plan/references/progress-updates.md`** — every write execution makes to a plan file or the roadmap. **This file is deliberately subordinate**: the checkbox vocabulary and counting rules are specified in `plan-module`'s `plan-template.md`, and the roadmap `Status` vocabulary in `scaffold`'s `templates.md`. It may say how to apply them and nothing more — if it ever disagrees with either, it's the file that's wrong.
+- **`skills/test-and-verify/SKILL.md`** — running a suite, reading the output, and the bounded fix loop. It never writes a plan file; that's `execute-plan`'s alone, and a change here that starts editing plan state is a bug, not a feature.
+- **`skills/test-and-verify/references/test-commands.md`** — where the test command lives per ecosystem, targeted versus whole-suite runs, and the type-check and lint commands a gate adds. **This file is expected to age**, like the heuristics file — a stale runner or flag is a welcome PR, not a bug report.
+- **`skills/test-and-verify/references/remediation.md`** — telling an application bug from a test bug, what a targeted fix may touch, the three-attempt circuit breaker, and the pass/fail report formats. Guidance on *how to fix* belongs here; guidance on what "done" means belongs in `execute-plan`'s `verification.md`.
 - **`examples/`** — shared across every skill in the plugin, which is why it stays at the repo root rather than moving under `skills/scaffold/`.
 
 ## Reporting an outdated recommendation