Pedidos de acceso sin perfil: codigo y deploy completos; falta ejercicio autenticado real

Sub-tickets

Activity

• wi-cli-venus created · 2026-08-16
• wi-cli-venus blocked · 2026-08-16
  Blocked on Elazar: who is 'la coordinacion' (the COORDINATION_GROUP recipient). Open since the TERRA-13 mail work; not a new question and not re-escalated here.
• wi-cli-venus commented · 7w ago
  c5d2828 LIVE: /administrar renders the open accesoCuenta queue via the shared resolveScopedSupportTicketsStaffQueue('terra'), status NOT IN (resolved,closed); failed read renders as a stated failure, never as an empty queue. This is the PULL half - awareness no longer depends on the undecided COORDINATION_GROUP. The WI stays blocked on Elazar for the mail recipient; what it is blocked on is now smaller: nobody is un-notified-and-invisible, only un-emailed. Table has 0 rows across every app, so the queue renders empty and is UNEXERCISED against real data.
• wi-cli-venus commented · 7w ago
  RECIPIENT HALF DONE, live v0.24.44 dpl_5VQiK3gNBN6RpuDnKyYD8TJiBGTt. Elazar ruled the recipient is elazar.pimentel@pensanta.com - a PERSON, so it went into a new COORDINATION_EMAILS literal, NOT COORDINATION_GROUP, which feeds a vUserGroups.group predicate and would have matched zero rows and reported none ("everybody who was subscribed is gone"). STILL BLOCKED, and the blocker CHANGED rather than cleared: prod has no SMTP_USER/SMTP_PASS (vercel env ls production = 5 names, none mail), so readMailConfig returns missingCredentials and the outcome is missingConfig. Deciding who is notified and being able to reach them are two blockers; one is cleared. What is needed from Elazar: SMTP credentials (a Gmail app password on a mailbox whose send-as matches SMTP_FROM, or another provider). Until then the PULL half on /administrar is the only working path, and that page now says so accurately.
• wi-cli-venus blocked · 7w ago
  Needs SMTP_USER/SMTP_PASS in Vercel prod env from Elazar. Recipient question answered 2026-08-22 and shipped in v0.24.44; the remaining blocker is credentials, not a decision about who.
• wi-cli-venus commented · 7w ago
  BLOCKER RE-MEASURED AND NARROWED TO TWO ENVIRONMENT VARIABLES, 2026-08-23 by coder-terra-cc. `vercel env ls production` returns exactly five names - TERRA_PROBE_TOKEN, NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY, IMAGE_API_KEY, DATABASE_URL, NEXT_PUBLIC_SUPABASE_URL - and none is SMTP_*. So readMailConfig() returns missingCredentials, sendGuarded takes a no-socket branch, and every notification is a ledger row for a mail that was never attempted. Confirms the 2026-08-16 reading rather than inheriting it. THE REST OF THE CHAIN IS WIRED AND WAS RE-READ END TO END, not assumed: /sin-acceso -> requestTerraAccess (schema-qualified) -> fileAccessRequest -> notifyAccessRequest -> notifyAccessRequestCore -> sendGuarded -> filterRecipients -> nodemailer. resolveCoordinationRecipients returns {ok:true} today because COORDINATION_EMAILS holds elazar.pimentel@pensanta.com since v0.24.44. Nothing in terra's code is missing. EXACTLY WHAT IS NEEDED, and nothing more: SMTP_USER = the Gmail/Workspace mailbox that AUTHENTICATES SMTP_PASS = a Gmail APP PASSWORD for that mailbox, never the account password Set on the Production environment of prj_HTTOJEAeVtjuJ3BJMYvyck2xmYaq. Setting env vars is a config action and is permitted to this lane; the credential itself is Elazar's to supply. DO NOT SET SMTP_HOST OR SMTP_PORT. They default to smtp.gmail.com:587 and SMTP_HOST is ALLOW-LISTED to exactly that one value - setting them adds a way to be wrong and buys no capability. A non-member value is a hard failure by design, not a fallback. SMTP_FROM ALSO STAYS UNSET UNLESS A VERIFIED SEND-AS EXISTS. It defaults to SMTP_USER, which is the only value Gmail cannot silently re-stamp. An SMTP_FROM that is not a verified send-as on the authenticating mailbox makes the address in the config a fiction and the failure invisible in every log terra owns. ONE STALE COMMENT FIXED IN PASSING, 55046c4: access-request-actions.ts justified offering no out-of-band contact route by citing COORDINATION_GROUP === null. Still literally true, no longer the reason - the recipient is decided, the transport is what is missing. The conclusion survived its premise, which is the shape that passes a spot-check and leaves the reader believing an answered question is still open. STILL TRUE AND NOT CLOSED BY ANY OF THIS: shipping the mailer makes coordination AWARE. It does not make anyone answer, and the page's promise is that someone will. The register received today does not answer who "la coordinación" is either - it is an enrolment record.
• wi-cli-venus commented · 7w ago
  CONFIGURED AND DEPLOYED, NOT YET PROVEN TO SEND. Both halves stated because a green deploy looks like proof and is not. DONE 2026-08-23. Four Sensitive variables on Production of prj_HTTOJEAeVtjuJ3BJMYvyck2xmYaq: SMTP_USER elazar.pimentel@pensanta.com SMTP_PASS Gmail app password, already in Elazar's ltm (Venus SMTP block, in use by pluto and venus since 2026-05-05). No new secret minted, none written to a tracked file. SMTP_FROM soporte-evolutiva-terra@pensanta.com (verified send-as alias, provisioned by Elazar today) SMTP_FROM_NAME Soporte Terra SMTP_HOST and SMTP_PORT deliberately unset: they default to smtp.gmail.com:587 and SMTP_HOST is allow-listed to exactly that one value, so setting them adds a way to be wrong and buys no capability. Shipped in two deploys because an env var does nothing until a build reads it: f6f755a v0.24.52 (picks up USER/PASS) and 6ab0c2a v0.24.53 (adds SMTP_FROM_NAME support). Both live-verified on /api/health. SMTP_FROM_NAME IS NEW CODE AND EXISTS FOR A REASON THAT IS NOT COSMETIC. Venus stores the whole RFC5322 string in SMTP_FROM. Copying that shape into terra fails twice: checkRecipient() rejects `Name <addr>` as malformed and returns invalidFrom, blocking every send - loud, catchable. The second failure is the dangerous one: transport-core builds knownAddresses = [...to.allowed, config.from, replyTo] and uses it to REDACT addresses out of SMTP error text before it reaches an appEvents ledger row. A display-name string in config.from stops matching the bare address, so the redaction silently leaks the value it exists to hide. config.from therefore stays bare; the name composes only at the sendMail call. The resolver is a fail-closed ALLOWLIST because nodemailer builds the From line from this string and a CR/LF is header injection into every message terra sends. 7 arms, 40/40 green, including a must-fail control that confirms a permissive stand-in accepts the CRLF payload the shipped resolver refuses. WHY THIS ROW DOES NOT CLOSE, and it is the same structural fact recorded at 15eb713 rather than a new problem: THE NOTIFY PATH HAS NO ELIGIBLE CALLER. requestTerraAccess admits only a user with ZERO terra memberships. Measured live today: 159 users, roleless_for_terra = 0. So nothing in production can reach /sin-acceso -> notify, and no mail has been attempted. Nodemailer, Gmail auth, the alias's send-as verification and delivery are ALL unexercised. THE ALIAS BEING CORRECT IS ELAZAR'S STATEMENT, NOT TERRA'S MEASUREMENT, and Gmail RE-STAMPS an unverified From silently - so if the send-as were not actually verified, terra's logs would show a successful send and the recipient would see a different From. That is precisely the failure this configuration cannot detect on its own. TO CLOSE, ONE OF: (a) Elazar signs in with a Google account holding no terra membership and files a request from /sin-acceso - the natural exercise, and it also proves the alias; (b) a deliberate test user with zero terra memberships, which needs a write to the SHARED users table and therefore db-enamel-cc, not this lane. Until one happens the honest status is CONFIGURED, UNEXERCISED.
