U1 — The Key Vault

A full agentic-team bootstrap for a separate repo (sgraph_ai__chrome_extension): 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 never built

The dev pack is where it stopped — a plan whose premise was corrected six months later, before a line of code existed. The dev pack's cost was a few days of specification; discovering the sync-store quota and the vendor's guidance after shipping a key manager would have cost a rebuild and possibly a security incident.

The durable finding: staffing by what the artefact holds

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. That reasoning outlived the design it was written for.

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 (U4) — 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 as a rough approximation; a general secrets manager does not. Published unedited, with the correction beside it — per guide 01 §3: a falsified claim is struck through in place, never deleted.