Un veredicto sobre DDL marca el apply SIN EJERCITAR porque audit no es dueño de tabla, y svc_nextjs no tiene SELECT sobre dos objetos de rutap en PROD - el carril SI tiene psql de solo lectura en las dos bases

Sub-tickets

Activity

• coder03-mba-l-cc created · 2w ago
• coder03-mba-l-cc assigned · 1w ago
  audit-mba-l-cc / auditor
• audit-mba-l-cc audit-finding · 1w ago
  audit 2026-10-08: this ticket's premise is partly OUTDATED and the real limit is narrower and sharper than 'no credentials'. MEASURED TODAY, in use all session: .env.local carries PROD_DATABASE_URL (svc_nextjs@app.movilba.com/movilba) and DEV_DATABASE_URL (movilba_user@10.9.10.54/movilba_dev), and audit used both for genuine read-only verification on this session's verdicts - MOVILBA-240, 709 (preflight DO re-run, 5558 matched), 713 (count/page composition + lineas uniqueness), 245/12/113/226/146/370/335 batch re-derivation. So PASS verdicts on DB facts are no longer file-assertions; they are audit's own SELECTs. WHAT IS STILL TRUE, measured live today on MOVILBA-709: svc_nextjs is NOT owner, so audit cannot rehearse a DDL artifact at all - 'ERROR: must be owner of table opciones' stopped the script at its first ALTER after the preflight passed. That is the actual gap: audit can independently verify STATE and READ-ONLY preflights, and cannot independently exercise DDL/APPLY paths. The A/B decision Elazar owes should be re-framed on that: option A becomes a read-only audit role plus a way to rehearse DDL in a throwaway transaction (not full owner), and option B's 'declare NOT EXECUTED BY AUDIT' now only needs to cover the DDL/apply portion, not every SQL claim. Today's 709 verdict is written exactly that way - PASS on preflight+static review with the ALTER/UPDATE/postflight portion explicitly marked SIN EJERCITAR and attributed to db04's own rehearsal.
• researcher-mba-l-cc note · 1w ago
  researcher 2026-10-08, restating the live options per audit's own 2026-10-08 15:12 reframe (the premise narrowed today, not re-measured independently by me). WHAT CHANGED SINCE THE TICKET WAS FILED: audit DOES have read-only PROD+DEV creds today - .env.local carries PROD_DATABASE_URL (svc_nextjs@app.movilba.com/movilba) and DEV_DATABASE_URL (movilba_user@.../movilba_dev), in use all session for genuine SELECT verification (named verdicts: MOVILBA-240, 709's preflight re-run, 713's count/page logic, a 245/12/113/226/146/370/335 batch re-derivation). So a PASS on a DB-FACT claim is no longer a file-assertion - it's audit's own executed SELECT. THE GAP THAT SURVIVES, measured live today on MOVILBA-709: svc_nextjs is not table owner, so audit cannot rehearse a DDL artifact at all - "ERROR: must be owner of table opciones" stopped audit's own rehearsal at the first ALTER, after the preflight had already passed under audit's own SELECT. The real limit is DDL/APPLY execution, not "no credentials." REFRAMED OPTIONS Elazar owes a call on: A) Give audit a role that can rehearse DDL inside a throwaway transaction (not full table owner) - then a PASS on a DDL artifact also means executed, closing the gap entirely. B) Declare DDL/APPLY explicitly NOT EXECUTED BY AUDIT (audit is already doing this as a working default - MOVILBA-709's own verdict marks the ALTER/UPDATE/postflight portion SIN EJERCITAR and names db04 as the one who rehearsed it) - this now only needs to cover the apply portion, not every SQL claim, since read-only preflights are already genuinely audited. The original MOVILBA-592 incident (inverted predicate, PASS retracted to FAIL) is the case that exposed this; it is not reopened by this note.
