basquetWi + New ticket
terra TERRA-207

Demo 1/10: resolver 2 candidatos de identidad y ensayar el acceso real antes de la jornada

Done normal ctcoder-terra-cc

Fecha acordada con el cliente: jueves 1/10/2026 de 8:00 a 8:30, con todas las camadas; 10 minutos para alumnos y 5 para docentes por separado. RECONCILIACION FINAL 2026-09-10, DB02 read-only y sin copiar PII: el checksum de la planilla canonica coincide con la copia documentada. La seccion 2026 contiene 67 personas y las 67 tienen match exacto por email o DNI en usuarios activos; 2024 tiene 15/15; 2023 tiene 55 filas reales mas 2 filas estructuralmente vacias, con 50/55 matches exactos. De los 5 restantes de 2023, 3 tienen match por nombre completo normalizado y solo 2 no tienen match exacto por email, DNI ni nombre. Por tanto no falta un alta masiva ni corresponde automatizar el Excel: quedan 2 candidatos de identidad para revision manual contra la fuente protegida, sin crear usuarios en lote. RIESGO PRINCIPAL DE LA DEMO: la medicion previa encontro que solo 5 de 159 usuarios cargados habian completado vinculacion de Auth; 154 no habian realizado su primer ingreso. Tambien habia 46 direcciones no-Google que requieren confirmar con que identidad Google entrara cada persona. ACCIONES EXTERNAS: resolver manualmente los 2 candidatos, confirmar identidades no-Google con la catedra y ensayar el login de al menos una camada antes del 1/10. TERRA-59 ya desplego la solicitud de acceso y notificacion durable para quien no haga match, pero ese recorrido autenticado real aun no fue ejercitado.

Sub-tickets

No sub-tickets.
+ Add sub-ticket

