Summary
The baseline suppresses 233 findings and reports only that count. There is no aging, no triage state, and no indication of whether anyone has ever looked at them — so a baseline created as "we'll get to these" silently becomes permanent amnesty.
Observed
📋 233 pre-existing finding(s) suppressed by .docguard.baseline.json (--no-baseline to show)
That is the entire lifecycle signal. The same line will print identically in two years.
Why it matters
The baseline is the right design — it is what makes adoption on a mature repo possible at all, and it is why this project could turn DocGuard on as a fail-closed gate without a six-month cleanup first. But a baseline is a loan, and the tool currently reports the principal without ever mentioning the interest.
Concretely, in this repo: 233 suppressed findings against 1870 active checks. Nobody on the team could tell you today what is in there, whether any of it is severe, or whether it has grown. --no-baseline dumps all 233 at once, which is not triage — it's a wall.
Proposal
- Age the baseline. Stamp creation time per entry (and on the file), then report:
📋 233 suppressed by .docguard.baseline.json — created 187 days ago
8 HIGH · 41 MEDIUM · 184 LOW · 0 triaged · 0 resolved since creation
next: docguard baseline --triage --severity high # 8 findings
- Report drift in both directions. Entries whose underlying finding no longer reproduces are free wins — they should be reported and offered for removal, so the baseline shrinks on its own as unrelated work fixes things. Today a stale baseline entry is invisible and keeps suppressing nothing forever.
- Support per-entry triage state and a note (
accepted / deferred / wontfix + why + who). This turns the baseline from a blob into a record, and makes it reviewable in a PR.
- Optional budget: a config key like
baseline.maxAgeDays or baseline.maxEntries that warns when the debt grows rather than shrinks.
This pairs with the same request in websec-validator — a shared convention for baseline aging across your three tools would be a genuine differentiator, since almost nothing in this category treats suppression as a tracked liability.
Acceptance
- The baseline line reports age and severity composition, not only a count.
- Entries that no longer reproduce are surfaced for removal.
Summary
The baseline suppresses 233 findings and reports only that count. There is no aging, no triage state, and no indication of whether anyone has ever looked at them — so a baseline created as "we'll get to these" silently becomes permanent amnesty.
Observed
That is the entire lifecycle signal. The same line will print identically in two years.
Why it matters
The baseline is the right design — it is what makes adoption on a mature repo possible at all, and it is why this project could turn DocGuard on as a fail-closed gate without a six-month cleanup first. But a baseline is a loan, and the tool currently reports the principal without ever mentioning the interest.
Concretely, in this repo: 233 suppressed findings against 1870 active checks. Nobody on the team could tell you today what is in there, whether any of it is severe, or whether it has grown.
--no-baselinedumps all 233 at once, which is not triage — it's a wall.Proposal
accepted/deferred/wontfix+ why + who). This turns the baseline from a blob into a record, and makes it reviewable in a PR.baseline.maxAgeDaysorbaseline.maxEntriesthat warns when the debt grows rather than shrinks.This pairs with the same request in websec-validator — a shared convention for baseline aging across your three tools would be a genuine differentiator, since almost nothing in this category treats suppression as a tracked liability.
Acceptance