coverage-redo

coverage-redo

Reconcile a repo that an EARLIER kit version already onboarded. It re-runs the classification against today's rules, corrects the existing manifest rather than replacing it, migrates it to the current schema, fills only the gaps in test coverage, and regenerates the report. It is the idempotent successor to coverage-init for repos that already have a manifest, tests, and a report.

It is also the kit-upgrade entry point. "The kit has new updates, review and apply them to this repo" is this skill, run as a version delta: step 1 works out which kit changes this repo has not picked up (from MIGRATIONS.md) and the rest of the steps apply them. There is no separate upgrade command and no per-feature request to make: every change since the repo's recorded kit_version: is in scope for one run.

Use coverage-init instead when there is NO manifest yet (greenfield). Use this skill when a manifest exists and may be stale, because the classification rules have improved since it was written (for example: a constructor-injected DbContext is now a testable seam, not an integration-scope exclusion; mixed files must be per-file structured carve-outs, not one folder glob).

Non-negotiables

These are what make a redo safe to run on a live repo:

1. Existing tests are kept intact and reused. Never delete, rewrite, or "regenerate" a test that already exists and passes. The backfill only ADDS tests for spots that are newly in scope and not already covered. A reclassification that would orphan an existing test is reported for a human to resolve, never actioned by deleting the test.
2. Correct the manifest, do not rewrite it. Preserve the human-curated content: the baseline, the gate thresholds, intentional gray-zone exclusions, and every carve-out that is still valid. Produce a reviewable DIFF of changes with a reason each, not a fresh file.
3. Migrate the schema. Convert legacy CARVE-OUT: prose to structured carve_outs:, split any carve-out-bearing folder glob or multi-file pattern into per-file entries (the gate warns on these), and recategorize stale cannot_test entries to the canonical natures, adding the now-required mitigation.
4. Never silently move the ratchet. Bringing newly-found testable code into scope grows the Adjusted denominator and can lower the recorded coverage. The re-baseline decision is explicit and human-gated (step 8). Lowering the floor is a reviewed change, never automatic.
5. Stop for human confirmation of the corrected manifest BEFORE generating any test (step 6). Generating tests off an unreviewed reclassification is exactly the mistake this skill exists to fix.