Censo estructural completo movilba vs movilba_dev en las dos direcciones, con el lado correcto justificado por migracion para cada diferencia

Sub-tickets — 1/1 done

Activity

• coder03-mba-l-cc created · 3w ago
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24: Started partial census record docs/reference/movilba-585-dev-prod-structural-census.md. Installed v_vehiculos_detalle contract is 60 cols PROD / 55 DEV; db03 independently measured same ~11:3x ART. Five PROD-only outputs recorded (observaciones and four SUBE/OpenPass fields), direction DEV follows PROD per Elazar's 24/09 structure rule. This is only a preliminary single-object entry; full bidirectional census remains incomplete.
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24: Bidirectional installed-catalog check for rutap.rutap_rows.digitos: both DEV (movilba_dev, PG15.17) and PROD (movilba, PG17.6) have nullable text at attnum 58 after col_52; col_39..col_52 remain attnum 44..57 in both. No difference to classify. BWI-373 records audited migration applied PROD first then DEV; detail added to docs/reference/movilba-585-dev-prod-structural-census.md. Data-value/view-dependency parity not tested; full census incomplete.
• audit-mba-l-cc audited · 2w ago
  audit pass: post-hoc, sha f817ed3a/2ab098f7 (no per-lane gating, Elazar order). tools/libro-valores-inventario.py (new, 130 lines) - full read.
  payload

  {"scope":"post-hoc, sha f817ed3a/2ab098f7 (no per-lane gating, Elazar order). tools/libro-valores-inventario.py (new, 130 lines) - full read.","outcome":"pass","evidence":"audit-mba-l-cc 2026-09-28. SELECT-only DB access (public.opciones, rutap.unidad_propulsora_resolver), DSN from os.environ PROD_DATABASE_URL, no literal in file. No writes anywhere in script. docs/reference/movilba-585-dev-prod-structural-census.md and docs/gcaba-gitlab-migracion/README.md grepped for password/token/secret/bearer/api_key/BEGIN - only variable NAMES and a public CUIL/email for the GCABA ticket, no literal credential values. tools/todo-rutap-tracker.py +1 line: one dict entry (cambio-empresa sheet key), trivial. No gate exists or ever will for .py on any ship path (per CLAUDE.md); this is the only review these files get.","reportRef":null}

• coder03-mba-l-cc note · 2w ago
  coder03-mba-l-cc 2026-10-01, fila de censo medida de paso en MOVILBA-453. public.v_vehiculos_export DIVERGE EN CUERPO entre las bases y el lado correcto NO es obvio: PROD 89 lineas, DEV 103. PROD: fecha_alta = COALESCE((select max(h.fecha_alta) from v_vehiculo_historial h where tramite ALTA), vdc.fecha_vigencia_desde); expediente_alta/baja desde vdc; join a v_vehiculos_export_vdc; proyecta las cuatro columnas de validadoras. DEV: fecha_alta = CASE WHEN estado 'Baja%' THEN alta.fecha_alta_cerrada ELSE alta.fecha_alta END; expediente_alta/baja desde periodo_veh; sin join a vdc; sin columnas de validadoras. Medido contra v_vehiculos_hist_ultimo: fecha_baja, expediente_alta y expediente_baja dan 0 diferencias contra el periodo vigente en LAS DOS bases, asi que esas tres columnas convergen en semantica aunque el cuerpo difiera. La que no converge es fecha_alta: 1595 de 2419 filas en PROD y 1778 de 2453 en DEV difieren de la fecha_alta del periodo vigente, con DOS formulas distintas, y las dos son defendibles -el alta ORIGINAL del vehiculo contra el alta del periodo vigente-, asi que esto es una DECISION de Elazar y no una convergencia que se pueda resolver eligiendo un lado. Las cuatro columnas de validadoras en PROD se quedan como estan: el ocultamiento es por codigo y sin DDL. SIN EJERCITAR: no corri el diff columna por columna del resto de la proyeccion, solo fecha_alta, fecha_baja y los dos expedientes.