• wi-cli-venus unblocked · 7w ago
  Credentials landed - the blocker named in blockedReason (SMTP_USER/SMTP_PASS from Elazar) is resolved and all four mail variables are set and deployed. Not done: no mail has been sent, because the notify path has no eligible caller (roleless_for_terra = 0 of 159, measured today). Moves to inProgress rather than done - closing here would close on configuration while the WI's actual subject is that a filed request notifies somebody.
• wi-cli-venus commented · 7w ago
  v0.24.54 live: /api/health now carries mailOk/mailError/mailFromName. Measured against prod 11:04 UTC - mailOk:true, mailError:null, mailFromName:true. That proves the RUNNING build carries SMTP_USER, SMTP_PASS, SMTP_FROM and SMTP_FROM_NAME, and that SMTP_FROM passes checkRecipient as a bare address. Why it was in doubt: the alias vars were added to Vercel production at ~10:47 and the v0.24.53 deployment was created 10:47:22, the same minute, and Vercel binds env at build time. STILL UNPROVEN and it is the whole of what remains: that soporte-evolutiva-terra@pensanta.com is a VERIFIED send-as on the authenticating mailbox, and that a real message leaves and arrives. Gmail silently re-stamps an unverified From, so neither this field nor any log terra owns can see that failure - it is Elazar's operator statement, never terra's measurement. Close condition unchanged: sign in with a Google account holding no terra membership and file a request from /sin-acceso.
• wi-cli-venus assigned · 7w ago
  coder-terra-ca
• wi-cli-venus titleChanged · 6w ago
  Access-request notification path is CONFIGURED but never exercised: no roleless Terra account exists to file one, so delivery has never been observed end to end
• wi-cli-venus blocked · 6w ago
  --agent
• wi-cli-venus blocked · 6w ago
  No roleless terra account exists, so an access request cannot be filed and the notification path has never been exercised end to end. The configuration is present; what is missing is a caller. This sat in inProgress with nobody on it - reconciled to blocked, which is what it actually is, so it stops reading as work in flight.
• wi-cli-venus note · 6w ago
  Two additions, both verified at source by me before filing. Found by audit-terra-ca on a comment-to-backlog sweep, 2026-08-31. ONE, a decision this row does not yet name. src/lib/email/recipients.ts settles WHO is notified today and explicitly leaves the standing rule open. COORDINATION_EMAILS is the literal ["elazar.pimentel@pensanta.com"], and COORDINATION_GROUP is null with the comment stating that null is "not 'no group', but 'the question has not been answered'" - the standing subscription rule. This row currently tracks only that a configured delivery path has never been exercised end to end. That is a different fact from a deferred decision about who "la coordinación" durably IS, and the deferred decision has no home. It belongs here rather than in a new row: splitting one notification-recipient semantic across two rows is how the two halves stop being read together. Either the named-person literal is ruled permanent, or a group is named - and that is Elazar's, same as the rest of this row. TWO, and this one is a stale comment that will mislead the next reader. src/lib/support-queue.ts:9-12 states, of the access-request path, that "no recipient was decided in email/recipients.ts because who 'la coordinación' IS has never been ruled, so resolveCoordinationRecipients returns sourceUndecided unconditionally and no mail has ever been sent - including on the success path." The first two clauses are now FALSE. recipients.ts records the ruling of 2026-08-22 and resolveCoordinationRecipients returns the literal on its FIRST branch, before the null-group check ever runs; sourceUndecided is unreachable while COORDINATION_EMAILS is non-empty. The conclusion survives - no mail sends - but for an entirely different reason, missing SMTP credentials in production, which is a delivery blocker rather than a decision blocker. A comment that gives the right outcome from a dead cause is worse than one that is simply wrong, because the outcome checks out and nobody re-reads the cause. Routing note: audit-terra-ca recommended attaching the stale comment to TERRA-111. I did not. TERRA-111 is about onboarding users on non-Google addresses and does not own comment cleanup in this file cluster. It goes here, with the file it describes.
• wi-cli-venus descriptionChanged · 6w ago
  was: MEASURED by coder-terra-cc 2026-08-16 while scoping TERRA-41: src/lib/email/recipients.ts:66 holds 'const COORDINATION_GROUP: string | null = null', so resolveCoordinationRecipients returns sourceUndecided UNCONDITIONALLY and no mail is ever sent - including on the SUCCESS path. A user who successfully files an access request is told 'la coordinacion la va a responder' and nobody is notified. The supportTickets row is the entire channel, and whether anyone reads it is a separate unmeasured question. WHY ITS OWN ROW AND NOT PART OF TERRA-41: coder-terra-cc's call and I agree with the reason. TERRA-41 is about a FAILURE-path toast that does not tell the user their request was not filed. This is a SUCCESS-path promise with no transport behind it. Folding them means one closes and the other is quietly still open, which is the shape terra keeps rediscovering. Two defects, two rows. BLOCKED, and on a question already open rather than a new one: terra cannot pick a recipient because 'who is la coordinacion' has been on Elazar since the TERRA-13 mail work. Nothing here is buildable until that answers - this row exists so the consequence is visible and filed rather than living as a comment acknowledging its own gap. DO NOT FIX BY SOFTENING THE COPY ALONE. Changing the success message to stop promising a response would make the app honest and would ALSO silently retire a commitment to the user that nobody decided to drop. The promise or the transport is a product decision, not a wording cleanup.
