Un periodo vigente de origen app, sin snapshot y con columnas del libro en NULL, tapa el valor que el libro si trae

Sub-tickets

Activity

• wi-cli-venus created · 5w ago
• wi-cli-venus verified · 4w ago
  Application writer fix for preserving imported chassis manufacturer in new app periods deployed to DEV v5.5.144. Guarded repair for the two existing affected periods awaits operation-specific GO under MOVILBA-399 / EQ 114.
• coder03-mba-l-cc assigned · 2w ago
  db03-mba-l-cc
• coder03-mba-l-cc assigned · 2w ago
  db04-mba-l-ca
• coder03-mba-l-cc assigned · 1w ago
  db03-mba-l-cc / db
• db03-mba-l-cc note · 1w ago
  db03 2026-10-08: re-measured fresh in both bases, not against the 09-08 snapshot numbers. SCOPING a live code defect this ticket's own history did not catch - leaving open, no write. AA033TK AND THE ORIGINAL "19 FILAS" IN PROD: RESOLVED, BUT NOT BY A FIX - BY REPROJECTION. rutap.v_vehiculo_historial_actual for AA033TK now ranks a book row (rutap_snapshot_id=11, chasis_marca MERCEDES BENZ, chasis_id 131) as current_rank=1, not the app-origin NULL period. Same mechanism as MOVILBA-719 closed this session: the latest book reload (current snapshot 11) re-derived current_rank across every open period, including app ones, and a fresh book row with real data outranked the old blank app period under the view's own tie-break. PROD today: 0 rows with origen='app' AND chasis_marca IS NULL (measured count, not sampled). The 19-row population this ticket measured in DEV on 09-08 is not reproduced in PROD today. THE REAL, STILL-LIVE DEFECT (not what 399/400's history chased): MOVILBA-338 (commit 38ccdf57, 2026-09-07, PREDATES this ticket's own creation on 2026-09-08) was supposed to make every app-opened period carry chasis_marca resolved from the ficha, same as import. It does NOT. `columnasDesdeFicha()`'s type (src/repositories/vehiculos.ts:195) declares `chasisMarca` as one of the fields it returns, but the SQL SELECT inside the function (lines ~206-250) never projects a `chasisMarca` column - no `AS "chasisMarca"` anywhere in that query, confirmed by grep across the whole file. `fila.chasisMarca` is `undefined` on every call, so every INSERT built from `columnasDesdeFicha()`'s result writes chasis_marca = NULL regardless of whether chasis_id resolved. chasisModelo (:663, :869, :1277) IS wired elsewhere as a direct form-field passthrough, unrelated to this ficha-read function, so it is not affected the same way. MEASURED IMPACT: DEV, today (2026-10-08), 162 origen='app' rows with chasis_marca NULL, creado_en ranging 2026-09-21 to 2026-10-08 11:46 (i.e. STILL being produced right now, post-338, not legacy). Of those, 133 have chasis_id SET (i.e. the chasis DID resolve - only the label is missing) and 29 have chasis_id also NULL (genuinely no chasis assigned, not this bug). PROD not separately re-measured for ongoing production of this defect since PROD's periods converged to 0 via the unrelated reprojection event above - the code defect is in the SAME shared repository file and would reproduce in PROD on the next app-opened period over a vehicle whose current rank does not get rescued by a future book reload. NOT MOVILBA-399: 399 was about a visible-surface text fallback and was explicitly derogated by Elazar's 2026-09-24 ruling 2 (project CLAUDE.md, "Retires MOVILBA-399" / commit d45cd52e) - a display-layer decision. This is a different layer: the historial row's own resolved chasis_marca column never gets written at all, independent of what any UI falls back to display. The 09-13 progress note's "guarded repair for the two existing affected periods awaits GO under MOVILBA-399/EQ-114" is now moot both ways - 399 itself is retired, and the two originally-named periods are not even affected any more (resolved by reprojection). FIX NEEDED (not applied, no GO yet): add the missing SELECT expression to `columnasDesdeFicha()` - `fab_chasis.fabricante AS "chasisMarca"` (or equivalent, joined off `v.chasis_id` to a chasis manufacturer table/catalog) mirroring how `motorFabricante`/`carroceriaFabricante` already resolve via their own `fabricantes` joins (:228-229, :234). Small, scoped change to one function; not applying without GO since it changes a shared writer used by 4 call sites (:937, :1134, :1454, :1553). NOT RE-EXERCISED: whether any OTHER column besides chasisMarca is declared in ColumnasDesdeFicha's type but similarly missing from the SELECT (not diffed field-by-field this pass - the type has ~35 fields, only chasisMarca was checked because it's this ticket's named symptom); no UI screen opened; no period actually written to observe the NULL live.
• coder03-mba-l-cc assigned · 1w ago
  coder04-mba-l-ca / coder
• coder04-mba-l-ca progress · 1w ago
  Read-only census of columnasDesdeFicha found two declared fields absent from its SQL projection: chasisMarca and chasisModelo. chasisMarca should resolve through vehiculos.chasis_id -> chasis.fabricante_id -> fabricantes.fabricante; chasisModelo already persists on vehiculos.chasis_modelo and should project with it. Both otherwise become undefined in all four app-period writers. I will add both in the one-function fix after MOVILBA-713 handoff.
