# Product 🤖 Product record for CONTRA. Confirmed with Paul, 2026-09-03. Everything here is product truth, not visual direction — `AGENTS.md` holds the settled decisions, `PROTOCOL.md` the cryptographic protocol, `DESIGN.md` the visual system, `PLAN.md` what is built. ## Platform adaptive The web console is what exists today. `AGENTS.md` decision 6 fixes the build order: rastrillo instance and client-shape web console first, then a native Mac app as the *second* implementation of a settled contract, then the macOS AutoFill Credential Provider extension, then iOS. Recorded as `adaptive` because those native surfaces are the product, not ports of it — and because the trust story differs by platform in a way design must not blur: the at-rest promise holds everywhere, but "compromise the running server and still get nothing" is only fully true where the code is signed and not fetched per visit. ## Users Two primaries, weighted equally. Neither may be traded off for the other. - **A small team moving off a shared password manager.** Eleven is the first, and its secrets move in as soon as CONTRA is ready — with shared vaults working on day one, not as a later capability. Their situation: credentials that several people genuinely need, on infrastructure they control, without a multi-tenant operator holding anything that opens them. - **A person leaving 1Password with their own vault.** Their job is getting everything across without a support article, and then trusting a thing whose recovery story is stricter than what they left. The `.1pux` file is opened, parsed and sealed in their browser; it never reaches the server. An AI agent is a third, narrow actor rather than an audience: it may list a vault, use a secret without receiving it, and add new secrets. It may not read a value into its own context, and there is no setting that turns that on (`AGENTS.md` decision 5). ## Product Purpose A password manager where the server knows nothing about you. Not "we promise not to look" and not "we encrypt at rest": the instance holding a vault cannot open it, cannot tell one account from another by content, and does not know the account's email address. Success is that a stolen instance yields a pile of ciphertext and the times of day somebody connected — and that a person who reads the trade-offs first still chooses it. ## Positioning Built to **CARLOS A1, host-blind** — the strictest class the family publishes. What a neighbouring product cannot truthfully copy without rebuilding on the same terms: - **No content-derived identifiers at rest.** Item names, URLs, usernames, folder structure and vault names seal exactly like passwords, because a name is a secret too. All object identifiers are random, never content hashes: a content-derived identifier is both an A1 violation and an equality oracle. - **There is no way back in that we control.** No reset link, no support override, no identity verification that restores a vault — because a server that could give your vault back could give it to someone else. Every competitor that can email you a way in has, by definition, a way in. - **Sign-in is a signature, not a stored verifier.** The server holds only a public key and authenticates by signed challenge, so a fully compromised server holds something that cannot decrypt and cannot be replayed. - **The honest trade-offs are on the front page**, not in a support article — including the ones competitors omit: that removing somebody from a shared vault cannot un-download what they already have, that the server learns transport shape, and that a browser trusts the server to send honest code. ## Operating Context - **One instance per account**, on the owner's own deployment. A shared vault lives on its owner's instance and other members are identities there. That is what keeps membership an access-control list — transport shape — rather than a content-derived identifier, and the distinction is load-bearing. - **The Emergency Kit is paper.** Two printed documents, generated in the browser at signup and never sent to the server: an **Account Key card** (a new device asks for it once; useless without the passphrase) and a **Recovery sheet** (the way back if the passphrase is forgotten; opens the vault on its own, and nobody can reissue it). They are stored differently on purpose — a drawer versus a safe — and the copy must keep saying so. - **Getting onto a new device** is a three-rung ladder that must never dead-end: a handoff from an already-enrolled device, scanning the card's QR, or typing its code. Once a device holds the Account Key, the passphrase alone unlocks it — the everyday case. - **Migration is a file, not an integration.** 1Password `.1pux`, opened client-side. Passkeys stored in 1Password cannot be exported by anyone, so those are re-created by hand and the product must show which ones. ## Capabilities and Constraints - **Crypto is byte-identical across implementations**, pinned by shared golden vectors generated by neither of them. Changing a pinned value is changing the protocol. - **Sealing happens where the keys are**, which makes a server-rendered vault impossible rather than merely discouraged: the server has never seen a title and could not render one. - **A new storage surface lands with its canary or it does not land.** Canary strings are pushed through every write path and the raw database bytes searched for them. - **Recovery, stated plainly:** lose the kit *and* the passphrase and the data is gone. Lose the kit while a device is still enrolled and it reprints — the Account Key card exactly, the recovery sheet only by regenerating, which invalidates the old one. - **Accepted residue**, published rather than hidden: the sharing graph (which accounts share a vault, never what is in it), item count, per-item write timing, and sign-in timing. - **Money:** a genuine free rung, then €5/year. Cheap on purpose — a password manager people cannot afford to keep is one that loses their data. Integer cents; a float never touches an amount. - **Terminology that must stay stable:** Account Key, recovery code, Emergency Kit, vault, item, member, drop box, instance, handoff. - **Explicitly undecided / not built:** Bitwarden and Apple Passwords importers, passkey migration out of 1Password, cross-instance sharing (federation — never in v1), breach monitoring, one-off sharing links, agent mutation of an existing item. Each has a written trigger in `AGENTS.md`. ## Brand Commitments - **Name:** CONTRA. A CARLOS app. - **Voice:** plain, specific, and unapologetic about consequences. It states the cost of a decision in the same breath as the decision, and does not soften a limitation into a feature. "That is the product, not a gap in it." - **AI authorship is disclosed.** Machine-authored text carries 🤖 where it surfaces; a person marker (👨/👤/🧑) certifies human text an LLM must not rewrite, rephrase, condense or delete. AI features are opt-in, always disclosed, and every path works with AI switched off. - **No dark patterns around loss.** The product nags toward a second device and a reprinted kit because both are real protection — never to manufacture urgency. ## Evidence on Hand - **Pre-alpha. Nothing to sign up for yet.** There are no customers, no testimonials, no press, no benchmarks and no pricing page in market. None may be invented. - Real artefacts that do exist: the deployed canary (https://contra.bdj.oncarlos.com), the golden vectors (`vectors/contra-v1.json`), `README.md`'s trade-offs section, `AGENTS.md`'s nine settled decisions, `PROTOCOL.md`'s protocol and compromise matrix, and `PLAN.md`'s built/not-built state with a trigger per deferral. - The two kit documents are generated by the product itself (`internal/contra/static/crypto/kit.js`) and are the only real "assets". ## Product Principles 1. **Say the cost where the promise is made.** Trade-offs belong on the front page and beside the button, not in a support article. The recovery rule, the sharing residue and the browser-trust boundary are stated in the copy that precedes the action. 2. **Never dead-end a person who still has a way through.** Every screen that needs a key offers every rung that can work, and the last one always can. 3. **The server is a hostile witness.** Design as though the instance is already stolen: nothing it holds may name, rank, group or identify content. 4. **Sealed by default, everywhere a name could hide.** If a person typed it, it is a secret — titles, URLs, usernames, vault names included. 5. **Paper is a feature, and it is asked for honestly.** The kit exists so that a chosen passphrase cannot cap how safe a vault can be; the product explains that rather than assuming compliance. ## Accessibility & Inclusion **WCAG 2.2 AA**, binding. Two places where that is more than a checklist and design must treat it as a product constraint: - **The printed kit is an accessibility surface.** Contrast, type size and the QR's quiet zone have to survive real paper and a phone camera, at the worst moment somebody will ever use this product. - **Recovery paths must not assume a mouse, a camera, or a steady hand.** The device ladder's typing rung is the one that always works, and it self-heals a single mistyped character rather than only rejecting it.