oficina / home Public

Answer the Task 1 review, and land the sealed link store

Two things in one commit, which is one more than it should be: the
review fixes and Task 4. They interleave — Task 4's store is built on
New's signature, which finding B5 changed — so splitting them would
produce two commits neither of which builds.

## The Task 1 review: CHANGES NEEDED, six blocking

The three that mattered most were all the same shape — a comment
asserting something the code did not do.

B1/B2/B3 — the boot path could not have started on the platform.
The home does not hibernate, so it runs as an ordinary unit tenant:
carlos-app@.service is `ExecStart=/opt/carlos/live/%i serve` with NO
arguments, and only the hibernate exec child is invoked with --socket
and --db. Requiring --db meant refusing every boot on the platform while
working perfectly for anyone who typed the flag locally. rastrillo's
Resolve overwrites Options.DBPath only when -db is actually passed and
joins a relative path to $STATE_DIRECTORY, so the path is now a default
in Options and the flag still wins locally. Verified end to end: the
built binary, invoked with --socket and no --db, boots, creates home.db
under $STATE_DIRECTORY and answers /healthz and / with 200; with a
secret missing it exits 1 and serves nothing.

The commit that introduced this also claimed "the previous build is what
serves" if a deploy went out without secrets. That was wrong and worth
correcting loudly: the unit is Restart=always and the activator does not
treat a wedged unit as down, so a deploy of a binary that exits 1 would
have systemd respin it and the site would 502 until a rollback. That is
what a promote does, not a deploy. Nothing in .amadan/ci.d deploys on
merge, so merging is safe; deploying is what needs the secrets first.

B4 — an all-zero key passed every check. Right length, valid base64, and
the canonical placeholder. signin.Flow refuses a zero Key per request
rather than at construction, so the app would have booted, answered
/healthz and failed every single sign-in. Refused at load now, for all
three keys, with a test per key and verified against the real binary.

B5 — "there is no zero-value escape hatch" was false. New(Secrets{})
compiled and ran. New now returns an error and refuses a nil Sealer, an
empty pepper, a zero signing key, a nil mailer and a nil database.

B6 — "adjacent columns of the same row" is Sheets' schema fact, carried
over with the port. The home's three purposes live in three tables. What
the HKDF split actually prevents here is a store handed the wrong
purpose, which no type and no round-trip test would notice.

Nits, all taken: the SMTP error text contradicted the comment above it
(HOST/FROM leak addresses into logs, PASS costs delivery — two failures,
two messages); LoadSecrets read HOME_DEK itself instead of calling
LoadSealer; "two settings" was three; sealtest scanned case-sensitively
while shipping upper-case canaries, and a team name is normalised for
reservation, so the scan folds case now; Sheets' vectors test is ported,
plus one asserting the home and Sheets derive different keys for the
same purpose name, which is the entire content of the change the port
made; the Makefile's "no database, no concurrency-bearing package" is
false twice over, so test-race lands with a CI step; the plan's
reference to the renamed containment guard.

One finding was mine: the runtime address-column check and gate 2's
static one disagreed about sealed_address, because only the static one
carried the exemption. That is the cost of two independent
implementations and also the point of them.

## Task 4: the sealed link store

- migrations/0002_signin_links.sql. No redeemed_at column, and its
  absence is the design: a row that survives redemption lets a handler
  tell "already used" from "never existed", which is an oracle, and
  marking it redeemed makes the take a read-then-write race where two
  clicks both mint a session.
- links.go. PutLink seals before it inserts — Litestream ships WAL
  frames continuously, so a plaintext write reaches the bucket before
  any delete could remove it. TakeLink is one DELETE ... RETURNING, so
  exactly one concurrent caller wins and unknown, expired and
  already-used are all "no row" by construction. expires_at is compared
  as a string, so both sides are written UTC RFC3339; a zone offset
  would sort differently and silently accept expired links.
- blindIndex is ruling 3, HMAC(pepper, lowercased address). §3.1 prefers
  "an expensive KDF rather than a bare HMAC"; that is a mitigation note
  in the threat-model section and ruling 3 is in §1's settled table, so
  the ruling wins. FILED FOR PAUL, not resolved here.
- findOrMintPerson is one upsert, so a returning person and a first-time
  person take the same path. Without it, a UNIQUE blind index and a
  fresh ref per visit would attach every session, credential and
  recovery code to an identity nobody can return to.
- The sweep runs after each put and never fails the put: sealed rows are
  not a leak, and refusing a sign-in because housekeeping failed trades
  a hygiene problem for an outage.

Gate 1 was verified to bite, as the plan insists: storing the address
unsealed fails TestPutLinkSealsTheAddress with `plaintext
"canary-8f3a@example.invalid" found in home.db-wal` — found in the WAL,
not the main file, which is exactly the reason the WAL is scanned.

Deferred with a reason: the plan's Task 4 step 5 also asks for
sessions.Sweep and passkey.Sweep on the same boot-plus-on-write shape.
Neither package is wired yet, so they land with the tasks that wire
them rather than as imports of packages nothing uses.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E4uVkB6xnZJYuxTooPiUn4