EVO-74 venus: schema-anchor check + read-only dupe candidate query

Sub-tickets

Questions

Activity

• wi-cli-venus created · 4w ago
  parent=#2196
• wi-cli-venus note · 4w ago
  db-venus result 2026-07-19: ANCHOR-GAP - venus users table has NO legajo/DNI/secondaryEmail on the account; those exist only on accessRequests, reachable per-account only via matchedUserId (request-flow users only, not pre-created). Dedup on venus falls back to name. 3 candidate pairs (40 live non-demo users): (1) Elazar self-test 2 emails LOW/non-actionable; (2) Martina Rubino Iriarte - 2 gmails, accent/name-order variant, MEDIUM-HIGH; (3) Sebastian Puia - personal vs odontologia.uba.ar institutional, MEDIUM-HIGH. 0 matched on legajo/DNI/altEmail (thin coverage). Requested looser token-sort+Levenshtein pass for higher recall.
• wi-cli-venus note · 4w ago
  db-venus looser pass complete: 1 new candidate beyond the 3. Final venus list = 4: (1) Elazar-self non-actionable; (2) Martina Rubino Iriarte MED-HIGH; (3) Sebastian Puia MED-HIGH; (4) Eugenia Mendez (od.eugeniamendez@gmail.com vs mariaeugeniamendez96@gmail.com) partial-name-token-overlap LOW-MED. Remaining 32 distinct. Read-only pass done.
• wi-cli-venus completed · 4w ago
  Read-only detection complete, 4 candidate pairs, no writes
• wi-cli-venus note · 4w ago
  CORRECTION 2026-07-20 (live-query resolved, db-venus): my earlier EVO-78 anchor claim was INCOMPLETE. venus rob rob rob raw table has no DNI/legajo (accurate), BUT a separate profile table (FK userId->users, missed in the original pass) DOES carry dni/documentoType/documentoNumber - 33/33 live alumnos populated (100%). So venus DOES have DNI on the account via alumnos; DNI-exact IS a runnable, well-populated dedup signal. legajo remains the real gap (accessRequests-only, not on users OR alumnos). The original EVO-74 venus dedup used name + login/participation, NOT DNI-exact - a DNI-exact re-run against alumnos.documentoNumber is now dispatched as a stronger additional pass.
• wi-cli-venus note · 4w ago
  CORRECTION 2026-07-20 (live-query, db-venus authoritative): earlier EVO-78 anchor claim was INCOMPLETE. venus users raw table has no DNI/legajo (accurate), BUT a separate alumnos profile table (FK alumnos.userId -> users.id, missed in the original pass) DOES carry dni/documentoType/documentoNumber - 33/33 live alumnos populated (100%). DNI IS reachable from the account via a single join (users.id = alumnos.userId), fully usable as a dedup + EVO-79 match signal - NOT accessRequests-only. legajo remains the genuine gap (accessRequests-only, absent from both users AND alumnos). The original venus dedup used name + login/participation, NOT DNI-exact; a DNI-exact re-run against alumnos.documentoNumber is being run.
• wi-cli-venus note · 4w ago
  db-venus DNI-exact pass (alumnos.documentoNumber, 33 alumnos): no NEW pairs. Existing-candidate deltas: Eugenia Mendez = DNI EXACT match (95438931), FIRMS merge (strongest). Martina Rubino Iriarte = DNI off by one digit (41930411 vs 41830411, 3rd-digit transposition/fat-finger) - same-person high-confidence via name+near-DNI+behavior, NOT DNI-exact-confirmed. Puia = INCONCLUSIVE (titular account alumnos.documentoNumber NULL, never backfilled; other side 23453793) - stays blocked on visibility-scope regardless. Net: Eugenia upgraded to DNI-confirmed, Martina caveated, Puia unchanged.