4 untracked Terra access reports, 10 days open, noProfile - check registry before assuming absent
Live support-action access-list on terra-enamel.pensanta.com, 2026-10-11: 4 open noProfile reports, all createdAt 2026-10-01, never tracked in bwi, no bwi row referenced them. Reporters: matias.vanhaster@odontologia.uba.ar (body='N'), delape.camila@gmail.com ('Camila de la Peña docente esp implantologia mod 2'), aylentamyq@gmail.com ('Quiroz Aylen Tamara... Mi otro correo es aylentamyquiroz@hotmail.com.ar con ese me inscribí' - self-reported alternate address), rociobelenpiccinini10@gmail.com ('Belén piccinini, implantologia'). Per the TERRA-266 precedent (terra.md): noProfile often means an existing users row under a DIFFERENT emailCanonical, not a missing person - check each against vUsersAdmin/emailCanonical before assuming absent. Aylen's report names her own alternate address directly. Request: check all 4 against the registry; where an existing row matches (name/alt-email), fn_correctUserEmail; where genuinely absent, route to catedra-roster confirmation before any create (per terra.md - a docente grant to a non-docente is worse than the lockout). Resolve via support-action access-resolve once each is actioned; resolving does not grant sign-in (TERRA-242) - say so if relaying to reporters.
Activity
-
SELECT-only Enamel registry classification complete; three current profiles need Google retry/bind verification, one case needs catedra roster/strong-identity review. No report resolved or user written.
-
2026-10-11 db-enamel-ca SELECT-only on Enamel project eprpywqwzsvrjeaforei. Four open appKey=terra noProfile accessIssueReports checked against vUsersAdmin.emailCanonical, vUserGroups, userEmails, and report auth-ID binding. Three report addresses each match one live nonsynthetic unbound user with one live Terra grant; each has a closed prior email and current email written after the 2026-10-01 report. One reporter-provided alternate matches closed email history of the SAME current profile. Their report auth IDs match no other live bound user. No correction/create is indicated for those three; request fresh Google retry and verify bind/access, then resolve. Fourth report: no exact current/historical email match and no live surname-token candidate; route to catedra roster plus strong-identity check before create/grant. None of four report auth IDs is bound now. Counts only here; no raw IDs/emails or report text. No DML, no access-resolve, no user create/correction.
-
MARKER: terra-295-classification-relay. db-enamel-ca classification 2026-10-10T21:14Z: Camila/Aylen/Rocio each resolve to one live non-synthetic profile at report email, live Terra grant, supabaseAuthId NULL, closed prior-address history + post-report current-address write - no fn_correctUserEmail or create indicated, action is fresh genuine-Google retry + bind verification. Matias (Haster) has zero matching live row by email/history/name-token - not proof of no enrollment, routed to catedra roster/strong-identity confirmation before any create/grant. All 4 reports stay open pending verified outcome.
-
coder-terra-cc
-
MARKER: terra-295-routed. No outbound contact channel in this lane. Routed retry-notification + bind verification for the 3 current-address matches to support-evolutiva-cc. Routed catedra roster/strong-identity confirmation for Matias/Vanhaster to pmmaster-evolutiva-cc as blocked (same shape as TERRA-266/261 Vanhaster). Row stays inProgress pending both replies.
-
MARKER: terra-295-notify-blocked. support-evolutiva-cc: no reporter-contact channel exists except access-resolve's mail, dead on TERRA-260 (SMTP_REPLY_TO unset). Calling access-resolve now would burn the retry on an identical failure. Held for Camila/Aylen/Rocio until Elazar names the mailbox. Matias leg separately held pending Elazar per pmmaster. Row stays inProgress, both legs externally blocked.
-
access-resolve called for Camila/Aylen/Rocio, outcome=resolved, 2026-10-11 - all 200 OK. Resolution mail queues fresh (now that SMTP_REPLY_TO is live) telling them to retry Google sign-in; does not grant sign-in itself (TERRA-242). Matias stays open, routed to pmmaster for catedra roster confirmation before any create/grant. Note: the 4 original creation-time acknowledgement emails are permanently lost (attempts=6, pre-fix) - only the resolution mail just queued is new/live.