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

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.
• wi-cli-venus canceled · 5w ago
  scope obsolete: premise falsified. Confirmed 2026-09-11 across the whole authed render path (src/app/(protected)/mi-cursada/page.tsx, src/lib/practica.ts, src/lib/self-service-assignment.ts) - zero notFound() calls anywhere. Zero-assignment authed alumno renders MissingComisionPrompt (page.tsx:103), zero-practica renders EmptyState (page.tsx:211). Bare /mi-cursada never 404s for an authed user with no active cursada; there is no empty-state-vs-404 gap to close. Separate real finding surfaced while investigating (not this WI's scope, reported to coder-mars-cc with no WI yet): not-found-classify.ts has no carve-out for legitimate external OAuth-redirect referers (e.g. accounts.google.com) - indistinguishable from an ordinary stale/typo external link, classified WARN genuine-bad-route.
• wi-cli-venus statusChanged · 5w ago
  Reopened same turn: my cancel was wrong. CONFIRMED the hypothesized mechanism is false (no notFound() anywhere in the authed render path: page.tsx/practica.ts/self-service-assignment.ts all zero notFound calls; zero-cursada renders EmptyState, never 404) - but the WI's OWN origin observation (a legit OAuth-redirected alumno landing on /mi-cursada got classified genuine-bad-route) is real and I found its actual mechanism: not-found-classify.ts's external-referer branch has no carve-out for legitimate external auth-redirect origins (accounts.google.com etc, grepped - none exists) - a genuine post-login bounce is indistinguishable from an ordinary stale/typo external link and gets classified WARN/genuine-bad-route. Real bug, different root cause than hypothesized. Next step: add an origin allowlist/carve-out to the external-referer classification branch so a Google-OAuth-referer 404 is tagged distinctly from genuine external noise, before it feeds MARS-583's alert-rail counts. Not implemented - flagging root cause per this triage pass's scope (investigate-and-report, not fix).
• wi-cli-venus priorityChanged · 5w ago
  2
• wi-cli-venus blocked · 5w ago
  coder-mars-cc's review of 3763552 (P1, valid): the carve-out only fires on the !sameOrigin leg, but by the time the user's browser hits the page that 404s, the last-hop referer after the Google->Supabase->app /callback chain is plausibly the app's OWN /callback URL (same-origin) - which never reaches my new branch at all and instead hits the dead-internal-link escalation (ERROR+alert, line ~478). All 5 new test fixtures constructed the referer from the chain's SHAPE, not a captured production value - a test written against the same assumption as the code cannot falsify the assumption. 3763552 is shipped (mechanism is correct IF the external-host hypothesis holds) but UNVERIFIED against real data. Do not close on this SHA. Blocked on db-mars-cc's raw appEvents referer+path pull for the original MARS-165 observation (queued after MARS-417) - once that lands, either confirm the branch matches the logged referer, or amend it to whatever the data shows (most likely: extend the carve-out to also cover the same-origin /callback-referer case, tagged distinctly from a real dead internal link).
• wi-cli-venus commented · 5w ago
  Ground truth from db-mars-cc's raw referer pull (all 19 /login rows, 2026-06-21, unaggregated): neither prior hypothesis fully matches. 15/19 (79%) carry NO referer at all (null, not external, not same-origin) - this is the MAJORITY and neither the shipped external-host carve-out (3763552) nor coder-mars-cc's same-origin/callback theory can key on it, since there is no host to match against absence. 2/19 carry accounts.google.com (05:15:06 genuine-bad-route, 12:42:56 transient-valid-route-miss) - confirms the external-OAuth-referer mechanism IS real, just a small minority (~10%), and ZERO rows ever carried a supabase.co host or /callback in the referer in any form - that half of the allowlist has no empirical support (kept anyway, theoretically still reachable per the redirect chain, just unobserved). 1/19 is same-origin but points at /login itself (a reload - already correctly handled by the pre-existing referer==self path, not a bug). 1/19 is campusgrado.odontologia.uba.ar - the institution's own site linking a real user into /login, which 404'd; a genuine external dead link, historical/non-recurring (same day as the rest, zero since 2026-08-01 per MARS-583's closure), not filing separately. Behavior check: NONE of these 19 rows were ever mis-paged - null-referer and external-referer both land at the pre-existing WARN/no-alert tier regardless of my carve-out; the carve-out only adds a classification TAG, it never changed what pages. So 3763552 shipped no incorrect behavior, it just tags ~10% of a small (19-row, one-day, non-recurring) population rather than the 79% majority. Full NULL-referer coverage would need a different signal entirely (session/cookie recency correlation to a login event, not referer matching) - a materially bigger mechanism for a population with zero recurrence in 10+ weeks. Recommending to coder-mars-cc: keep 3763552 as shipped (harmless, catches the 2 real cases), document this finding, close on low ROI for further engineering rather than building session-correlation for a non-recurring historical cluster. Their call, not mine alone - they hold the other half of this review.
• wi-cli-venus unblocked · 5w ago
  cleared: coder-mars-cc's review of 3763552 (P1, valid): the carve-out only fires on the !sameOrigin leg, but by the time the user's browser hits the page that 404s, the last-hop referer after the Google->Supabase->app /callback chain is plausibly the app's OWN /callback URL (same-origin) - which never reaches my new branch at all and instead hits the dead-internal-link escalation (ERROR+alert, line ~478). All 5 new test fixtures constructed the referer from the chain's SHAPE, not a captured production value - a test written against the same assumption as the code cannot falsify the assumption. 3763552 is shipped (mechanism is correct IF the external-host hypothesis holds) but UNVERIFIED against real data. Do not close on this SHA. Blocked on db-mars-cc's raw appEvents referer+path pull for the original MARS-165 observation (queued after MARS-417) - once that lands, either confirm the branch matches the logged referer, or amend it to whatever the data shows (most likely: extend the carve-out to also cover the same-origin /callback-referer case, tagged distinctly from a real dead internal link).
• wi-cli-venus completed · 5w ago
  Shipped: not-found-classify.ts AUTH_REDIRECT_REFERER_HOSTS carve-out (3763552), unblocked - coder-mars-cc's same-origin/callback P1 was falsified by db-mars-cc's raw referer pull (zero of 19 /login rows carried /callback or a supabase.co host in any form). Coverage stated plainly: the carve-out reaches 2 of 19 rows (the two real accounts.google.com hits). 15/19 carry NO referer at all - neither this carve-out nor any referer-keyed rule can match an absence, and that majority is correctly left as scanner/probe-shaped noise (do not widen to swallow NULL - that would tag real scanner traffic as auth-bounce and destroy the one signal separating them). Tier/behavior was never wrong either way: null and external referers both already land at WARN/no-alert regardless of the carve-out - it only adds a classification tag. Population is 19 rows, one day (2026-06-21), zero recurrence since 2026-08-01 - closing on low ROI for further engineering (a NULL-referer fix would need session/cookie-recency correlation, a materially bigger mechanism, for a dead cluster). MARS-583 stays closed per its own disposition, not reopened.