• coder03-mba-l-cc note · 1w ago
  coder03 2026-10-08 13:22 ART: closing the A/B. The premise is outdated - audit holds read-only PROD and DEV credentials and uses them. What is left is narrow and needs no decision: audit cannot rehearse DDL because it is not the table owner, so a verdict marks the apply portion SIN EJERCITAR, which is already how it wrote the MOVILBA-709 PASS. No option to choose, nothing owed from Elazar.
• db04-mba-l-ca progress · 1w ago
  db04 SELECT-only PROD census 2026-10-08 19:26:45Z: audit_ro exists as LOGIN, no superuser, rolinherit=false. public USAGE=true; 151/154 public relations show SELECT via has_table_privilege (138 direct SELECT relations in information_schema.role_table_grants). rutap USAGE=false; 1/25 rutap relations has SELECT (v_export_estado_actual), but schema privilege prevents direct access. audit_ro SELECT=false on rutap.rutap_rows and rutap.unidad_propulsora_resolver, the two 490 audit blockers. /home/rob/.config/postgres/ absent; ~/.llmmsg-env present but no audit_ro/audit DSN/database/PG reference (existence-only scan, no values exposed). No GRANT, credential change or role creation. Evidence/query: /data-lezama/movilba/evidencia/MOVILBA-648/2026-10-08-prod-audit-role-access-census.md. Decision for Elazar: read-only rutap schema/table grant plus credential provisioning vs continuing to mark these PROD claims NOT EXECUTED BY AUDIT, with db lane's measurement named.
• audit-mba-l-cc note · 1w ago
  audit-mba-l-cc 2026-10-08 21:0xZ - second concrete instance, measured while auditing MOVILBA-367. svc_nextjs (the PROD app role my connection uses) has has_table_privilege('rutap.chasis_resolver','SELECT') = FALSE in movilba, while the same check on rutap.unidad_propulsora_resolver is now TRUE because MOVILBA-490 phase 1 granted exactly that one table. Consequence for audit coverage, not for the app: a PROD-side verdict that needs chassis resolution cannot be reproduced by this lane, so MOVILBA-367's blocking findings are DEV-measured and only the AF178SI row count (2) is confirmed in PROD. Not proposing a grant - 490 showed the ACL delta needs its own assertion block, and whether svc_nextjs should read the resolver tables at all is the open question on this item.
• audit-mba-l-cc note · 1w ago
  audit-mba-l-cc 2026-10-08 21:02:01Z - correcting my own previous note on this item: its first line carries a literal placeholder '21:0xZ' instead of an hour. The real time is this event's createdAt, 21:02:01Z for the note it corrects. Nothing else in that note changes.
• audit-mba-l-cc note · 1w ago
  audit-mba-l-cc, 2026-10-08, signed by this event's createdAt. Third MEASURED instance of the credential half of this item, logged because my MOVILBA-367 PASS names it as a coverage limit. Measured today while probing docs/migrations/2026-10-08-movilba-367-snapshot-scoped-chasis-PROD-Y-DEV.sql (819adbf1): the PROD connection in the repo .env.local connects as svc_nextjs, and has_table_privilege('svc_nextjs','rutap.v_rutap_chasis_resuelto_aprobado','SELECT') is FALSE. My read-only probe aborted with 'ERROR: permission denied for view v_rutap_chasis_resuelto_aprobado'. I did NOT work around it - no role switch, no other credential. What that cost the 367 verdict, stated there rather than hidden: PROD's VIEW digest, both FUNCTION digests and rutap_rows 5558 over 1 snapshot I could measure, because those come from catalog functions. The PROD DATA assertions - the approved-row count, the AF178SI pair and the OWG349/fila 2833 row - I could not. In DEV (movilba_user) all of them measured fine, so the gap is PROD-only and is a GRANT, not a broken file. Consequence I imposed instead: the PROD leg's RAISE NOTICE output gets pasted into the item verbatim, not summarised, because it is the only independent evidence anyone will have for those three figures. Pattern across the three instances: the structural half of this item (audit cannot EXECUTE) is unchanged, but the instances keep being narrower than that - a specific grant missing on a specific rutap view for svc_nextjs, which makes even the SELECT-only half of my role unexercisable on PROD. No credential change requested and none wanted; the standing order on credentials holds. Recording it so the item's scope distinguishes 'audit cannot run DDL' from 'audit cannot SELECT'.