• coder04-mba-l-ca note · 1w ago
  Further source check: Alta form exposes required chasisId dropdown but no chasisModeloVehiculo input, so the base vehiculos.chasis_modelo passthrough is not a reliable substitute. The history writer should project both canonical labels from the selected chasis row: fabricantes.fabricante for chasisMarca and chasis.chasis_modelo for chasisModelo. This follows the catalog-only visible-field rule and the declared ColumnasDesdeFicha contract.
• coder04-mba-l-ca note · 1w ago
  Coder03 decision 2026-10-08 12:06 ART: fix chasisMarca only through chasis.fabricante_id -> fabricantes.fabricante. Do not add chasisModelo: raw/base chasis_modelo is MOVILBA-395, parked on Elazar, and catalog ruling 2 forbids raw text where chasis_id resolves model. Remove chasisModelo from ColumnasDesdeFicha declared return type because its SELECT does not project it.
• coder04-mba-l-ca progress · 1w ago
  Scoped one-function diff ready: columnasDesdeFicha now SELECTs btrim(fab_chasis.fabricante) AS chasisMarca through v.chasis_id -> chasis.fabricante_id, preserving the same catalog-resolution pattern as carroceria/motor. Removed dead chasisModelo from declared Pick; no model value written or changed (MOVILBA-395 decision remains separate). git diff --check clean. Sent to audit for test:tools/typecheck.
• audit-mba-l-cc audited · 1w ago
  audit pass: typecheck clean; test:tools 113/113; lint(1 file) clean; PROD spot-check of new chasis->fabricantes join
  payload

  {"scope":"typecheck clean; test:tools 113/113; lint(1 file) clean; PROD spot-check of new chasis->fabricantes join","outcome":"pass","evidence":"vehiculos.ts: columnasDesdeFicha adds btrim(fab_chasis.fabricante) AS chasisMarca via new LEFT JOIN chasis ch ON ch.id=v.chasis_id, LEFT JOIN fabricantes fab_chasis ON fab_chasis.id=ch.fabricante_id - mirrors existing carroceria/motor manufacturer-resolution pattern exactly. chasisModelo dropped from declared Pick only (SELECT never projected it - dead field, matches coder03's 2026-10-08 scope decision citing MOVILBA-395 parked/catalog ruling 2). PROD spot-check (OWG349/AG451NP/AG449JS) confirms the join resolves real manufacturer names, not NULL.","reportRef":null}

• coder03-mba-l-cc note · 1w ago
  coder03 12:15 ART: deployed PROD+DEV v5.6.189; pod leg requested.
• coder04-mba-l-ca statusChanged · 1w ago
  Fresh PROD/DEV census requested; tracing all published resolvers before proposing a change. Earlier chasisMarca writer fix shipped in patch 189, but pre-existing app periods and read paths still need current measurement.
• coder04-mba-l-ca progress · 1w ago
  Read-path census, code only, pending fresh DB counts: ficha and edit share GET /api/vehiculos/[id] -> v_vehiculos_detalle and chasis/fabricantes by vehiculos.chasis_id; current CSV/XLSX and /api/v1/exports/vehiculos share v_vehiculos_export and its chasis/fabricantes join; historical report /api/reportes/vehiculos-historico joins each period h.chasis_id to chasis/fabricantes; RUTAP book export reads v_export_libro, which resolves import history chasis_id through catalog. Public /api/v1/parque vehicle payload does not publish chassis make/model. The earlier writer fix populates chasisMarca for new app periods, but does not repair existing rows. No read-path edit proposed until PROD/DEV current-rank census distinguishes affected history rows from visible catalog-backed values.
• db04-mba-l-ca progress · 1w ago
  Fresh SELECT-only PROD→DEV census at 2026-10-08 19:11 ART, SQL /data-lezama/movilba/evidencia/MOVILBA-400/2026-10-08-current-app-book-null-census.sql sha256 58b49d06; report sibling .md. Current_rank=1 app/snapshot-NULL: PROD 0 rows/vehicles/domains (snapshot 11); DEV 69/69/69 (snapshot 21), 24 unique-open-book-domain matches, 45 unmatched, 24/24 matched have NULL vs nonblank. DEV field counts: tramite 24, carroceria_categoria 22, chasis_marca 20, chasis_modelo 20, id_adas/ip_canbus 2 each, twelve other fields 1 each. Field counts overlap. No writes/import; patch189 omission not inferred from stored residual.
• coder04-mba-l-ca progress · 1w ago
  Fresh DB04 SELECT-only census: PROD snapshot 11 has 0 current app/snapshot-NULL periods; DEV snapshot 21 has 69 current app rows/domains, 24 with one matching open book row and 45 absent from book. All 24 matched have some NULL/book-nonblank field; overlapping counts include tramite 24, carroceria_categoria 22, chasis_marca 20, chasis_modelo 20. These are stored DEV residuals, not evidence the shipped patch-189 writer is still failing. Source trace: all four app-history INSERT paths in src/repositories/vehiculos.ts (create, assignment, transfer close, edit) use columnasDesdeFicha; the helper now projects chasisMarca from vehiculos.chasis_id -> chasis.fabricante_id -> fabricantes. Requested the 20 rows creation timestamps, normalizado_por/write origin, and history versus ficha chasis IDs before changing code or data. Evidence file: /data-lezama/movilba/evidencia/MOVILBA-400/2026-10-08-current-app-book-null-census.md.
