The arc: a plan, a shipped tool, and a correction

The founder's framing was that the existing extensions are "all with different levels of quality." That is true, and the corpus makes the differences legible — which turns a guidance site into an argument. Each effort represents a different epistemic state, and this page labels them that way.

Effort 1 — the March dev pack (planned)

v0.11.12__chrome-extension-key-vault, dated 5 March 2026: a full agentic-team bootstrap for a separate repo, with a reading order, BRIEF.md, architecture.md, code-context.md ("the exact vault and send crypto source the extension must interoperate with"), role definitions, a technical bootstrap guide, and a copy-paste first-session prompt.

Five phases: Key Vault MVP → security posture → an independent API channel → cross-device communication → distribution and corporate extensions.

Confirmed on 8 September 2026: it was never built. The dev pack is where it stopped. That makes the correction in effort 3 a saved rebuild rather than a post-mortem — the premise was overturned before any code existed. A plan that was corrected before it shipped is the system working.

The decision worth publishing: the pack added AppSec as a seventh role — one not present in the sibling tools pack — with the reason stated plainly: "because the extension holds encryption keys — it's the highest-stakes component in the ecosystem." Staffing a team by what the artefact holds rather than by convention is exactly the teams.sgit.ai thesis, arriving here first.

And the premise that did not survive. The architecture put an encrypted bundle in chrome.storage.sync and noted:

~~"Chrome Sync allows ~100KB total. One bundle with identity keys + hundreds of room keys fits easily. If exceeded: split into indexed chunks or fall back to chrome.storage.local."~~ CORRECTION, September 2026 — read from documentation rather than recalled: 102,400 bytes total, 512 items max, 8,192 bytes per item, 120 writes/minute. The "hundreds of room keys" claim survives; a general secrets manager does not. See effort 3 below.

That is a recalled approximation with a contingency plan, and it is wrong in a way that matters. Published unedited, with the correction beside it — the guides' own rule (guide 01 §3): a falsified claim is struck through in place, never deleted, because "a confident wrong claim in a doc is a trap for the next reader" and "the reasoning that produced the error is reusable."

Effort 2 — the recorder (shipped, and the evidence base)

The subject of all four guides. v0.16.0 · ~3,400 lines · 176 tests · 33 numbered lessons · 12 capture runs, built over five weeks against a target that changed its entire API stack mid-project.

What makes it the quality benchmark is not the line count but that every claim in its documentation is measured: 58 distinct type names found in one run; capture modes catching 14 / 33 / 181 responses; a derived timestamp verified three ways against artefacts the target itself produced (27 ms against a pagination cursor, six-for-six against rendered age strings, 0.269 s against a server-minted id — "a network round trip"); 381 of 382 identifiers exactly 39 characters before it was safe to cut at 39.

It also ships the affordances that let a human verify it: counters on a page global, a coverage tab, a single-file viewer that "never draws a missing value as zero," and a build stamp on every artefact.

Effort 3 — the September correction (specified, honestly incomplete)

The 5 September dev brief responds to a memo asking for the March extension again — a secrets manager syncing across machines with minimal permissions and a right-hand panel. Rather than re-planning, it read the platform documentation and returned two corrections and one downgrade.

Correction 1 — the budget is a design constraint, not a footnote. Measured against the docs, not recalled:

The verdict is a sizing judgement, and it is the useful part: "ample for vault keys and nowhere near enough for a general secrets manager holding certificates or long tokens."

Correction 2 — the vendor steers sensitive data away from this store. The platform's documentation "does not state that this store is encrypted and explicitly recommends the session store instead when working with sensitive user data" — described as "the vendor steering us away from exactly the thing the memo wants to do."

The resolution refuses to argue with the guidance and makes it irrelevant instead: treat the synchronised store as an untrusted transport carrying ciphertext and nothing else — "precisely the position this estate already takes toward its own server, so the extension becomes the same architecture at a different altitude, with a passphrase that never leaves the device, a key derived from it, and a store that holds bytes nobody upstream can read."

The downgrade — origin binding fails the enforcer test. The memo's idea of binding a secret to a site so only that site can reach it is assessed and demoted: "the thing enforcing the binding would be the extension, and the extension is the actor that holds every secret it manages, so an extension enforcing a rule about itself is the same weak shape this corpus rejected when an agent enforces its own mandate." The honest version — a usability control that prevents mistakes, not a security boundary that prevents attacks — "and it should be labelled as one."

What does hold: the permission discipline. The platform grants permissions at runtime rather than at install and its own guidance is to use them wherever functionality permits, so the extension ships "with almost nothing at install" and asks for one origin at first use. And the panel is right for a reason beyond taste: "a secrets manager should never be a page you navigate away from into the thing you are pasting into."

Two further designs — risk cards on extensions (4 July) and the Scribe (14 August) — also exist and were also never built. They carry platform constraints that matter more than their designs do; see the unbuilt.

The ladder, as this site teaches it

Three states, in increasing order of trust, each legitimate at its moment:

1. recalled — you remember roughly how the platform behaves. Fast, and the source of the March quota error. Acceptable for a plan; never for a constraint that decides an architecture.
2. read — you opened the documentation on a stated date. The September position. Better, and still not behaviour.
3. measured — you ran it and counted. The recorder's position, and the only one that survives contact with a target that changes underneath you.

A claim on this site carries which of the three it is, and when. That is this site's contribution to a genre otherwise full of undated assertions about what Chrome does.