Ejercicio autenticado real: un solo login de una persona real desbloquea seis filas que hoy esperan por separado

Sub-tickets

Activity

• wi-cli-venus created · 5w ago
• wi-cli-venus assigned · 5w ago
  coder-terra-cc
• wi-cli-venus audit-finding · 5w ago
  THE PAGE HAS NEVER BEEN USED, AND THAT IS NOW MEASURED RATHER THAN ASSUMED. Marker: ZEROROWS213-20260911. db-enamel-cc measured 2026-09-11: accessIssueReports holds ZERO rows in the BASE TABLE - not zero visible through the staff view, zero total, ever. The form shipped in 0.31.44 on 2026-09-05. Six days, no row. WHY THIS SHARPENS THE ROW INSTEAD OF JUST CONFIRMING IT. 'Not exercised against the deploy' was previously a statement about our own testing. It is now a statement about the table: nothing distinguishes 'nobody reached the page' from 'the write is broken'. Both produce exactly zero rows, and the second is invisible until a real person hits it. tomas.cardozo appears in the appEvents refusal trail and NOT in this table, which is consistent with either reading and settles neither. The write path was also REBUILT since the form shipped: d3ea382 (2026-09-10) moved fn_reportAccessIssue off supabase.rpc onto the pg pool with an explicit BEGIN and a transaction-local request.jwt.claim.sub. So the code that would produce the first row is not the code that was live when the page shipped, and it has never once run against the deploy with a real session. A missing BEGIN in that path raises 28000 for every user and renders as 'Ocurrio un error inesperado' - indistinguishable on screen from any other failure. CONSEQUENCE FOR THE 1/10 DEMO: discovering this with a live person is the expensive version. One real authenticated sign-in resolves it, which is exactly what this row already asks for - the finding does not add work, it adds a reason not to defer. NOT DOING: no synthetic row. A hand-written INSERT would prove the table accepts writes and would NOT exercise getUser, the claim seeding, or the function's auth-id equality check - it would make the table non-empty while leaving the actual question open, and the next reader would see rows and conclude the path works.
• wi-cli-venus verified · 5w ago
  THE EXERCISE RAN. Elazar performed it himself on 2026-09-11 10:53Z with a real non-roster Google account. Marker: T213-run1-mtwwz2. This was living only in CLI prose until now, which is the exact failure this lane has been closing all morning - an ask that is not a row is not an ask, and neither is a RESULT. WHAT WAS EXERCISED, arm 1 of the six only: the no-profile access-request path end to end, browser -> Google sign-in -> server action -> pg pool. accessIssueReports row 0c8512f8-a470-49ad-8117-616b2d8f1b74, elazarphotos@gmail.com, reason noProfile, supabaseAuthId bf3e275e-... matching its own signInCompleted event. NO 28000. That is the operative result: fn_reportAccessIssue's explicit BEGIN + transaction-local set_config('request.jwt.claim.sub', ..., true) works against a REAL GoTrue session, not just a psql simulation. Client-facing copy rendered in Spanish as designed ('Pedido registrado ... La coordinacion de la Especialidad lo revisa y te habilita el acceso'). AND IT FOUND A DEFECT THAT ONLY A REAL RUN COULD FIND. The inline send refused with missingReplyTo; the 10:55 drain tick then DELIVERED the same mail 74s later, messageId <86a5b2b1-...@pensanta.com>. Two senders disagreeing about the same row: drain-route carried the literal emailClass === 'accessRequest' while this mail enqueues as accessIssue, so the requirement held on attempt 1 and lapsed on the retry. Fixed in v0.31.52 by the shared predicate requiresReplyTo() over REPLY_TO_REQUIRED_CLASSES, with a regression test that greps the route with comments stripped. Post-fix behaviour is that this mail STOPS in the outbox rather than arriving non-compliant, until SMTP_REPLY_TO is set in Vercel - that env var is Elazar's and is the only thing between here and delivery. ALSO CONFIRMED LIVE BY THIS RUN: db:poolIdentity success rows now carry attempts 1, so the TERRA-98 attempt-counting change (v0.31.51) is deployed and the success path is no longer censoring the retry's denominator. FIVE ARMS REMAIN AND THEY ARE NOT INTERCHANGEABLE: TERRA-208's image arm (a practica saved with a real radiografia through the api-images path - zero practicas carry an image today), TERRA-6's Pasart bind with the institutional address, TERRA-22's aged live session, TERRA-207's pre-1/10 rehearsal, and TERRA-59's remaining refusal reasons beyond noProfile. Each needs a real authenticated human; none can be staged by an agent, which is why this row exists as one row. Row stays open. Arm 1 of 6 done.
