Quality floor

A floor is the short list of things a change may never do, plus the numbers the project refuses to get worse at. It lives in CONSTRAINTS.md at the repo root and every row names the command that produces the verdict. A dimension with a number and no command is an aspiration, not a constraint.

Write the floor (once per project, 15 minutes)

1. Read what already gates the repo: pre-commit hook, CI jobs, lint/typecheck/test commands. A repo with no guardrail at all is itself the first finding.
2. Write CONSTRAINTS.md with two parts:
   • Floor (no numbers, absolute): no new suppression comments (@ts-ignore, eslint-disable, # noqa, # type: ignore, #pragma warning disable); no unimplemented stubs (TODO: implement, NotImplementedError, empty handlers); no skipped or deleted tests without a reason in the commit message; no secrets in source; this file is never weakened to make a change pass.
   • Ratchet (numbers with commands): coverage, type errors, lint warnings, bundle size, p95 latency. Record where the project is today; the rule is "refuse to get worse".
3. Commit it beside the code. Tightening a number is silent; loosening one is a commit that says why, in the message.

Check a diff against the floor (every review, every handoff)

Run from the project root (<skill-dir> = where this skill is installed):

python3 <skill-dir>/scripts/floor_check.py --base origin/main          # exit 1 on any floor violation in the diff
python3 <skill-dir>/scripts/floor_check.py --base HEAD~1 --json        # machine-readable
python3 <skill-dir>/scripts/floor_check.py --base origin/main --working # include uncommitted changes

The script reads git diff <base>...HEAD and reports, with file:line: added suppression comments, added skip markers (.skip(, xit(, @pytest.mark.skip, [Ignore]), deleted test files, added stub markers, and secret-shaped strings. It does not judge style; that is code-review-discipline's job.

Step budget (every commit, every PR)

Small steps make review real: Google eng-practices call ~100 lines a reasonable change and ~1000 too large; SmartBear's Cisco study found defect finding drops past 200–400 lines reviewed at once. Budget: a commit adds ≤50 logic lines, a PR changes ≤400 lines.

python3 <skill-dir>/scripts/diff_budget.py                 # uncommitted step (incl. new untracked files) vs HEAD
python3 <skill-dir>/scripts/diff_budget.py --base HEAD~1    # the commit just made
python3 <skill-dir>/scripts/diff_budget.py --pr origin/main # whole branch, PR budget

Exit 1 = over. Not counted for a step: tests, docs, config, generated code, lockfiles, deletions, renames. It warns, it does not block: a migration, a mass rename or a new tool may exceed it — split, or give the reason in the commit message. Self-test: bash <skill-dir>/scripts/test_diff_budget.sh.

The five loosening moves (say them by name in review)

1. Threshold moved — a number in CONSTRAINTS.md or a config went down.
2. Test got easier — an assertion weakened, a fixture shrunk, a case removed.
3. Checker silenced — suppression comment, rule disabled, file excluded.
4. Work unfinished — stub, TODO, feature flag defaulting the new path off "for now".
5. Exception appeared — an allowlist entry, a special case in the gate itself.

Any of these in a diff is reported as a finding even when tests are green. The author may keep it, with the reason written in the commit message; the reviewer never removes the finding to make the review pass.

Red flags

• "I'll re-enable that check after the release."
• Coverage config edited in the same commit as a feature.
• A skipped test with no linked issue.
• The floor file edited in a feature branch.

Recovery

Distilled from addyosmani/agent-skills constraint-driven-development (MIT © Addy Osmani) @ bcab6a1 (2026-09-22). The upstream floor-guard sketch (a reference doc there) became a runnable script here, scripts/floor_check.py. See SOURCES.md.