Instrumento MOVILBA-738: censo de FK a opciones - veredicto de audit antes del commit

Sub-tickets

Activity

• db03-mba-l-cc created · 1w ago
  parent=#4552
• db03-mba-l-cc note · 1w ago
  db03 2026-10-08 ART. THE COVERAGE ASSERT HAS NOW BEEN SEEN TO FAIL, so it is a control and no longer a green line. This closes the weak point I named when opening this item, before audit reviews it. THE MUTANT, one token, on a copy in the scratchpad and never in the repo file: the DO block's driving query gets AND att.attname <> 'wifi_id' appended to its cardinality filter, so the loop censuses fewer columns than there are single-column FKs. diff against the instrument is one line, 77, and nothing else. RESULT, PROD movilba, same read role: the mutant ABORTS with rc=3 and prints ERROR: MOVILBA-738: el censo cubrio 36 columnas y las FK de una sola columna son 38. The repo file on the same base and in the same session gives rc=0 and prints NOTICE: COBERTURA: 38 columnas censadas, una por cada FK de una sola columna a opciones. So both sides were observed: the assert fires on under-coverage and stays silent on full coverage. ONE DETAIL WORTH READING RATHER THAN SKIPPING: excluding the single name wifi_id removed TWO columns, not one - public.vehiculos_datos_colectivos.wifi_id and rutap.vehiculo_historial_normalizado.wifi_id - which is why the failure says 36 and not 37. The arithmetic of the failure message is consistent with the mutation, which is the second thing that makes it a control rather than a coincidence. STILL NOT EXERCISED in this instrument: the branch where a table exists but cannot be read - the permission_denied case is commented in the file from the PROD app role but the file does not catch it, it simply stops under ON_ERROR_STOP, so there is no assert about it to fail. Nothing here changes the file's sha256 c017c024362b34861020f57cab5fa7b15fcc198cc276122eefa713a3b1117856.
• audit-mba-l-cc audit-finding · 1w ago
  # MOVILBA-774 - audit verdict: PASS. Author db03-mba-l-cc. audit-mba-l-cc, 2026-10-08 Instrument tools/verification/movilba-738-censo-fk-opciones.sql, pin c017c024 confirmed exact, untracked (correctly - no commit yet named in bwi), full file read. ## Ran fresh myself, both bases DEV (movilba_user): rc=0, NOTICE "38 columnas censadas", 37 populated rows, 1 zero-row column (rutap.vehiculo_historial_normalizado.motivo_id), 0 rows pointing at a borrado opcion. PROD: the app role (svc_nextjs) cannot run this - confirmed the file's own comment, permission denied on rutap.chasis_resolver under SUPERUSER_ELAZAR_URL's own grant check is moot since elazar has full access; ran under SUPERUSER_ELAZAR_URL, rc=0, NOTICE "38 columnas censadas", 29 populated rows, 9 zero-row columns. The 9 match the 763 doc's own 9-empty-in-PROD list name for name (asociaciones_entidad_persona.tipo_asociacion_id, direcciones_postales.tipo_direccion_id, licencias_choferes.clase_licencia_id, personas_datos_chofer.ambito_id, recorridos.sentido_id, validadoras.modalidad_id, validadoras.tipo_id, validadoras_historial.evento_tipo_id, rutap.vehiculo_historial_normalizado.motivo_id) - cross-instrument consistency with 763's independently-run census. Structure (39 FKs, 38 single-column + 1 composite vh_norm_categoria_catalogo_fk) matches 763 exactly. DEV's clase_licencia_id 38 rows / 2 pares (licencia/clase_lnc, personas/clase_licencia) matches 763's 35/3 reparto claim (same underlying mixture, different grouping granularity). ## The four review points from the ticket, checked 1. Coverage assert: forced it myself on a scratch copy, one-line mutant (AND att.attname <> 'wifi_id' in the DO block's driving query), diff against the repo file is exactly that one line. PROD run: rc=3, "ERROR: MOVILBA-738: el censo cubrio 36 columnas y las FK de una sola columna son 38" - matches db03's report exactly, including the 36 (two wifi_id columns removed, not one: public.vehiculos_datos_colectivos.wifi_id and rutap.vehiculo_historial_normalizado.wifi_id). The assert fires on under-coverage and stays silent at full coverage - both sides observed, now a control. 2. Section 3b correctly separates zero-row columns as SIN EJERCITAR, not folded into the clean/populated table - confirmed in my own output, both bases. 3. Section 3c counts borrado-opcion references without filtering them out of the main census - confirmed by reading the query (no borrado_en IS NULL filter on the join) and by the output (0/0 in both bases, which this ticket's checklist calls a separate question, not silently assumed clean). 4. Every total in section 2 is its own count(DISTINCT ...) - confirmed by reading the query: 4 independent aggregates in one SELECT, no shared GROUP BY to blur them. 39/39/16/1 both bases. Permission-denied-on-app-role and the old ON COMMIT DROP failure are both named in the file's own comments as already-seen failures, not reproduced by me - they're documentation of history, not live claims needing a fresh repro. ## NOT EXERCISED No DDL, no composite FK written, no app surface. The permission_denied-for-unreadable-table branch has no assert and none was added - noted as a real gap in db03's note and confirmed by reading the file (ON_ERROR_STOP just aborts, nothing names the cause).
• audit-mba-l-cc audited · 1w ago
  audit pass: Instrument rerun fresh both bases (pin c017c024, untracked). Coverage assert forced to fail with db03's one-line mutant, reproduced rc=3 myself. All 4 review points checked against the query text and live output.
  payload

  {"scope":"Instrument rerun fresh both bases (pin c017c024, untracked). Coverage assert forced to fail with db03's one-line mutant, reproduced rc=3 myself. All 4 review points checked against the query text and live output.","outcome":"pass","evidence":"38/38 coverage both bases rc=0; mutant rc=3 exact message match (36 cols, wifi_id x2); 9-empty PROD list matches 763's census name for name; 3b/3c/independent-counts confirmed by reading the SQL.","reportRef":null}

• coder03-mba-l-cc commit · 1w ago
  coder03 2026-10-09 00:08 ART. Audit PASS already posted 23:58 (38/38 coverage reproduced, mutant test independently reproduced, one gap carried forward: permission_denied-on-unreadable-table has no assert). No code/coder lane owns this instrument item - closing on the PASS per protocol (audit verifies, dispatcher closes when no separate coding lane exists).
• coder03-mba-l-cc completed · 1w ago
  completed