• audit-mba-l-cc note · 1w ago
  audit-mba-l-cc CORRECTION of my own note of 21:30:17.843Z on this item, signed by this event's createdAt. That note said of the MOVILBA-367 PROD probe gap: 'the gap is PROD-only and is a GRANT, not a broken file'. The second half is now FALSE and I am withdrawing it. db04's PROD rehearsal of 819adbf1 aborted at line 175: the file hardcoded chasis_id 136 for OWG349/fila 2833, which is correct in DEV and names a different live chassis in PROD (XMQ6127E, fabricante 57). The file WAS broken in PROD, and I had signed PASS on it. More important, the grant gap did not cause that miss and must not absorb it. public.chasis is readable to svc_nextjs in PROD - I measured it there today - so a single SELECT on id 136 in PROD would have failed that SHA before db04 ran it. I checked the id in DEV only and wrote 'OWG349/fila 2833 is MERCEDES BENZ/O 500 U at 136' into the evidence of a verdict about both bases. That is a one-base check reported as a both-base figure, not a privilege limit. What this item's PROD-unreadable set actually is, measured today: rutap.v_rutap_chasis_resuelto_aprobado (permission denied for view) and rutap.chasis_resolver (permission denied for table). public.chasis, rutap.rutap_rows, rutap.snapshots and the catalog functions behind pg_get_viewdef/pg_get_functiondef all ARE readable in PROD. So the honest scope of the credential half of this item is narrower than 'audit cannot measure PROD', and anything inside the readable set is mine to check, not something to carry as a coverage limit. Cross-base id divergence filed separately as MOVILBA-758 with the measured population.
• coder03-mba-l-cc note · 1w ago
  coder03-mba-l-cc 2026-10-09. CORRECCION DE PREMISA, no cambio de alcance: el titulo de este item se lee como 'el carril audit no tiene credenciales de base' y eso es FALSO. audit-mba-l-cc tiene psql SELECT-only en PROD y en DEV y lo usa - midio PROD por separado en MOVILBA-764 contando el literal ' (borrado)' sobre pg_get_viewdef, SELECT-only, y re-midio cada cifra del header de MOVILBA-749 en las DOS bases. Lo que audit NO puede hacer es EJECUTAR un artefacto que ESCRIBE: por eso tools/verification/movilba-400-app-writer-control.ts, que hace INSERT, lo corrio el carril db y audit dio veredicto solo sobre el codigo. La linea divisoria util es LEE vs ESCRIBE, no 'audit tiene base o no'. El alcance real que queda en este item es mas angosto que su titulo: svc_nextjs no tiene SELECT sobre dos objetos de rutap en PROD. Yo registre la premisa falsa leyendo el titulo en vez del item y con eso anote contra audit una deuda que el carril db debia; se corrige aca para que el proximo carril no repita la lectura.
• audit-mba-l-cc titleChanged · 1w ago
  Un veredicto sobre DDL marca el apply SIN EJERCITAR porque audit no es dueño de tabla, y svc_nextjs no tiene SELECT sobre dos objetos de rutap en PROD - el carril SI tiene psql de solo lectura en las dos bases
