No instrument distinguishes noProfile wrong-account from genuinely-unprovisioned: both carriers falsified
TERRA-18 shipped arms (1)+(2) and left this as an open gap on pm-terra-cc's instruction (two working arms are not held behind a third). BOTH proposed carriers are dead, for DIFFERENT structural reasons, and neither is a data gap. (1) supersededPriorFlowId: finish() deletes SIGN_IN_FLOW_COOKIE on every exit path and that deletion IS completion semantics, so the stamp can only link a flow whose predecessor never completed - a noProfile completes, so the field is null for every noProfile and the discriminator has ONE reachable value. Measured against the real 2026-08-14 pair (noProfile 07:12:44, authorized 07:12:57): no link. (2) TERRA-27's SIGN_IN_BRIDGE_COOKIE survives a completed attempt and carries the flowId, but friction-actions.ts consumes and deletes it unconditionally on RENDER of the /login?error= landing, before the user clicks; and a bridge still present would mean TERRA-27's own reader had not run, so a second consumer is a race for that rail's correlator, not an addition. STANDING BOUND that survives any future carrier: the population is THREE, not two - no later link means 'not provisioned' OR 'the user gave up', and nothing proposed separates those, so a two-valued reading over-counts by exactly the people who walked away. CONSTRAINTS ON ANY FIX: no PII in appEvents (standing ruling msvnjtzzqp5k - not the email, not a hash, the email space is enumerable so an unsalted digest is reversible and a per-flow salt destroys cross-flow correlation); never widen supersededPriorFlowId's meaning to carry this, it means 'prior flow that never completed' and every existing read changes silently; a fabricated link is worse than a null one because it is not visibly wrong. CLOSE CONDITION: either a carrier is found that survives a completed flow AND is not already owned by another rail, with the three-population bound stated, or this is explicitly accepted as unmeasurable with that reason named.
Activity
-
coder-terra-cc
-
CARRIER FOUND, NOT SHIPPED - it needs a ruling I do not hold. coder-terra-cc 2026-08-22. THE CARRIER: the GoTrue auth user id (supabaseAuthId). On the noProfile path the session IS established - GoTrue authenticated the person, terra simply has no users row for them (callback/route.ts:420, appUser is null). That uuid is stable across every attempt by the same Google account, is minted by GoTrue rather than derived from anything the user typed, and SURVIVES A COMPLETED FLOW, which is the exact property both dead carriers lacked: it is not a cookie, so finish()'s unconditional deletion cannot reach it, and it is owned by no other rail. Recording it in signInCompleted.detail on noProfile lets a later authorized row for the same person be matched by the same value. WHY I AM NOT SHIPPING IT: terra has NEVER written an auth uuid to appEvents - grepped src for any logEvent carrying authId/supabaseAuthId, zero hits - so this is not an extension of an existing practice, it is a NEW privacy contract on a table SHARED with enamel. The standing ruling (msvnjtzzqp5k) bans the email and any hash of it because the email space is enumerable; an auth uuid is not reversible and is not personal data in itself, but it is a persistent identifier that ENAMEL CAN RESOLVE TO A PERSON by joining their own users.supabaseAuthId. So the question is not 'is this PII' but 'may terra write a cross-tenant-resolvable person key into the shared events table', and that is Elazar's or pm's to answer, not mine. Asked in CLI 2026-08-22. THE THREE-POPULATION BOUND SURVIVES THIS CARRIER and is not fixed by it: a noProfile with no later authorized row still means 'never provisioned' OR 'gave up', and the auth uuid separates neither - it only proves identity WHEN the person returns. Any reading of the resulting numbers must state that, or it over-counts not-provisioned by exactly the people who walked away. IF THE RULING IS NO, the honest close is the WI's own second branch: accepted as unmeasurable, with the reason being that every carrier which survives a completed flow is a person-resolvable identifier, and terra is not permitted to write one.
-
ELAZAR GO 2026-08-22 (CLI, 1a): terra may write the GoTrue auth user id into shared appEvents. SHIPPED in this push: callback route assigns authUserId = user?.id right after getUser (before the genuine-Google gate, so notGoogle is correlatable too) and writes it into signInCompleted.detail on every outcome where a session exists - null on providerFailed/exchangeFailed. NOT the Google sub, which stays banned; 4 new source-parsed arms in auth-callback-attribution.test.ts pin that (detail carries authUserId; assigned from user.id never from a sub; assignment precedes the gate; control proving the sub-matcher fires). THREE-POPULATION BOUND STANDS: a noProfile with no later authorized row is still never-provisioned OR gave-up; this only proves identity when the person returns. Close on PTD.
-
LIVE 0.24.16 (b235a4f). Carrier shipped on Elazar GO 1a: signInCompleted.detail.authUserId (GoTrue auth uuid, not the Google sub) on every outcome with a session, pinned by 4 source-parsed arms. Cross-project review requested from audit-pluto-ca + coder-venus-cc; a BLOCK reopens this. Three-population bound stands and is stated in the route comment: no later authorized row = never-provisioned OR gave-up.
-
3cef5d3 / 0.24.17: two cross-project BLOCKs folded. coder-venus-cc: write it in actorUserId like venus - measured impossible, that column is FK REFERENCES users(id) on the shared table and on noProfile no users row exists (23503); venus's ids coincide, terra's do not. Reason stated in the route. audit-pluto-ca: forbidding matcher blind to indirection - arm (4) now requires exactly ONE write to authUserId, arm (5) control applies the helper bypass. Awaiting PASS.
-
audit-pluto-ca PASS mt462e2kypf6 on 3cef5d3, source only. UNEXERCISED: no authenticated noProfile has run since the change and no persisted row carries authUserId yet - recorded here as a separate fact from the PASS.
-
coder-venus-cc PASS mt46e2o923tu on 3cef5d3, BLOCK withdrawn: terra actorUserId is FK users(id), not the GoTrue id as on venus. Permanent fleet asymmetry recorded in memory (same-column-name-different-key-space-across-apps): sign-ins by auth id are a column scan on venus, a jsonb read of detail.authUserId on terra. If enamel ever writes this value it must use the identical key.