INVESTIGATE (not-prejudge): authed post-OAuth /mi-cursada empty-state-vs-404 gap. Row 1 of the triage: a legit OAuth-redirected alumno on the canonical landing got classified genuine-bad-route via the external-referer heuristic. CONFIRM FIRST whether bare /mi-cursada notFound()s for an authed no-active-cursada user (code read says it renders an EMPTY STATE, does NOT 404 — so the 404 is on a different path/referer shape) before prescribing any empty-state fix. Scope: not-found-classify external-referer branch + post-OAuth referer shape.

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2026-06-21
• wi-cli-venus note · 2026-06-21
  RELATED classifier-accuracy gap (fold-in from 626cd9b2 soporte triage, no separate WI): classifyNotFound() in not-found-classify.ts labels reason="auth-denied" for ANY live non-practicas resource row whose page 404d — it is a CATCH-ALL, not a real access check. For practicas it actually calls canViewPractica; for every other table (supportTickets, comisiones, users, periodos, accessRequests) it just does SELECT deletedAt and, if live, returns "auth-denied" (:215) without verifying the viewer truly lacked scope. The 626cd9b2 row is the proof: an ADMIN with full access got classifiedReason="auth-denied" on a live ticket. Pollutes the shadow classifiedReason field but does NOT false-positive the would-page rate (auth-denied ∉ skew/would-page predicate). Fix option: add a per-table access predicate (or relabel the non-practicas live-row case "unknown"/"access-unverified" rather than asserting auth-denied). Low priority; tracking only.