• coder03-mba-l-cc note · 2w ago
  coder03-mba-l-cc 2026-10-01, dato que fortalece el item: la divergencia de v_vehiculos_export es DERIVA POSTERIOR a una migracion que instalo cuerpos identicos, no una diferencia que nunca se unifico. docs/migrations/README.md, entrada del 2026-09-17, dice literalmente de 2026-09-17-movilba-445-vehiculos-export-reconstruccion-DEV.sql y ...-PROD.sql: APLICADOS los dos, y 'los dos archivos instalan el MISMO cuerpo SELECT, byte a byte', reconstruidos desde el ledger docs/reference/v-vehiculos-export-definicion-correcta.md y no desde el cuerpo instalado de ninguna base, porque ninguna de las dos era correcta. Medido hoy: PROD 89 lineas, DEV 103. O sea que entre el 2026-09-17 y hoy una de las dos bases -por lo menos- recibio un cambio que la otra no, despues de haber quedado iguales a proposito. Eso cambia la pregunta del censo: no es 'que lado tiene razon' sino 'que se aplico a una sola base y cuando', y la respuesta esta en el ledger, que es el arbitro escrito y vive en el repo, no en ninguna de las dos bases. Para el censo: el ledger es el lado correcto por construccion para esta vista, y cualquier cuerpo que no coincida con el es el que hay que explicar, en la base que sea. Las cuatro columnas de validadoras que proyecta PROD y DEV no son aparte: el ocultamiento es por codigo y sin DDL, asi que no justifican una diferencia de cuerpo. SIN EJERCITAR: no diffee ninguno de los dos cuerpos instalados contra el ledger, que es justo el paso que nombra al culpable.
• coder03-mba-l-cc assigned · 1w ago
  db03-mba-l-cc / db
• db03-mba-l-cc progress · 1w ago
  db03-mba-l-cc 2026-10-05: full bidirectional structural census written to docs/reference/movilba-585-dev-prod-structural-census.md (relations+columns+CHECK+sequences measured live both bases, functions/triggers/constraints/indexes folded in from MOVILBA-647). Sent to audit for PASS.
• audit-mba-l-cc audited · 1w ago
  audit pass: read docs/reference/movilba-585-dev-prod-structural-census.md in full, structural review, no DB exec
  payload

  {"scope":"read docs/reference/movilba-585-dev-prod-structural-census.md in full, structural review, no DB exec","outcome":"pass","evidence":"every diff names correct side or UNRESOLVED w/ citation (503,660,472); coverage statement at end names unmeasured (grants/ACLs/extensions/roles/data values/export-body ledger diff)","reportRef":null}

• db03-mba-l-cc completed · 1w ago
  Audit PASS 2026-10-05. Full bidirectional structural census complete: docs/reference/movilba-585-dev-prod-structural-census.md.
• db04-mba-l-ca progress · 1w ago
  2026-10-05 db04 post-MOVILBA-442 view-only structural census, both directions: public.v_vehiculos_export pg_get_viewdef(...,true) md5 PROD=DEV=9c20c599da3ec42bac8226b90c99bfed; ordered column name+type md5 PROD=DEV=ee90e71d75b335d6796190d03abd0a19; count 46 columns in both. PROD owner movilba_owner and original svc_nextjs/audit_ro relacl preserved; DEV owner movilba_user and NULL relacl preserved (expected owner asymmetry under 497). PROD output 2419/2419 unique vehicles; DEV 2457/2457. These are exact equality checks in both directions for this VIEW only, not a complete 585 database-structure census. Applied PROD then DEV under MOVILBA-442 audit PASS.
• db04-mba-l-ca note · 1w ago
  MOVILBA-750 resolution: DEV-only agents schema is an explicit parity exception (2026-08-24 DEV lookup migration, preserved 2026-09-18 DEV migration, PM decision 2026-10-08). Updated docs/reference/movilba-585-dev-prod-structural-census.md paragraph (SHA256 64d89ab7); do not re-raise either agents view as pending PROD DDL.
• db04-mba-l-ca note · 1w ago
  CORRECTION to prior MOVILBA-750 note: only agents.v_vehiculo_lookup is the cited DEV-only exception. Separate invariant diagnostic view is UNRESOLVED removal candidate MOVILBA-757, not covered by the Aug24 lookup migration. Revised docs/reference/movilba-585-dev-prod-structural-census.md SHA256 90caa1f7, supersedes 64d89ab7; no DDL.
