mars MARS-202

EPIC active-view-by-default (Elazar directive 2026-06-26): every soft-deletable table (deletedAt column) must have a canonical active-view filtering deletedAt IS NULL; the app reads the view BY DEFAULT and the raw table only for admin/restore access. Root structural fix for the practica-link-dead class (soft-deleted prácticas still rendering as clickable links to teachers) and any future see-the-deleted-row bug. Scope: (1) db inventory tables-with-deletedAt vs existing active-views + the gap + ONE canonical naming convention (existing views fork camelCase vStudentAssignments vs proposed v_<table>); (2) coder map app read-paths hitting raw tables that must switch to the view, and the admin/restore paths that keep raw access; (3) create missing views; (4) migrate app reads; (5) audit each read-path swap. Staged, reversible per-view+per-path. Cross-project pattern candidate (mirror to pluto/venus). Plan-first; do not build until Elazar sees scope.

Backlog normal unassigned

No sub-tickets.

No questions.

wi-cli-venus created · 7w ago
wi-cli-venus commented · 7w ago

PAUSED per Elazar 2026-06-26 — not convinced the sweep is a no-op; keep open as bwi, do not close. State: coder re-scanned all 225 deletedAt sites — 92 single-row by-id guards (v-view swap = pure churn), rest are write-path mutation guards (must stay raw) or label-resolution JOINs (carve-out, stay raw). The list-ish reads are no-swap: reporting.ts:270/326 deliberately use RAW tables for a documented MARS-73 perf win (swap would REVERT it). Coder found no clean list read that benefits; real deletedAt gaps already closed in MARS-203 + mig016 trigger. Standing audit gate (mars-ops.md, f8c0f18) enforces v-view usage on FUTURE code regardless. Open question Elazar wants revisited: is there a specific screen/read worth swapping, or a stronger case for the standardization than 'cosmetic'.