venus
VENUS-236
Reconcile comoAsistente split + práctica-count dedup semantics: dashboard vs /reportes
Done normal
unassigned
Surfaced by coder-venus-cc during Postgres-offload item#1 (vPracticaScoringFacts base view): (1) comoAsistente is COMBINED (ayud1ra+ayud2da) on student dashboard but SPLIT into Ayudante1/Ayudante2 on admin /reportes. (2) 'total practicas' dedups differently: dashboard=distinct practicaId, /reportes=distinct (pacienteDni,fecha,sedeId) scoring-tuple -> same student can show different totals in the two places. Pre-existing inconsistency, not caused by the refactor. Needs a product/client ruling on which semantics is correct before reconciling. Postgres-offload campaign proceeds with pure refactor (zero user-visible change, view exposes both cuts) - this WI tracks the follow-up decision.
Questions
No questions.
Activity
-
coder-venus-cc refined scope during Postgres-offload item#2 (getStudentKpis consolidation): getStudentKpis dedups totals/role-buckets on DISTINCT practicaId; canonical scoring-tuple (pacienteDni,fecha,sedeId) used everywhere else (vScoringByAlumno, /reportes, PDF export) diverges for 1/29 alumnos live on prod - that student's /mi-cursada total would drop 2217->2216 (fleet-wide) and operador count -1 if consolidated. getStudentKpis is the sole outlier on BOTH cuts (ayudante split AND dedup grain), both /mi-cursada-only. Folded question: align /mi-cursada to canonical scoring semantics (split ayudante + scoring-tuple dedup), or keep /mi-cursada's current numbers and skip the getStudentKpis consolidation entirely. Escalated to Elazar directly - changes a real student's displayed number on live prod, not a PM-level call. Items 1+2 of the offload campaign held pending ruling; items 3-4 unblocked and proceeding.
-
Elazar ruling (live, direct): Ayudante 1ra mano and Ayudante 2da mano are DISTINCT roles, cannot be combined - confirmed by viewing a live práctica detail page. Ayudante-split question RESOLVED: align /mi-cursada + /admin/alumnos/[id] (getStudentKpis, the sole combiner) to the split shown everywhere else. Dedup-grain question (distinct practicaId vs scoring-tuple) still OPEN pending pm-pluto-cc's opinion.
-
Ayudante-split half SHIPPED: fb661b0/v0.95.17, live-verified. getStudentKpis comoAsistente -> comoAyudante1/comoAyudante2; /mi-cursada + /admin/alumnos/[id] show split cards; no other comoAsistente refs (grep clean). Dedup-grain half still HELD - asked Elazar (05:53) whether to investigate why tuple-grain was chosen on the other surfaces, or rule now that total-practicas=distinct practicaId everywhere. Awaiting reply.
-
Elazar reaffirmed: one práctica is one práctica (distinct practicaId), with live example PRA-475 (1 práctica, 2 participantes, should count as 1). Dispatched coder-venus-cc + db-venus-cc to check client docs/CR/punch-list/WhatsApp transcripts for why the scoring-tuple dedup was built for /informes+PDF+stats in the first place, before touching those surfaces.
-
coder-venus-cc archaeology verdict (citations, live proof): client spec 2026-07-03 §7.5/§12 asked for (DNI,fecha,sede) dedup, but purpose was to collapse duplicate independent-load logging (a data model never shipped). Shipped model (one práctica row + practicaParticipations join) already satisfies that intent via distinct practicaId. Tuple-dedup over-collapses on top: live proof PRA-32+PRA-198, same patient/day/sede, genuinely different cirugías, wrongly merged - the exact source of the 2217 vs 2216 divergence. Recommendation sent to Elazar: switch /informes+PDF+stats to distinct-practicaId everywhere, matching spec intent + PRA-475 + pluto's opinion. Awaiting Elazar's go.
-
db-venus-cc independent corroboration: the 'Q3 resuelto' tag on the independent-load multi-alumno section is a MISLABEL (no verbatim client quote; two different sections both tagged Q3 RESPONDIDA in the 2026-05-10 spec, confirms reuse not genuine resolution). Fleet scan of all 1459 live prácticas: exactly ONE tuple-collision (PRA-32/PRA-198), and it reads as an accidental duplicate re-entry (same creator, cirugía corrected + ayudante added next day) not a legit independent-multi-alumno case. Bonus bug found: practica-actions.ts:383 comment claims a DB UNIQUE(pacienteDni,fecha,sedeId) constraint that does NOT exist (pg_constraint shows only PK) - only a soft app-level pre-check exists, didn't block PRA-198. db recommends distinct-practicaId replacing the tuple in getReporteSummary/getAlumnoReporteDetail/vScoringByAlumno/vKpiAlumno/PDF/digest. Second independent verdict agreeing with coder-venus-cc's archaeology. Both holding pending Elazar's go-ahead.
-
Elazar RULED 2026-07-13-07:00: practicaId replaces tuple. Dispatched coder+db to implement switch across getReporteSummary/getAlumnoReporteDetail/vScoringByAlumno/vKpiAlumno/PDF/digest, resume VENUS-237 item1-dedup-half + item2.
-
status=inProgress
-
Elazar ruled: practicaId replaces (pacienteDni,fecha,sedeId) tuple for all 'total prácticas' counts. Dispatched to coder-venus-cc+db-venus-cc for implementation (tracked under VENUS-237 items 1-dedup-half + 2).
-
DB-side landed: migration venus_scoring_dedup_grain_practicaid, audit PASS. Scope expanded to 4 views (vScoringByAlumno + vKpiCamada/vKpiAdmin/vKpiTitular — 2 extra tuple-embeds found beyond design-ping). Bonus fix: NULL-pacienteDni collapse bug in vKpiAdmin/vKpiTitular (78 live rows). vKpiAlumno/vKpiCohorte auto-inherit via composition. Coder proceeding with 9 app-side inline-SQL sites (report-actions.ts, PDF, soporte-cron digest).
low
5w ago by wi-cli-venus
5w ago
2026-07-13 10:01