Contrato de escritura con id explicito para las tablas de catalogo

Sub-tickets

Activity

• coder03-mba-l-cc created · 2w ago
  parent=#4196
• coder04-mba-l-ca progress · 2w ago
  coder04-mba-l-ca | 2026-09-30 ART. Read-only inventory against shared checkout dev. Runtime insert writers: src/repositories/fabricantes.ts:74, chasis.ts:203, carrocerias.ts:210, opciones.ts:184; API create routes delegate to these repositories. Import writers: tools/import/master-data-populator.js:119 (fabricantes), component-data-populator.js:165 (chasis) and :273 (carrocerias). tools/import/01_add_missing_opciones.sql has three direct opciones INSERTs but is retired/fail-fast. No insert path found for vehiculos_subtipos_transporte in src/tools/api-external; it currently appears read-only. All four live repository inserts omit id and rely on DB defaults. Historical migration INSERTs exist and are not live create paths. No approved cross-base allocator/source found in repo; local nextval/max(id)+1 cannot guarantee identical IDs in separately connected PROD/DEV or serialize writers globally. Asked coder03 for the approved authority/concurrency/replication contract before code changes. No files changed, no DB writes or gates run.
• coder04-mba-l-ca statusChanged · 2w ago
  coder04-mba-l-ca | 2026-09-30 ART. Began source census; live repository inserts omit IDs and no approved shared allocator is documented. Waiting on coder03's allocator/replication decision before implementing.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-09-30 14:15 ART. SELECT-only PROD/DEV sequence census; no nextval called. All five id columns are integer/int4 (range -2147483648..2147483647), defaults nextval, sequence increment 1/cache 1/noncycling, all is_called=true. Table: PROD max(id), sequence last_value, next candidate; DEV max(id), last_value, next candidate. fabricantes: 69,76,77; 61,75,76. chasis: 144,144,145; 146,146,147. carrocerias: 71,80,81; 71,91,92. opciones: 331,332,333; 331,333,334. vehiculos_subtipos_transporte: 18,18,19; 18,18,19. Every PROD sequence currently has MAXVALUE 2147483647; every table has zero IDs >=1000000000 in both bases. Candidate DEV-only band 1000000000..2147483647 is vacant now. Each PROD sequence can be capped at 999999999 (current last values <=332), but no current cap prevents future PROD allocation there; explicit PROD inserts also require a separate check/contract. Reported to MOVILBA-625 owner; no writes.
• coder04-mba-l-ca progress · 2w ago
  coder04-mba-l-ca | 2026-09-30 14:20 ART. Rechecked shared dev checkout and full item spec; no edits made. Live repository creates and both import populators have no incoming IDs (CSV-derived keys only), so all six paths need an ID source. db04's read-only PROD/DEV census confirms int4, no IDs >=1,000,000,000, and PROD nextval candidates 19–333; the proposed DEV-only band 1,000,000,000..2,147,483,647 is vacant, but PROD must be capped below it. Implementing app IDs with a local allocator while canonical source is undecided would violate same-ID replication; making the provider fail closed would disable ordinary create paths. Need the already-pending Elazar decision (PROD allocate-and-copy vs literal repo seed) before a functional explicit-ID provider and importer contract can be completed safely. No tests/gates or DB writes run.
• coder03-mba-l-cc blocked · 2w ago
  Esperando la decision de Elazar sobre el origen del id de catalogo: PROD asigna y DEV copia, o un archivo del repo con ids literales que se importa a las dos bases. Censo hecho y verificado por coder04: 4 repositorios + 2 populadores de import, ninguno manda id; no hay insert de subtipos; el SQL de opciones esta retirado. Banda 1000000000..2147483647 libre en DEV para filas de prueba, con PROD topado por debajo. El proveedor de id no se puede implementar antes de esa decision: un asignador local en cada base rompe la igualdad de ids entre bases, y un placeholder que falla cerrado deja sin funcionar la creacion normal desde la app. Preguntado a Elazar en CLI el 2026-09-30, dos veces.
• coder04-mba-l-ca progress · 2w ago
  coder04-mba-l-ca | 2026-09-30 14:13 ART. db04 reports MOVILBA-620 apply is on hold: the ROLLBACK-tested remap leaves DEV-only fabricante id 33 in the PROD-range low band. No DB change occurred. The remap must be revised and re-rehearsed after this item's explicit-ID source and reserved DEV band are decided; this confirms the allocator decision is blocking both the writer contract and final remap, not just sequence removal.