• db04-mba-l-ca note · 1w ago
  2026-10-08 audit read-only ACL addendum, NOT a new DDL directive: DEV has 104 views owned by movilba_user and relacl NULL on 92; PROD views are owned by movilba_owner/postgres and 95/104 have explicit ACL. This makes the already-shipped MOVILBA-123 grant-preservation check asymmetric: it compares coalesce(relacl, ~NULL~) before/after and warns on NULL, so on DEV 11/12 of its touched views compared NULL to NULL and the check could not discriminate grant loss there; on PROD the explicit ACLs made it a real control. Source: audit-mba-l-cc DM 2026-10-08 20:41 ART. Do not read structural parity or a DEV green from this grant check alone.
• audit-mba-l-cc audit-finding · 1w ago
  # MOVILBA-585 — view ownership and grants are a DEV/PROD structural divergence, and one shipped control is inert on the DEV side Filed by audit-mba-l-cc, 2026-10-08, found while classifying the regenerated mirror for MOVILBA-764. SELECT-only in both bases, no DDL. ## The measurement base connected as owner relacl NOT NULL relacl NULL total views PROD svc_nextjs movilba_owner 62 9 71 PROD svc_nextjs postgres 33 0 33 DEV movilba_user movilba_user 12 92 104 Query: `pg_class` joined to `pg_namespace`, `relkind='v'`, `nspname in ('public','rutap')`, grouped by `pg_get_userbyid(relowner)` and `relacl IS NOT NULL`. Both bases hold **104 views** (89 `public` + 15 `rutap`), so the totals are comparable row for row. PROD: two owners, and **95 of 104 views carry an explicit ACL**. DEV: one owner, and only **12 of 104** do. DEV works anyway because the application role *is* the owner, so the default privileges suffice. That is consistent with the PROD-side design recorded for `movilba_owner`, and it is **not a defect report against either base** - DEV is reachable and PROD is granted. It is a structural difference in `relowner` and `relacl`, which is 585's subject, and it is not visible in `drizzle/schema.ts` because the mirror carries neither. ## Why it is not just a footnote: a shipped control cannot fail on the DEV side `docs/migrations/2026-10-08-movilba-123-sufijo-borrado-vistas-PROD-Y-DEV.sql` is explicit that the grant risk is why it uses `CREATE OR REPLACE` and no `DROP VIEW` (`:78-82`), and it measures rather than assumes (`:114`, "coder03 pidio que esto se mida, no se asuma"). Its control: - `:116` snapshots `relacl::text` for the 12 target views into `mb123_acl_antes`. - `:127-128` raises if the census is not 12 rows. **It is 12 in both bases**, so this passes. - `:130-131` raises a **`WARNING`**, not an exception, when any snapshotted `relacl` is NULL. - `:731-735` compares before to after as `coalesce(c.relacl::text,'~NULL~') <> coalesce(a.acl,'~NULL~')`. In DEV, 11 of those 12 views have `relacl` NULL (`v_personas_completas` is the one exception), so the final comparison evaluated `'~NULL~' <> '~NULL~'` for 11 of 12 and **could not have failed there**. The `WARNING` is the only thing that fired, and a warning does not stop a transaction. So control E - "relacl identico en las 12 vistas" (`:737`) - is a **real control in PROD and a green line in DEV**. It is not wrong and nothing it protects was damaged: PROD's 95 ACLs are intact, measured above, and `CREATE OR REPLACE` cannot drop a grant anyway. The point is narrower and worth recording: on the DEV leg this check reported success without the condition it tests being present. ## What this does and does not claim - It does **not** say any grant was lost. Measured: PROD's views still carry their ACLs. - It does **not** reopen MOVILBA-123. That migration is applied and verdicted, used the safe path, and its PROD leg exercised the control for real. - It does **not** propose DDL. Whether DEV should mirror PROD's `movilba_owner` + explicit grants, or whether owner-is-app-role is the intended DEV shape, is a decision, not a defect, and it belongs to 585 with MOVILBA-497's ownership design. - It **does** say the DEV/PROD census for 585 must include `relowner` and `relacl`, because a census keyed on names, columns and bodies reports these 104 views as matching while they differ here. ## NOT EXERCISED - No DDL, no `GRANT`, no `REVOKE`, nothing applied. Every statement was a catalog `SELECT`. - I did not test whether any specific role can actually read any specific view; I read `relacl` and `relowner`, not an effective-privilege probe. `has_table_privilege` per role per view is the measurement that would close that, and I did not run it. - Tables, sequences, functions and schema-level privileges are unmeasured - views only. - The 9 PROD views with NULL `relacl` are not identified here by name; only counted.
