Nav visibility gap: /practicas/nueva + /mi-cursada unreachable via sidebar for non-alumno roles

Sub-tickets

Activity

• wi-cli-venus created · 2026-08-07
• wi-cli-venus progress · 2026-08-16
  NAV HALF SHIPPED 6736632 v0.20.9, live-verified, 10 files / 364 insertions / 84 deletions read out of the push output. Acceptance met with no second source of truth: new src/lib/route-access.ts holds the table, nav.ts contains ZERO role literals and groups/orders ROUTE_ACCESS rows through one admits() predicate, and the four page-local consts moved into the table. PRACTICA_ROLES and MANAGER_ROLES are re-exported so action call sites are untouched and user-admin-core's suite still asserts the same two values. The drift was measured, not hypothetical: /mi-cursada and /practicas/nueva gate on PRACTICA_ROLES but were listed under roles.includes('alumno') alone, so FOUR of the five admitted roles saw no link. Class-S read confirmed against the code: the derivation is one-way, so a wrong table shows a link that bounces the user home and cannot admit anyone; every route still calls requireAppUserPage against live vUserGroups, and app-header/app-sidebar remain non-gate helpers that already null out for a roleless user. BOUND: 22/22 new plus 156/156 tree, typecheck clean, live version matches - the suite reads the actual requireAppUserPage calls out of src/app, so it proves the two STATEMENTS agree; it renders no sidebar and proves no route refuses anyone at runtime. No browser exercise.
• wi-cli-venus blocked · 2026-08-16
  Nav half shipped at 6736632. Remaining half is SCOPE, not work: whether docentes/bedeles need a catedra-wide practicas list route, which does not exist at all today - /mi-cursada is by construction one alumno's own cursada. Filed to Elazar as eq 37 (topic terra-practicas-scope) asking whether the route is wanted and, if so, whether they need to read only, filter, or act on rows - that answer decides page vs module. Blocked deliberately rather than left in backlog so it does not read as actionable: nobody can start it without the answer.
• wi-cli-venus priorityChanged · 2026-08-17
  1
• wi-cli-venus note · 2026-08-17
  Elazar re-raised this complaint directly today (2026-08-17, relayed via coder-mars-cc): stakeholders log in, cannot find route to create practicas, stop testing. Nav half (6736632) was never browser-verified live. Bumped to P1, dispatching coder-terra-cc to walk the flow live before TERRA-76.
• wi-cli-venus note · 2026-08-17
  coder-terra-cc live-walked (DB+HTTP, no browser session available): nav confirmed correct against all 5 live role-sets (alumno x130, docente x16, alumno+docente x9, admin x1, client+docente x1) - all get Nueva practica + Mis practicas, all 7 nav routes 307->/login live, none 404. jtp/bedel have ZERO members so their coverage is population-limited, not a defect. REFRAMED: terraPracticas has ZERO rows ever. 154/157 terra members have never completed a sign-in (3 linked accounts, auth.users holds 5 identities total, 2 match no app-user/group row). The reported complaint 'stakeholders log in and cannot find create practica' does not survive contact with the data as a nav problem - either it is one of the 3 linked accounts hitting something else, or (fits the numbers) invitations never reached the other 154. Escalating to Elazar for which account saw it.
• wi-cli-venus note · 2026-08-18
  Walked 2026-08-17 as pm asked. NAV IS CORRECT, the population is the problem. buildNavSections run over the five rolesets that actually exist in live vUserGroups (alumno x130, docente x16, alumno+docente x9, admin x1, client+docente x1): all five get Nueva practica and Mis practicas. Both rails render from the same call in the root layout. All seven nav routes answer 307 -> /login live, none 404. NOT browser-clicked - terra sign-in is Google OAuth and no lane holds a session; this is source + live DB + live HTTP. TWO LIMITS: no jtp and no bedel member EXISTS, so those two role paths are unexercised by the population, not just by me; and route-access.ts's header claims the drift hid four of five admitted roles, which on the live population was docente and admin only. Bigger finding: terraPracticas has 0 rows ever, 157 members, 3 with a supabaseAuthId, auth.users holds 5 identities - 154 seeded members have never completed a sign-in, so they cannot have failed to find a sidebar they never saw.
• wi-cli-venus commented · 7w ago
  787abcb: /practicas cátedra-wide list shipped for ROSTER_ROLES, ?modulo filter, rows link to /practicas/[id]; nav entry under Cátedra. Built under Elazar's 2026-08-22 enhance directive + Puia's 'Recordá las prácticas dentro de los módulos' rather than waiting on eq 37. Awaiting deploy PTD, then close.
• wi-cli-venus unblocked · 7w ago
  LIVE 0.24.8 (787abcb + follow-ups). Nav half 6736632; list half /practicas for ROSTER_ROLES with ?modulo filter, rows link to /practicas/[id]. PTD: /practicas and /practicas?modulo=1 -> 307 /login unauthenticated; route-access + proxy tests green in the gate. NOT exercised: an authenticated docente render (no session available to any lane). eq 37 is answered by the build under Elazar's 2026-08-22 enhance directive; read-only list, no row actions beyond opening the detail.
• wi-cli-venus completed · 6w ago
  BACKFILL written 2026-09-02 by coder-basquetwi-cc, authorized by Elazar directly. Historical repair for the bug fixed in 526f6b0: closing a BLOCKED row straight to a closed status wrote only the 'unblocked' event and never the terminal one, and the close reason landed on that unblock event. The row was always correctly closed (closedAt stamped, status done); only the ledger was wrong, and its last word read 'unblocked' - which reads as still-open to anyone reconciling by event rather than by status. THIS EVENT IS NOT CONTEMPORANEOUS: its timestamp is the repair's write time, not the real close time, which is in closedAt. The original close reason has been left where the bug put it, on the unblock event - it is the only artifact showing the bug's shape. Authorization note: the assignee coder-terra-cc is not a live agent (hub forwards its mail to coder-terra-ca), and coder-terra-ca, coder02-terra-cc and db-terra-ca all declined to authorize in its place. Elazar ruled directly, which is the only remaining authority for an unreachable owner's row.
• wi-cli-venus completed · 6w ago
  test
• wi-cli-venus note · 6w ago
  LEDGER DEFECT, self-reported by coder-basquetwi-cc 2026-09-02: the 'completed | test' event stamped 08:27:45Z immediately above is JUNK. I wrote it probing whether the 'wi event' subcommand existed after the real backfill (08:25:26Z) returned a non-zero exit from a shell pipeline rather than from the write itself - the write had in fact succeeded, and the probe was unnecessary. Events are append-only and there is no delete route, so it cannot be removed; this note is the only correction available. The AUTHORITATIVE terminal event for this row is the 08:25:26Z one. Ignore the 08:27:45Z one entirely - it asserts nothing and was never authorized by anyone.