• coder04-mba-l-ca progress · 2w ago
  coder04-mba-l-ca | 2026-09-30 14:15 ART. db04's SELECT-only census confirms int4 IDs, nextval defaults in both bases, and no IDs >=1,000,000,000 in any of the five tables. Candidate DEV band 1,000,000,000..2,147,483,647 is vacant. PROD sequences are not yet capped (MAXVALUE 2,147,483,647); all could be capped below the band because last values are <=332. Explicit PROD inserts also need a range guard. No sequence advanced or database writes. Source-strategy decision remains pending, so no code change is safe yet.
• coder03-mba-l-cc unblocked · 2w ago
  Elazar decidio el 2026-09-30 (CLI): HIBRIDO. PROD es el unico que asigna un id de catalogo, y la asignacion se escribe en un archivo del repo que DEV importa, asi que el id queda como valor literal, revisable en un diff y replicable sin que nadie lo vuelva a inventar. Las filas de catalogo que los usuarios creen en DEV van a la banda 1000000000..2147483647, con PROD topado por debajo - banda medida libre por coder04 el 2026-09-30.
• coder04-mba-l-ca statusChanged · 2w ago
  coder04-mba-l-ca | 2026-10-02 00:00 ART. Implementing the hybrid contract after Elazar's 2026-10-01 decision: shared DEV-band allocator plus explicit repository IDs and PROD registry export/DEV import. PROD registry SELECT returned 31 fabricantes, 194 opciones, 32 chasis, 17 carrocerias, 14 subtipos. No DB writes or test gates run.
• coder04-mba-l-ca progress · 2w ago
  coder04-mba-l-ca | 2026-10-02 10:12 ART. Correction to the 00:00 placeholder in my preceding status event: current time was 10:12 ART. Implementation is underway under path locks. PROD registry SELECT returned 31 fabricantes, 194 opciones, 32 chasis, 17 carrocerias, 14 subtipos; no DB writes or test gates run.
• coder04-mba-l-ca progress · 2w ago
  coder04-mba-l-ca | 2026-10-02 10:24 ART. Implemented code-side hybrid contract in shared dev checkout: src/lib/catalog-id.ts chooses the table sequence once, checks current_database, explicitly allocates PROD IDs 1..999999999 and DEV IDs 1000000000..2147483647; PostgreSQL nextval is atomic. All four create repositories now include returned id in INSERT values. Both import populators require a matching ID from the PROD registry; no match errors instead of falling back to a DB default. tools/catalog-id-registry.mjs exports a repeatable-read/read-only PROD snapshot and imports into DEV transactionally with explicit IDs, inserts only, preserving and reporting divergent existing DEV rows. Current PROD registry (SHA256 ceb6bb5b83e8ce69ef4b1b59f0e69ab7b8f89fd78dc17674469517e020d6ca61): fabricantes 31, opciones 194, chasis 32, carrocerias 17, subtipos 14. Registry data is checked in at tools/import/catalog-id-registry.json. Retired 01_add_missing_opciones.sql still fails before its legacy INSERTs. Added five allocator range/target tests; did not run tests, lint, or typecheck per workflow. No DB writes. DB sequence caps/DEV high-band restart remain with db04; the app rejects IDs until those sequence settings are applied.
• audit-mba-l-cc audited · 2w ago
  audit pass: src/lib/catalog-id.ts(+test) 4 repos(opciones/carrocerias/chasis/fabricantes) + catalog-id-registry.mjs + both populators + registry.json
  payload

  {"scope":"src/lib/catalog-id.ts(+test) 4 repos(opciones/carrocerias/chasis/fabricantes) + catalog-id-registry.mjs + both populators + registry.json","outcome":"pass","evidence":"test/lint/typecheck green. Registry import ON CONFLICT DO NOTHING + compare never overwrites DEV rows. SHA256 matches claimed snapshot exactly.","reportRef":null}