• wi-cli-venus verified · 6w ago
  HALF OF (c) IS NOW MEASURED AND IT RESOLVES IN FAVOUR OF THE PATH. Fact (c) held two unknowns bundled as one blocker - no caller, and unverified SMTP credentials in production. The second is now verified PRESENT, so the blocker narrows to exactly one thing. MEASURED 2026-09-01 against the live deployment, not against source: /api/health on v0.30.87 returns mailOk true, mailError null, mailFromName true. mailOk is health-route.ts:73 reporting readMailConfig().ok, so a true there means the RUNNING BUILD carries valid SMTP configuration; mailFromName true additionally means the verified send-as alias display name reached this build. Both were false-or-absent at the last recorded measurement. SO THE REMAINING BLOCKER IS THE CALLER, AND ONLY THE CALLER. Recipient decided (fact (a), the COORDINATION_EMAILS literal, first branch of resolveCoordinationRecipients). Transport configured (this measurement). What is still missing is a roleless Terra account able to file an access request, which is what the title already says and what blockedReason should now say alone. Fact (b), the durable subscription rule, is untouched and still Elazar's. AND THERE IS A SECOND STALE COMMENT, of the same class this row already documents. src/lib/email/recipients.ts:13-19 asserts in present tense: THE MAIL STILL DOES NOT SEND, prod carries no SMTP_USER/SMTP_PASS, measured against vercel env ls production 2026-08-22, so readMailConfig returns missingCredentials and the outcome is missingConfig. Every clause of that was true on 2026-08-22 and the credentials landed inside the following ten days. It now asserts a false present-tense fact. WHAT MAKES THIS ONE WORTH NAMING RATHER THAN JUST FIXING. health-route.ts:59-72 states, in its own words, that mailOk exists BECAUSE Vercel binds env at build time and terra had NO WAY to tell whether the running build carries the vars. The field was purpose-built to detect this exact transition. It detected it. Nobody read it back against the prose that motivated building it. A measurement instrument does not update the claims it was built to supersede - that step has no owner. And the decay is invisible precisely BECAUSE the comment is rigorous: it names its method, its date and the resulting enum value, and that specificity reads as freshness, which is what stops a reader spending one curl on the health route. THIS ROW ALREADY CARRIES THE SAME PATTERN ONCE, in the SUPERSEDED paragraph about support-queue.ts:9-12 reaching a correct outcome from a dead cause. That is now TWO stale mail-related comments in scope here, from two different dead causes, both still reading as current. Routed to coder-terra-ca as a fold-in, explicitly not worth a version of its own. BOUND, and it is not a small one. mailOk proves the CONFIG parses in the running build. It does not prove a message has ever left, that credentials authenticate against the SMTP host, or that anything arrives. Nothing has been sent on this path, so transport remains untested end to end - config-present and delivery-works are two different claims and this measurement supports only the first.
• wi-cli-venus blocked · 6w ago
  No roleless terra account exists, so an access request cannot be filed and the path has never carried a message. This is now the ONLY blocker: recipient decided (COORDINATION_EMAILS literal), SMTP config verified present in the running build 2026-09-01 (health mailOk true, mailFromName true, v0.30.87). Config-present is not delivery-works - nothing has been sent, so transport stays untested end to end.
• wi-cli-venus commit · 6w ago
  Corrected support-queue historical rationale: the former sourceUndecided reading is superseded by the 2026-08-22 COORDINATION_EMAILS ruling. It now preserves the unexercised access-request and delivery limits without claiming no mail is ever sent. Commit b6e09bb pushed.
• wi-cli-venus note · 6w ago
  MEDICION REFRESCADA POR MI 2026-09-01T07:24:41Z, no citada. La razon de bloqueo de esta fila apoyaba la mitad de configuracion en una lectura de salud del 2026-09-01 sobre la version 0.30.87. Hoy corre la 0.31.28, o sea que la cifra estaba fechada contra un build que ya no es el que atiende. GET https://terra-enamel.pensanta.com/api/health: version 0.31.28, deploymentId dpl_3wKBsb5EuVjMavfuCic4d6BNGSEL, dbOk true, mailOk true, mailError null, mailFromName true. ALCANCE DEL INSTRUMENTO, y lo escribo porque una cifra sin su alcance es la forma en que esta misma fila se leyo mal antes: mailOk sale de readMailConfig en src/lib/email/transport-core.ts, que LEE LAS VARIABLES DE ENTORNO y valida su forma - credenciales presentes, host, puerto, direccion de origen - y devuelve un enum cerrado de codigos cuando falta algo. NO ABRE CONEXION SMTP Y NO MANDA NADA. Queda establecido que el entorno de produccion vivo tiene hoy SMTP_USER y SMTP_PASS con forma valida. NO queda establecido que un mail salga, que es literalmente el titulo de esta fila. EL BLOQUEO NO CAMBIA Y SIGUE SIENDO UNO SOLO: no existe una cuenta terra sin rol que pueda presentar una solicitud, asi que el camino nunca llevo un mensaje. Configuracion presente no es entrega funcionando, y la distancia entre las dos es exactamente lo que esta fila mide. EFECTO EN TERRA-111, que apuntaba aca: corregi ahi un parrafo mio del mismo dia que declaraba este estado NO MEDIBLE por no haber CLI de vercel en este host. Habia con que medirlo y era este endpoint. La regla que queda anotada en las dos filas: "no tengo con que medirlo" casi siempre significa "no con la herramienta que se me ocurrio primero", y antes de declarar algo no medible hay que preguntar que instrumento observa ese sistema.
• wi-cli-venus audit-finding · 6w ago
  THE BLOCKER AS WRITTEN IS REFUTED, MEASURED 2026-09-03. The row said no roleless terra account exists so a request cannot be filed. Terra ALREADY HAS the roleless arrival and already logs it: appEvents carries action login:no-profile, categoryValue toast, FOUR times - 2026-07-30 10:02, 2026-07-30 10:15, 2026-07-31 12:22 and 2026-08-14 07:12:45. The last one is the client himself: it is the same minute the consultas document cites for his 2026-08-14 07:12 attempt with puia.sebas@gmail.com, eight days before that alumno row was created. So a person with a Google identity and no profile HAS reached terra four times and the app noticed each time. What has NEVER happened is the next step: there is no access-request event of any kind in the entire terra series - no request, no admin-email, no failure. The gap is not that nobody can arrive roleless; it is that nobody who arrived has filed, or that filing is not instrumented. Those are different repairs and nothing here distinguishes them. THIS CAME FROM coder-mars-cc, who challenged the premise rather than answering the question as asked: mars holds no test identity either, because roleless-with-a-Google-identity is the normal state of every unprovisioned student, and mars sees them as auth/login-unknown at /callback. Their advice was to check for the equivalent event BEFORE manufacturing a test account. That check is the paragraph above and it changed the row. MARS SHAPE, for whoever builds this: the request row is inserted FIRST, then admins are mailed with Promise.allSettled over the recipient list so one bad address cannot reject the batch or lose the other sends; rejections are written as a WARN event naming the failed addresses; there is NO retry - a failed notification is a logged fact. A second, independent in-app notification channel does not depend on SMTP at all, and the DB row is the SSOT. Mars's evidence is 13 access-request events, most recent 2026-08-27, and zero email-failed rows ever - and they stated the limit themselves: allSettled only rejects on transport refusal, so a provider that accepts and drops looks identical to success. THE INSTRUMENT: verify by EXECUTION, not inspection - file one real request and read the rows. Config-loaded (health mailOk/mailFromName) proves strictly less than that and should not be cited as delivery evidence. ONE THING I DID NOT MEASURE and it decides whether a personal gmail can even reproduce this: mars deliberately admits ANY genuine Google identity, so a personal account works there. I have not read what terra's gate does, and if terra keys on a domain, a personal account will not reproduce the path. SECONDARY DEFECT: those four login:no-profile rows carry NULL actorUserId, message, route and path. The event fires but names nobody and nothing, so it cannot be correlated to a person or a screen - it proves arrival and nothing else.
• wi-cli-venus unblocked · 6w ago
  Unblocked 2026-09-03: the stated blocker was false. Roleless arrivals already happen and are already logged (4 login:no-profile events, last one the client on 2026-08-14). No test account needs manufacturing. Next step is execution, not analysis: read terra's login gate to see whether a personal Google account is admitted, then file one real request and read the resulting rows.
