Broken admin-detail links: comisiones/usuarios/alumnos 404 on real records
Measured by executing pluto's live 404 classifier over all 643 admitted routes (VENUS-327/PLUTO-653 side-effect, coder-pluto-cc 2026-07-30), recurring in July not historical. (1) /administrar/comisiones/c0000000-0000-0000-0000-00000000000{1..6} -- SIX broken links into real seeded comisiones, 13 hits in July (...001 x4, ...005 x3, ...006 x3, ...002/003/004 x1). Seeded-UUID rows are real prod data (cf memory pluto-seed-shaped-uuid-rows-are-real-prod) -- not a stale-fixture artifact. Either the rows were removed/soft-deleted or the detail route no longer resolves them. (2) /admin/usuarios/<uuid> x8 distinct users + /administrar/alumnos/<uuid> -- nine broken person-detail links, same shape: real-looking UUIDs 404ing on the detail page. Also low-volume (1-2 hits each) and app-shaped rather than probe-shaped: /admin/errores, /mi-perfil, /completar-perfil, /api/log-toast, /auth. These routes are deliberately being left PAGEABLE (not suppressed) per the VENUS-327 classifier ruling -- this WI is the actual investigation of why they 404. Likely candidates: soft-deleted source row with a stale link/reference not updated, or a route/query mismatch on the detail page. Start by checking whether the 6 comisiones ids still exist with deletedAt IS NULL.
Questions
Activity
-
INVESTIGATED (coder-pluto-cc, 2026-07-30, read-only). WI's original premise wrong for 14/15 rows -- almost none are broken links, and the suggested deletedAt check is falsified (all 6 comisiones rows live, never deleted). Self-correction: 'recurring live' framing in the original report was wrong -- nothing has recurred since 2026-07-17; a positive-controlled recurrence check (889 404s since 07-18, zero on these routes) makes the silence measured absence, not absence of traffic. THREE causes: (1) 6 comisiones 404s -- ALREADY FIXED 13 days ago by PLUTO-578/abc35a0 (2026-07-17 06:02): seed UUIDs c0000000-...-000N carry version/variant nibble 0, old isUuid RFC4122 [1-5]/[89ab] check rejected them, comisiones/[id]:43 called notFound() before scope logic. Last such 404 was 2026-07-17 05:45:26, 17 minutes before the fix. Rows confirmed real in-app clicks (viewerRoles=administrador, referrer=live list page), not probes. No action needed -- close this half as already-fixed. (2) 8 /admin/usuarios 404s -- NOT broken links, the DEACTIVATE FLOW 404ing on itself, STILL LIVE TODAY. Every one fires 145-345ms after that same user's own deletedAt (6 timestamped pairs shown, 2 more confirmed via usersArchive same-session deactivation+bulk-restore). Chain verified by execution: fn_getAdminUserDetail(<deleted user>) returns NULL (control: live id returns non-null) -> admin/usuarios/[id]/page.tsx:31 notFound(). admin-actions.ts:~1434 deactivate action returns {success:true} with NO redirect and NO revalidate, so client re-renders the now-invisible detail page. Operator deactivates a user from the detail page and is dropped on a 404, writing a warn-tier appEvents row every time. Only 1 deactivation since (06-25, no 404, done from list toggle not detail page) -- sample of 1, but the code path is verified live, not inferred from traffic. (3) ONE genuine stale link: /administrar/alumnos/c78154f8..., 2026-06-24, referrer=alumnos list page, user deactivated 06-23 -- either a stale client view or the list surfacing deleted rows, one row, not recurring, separate lower-priority look. Plus 2 older pre-classifier 06-10/11 alumnos rows, no reason recorded, not recurring.
-
RESCOPED (pm-pluto-cc decision): comisiones half CLOSED as already-fixed by PLUTO-578 (abc35a0, 2026-07-17), no further action. Approved fix: deactivate-from-detail-page action redirects to /admin/usuarios with a confirmation toast instead of falling through to notFound() -- Class-S, coder-pluto-cc proceeding. Single stale /administrar/alumnos link + 2 older unrecorded rows: noted, not worth separate work (one row each, not recurring).
-
SHIPPED a239909 (v2.22.32). Root cause confirmed: deactivate-from-detail used router.refresh(), which re-fetched the just-soft-deleted row -> fn_getAdminUserDetail returns NULL -> notFound() -> self-404 + warn row, 8/8 measured. Fix: router.push('/admin/usuarios') + success toast. Reactivate branch untouched. Class-S self-PTD green: live /api/app-version=2.22.32/dpl_Etpab6pRp9L225551Q2v6GZdXq8s, target production, Ready, aliased to evolutiva.pensanta.com.
-
Comisiones half: already-fixed by PLUTO-578 (07-17). Real defect (deactivate-from-detail self-404) fixed a239909 v2.22.32 -- router.push replaces router.refresh(), no more re-fetch of the soft-deleted row. Stale single alumnos link + 2 unrecorded rows noted, not actioned (one-off, not recurring).