• coder04-mba-l-ca note · 1w ago
  Interpretation guard on the 24 DEV matched rows: counts are NULL-text-versus-nonblank-book, not 24 proven visible defects. Current writer intentionally leaves tramite text NULL while tramite_id carries catalog value; chasis_modelo is excluded from ColumnasDesdeFicha under MOVILBA-395; carroceria_categoria has an explicit catalog ID on current edit paths. Catalog-backed visible chassis make/model reads use chasis_id, not raw period text (MOVILBA-574). Need per-row history/ficha IDs, creation time and per-surface output before choosing a fix. Patch-400 SELECT addition entered git at e56dfd22 2026-10-08 12:01 ART; production patch189 reported live about 12:15 ART.
• db04-mba-l-ca progress · 1w ago
  Follow-up SELECT-only DEV snapshot 21, 2026-10-08 19:13 ART: 20 current app periods with chasis_marca NULL vs nonblank unique open book row = 20 vehicles/domains. Created 2026-09-23 14:21:59 through 2026-10-08 11:46:50 ART; 20 before approximate patch189 cutoff 12:15 ART, 0 at/after. History chasis_id set 20/20, public.vehiculos.chasis_id set 20/20, equal 20/20. Examples h.id 286447 (AI563JO, book fila 5537, id123), 320005 (AI578CF, fila5556, id123), 364502 (AG202SZ, fila4005, id130). SQL /data-lezama/movilba/evidencia/MOVILBA-400/2026-10-08-chasis-marca-null-20-timing.sql SHA c909193b; report sibling census .md. Creation time does not exclude later edits; no DB writes.
• db04-mba-l-ca progress · 1w ago
  PM ruling 2026-10-08 19:13 ART supersedes any implied row repair from this census: PROD qualifying app/snapshot-NULL population is 0; all 69 are DEV app-created data protected by Elazar 2026-09-24 ruling 1, so no data fix/replay in either base. The 20-row creation-time follow-up completed SELECT-only before cancellation: 20/20 predate approximate patch189 cutoff, 0 after, and all 20 carry matching history/vehicle chasis_id. This is historical context only, not a code verdict. Surviving 400 scope is coder04’s four-path post-patch write control, failing against pre-patch189 body first; no additional DB census or row writes owed from db04.
• coder04-mba-l-ca proposal · 1w ago
  Code control design under checkout lock: a DEV-only, explicit verification instrument should use one pg client transaction and ROLLBACK, route repository db.transaction callbacks through that client, disable app_logs writes, create a synthetic vehicle with an existing catalog chasis FK and nonblank book-equivalent fields, then drive createColectivo, createHistorialRecord, transfer close, and edit successor. Query each inserted history row within the transaction for chasis_marca/chasis_id and require the catalog manufacturer; restore the db.transaction seam and ROLLBACK in finally. Run a pre-patch189 query-body mutant (omit chasisMarca projection) to see all four assertions fail, then current body pass. No test runs on the deploy path or PROD. Existing source tests are static and do not provide this control. Pending lock and feasibility review before implementation.
• coder04-mba-l-ca verified · 1w ago
  DB04 SELECT-only DEV timing follow-up, 2026-10-08 19:13 ART, snapshot 21: all 20 current app periods with chasis_marca NULL and nonblank unique open book row were created before patch189 (~12:15 ART); 0 at/after. Creation range 2026-09-23 14:21:59 to 2026-10-08 11:46:50 ART. All 20 history chasis_id are non-NULL, all 20 matching public.vehiculos.chasis_id are non-NULL, and 20/20 IDs equal. This supports a legacy stored-text gap and catalog-backed current reads; creation time alone cannot exclude later edits or prove the current writer. No DEV data repair by Elazar rule. Evidence /data-lezama/movilba/evidencia/MOVILBA-400/2026-10-08-chasis-marca-null-20-timing.sql, SHA c909193b. Current four-writer control still owed.
• coder04-mba-l-ca progress · 1w ago
  Verifier candidate ready at tools/verification/movilba-400-app-writer-control.ts, SHA256 eef270bea9a2a702138f3e17ea9b217ffc5ff8c6883f4fe8696e63358fb6a783 (234 lines). Explicit hand-run MEASUREMENT, not a deploy/regression gate: tools/tests glob cannot reach it. Uses .env.local DEV_DATABASE_URL; checks current_database=movilba_dev and current_user=movilba_user before any insert. One outer transaction must ROLLBACK; routes four repository writers through its db.transaction seam and suppresses fire-and-forget app_logs only in the verifier process via db.insert injection, no production switch. Pre-patch189 mutant removes the field that old columnasDesdeFicha omitted; all four history-label assertions must fail on NULL, then pass on current bytes. No coder gate or DEV execution run yet; audit owns verification and verdict. Synthetic rollback only, no PROD or SUPERUSER URL.
• coder04-mba-l-ca progress · 1w ago
  Superseded unexecuted verifier eef270be with bcd35f2d7b80a06588effbf9152a338208c5650f1b6a9c51da215b12eb9ebb87. Static schema review caught seed query h.origen against v_vehiculo_historial_actual, which omits origen; new bytes join rutap.vehiculo_historial_normalizado on h.id and filter stored.origen='import'. No DEV run or audit verdict on either SHA yet. Explicit hand-run measurement, not a deploy gate; all mutation remains DEV-only in one mandatory ROLLBACK.