• wi-cli-venus audit-finding · 6w ago
  THE FUNNEL, AND WHERE IT ACTUALLY BREAKS. coder-mars-cc reframed the zero: four arrivals and zero filings is not an unused path, it is a 100% drop between landing and submit, shipping since 2026-07-30, and it caught the client himself. They pointed at MARS-369 as the prerequisite - until a REJECT writes a row, someone who abandoned and someone the form refused are the same silence, and the repair differs completely. THAT PREREQUISITE IS ALREADY MET IN TERRA AND I CHECKED BEFORE ADOPTING THE ADVICE. Every refusal in requestTerraAccess throws ActionError with an explicit tier - warn for no session, info for already-a-member, info for empty reason, info for over-length - and createWithAction in src/lib/action-core.ts logs every non-null tier through logError before returning the friendly string. Terra does not have mars's silent-reject gap. THEREFORE THE ZERO MEANS SOMETHING SHARPER THAN MARS ASSUMED: a full census of terra appEvents by categoryValue and action returns 13 distinct actions and NOT ONE of them is acceso:solicitar, at any level. Not a success, not a reject, not a warn. The action has never been ENTERED. The drop is upstream of the server action entirely - at /sin-acceso, in the client component, or in whether those four people ever reached that page at all. Instrumenting the reject path would have measured a path nobody reaches. ORDER, REVISED FROM WHAT MARS PROPOSED AND FOR A REASON THEY COULD NOT SEE: not log-rejects-then-file. The reject logging exists. What is missing is a row proving the PAGE was reached, which is the same defect as the NULL actorUserId on login:no-profile - terra can prove someone arrived and cannot say who or where they went. Close that first, then file one real request. NOT MEASURED: whether /sin-acceso renders the form for a session with no profile, or whether those four were redirected elsewhere before seeing it. I read the action, not the page.
• wi-cli-venus descriptionChanged · 6w ago
  was: THREE DISTINCT FACTS LIVE IN THIS ROW AND THEY MUST BE READ SEPARATELY, because the first one changed on 2026-08-22 and the row's original text still described the world before it. (a) WHO IS NOTIFIED TODAY: a named literal, decided. src/lib/email/recipients.ts holds COORDINATION_EMAILS = ["elazar.pimentel@pensanta.com"] and resolveCoordinationRecipients returns it on its FIRST branch. That is the ruling of 2026-08-22 and it is live in source. (b) THE DURABLE SUBSCRIPTION RULE: still open, and it is Elazar's. COORDINATION_GROUP is null, with the source comment stating that null means "not 'no group', but 'the question has not been answered'". Either the named-person literal is ruled permanent or a group is named. This deferred decision has no other home and is deliberately kept in this row rather than split off - separating one notification-recipient semantic across two rows is how the halves stop being read together. (c) DELIVERY: never exercised end to end, which is what the title is about and what keeps this blocked. No roleless Terra account exists, so an access request cannot be filed and the configured path has never carried a message. SMTP credentials in production are also unverified. The configuration is present; what is missing is a caller. SUPERSEDED, RECORDED RATHER THAN DELETED. This description previously stated, from a 2026-08-16 measurement by coder-terra-cc, that COORDINATION_GROUP being null made resolveCoordinationRecipients return sourceUndecided UNCONDITIONALLY, so no mail could ever be sent including on the success path. That was true when written and is FALSE now: the literal short-circuits ahead of the null-group check and sourceUndecided is unreachable while COORDINATION_EMAILS is non-empty. src/lib/support-queue.ts:9-12 still carries the old rationale verbatim and is stale in the same way - it reaches the correct outcome (no mail sends) from a dead cause (no recipient decided) rather than the live one (no caller, unverified SMTP). A comment that gives the right outcome from a dead cause is worse than one plainly wrong, because the outcome checks out and nobody re-reads the cause. Fixing that comment is in scope for this row. WHY ITS OWN ROW AND NOT PART OF TERRA-41, unchanged and still the reason: TERRA-41 is a FAILURE-path toast that does not tell the user their request was not filed. This is a SUCCESS-path promise with no transport behind it. Folding them means one closes and the other is quietly still open, which is the shape terra keeps rediscovering. DO NOT FIX BY SOFTENING THE COPY ALONE. Changing the success message to stop promising a response would make the app honest and would ALSO silently retire a commitment to the user that nobody decided to drop. The promise or the transport is a product decision, not a wording cleanup.
• wi-cli-venus titleChanged · 6w ago
  Cuatro personas llegaron sin perfil y ninguna pidio acceso: cero eventos acceso:solicitar en toda la serie, y como los rechazos ya se registran, la caida esta aguas arriba de la accion
• wi-cli-venus assigned · 5w ago
  coder-terra-cc
• wi-cli-venus verified · 5w ago
  MEDIDO 2026-09-05, pedido por pm-terra-cc como la mitad que le faltaba a TERRA-207. Read-only, sin cambios de codigo. HAY DOS POBLACIONES SIN ACCESO Y SOLO UNA TIENE SALIDA. La separacion es deliberada y correcta (ruling ms722qkwf9c5); lo que no esta bien es que una de las dos ramas nunca se termino. RAMA A - tiene fila en users, cero membresias terra. auth/callback/route.ts:497 manda a /sin-acceso. Esa pagina SI funciona: renderiza AccessRequestForm con el email de la sesion, y la copia dice que la coordinacion lo revisa. Salida real. RAMA B - NO tiene fila en users. auth/callback/route.ts:483 manda a /login?error=no-profile. El login-card se porta bien: nombra la cuenta usada ("Ingresaste con X. Si no es la cuenta que usas aca, proba con otra", login-card.tsx:169-175) y ofrece un boton "Solicitar acceso" a /solicitar-acceso (188-192). Hasta ahi correcto, y es exactamente el mensaje que necesita alguien que eligio la cuenta de Google equivocada. Y /solicitar-acceso ES UN CALLEJON SIN SALIDA. src/app/solicitar-acceso/page.tsx, 23 lineas, sin form, sin action, sin link, sin direccion de contacto. Dice "Contacta a la coordinacion de la Especialidad" y no da ningun medio para hacerlo. Su propio comentario (linea 6-7) dice que el form "ships with the access backlog once the shared users tables exist" - esas tablas existen hace meses y el form nunca llego. La pagina es la cascara que se dejo puesta. CONSECUENCIA MEDIBLE, Y ES LA RESPUESTA A TERRA-59: la rama B no emite NINGUN evento. Consultado appEvents con appKey=terra sobre action ILIKE %acceso% / %solicit% / %noProfile% y failureCode ILIKE %noProfile%: 3 filas en total, las tres signInCompleted, entre 2026-07-31 y 2026-09-03. Cero acceso:solicitar en toda la serie. No es que la accion falle - es que por la rama B no hay accion que fallar. La persona se queda sin via de contacto y nosotros sin registro de que lo intento. POR QUE IMPORTA PARA EL 1/10 (TERRA-207): las 154 personas cargadas que nunca ingresaron tienen su fila indexada por la direccion que la catedra tipeo en el Excel. La que elija otra cuenta de Google cae en la RAMA B, no en la A - no tiene fila para esa direccion. O sea que el dia de la demo el modo de falla mas probable aterriza justo en la rama que no tiene salida ni deja rastro. Con 46 direcciones de la nomina que no son gmail ni uba.ar, esto no es hipotetico. ARREGLO PROPUESTO, NO EJECUTADO - hace falta OK: darle a /solicitar-acceso la misma salida que ya tiene /sin-acceso. La rama A demuestra que la pieza existe y anda; la B quedo sin ella. Lo minimo util para el 1/10 es que la pagina deje constancia de quien intento entrar y con que direccion, que hoy es justo lo que no queda registrado. Que forma toma esa constancia depende de si hay identidad atribuible - supportTickets.createdBy es NOT NULL y en la rama B no hay fila de usuario a la cual atribuir, asi que no es copiar el componente y listo. NO MEDIDO: no ejercite ninguna de las dos ramas contra el deploy. Todo esto es lectura de codigo mas la consulta a appEvents citada arriba.
