PLUTO D8 compute-placement remediation (self-scan)

Sub-tickets — 1/1 done

Activity

• wi-cli-venus created · 2026-06-14
• wi-cli-venus commented · 2026-06-14
  Tracking WI for the Dimension-8 (Postgres-vs-Node compute placement) self-scan remediation. Source: coder-pluto D8 self-scan first-pass 2026-06-14 (/informes+/alumnos excluded — those are PLUTO-93/97). 11 findings across 4 tiers. STRATEGY: durable fix = collapse to Postgres (bundle-RPC/CTE/view per the PLUTO-97 pattern), NOT app-side limiters. Limiter is band-aid Elazar criticized; these pages have NO active timeout (latent risk, single-admin load) so no interim band-aid warranted — do the real fix. SEQUENCED AFTER PLUTO-97 lands (PLUTO-97 = reference impl; db replicates the pattern). Children below.
• wi-cli-venus assigned · 7w ago
  coder-pluto-cc
• wi-cli-venus note · 7w ago
  Children recovered - wi show hides closed ones, so the 'children below' list read as empty. Full set: PLUTO-99 Tier-2 (done, no-action on measurement), PLUTO-101 (done), PLUTO-102 Tier-1 bundle-RPC collapse (done), PLUTO-100 Tier-3 (open, held on db measurement), PLUTO-103 hygiene (open, db-pluto-cc, assigned 08:48 today). Dependency cleared: PLUTO-97, the reference implementation this was sequenced behind, closed 2026-06-14. Parent stays open on 100 + 103 only; the 11-finding scan is otherwise worked through.
• wi-cli-venus note · 7w ago
  PLUTO-100 closed (no-action, split verdict: admin-batch role loop measured-bounded at 8; roster import unexercised-in-prod, per-row shape kept because the per-row archive reason and per-row error reporting are load-bearing). Parent now blocks on PLUTO-103 alone (vPracticaParticipantFacts demo-practica contamination, db-pluto-cc). Coder legs of the D8 self-scan are done.
• coder-pluto-cc verified · 1w ago
  FRESH D8 re-scan 2026-10-06 (coder legs closed 2026-08-22, so this covers only what changed since). SCOPE: the 52 files under src/lib, src/db, src/app changed since 2026-08-22. INSTRUMENT: a brace-depth tracker (strings and comments skipped, or a brace inside a SQL literal shifts every depth after it) reporting awaited client|pool|tx|c.query / pool.connect lexically INSIDE a loop body, plus a .rows.(reduce|filter|sort|flatMap) pass. Two false-positive classes were measured and excluded, not guessed: (a) transaction control inside a loop (BEGIN/COMMIT/ROLLBACK/SAVEPOINT/RELEASE/SET LOCAL) is an early exit or a per-row error boundary, not per-row compute, and counting it inflates the census with the rows that are CORRECT; (b) a braceless single-statement loop opens no body, and left pending it attaches to the next unrelated block and reports every query in it. Raw awk without brace tracking said 29; the instrument said 15; after the two exclusions, 6. N+1 RESULT: 6 awaited queries inside a loop body across 3 sites, all adjudicated no-action. 1. src/app/api/internal/poll-security-alerts/route.ts:103 (loop@83) - NEW since the last scan. No action: BATCH_LIMIT = 50 bounds it, and the per-row UPDATE securityAlerts SET emailedAt = now() WHERE id = $1 is the exactly-once guard against a duplicate send. Batching it after the loop trades a resend hazard for a lower query count - the wrong trade on an email rail. 2. src/lib/admin-batch.ts:406 (loop@405, for roleId of args.roleIds) - already closed by PLUTO-100: measured-bounded at 8. 3. src/lib/administrar-actions.ts:1524/1541/1551/1557 (all loop@1469, roster import) - already closed by PLUTO-100: per-row shape kept because the per-row archive reason and the per-row error reporting are load-bearing. IN-JS ROW-SHAPING RESULT: exactly 1 hit, src/lib/practica-actions.ts:673 - candidates.rows.filter((r) => canonicalPiezaKey(r.piezaDentaria) === wantedKey) in the 23505 recovery path. No action applied, but the justification in the comment above it is now SPENT and the row should carry that: lines 647-654 keep the compare in JS so the code lane and db migration 117 could ship in either order, and 117 is now in db/migrations/applied/ (117-pluto-728-canonical-pieza-natural-key.sql, further amended by 121 for the search_path pin) with f_canonicalPiezaKey present in the generated db/schema.md. With 117 landed, the D8-correct form is AND f_canonicalPiezaKey("piezaDentaria") = f_canonicalPiezaKey($5) in the two SELECTs with the JS filter deleted. The argument for doing it is NOT performance - the candidate set is bounded by the natural key minus pieza (one pair, one day, one periodo) - it is that the JS copy is one of the two JS<->DB lockstep surfaces that practica-actions.ts:34-39 already warns must change together. Deliberately left as a follow-up rather than applied in the same pass as the census; it touches the práctica-create recovery path and needs its own forced-red test. COVERAGE LIMIT: this scan covers exactly two shapes (awaited-query-inside-a-loop-body, and .rows.reduce|filter|sort|flatMap) over CHANGED FILES ONLY. It does not re-scan the files unchanged since 2026-08-22, and it says nothing about aggregation, pivots, dedup or set-based writes that are already in SQL or were never written. No fixes were applied: every finding is either already adjudicated by PLUTO-100 or a deliberate correct shape. PLUTO-103 (vPracticaParticipantFacts demo-práctica contamination) remains db-pluto-ccs and is the only thing this parent still blocks on - unchanged by this scan.
• coder-pluto-cc note · 1w ago
  The one follow-up the re-scan produced is filed as child PLUTO-781 (p3, coder-pluto-cc): move the canonical-pieza 23505 recovery compare out of JS into SQL now that migration 117 is applied. Not applied in the census pass. This parent still blocks on PLUTO-103 only (db-pluto-cc).