• coder04-mba-l-ca verified · 1w ago
  Correction classification and assertion-source audit, 2026-10-08: eef270be's h.origen against v_vehiculo_historial_actual would raise undefined_column before any fixture write: LOUD non-executable verifier, not a false-green near miss. bcd35f2d joins the base row to read stored.origen. The silent-risk check is direct-object identity: createColectivo, createHistorialRecord, transfer closure and edit successor each call atx.insert(vehiculoHistorialNormalizadoInRutap).values({...desdeFicha,...}) at repositories/vehiculos.ts:972,1227,1600,1632; Drizzle schema maps that table to rutap.vehiculo_historial_normalizado and chasisMarca to chasis_marca at drizzle/schema.ts:1675,1707. The verifier asserts SELECT chasis_marca FROM rutap.vehiculo_historial_normalizado WHERE vehiculo_id=<synthetic id> AND normalizado_por=<one exact per-writer label>, requiring exactly one row for each. Thus all four assertions read the SAME base relation and column each writer inserts, not a derived view or unrelated catalog row. DEV execution/mutant still owed to audit.
• db04-mba-l-ca progress · 1w ago
  DEV execution attempt of verifier SHA bcd35f2d (tools/verification/movilba-400-app-writer-control.ts), `timeout 120s pnpm exec tsx ...`, exited 1 BEFORE module evaluation/database connection: esbuild TransformError, top-level await unsupported with cjs output at lines 27 and 235. No transaction, INSERT, mutant assertion, or current-writer assertion ran. 0/4 mutant and 0/4 current are UNEXERCISED, not failed or passed. Return to coder04 for executable module format/new SHA; db04 will rerun corrected bytes DEV-only under mandatory rollback.
• coder04-mba-l-ca progress · 1w ago
  Execution ownership correction: audit-mba-l-cc has no database credentials (MOVILBA-648) and reviews bcd35f2d CODE only. db04-mba-l-ca owns the authorized DEV run with .env.local DEV_DATABASE_URL: four mutant NULL assertion failures, four current passes, zero synthetic rows after mandatory ROLLBACK. The verifier's own execution is a measurement, not a ship-path gate. No DEV run has been reported yet. Earlier note assigning execution to audit is superseded by this event; audit --scope should name db04 as executor and not imply audit ran it.
• coder04-mba-l-ca progress · 1w ago
  db04 attempted exact bcd35f2d with repo pnpm exec tsx under timeout 120s: transform exited 1 because top-level await is unsupported with CJS output (lines 27,235). Module never evaluated; no DB connection, transaction, or INSERT. Mutant 0/4 and current 0/4 UNEXERCISED. This is a LOUD runner defect in the verification instrument, not a writer-path result. Candidate superseded pending async-main correction/new SHA; db04 reruns after re-pin. Audit instructed not to verdict bcd35f2d.
• coder04-mba-l-ca verified · 1w ago
  Runnable verifier replacement SHA256 764fe0f33cf0b8e6991a5f81b5c76bf567508dd357ec8f5aa0583b4e9e1e71fe at tools/verification/movilba-400-app-writer-control.ts supersedes unexecuted bcd35f2d. Async main removes CommonJS top-level await. Preflight positive control RUN by coder04 from repo root: timeout 120s pnpm exec tsx tools/verification/movilba-400-app-writer-control.ts --guard-probe; exit 1 at file line 58, AssertionError 'no write outside DEV', actual current_database=movilba_dev vs inverted expected __movilba400_guard_probe_must_fail__. Module evaluated, connected and reached identity assertion. Probe only inverts expected DB name; an unconditional throw immediately after makes it structurally unable to reach an INSERT even if expectation somehow matches. No synthetic writer phase ran in probe. db04 owns four mutant/four current DEV ROLLBACK run; audit reviews bytes only.
• db04-mba-l-ca progress · 1w ago
  DEV run of exact verifier SHA 764fe0f3 (tsx, external 120s bound) connected and passed movilba_dev/movilba_user identity guard, then aborted BEFORE any INSERT at line 87: `regulatory category: exactly one row required`, 0 != 1. Its fixture queries public.v_opciones for vehiculo/categoria_regulatoria; SELECT-only census in DEV shows public.opciones has 10 rows but 0 live, so v_opciones returns 0. Installed categoriaCarroceriaIdParaPeriodo reads public.opciones without borrado_en filter. No synthetic vehicle or history write occurred; mutant 0/4 and current 0/4 remain UNEXERCISED. Return to coder04 for fixture correction/new SHA, then rerun exact bytes. No DB mutation persisted.
• coder04-mba-l-ca progress · 1w ago
  Correction to my earlier execution handoff: audit has SELECT-only access to PROD and DEV. MOVILBA-648 concerns svc_nextjs SELECT on two RUTAP objects, not all database credentials. Audit cannot execute this verifier because it INSERTs; db04 owns the authorized DEV-only ROLLBACK run. Latest verifier SHA256 764fe0f33cf0b8e6991a5f81b5c76bf567508dd357ec8f5aa0583b4e9e1e71fe passed my --guard-probe at line 58 before any INSERT. The four mutant failures and four current passes remain UNEXERCISED pending db04.
• coder04-mba-l-ca verified · 1w ago
  Fixture correction at tools/verification/movilba-400-app-writer-control.ts SHA256 9dc12914a93168d43b8000792ab06de956dde45dc181b758b243ed7a550ceb49: regulatory category seed now reads public.opciones, exactly as installed categoriaCarroceriaIdParaPeriodo does, including DEV soft-deleted rows. Supersedes 764fe0f3; that run passed identity then aborted before INSERT (mutant/current 0/4). I reran --guard-probe on the new bytes from repo root: exit 1 at line 58, actual movilba_dev versus inverted expected __movilba400_guard_probe_must_fail__, before any INSERT. Probe cannot bypass guard. db04's DEV-only ROLLBACK run of four mutant failures and four current passes remains owed; audit reviews bytes only.
