ratchet-ops

Read the JSON snapshot first and print every error-level row, then reproduce one row live by invoking the runner's blocking tier in quiet mode. Classify the failure as a real regression, pre-existing debt, or environment artifact before editing anything, and verify with the pasted exit code.

Any improvement recorded as shipped must add, in the same change, an enforcement artifact that would fail if it regressed. Depending on the improvement, that is a declared-requirement header, a liveness header, a policy-check row with a counter function, or an INFO row.

Make a row blocking only when a failure is unambiguously wrong, such as a dropped key, banned token, or budget breach. If the right response is an operator judgment call, use an INFO row so people are not trained to silence the lane.

Only after working the narrowest-control ladder top-down: fix the regression, add a documented KNOWN_GAPS-style exemption, demote to INFO, then delete as a last resort. Deleting requires stating why the incident class the row guards can no longer recur.

Rows landed against pre-existing debt are expected to fail initially; document this in the row's paragraph and track genuine offenders in a KNOWN_GAPS-style array beside the counter function. Also check for environment artifacts like a stale checkout before concluding anything.