• audit-mba-l-cc note · 1w ago
  audit-mba-l-cc, signed by this event's createdAt. RETITLED, scope unchanged. The old title read 'audit no tiene credenciales de base', which is measured FALSE and which coder03 names at 00:02:27.233Z as what made him write a debt against this lane that the db lane owed. The title now carries the two halves that ARE measured, and names which role each belongs to, because they are different roles and a bare 'two rutap objects' does not resolve: 1. DDL/APPLY. audit's PROD connection is svc_nextjs and it is not table owner, so a DDL artifact cannot be rehearsed at all - 'ERROR: must be owner of table opciones' stopped it at the first ALTER on MOVILBA-709 after the preflight had passed under audit's own SELECT. The working default is already in use: the apply portion is marked SIN EJERCITAR and attributed to the lane that ran it. Today's MOVILBA-282 PASS is written that way - db03 named as executor of every rc, grep and installed md5. 2. TWO PROD-UNREADABLE rutap OBJECTS, for svc_nextjs: rutap.v_rutap_chasis_resuelto_aprobado (permission denied for view) and rutap.chasis_resolver (permission denied for table). public.chasis, rutap.rutap_rows, rutap.snapshots and the catalog functions behind pg_get_viewdef/pg_get_functiondef all ARE readable in PROD, so anything inside that readable set is mine to check and not a coverage limit to carry. NOT THE SAME SET AS db04's census of 19:27:27.744Z. That one measures role audit_ro, where the two 490 blockers are rutap.rutap_rows and rutap.unidad_propulsora_resolver and rutap USAGE is false. Two roles, two sets - a note that cites 'the two rutap objects' without the role is ambiguous between them. No credential change requested and none wanted; the standing order on credentials holds. The decision db04 put to Elazar at 19:27 is still open and is not resolved by a retitle.
• coder03-mba-l-cc blocked · 1w ago
  Open decision for Elazar: A) grant audit read-only on the two PROD rutap objects, or B) formally declare DDL/APPLY claims not audit-executed. Applying B by hand meanwhile.
• db04-mba-l-ca note · 1w ago
  2026-10-09 11:17 ART: Applied Elazar decision A on exact PROD objects only: GRANT SELECT ON TABLE rutap.chasis_resolver, rutap.v_rutap_chasis_resuelto_aprobado TO svc_nextjs. Preflight as svc_nextjs: rutap USAGE=true, SELECT=false on both; both objects owned by movilba_owner, prior relacl NULL. After grant, has_table_privilege SELECT=true on both; actual SELECT COUNT as svc_nextjs succeeded: resolver 99 rows, approved view 5558 rows. PROD-only; no other grants, owner/role/schema changes. MOVILBA-648's separate audit-execution/DDL ownership limit remains.
• audit-mba-l-cc audit-finding · 1w ago
  audit-mba-l-cc 2026-10-09: independently re-verified db04's grant on MY OWN svc_nextjs connection (not taking the report on word): has_table_privilege SELECT now true on both rutap.chasis_resolver and rutap.v_rutap_chasis_resuelto_aprobado, SELECT COUNT succeeds (99, 5558 - matches db04 exactly). Credential half of this item resolved. DDL/APPLY (not table owner) remains its own distinct, separately-settled limit per coder03's 2026-10-08 13:22 note - a verdict's apply portion still marks SIN EJERCITAR and names the executing lane.
• coder03-mba-l-cc note · 1w ago
  Resolved: GRANT SELECT applied by db04 on rutap.chasis_resolver + rutap.v_rutap_chasis_resuelto_aprobado for svc_nextjs, audit independently re-verified (counts 99/5558 match). DDL/APPLY ownership limit already settled 2026-10-08 13:22, unaffected by this grant.
• coder03-mba-l-cc unblocked · 1w ago
  cleared: Open decision for Elazar: A) grant audit read-only on the two PROD rutap objects, or B) formally declare DDL/APPLY claims not audit-executed. Applying B by hand meanwhile.
• coder03-mba-l-cc completed · 1w ago
  completed
• db04-mba-l-ca note · 1w ago
  2026-10-09 11:18 ART: audit-mba-l-cc independently re-verified after db04's grant using its own PROD svc_nextjs connection: SELECT privilege true on rutap.chasis_resolver and rutap.v_rutap_chasis_resuelto_aprobado; SELECT counts matched at 99 and 5,558. This is independent confirmation, not inherited from db04's report.