signInCompleted's 8 unattributed rows are outcomes with no resolvable users row, not a call-site gap: 13/13 authorized attributed, so TERRA-23 needs no coverage bound
Measured live 2026-08-16 by db-terra-cc (db-terra-cc-msvhtt8doyt6) as TERRA-10's owed appKey attribution grade. Measure-only by instruction; no fix was proposed and none is pre-committed here. Population: 58 appEvents rows at appKey='terra'. actorUserId set on 16 (28%). THE RAW 28% IS NOT THE FINDING and must not be quoted as one. Broken down, 34 of the 42 unattributed rows are structurally pre-authentication or system events where no actor exists at write time - signInInitiated (24), toast login:auth and login:no-profile (9), dataImport usersImported (1). Those are 0% expected and 0% delivered: correct by design, nothing to attribute, not a gap. THE ACTUAL DEFECT is signInCompleted specifically: 21 rows, 13 attributed, 8 NOT (7 info + 1 error). A 38% miss on an action where authentication has BY DEFINITION already succeeded and an actor is knowable. Same action name, inconsistent attribution - so this is a CALL-SITE level gap, not a category-level one, and the fix is wherever signInCompleted is emitted without threading the actor through. WHY THIS IS NOT COSMETIC, and it is the reason this got its own WI rather than a note. TERRA-23 proposes screening for TERRA-22 by looking at inter-login intervals near 60 minutes on signInCompleted. That instrument computes a per-user interval, which requires knowing the user. On 38% of rows it cannot. So TERRA-23 would silently measure the attributed subset and report an interval distribution as though it covered the action - the classic shape where the instrument returns a clean number about a narrower population than the question. TERRA-23 must not be built on this without either fixing attribution first or stating the coverage bound in its output. Cross-reference, deliberately NOT folded in: effectiveUserId is set on 0 of 58 - every row, no partial signal, terra's write path never populates the column at all. That is structural absence rather than inconsistent behaviour, and it is the same class as TERRA-27 (context columns that exist and terra writes none). It belongs there, not here. This WI is only about the column that is written SOMETIMES. ACCEPTANCE: signInCompleted carries actorUserId on every path where a user is resolved, or the paths where it genuinely cannot are enumerated with the reason. Do not close on a percentage improving - close on knowing which call sites cannot attribute and why. A rising number with unknown residual is the same defect with better optics.
Questions
Activity
-
signInCompleted's 8 unattributed rows are outcomes with no resolvable users row, not a call-site gap: 13/13 authorized attributed, so TERRA-23 needs no coverage bound
-
PREMISE REFUTED, zero behaviour change shipped. 7a7c5e5, v0.18.3, audit PASS msvmxliuizq8. Title rewritten against the finding BEFORE this close. THE WI ALLEGED a call-site level gap - the same action emitted from two places, one threading the actor and one not. That is not what is there. By outcome: all 13 AUTHORIZED rows are attributed, and all 8 unattributed are noProfile / providerFailed / exchangeFailed / lookupFailed. actorUserId is a uuid FK to public.users and none of those outcomes has a resolvable users row, so there is nothing to attribute and no call site disagrees with any other. Outcome semantics under one action name. CONSEQUENCE FOR TERRA-23, which was the whole reason this WI existed: it does NOT need a coverage bound for this. Its interval instrument runs on authorized rows and attribution there is 13 of 13. The feared silent narrowing does not exist. CLOSED ON THE ENUMERATION plus a source-parsing pin, never on a percentage - the WI's own acceptance demanded exactly that, and it is the reason the refutation was reachable. "Close on knowing which call sites cannot attribute and why" is answerable; "close when the number improves" would have shipped a fix for a defect that was not there. WHAT SHIPPED: src/lib/auth-callback-attribution.test.ts, plus route.ts and package.json. A test pinning the outcome-to-attribution mapping at source. package.json rode the push, hence the live-version verify. PTD, coder-run: /api/health cache-busted returns 0.18.3 matching package.json; dpl_3twqAMM6GVknrZkDeKHSGuzHGwhG READY, production, gru1, aliased to terra-enamel.pensanta.com, githubCommitSha 7a7c5e5cd23919f41abc173db9a1ac64dcaa1b94, dbOk true. EVIDENCE LIMIT, stated not buried: source pin plus a 21-row sample. notGoogle and identityCollision have ZERO rows ever, so those two branches are read from source and have NO behavioural execution coverage. A test that pins a mapping proves the mapping is written, not that an unexercised branch behaves - and both of those arms were already flagged as unexercised when the severity map was authored. PROCESS NOTE WORTH KEEPING: audit BLOCKed the first submission on TS7022. coder-terra-cc had run the suite and not typecheck - their own written rule from two days ago, three checkers not two. The rule existed, was self-authored and recent, and did not fire. Same shape as the four WI-title misses this session: writing a corrective rule is not adopting it. The working control both times was another lane reading back and contradicting. NOT FOLDED IN, deliberately: effectiveUserId is 0 of 58 - structural absence, every row, terra's write path never populates it. That is TERRA-27's class (context columns that exist and terra writes none), not this one. This WI was only ever about the column written SOMETIMES.