No es un defecto: los roles estan bien y el menu si cambia por rol - el cliente nunca entro con la cuenta de alumno, supabaseAuthId nulo y cero signInCompleted

Sub-tickets

Activity

• wi-cli-venus created · 6w ago
• wi-cli-venus verified · 6w ago
  MEASURED 2026-09-03 AGAINST THE LIVE BASE AND THE SOURCE. NEITHER OF THE TWO CAUSES I FILED IS THE CAUSE. Both memberships are correct and active: sebastian.puia@odontologia.uba.ar (6ebaffae-a195-459e-afe8-b89c3fd73fc0) holds docente since 2026-08-14 07:24 plus client since 2026-07-30, both appKey terra, toAt null, deletedAt null, isSynthetic false; puia.sebas@gmail.com (4304d643-7cd9-4eaa-b8d4-86d3c8f46fee) holds alumno since 2026-08-22 10:40 on the same terms. So the docente role IS assigned - candidate (1) is dead. AND THE APP DOES DIFFER BY ROLE, materially, in one table: ROUTE_ACCESS in src/lib/route-access.ts gives ROSTER_ROLES (docente, jtp, bedel, admin) the links Alumnos and Practicas de la catedra, INFORME_ROLES adds Informes, CLIENT_ROLES adds Panel. An alumno matches none of those and sees only Mis practicas, Nueva practica and Mi perfil. A docente and an alumno therefore do NOT see the same menu - candidate (2) is dead too. THE ACTUAL EXPLANATION IS THAT HE NEVER ENTERED WITH THE ALUMNO ACCOUNT. users.supabaseAuthId is NULL for the gmail row, which means it has never completed a Google sign-in even once, and appEvents confirms it independently: every signInCompleted in terra since 2026-08-20 belongs to one of three actor ids and 4304d643 is not among them. His two completed logins nearest the complaint - 2026-08-30 14:48 and 2026-08-31 19:42 - are BOTH the odontologia.uba.ar account. He compared one account against itself, which is exactly why both mails did the same thing. This matches what the consultas document already told him on 2026-08-29: his alumno user was created 2026-08-22, eight days after his 2026-08-14 attempt, so the earlier try could not have worked. NOT COVERED, and I am not claiming it: I did not measure what terra renders for a signed-in Google identity with no row in users, and there are two signInInitiated with no matching signInCompleted in the window (2026-08-29 12:01 and 2026-08-30 16:44) that I have not attributed to anyone.
• wi-cli-venus blocked · 6w ago
  No es un defecto de la aplicacion. Los roles estan bien asignados y el menu si cambia por rol; lo que falta es que el cliente entre efectivamente con puia.sebas@gmail.com, cosa que nunca hizo - supabaseAuthId nulo y cero signInCompleted. Es un mensaje al cliente, no un cambio de codigo. Se cierra cuando haya un signInCompleted con esa cuenta.
• wi-cli-venus titleChanged · 6w ago
  No es un defecto: los roles estan bien y el menu si cambia por rol - el cliente nunca entro con la cuenta de alumno, supabaseAuthId nulo y cero signInCompleted
• wi-cli-venus audit-finding · 6w ago
  CONTRADICCION DIRECTA ENTRE LO QUE EL CLIENTE MARCO Y LO QUE MIDE LA BASE, encontrada el 2026-09-03 en /data-venus/terra/client-communications/2026-08-29-terra-consultas-para-puia.md. En la tabla Para probar vos mismo, la fila 0 dice literalmente: 'Entrar con puia.sebas@gmail.com y que la app te reconozca como alumno' - respuesta 'si'. La base dice lo contrario y por dos vias independientes: users.supabaseAuthId es NULL para esa fila, o sea que esa cuenta nunca completo un ingreso con Google ni una vez, y en appEvents no hay NINGUN signInCompleted con el actor 4304d643-7cd9-4eaa-b8d4-86d3c8f46fee en toda la serie. No puede haber entrado y que la base no tenga rastro: el mismo riel registro sin problema sus dos ingresos con la cuenta de odontologia el 2026-08-30 14:48 y el 2026-08-31 19:42. LAS DOS LECTURAS POSIBLES, y no puedo distinguirlas desde aca: marco la fila sin probarla, o probo y se confundio de cuenta porque el navegador ya tenia abierta la de odontologia - que es exactamente el riesgo que el propio documento le advierte dos parrafos antes cuando le sugiere una ventana de incognito. En el mismo bloque el cliente ESCRIBE MAL una respuesta ('ai' en vez de 'si' en la fila 1), asi que la tabla se completo rapido. ESTO IMPORTA MAS ALLA DE ESTA FILA: una tabla de verificacion contestada por el cliente NO ES EVIDENCIA de que algo funcione, y aca hay una fila marcada 'si' que la base refuta. Cuando el mensaje le pida entrar con la cuenta de alumno, la confirmacion tiene que ser un signInCompleted en appEvents, no un 'si' de el.
• wi-cli-venus note · 6w ago
  Message sent to the client by Elazar on WhatsApp 2026-09-03, asking him to sign out and re-enter with puia.sebas@gmail.com. The row now waits on ONE observable fact and nothing else: a signInCompleted in appEvents with actor 4304d643-7cd9-4eaa-b8d4-86d3c8f46fee. His word that he did it does not close this - the row was opened by exactly that kind of self-report being wrong.
• wi-cli-venus verified · 5w ago
  CERRADA POR EL EVENTO, NO POR SU PALABRA. El 2026-09-03 a las 20:16:56 UTC hay un signInCompleted con actor 4304d643-7cd9-4eaa-b8d4-86d3c8f46fee, puia.sebas@gmail.com - el primero de esa cuenta en toda la serie - precedido de su signInInitiated a las 20:16:41, y seguido 37 segundos despues por un ingreso con la cuenta de odontologia. users.supabaseAuthId dejo de ser NULL para esa fila. En el chat, a las 17:17 y 17:18 hora local, el cliente escribio 'Ya esta' y 'Ahi refresque todo y me aparece todo ok'. Esta vez su reporte y el riel coinciden, y lo digo en ese orden a proposito: la fila se abrio justamente porque un 'si' suyo NO habia coincidido. La causa era la que quedo escrita - nunca habia entrado con esa cuenta - y el remedio fue el mensaje de cerrar sesion, no un cambio de codigo. Ningun commit toco esto.
• wi-cli-venus unblocked · 5w ago
• wi-cli-venus completed · 5w ago
  Confirmado por signInCompleted 2026-09-03 20:16:56 UTC con puia.sebas@gmail.com, el primero de esa cuenta. No hubo defecto ni cambio de codigo.
• wi-cli-venus assigned · 5w ago
  coder02-terra-cc