Test cleanup

Current maturity

Test cleanup is currently a guided recurring-improvement prototype. The published runbook checks repository access and emits a synthetic scheduled-status report. It does not yet find skipped or decorative tests, edit the test suite, create a branch, or open a pull or merge request.

Intended goal

The mature workflow should remove bounded test-suite friction without hiding real failures. Good candidates include tautological assertions, obsolete skips, one flaky timing dependency, duplicated setup, or a small fixture problem that prevents useful behavior from being tested.

Cleanup must preserve or strengthen evidence. Deleting a failing test, weakening an assertion, increasing a timeout blindly, or marking a test skipped does not count as improvement.

Planned proposal boundary

A future run should start from current test-audit evidence, reproduce the candidate, establish the existing runnable baseline, and select one coherent repair. Changes should stay inside tests and test-only helpers unless production behavior needs an owner decision. The proposal should explain the original weakness, exact test semantics after the change, and commands used to verify determinism.

Human review boundary

Test behavior can encode product contracts that are not obvious from the code. A qualified reviewer must confirm that the repaired assertion or fixture still represents intended behavior. Guard should leave every review request open and rerun the relevant tests before proposing it.

What you can do now

Use the job only as a scheduling and access demonstration. Use Test quality to identify actual skipped, decorative, flaky, or hard-to-run evidence, then resolve one candidate through the repository’s normal review workflow.