• audit-mba-l-cc audited · 2w ago
  audit pass: src/lib/catalog-id.ts+test (ran, 5/5 pass); 4 catalog repos create() hunks; importer populators findCatalogId hunks; registry.mjs export/import/validate. typecheck+lint clean.
  payload

  {"scope":"src/lib/catalog-id.ts+test (ran, 5/5 pass); 4 catalog repos create() hunks; importer populators findCatalogId hunks; registry.mjs export/import/validate. typecheck+lint clean.","outcome":"pass","evidence":"allocateCatalogId bands verified disjoint from registry PROD-range reuse; refuses unknown db before query; importer has no sequence fallback on registry miss (known, flagged to coder04/db04, not a defect here).","reportRef":null}

• coder03-mba-l-cc note · 2w ago
  2026-10-02 coder03-mba-l-cc: BROKEN in PROD since patch 140 (found by db04 on MOVILBA-620). src/lib/catalog-id.ts named fabricantes_id_seq/chasis_id_seq/carrocerias_id_seq/opciones_id_seq; to_regclass NULL in both bases, real ones are *_new_id_seq and opciones_new_id_seq1, so every create() of those four catalogs throws. Fix: resolve via pg_get_serial_sequence('public.<table>','id') - verified non-mutating in movilba and movilba_dev it returns the real sequence for all 5 tables. Test now asserts the query shape and the no-owner error, not the constant. Sent to audit.
• audit-mba-l-cc audited · 2w ago
  audit pass: MOVILBA-625 BROKEN-fix: catalog-id.ts+test, sequence now resolved via pg_get_serial_sequence(table,id) instead of hardcoded *_id_seq names. 7/7 tests pass, lint+typecheck clean.
  payload

  {"scope":"MOVILBA-625 BROKEN-fix: catalog-id.ts+test, sequence now resolved via pg_get_serial_sequence(table,id) instead of hardcoded *_id_seq names. 7/7 tests pass, lint+typecheck clean.","outcome":"pass","evidence":"Prior PASS relied on hardcoded names that do not match real sequences (fabricantes_new_id_seq, opciones_new_id_seq1) - genuine bug, now fixed. NULL-owner path throws with table named. No stale CATALOG_ID_SEQUENCES refs (grep clean).","reportRef":null}

• coder04-mba-l-ca progress · 2w ago
  coder04-mba-l-ca | 2026-10-02 11:37 ART. db04's sequence-name finding is superseded by patch 141: current src/lib/catalog-id.ts resolves the owned sequence with pg_get_serial_sequence(table, 'id'), not hard-coded *_id_seq names. Audit PASS is recorded for catalog-id.ts+test, and the fix is in production commit 6441ee86 (main); I verified 62d5da88 and its fix are ancestors of main. No DB state changed by me. db04's independent preflight still says the PROD cap below 1,000,000,000 is owed; registry-miss import policy also remains unresolved per audit.
• coder04-mba-l-ca note · 2w ago
  coder04-mba-l-ca | 2026-10-02 12:26 ART. Correction: supersede my 2026-10-02 11:37 MOVILBA-625 note. MOVILBA-620 db04 apply/verification events record PROD sequence caps and DEV high-band restarts completed; the “cap owed” statement is stale. Registry misses intentionally fail loudly under the chosen workflow, not an unresolved gap. I have no further 625 work; current queue is 268 and 546.
• coder04-mba-l-ca note · 2w ago
  coder04-mba-l-ca | 2026-10-02 12:26 ART. Supersede my 11:37 note: MOVILBA-620 records PROD caps and DEV high-band restarts applied/verified. “Cap owed” is stale. Registry misses fail loudly by design, not an open gap. No further 625 work; my queue is 268 and 546.
• coder04-mba-l-ca note · 2w ago
  coder04-mba-l-ca | 2026-10-02 12:27 ART. Clarification on MOVILBA-625: PROD sequence caps and DEV high-band restart/remap are applied (MOVILBA-620). Registry-miss POLICY is settled: fail import; create new catalog value in PROD, export its literal ID, import into DEV, retry. The end-to-end recovery workflow has not been exercised; this is an operational verification gap, not an unresolved policy.
• coder04-mba-l-ca note · 2w ago
  coder04-mba-l-ca | 2026-10-02 12:27 ART. 625 clarification: MOVILBA-620 records caps/restarts applied. Registry-miss policy is settled: fail import; create value in PROD, export literal ID, import into DEV, retry. That end-to-end recovery is unexercised; it is an operational verification gap, not an unresolved policy.
• coder04-mba-l-ca completed · 1w ago
  Wave-2 closeout: shipped/audited scope is live; remaining checks or separate decision items are tracked outside this item's shipped scope.