• db04-mba-l-ca progress · 1w ago
  SHA 9dc12914 fixture lookup now matches installed public.opciones resolver, guard-probe reported by coder04. DB lane did not execute writer phase: the previously observed tree-wide TS2698 spread site remains unchanged at shifted line 234 (`{ ...summary, rolledBack: true }`), so coder03’s instruction to pin a typechecking artifact is not met by this SHA. No new typecheck gate run by db04 (audit/code lane scope), no synthetic writes on this candidate. Await new executable/typechecking SHA before DEV rollback measurement.
• coder04-mba-l-ca progress · 1w ago
  Verifier repin SHA256 ddecf55e0778cf23ac48900cff577df35b72261fb9662089a11cafe944e4968a at tools/verification/movilba-400-app-writer-control.ts. Replaces 9dc12914: completion summary now lives in an object holder and is narrowed locally before spread, addressing tree-wide TS2698 on the prior candidate. Fixture still reads public.opciones matching installed resolver. --guard-probe run on these bytes reaches identity guard line 58 and exits 1 before INSERT, actual movilba_dev versus deliberately inverted expected name. Four mutant/current writer paths still UNEXERCISED; audit must typecheck these bytes before db04's next DEV rollback run.
• coder04-mba-l-ca note · 1w ago
  Separate catalog writer defect filed as MOVILBA-767. The MOVILBA-400 verifier intentionally reads public.opciones because that is what installed categoriaCarroceriaIdParaPeriodo does; this measures the existing four writer paths and does not endorse selecting a soft-deleted ID. Fixing 767 will require its own scope and control after the 400 measurement.
• coder04-mba-l-ca verified · 1w ago
  Whole-tree typecheck gate on verifier SHA256 ddecf55e0778cf23ac48900cff577df35b72261fb9662089a11cafe944e4968a is MEASURED green by coder03: pnpm exec tsc --noEmit zero output/exit 0; subsequent MOVILBA-765 deploy ran pnpm typecheck to completion over the same tree. This closes prior TS2698 static hold; no coder duplicate gate run needed. The verifier's DEV ROLLBACK writer phase remains UNEXERCISED: db04 owes four pre-patch-189 mutant NULL failures and four current-writer passes, plus rollback confirmation.
• db04-mba-l-ca progress · 1w ago
  DEV execution of exact verifier SHA ddecf55e after coder03 measured typecheck green: first invocation without APP_ENV reached createColectivo but aborted before INSERT at origenIngresoNuevaFilaApp (APP_ENV unset). Same SHA rerun with APP_ENV=dev (installed mapping to app_dev) reached first INSERT but PostgreSQL rejected synthetic vehicle with 23514 chk_vehiculos_chasis_serial_activo: numero_serie_chasis NULL. SELECT-only pg_get_constraintdef: active vehicle requires numero_serie_chasis IS NOT NULL. DEV SELECT after both aborts: synthetic domains ZZ621ZZ/ZZ546ZZ present 0. Four mutant and four current history assertions remain UNEXERCISED; this is fixture incompleteness, not writer result. Return to coder04 for valid synthetic numeroSerieChasis and new SHA. No committed row.
• coder04-mba-l-ca verified · 1w ago
  DEV fixture repin at tools/verification/movilba-400-app-writer-control.ts SHA256 b6534a16660cf550fcbefb0969214a9199bd9ac598c87fede519e0610428e4e5, superseding ddecf55e. Previous db04 run: APP_ENV unset aborted before INSERT; with APP_ENV=dev the first INSERT hit chk_vehiculos_chasis_serial_activo because synthetic numero_serie_chasis was NULL. Neither phase reached assertions (0/4 mutant, 0/4 current), both synthetic domains absent postabort. New file requires APP_ENV=dev before imports and supplies a unique M400-prefixed chassis serial within varchar(50). I ran APP_ENV=dev --guard-probe: exit 1 at line59 identity guard before INSERT; pnpm exec tsc --noEmit over the whole tree: zero output, exit 0 on these bytes. DEV-only rollback writer run still owed by db04.
• db04-mba-l-ca progress · 1w ago
  DEV execution of exact verifier SHA b6534a16 with APP_ENV=dev: identity guard passed, first createColectivo INSERT rejected before history phases by PostgreSQL 23514 chk_vehiculos_motor_serial_activo (numero_serie_motor NULL). SELECT-only full CHECK census on public.vehiculos: domain format, non-NULL active chassis serial, non-NULL active motor serial, valid origen_ingreso. Synthetic ZZ897ZZ absent after transaction abort (0 rows). Mutant 0/4 and current 0/4 UNEXERCISED. Do not patch one constraint per round; next fixture must satisfy both serial checks and the remaining active-row constraints up front, then publish new SHA. No persistent row.
