Solicitudes de acceso -> Pluto-parity refactor (bs-mr4h5azsk3g): adopt Pluto's /admin/solicitudes card-list + detail SKIN on Mars, ZERO feature drop. Mars keeps: match-candidate email vs doc-triple dedup + email-change branch, fraud flags, comision auto-assign-on-approve + block-if-no-active-teacher, signed single-use completar resume-link, needs-info checklist, notify-institutional-email, advisory-lock dup-pending guard, SOL-N numbering, 23505->Spanish map, appEvents-on-every-path. Fold FROM Pluto: copy-analysis-context, per-field needs-info checklist UX, tiered merge-candidate panel skin. Share TO Pluto: signed completar link, comision auto-assign, SOL-N, advisory-lock guard, 23505 map. Process: Mars coder diffs Mars superset vs Pluto reference surface (2 route pages + list/detail clients + access-request action fns + field-spec + status-sql), implements in-repo, NO cross-repo push. ALSO app-sidebar 'Mars v{ver}' label. ASSUMPTION pending Elazar: skin-parity NOT feature-parity-down. Restore-twin fork = SEPARATE shared bug MARS-181, do NOT duplicate here.

Sub-tickets

Questions

Activity

• wi-cli-venus created · 6w ago
• wi-cli-venus commented · 6w ago
  Pluto reference surface READY (read-only, no push): ~/gdrive/projects/evolutiva/pluto/solicitudes-reference/ (17 files @ Pluto main 370a482 / v1.97.25). Start at INDEX.md (dir map, detail 7-action list, list-surface features, server-actions fn->file:line table, PLUTO-448 restore-twin caveat = shared-bug-to-fix not a feature). Corrections in INDEX: access-request migrations are 014/015/022 (schema.md SSOT); submitAccessRequest in auth-actions.ts + approveAccessRequestMatchedBranch in admin-batch.ts; access-requests-list.tsx is LIVE. Dispatch still gated on Elazar skin-vs-feature-parity confirm (Class-A: approve provisions users/roles + email-send -> full pre-impl audit gate).
• wi-cli-venus commented · 6w ago
  ELAZAR DIRECTIVE 2026-07-03 (match/approve flow): (1) FUZZY match candidates — do NOT search by hard exact matches only; adopt Pluto's tiered SCORED merge-candidate panel (name/doc/email similarity, ranked) so a returning user is recognized even without an exact normalizedEmail/doc-triple key hit. (2) LOW-CERTAINTY handling — when a candidate match is uncertain, do NOT auto-link; SURFACE it in the approve/reject/needs-info review form for the operator to decide + document. (3) On a confirmed match: RE-USE the existing account + UPDATE its email (never create a new account) — ties to the email-change branch + MARS-181 resurrect. This refines the match-candidate fold already in scope; the reuse/resurrect handler itself is MARS-181 (sequenced after this WI's approve-path stage).
• wi-cli-venus commented · 6w ago
  SCOPE +security (PM approved to RIDE this WI, audit-flagged 2026-07-03): getMatchCandidates is an ungated exported 'use server' action returning cross-user PII (email/name) for arbitrary input with NO client caller — any authenticated user can invoke it directly (IDOR/PII-enum, same class as the copy-analysis-context PII gate). Fix = un-export it (make it a plain internal fn) since it has no legit client caller; confirm zero client callers before removing the export. Rides MARS-376 because coder is already reworking this exact file (getMatchCandidates surface). Pre-existing hole, but folding is lower-risk than a separate WI churning the same file. Class-A (already). Audit diff-review + PTD gates still cover it.
• wi-cli-venus completed · 6w ago
  Fuzzy-match candidate surfacing + reuse-existing-account on approve. Shipped: S3 write-path (a0cece3, resurrect + Branch-C, code+view-verified) + mig021 fuzzy hardening (41f5ec9, PASS): fuzzy_name+fuzzy_email floor 0.55, fuzzy_email local-part-only (split_part) killing shared-@domain inflation, exact email/doc_triple ungated. Live 2.23.27. Elazar directive (keep fuzzy, make strict) satisfied. S3 live-exercise optional/declined-by-default-B; fixtures held pending teardown.