• wi-cli-venus verified · 5w ago
  CORRECCION A MI PROPIA MEDICION DE HACE UN RATO, Y CAMBIA LA CONCLUSION. Dije "cero acceso:solicitar en toda la serie, 3 filas en total". El 3 salia de un ILIKE sobre %acceso%/%solicit%/%noProfile% que no matchea donde vive el dato. El predicado correcto es failureCode='noProfile' OR detail->>'outcome'='noProfile', porque en las filas viejas failureCode es NULL y el veredicto vive en detail. NUMEROS REALES: 36 signInCompleted en total para appKey=terra. CINCO son noProfile - 2026-07-30 10:02 y 10:15, 07-31 12:22, 08-14 07:12 y 2026-09-03 09:45. Cero terraAccessDenied. O sea que la rama sin fila SI se disparo, sobre cinco personas reales, la ultima hace dos dias. De las cinco, solo la del 3/9 trae detail.authUserId. Las otras cuatro no: son intentos de los que sabemos que ocurrieron y no de quien. authUserId es el portador correcto y esta explicado en route.ts:100-118 - appEvents.actorUserId es FK a users(id), y en noProfile no hay tal fila, asi que un uuid de GoTrue ahi es un 23503 justo en el outcome para el que existe el campo. EL SINK YA EXISTE Y EL CAMINO DE ESCRITURA NO. accessIssueReports esta viva en public con las columnas exactas que hacen falta - appKey, supabaseAuthId, sessionEmail, reasonValue, body, statusValue, resolvedToUserId, resolvedAt, resolvedBy - mas vAccessIssueReportsStaffQueue. Y pg_proc no tiene NADA que matchee %accessIssue% ni %reportAccess%. La migracion de db-enamel-cc aterrizo la tabla y nunca aterrizo la funcion. Terra no escribe tablas compartidas de enamel directamente y no lo va a hacer, asi que la mitad de app esta BLOQUEADA hasta que db-enamel-cc entregue la funcion de borde. Pedido enviado: coder-terra-cc-mto946hrgew4, con la forma que necesito (auth id + sessionEmail + reasonValue + body acotado, outcome mapeable a copy en castellano como changeTerraMembership y setTerraUserTelefono) y con la idempotencia marcada como requisito, porque alguien sin acceso aprieta el boton varias veces. TAMPOCO ES COPIAR AccessRequestForm. Esa via escribe supportTickets via requestTerraAccess, y supportTickets.createdBy es uuid NOT NULL REFERENCES users(id) - la poblacion sin fila no puede atribuirse ahi por definicion. access-request-actions.ts:21-34 ya dice esto y dice que estas dos poblaciones van a accessIssueReports. La separacion es estructural, no una etapa pendiente; unificarla exige nulear una columna que es load-bearing para todo co-inquilino. Y EL EMAIL NO VA A appEvents: noteTerraAccessDenied (auth.ts:363-366) lo prohibe explicitamente. sessionEmail va en accessIssueReports, que tiene la columna para eso.
• wi-cli-venus blocked · 5w ago
  Blocked on db-enamel-cc: accessIssueReports is live in public but has NO boundary function (pg_proc has nothing matching %accessIssue%/%reportAccess%), and terra does not write shared enamel tables directly. Outbound ask carrying the request: coder-terra-cc-mto946hrgew4 (2026-09-05). App half is designed and cannot ship until the function exists.
• wi-cli-venus commit · 5w ago
  Enviado y vivo en 0.31.44, verificado contra /api/health (deploymentId dpl_HbJ8gqsDLGknYct3QUsJbc9PXfvf, dbOk true). 407/407 unit, tsc limpio. QUE CAMBIO: /solicitar-acceso tenia 23 lineas que le pedian a la persona contactar a la coordinacion sin darle ningun medio - ni form, ni action, ni link, ni direccion. Ahora renderiza AccessIssueForm y escribe en accessIssueReports via fn_reportAccessIssue (enamel_046 / c0ac136, db-enamel-cc, pedido con coder-terra-cc-mto946hrgew4). Archivos: src/lib/access-issue-core.ts (vocabulario y copy, sin dependencias), src/lib/access-issue-actions.ts (la action), src/components/access-issue-form.tsx, src/app/solicitar-acceso/page.tsx, mas src/lib/access-issue-core.test.ts. LA UNICA ESCRITURA DE TERRA QUE NO PASA POR EL POOL. fn_reportAccessIssue es SECURITY DEFINER, con EXECUTE solo para authenticated, y levanta 28000 salvo que authIdArg = auth.uid(). El pool conecta como postgres, donde auth.uid() es NULL: toda llamada por el pool fallaria, siempre. El unico caller que puede satisfacer el chequeo es el cliente Supabase con cookies. Queda un test que lo fija (prohibe importar el pool en ese archivo) porque es exactamente el tipo de cosa que alguien "normaliza" despues y rompe cerrado. Tampoco usa getSessionUser en la pagina: esa funcion resuelve una fila de users, que es justo lo que esta poblacion no tiene, y devolveria null para todo visitante que la pagina existe para atender. La sesion de GoTrue si es real - el login funciono, lo que falta es el perfil. alreadyOpen se muestra como exito, no como error. La idempotencia esta puesta porque alguien sin acceso aprieta el boton varias veces. Sin fila en appEvents: sessionEmail vive en accessIssueReports. Ponerlo en appEvents violaria la regla que noteTerraAccessDenied enuncia sobre si mismo (auth.ts:363-366) sobre una tabla compartida y ampliamente consultable. LO QUE ESTE ROW PEDIA Y NO ESTA CUBIERTO ACA: el titulo habla de que cero personas pidieron acceso y de que la caida esta aguas arriba de la accion. Esa parte era cierta y ahora hay accion. Lo que NO verifique es el aviso a la coordinacion: COORDINATION_GROUP sigue sin resolverse en este row, y accessIssueReports no manda mail por si sola. Alguien tiene que mirar vAccessIssueReportsStaffQueue, o hay que construir la notificacion. Lo dejo dicho para que no se lea como cerrado de punta a punta. NO EJERCITADO CONTRA EL DEPLOY. Hace falta una cuenta de Google real sin fila en users para recorrerlo; no la tengo y no la voy a fabricar. Los cinco eventos noProfile historicos prueban que la rama se alcanza, no que el form nuevo escriba. Eso queda pendiente y es exactamente lo que el ensayo previo al 1/10 deberia cubrir.
• wi-cli-venus unblocked · 5w ago
  Desbloqueado: db-enamel-cc entrego fn_reportAccessIssue (enamel_046, c0ac136). App half enviada en 0.31.44.
• wi-cli-venus assigned · 5w ago
  coder02-terra-ca
• wi-cli-venus titleChanged · 5w ago
  Registrar y notificar pedidos de acceso sin perfil; el Data API ya no es requisito en el working tree, pero falta ship y ejercicio real
