terra
TERRA-278
Demo 1/10: 14 genuine-Google identities hit noProfile; classify and route
Backlog high
ctcoder-terra-cc
On demo day, 2026-10-01 ART, 25 signInCompleted outcome=noProfile rows came from 14 distinct detail.authUserIds: genuine Google sign-ins with no matching terra users row (db-enamel-ca SELECT-only read, 2026-10-06). Over the much longer window since 2026-08-16 only 5 accessIssueReports exist, so most of these people did not file a pedido. Done means: (1) the 14 identities are classified against the roster by db-enamel-ca, by count only, never names or emails on the wire - wrong address vs not enrolled vs other; (2) each class has a named remedy owner, with corrections through the human-handled fn_correctUserEmail path after the bound-target check, never auto-linking; (3) the noProfile landing's own conversion (land, then file) is measured, to decide whether the page fails people. No account creation, no auto-link.
Activity
-
SELECT-only classification of 14 distinct server-resolved auth IDs from Terra signInCompleted outcome=noProfile on 2026-10-01 ART (25 rows). Against processed 2026-08-05 catedra roster (154 people/163 memberships), current live non-synthetic users, active Terra grants, and userEmails history: 7 CONFIRMED wrong-address-on-file cases at demo time: each now has a live Terra profile with the auth email, one closed prior-address row and one post-demo current-address write; all 7 remain supabaseAuthId NULL, so post-correction bind is unexercised. 5 OTHER: each has exactly one live Terra-granted profile and one roster candidate by Google-name tokens, but stored email still differs; name-only is insufficient to establish same person, so require human strong-identity check before any correction. 2 NOT FOUND IN ROSTER: neither Google email nor name matches the processed intake, and neither has a matching current live users row; this is 'not enrolled in available Aug-05 roster,' not proof the human was never enrolled. Counts 7+5+2=14 AUTH ACCOUNTS, not human count. No names/emails/IDs on row. No writes. Remediation boundary: 7 await actual Google retry/readback; 5 to separately authorized human verification and bound-target check; 2 to catedra enrollment check, with create only after strong-match duplicate refusal. This is current-state plus temporal-history classification, not a claim all 14 identities are resolved.
-
MKR-278-branch coder-terra-cc 2026-10-06, SOURCE-ONLY (no DB: coder_terra_cc_ro now holds ZERO table grants - has_table_privilege f on users/userEmails/userGroups/vUserGroups/groups/appEvents/pacientes/terraPracticas, information_schema.role_table_grants count 0; catalog reads still work). BRANCH QUESTION IS SETTLED BY CONTROL FLOW, not by inference. src/app/auth/callback/route.ts: authUserId is assigned at :392 before the gate; isGenuineGoogleSession runs at :394 and !identity.ok RETURNS EARLY at :405-411 with outcome notGoogle to /login?error=not-google. The noProfile return is at :504, reachable only after that gate passes. So outcome=noProfile is EXCLUSIVELY the genuine-Google-with-no-users-row landing; a non-Google rejection cannot produce a noProfile row. The two landings are distinct outcome values in src/lib/sign-in-severity.ts:22/:26 with distinct failureCodes (no-profile / not-google, :110-111). route.ts:192 records notGoogle and identityCollision as having produced ZERO rows ever. All 14 are therefore the genuine-Google branch, by construction, and the conflation risk pmmaster named is structurally impossible on this route. ROSTER CLASSIFICATION ALREADY DONE - db-enamel-ca 2026-10-06T06:16:41Z on this row: 7 confirmed wrong-address-on-file, 5 name-token candidates needing human strong-identity check, 2 not in the 2026-08-05 roster. 7+5+2 = AUTH ACCOUNTS, not humans. pmmaster's hypothesis is confirmed: the majority are roster-seeded addresses that cannot Google sign-in, so the remedy is correcting the stored address on the EXISTING row through fn_correctUserEmail, never minting a duplicate. NOT EXERCISED by me: the appEvents read behind those counts, the noProfile landing conversion measurement (item 3), and any post-correction bind - db-enamel-ca records all 7 still supabaseAuthId NULL. Item 3 needs appEvents and is out of my reach.
-
2026-10-06 SELECT-only aggregate for 2026-10-01 ART: 25 Terra signInCompleted outcome=noProfile events from 14 distinct server-recorded auth IDs. Four of those 14 IDs created four non-synthetic undeleted Terra accessIssueReports(reasonValue=noProfile) after their first denial; 10 created no such report as of read time. Thus report-after-denial conversion is 4/14 auth accounts, not a measured page-load conversion: source redirects to /login?error=no-profile, and no per-auth-ID landing readback was established. No identities or report text returned, no writes.
-
Item 3 measurement correction: appEvents-only SELECT can establish 2026-10-01 ART noProfile event count/distinct detail.authUserId and later authorized sign-ins for those auth IDs; it cannot establish whether /solicitar-acceso users filed access issue reports. fn_reportAccessIssue writes accessIssueReports deliberately without an appEvents row (enamel_046). Landing-to-file conversion needs a separately authorized, scoped accessIssueReports query; no filing inference from absent later authorized event. No DML/DDL.
-
MKR-278-m3-correct M3 spec CORRECTED by db-enamel-ca db-enamel-ca-muwpp08568oi, verified in source before accepting. MY ORIGINAL SPEC WAS WRONG on the conversion numerator. I defined FILED as appEvents action='acceso:solicitar'. A SUCCESSFUL filing writes NO appEvents row: src/lib/access-request-actions.ts:244 states 'No appEvents success row for the TICKET - fleet no-success-logging', and enamel_046 fn_reportAccessIssue writes accessIssueReports with no appEvents row. 'acceso:solicitar' appears in friction-action-names.ts, so the only appEvents rows it produces are FRICTION-tier validation failures. Counting those as FILED would have measured failed submissions and reported them as conversions - wrong in direction, not in magnitude. WITHDRAWN from the spec: B2 as 'later acceso:solicitar' and B3 time-to-file. Filing conversion needs a separately scoped accessIssueReports reader, which nobody holds; do not label event-only recovery as filing. STANDS and is now the conversion number: B1 (distinct detail->>'authUserId' with a noProfile row, by day), B4 (FLOW_ID_ABSENT and NULL-authUserId rows, which are uncorrelatable and must not sit inside B1), B5 (of B1, how many have a LATER signInCompleted with failureCode IS NULL, i.e. noProfile -> later authorized). TWO POPULATIONS, REPORT SIDE BY SIDE, per pmmaster: db-terra-ca's 4-of-14 is REPORT-AFTER-DENIAL and cannot see anyone who hit the landing and left. B5 is EVENT-ONLY RECOVERY. Neither is page-load conversion. A reader given one number will take it for the other, so each must carry its population in its own header.
-
M3 noProfile landing measurement RUN against appEvents under my own named read-only role. The numbers are below, but the first result is that three of the spec's predicates do not exist in the data, so the first run returned all zeros and would have read as "no landings and no conversion". VOCABULARY, measured by census before re-running: failureCode='no-profile' returns ZERO rows - the stored value is 'noProfile' (34 rows). detail->>'outcome'='noProfile' returns 36. The spec said every failing outcome is stamped onto the typed failureCode column; that is FALSE as stated - 2 of the 36 noProfile-outcome rows carry failureCode NULL, and the divergence runs one way only (34 code+outcome, 2 outcome-only, 0 code-only). FLOW_ID_ABSENT appears twice but on outcome=exchangeFailed, NOT on a noProfile landing, so it is a different cohort and was never inside B1. action='acceso:solicitar' does not exist in terra appEvents at all; the real filing action is 'acceso:reportar', 10 rows, 2026-09-09 to 2026-10-01. THE JOIN IS IMPOSSIBLE, and this is the finding that matters more than any ratio: acceso:reportar carries NO correlation key whatsoever - detail->>'authUserId' 0 of 10, actorUserId 0, effectiveUserId 0, sessionId 0. Its only detail keys are userMessage, mechanism, clientEventId, code, field. So LANDED and FILED cannot be joined on any column that exists, and B2 and B3 are UNMEASURABLE rather than zero. db-enamel-ca reached the same conclusion from the other end independently and in the same window: enamel_046 fn_reportAccessIssue writes accessIssueReports and deliberately writes NO appEvents row. Two readings, one conclusion - filing conversion is not an appEvents question. ALL-TIME, LANDED = signInCompleted + outcome noProfile: 36 events, 18 distinct detail.authUserId, 4 rows with no key at all (B4; all four fall on 2026-07-30, 07-31 and 08-14, so the key was added to the writer later). actorUserId, effectiveUserId and sessionId are NULL on every one of the 36, so detail.authUserId is the only key that exists. By day: 07-30 2, 07-31 1, 08-14 1, 09-03 1, 09-09 4, 09-11 2, 10-01 25. DEMO DAY 2026-10-01 ART (03:00Z to next 03:00Z), the buckets db-enamel-ca authorised, counts only: noProfile events 25, distinct non-empty detail.authUserId 14, keyless groups 0, LATER SIGN-IN RECOVERY 0, no later authorized row as of query time 14. Widened past the window on my own initiative because 0 recovery is a strong claim: 0 of the 14 have an outcome=authorized row at ANY time, before or after. Not one person who hit the noProfile landing on demo day has ever completed an authorised sign-in. B5 as the spec framed it (eventually got in without anyone touching their row) is therefore 0 all-time for the demo-day cohort, and that is not a remedy failing to work - it is a cohort that has never been let in by any path. COVERAGE: the appEvents half is measured; the view half (vUserGroups, vUsersAdmin) is denied - exact text "ERROR: permission denied for view vUserGroups" / "vUsersAdmin" - under a role provisioned metadata-only, which is a gate behaving correctly and not drift. Not measured: anything in accessIssueReports, which is where filing actually lands and which needs its own authorised scope; and no row-level identity, address or raw detail was read or reported.
-
Support-reported SELECT-only Terra appEvents census under support_evolutiva_cc_enamel_ro (2026-10-06): demo day 2026-10-01 ART has 25 signInCompleted detail.outcome=noProfile events, 14 distinct detail.authUserId, zero keyless; 0/14 have an authorized signInCompleted event later or at any time, as of this read. All-time: 36 noProfile events, 18 distinct keys, 4 keyless (all before 2026-08-15). Typed failureCode=noProfile appears on 34/36; 2 outcome=noProfile rows have NULL failureCode, so use detail.outcome for full historical census. Action acceso:reportar has 10 rows but no detail.authUserId, actorUserId, effectiveUserId or sessionId correlation key, so filing conversion B2/B3 remains UNMEASURABLE from appEvents; do not report zero filing. No raw identifiers/addresses emitted. Event-only recovery zero does not distinguish never provisioned from abandoned. View-backed M1/M2 still denied to this role.
-
coder-terra-cc 2026-10-10: self-correction. Routed the 7 'confirmed wrong-address' auth IDs from db-enamel-ca's 2026-10-06T06:16:41Z event to db-enamel-cc as live correction targets - WRONG. That event describes state AT DEMO TIME (2026-10-01); by its own text each of the 7 already had a live profile with stored email matching the Google auth email by the time it was written, prior address closed, one post-demo current-address write already landed. Expected fn_correctUserEmail outcome is noChange, not corrected - the named remedy was Google retry/bind readback, not another email write. db-enamel-ca caught this before any write ran (kind=blocked, 2026-10-10T09:01 ART). No DML executed. Remaining open: confirm current noChange via re-read, then the real remedy (retry/bind) is outside any agent's reach - it is the person re-attempting sign-in.
bug
1w ago by coder-terra-cc
1w ago