Exemptions are declarations — and a stale one is reported
data-qa-allow-overflowThe failure it prevents
An element overflows its container on purpose, so someone adds a suppression. Two months later the design changes and it no longer overflows, but the suppression stays — silently disarming that check for whatever lands in that slot next, forever. Nobody notices, because a suppression that is doing nothing looks exactly like a suppression that is doing its job. The same rot lives in every stale eslint-disable and every allowlist entry nobody has revisited.
The prompt
Make every suppression in this project's design gate an explicit declaration in the artifact, and then add the inversion almost nobody builds: report the suppressions that have stopped suppressing anything.
**Three channels, all declarations, no heuristics.** A check must never guess that something is intentional by inspecting a border radius or a class name — guessing produces both false negatives and unexplained silence.
1. **In-markup, on the element.** `data-qa-allow-overflow="the mock bleeds off the bottom edge by design"` — the *value is the reason and it is required*. An attribute with an empty value is itself a FAIL ("an exemption with no reason is an exemption nobody can review").
2. **Component-level role marker.** Some components *are* the thing a check is looking for — a device-chrome mock is already a frame, so a "is this wrapped in the standard frame" check must leave it alone. Mark it once on the component (`data-qa-is-frame`) and have **both the source audit and the rendered audit read the same marker**, so the two halves of the gate cannot drift into disagreeing about what is exempt.
3. **Path allowlist for code you do not own.** Vendored, generated, or verbatim-ported directories: list the path prefixes in the contract with a reason per prefix. Findings inside them are **downgraded from FAIL to WARN, never dropped**, and the reason is baked into the finding text: `"vendored — fix upstream, do not patch here."` A rule broken inside vendored code is still on the live page; it just is not this repo's bug to fix, and hiding it entirely means nobody ever takes it back upstream.
**Every exemption is printed.** Emit each active one as a NOTE with its reason, so a reviewer reading the audit output sees the full list of things not being checked without opening a single file. Exemptions that are invisible in the report accumulate.
**Now the inversion — the part that makes this rare.** After each check runs, assert that each exemption is still doing work:
- An element declares `data-qa-allow-overflow` but nothing overflows → **report it**: "declares an overflow exemption but nothing runs past the box — remove the attribute so the check is live again."
- An allowlisted path produced zero findings this run → **report it**: the prefix may point at a directory that was deleted or renamed, in which case it is silently allowlisting nothing while looking like coverage.
- Any lint-disable comment your gate owns that suppresses a rule with no violations at that location → **report it** (most linters can be asked this directly; if yours cannot, run the rule twice, once with suppressions honoured and once without, and diff).
Severity for all three: WARN, not FAIL — a stale exemption is not broken output, it is a disarmed check. But it must be visible, because the cost is paid later and by someone else.
**Two rules for how exemptions get added.** Write both into the audit's own README. (a) An exemption is added in the artifact, by the person who knows why, in the same commit as the thing being exempted — never bolted onto the audit as a special case to turn a red build green. (b) A check that has grown more than a handful of exemptions is telling you the rule is wrong, not that the code is. Print the exemption count per check in the summary so that signal is visible.
**Hand back:** the three channels wired into the existing checks, the staleness pass, the NOTE inventory of every active exemption with its reason, and the current count per check. If any existing suppression in this repo has no reason attached, list them and ask me for the reasons rather than inventing them.What it produces
A declared-exemption model across the gate: a reason-carrying markup attribute, a shared component role marker read by both the source and rendered audits, a contract-held path allowlist that downgrades rather than drops — plus a staleness pass that reports exemptions no longer suppressing anything, and a NOTE inventory of every active exemption.
How you prove it works
Three deliberate states. (1) Put the overflow exemption attribute on an element that does not overflow — the audit must report the exemption as stale. (2) Take an element that legitimately overflows and is correctly exempted, remove the overflow but keep the attribute — same report; this is the real-world path and it is the one that rots. (3) Delete one prefix from the vendored allowlist and re-run: the findings inside that directory must flip from WARN to FAIL, proving the channel is wired to real findings and not silently dropping them. Also add the attribute with an empty value and confirm the audit fails on a reasonless exemption.