• wi-cli-venus audit-finding · 5w ago
  EL BRAZO DE IMAGEN NO SE PUEDE EJERCER HOY: una foto de telefono es rechazada antes de llegar a nuestro codigo. Marker: T218-block-TERRA-213-mtwxt2. TERRA-218 (p1, hija de TERRA-143) documenta el defecto completo. Lo esencial para esta fila: el cuerpo de una server action de Next tiene un limite por defecto de 1 MB - campos del formulario mas TODAS las radiografias juntas - y next.config.ts no define serverActions.bodySizeLimit, asi que ese default rige. Pasado el limite el framework devuelve 413 antes de que corra una linea nuestra. El techo duro de Vercel es 4.5 MB (FUNCTION_PAYLOAD_TOO_LARGE), verificado hoy en su documentacion, asi que subir el limite no alcanza: una foto de 5 MB o dos de 3 MB siguen fallando. POR QUE IMPORTA PARA EL EJERCICIO Y NO SOLO PARA EL BACKLOG: practica-form.tsx declara accept='image/*', que en un telefono abre la camara, y una foto de telefono pesa 3-6 MB. O sea que la forma MAS PROBABLE de ejercer este brazo - alguien fotografiando una radiografia con el celular - falla. Y falla mostrando 'Ocurrio un error inesperado. Por favor, intenta de nuevo mas tarde.', el catch generico de use-action-form.ts:72, identico al texto que se veria si el servidor estuviera caido. POR ESO SE ESCRIBE ACA Y NO SOLO EN TERRA-218: si Elazar intenta el ejercicio antes de que TERRA-218 este arreglado, va a ver un error generico y lo va a leer como una caida de la aplicacion. No lo es. Es un limite de tamaño sin mensaje propio. QUE SI FUNCIONARIA HOY: una imagen de menos de 1 MB en total contando el resto del formulario - una captura de pantalla chica o un JPEG comprimido a proposito. Sirve para probar el camino de api-images de punta a punta, NO para probar el caso real de uso. Nunca se detecto antes porque la superficie esta desplegada desde 0.31.50 y nunca fue ejercida: practicaImages tiene 0 filas, medido por db-terra-cc.
• wi-cli-venus verified · 5w ago
  T213-app-mtx7b - APP HALF EXERCISED AND MEASURED from Vercel production runtime logs, dep dpl_4ddDXUb1DEiUrkZ5JRST1j5eyFkm. Elazar signed out and signed in at 2026-09-11 16:51-16:52 UTC. THE SIGN-IN SUCCEEDED END TO END: 16:51:53Z GET /mi-perfil 200 (a session was already live - he signed out of one), 16:51:54Z POST /administrar 303, 16:51:54Z GET /login 200, 16:51:56Z POST /login 200, 16:52:01Z GET /auth/callback 307 with a redirect and no error param, then 16:52:03Z every gated route 200: /administrar, /administrar/usuarios, /alumnos, /informes, /panel, /cirugias, /practicas, /practicas/nueva, /mi-cursada, /pacientes/pendientes. ZERO 4xx and ZERO 5xx across the 30-minute window, queried explicitly by status class rather than inferred from a histogram whose tail was truncated. TERRA-59 IS NOT EXERCISED BY THIS RUN AND CANNOT BE. He signed in as an account that HAS a profile and full access, so he never reached /sin-acceso, never saw the request button, and no accessIssueReports row could have been created. That path still has ZERO successful runs in production. It needs a Google account with NO terra profile - a different ACCOUNT, not a different click. This is the one item of the four that has never once worked and it remains open. TERRA-208 NOT EXERCISED: /practicas/nueva was fetched but no POST to any practica action appears in the window. The 16:52:03 burst is Next.js link prefetch - every nav entry at once - and must not be read as a walkthrough. That distinction is the reusable part: a prefetch produces a 200 on every gated route without a human having opened any of them. TERRA-22 HAS A DEADLINE: the session clock started 16:52:01Z, so the aged-session test needs navigation on that same session at roughly 17:52Z. INCIDENTAL AND REAL: /pacientes/pendientes returned 200 for a real authenticated admin 49 minutes after terra_151/terra_150 went live - the TERRA-150 queue page rendering in production against the live table, which nothing had exercised before. NOT ANSWERABLE FROM THE APP HALF: which address authenticated. Vercel logs carry no identity, and Elazar wrote 'elazar.pimentel@ppensanta.com' with a doubled p. Whether that is a typo in the message or the address that actually bound is a catalog question for db-terra-cc, complicated by there being TWO sessions in this window.
