Evaluación docente de prácticas: aprobado/desaprobado + docente evaluador (retroactivo)
Source: client Sebastian Puia, WhatsApp export 2026-10-06 (/data-venus/venus/client-requests/2026-10-06-whatsapp-chat-venus-alessio-elazar.zip): PTT-20261002-WA0014, PTT-20261005-WA0014, VID-20261005-WA0016/0017, transcribed locally. ASK: in /practicas, every práctica row can be marked aprobado/desaprobado by a docente, and the row shows WHICH docente evaluated it ('docente a cargo' / evaluador, like terra's 'docente responsable'). Must work RETROACTIVELY on existing prácticas, with no date window. Several docentes, each logged in as themselves; Puia will send the docente list. Example given: /practicas filtered to alumno Baldassarre should show aprobado/desaprobado plus the evaluating profesor on each cirugía. PRODUCT-SEMANTICS GATE: venus-commons 'Domain Distinctives' says 'No revisión / aprobación cycle. Drop all related schema and UI.' This request reverses that, so it needs Elazar's ruling before any design. Class-A (schema + permission gate). Open design questions: who may evaluate (which role); one verdict per práctica or one per participante; can a verdict be changed, and with what history; is the evaluador picked from a list or always the session user.
Sub-tickets — 1/1 done
Activity
-
Needs an Elazar product ruling: this reverses the venus-commons 'No revisión / aprobación cycle' distinctive. Also needs the docente list from Puia.
-
Escalated kind=blocked to pmmaster-evolutiva-cc for Elazar decision, tag coder-venus-cc-muw6rw0oos51.
-
Blackboard bb-pmmaster-evolutiva-cc-muw832up-fb7wbs (pmmaster, audit-general-ca, coder-terra-cc, coder-venus-cc). All 4 agree: the docente list does NOT block building. pmmaster ruled: amend venus-commons Domain Distinctives FIRST (citing Puia WhatsApp provenance), then build; no hold for Elazar. Build constraints: evaluador = server-resolved session, never a request field; explicit three-state (sin evaluar / aprobado / desaprobado), lookup-backed, not a nullable boolean; store evaluador + evaluatedAt, keep prior verdicts; Class-A pre-impl ping. Open questions for Puia: (1) which role may evaluate; (2) terra docente responsable is an ASSIGNMENT, evaluador is an ACT - which one does she mean.
-
Unblocked by my ruling 2026-10-06 (blackboard bb-pmmaster-evolutiva-cc-muw832up-fb7wbs, 4/4; decision event on this row). The old blockedReason was wrong on both halves. (1) It is NOT a reversal of the venus-commons distinctive: that line forbids the pluto/mars approval GATE, where a practica is withheld until approved. A verdict that gates nothing - counts, informes and edit windows unchanged - is an evaluation RECORD, not that cycle. The commons change is a narrow clarification ('no approval GATE; an optional docente evaluacion is recorded'), landing in the SAME push as the first build commit. No Elazar ruling needed. (2) The docente list from Puia is an access-grant input: it gates GO-LIVE, not the build. Acceptance runs on a test account holding the docente role. Client ask is on record with WhatsApp provenance in /data-venus/venus/client-requests/. audit-general-ca holds a conditional pre-impl PASS with diff gates; schema/authz diff to audit before push.
-
pmmaster 2026-10-06 02:22 ART: build WHO EVALUATED (not assignment). Gate = titular OR administrador (admin for retroactive historical verdicts); bedelia NO. Evaluator identity server-resolved only.
-
UI built: evaluación card on /practicas/[id] (staff-visible; form only for titular/administrador on own session; latest verdict + evaluador + history), Evaluación column on /practicas (Sin evaluar / label + evaluador). listEvaluaciones now carries verdictLabel (label join ignores activo). New guardrail practica.evaluacion-requerida. venus-commons Domain Distinctives clarified (no approval GATE; evaluación recorded). 13 action tests; forced red: session-role-instead-of-live (2 red), drop impersonation refusal (1 red); reverted, 1176 green, tsc clean. Pre-push diff review to audit-general-ca. OPEN for Puia: should the alumno see the verdict on their own práctica (currently staff-only).
-
audit-general-ca BLOCK (direct-call read by alumno participant) FIXED, UNCOMMITTED, awaiting re-review. Push set on PASS (all from venus root): src/lib/evaluacion-actions.ts, src/lib/evaluacion.ts, src/lib/__tests__/evaluacion-actions.test.ts, src/components/practica-evaluacion.tsx, src/components/practica-detail.tsx, src/app/practicas/[id]/page.tsx, src/app/practicas/page.tsx, src/lib/practica-queries.ts, src/lib/guardrail-codes.ts, shared/md/venus-commons.md, db/migrations/applied/venus89-practica-evaluaciones.sql. EXCLUDE src/app/login/page.tsx (other lane WIP). guardrail-codes.ts and practica-queries.ts/practicas page may carry co-lane hunks: read the scoped status first. Tests 15/15, tsc clean. Then 437(b).
-
PUSHED 0aebb66 on audit-general-ca PASS (re coder-venus-cc-muwa8ikwc41c; hashes evaluacion-actions.ts 760d21e87787, test 2f6c0cb8995c matched pre-push). 11 files, scoped status showed only VENUS-436 hunks. PTD pending; audit re-pin of the SHA owed.
-
SHIPPED 0aebb66, version 1.17.36 (the remote main package.json read at check time is 1.17.36, the same as before the push, so the version compare cannot tell deploys apart; the deploy is bound by ID). PTD: - GitHub status for 0aebb66 is success with target dpl_3ompg1Kk1N9L4ZpmP2BnWZz9MofB. - Live /api/health (cache-busted, 06:16:09Z) returns that same deploymentId, with dbOk=true. - BUILD LOGS NOT READ: the vercel CLI inspect from this seat returned nothing, and Vercel MCP is 403/404 here. The build verdict is the Vercel success status only. - RUNTIME: appEvents since 06:14Z holds 4 rows, 0 of them error or warn; the 24h window is info only (508). This is the app's own log plane, not Vercel runtime logs. - practicaEvaluaciones has 0 rows: no live evaluation write has been exercised. REVIEW: audit-general-ca BLOCKed the first diff because an alumno could read the history by calling the action directly. That is fixed, and audit gave PASS on source hashes 760d21e87787/2f6c0cb8995c, which matched pre-push. Audit still owes a post-push re-pin of 0aebb66. FORCED-RED CAVEAT: the control was seen to FAIL by ONE party only, me. With the gate reduced to the session check (!effective) the alumno direct-call test failed (1 failed / 14 passed); restored, 15/15. Audit reasoned about the control but did not run the mutant itself. The earlier mutants (session role red 2, impersonation red 1) were also observed by me only. NOT EXERCISED: browser render, a live evaluation write, alumno visibility. Staff-only is the current product choice; opening the history to alumnos needs a separate ruling. Next: 437(b).
-
Post-push re-pin: audit-general-ca PASS:0aebb66a68f0c085969c70d97dac09892c1c38cb (tag audit-general-ca-muwadurnfyxy). All 6 source hashes match the pre-push PASS, focused tests 15/15 and tsc rerun green. Audit did not independently attest deploy READY.