Signup journey gains a pre-provisioning ownership gate

The signup story now has a two-gate flow (ADR-0005, docs/03-provisioning.md §4/§4a). Step 3 in the happy path changes materially:

• Before provisioning, a verifying claim must pass the ownership gate — either Mechanism A (TXT challenge _sovrn-challenge.<domain> = sovrn-verification=<per-claim nonce>) or Mechanism C (apex-handle _atproto TXT proof, only when handle == registrable domain).
• Only a verified claim triggers stalwartsync Domain+Account provisioning (step 4). The old single “DNS probe stubbed-pass → active” collapses into two stub points: ownership probe, then readiness probe (MX/SPF/DKIM).

Implications for this risk probe:

• Add a harness DNS stub that can answer the challenge TXT (and later MX/DKIM) so the happy path reaches verified → active deterministically.
• Add a failure injection: ownership probe never passes → claim expires (~48 h schedule) with no Stalwart objects ever created (assert zero registry writes).
• Cross-reference implementation bug b5a31bd ([C7]) and ADR-0005.

Re-scoped after ADR-0006 (data placement & space topology) — 2026-08-28

The original tasks baked in an un-examined assumption: user publishes a public com.sovrn.mail.claim → jetstream → reconciler → space projection. ADR-0006 removes the public claim and the jetstream signup path. Updated happy path and failure injections below.

Happy path (revised)

1. OAuth login (browser-sim atproto OAuth for the signing-up DID)
2. App view XRPC: record signup intent (domain + address) → app-DB claim row claimed
3. DNS ownership gate (stubbed challenge TXT) → verified
4. Postmaster authors at.sovrn.domain.detail + at.sovrn.mail.account records (tenant + domain spaces)
5. Reconciler provisions Stalwart Domain+Account (alias) via Registry/set
6. Readiness gate (stubbed MX/SPF/DKIM) → active
7. User re-login → at.sovrn.mail.service record written to the user’s public repo (endpoints only)
8. sovrn OIDC token minted → JMAP session opens → mailbox list returned

Failure injections (revised)

• Stalwart stopped mid-step-5 (retry/idempotent re-apply)
• PDS unreachable at login (step ¹⁄₇)
• tokenissuer keys unavailable at step 8
• forged member-authored record written to the domain space → reconciler ignores it (assert authorDid == postmaster filter)
• duplicate jetstream event replay (dropped: jetstream is identity-only now, not in the signup path)

Acceptance criteria (revised)

• Happy path green end-to-end, repeatable from clean stack
• Each injected failure produces the designed behaviour from docs/01 §6 (no crashes, no stuck states)
• authorDid enforcement proven: non-postmaster records are ignored
• Findings doc committed; follow-up issues created and referenced in tracker f98ccdc

Design basis: docs/adr/0006-data-placement-and-space-topology.md.

Lexicon design landed — at.sovrn.* (feeds this probe + f6192a1/a472ea3)

Delivered the first-cut at.sovrn.* lexicon surface and Go codegen, per ADR-0007 (write-through postmaster PDS projection; facts on protocol, app DB = transient/ security/cache). Files under lexicons/at/sovrn/:

Space types ("type": "space", proposal-0016 wire shape): - at.sovrn.space.tenant — collections [at.sovrn.tenant.detail, at.sovrn.domain.detail] - at.sovrn.space.domain — collections [at.sovrn.mail.account]

Records: - at.sovrn.tenant.detail (tenant space, literal:self) — name, createdAt - at.sovrn.domain.detail (tenant space, tid) — domain, mode, status, mxVerifiedAt, dkimState, tierDefaults, dns{mx[],spf,dkimSelector,dkimTxt} - at.sovrn.mail.account (domain space, tid) — did, address, status, verifiedAt - at.sovrn.mail.service (public repo, literal:self) — appview, webmail, optional mailEndpoints{jmap,imap,smtp}

XRPC (app-view / reconciler, org→domain→account progression): - at.sovrn.tenant.create — {name?} → {tenantId, name, space} (name defaults to handle) - at.sovrn.domain.create — {tenantId, domain, mode} → {domainId, state, challenge?} - at.sovrn.domain.list / at.sovrn.domain.getDnsState - at.sovrn.mail.createAccount — {domainId, address, did?} → {accountId, state} (did omitted = self) - at.sovrn.mail.listAccounts / at.sovrn.mail.removeAccount

Codegen: cmd/sovrn-lexgen (wraps indigo lex) emits api/sovrn types for records + XRPC + views; strips indigo’s dynamic $type registration (JSON-only, no cbor-gen dep) — regenerate via just gen / go generate ./api/sovrn. Space types are hand-written in api/sovrn/spacetypes.go (indigo lex has no "type":"space" case — worth a follow-up).

Records relevant to this probe’s steps: step 4 = at.sovrn.domain.detail + at.sovrn.mail.account (tenant/domain spaces); step 7 = at.sovrn.mail.service (public repo). These schemas are the source of truth the spaceproj publisher/ reader (12ce549) and reconciler (f15633a) validate against.

Deferred to those bugs: the reconstruction test (fresh appview state from PDS-only reads, diffed vs app DB — proves completeness/portability) and the CI lexlint/idempotency check, both of which need the spaceproj/PDS harness.

Verification: go build ./..., go vet ./..., go test ./... all green.

Happy-path risk probe: TestIntegrationHappyPathLexicon (uses the new lexicons)

