feat: accept a finding in the workflow it belongs to, with a stated reason

[bgard68]

A finding that is genuinely acceptable had nowhere to go. It reported forever, or the reader learned to ignore it.

This repository proved the point: its own accepted findings lived in a Dictionary inside a test file — invisible to anyone reading the workflow they were about, and useless to anybody else scanning their own repo.

permissions:
  # sentinel:accept GHA002 - deleting a workflow run has no narrower grant
  actions: write

Why in the workflow, not a config file

A separate file of rule/line/reason entries is the obvious design and the wrong one. Line numbers drift the moment anyone edits the workflow, the reason ends up far from what it explains, and the file outlives the code it was written about.

A comment is deleted by the same edit that deletes what it annotates, and a reviewer sees it appear in the diff beside what it waves away.

It also fits the constraints already in place: Sentinel is read-only and anonymous, so there is no account to store a decision against. It has to live in the repo it is already fetching.

Three refusals do the actual work

No reason, no acceptance. A directive with no stated reason is ignored and the finding still reports. A bare marker records that someone wanted the finding gone, not that anyone considered it — the mute button this exists instead of.

Matched on rule and line. Accepting one grant cannot quietly cover a second finding of the same rule elsewhere in the file.

A stale acceptance is itself reported. If someone accepts GHA002 on a line and later fixes the permission, that comment is now a claim sitting in the file that somebody considered a problem which is no longer there. It reads as considered when nothing considered it. Every suppression list accumulates these; reporting the rot is what stops it.

That last rule is this repository's own stated principle, previously enforced only by hand in a test file:

"An exception that no longer corresponds to a real finding is worse than no exception: it reads as considered when nothing considered it."

Nothing disappears

An accepted finding moves into Reviewed and accepted carrying its original severity and the stated reason. The summary shows both counts, so a suppressed Critical is quiet, never invisible.

The client separates the two kinds of acceptance, because they are different claims and only one of them can be wrong about the risk:

• required by an action — a documented fact, established by the rule
• accepted by author — a person's judgement, with their reason

The exemption table is now empty

prune-runs.yml states its own acceptance beside the grant, so RepositoryWorkflowsTests.Accepted holds nothing.

That test also stopped calling the rules directly. Doing so bypassed the service where acceptance is applied, which held this repository to a stricter standard than the tool applies to anyone else's. It now measures what the product actually reports — and fails on a stale or unexplained acceptance of its own.

Verification

322 backend tests and 28 frontend tests pass; both stacks build. Eight new tests cover the mechanism, each paired with what it must refuse: no reason, wrong rule, wrong line, still-valid, and outlived.

🤖 Generated with Claude Code

https://claude.ai/code/session_01N7HjzX5e8Wv7PKENDo2Uj7

---

Generated by Claude Code