April 7 feels like the moment I stopped just adding things and started asking what I could actually prove.
The commit that stands out most to me in the whole history is 8b09635, “Ship verified public release sync.” Not because it is the biggest single feature, but because it changes the repo’s posture.
Before that, A11Y Cat already had a lot of visible functionality. After that commit, it starts looking like a project that wants to defend its own claims.
This one change drops in a lot at once: package.json, Playwright config, node tests, linting, docs checks, supported-environment docs, manual accessibility checklist, real-axe verification docs, a local assistant backend, fixtures, release-bundle tests, and a much more explicit public README. It is hard to overstate how different that makes the repo feel.
I do not read this as a tidy greenfield engineering plan. It feels more like a recognition point. The tool had become broad enough that it needed a proper verification layer or the public story was going to drift away from the actual behavior.
The docs from this stage are especially telling. SUPPORTED_ENVIRONMENTS.md is not a brag sheet. It is a boundary document. The README starts distinguishing what is strongest on desktop Chromium, what is optional, what is still not proven, and what broader rollout would overstate. That tone is very different from a typical early project README. It sounds like someone who has started to feel the cost of being vague.
The test setup reflects the same change. Instead of one vague promise that the tool works, the repo starts carrying representative pages, command fixtures, real-axe fixtures, release-bundle checks, UI contrast checks, local-assistant behavior tests, and cross-browser smoke coverage. It is still not perfect or complete, but it is clearly trying to replace wishful confidence with executable evidence.
This is also where the product starts to split into named verification concerns. There are docs checks. There are syntax checks. There are build checks. There are browser suites. There are node tests. There are public-surface alignment passes. In other words, the project is no longer assuming one kind of test can stand in for all the others.
I think this phase is where the builder’s standards become easier to trust. Not because the code suddenly becomes flawless, but because the repo starts documenting its own limits and checking its own outputs in a much more disciplined way.
There is a funny side effect here too. Once you make a project verifiable, it also becomes easier to see how much of it is still messy. The later April history is full of hardening, alignment, stabilization, and evidence work precisely because the new discipline starts exposing weak spots. That is not a failure of the phase. That is what good verification does.
Visual evidence
This phase is mostly about tests, fixtures, docs, and release discipline, but I was able to reconstruct the public site and a mounted panel from the historical 8b09635 state:
What I was really learning here
I was learning that a feature-rich tool can still be loose and under-proved. The only way out of that is to build verification and boundary language into the project itself, not keep them in my head.
Evidence
- Commits:
8b09635– verified public release sync402eeab– public surfaces and verification state synced2750b83– public-site claims aligned with verified boundaryf274578– agent regression coverage and release integrity hardening
- Files:
../../package.json../../playwright.config.js../../SUPPORTED_ENVIRONMENTS.md../../MANUAL_ACCESSIBILITY_CHECKLIST.md../../REAL_AXE_VERIFICATION.md../../tests/
- Visuals:
phase-03-reconstructed-verified-bookmarklet/landing-page.pngandphase-03-reconstructed-verified-bookmarklet/panel-on-command-fixture.png– direct historical screenshots captured from a checked-out worktree at8b09635
- Inference:
- Calling this a “recognition point” is an inference from the density and type of files added in
8b09635.
- Calling this a “recognition point” is an inference from the density and type of files added in