• wi-cli-venus descriptionChanged · 5w ago
  was: El aviso por mail al pedir acceso nunca se ejercito, y medido el 2026-09-03 el problema NO es el que decia esta fila. Cuatro personas llegaron a terra con identidad de Google y sin perfil - login:no-profile el 2026-07-30 10:02, el 2026-07-30 10:15, el 2026-07-31 12:22 y el 2026-08-14 07:12:45, esta ultima el propio cliente con su cuenta de gmail - y NINGUNA presento una solicitud. Cero eventos acceso:solicitar en toda la serie, ni exito ni rechazo ni warn, sobre 13 acciones distintas censadas. La accion del servidor nunca fue invocada. Como cada rechazo de requestTerraAccess ya escribe su evento via ActionError y createWithAction, el silencio no puede ser un rechazo no registrado: la caida esta AGUAS ARRIBA de la accion, en /sin-acceso o en si esas cuatro personas llegaron siquiera a esa pantalla. Los cuatro eventos de llegada ademas tienen actorUserId, message, route y path en NULL, asi que prueban que alguien llego y no pueden decir quien ni adonde fue - por eso el intento del cliente es inatribuible en nuestros datos aunque sepamos por fuera que fue el. Lo que falta primero es esa traza; recien despues tiene sentido presentar una solicitud real y leer las filas, que es la unica forma de probar el transporte. Que la configuracion de correo cargue no es evidencia de entrega y no debe citarse como tal.
• wi-cli-venus verified · 5w ago
  Metadata reconciliada por coder02-terra-ca contra fuente local y evidencia DB02: Data API eliminado solo del write path local; Supabase Auth sigue siendo la autoridad; notificacion de reportAccessIssue, ship y ejercicio real siguen abiertos.
• wi-cli-venus descriptionChanged · 5w ago
  was: ESTADO VERIFICADO 2026-09-10, separado por procedencia. CODIGO LOCAL: reportAccessIssue conserva la identidad verificada por Supabase Auth pero reemplaza la llamada PostgREST/Data API por una transaccion sobre el pool directo; fija request.jwt.claim.sub con alcance local y llama a fn_reportAccessIssue en el mismo backend. El formulario y su prueba focal estan modificados en el working tree. VERIFICACION: prueba focal 10/10, suite completa 499/499, typecheck limpio y lint sin errores con 4 advertencias preexistentes. DB02 ejecuto un BEGIN/ROLLBACK equivalente por Postgres directo sin residuo; eso no prueba el trayecto real de la app por Supavisor transaction pool. NO SHIPPED: el cambio no esta confirmado en commit, deploy ni navegador, y el push del repo sigue congelado por el artefacto aplicado pero no versionado de TERRA-210. BRECHA FUNCIONAL RESTANTE: reportAccessIssue registra accessIssueReports pero no llama notifyAccessRequest; la unica productora del outbox sigue siendo requestTerraAccess en /sin-acceso. Por eso el pedido que nace en /solicitar-acceso o /identidad-en-revision aun no avisa a coordinacion. COORDINATION_GROUP permanece sin decision, aunque el literal individual existente resuelve destinatario por la primera rama. PARA CERRAR: conectar la notificacion adecuada sin duplicar ni filtrar PII a appEvents, probar contra el pool real, ship, PTD y ejercer al menos un caso autenticado de cada razon con evidencia de fila y entrega o cola. No confundir fuente, DB viva, deploy y comportamiento ejercitado.
• wi-cli-venus verified · 5w ago
  Independent audit PASS 2026-09-10 (audit-terra-ca, tag audit-terra-ca-mtvnp4fj4iqj) at current source/BWI boundary. Excludes commit, deploy/PTD, authenticated-browser/live-email, concurrent-drain, and rerun of claimed 509-test gate.
• wi-cli-venus progress · 5w ago
  Scoped source shipped in d3ea382 as v0.31.50; Vercel production-target deployment dpl_GKQxq7iwvYsxX2x4DEd3V4MqWuJs is building. Runtime and authenticated-path exercise remain pending.
• wi-cli-venus descriptionChanged · 5w ago
  was: ESTADO VERIFICADO 2026-09-10. CODIGO LOCAL: reportAccessIssue usa identidad fresca verificada por Supabase Auth, abre una transaccion por el pool directo, fija request.jwt.claim.sub con alcance LOCAL y llama fn_reportAccessIssue; el Data API no es requisito. Cuando el resultado es created, despues del COMMIT emite exactamente una notificacion durable access_issue; alreadyOpen no duplica. Fallas de destinatarios, cola, SMTP o logging no rechazan la accion ni filtran el email del solicitante a appEvents. EVIDENCIA: gate combinado actual: focales 58/58, typecheck PASS, suite 509/509, lint 0 errores y 3 warnings preexistentes. Auditor independiente dio PASS a la capa durable TERRA-209 que usa esta notificacion. DB02 ya probo la forma directa en rollback sin residuo. NO SHIPPED/NO EJERCITADO: falta commit/deploy/PTD y un caso autenticado real por razon; el push sigue sujeto a TERRA-211. La fuente local resuelve el defecto de codigo; no confundirla con entrega de correo en produccion.
• wi-cli-venus blocked · 5w ago
  Implementacion y deploy completos; falta una cuenta autenticada real sin perfil para ejercer cada razon y comprobar fila mas cola/entrega.
• wi-cli-venus titleChanged · 5w ago
  Pedidos de acceso sin perfil: codigo y deploy completos; falta ejercicio autenticado real
• wi-cli-venus assigned · 5w ago
  coder-terra-cc
• wi-cli-venus note · 5w ago
  Resolve side parked at stand-down 2026-09-11 14:25 ART, park-file-r59-park-marker. Nothing half-applied: no commit, no push, no migration. enamel_056 written + dry-run PASSED (db-terra-cc), NOT applied - db-enamel-cc lane, held by the same stand-down. Eight files uncommitted in terra/. Real signature is fn_resolveAccessIssue(reportIdArg, appKeyArg, outcomeArg, actorUserIdArg, resolvedToUserIdArg DEFAULT NULL) - actor is arg 4, not arg 5, because Postgres refuses a non-defaulted parameter after a defaulted one; both are uuid so a swap would record the asker as the actor with no error. Outcomes now include notManager. BIND GAP: resolving does not let the person in - bindSupabaseAuthId resolves BY EMAIL and no sign-in path reads resolvedToUserId, so the screen says the pedido is resolved and never that the person has access (button Habilitar acceso -> Asociar a una persona, toast no longer claims a grant). The actual bind is a separate change. Full state: /data-venus/terra/handoff/2026-09-11-terra-59-resolve-side-park.md
• wi-cli-venus commit · 5w ago
  29c7409 resolve UI committed, r59-commit-marker-29c7409. 8 files, 550 insertions. enamel_056 applied and verified by db-enamel-cc (6ded1d4, registry 20260911234134): fn_resolveAccessIssue live INVOKER with search_path pinned, EXECUTE to postgres and service_role only, and both CHECKs validated - statusValue IN (open,resolved,denied) and (statusValue='open') = (resolvedAt IS NULL), so a hand-written UPDATE that strands a row in ux_accessIssueReports_open_perApp now gets 23514. Not pushed yet: venus-host.push-gate held by coder02-mars-cc, registered for release. db-terra-cc cleared 5be2f59 (docs ENAMEL-38) to go out in the same push; pmmaster GO on Elazar's behalf. Bind gap filed as TERRA-242 - resolving records who the admin decided this person is and no sign-in path reads it, so the asker is still locked out and the decision owed is what 'asociar' should mean. resolutionNote agreed and going to db-enamel-cc's lane as a second short migration.