• wi-cli-venus note · 5w ago
  db-terra-cc EVIDENCE-MARKER-mtx7dmdqlsy9. Mitad base de datos de la sesion real. La direccion que autentico es elazar.pimentel@pensanta.com con UNA p - ppensanta no existe en auth.users ni en public.users, era un error de tipeo, no una segunda identidad. auth id 1ba406d2, ingreso 16:52:02.077Z, liga a una sola fila users 8157954d; cero filas users creadas en 8h, asi que no hubo identidad partida. Hubo TRES ingresos en la ventana y DOS identidades: 16:51:33 completo con failureCode=noProfile (elazarphotos@gmail.com, sin perfil), 16:51:44 y 16:52:02 como 8157954d. TERRA-59 SI ESTA EJERCITADO Y FUNCIONO: accessIssueReports tiene una fila real (isSynthetic false) 0c8512f8 creada hoy 10:53:51.513Z, cadena completa en appEvents con appVersion 0.31.51 en produccion, y el correo salio (emailOutbox d87259ae, clase accessIssue, email:sent success 10:55:05). Lo que nunca corrio es la RESOLUCION administrativa: statusValue sigue open, resolvedToUserId/resolvedAt/resolvedBy nulos. Defecto nuevo en esa cadena: appEvents 10:53:51.562 email:replyToRequired failure missingReplyTo sobre ese reporte, y el correo se envio igual 74s despues. TERRA-22 ya esta respondido y su premisa es falsa: auth.sessions.not_after es NULL en las tres sesiones y la sesion 7620b5a4 se refresco a las 16:51:22.522Z tras 5h58m sin expirar. TERRA-210 confirmado, pero public.users.lastSignInAt sigue NULL tras dos ingresos exitosos - el camino de ingreso no escribe esa columna. La sesion no creo nada mas: pacientes 0, terraPracticas 0, solicitudes 0. Aparte: userEmails tiene 162 filas creadas en el unico minuto 11:25Z sobre 159 usuarios, backfill de otro carril, no de esta sesion. No ejercitados: TERRA-208, TERRA-6, TERRA-207. Evidencia: terra/agents/db-terra/evidence/2026-09-11-terra213-signin-database-evidence.result.md
• wi-cli-venus progress · 4w ago
  T213-INSTRUMENT-EXISTS-20260912: the authenticated instrument this row has been waiting for now EXISTS, and it is not the thing anyone was asking for. proxy-mars-cc-w holds chrome-devtools MCP on whey and is signed in to terra-enamel.pensanta.com as Elazar; it drove /administrar/pedidos-de-acceso, /administrar/usuarios and /administrar live tonight and returned exact rendered copy, control states and a search result. Used 2026-09-12 03:18-03:19 ART to discharge the read-only half of TERRA-59 (marker TERRA59-LIVE-UI-20260912) and to find a real defect nobody could see from source (TERRA59-LINK-PREFILL-20260912, shipped 544aff7). WHAT THIS CHANGES FOR THE SIX ROWS: every assertion of the form 'does this screen render for a real session, with what copy, in what state' is now answerable in minutes without Elazar's own time. WHAT IT DOES NOT CHANGE, and this is the part to not oversell: (1) it is Elazar's own session, so it exercises HIS roles and HIS provenance, never a dedicated test identity, and any row needing a second or lower-privileged person is still blocked; (2) every press is a PRODUCTION write by Elazar - tonight nothing was submitted anywhere, deliberately, because the only open pedido is a real locked-out person's request and resolving it is a production decision, not a test; (3) it cannot produce the STORED SESSION this row's other half wants, and no credential can - terra's only sign-in call is signInWithOAuth google (login-card.tsx:141), so a test user's email+password mints nothing that passes /auth/callback. So this row's six dependents split: the read-only assertions are unblocked NOW, the ones needing a write or a second identity are not.
• coder-terra-cc note · 2w ago
  MARKER-t213-recon-muldu RECONCILED against what actually happened today; this row's description is STALE and overstates what remains. It says six rows wait on one authenticated exercise that is nobody's task. That exercise WAS run today by proxy-general-cc in a signed-in session, and the six split three ways. DISCHARGED TODAY: TERRA-208 - its blockedReason was 'falta ejercicio autenticado con imagen real'. proxy uploaded two real JPEGs to production and both RENDERED, with a live control on orientation (N19 portrait red-top, N20 landscape red-left), which also ruled out a blind global rotation. TERRA-207 - its blockedReason was 'un ensayo autenticado real antes del 1/10'. proxy walked the whole 1/10 script end to end and it found a real defect, fixed and pushed as d4d7836. Both of those waits are over. NOT DISCHARGED AND NOT DISCHARGEABLE BY THIS INSTRUMENT, for the reason this row's own 2026-09-12 event already gave: proxy drives ELAZAR's session, so it exercises his roles and his provenance. TERRA-6 needs Pasart's own first login - a SECOND identity, which no proxy session can ever supply. TERRA-59 needs an authenticated account with NO profile - by construction not Elazar's. TERRA-22 needs a build with the fix DISABLED to force the failure first, per its own 2026-09-12 note; a passing aged-session run on production proves nothing. SO THE HONEST RESIDUE IS TWO THINGS, NOT SIX: a second, lower-privileged identity (TERRA-6, TERRA-59) and a fix-disabled build plus a dedicated test user (TERRA-22). Both need Elazar. The blanket claim that one login discharges six rows is no longer true and should not be repeated to him - it was true on 2026-09-11 and today's exercise is what made it false.
• coder-terra-cc completed · 1w ago
  Umbrella with no work of its own. Arm 1 (no-profile access request, end to end) ran 2026-09-11 10:53Z, accessIssueReports 0c8512f8. TERRA-208 (image) and TERRA-207's rehearsal were discharged 2026-09-28 by proxy-general-cc's authenticated run (TERRA-208 is done). The residue is a second real identity, and each part is on its own row with its own blockedReason: TERRA-6 (Pasart's first login), TERRA-59 (other refusal reasons), TERRA-22 (aged-session instrument, WEBUSAGE-1). Keeping this row open duplicates those three rows and restates a claim already falsified 2026-09-28 (that one login unblocks six rows).