generate-tests

generate-tests

Generates tests under the base rules and this repo's overlay + manifest. Read all three before generating:

• ${CLAUDE_PLUGIN_ROOT}/rules/unit-testing.base.md
• .claude/coverage/refs/unit-testing.md (repo overlay)
• .claude/coverage/refs/coverage-manifest.yml (categories, exclusions, gate)

Preflight: is this repo on the current kit?

Run this before building the worklist, every time, whether or not anyone mentioned an upgrade:

python .claude/coverage/tools/coverage-gate.py \
  --manifest .claude/coverage/refs/coverage-manifest.yml --print-kit-drift

Any state other than current means the repo has not been reconciled against today's rules, and a backfill is the worst moment to discover that: a pass run on superseded mechanics wastes every token it spends. Consult ${CLAUDE_PLUGIN_ROOT}/MIGRATIONS.md ("Preflight") and split what you find:

• auto entries governing how THIS pass runs (refresh the .claude/coverage/tools/ copies, the fan-out contract, frozen-bug recording): apply them now, silently, and note them in the closing summary.
• sign-off entries (anything that moves scope, the denominator, or the floor): report them in one line and leave them alone. Re-scoping mid-backfill moves the worklist under your own feet. coverage-redo is what applies them; say so and carry on with the pass as scoped today.

If the state is current, say nothing and continue.

Build the full worklist first — then cover ALL of it (do not stop early)

The scope of a backfill pass is the entire testable set the manifest defines, not a handful of "priority" files. Before writing any test, enumerate that set explicitly from the manifest and write it down as a checklist. The testable set is:

1. Every file matched by a category_map target category and not matched by an exclusions pattern (the genuine unit-scope files), AND
2. Every carve-out method on an exclusion entry: the structured carve_outs: list (each { method, lines, testable }), or the legacy CARVE-OUT: MethodA, MethodB prose in reason on older manifests. These are the thin pure/decision slices of god-classes (the UserService pattern): testable units even though their file is integration-scope, and a DbContext-injected service is tested by backing the context with the EF in-memory / SQLite provider. Init recorded them precisely so this step covers them; the file's excluded_rest says what stays out of scope.