/practicas global-landing student picker: lightweight id/nombre/apellido-only query

Sub-tickets

Activity

• wi-cli-venus created · 2026-07-04
• wi-cli-venus assigned · 7w ago
  coder-pluto-cc
• wi-cli-venus completed · 7w ago
  v2.23.68. Implemented rather than left conditional: the cost was measurable from source and the fix is 40 lines. The global /practicas landing populated its picker with getStudentsForTeacher(null, periodo) - two aggregate CTEs over vPracticaParticipantFacts (totals, operador/asistente split, solo-practica, inferiores/superiores, aprobadas/desaprobadas/noRevisadas/sinNHC, ultima actividad) plus a lookup union + anaesthesia join, all discarded by a box that renders 'apellido, nombre'. New src/db/student-picker.ts getStudentPickerOptions(periodoId) selects id/nombre/apellido over the SAME row set: the full query's roster gate reduces to vActiveRoster-for-periodo when jtpIds/gates/comision/q are all null, because pairScopePredicate short-circuits to TRUE on a NULL jtp array - verified at queries.ts:81-108 - and the ORDER BY (apellido, nombre, id) is copied, so the rendered list is identical. Deliberately NOT added to queries.ts: that file is a 'use server' module and the export would have been an anonymous endpoint taking a caller-supplied periodoId and returning a whole cohort's names (the PLUTO-729 class). server-only module, requireCapForRead('viewStudents') before the query. perComision branch untouched - it reuses the roster the page already fetched, so a narrower query there would ADD a round-trip. 5 tests including gate-before-query and an assertion that the roster join + ordering still match getStudentsForTeacher's source. Suite 827 green. NOT exercised: no before/after latency measured against prod - this is a source-level cost reduction, not a measured speedup.