This was one of those moments where the main limitation was not the audit logic. It was how the tool reached the page at all.
I still think the bookmarklet was a good place to start. But by April it is pretty obvious that it was no longer enough for the full job the project wanted to do.
The repo keeps circling the same problem in different forms: CSP, hostile CSS, page policies, injection friction, reliability on real sites. Those are not small edge cases if your whole delivery model depends on a page accepting an injected script from a host URL.
The project becomes much more explicit about that around April 8. There is a commit called “Harden bookmarklet: bundle axe-core, CSP-aware errors, docs, tests” (d82c03b). That is a very specific kind of improvement. It is not saying “the bookmarklet is perfect now.” It is saying “at minimum, the failure mode should be more honest, and the runtime should be less fragile where it can be.”
Bundling axe-core into the built bookmarklet helps. CSP-aware errors help. Tests help. But none of that removes the real boundary: if the page will not allow the bookmarklet host to load, there is no clever runtime trick that saves you from that.
I think this is why the later docs feel so careful about bookmarklet vs extension. The current README and SUPPORTED_ENVIRONMENTS.md do not treat them as equal paths. The bookmarklet is the lighter fallback for cooperative pages. The extension is the preferred path for hostile or CSP-locked pages. That is not marketing framing. That is a repo admitting what reality won.
The hostile CSS work is also part of this story. Once the tool is injected into pages with aggressive styling, even a mounted panel can become unreliable unless the host isolation is strong enough. So the repo starts testing not just “can I scan?” but “can the tool survive the page it landed in?” That is a different kind of product problem than early bookmarklet thinking.
I find this phase useful because it is where the repo starts treating delivery as a first-class engineering problem. Not an annoying wrapper around the real logic. A real problem in itself.
That shift makes a lot of later decisions make more sense. Once you accept that bookmarklet delivery has hard boundaries, the extension pivot stops looking like scope creep and starts looking like the tool following its own problem honestly.
Visual evidence
I could reconstruct the verified bookmarklet-era public site from just before the extension pivot, but I could not honestly reproduce a historical screenshot of a real CSP failure state. So this section includes the reconstructed bookmarklet-era surface plus the later hostile-page proof image that documents why the delivery model had to change:
What I was really learning here
I was learning that a browser tool can have decent audit logic and still be unreliable in practice if the delivery model is weak. I had to stop treating injection as a solved detail and start treating it as part of the product.
Evidence
- Commits:
d82c03b– bookmarklet hardened with bundled axe-core, CSP-aware errors, docs, and testsecfc5ba– MV3 extension foundation added immediately after
- Files:
../../README.md../../SUPPORTED_ENVIRONMENTS.md../../tests/playwright/hostile-css-isolation.spec.js../../tests/playwright/release-bundle.spec.js
- Visuals:
phase-03-reconstructed-verified-bookmarklet/landing-page.png– direct historical screenshot captured from a checked-out worktree at8b09635phase-03-extension-release/store-07-hostile-css-isolation.png– existing repo asset showing the later explicit hostile-page isolation work
- Inference:
- The idea that the bookmarklet had “hit a wall” is an interpretation of the delivery-boundary docs and the sequence of hardening followed by extension work, not a literal sentence from a design note.