Activity

  • wi-cli-venus created · 5w ago
  • wi-cli-venus assigned · 5w ago
    coder-terra-cc
  • wi-cli-venus verified · 5w ago
    MEDICION PREVIA A DECIDIR. La premisa del row - "falta resolver el alta masiva" - es en su mayor parte falsa: el alta masiva YA SE HIZO. Lo que falta es otra cosa, y es peor. FUENTES (las tres planillas de ~/gdrive/projects/evolutiva/terra/intake-usuarios/): - 2026-08-05 IMPLANTOLOGIA ORAL MOD II PASART.xlsx - alumnos, hojas 2023/2024/2026, 174 direcciones unicas - 2026-08-05 Plantel Docente.xlsx - 24 direcciones unicas - Union deduplicada: 190 direcciones CONTRA LA BASE VIVA (users, deletedAt IS NULL), medido 2026-09-05: - 159 usuarios cargados, y los 159 tienen membresia terra. 141 alumno, 26 docente. - 153 de las 190 direcciones de la nomina YA EXISTEN en la base. - 37 direcciones de la nomina NO existen. LOS 37 NO SON 37 PERSONAS. Al menos 14 son una SEGUNDA direccion de alguien ya cargado bajo su otra direccion: carolina.ricardi@hotmail vs @odontologia.uba.ar, juanfranciscodenapoli gmail vs hotmail, rastellimauro164@gmail vs rastellimauro@hotmail, tomas.tajes@gmail vs @odontologia.uba.ar, tomasolives98@gmail vs tomas.olives@hotmail, valeosandoval0206 hotmail vs gmail, tiagofao9205@gmail vs tiago9205@hotmail, natalia_failla79 vs nataliafailla79, pato.m.donato@gmail vs patricio.donato@odontologia.uba.ar, aylentamyq@gmail vs aylentamyquiroz@hotmail.com.ar, eugeniagutierrez91 vs euge.gutierrezdt, swbastian.kawka@gmail vs sebastian.kawka@hotmail (con el typo en la planilla), jordipasart@hotmail vs jorge.pasart@odontologia.uba.ar. El alta pendiente real es de a lo sumo 23 personas nuevas, no 190. Eso es trabajo manual de una sentada, NO justifica automatizar contra el Excel. EL PROBLEMA REAL, Y NO ES EL ALTA: de los 159 cargados, SOLO 5 tienen supabaseAuthId. 154 personas tienen fila y membresia y NUNCA completaron un ingreso. El 1/10 a las 8:00 seria la primera vez que se loguean camadas enteras, todas a la vez, sin ningun ensayo previo. Y hay un modo de falla concreto para ese dia: la fila esta indexada por la direccion que la catedra puso en el Excel, y el ingreso es con Google. Si una persona toca "Ingresar con Google" y elige una cuenta cuya direccion no es la que figura en su fila, no matchea con su fila - cae como alguien sin acceso, y segun TERRA-59 esa via no genera ni un evento acceso:solicitar en toda la serie. O sea: falla en silencio, del lado de la persona y del nuestro. La nomina tiene 46 direcciones que no son gmail ni uba.ar (36 hotmail, 3 yahoo, 2 outlook, y cinco dominios sueltos incluido el del propio Pasart), y para cada una de esas es una pregunta abierta si la persona tiene siquiera una cuenta Google con esa direccion - TERRA-111. QUE HACE FALTA DECIDIR, y no lo decido yo: 1. Las ~23 personas nuevas: se cargan a mano contra la planilla. Propongo eso, no automatizacion. 2. Las 46 direcciones no-Google: hay que preguntarle a la catedra con que cuenta va a entrar cada una ANTES del 1/10, no el mismo dia. 3. Ensayo previo obligatorio: al menos una camada logueandose antes del 1/10. 154 primeras sesiones simultaneas sin un solo ensayo es el riesgo grande de la demo, mas que el alta. NO MEDIDO: que ve exactamente una persona sin acceso al entrar hoy. Es la mitad que le falta a esto y es lo mismo que TERRA-59 tiene abierto.
  • wi-cli-venus assigned · 5w ago
    coder02-terra-ca
  • wi-cli-venus titleChanged · 5w ago
    Demo 1/10: reconciliar hasta 23 personas y ensayar el acceso real antes de la jornada
  • wi-cli-venus descriptionChanged · 5w ago
    was: Fecha acordada en el chat del cliente el 3/9/2026: jueves 1/10, 8:00 a 8:30, con todas las camadas de la especialidad juntas antes del teorico, porque ese dia hay demo y estan todos. Formato dicho en audio por el cliente (PTT-20260903-WA0023 y WA0024): 10 minutos con alumnos y 5 con docentes, por separado, porque cada rol entra distinto. Es la unica fecha concreta acordada en todo el hilo desde el 29/7. Dos cosas cuelgan de ella y hoy no estan resueltas: (1) el cliente pidio el 3/9 17:20 un link para repartir por un grupo de WhatsApp, y en el audio siguiente el mismo aclara que el acceso NO es abierto - "te tiene que dar autorizacion, de acuerdo al mail que vos nos mandaste en ese Excel"; o sea que lo que pide es la direccion publica de la app mas alguien habilitando a mano contra la nomina, y hay que decidir si el alta masiva previa a la demo se hace a mano o se automatiza contra el Excel; (2) si el dia de la demo van a loguearse camadas enteras a la vez, conviene saber antes cuantos son y que pasa con el que entra y todavia no tiene acceso. Cadena completa en /data-venus/terra/client-communications/2026-09-05-whatsapp-chain-reconstruida.md.
  • wi-cli-venus blocked · 5w ago
    Faltan confirmacion de identidades por la catedra, reconciliacion manual de hasta unas 23 personas y un ensayo autenticado real antes del 1/10; no queda una automatizacion masiva de codigo o DB por implementar.
  • wi-cli-venus verified · 5w ago
    Independent audit PASS 2026-09-10: title, roster aggregate and external readiness blockers match the verified source; no bulk-import automation remains.
  • wi-cli-venus titleChanged · 5w ago
    Demo 1/10: resolver 2 candidatos de identidad y ensayar el acceso real antes de la jornada
  • wi-cli-venus descriptionChanged · 5w ago
    was: Fecha acordada con el cliente: jueves 1/10/2026 de 8:00 a 8:30, con todas las camadas; 10 minutos para alumnos y 5 para docentes por separado. La premisa de alta masiva ya no es valida: la medicion verificada del 5/9 encontro 159 usuarios activos cargados y los 159 con membresia Terra; 153 de 190 direcciones de la nomina ya existian. De las 37 direcciones ausentes, al menos 14 eran segundas direcciones de personas ya cargadas, por lo que la reconciliacion pendiente quedo acotada a no mas de unas 23 personas y no justifica automatizar el Excel. Riesgo principal de la demo: solo 5 de esos 159 habian completado vinculacion de Auth; 154 no habian realizado su primer ingreso. Ademas, 46 direcciones de la nomina no eran Gmail ni uba.ar y requieren confirmar con que identidad Google entrara cada persona. ACCIONES EXTERNAS PENDIENTES: la catedra debe confirmar las identidades no-Google, validar las altas manuales realmente faltantes y coordinar un ensayo de login de al menos una camada antes del 1/10. TERRA-59 ya desplego la solicitud de acceso y notificacion durable para quien no haga match, pero ese recorrido autenticado real aun no fue ejercitado.
  • wi-cli-venus blocked · 5w ago
    No hay alta masiva pendiente. Faltan revision manual protegida de 2 candidatos de identidad, confirmacion de cuentas Google por la catedra y un ensayo autenticado real antes del 1/10.
  • wi-cli-venus verified · 5w ago
    DB02 privacy-safe evidence artifact: agents/db02-terra/evidence/2026-09-10-terra_207-roster-aggregate-and-terra_98-boundary.md, SHA-256 cfe44ccd2a96e29f3a6cb28a816e5f583ded4ca554dbd66d0fd8117a059acb0e. It records canonical workbook MD5 55db9c54392180b0c78e8e85ee7ac498, explicit sheet/range semantics, aggregate-only matching method and results, no PII and no DB mutation. Independent final audit pending.
  • wi-cli-venus verified · 5w ago
    Independent audit PASS 2026-09-10: SHA-verified aggregate artifact is PII-free; counts and the two external identity candidates are accurately bounded.
  • wi-cli-venus assigned · 5w ago
    coder-terra-cc
  • coder-terra-cc note · 2w ago
    MARKER-t207-redirect-mul5t. The authenticated rehearsal is DONE and it found one real defect, now fixed and pushed as d4d7836. proxy-general-cc walked the entire 1/10 demo script in a signed-in session: paciente DNI 90000002 'Synthetic TERRA207', Implantología / Preservación alveolar, pieza 11, radiografía attached. Every step instant, no lag anywhere - /practicas load, nueva práctica load, new-patient DNI lookup and Nombre/Apellido reveal, Módulo -> Cirugía dependent dropdown repopulation, file select. Guardar práctica ~1-2s with no spinner hang. Práctica N° 8 created; reopened from the list, the radiografía renders as a live thumbnail with no reload, confirmed visually AND by fetch (GET /api/practica-image/2026_1482e586-c555-4a59-9829-dabeb1cd7e94 -> 200 image/jpeg). THE DEFECT: after a successful save the redirect went to '/', which resolves to /administrar for a docente. The person then had to return to /practicas and find their own new row by hand. It saved correctly every time - it simply did not LOOK like it, and 'did it save?' in front of every camada is the one failure mode a demo cannot absorb. Fixed by pushing to /practicas/<practicaId>; the id was already in CreatePracticaResult, so nothing needed looking up. The test pins it by source because the regression is invisible to a type check - router.push takes a string and '/' is a valid one. Forced RED against the old line and then green before being accepted, rather than trusted as a passing assertion. This clears blocker 3 of 3 on this row. The two that remain are not ours: manual review of the 2 identity candidates against the protected source, and the cátedra confirming the Google accounts. Both are Elazar's.
  • coder-terra-cc note · 2w ago
    MARKER-t207-clean-mul5z. d4d7836 confirmed live by proxy-general-cc: re-ran the save, landed directly on /practicas/0c4b1ed3-bcfa-45f4-ba63-cfb2e115f001 (Práctica N° 9) with the radiografía thumbnail already rendered, no extra click. The demo path is clean end to end. All three code/rehearsal blockers on this row are now cleared. What remains is not ours and cannot be done by an agent: manual review of the 2 identity candidates against the protected source, and the cátedra confirming the Google accounts. Both are Elazar's.
  • coder-terra-cc note · 2w ago
    MARKER-t207-noprofile-mulcn: behaviour a docente absent from the padron will see on 1/10, measured from source rather than assumed (src/app/auth/callback/route.ts:480-501, full reasoning on TERRA-137). A successful Google sign-in by someone with no row in the shared users table lands on /login?error=no-profile. LoginCard renders a banner, echoes the address they signed in with, and offers the request-access path. The session is kept - login is not access. It is an explained refusal, not a crash, a blank page or a loop. A DIFFERENT population gets a DIFFERENT page, and the distinction matters on the day: someone who HAS a users row but no terra membership - an enamel person, or a grant nobody made - goes straight to /sin-acceso, not through /login, because showing a sign-in form to someone who just signed in successfully is the wrong copy. That path also writes a terraAccessDenied row, deduped to roughly one per user per day. SO THE FAILURE MODES ON THE DAY ARE LEGIBLE: 'no estas en el padron' and 'estas, pero sin acceso a terra' are visibly different screens with different next steps. Neither is silent. Whoever runs the jornada can tell the two apart from what the person describes, without a log query.
  • coder-terra-cc note · 2w ago
    MARKER-t207-noimages-mule7 DEMO-DAY FINDING nobody had flagged, and it is about the feature we just finished shipping. db/seed-demo-sample-data.sql creates ZERO practicaImages rows - verified by content search, not by glob - so none of the eight TERRA-251 demo practicas carries a radiografia. Combined with src/app/practicas/[id]/page.tsx:157, which gates the entire Radiografias block on imagenes.length > 0, every one of the eight demo practicas renders with NO Radiografias section at all. CONSEQUENCE FOR 1/10 AS IT STANDS: the image feature - TERRA-208, shipped, live, and verified end to end this morning - is INVISIBLE on every practica the demo was built to show. The only rows in production carrying a visible image are N18 (created live by proxy during the rehearsal) and N19/N20, which are the test residue TERRA-255 exists to remove. Run TERRA-255 and the demo set shows no images anywhere; leave it unrun and the only images on screen are the two rows we intend to delete. THIS IS NOT A DEFECT TO FIX BEFORE THE DAY AND SHOULD NOT BE TREATED AS ONE. proxy demonstrated the working path this morning: creating a practica live through /practicas/nueva with a radiografia saved, landed on the detail page, and rendered the image immediately. So the feature demos correctly - it just has to be demonstrated by CREATING one during the jornada rather than by opening a seeded row. That is a line in the demo script, available today, needing no write to production and no decision from anyone. RECOMMENDATION FOR THE SCRIPT: show the image arm on a practica created live, not on the seeded eight.
  • coder-terra-cc note · 2w ago
    MARKER-t207-doc-mulf2 Assembled the jornada readiness doc for whoever runs 1/10: https://claude.ai/artifact/26oX21R3MoQVRua63DzpnS - in Spanish, since it is client-facing. It consolidates what was scattered across TERRA-207/208/251/252/255/22 and had never been in one place: what works and how it was verified, the suggested script, the two not-signed-in screens and how to tell them apart from what the person says, the N19/N20 residue, and an explicit limits section. TWO THINGS IN IT THAT CHANGE HOW THE DAY SHOULD RUN, both from this round's findings. First, the radiografia has to be demonstrated by CREATING a practica live - none of the eight demo practicas carries an image and the ficha hides the section entirely when there is none, so opening a seeded row to show the image feature shows nothing at all. That is now step 4 of the script with the reason stated. Second, the limits section says plainly that every verification came from ONE administrator account, so no ordinary alumno or docente has used the system and no person has completed a real first sign-in - which is exactly what 1/10 consists of. It is PRIVATE until Elazar shares it from the page's Share menu. Nobody else can open the link until he does.
  • db-enamel-ca verified · 1w ago
    Standing SELECT-only read 2026-10-06 for 2026-10-01 ART (03:00Z Oct-01 to 03:00Z Oct-02): Terra signInCompleted authorized 45 rows / 44 distinct actorUserId / 44 distinct detail.authUserId; noProfile 25 rows / actorUserId NULL in all 25 / 14 distinct detail.authUserId. Distinct actorUserId for noProfile is 0 by schema event shape, not zero attempted accounts. No data write.
  • coder-terra-cc unblocked · 1w ago
    cleared: No hay alta masiva pendiente. Faltan revision manual protegida de 2 candidatos de identidad, confirmacion de cuentas Google por la catedra y un ensayo autenticado real antes del 1/10.
  • coder-terra-cc completed · 1w ago
    MK207DONE. The demo date has passed. What happened on 2026-10-01 ART (db-enamel-ca read, 2026-10-06): 45 authorized signInCompleted rows from 44 distinct users; 25 noProfile rows, all with actorUserId NULL, from 14 distinct Google auth identities. No checklist item remains as a pre-demo action. The 14 locked-out identities are the live follow-up, filed as a new row: TERRA-278
task
5w ago by wi-cli-venus
1w ago
2026-10-06 06:07