Once I started looking at the extension commits closely, it stopped feeling like “another way to launch the tool” and started feeling like a different phase of the product.
The bookmarklet and the extension are related, but they are not the same story.
When the MV3 foundation lands on April 8, the repo is solving a very specific problem: how do I inject packaged local code into the current tab after an explicit toolbar action, without depending on the page allowing a third-party script host? That is not a cosmetic change. It is a new answer to the biggest weakness in the original delivery model.
The first extension commit is pretty clean about that. It adds a manifest, a service worker, icons, a content entry, a build script, and the basic injection path. Then the follow-up commits immediately go into the practical bits: serializing programmatic injection per tab, safer style mounting, delivery-aware errors, settings persistence, permission docs, and live-site runtime hardening.
That sequence is useful because it shows the extension was not just “turn the bookmarklet into an extension package.” It had its own runtime concerns almost immediately. Launch mechanics. Injection timing. Tab state. Error boundaries. Storage. Permission posture. Those are extension problems, not just audit problems.
I also think this is where the project’s public story changes most visibly. The README eventually becomes extension-first. The public site gets rebuilt around the extension workflow. The bookmarklet remains, but it stops being the main character. That shift only makes sense if the builder had already learned that the extension path solved the more serious real-world delivery problem.
The interesting thing is that the repo does not use the extension pivot as an excuse to overclaim maturity. Even when the extension becomes primary, the docs stay careful. Restricted URLs are still unsupported. Broad rollout is still blocked. Manual AT sign-off is still required. The extension is better for hostile pages, but it is not treated like a magic fix for every support boundary.
That makes the pivot easier to trust. It is not framed as “now the product is complete.” It is framed as “this is the more reliable delivery model for the pages that were breaking the old one.”
I think this post is one of the clearest examples of the repo following evidence instead of ego. It would have been easy to keep polishing the bookmarklet because it was already there and already public. Instead, the project changed shape because the delivery problem stayed real.
Visual evidence
This phase has a direct reconstruction of the extension-first public site, plus the committed extension screenshots that came later in the same general product direction:
What I was really learning here
I was learning that if I wanted this tool to work on the kinds of pages that actually cause trouble, I needed to change how it was delivered, not just how it scanned. The extension was not a nice extra. It was the next honest step.
Evidence
- Commits:
ecfc5ba– MV3 foundation addedefe6959– live-site runtime and injection feedback hardened0ad8ec8– programmatic injection serialized per tabab2fb62– safer host style mount and delivery-aware errors4b26bdb– settings persisted inchrome.storage.locald44c21e– public site rebuilt around extension workflow
- Files:
../../extension/manifest.json../../extension/background/service-worker.js../../extension/README.md../../README.md../../index.html
- Visuals:
phase-04-reconstructed-extension-first-site/landing-page.pngandphase-04-reconstructed-extension-first-site/extension-guide.png– direct historical screenshots captured from a checked-out worktree atd44c21ephase-03-extension-release/store-01-toolbar-launch.pngandphase-03-extension-release/store-02-scan-results.png– existing repo assets from the later extension-first release/store set