Added internal/integration/happypath_test.go — a Phase-0 risk probe that walks the ADR-0007 happy path through the generated at.sovrn.* types, drives the implemented slice (Stalwart provisioning) from those records, and records a FINDING for every missing piece. Runs against the live harness; go test ./internal/integration/ green.

What it proves (CORE): - All four records (tenant.detail, domain.detail, mail.account, mail.service) and the three XRPC inputs (tenant.create, domain.create, mail.createAccount) round-trip JSON with correct $type identity. - The record→Stalwart mapping is sufficient to provision: tenant.detail.name → tenant, domain.detail.domain → domain, mail.account.address → account, plus an app password — the executable slice of the happy path.

Findings it surfaces (gap inventory): - Data gaps (new, no existing bug covers them): 1. at.sovrn.tenant.detail carries name+createdAt only — tenant quotas/ tier (maxDomains, maxAccounts, diskQuota) have no protocol home. 2. domain.detail.dns (mx/spf/dkimSelector/dkimTxt) is declared but has no writer/reader; Stalwart auto-DKIM generates its own selector/key, which is not reflected back → desired-state vs applied-state divergence. 3. enum/knownValues (mode/status/dkimState) are plain strings in the generated Go — no validation; needs the reconciler validation layer (docs/03 §3). 4. mail.account.did has no Stalwart equivalent (by design); the three-way diff can’t verify the DID↔mailbox correlation against Stalwart. - Component gaps (already tracked): OAuth/PDS (no PDS in harness), app-view XRPC server (b04aeb9), dnsprober gates (b5a31bd), spaceproj publisher (12ce549), reconciler (f15633a), mail.service endpoints (a472ea3/ac83db8). Step 8 (OIDC→JMAP) is already covered by TestIntegrationOIDCBearerAuth.

Recommend filing the three “data gaps” against f6192a1 (lexicon schemas) or as new child issues; the component gaps are already in the tracker.

DKIM correctness fix landed — manual, sovrn-generated RSA-2048, no rotation

Resolved the domain.detail.dns gap (ADR-0007 D19). The record is now populated synchronously with Stalwart-derived values — no async generation, no polling, no rotation.

Changes: - internal/domain: domains now set dkimManagement: {"@type":"Manual"} instead of Automatic; dropped the DKIMAuto projection and the “patch toward Automatic” Ensure behavior (key lifecycle is sovrn’s, not Stalwart’s). - internal/dkim (new): Generate creates an RSA-2048 key, installs the private half into Stalwart as a Dkim1RsaSha256 DkimSignature (selector="sovrn", privateKey as SecretText), reads back the decorated publicKey, and returns the DNS TXT (v=DKIM1; k=rsa; h=sha256; p=…) at sovrn._domainkey.<domain>. The private key is never retained by sovrn. - Happy-path probe: dkim.Generate → populate domain.detail.dns.dkimSelector / dkimTxt is now a CORE assertion (was a FINDING). Verified live against Stalwart: key accepted, publicKey read back, record round-trips.

Decisions (per owner): RSA-2048 only (major receivers lack ed25519 — Gmail/ MS365/Yahoo/iCloud); fixed selector sovrn for easy copy/paste/verify; no v1 rotation; Stalwart sole holder of the private key (regenerate on migration).

Still out of scope (noted, not fixed): dns.mx/dns.spf are sovrn ingress config, not Stalwart-generated — populated from config separately.

Verification: go build ./..., go vet ./..., gofmt -l, go test ./... all green (unit + integration, incl. live Stalwart harness).

Closing: Phase-0 risk probe served its purpose

The C6 probe’s goal was to surface unknowns and force assumptions into decisions, not to ship product code. It did: the data-placement question it flagged in week one produced ADR-0006 (space topology) and ADR-0007 (postmaster write-through projection), which re-scoped this bug twice. The remaining work is now concrete, filed Phase-1 issues rather than open questions.

Delivered in this bug’s orbit: - at.sovrn.* lexicons + Go codegen (cmd/sovrn-lexgen → api/sovrn) — f6192a1/a472ea3 schemas. - TestIntegrationHappyPathLexicon — the signup story expressed through the lexicon types, driving Stalwart from record data with a FINDING inventory. - Manual DKIM fix (ADR-0007 D19): internal/dkim generates RSA-2048, Stalwart holds the private key, the record carries sovrn._domainkey.<domain> — the domain.detail.dns correctness bug is resolved and asserted live. - Real app-view XRPC server: root router.go (NewApp(cfg)), internal/store (SQLite TID↔Stalwart-ID mapping), 7 handlers in internal/appview, cmd/sovrnd. TestIntegrationAppViewXRPCEndToEnd drives all 7 endpoints over HTTP against live Stalwart — the earlier “XRPC endpoints not exercised” gap is closed. - Config surface tracked in 82af326; ADR-0002 amended to mattn/go-sqlite3.

What the probe surfaced → now tracked elsewhere (not this bug): - 12ce549 (spaceproj), f15633a (reconciler), b04aeb9 (app view UI), ee2256b (postmaster/PDS), b5a31bd (dnsprober), ac83db8 (webmail), a472ea3 (mail.service endpoints).

Failure injections: the revised set (comment 09d75f4) targeted components that did not yet exist when those would run. They are superseded by the Phase-1 component test suites (spaceproj forged-record authorDid test, reconciler idempotent re-apply, dnsprober gate), not lost. Auth (OAuth) and DNS (dnsprober) remain stubbed in the app view until those bugs land — by design.

Closing as the tracker is complete; the design decisions and follow-ups above carry the remaining work.