• coder04-mba-l-ca verified · 1w ago
  Fixture repin SHA256 2a6ad511cf68aac4a797ab7a5bf39fc7d18117b208afd91ec32ce5a4e6662bb6 at tools/verification/movilba-400-app-writer-control.ts. db04's b6534a16 run with APP_ENV=dev hit first INSERT but PostgreSQL rejected NULL numero_serie_motor via chk_vehiculos_motor_serial_activo; mutant 0/4, current 0/4, domain ZZ897ZZ absent postabort. New fixture adds unique M400+16-hex numeroSerieMotor (20 chars, fits varchar(20)); existing M400+UUID chassis serial fits varchar(50). Static constraint sweep: synthetic domain ZZ###ZZ satisfies chk_dominio_format, APP_ENV=dev yields allowed app_dev origin, both active serials non-NULL; VDC gets non-NULL interno, default conexiones_usb=25 satisfies its check, and allowed app_dev origin. APP_ENV precondition remains fail-closed. On exact new SHA I ran APP_ENV=dev --guard-probe (exit1 at DB identity line59 before INSERT) and whole-tree pnpm exec tsc --noEmit (exit0, no output). db04 still owns DEV-only ROLLBACK execution of four mutant failures and four current passes.
• db04-mba-l-ca progress · 1w ago
  DEV-only execution on exact tools/verification/movilba-400-app-writer-control.ts SHA256 2a6ad511cf68aac4a797ab7a5bf39fc7d18117b208afd91ec32ce5a4e6662bb6, APP_ENV=dev, .env.local DEV_DATABASE_URL: exit 0. Identity guard reported database movilba_dev, role movilba_user. Final verifier result: bookManufacturerNonblank=true, mutantFailures=4, currentPasses=4, rolledBack=true. The rolledBack result is emitted only after an independent post-transaction SELECT confirmed zero synthetic vehicles for the generated domains. This is the first candidate to reach all four writer assertions in both phases; earlier fixture/setup aborts remain UNEXERCISED rather than counted as writer failures. Audit code verdict remains owed, execution performed by db04, no PROD write or test traffic.
• coder04-mba-l-ca progress · 1w ago
  Read-surface inventory from current code (read-only): four independent chassis-manufacturer query paths cover five outputs. (1) ficha and its PDF share vehiculosRepository.findById -> v_vehiculos_detalle catalog-backed chasisFabricante; the page renders that same DTO. (2) current XLSX export reads v_vehiculos_export, with current-history enrichment that does not replace marcaChasis with raw chasis_marca. (3) historical report API joins each period's h.chasis_id to public.chasis/public.fabricantes and emits fabricante_chasis.fabricante. (4) RUTAP book export reads rutap.v_export_libro via getLatestRutapLibroRows, pinned to latest imported snapshot, so app-owned periods do not enter it. Existing src/repositories/vehiculos.chasis-marca.test.ts names these contracts but is a source-text guard, not a live row control. No reader fix proposed: db04's four-path DEV rollback shows current writers persist catalog manufacturer, while PROD has 0 app/no-snapshot current rows and 69 DEV rows are user-created test data left untouched by the 2026-09-24 rule. Audit code verdict on verifier SHA 2a6ad511 remains owed.
• audit-mba-l-cc audited · 1w ago
  audit pass: CODE ONLY at 2a6ad511, re-hashed before/after my tsc: DEV guard, mutant hook + self-check, rollback seams traced through the repo, fixture vs all 7 CHECKs and the NOT NULLs of both written tables, typecheck. EXECUTION NOT MINE - db04 ran it, I ran nothing. Four earlier pins NOT verdicted.
  payload

  {"scope":"CODE ONLY at 2a6ad511, re-hashed before/after my tsc: DEV guard, mutant hook + self-check, rollback seams traced through the repo, fixture vs all 7 CHECKs and the NOT NULLs of both written tables, typecheck. EXECUTION NOT MINE - db04 ran it, I ran nothing. Four earlier pins NOT verdicted.","outcome":"pass","evidence":"PASS on the CODE at 2a6ad511 (253 lines). Tables, three non-blocking findings and anchors: audit-finding. 764fe0f3, 9dc12914, ddecf55e, b6534a16 NOT verdicted - my b6534a16 FAIL draft on the motor-serial CHECK went unposted because db04 hit that abort and 2a6ad511 fixes it.\n\nFIXTURE: censused against every constraint, not the last to fail. All 7 validated CHECKs on vehiculos + vdc hold; of the four NOT NULLs without default, estado_id is absent and correctly so - vehiculos.ts:844-860 resolves ALTA and throws if missing, so the omission exercises the real default path. FRAGILITY: the motor serial (:153) is EXACTLY varchar(20)'s width, so any prefix change reopens the abort.\n\nROLLBACK, traced BEFORE the PASS since the PASS licenses the writes. db.update/delete, bare db.execute and pool.query are NOT replaced and the post-check (:235-239) counts only public.vehiculos, so a leak elsewhere is invisible; :105 only claims this, so I traced every bare db.* in vehiculos.ts and the two libs reached. Every write from :823 on goes through the replaced db.transaction or the stubbed db.insert, whose stub ASSERTS the table. Holds. Caveat: the 0-rows check sits after the rethrow at :232, confirming the rollback only on the success path.\n\nGUARD (:59-63): movilba_dev + movilba_user demanded before any write, re-measured as exactly that; --guard-probe only inverts the name then throws unconditionally. MUTANT: :216-217 asserts the hook fired 4x per phase, foreclosing a renamed alias going green.\n\nTYPECHECK: tsc --noEmit whole tree, exit 0, this file and drizzle/schema.ts (b6029b49) re-hashed before and after; not pnpm typecheck, so typegen did not run. 765's blocker reproduced at 9dc12914; cause FILED AS MOVILBA-768.\n\nNOT EXERCISED: no execution of mine at any pin - the 4 mutant failures, 4 passes and rolledBack are db04's; db.transaction replaced, so nested/savepoint semantics are not production's; db.insert stubbed; eslint ignores tools/**; suites do not cover it; census DEV only.","reportRef":null}

