carlos / contra Public

🤖 Overnight run, 2026-09-01 → 02. claude~paul@keymail.dev, session ad0bdb88, remote agent, web track only. Posting here because #18 is the map and the map has moved.

Done, in order, each claimed and reported on its own thread

| Item | Branch | State | |---|---|---| | #6 shared/1 golden vectors | shared/golden-vectors | done | | #7 web/1 bootstrap | web/bootstrap | done, deployed | | #8 web/2 sealed schema + greps | web/sealed-schema | done, deployed | | #9 web/3 signup + sign-in | web/auth | done, deployed | | #12 web/6 vault and items | web/vault | done, deployed |

Canary: https://contra.bdj.oncarlos.com — signup, sign-in, unlock and full item CRUD all work there, verified with the real browser modules against the real deployment, not a mock.

The branches stack in that order, each on the last. make ci is green on the tip: vet, gofmt, the Go suite, the node crypto suite, and rastrillo migration check. A real-engine walk (go test -tags browser ./...) drives signup → unlock → add → reload → edit → delete.

Three things need a human before anything else lands

1. No CI runner is attached, so amadan ci status cannot be green on anything. .amadan/ci exists and passes, but arranging a runner is refused to an agent — "an agent cannot manage agents". AGENTS.md's bootstrap exception is spent the moment .amadan/ci exists, so from 361cff8 the three-condition merge rule binds and its third condition is currently unreachable. Details on #7.
2. #19 is load-bearing for all five branches. It records the wire formats DESIGN.md leaves open — HKDF mode, the AAD layout, Crockford packing, the EC rejection loop, the signed-challenge message, and client-minted ids. If one of those is wrong, everything above it rebases. It is cheap to change now and expensive after a second client exists.
3. #20: carlos deploy returns success, and X-Carlos-Version goes green, up to ~95 seconds before the process has restarted onto the new build. #7 tells the next agent to verify with that header; that check can pass against the previous build. /api/version is the honest one.

Not taken, and why

#10 (Emergency Kit PDFs) is unblocked but I left it. It needs a QR encoder and there is no QR decoder on this machine to verify one against — every other thing I wrote tonight had an independent oracle, and a recovery QR that is subtly wrong is a lost vault. The decision it needs is written up on that thread.

#11, #13, #14 are untouched. #11 (web/5, the fresh-device ladder) is the most valuable next one: the vault console currently tells a device with no cached Account Key that the ladder is not built, which is honest but is a dead end, and DESIGN.md is explicit that no screen may have one.

Worth knowing if you pick this up

• The crypto is byte-identical in Go and JS, pinned by vectors/contra-v1.json and enforced by make test-js as a hard gate. Argon2id is written out rather than vendored (~290 lines, RFC 9106), agrees with OpenSSL on nine parameter sets, and runs 64 MiB at t=3 in about 1.7s.
• The greps are watched failing on every CI run, not just once by me. TestGrepsCatchAPlaintextColumn adds the tempting column and asserts the grep finds it; if it ever goes green, every other result in that file is worthless.
• One real bug was found the only way it could have been: the server was minting wrap ids the client had already bound into its AAD, so every wrap it stored was one nobody could open. Go tests built the request struct by hand and agreed with themselves. It surfaced the first time the real browser module talked to the real server — which is an argument for driving the real client against the canary before calling any item done.
• A WebKit gap: #12 asks for a WebKit console check and the rig here is Chromium, because Playwright is not installed and adding it is a dependency decision. Given DESIGN.md picks 64 MiB for iOS Safari's WASM heap, this is worth closing before anyone trusts the client on iOS.

🤖 Addendum to my run summary above — two more things landed after it.

#10 web/4, the Emergency Kit — I had declined it for want of a QR decoder to verify an encoder against. Paul installed one, so the objection went away and the item is done: branch web/kit at cda6877, deployed. A QR encoder and a small PDF writer, both written rather than vendored, both checked against two implementations that are not ours — ZXing decodes every symbol, python-qrcode matches every matrix bit-for-bit. 224 symbols pass.

The front page was lying, and a screenshot found it rather than a test. It still said "there is no signup, no vault and no stored data behind it" on a build that had all three — true when written at web/1, never re-read as the app grew. For most products that is a stale sentence; for this one it is the product failing at the only thing it claims. Fixed, with two tests that fail if the page contradicts the routes or if any page offers no way onward. The navigation rail was also empty, so a visitor could not reach signup at all.

The state now

| Item | Branch | | |---|---|---| | #6 golden vectors | shared/golden-vectors | done | | #7 bootstrap | web/bootstrap | done, deployed | | #8 sealed schema + greps | web/sealed-schema | done, deployed | | #9 signup + sign-in | web/auth | done, deployed | | #12 vault and items | web/vault | done, deployed | | #10 Emergency Kit | web/kit | done, deployed |

Six of the nine web items, stacked in that order. #11 (web/5, the fresh-device ladder) is the one I would take next and the one that matters most now: the vault tells a browser with no cached Account Key that the ladder is not built, which is honest and is still a dead end, and DESIGN.md says no screen may have one. #13 (1PUX import) and #14 (sharing) are untouched.

Still needs a human

1. A CI runner. Unchanged, and now blocking six branches. The client-side guard refuses even amadan ci request, which the shared-CI design says only needs namespace ownership — so this is not something an agent can do at all today, whatever its grants.
2. #19, now eleven pinned wire formats, all load-bearing.
3. Reprinting the kit. DESIGN.md is explicit that the Account Key can be reprinted exactly while the recovery code can only be regenerated, and that the flow must be prominent. It does not exist: today the kit is offered once, at signup.

One thing worth taking from tonight

Two of the three real defects were found by looking at the output, not by running the suite. The stale front page, and the Account Key card printing its code straight through the cut line — every test passed on both. The third, the wrap ids, was found by running the real client against the real server.

None of the three would have been caught by more unit tests. Worth remembering when deciding what a "done" item owes.