This is where the project starts moving from “run a scan now” toward “use the tool as part of an ongoing review process.”
There is a stage in browser tooling where one-off scans stop being enough. You want to compare. You want to annotate. You want to know what changed. You want to keep local notes about whether a finding was reviewed, fixed, or still open. That is the point where the tool starts behaving less like a utility and more like a working product.
A11Y Cat hits that stage in April.
There is work on recurring issue groups, history filters, deterministic sort behavior, scoped baseline selection, comparison provenance, local issue annotations, and identity-safe persistence. The extension gets local issue statuses like open, needs review, false positive, accepted temporarily, and fixed pending retest. The history and export layers get more careful about stable issue identity and about not pretending a comparison baseline exists when the provenance is weak.
I think the “scoped baseline” work is especially important. A weaker version of this feature would just compare against the last scan globally and call it a day. The repo explicitly rejects that. Baseline selection needs to be scoped, provenance needs to travel through exports, and comparison sections should be omitted rather than guessed when attribution is incomplete. That is a much better product stance.
The local issue-state model is also interesting because the docs stay very clear about what it is not. It is not a shared workflow system. It is not centrally governed. It is not a multi-user approval layer. It is local to the browser profile. That kind of limit makes the feature easier to trust. It is not pretending to solve a bigger collaboration problem than it actually does.
I also think this area shows the builder getting more aware of lifecycle pain. Once you can run scans repeatedly, the real annoyance is not producing one more result. It is tracking how today’s result relates to yesterday’s result and what a human already decided about it.
That is where a lot of tools quietly become more useful than their headline feature list suggests.
Visual evidence
There is no reliable repo-held screenshot in this series bundle that isolates the local issue-state and baseline-comparison UI directly. The nearest visible evidence is the extension scan-results surface that these local workflow features sit beside:
What I was really learning here
I was learning that scanning is only part of the work. The moment people start re-running checks and making decisions, the painful part shifts to continuity: what changed, what stayed, and what somebody already decided.
Evidence
- Commits:
fa4bfee– local issue-state model hardened with identity-safe persistence35526fa– scoped baseline subsystem with comparison provenance74a6c3candd044a9a– baseline selection and settings contracts fixedc5a5972– CSV export redesigned with workflow profiles
- Files:
../../src/runtime/modules/history-storage.js../../src/runtime/modules/exports.js../../src/runtime/modules/scan-engine.js../../docs/SUBSYSTEM_SEAMS.md../../tests/node/runtime-modules.test.js../../README.md
