Admin action: agregar participante omitido a una practica fuera de la ventana de 48h
GAP FOUND VIA SOP-VENUS-18 (2026-08-16): a creator who omits a participant at load time has NO app path to add one after 48h. MEASURED, not inferred: - /corregir CANNOT do it at all, at any time. correction-fields.ts:11 lists 'participantes' as an explicitly EXCLUDED cascade field; CORRECTION_FIELDS is 17 scalar practicas columns; correction-actions.ts gate 9 states apply is 'practica-ROW-only'. participantes live in practicaParticipations (child table). - /editar (editarPractica) DOES handle participantes (soft-delete + resurrect), but is gated by EDIT_WINDOW_HOURS=48 from COALESCE(editWindowOpenedAt, createdAt) and MAX_EDITS=3. - No admin override exists: editWindowOpenedAt appears only in practica-actions.ts, correction-actions.ts (G5 forbids touching it) and db/queries.ts; admin-actions.ts has no practica-edit surface. So the only remedy today is a manual UPDATE of editWindowOpenedAt by the DB lane (done once for SOP-VENUS-18 under pm-venus-cc GO, actor+reason recorded in practicasArchive). That does not scale and puts a support desk on a bare row patch. PROPOSED: an approver-gated (administrador/bedelia) server action to add a MISSING participant to a practica, writing practicaParticipations directly, inside a txn with setArchiveContext, honouring trg_participations_operador_unique (<=1 operador) and the soft-delete/resurrect semantics editarPractica already implements. Should NOT touch editCount/editWindowOpenedAt (same independence the correction path keeps, G5). Consider whether removal needs the same treatment or add-only is the safe scope. Ref: mem:reference_archive_trigger_guc. Not urgent per pm-venus-cc.
Activity
-
GO from pm-venus-cc 2026-08-22: SOP-VENUS-18 lapsed on both reopens (3609, 3610), San Mauro used /editar once on 2026-08-15 without touching participantes - access was never the blocker. Do NOT re-contact, do NOT open a 3rd window, do NOT bare-row-patch the interim. Build VENUS-372 as the actual remedy; ticket 56e7f607 closes on our action.
-
Building: approver-gated add-missing-participant action. GO from pm-venus-cc 2026-08-21 21:56 after SOP-VENUS-18 lapsed (2 reopens, zero user action).
-
SHIPPED, WAITING ON ONE HUMAN CLICK - not on code. Action: 7644158 (approver-gated addMissingParticipant, administrador|bedelia only, NOT titular; add-only; does not touch editCount/editWindowOpenedAt; archiveReason prefix admin:). UI caller: 95f6e24 v1.16.0 (AddParticipantBox on the practica detail card, visibility gated on isApprover). 7644158 alone was a ZERO delivery - a server action with no caller is unreachable by a human. Live-verified v1.16.0 via /api/health. Remaining leg is Lorena Salomone (bedelia) using the control on practica 1ea22624-98a1-4ab5-8a31-86afda998cec to seat Colioni Laura as Observador, ticket 56e7f607. Re-read at 2026-08-22 07:0x UTC: practicaParticipations still exactly 2 rows (Tajes / San Mauro, both createdAt 2026-08-14 02:12:25, no soft-deletes), so she has not acted. DO NOT CLOSE THIS ON THE EMAIL HAVING BEEN SENT - it closes when the row exists. Expected branch when she does act is insert, NOT resurrect, since Colioni has no row live or soft-deleted; if the archive shows resurrect instead, that is a real finding. If she reports the button is invisible that is a role-resolution defect in new code, not user error, and comes to coder-venus-cc.
-
MEASURED 2026-09-11 14:5x UTC, prod DB: the code leg of this row is DONE and the remaining leg is NOT a code leg, and the reason it has not moved is not the one the 2026-08-22 note assumed. practicaParticipations on 1ea22624-98a1-4ab5-8a31-86afda998cec is STILL exactly 2 rows (San Mauro rolEnPracticaId=1, Tajes rolEnPracticaId=2, both createdAt 2026-08-14 02:12:25, zero deletedAt) - unchanged in the 20 days since. So Colioni Laura is still unseated and the expected branch is still insert, not resurrect. THE APPROVER HAS NOT HELD A SESSION SINCE 16 DAYS BEFORE THE CONTROL SHIPPED. Lorena Salomone (users aa3638ea-9d2c-4784-9963-e52e4bcc8beb) holds role=bedelia in userRoles, deletedAt NULL, so isApprover() returns true and the box IS visible to her - this is NOT the role-resolution defect the note said would come to me. Her identity is attached (googleSub 106053903177428570172, authId 746790ad-b80b-4d51-8afd-b48566b56a39, appEvents identityBound 2026-08-07 15:10). But auth.users.last_sign_in_at = 2026-08-06 13:05 UTC, her newest auth.sessions row was created 2026-08-06 13:05 and its updated_at NEVER ADVANCED past creation, and her newest of 6 refresh_tokens is also 2026-08-06 13:05. Three independent auth-side instruments agree. AddParticipantBox shipped 95f6e24 v1.16.0 on 2026-08-22. She has therefore never once loaded a page that contained the control. I did NOT rest this on appEvents, and that matters: nearly every appEvents action in the last 30 days has effectiveUserId NULL (error-shown 257 rows / 0 users, 404-probe 224/0, loginCallback 38/0), so appEvents is a WEAK activity instrument here and her single row proves nothing on its own. auth.sessions/refresh_tokens is the instrument that carries the claim. SECOND MEASURED FACT, and it reverses who is blocked: laucolioni@gmail.com - the person to be SEATED - signed in 2026-09-02. The subject is active; the approver is absent. THE UNBLOCK IS NOT CODE AND IS ~30 SECONDS. Exactly two accounts hold an approver role: Lorena Salomone (bedelia) and Elazar Pimentel (administrador). isApprover admits both identically, and the practica detail page gates the box on isApprover(roles) alone with no sede/ownership narrowing, so Elazar sees the control on this practica today. Either he seats Colioni himself, or somebody re-contacts Lorena - but re-contacting was already tried twice under SOP-VENUS-18 and lapsed both times, which is precisely why this row was built. Scope question in the description is ALSO closed and was closed at build time, not now: add-only is deliberate, with the rationale in add-participant-outcome.ts:9-13 - removal outside the 48h window destroys a clinical attribution with no user-visible trace beyond the archive, and only the omission case has measured recurring demand. No open code decision remains on this row.
-
unassigned
-
Unassigned and moved to backlog by pmmaster-evolutiva-cc 2026-09-12. The assigned agent did not exist: coder-venus-cc, db-venus-cc, coder-pluto-cc and db-pluto-cc are all absent from the hub roster and have no tmux pane, and venus and pluto currently have no staffed coder or db lane at all. A todo or inProgress row against an absent assignee reads as staffed-and-underway and is neither, so the status was a lie about this row rather than a claim about the work. The work itself is untouched and the priority is unchanged. Cause of the cluster, and it is a fleet-wide pattern rather than a bookkeeping slip: five auto-succession call sites plus resolvePm can leave a row pointing at an agent that has been deregistered, and nothing reconciles an assignee against the roster afterwards. Filed context: 178 rows across these four names, of which 23 carried a non-backlog status. Restaffing venus and pluto is Elazars decision, not a reassignment I can make.
-
Same decision as VENUS-56: post-48h admin edit fulfillment, which Elazar ruled 'not for now' (2026-06-26). Build only on a fresh GO.
-
Same decision as VENUS-56 (post-48h admin edit), Elazar 'not for now' 2026-06-26; build only on fresh GO