• wi-cli-venus note · 5w ago
  SHIPPED r59-live-marker-031076. 29c7409 is on origin/main (pushed inside db02-terra-cc's run at faf2b44 on the shared checkout; nothing ahead now). Live: /api/health reports 0.31.76 dpl_98MKNuc1i6BXt7fo7amimCMq961E dbOk true at 2026-09-12T00:01:17Z. /administrar/pedidos-de-acceso answers 307 unauthenticated, same as /administrar, so the gate is on and the route builds. NOT verified: no authenticated walkthrough has been run against it and report 0c8512f8 is still open - the screen can now show it, which is the defect this closed, but nobody has pressed either button in production yet. Both halves of the vocabulary (resolved, denied) and the alreadyResolved race are unexercised live.
• wi-cli-venus note · 5w ago
  resolutionNote app half BUILT, uncommitted, r59-note-half-marker-058. Waits on enamel_058 - db-enamel-cc caught that a trailing resolutionNoteArg cannot be added with CREATE OR REPLACE alone: a different argument count is a new OVERLOAD, so the 5-arg and 6-arg would both exist and my 5-positional call would bind to the EXACT 5-arg match, keep running the old body, and discard the note silently while the column filled with NULLs that read as 'no reason given'. Their fix is create 6-arg + DROP the 5-arg in the same transaction, with GRANT and COMMENT restated because both are per-signature and pg_get_functiondef emits neither. My side: call site is now 6-positional and passes the note EXPLICITLY rather than leaning on the DEFAULT - a call that leans on the default writes NULL on every press and rebuilds the exact gap the note closes. The requirement that a denial say why lives in the ACTION, not in a CHECK: the column stays nullable because every row resolved before the note existed has a NULL one, and a table-wide CHECK would also refuse a resolved with no note, which is fine to leave empty. appEvents gets hasNote boolean, never the text - it is free text an admin wrote about a named person. STILL MISSING and not built: the asker has no surface to READ the motive, so a denial with a reason is still invisible to the person who wrote in. One call site in src/, measured: access-issue-resolve-actions.ts:94.
• wi-cli-venus commit · 5w ago
  a86100c + 28aabe8 pushed, faf2b44..28aabe8, r59-note-live-marker-031077. Live: /api/health 0.31.77 dpl_3oxPEERYYgL1GL5EvuJngh7TKntc dbOk true at 2026-09-12T00:24:54Z; /administrar/pedidos-de-acceso still 307 unauthenticated. Six-argument call shipped against enamel_058 (db-enamel-cc 8320095, registry 20260912002049, one oid, to_regprocedure of the 5-arg vector NULL, resolutionNote text nullable, ck_accessIssueReports_resolutionNote_nonblank convalidated). Carried from db-enamel-cc's apply, both worth reusing: SAVEPOINT/ROLLBACK TO are illegal inside PL/pgSQL, so a positive assertion arm that proves a value is ACCEPTED commits a probe row into a production table unless it raises its own sentinel and catches it - and a bare WHEN check_violation catches any of that table's thirteen checks, so a probe tripping a different one reports the constraint under test as working while it did nothing (GET STACKED DIAGNOSTICS CONSTRAINT_NAME compared by equality is the fix). Also: the GRANT/REVOKE in that file are no-ops on this ref because pg_default_acl for owner postgres already lands the target ACL, but the row for owner supabase_admin carries anon and authenticated - so the same file applied from the dashboard or a restore ships a function those roles can EXECUTE, and a green ACL assertion certifies the shipped object, never that your GRANT ran. Still missing: no surface where the asker can READ the motive.
• wi-cli-venus note · 4w ago
  STOP-PARK r59-stop-park-marker-ffefbac. Fleet-wide stop relayed by pmmaster (Elazar direct, token budget). Stopping clean: nothing ahead of origin/main, nothing uncommitted in src/ or scripts/, no lock held, no half-applied migration. DONE: both halves of TERRA-59 are live at 0.31.77+ - the queue screen /administrar/pedidos-de-acceso, the resolve action against fn_resolveAccessIssue 6-arg, and the required motive on the denial arm (enamel_056 + enamel_058, both applied and verified by db-enamel-cc). Also pushed tonight as handoffs for db02-terra-cc: 01f4775 and a88549a on TERRA-201, and db02's own faf2b44 range carried 29c7409. NOT DONE: no authenticated walkthrough has ever been run against this screen - report 0c8512f8 is visible to it and nobody has pressed either button in production, so resolved, denied, the note requirement and the alreadyResolved race are all unexercised live. NEXT ACTION on resume, in order: (1) exercise the screen end to end against 0c8512f8, which is the only thing that converts this from shipped to working; (2) TERRA-242, the bind gap - resolving records who the admin decided this person is and no sign-in path reads it, so the asker is still locked out, and what 'asociar' should mean is an identity decision owed by Elazar; (3) the asker has no surface to READ a motive, so a denial with a reason is still invisible to the only person who cares. SUSPENDED, not cancelled: the terra production DATABASE_URL sslmode question is with Elazar via pmmaster - server side is settled (Supavisor ACCEPTS plaintext on both ports, measured twice independently), the client side is one Sensitive Vercel var that pulls back empty, and the fix value is sslmode=verify-full&sslrootcert=<CA>, NOT uselibpqcompat.
• wi-cli-venus note · 4w ago
  coder-terra-cc 2026-09-12: a dedicated test user with a stored session discharges this row's remaining half, with one sharp limit that splits it into two jobs. The FILING half is already exercised in production - access issue 0c8512f8 was written by a real person 2026-09-11 10:53:51Z. What is unexercised is the RESOLVE half, which needs one admin/bedel session, and a test user provides that. THE LIMIT: the screen is provenance-scoped. listOpenAccessIssues takes isSynthetic, so a synthetic test session will NOT see 0c8512f8 and cannot resolve it. The test user therefore proves the code path; answering the real outstanding report still needs a real admin session. The row currently reads as one job and it is two - say which one is being closed when it closes.
• wi-cli-venus verified · 4w ago
  Resolve screen exercised LIVE in production 2026-09-12 03:18 ART, marker TERRA59-LIVE-UI-20260912. Instrument: proxy-mars-cc-w via chrome-devtools MCP on whey, signed in as Elazar; venus has no browser and terra's only sign-in call is signInWithOAuth google (login-card.tsx:141), so an email+password test credential could not have produced this. Deploy: 0.31.80 = HEAD f21e759, dbOk true, mailOk true, dpl_3SHEKc4BSd6AFaTQcyxoCUbE5sxv. OBSERVED: (a) /administrar/pedidos-de-acceso RENDERS for a MANAGER_ROLES session - no 307 - which is the first live evidence requireAppUserPage admits rather than only refuses; (b) one row, elazarphotos@gmail.com 11/sep/26; (c) buttons read exactly 'Asociar a una persona' and 'No corresponde', the bind-gap copy, not 'Habilitar acceso'; (d) the bind arm opens an inline input placeholder 'correo exacto en Usuarios' with submit labelled 'Resolver', disabled while empty; (e) the deny arm names the address in its confirm line and reveals the required Motivo textarea with 'Si, cerrar' DISABLED while empty - the note requirement holds in the browser, not only in the action. NOT EXERCISED: neither submit was pressed. The single queue row is a real locked-out person's pending request and resolving it is a production decision, not a test. So fn_resolveAccessIssue has still never been called from the app, and no outcome word (resolved/denied/alreadyResolved/notFound) has been observed round-tripping. Screenshots: /data-venus/terra/handoff/terra59-{1-list,2-asociar,3-no-corresponde}.jpg
• wi-cli-venus verified · 4w ago
  TERRA59-LINK-PREFILL-20260912: shipped 544aff7, version 0.31.81. The 'Buscar en Usuarios' link on each queue card carried ?email=<sessionEmail> - the address the person signed in with and could NOT get in on, which is precisely the address the paragraph two lines above it tells the admin not to search by. Exercised in production on report 0c8512f8: following the link returned 'No encontramos a nadie con esa direccion. La cuenta tiene que existir en Enamel antes de poder darle un rol en Terra.' That sentence reads as 'this person is not in the registry' while it only means 'this address is not', and the admin's next available press is 'No corresponde' - closing a real request against someone who may well be registered under their other address. Fix: link to /administrar/usuarios with no prefill, so the admin types the address from the report body, the only one that can match. usuarios/page.tsx never calls findUserByEmail on an empty query, so an unprefilled arrival shows the search form rather than a false negative. Also rode in this commit: OPS-221, pnpm build removed from .gitpush-pre.sh (Vercel compiles on every push anyway); lint and typecheck stay.
• wi-cli-venus progress · 4w ago
  T59-DENIAL-MOTIVE-SPLIT-20260912: the last open half of this row - the asker has no surface on which to read a denial's motive - is now TERRA-245, filed rather than shipped. The rail already exists (email/outbox.ts enqueue + access-notify-core.ts already enqueues the filing-side notice), so it is a second enqueue on resolve, not a new channel, and sessionEmail's ownership is proven by the Google sign-in itself. Filed and not built because it is real outbound email to a real person and three questions are not mine: whether a RESOLVED outcome should notify at all while TERRA-242's bind gap means resolving grants nobody access (that notice would be a false promise); whether the admin's free text reaches the judged person verbatim; and whether identidadEnRevision should be notified at all, since telling that person something can worsen a contended identity.
• wi-cli-venus note · 4w ago
  T59-VERSION-CORRECTION-20260912: T59-LINK-PREFILL-20260912 says 544aff7 shipped as version 0.31.81. WRONG - 544aff7 carries 0.31.82 (git show 544aff7:package.json), and 0.31.81 never existed in any commit or deploy. The stated number came from a hand-edit made BEFORE the push; gitpush.sh reads the current version and increments it, so a hand-bump is absorbed as the BASE and the shipped number lands one AHEAD of the one stated. bin-venus-cc's read (OPS-246) corrects my earlier report that the hand-bump was a silent no-op: it is worse than that, because a verifier checking the stated number finds nothing while a verifier checking the repo finds a number that was never deployed. gitpush prints 'package.json: vOLD to vNEW' in green on every run and --infoforllms:913 already says not to hand-edit the version, so nothing was hidden - the defect is the habit of stating a version before the run. The fix that actually holds: never quote a version until it is read back from the DEPLOYED artifact (/api/health for terra), which is how ce501f9's 0.31.83 survived the same check. Nothing about the CODE in 544aff7 changes - only the version label on it.
• db-enamel-ca verified · 1w ago
  Standing SELECT-only read 2026-10-06, cutoff 2026-08-16T13:31Z: Terra appEvents signInCompleted detail.outcome=noProfile 32 rows; Terra accessIssueReports filed in same window 5 rows, all reasonValue=noProfile. This establishes real reporting activity but not every reason arm or mail delivery. No data write.
• coder-terra-cc blocked · 1w ago
  MK59Q. The noProfile reason HAS been exercised by real users: since the 2026-08-16T13:31Z deploy there are 32 signInCompleted outcome=noProfile and 5 accessIssueReports, all reasonValue=noProfile (db-enamel-ca read 2026-10-06). Remaining: the identidadEnRevision reason, with 0 real reports. This closes the first time one arrives.
• coder-terra-cc note · 1w ago
  MK59BUILD. Per pmmaster muwaljtiiho4, construct the identidadEnRevision state with the fleet test account instead of waiting. Needs three things: (a) A db lane sets up the contended binding (two users rows matching the test account's canonical email). That is a data write, so it needs a db-lane owner and a GO. (b) A HUMAN Google sign-in with that account. No agent can produce a session (Google OAuth only). (c) A residue declaration before the exercise: id manifest of the setup rows and the one accessIssueReports row; actor of record = the consenting human who signs in; archive context = the db lane's reason; removal verified by an id-keyed readback. Asked Elazar on the CLI to do (b).
• db-enamel-ca note · 1w ago
  DB fixture design correction (read-only): MK59BUILD proposed two live users rows matching designated test account canonical email. Live ux_users_email_canonical_live prevents that; do not bypass unique identity constraint. Binder can reach boundToOther with ONE nonsynthetic matching-email users row prebound to a different auth UUID; NULL would bind, and prebinding test auth UUID bypasses binder via callback auth-ID lookup. Baseline test GoTrue account confirmed; 0 matching/bound public.users rows; previous report resolved. A real OAuth exercise needs fixture committed, so transaction ROLLBACK cannot reverse it. boundToOther writes append-only appEvents referencing fixture; users INSERT writes userEmails history; filing writes accessIssueReports and queues notification after commit. Cleanup cannot promise zero residue or unsend mail. No DML. Prefer isolated project with two consenting test accounts; production requires explicit acceptance of durable residue/second-account binding plus exact-ID preimages, named actor, source-reviewed logical restore and GO. Shared finding sent to db-terra/coder/PM at db-enamel-ca-muwbxezml9h7.
• coder-terra-cc note · 1w ago
  MK59FIXTURE db-enamel-ca design (db-enamel-ca-muwbxezml9h7, no DML): two live users rows at one address are impossible (ux_users_email_canonical_live). The only feasible shape is one new non-synthetic users row bound to a second test GoTrue UUID, no grants, committed before OAuth, leaving durable residue (appEvents, userEmails, accessIssueReports, possible sent mail; delete FK-blocked). Escalated kind=blocked to pmmaster: A) accept residue + second account, B) leave unexercised, source-verified only.
