If you suppress a finding, should it still count against the grade?

[dheerajjha]

#203 adds inline suppression:

mcp_session_id = req.headers["X-Sid"]  # mcp-migrate: ignore[R001] -- proxy shim, not MCP session state

The implementation is good and I'm going to merge it. The design question underneath it is not settled, and it's the interesting part.

The question

Does a suppressed finding still count against the grade?

@ankitverma31 argued no, and put it plainly: a suppression that still costs you the grade isn't a suppression. Your only remaining move is to stop running the tool, which is exactly the outcome the feature exists to prevent.

I find that convincing. I also think it has a cost that's easy to wave past: the grade becomes partly self-reported. A project can suppress its way to an A. The badge on their README then means "an A, according to a rule set the project was allowed to edit."

What the PR does about that

Three things, and they're the reason I'm not blocking:

• the suppressed count always prints — not behind a flag
• --show-suppressions lists every one with file, rule and reason
• unused suppressions are reported, so stale ones can't quietly accumulate

That's the same standard #101 applied to stale badges: the claim may be wrong, but it can't be quietly wrong.

Where I'm genuinely unsure

Is "visible in the terminal" enough, when the badge is the thing people actually see?

Someone reading a README sees MCP 2026-07-28: A. They don't see the suppression count. The audit trail exists exactly where the person being reassured isn't looking.

Options I can think of, none of which I'm sure about:

1. Leave it. The count prints, --json carries it, anyone who cares can look. Badges are always a summary.
2. Suppressions cost nothing, but the badge changes. A distinct badge — or a suffix — when suppressions are active. Honest, and possibly so ugly nobody uses the feature.
3. A cap. Suppressions are free up to some number or share of findings, past which the grade is withheld. Principled-sounding, and I suspect arbitrary in practice.
4. Suppressed findings still count. Rejected above, but worth someone arguing for properly rather than me strawmanning it.

Also open

Should a suppression expire? A # mcp-migrate: ignore[R001] until=2026-12-01 would stop "temporary" suppressions becoming permanent, which is the normal fate of these things in every linter I've used. It also adds a concept, and concepts are how config formats rot.

If you use a linter with suppression you've formed an opinion about this whether or not you meant to. That opinion is what I want here.

[dheerajjha]

#203 is merged. So the answer to the title question is now shipped behaviour, not a proposal: a suppressed finding does not count against the grade. @ankitverma31's argument carried it, and the three audit affordances are all in — the count always prints, --show-suppressions lists each with file/rule/reason, and unused directives are reported in --json as well as on the console.

I said above I was genuinely unsure whether "visible in the terminal" is enough when the badge is what people see. I went and checked instead of continuing to wonder, and the answer is worse than I framed it.

The audit trail stops at the terminal

grep -rn suppress scripts/ returns nothing. Not one of render_badges.py, render_board.py, validate_registry.py or ecosystem_scan.py reads suppressed or unused_suppressions. And registry/schema.yaml has no field for them — a board entry carries grade, score, checked_with, spec, and nothing that could record that the score was reached with findings silenced.

So concretely, today: a project can suppress findings, take the improved grade, run mcp-migrate entry, and submit a board entry in which no artifact anywhere records that a suppression was involved. Not the badge, not the registry file, not the board page. The audit trail I called sufficient exists exclusively in a terminal session nobody else will ever run.

That isn't an argument against the design — I still think option 4 (suppressed findings still count) is wrong for the reason @ankitverma31 gave. It's an argument that option 1 ("leave it, anyone who cares can look") is not currently available, because there is nothing to look at outside the terminal. Option 1 is a position you can only hold after building the thing that makes it true.

What I'd narrow this to

Two questions, and the second is the one I'd like other people on:

1. Should mcp-migrate entry refuse to generate an entry from a suppressed scan, or emit the count into the YAML? This one I think has an obvious answer — emit it — and it needs a schema field, so it wants doing deliberately rather than by whoever gets there first.

2. Does the badge change? This is the real disagreement and I've stopped trusting my instinct on it. A suffix is honest and probably ugly enough that nobody adopts the feature, which would make the honesty worthless. A cap (option 3) still smells arbitrary to me — but "arbitrary" is what I said about RULE_CAP in Two servers, very different amounts of work, same grade C — what is the letter actually measuring? #211, and the answer there was that a defensible arbitrary number beats an undefensible silent one.

Nobody has argued option 4 properly yet, and I'd still rather read that than have it stay strawmanned by me.

Worth stating plainly since it cuts against my own feature: the board currently has zero entries submitted by their own maintainers (submitted_by: owner is 0 of 16). Every grade on it was produced by me running the tool. Suppression doesn't change that, but it does mean the thing I'd be protecting with a badge suffix is not yet a thing anyone outside this repo relies on.