• audit-mba-l-cc audit-finding · 1w ago
  # MOVILBA-400 @ `2a6ad511` — audit verdict: PASS on the CODE. Execution was db04's. audit-mba-l-cc, 2026-10-08 tools/verification/movilba-400-app-writer-control.ts 2a6ad511cf68aac4a797ab7a5bf39fc7d18117b208afd91ec32ce5a4e6662bb6 (untracked) Re-hashed by me before AND after my typecheck run, unchanged, with `drizzle/schema.ts` at db04's regenerated `b6029b49` both times. **I did not execute the file, at any pin, not even `--guard-probe`** — it INSERTs and this lane is SELECT-only. db04 ran it and owns that result. My earlier wire correction stands: the reason is SELECT-only, not a credentials gap; MOVILBA-648 is the narrower fact that `svc_nextjs` lacks SELECT on two `rutap` objects in PROD. **Superseded pins, named so no one reads an old verdict into this one:** `764fe0f3`, `9dc12914`, `ddecf55e` and `b6534a16` are not verdicted. I reviewed `ddecf55e` in full and had a FAIL drafted against `b6534a16` for the motor-serial CHECK; db04's run hit that same abort and `2a6ad511` fixes it, so the FAIL is moot and was never posted. A pin that changes while under review gets no verdict. ## 1. The fixture satisfies every constraint on the two written tables — my own census, not the diff's claim The churn through four pins was a sequence of pre-INSERT aborts, each found one at a time. So I enumerated what the fixture has to satisfy, rather than checking the one that last failed. Measured in `movilba_dev`: | table | constraint | validated | fixture | |---|---|---|---| | vehiculos | `chk_dominio_format` | t | `ZZ###ZZ` (`:143`) matches `^[A-Z]{2}[0-9]{3}[A-Z]{2}$` | | vehiculos | `chk_vehiculos_chasis_serial_activo` | t | `numeroSerieChasis` (`:152`), 36 chars into `varchar(50)` | | vehiculos | `chk_vehiculos_motor_serial_activo` | t | `numeroSerieMotor` (`:153`), **exactly 20** into `varchar(20)` | | vehiculos | `vehiculos_origen_ingreso_ck` | t | `APP_ENV=dev` -> `app_dev`, in the allowed array | | vdc | `chk_conexiones_usb` | t | 25, and the CHECK allows only `{24,25}` | | vdc | `chk_vdc_interno_activo` | t | `interno` from `generate_series`, non-NULL | | vdc | `vehiculosdatoscolectivos_origen_ingreso_ck` | t | same `app_dev` | NOT NULL with no default: `vehiculos.dominio`, `vehiculos.vehiculo_subtipo_transporte_id`, `vehiculos_datos_colectivos.vehiculo_id` and `vehiculos_datos_colectivos.estado_id`. The first three are supplied. **`estado_id` is not**, and that is correct rather than lucky: `:844-860` of `src/repositories/vehiculos.ts` takes an `else` branch when `colectivoData.estadoId` is falsy and resolves `ALTA` from `v_opciones`, throwing a named configuration error if that option is missing. So the omission exercises the real default path instead of bypassing it. **One fragility worth recording:** the motor serial is `'M400' + 16 hex` = **20 characters, exactly the column width**. Any later change to that prefix overflows `varchar(20)` and reopens the same abort. It is at the limit, not under it. `origenIngresoNuevaFilaApp` (`src/lib/origen-ingreso.ts:16-27`) **throws** on an unset or unfamiliar `APP_ENV` rather than defaulting, and the `APP_ENV=dev` assert at `:27` sits before the dynamic imports (`:38-42`) and before `DATABASE_URL` is pinned — so it is a real precondition, not a comment. ## 2. The rollback guarantee holds — checked BEFORE the PASS, because the PASS is what licenses the writes The forced rollback only holds if every write goes through one of the two replaced seams (`db.transaction` -> `callback(outer)`, and the stubbed `db.insert`). **`db.update`, `db.delete`, bare `db.execute` and `pool.query` are not replaced**: any of those would run on a separate pooled connection, commit, and escape the rollback — and the post-check counts only `public.vehiculos` by `dominio`, so a leak into `vehiculo_historial_normalizado`, `audit_log` or `vehiculos_datos_colectivos` would be invisible. The verifier's comment at `:105` asserts this; I traced it instead. Every bare `db.*` in `src/repositories/vehiculos.ts`: | line | seam | reachable from the driven writers? | |---|---|---| | 102, 149, 203, 300 | helpers taking the executor as a parameter | yes — always called with `tx` | | 417, 421 | `db.select` in `findAll` | no — read API | | 601 | `db.execute` in `findDominioCandidates` | no — read API | | 835, 1149, 1281 | `db.transaction` — the three driven methods | yes, and this IS the replaced seam | From `:823` to the end of `applyColectivoEditWithHistory` there is no bare `insert`/`update`/`delete`/`execute` and no `pool.query`. Every helper the writers call receives `tx`: `columnasDesdeFicha(tx, …)` at `:966`, `:1165`, `:1525`, `:1630`, plus `resolverEstadoColectivo(tx, …)` and `resolverDominioParaHistorial(tx, …)`. `src/lib/audit-wrapper.ts` writes `tx.insert(auditLog)` (`:100`) and reaches it through `db.transaction(execute)` (`:116`) — the replaced seam — while `setTransactionActor` uses `tx.execute(set_config(…, true))`, a transaction-local setting. `src/lib/logger.ts:210` is `db.insert(appLogs)`, the stubbed seam, and the stub **asserts the table IS `appLogs`**, so a write to any other table through it throws instead of committing. `vehiculos.ts` imports none of the four repositories that use `pool.query` (`opciones`, `chasis`, `fabricantes`, `carrocerias`). ## 3. The DEV guard cannot reach an INSERT `:59-63`: `current_database()` must be `movilba_dev` and `current_user` `movilba_user` before any write. I re-measured `DEV_DATABASE_URL` this session — the same variable the verifier parses at `:29-33` — and it answers `movilba_dev|movilba_user`, so the guard's expected values are the real ones and the assert is not vacuous. `--guard-probe` only INVERTS the expected name and is followed by an **unconditional** `throw`, so even an accidental match cannot advance. It is a negative control on the guard and proves nothing about the writer, which coder04 states correctly. ## 4. The mutant is a real mutant, and self-checking `:118-127` wraps `outer.execute` and, in the mutant phase only, deletes the `chasisMarca` key — the field absent from `columnasDesdeFicha` before `e56dfd22`. A hook that matched nothing (renamed alias, changed projection) would make a green run; `:216-217` forecloses that by asserting it fired exactly 4 times per phase. `:203-214` additionally requires the mutant's failure to BE the NULL reproduction, so a failure for an unrelated reason does not count. db04's reported 4 mutant failures / 4 current passes are therefore measuring the intended thing — **as reported; I did not observe them.** ## 5. Typecheck `pnpm exec tsc --noEmit`, whole tree: no output, exit 0 at these bytes. I ran `tsc` directly, not `pnpm typecheck`, so `next typegen` did not run. For the record, the blocker that stopped coder03's 765 dev deploy at stage 3/5 was real and I reproduced it myself: at `9dc12914` the same command emitted exactly one error in the whole tree, `tools/verification/movilba-400-app-writer-control.ts(234,34): error TS2698`. Cause: `summary` was a `let` assigned inside the transaction callback, and TypeScript discards `assert.ok` narrowing for a variable written in a nested closure. Cleared from `ddecf55e` onward. **Structural cause filed as MOVILBA-768**: `tsconfig.json` `include` is `**/*.ts` (excluding only `node_modules`, `temp-disabled`, `api-external`) while eslint **ignores** `tools/**/*` (`eslint.config:17`) — I ran eslint on this file and it answers `File ignored because of a matching ignore pattern`. Every `.ts` under `tools/` gates dev AND prod whole-tree, and lint never catches it first. ## 6. Findings — none blocks the PASS 1. **The rollback confirmation runs only on the SUCCESS path.** `:235-239` verifies on a fresh connection that 0 synthetic domains survive, but it sits after `if (error !== rollback) throw error`, so on any run that fails inside the transaction nobody confirms the rollback. db04's `rolledBack=true` is a genuine observation precisely because their run succeeded; the four aborted candidates produced no such confirmation. Moving the count into `finally`, before `pool.end()`, would make it unconditional. 2. **`:216-217` counts ROWS while its message says CALLS.** `selected` increments per returned row carrying the key, so the figure equals the call count only while each `columnasDesdeFicha` call returns exactly one row. 3. **The fixture inherits the behavior under measurement.** `:88-94` picks the regulatory-category option with no `borrado_en` filter, deliberately, to mirror the installed resolver — and every option in that group is soft-deleted, so the fixture necessarily writes a soft-deleted id. Correct for reproducing the writer, and it means this instrument **cannot** answer whether the writer should accept a deleted option. That is the separate `src/repositories/vehiculos.ts:311` question, now measured by db03 under MOVILBA-767; keep the two apart. ## 7. NOT EXERCISED - **No execution of mine, at any pin.** The four mutant failures, four current passes, `bookManufacturerNonblank=true` and `rolledBack=true` are db04's measurements as reported to me, not observations of mine. - `db.transaction` is replaced, so nested-transaction and savepoint semantics are **not** those of production: a defect that only appears when an inner transaction rolls back independently cannot be seen by this instrument. - `db.insert` is stubbed, so the real `app_logs` write path is unexercised. - No eslint verdict is possible for this path (§5). `test:source` and `test:tools` do not cover the file — it is untracked, hand-run, and outside `tools/tests/*.test.*js`. `next build` not run. - The constraint census in §1 is **DEV only**; the verifier refuses to run anywhere else, so PROD's constraint set was not compared.
• coder04-mba-l-ca completed · 1w ago
  Code-confirmed non-defect closed on audited verifier SHA256 2a6ad511cf68aac4a797ab7a5bf39fc7d18117b208afd91ec32ce5a4e6662bb6, tracked clean in commit 78124caf (patch 213). db04's DEV-only rollback measurement observed four pre-patch-189 mutant NULL failures, four current-writer passes, bookManufacturerNonblank=true and zero synthetic vehicles after rollback. Four independent read query paths serving five outputs inventoried in progress note. PROD has 0 qualifying app/no-snapshot current rows; 69 DEV user-created rows remain untouched under Elazar's 2026-09-24 rule. No runtime application fix or row repair owed. Verifier is hand-run, outside ship test glob. Audit PASS covers code only; db04 owns execution. Non-blocking abort-path rollback-confirmation gap moved to MOVILBA-770, with its own SHA/verdict. DEV and PROD patch 213 health green per coder03; pod push accepted, live patch not yet reported at close.