• coder-terra-cc unblocked · 1w ago
  cleared: MK59Q. The noProfile reason HAS been exercised by real users: since the 2026-08-16T13:31Z deploy there are 32 signInCompleted outcome=noProfile and 5 accessIssueReports, all reasonValue=noProfile (db-enamel-ca read 2026-10-06). Remaining: the identidadEnRevision reason, with 0 real reports. This closes the first time one arrives.
• coder-terra-cc completed · 1w ago
  MK59CLOSE SOURCE-VERIFIED ONLY, UNEXERCISED (pmmaster ruling B, pmmaster-evolutiva-cc-muwbzx6gecin). boundToOther branch source-verified at enamel_025:441-510. Live baseline (db-enamel-ca-muwbxezml9h7): designated GoTrue account exists and is confirmed; zero public.users rows match its canonical email or auth UUID; prior Terra accessIssueReport RESOLVED, none open. The boundToOther branch has NOT been exercised against a live binding and has not been seen to fail - a read control is a green line. Do not rebuild: two live users rows at one address are impossible (ux_users_email_canonical_live); prebinding the test authId makes the callback's first auth-ID lookup SKIP the binder (tests nothing); a fabricated UUID with no GoTrue principal is a different, false test. The only feasible fixture commits durable residue (appEvents, userEmails, accessIssueReports, outbox/possible sent mail; delete FK-blocked) - ruled the wrong trade. Reopen only if an isolated project exists. No DML authorized or performed.