• db04-mba-l-ca note · 1w ago
  2026-10-08 owner-exception addendum for prospective MOVILBA-59 manifest relation, SELECT-only. PROD has role movilba_owner (NOLOGIN), no movilba_user; all 25 rutap table/view-like relations owned by movilba_owner. DEV has role movilba_user (LOGIN), no movilba_owner; all 27 rutap table/view-like relations owned by movilba_user. Equal owner names for the new rutap.import_run_manifests table are impossible without role DDL, which belongs to MOVILBA-497. PM decision at 21:59 ART: create table as each base's LOCAL rutap.snapshots owner, document as the existing environment-specific owner exception rather than blocking MOVILBA-59 on 497. This adds one expected name-level owner difference but matches the local rutap ownership invariant in each base. No role or schema write; migration not applied. Fold into docs/reference/movilba-585-dev-prod-structural-census.md when shared checkout lock permits.
• db04-mba-l-ca note · 1w ago
  2026-10-08 docs/reference/movilba-585-dev-prod-structural-census.md now carries the PM-approved prospective MOVILBA-59 local-owner exception, SHA256 a76501087bcc4686a90ecce17bc0e617aeb8e3921e3aa37255d9cfc9e5bd3d30. Added 20 lines after MOVILBA-773 section. It states measured roles/counts (PROD movilba_owner owns 25 rutap relations, DEV movilba_user owns 27, opposite role absent), PROD svc_nextjs lacks rutap CREATE, and proposed manifest table follows each base's rutap.snapshots owner. It explicitly says table NOT INSTALLED and not in current census counts; role-name convergence belongs to 497, remeasure after apply. Docs-only, no DDL. Shared checkout edit after PARK DONE; pending audit/ship, do not read it as already committed.
• db04-mba-l-ca note · 1w ago
  2026-10-08 23:07 ART MOVILBA-59 post-apply owner/ACL exception, measured after both COMMITs: rutap.import_run_manifests is present with 0 rows in both bases; owner PROD movilba_owner, DEV movilba_user, exactly the local owner of rutap.snapshots in each. PROD relacl {movilba_owner=arwdDxtm/movilba_owner}; DEV relacl {movilba_user=arwdDxt/movilba_user}; PUBLIC SELECT false on both. svc_nextjs SELECT/INSERT false in PROD. These owner role names are disjoint by environment, with no cross-base role to SET; matching names would require separate role DDL under MOVILBA-497. This is the explicitly approved environment-local owner exception for 59, NOT unmeasured drift or authorization for ALTER OWNER/GRANT. The current docs/reference/movilba-585-dev-prod-structural-census.md prospective addendum still says 'not yet installed' and needs a separately reviewed post-apply correction; no repo edit while coder04 holds checkout lock.
• db04-mba-l-ca note · 1w ago
  Post-apply correction to the MOVILBA-59 owner addendum is in current tree at docs/reference/movilba-585-dev-prod-structural-census.md SHA256 49fbb907507a3a3c03c3902c23b45c2fca9e89bbfb2953fec8584633f50eb5a7, replacing the prospective 'not yet installed' wording with direct post-apply PROD/DEV state; pending audit. The original relation/owner census denominators remain the historical counts and future censuses must include the manifest relation.
• db04-mba-l-ca note · 1w ago
  2026-10-08 23:25 ART: audit PASS on updated installed-state MOVILBA-59 addendum, docs/reference/movilba-585-dev-prod-structural-census.md SHA256 49fbb907507a3a3c03c3902c23b45c2fca9e89bbfb2953fec8584633f50eb5a7. Gates exact before/after; independent count confirms original 25 PROD / 27 DEV relation denominators were pre-manifest, and new table owner/ACL are now recorded as installed state. Owner asymmetry remains the existing MOVILBA-497 issue/exception.