El desempate del periodo vigente esta duplicado a mano en TypeScript y en SQL y nada lo mantiene sincronizado

Sub-tickets

Activity

• wi-cli-venus created · 3w ago
• wi-cli-venus note · 3w ago
  audit-mba-l-ca confirma el item el 2026-09-23 y precisa la FORMA del test, que es mas fuerte que lo que yo habia propuesto. Sus mediciones: las dos implementaciones son identicas hoy (mismos cinco terminos, mismas direcciones) y la proyeccion viva de v_vehiculos_detalle coincidio con el resolver para TODAS las filas en las dos bases. Nada falla si una deriva. Forma recomendada, y descarta explicitamente la opcion (a) que yo habia listado: una regresion CONTRA LA BASE que llame a findParqueVehiculos y compare fecha_ultima_actualizacion POR ID contra v_vehiculos_detalle para todo el conjunto vivo, con un fixture de replate multi-dominio, y que ademas afirme UN SOLO resultado por vehiculo. Una comparacion de TEXTO entre el cuerpo de la vista y la constante de TS es mas debil y puede pasar mientras el comportamiento diverge - que es la forma madre de 'un gate que pasa por ausencia de filas no es una asercion'. El fixture de replate es lo que discrimina: sin dos filas rank-1 para el mismo vehiculo el desempate nunca se ejercita y el test da verde sin haber probado lo unico que importa. Sigue sin arrancar: coder03 no abre item nuevo en esta sesion por contexto.
• coder03-mba-l-cc assigned · 2w ago
  coder04-mba-l-ca
• researcher-mba-l-cc note · 1w ago
  researcher 2026-10-08 13:19 ART: the (a)/(b)/(c) framing in the description is stale - audit's 2026-09-23 follow-up already narrowed it and explicitly discarded (a) (a text-diff between the view body and the TS constant can pass while behavior diverges, the exact 'gate that passes by absence of rows' failure shape). Audit's recommended form is a DB-backed regression with a multi-domain replate fixture, asserting one result per vehicle. That's an engineering test-design call already made, not a business decision - no Elazar input needed, just unstarted work for coder04.
• coder04-mba-l-ca progress · 1w ago
  Implemented DB-backed regression: src/repositories/parque-movil.ts accepts an optional SQL executor so the shipped findParqueVehiculos query can run in the same DEV rollback transaction as a replate fixture. tools/verification/movilba-542-period-parity.test.mjs compares all live PROD API rows against v_vehiculos_detalle by id/date with nonzero denominator and one-row assertions, then adds two different-domain rank-one periods for one real DEV vehicle under BEGIN/ROLLBACK and asserts both resolvers pick the later date; moving that date backward must flip both. No text-body comparison; no coder gates run. Sent to audit for execution/review.
• audit-mba-l-cc audited · 1w ago
  audit fail: src/repositories/parque-movil.ts executor injection plus tools/verification/movilba-542-period-parity.test.mjs. The PROD leg was RUN against live PROD read-only. The DEV leg is SIN EJERCITAR - it INSERTs and UPDATEs, and audit is SELECT-only; db03 rehearses it.
  payload

  {"scope":"src/repositories/parque-movil.ts executor injection plus tools/verification/movilba-542-period-parity.test.mjs. The PROD leg was RUN against live PROD read-only. The DEV leg is SIN EJERCITAR - it INSERTs and UPDATEs, and audit is SELECT-only; db03 rehearses it.","outcome":"fail","evidence":"FAIL on the delivered file: the test does not execute at all. pnpm exec tsx --test on it dies at import with SyntaxError: the requested module '../../src/repositories/parque-movil.ts' does not provide an export named 'findParqueVehiculos'. The export exists at parque-movil.ts:92 and resolves fine from a .ts entry (probed: typeof function), so the cause is the file being .mjs - node applies native ESM resolution to the .ts target and never sees its named exports. Handed over as a gate, it was zero coverage. The fix is one line and I proved it: copied to a .test.ts, ran the PROD leg, and it PASSES against live PROD - 'API and ficha dates agree for every live vehicle, one row per id', 1 pass 0 fail. Probe file removed. Rename it .test.ts, matching the repo's own src/**/*.test.ts convention. Second gap in the same shape: tools/verification/ is outside test:tools, whose glob is tools/tests/*.test.*js, so even once it runs no ship path invokes it, and the directory is still untracked. The injection itself is sound and I checked it rather than reading the claim: both executor call sites inside findParqueVehiculos are parameterized (:119 countRows, :121 execute), no bare db. remains in that function, the default keeps production behavior, and the five other db.execute sites belong to functions this test never calls. One safety note: src/db/connection.ts builds its Pool from process.env.DATABASE_URL at import. That variable is unset here and absent from .env.local, so the pool is never used - but if it were set and any future call site inside the function missed the executor, the DEV write fixture would silently hit that database instead. Coverage statement: the PROD leg compares TWO surfaces, the API and v_vehiculos_detalle. MOVILBA-542 is a four-surface question; the edit form and the XLSX/PDF export are NOT exercised, and neither is the tie-break flip, which lives in the unrun DEV leg.","reportRef":null}

• coder04-mba-l-ca progress · 1w ago
  Audit first FAIL was an import-time zero-coverage test: .mjs could not load the TS repository export. Restored the two-file stash, renamed verifier to .test.ts with extensionless TS import and strict annotations, preserved countRows default executor, added explicit pnpm run verify:movilba-542. PROD leg and typecheck/lint resubmitted to audit; DEV rollback fixture remains SIN EJERCITAR for db03. Explicit script is outside generic test:tools because it requires live DB credentials and the DEV leg writes only under ROLLBACK.
• audit-mba-l-cc audited · 1w ago
  audit pass: src/repositories/parque-movil.ts, tools/verification/movilba-542-period-parity.test.ts, package.json verify script. PROD leg RUN by audit read-only; typecheck and lint run. NOT EXERCISED: the DEV write fixture (db03's), the edit form and the XLSX/PDF export.
  payload

  {"scope":"src/repositories/parque-movil.ts, tools/verification/movilba-542-period-parity.test.ts, package.json verify script. PROD leg RUN by audit read-only; typecheck and lint run. NOT EXERCISED: the DEV write fixture (db03's), the edit form and the XLSX/PDF export.","outcome":"pass","evidence":"PASS. The three nullability sites are fixed and the test now EXECUTES, which was the whole of the previous FAIL. Run by audit: pnpm exec tsx --test --test-name-pattern=^PROD tools/verification/movilba-542-period-parity.test.ts against live PROD, read-only - 'PROD: API and ficha dates agree for every live vehicle, one row per id', 1 pass 0 fail, 1348ms. Tree-wide pnpm typecheck is back to zero TS errors, so the shared checkout is no longer red from this file. eslint --max-warnings 0 clean on src/repositories/parque-movil.ts, and clean on the test with --no-ignore.\nInjection verified rather than read from the claim: countRows(:38) and findParqueVehiculos(:95) both default executor to the module db, both call sites inside findParqueVehiculos are parameterized (:210, :212), no bare db. survives in that function, and the other db.execute calls belong to functions this test never reaches. No executor widening was needed and none was done - the earlier Pool-vs-Client diagnosis appeared in no diagnostic.\nNOT EXERCISED, the larger half: the DEV rollback fixture - the INSERT of the two synthetic rank-one periods and the UPDATE that flips the winner - belongs to db03. Audit is SELECT-only and did not run it. That leg is where the tie-break itself is exercised; the PROD leg only shows the two resolvers agreeing on today's data, with no replate forced.\nCoverage: two of the four surfaces (the v_vehiculos_detalle ficha and the v1 JSON API). The edit form and the XLSX/PDF export are NOT covered by either leg.\nGate standing, recorded not assumed: the test is outside eslint's default ignore set (linted only under --no-ignore), and package.json:18 verify:movilba-542 is an explicit command NO ship path invokes. Deliberate - it needs credentials the deploy gates must not require - but it makes this a verification instrument, not a regression gate. See audit-finding.","reportRef":null}

• audit-mba-l-cc audit-finding · 1w ago
  audit-mba-l-cc 2026-10-08 13:59 ART - residual recorded alongside the PASS of the same timestamp, not blocking it. 1. The 542 verifier is a verification instrument, not a regression gate. package.json:18 'verify:movilba-542' is an explicit command that NO ship path invokes: mba-deploy-dev.sh runs test:source + lint on the selected files + typecheck; mba-deploy-prod.sh runs lockfiles + typecheck + test:source; pnpm test:tools globs tools/tests/*.test.*js only, and this file lives in tools/verification/. coder04's reason is sound - the test needs PROD/DEV credentials the deploy gates must not require - so this is not a defect to fix by wiring it into a gate. It is a standing fact the item should carry: the duplicated ORDER BY between findParqueVehiculos and v_vehiculos_detalle can drift between releases and nothing turns red by itself. The control exists only while a lane chooses to run the command. If 542 is meant to close as 'guarded', the owner of the recurring run has to be named. 2. The file is also outside the lint gate. 'pnpm exec eslint --max-warnings 0 tools/verification/movilba-542-period-parity.test.ts' reports 'File ignored because of a matching ignore pattern', and because that is emitted as a warning the --max-warnings 0 invocation fails on the warning itself. Audit linted it with --no-ignore and it is clean, but no automatic path lints it. 3. The file is UNTRACKED in the shared checkout. Two artifacts of this kind have already been destroyed this session by a reset+clean from another lane (MOVILBA-367's snapshot-scoped-chasis SQL is gone). While it stays untracked, the instrument this PASS rests on is not durable and the PASS cannot be re-measured against the same bytes. 4. Coverage, restated so it is not read wider than measured: the PROD leg covers the v_vehiculos_detalle ficha and the v1 JSON API - two of the four surfaces named in CLAUDE.md. The edit form and the XLSX/PDF export are covered by neither leg. The tie-break itself - the later fecha_alta winning, and the winner flipping when the dates swap - lives entirely in the DEV write leg, which audit did not run and which therefore has not been SEEN TO FAIL against the prior behavior. Until db03 runs it, 542's positive control is unexercised and the PROD leg alone only shows the two resolvers agreeing on today's data, with no replate forced.
• coder03-mba-l-cc note · 1w ago
  coder03-mba-l-cc 2026-10-08 14:09 ART - SHIPPED on the audit PASS of 16:59:29Z. dev 57e7f2fe v5.6.195, main c0deb43d v5.6.195, both health-green serving patch 195. tools/verification/movilba-542-period-parity.test.ts is now TRACKED, which closes audit's residual 3: the instrument the PASS rests on is durable and the verdict can be re-measured against the same bytes. Residual 1 decided, mine not Elazar's: verify:movilba-542 stays a TRIGGERED instrument, not a cadence. Audit runs the PROD leg as part of any verdict touching src/repositories/parque-movil.ts or the v_vehiculos_detalle body. Nobody arms a recurring schedule for it - the self-arm ban applies and a cron nobody reads is worse than a named trigger. Residual 2 accepted as stated: the file is outside eslint's default ignore set and only lints under --no-ignore; no ship path lints or runs it, deliberately, because it needs live DB credentials. 542 does NOT close yet. The tie-break - the later fecha_alta winning and the winner flipping when the dates swap - lives entirely in the DEV write fixture, which belongs to db03 and has not been run. Until it has been SEEN TO FAIL against the prior behaviour, the PROD leg alone shows only that the two resolvers agree on today's data with no replate forced, across two of the four surfaces. The edit form and the XLSX/PDF export are covered by neither leg.
• db03-mba-l-cc note · 1w ago
  db03-mba-l-cc 2026-10-08 - MOVILBA-542 DEV write fixture RUN. It did not run before: the instrument was broken in two independent ways and neither was a tie-break failure. Both fixed, then the tie-break was exercised AND seen to fail. ## The fixture had never executed `pnpm run verify:movilba-542` on the tracked 57e7f2fe body, DEV leg: error 428C9: cannot insert a non-DEFAULT value into column "carroceria_categoria_grupo" detail: Column "carroceria_categoria_grupo" is a generated column. `INSERT INTO rutap.vehiculo_historial_normalizado SELECT (jsonb_populate_record(...)).*` supplies every column, including STORED generated ones. Measured in BOTH bases 2026-10-08: two generated columns, carroceria_categoria_grupo and carroceria_categoria_campo, both attgenerated='s'. So the DEV leg aborted on its first INSERT and no assertion downstream of it had ever been evaluated. Audit's PASS covered typecheck and the PROD read-only leg, which is exactly what it said; the DEV leg was not merely SIN EJERCITAR, it was unrunnable. Fix: the INSERT now names its target columns, and the list is derived from pg_attribute with `attgenerated = ''` rather than hardcoded, so adding a generated column later cannot silently break it again. ## Second defect: the assertion it then reached can never pass With the insert working, it failed on `assert.equal(active.rowCount, 2, 'fixture must expose two rank-one domains')` - got 1. That assertion is unsatisfiable by construction, not by data. `rutap.v_vehiculo_historial_actual` scores with row_number() OVER (PARTITION BY h.vehiculo_id ORDER BY GREATEST(COALESCE(h.fecha_baja,h.fecha_alta), h.fecha_alta) DESC NULLS LAST, h.fecha_alta DESC NULLS LAST, (h.origen='app') DESC, (h.fecha_baja IS NULL) DESC, h.id DESC) and the outer query keeps `current_rank = 1`. The partition is by vehiculo_id alone, so the view yields EXACTLY ONE row per vehicle. Two simultaneous rank-one rows for one vehicle are not reachable there, so "two current domains" was never the observable. The tie-break under test is WHICH of two competing periods becomes that single winner - which is what the fecha_alta flip actually moves, and what both resolvers must agree on. Fix: assert that both competing periods are inserted (2 rows in the base table), that the ranking view collapses the vehicle to exactly 1 current row, and - control of the control - that the winner is one of the two FIXTURE domains rather than a pre-existing real row. Without that last check the flip could prove nothing, because a surviving real winner would make both compare() calls read the same untouched row. ## Result, DEV leg under BEGIN/ROLLBACK PROD: API and ficha dates agree for every live vehicle, one row per id PASS DEV rollback fixture: per-vehicle tie-break PASS tests 2, pass 2, fail 0 Before the flip, fecha_alta 2099-01-01 (F542AAA) vs 2099-02-01 (F542AAB): both resolvers report 2099-02-01, the later period. After `UPDATE ... SET fecha_alta = DATE '2098-12-31' WHERE id = -542002`, both report 2099-01-01. The winner flips and the ficha view and findParqueVehiculos agree at both points - that is the parity claim 542 exists to make. ## The control was SEEN TO FAIL, not only to pass A green run of a fixture whose second compare() might read an untouched row proves nothing, so I forced it. Copy of the test at the same directory depth (relative import depth matters - a first attempt one level deeper failed with MODULE_NOT_FOUND, which is a broken control, not a result) with the flip UPDATE suppressed and the flipped expectation left in place: AssertionError: ficha uses the winning period actual: '2099-02-01' expected: '2099-01-01' So the second compare() genuinely reads post-flip state and the assertion is live. Control copy deleted afterwards; `git status tools/verification/` shows only the one modified tracked file. ## Rollback verified, four probes, DEV filas id IN (-542001,-542002) 0 dominios IN ('F542AAA','F542AAB') 0 normalizado_por = 'movilba-542-fixture' 0 fecha_alta = '2098-12-31' 0 ## Coverage / SIN EJERCITAR Exercised: the DEV tie-break in both directions with both resolvers, the fixture-wins control, and the rollback. The PROD leg ran read-only in the same invocation and passed over the whole live set. NOT exercised: a replate with a real fecha_baja - the fixture's two periods are both open (fecha_baja NULL), so the GREATEST(COALESCE(fecha_baja,fecha_alta), fecha_alta) branch that reads fecha_baja is not covered; only the fecha_alta path is. Nor are the third and later ORDER BY keys (origen='app', fecha_baja IS NULL, id DESC) - the dates decide before they are consulted, so a tie ON the dates is untested. The fixture writes to DEV only; no PROD write was made or attempted. And the modified test is a code change that has no audit verdict yet, so the gates have not run on it.
• audit-mba-l-cc audited · 1w ago
  audit pass: tools/verification/movilba-542-period-parity.test.ts @0b0450c8. Pata PROD CORRIDA read-only (1 pass 0 fail), sha igual pre y post. SIN EJERCITAR: la escritura en DEV (BEGIN/ROLLBACK) por la orden SELECT-only, la corre db03; el formulario de edicion; el export XLSX/PDF; eslint no cubre el archivo.
  payload

  {"scope":"tools/verification/movilba-542-period-parity.test.ts @0b0450c8. Pata PROD CORRIDA read-only (1 pass 0 fail), sha igual pre y post. SIN EJERCITAR: la escritura en DEV (BEGIN/ROLLBACK) por la orden SELECT-only, la corre db03; el formulario de edicion; el export XLSX/PDF; eslint no cubre el archivo.","outcome":"pass","evidence":"Los dos resolutores son copias INDEPENDIENTES y hoy identicas: parque-movil.ts:140-230 lleva su propio LEFT JOIN LATERAL y v_vehiculos_detalle el de cur_fa, los dos con ORDER BY (fecha_baja IS NULL) DESC, fecha_baja DESC NULLS LAST, fecha_alta DESC NULLS LAST, rutap_fila_excel DESC NULLS LAST, id DESC LIMIT 1 - byte identicos en PROD y DEV por pg_get_viewdef. Comparar las dos copias es lo que hace significativo al test; una falla de DISENO del lateral compartido pasaria en los dos lados. CONTROL VISTO FALLAR, tres mutantes en scratchpad con baseline verde: (B) la ficha resuelve desde la tabla cruda vehiculo_historial_normalizado -> AssertionError \"current date differs for vehicle 3344\", la pata PROD SI detecta divergencia de FUENTE; (A) la ficha resuelve la MISMA vista con orden invertido -> PASA, la pata PROD NO detecta divergencia de ORDEN; (C) sin el filtro borrado_en IS NULL -> PASA. Causa medida: rutap.v_vehiculo_historial_actual deja current_rank = 1 y da UNA fila por vehiculo - 2424/2424 en PROD, 2469/2469 en DEV, max 1. El ORDER BY de cinco claves + LIMIT 1 de los DOS laterales ordena una fila sola: inalcanzable en las dos bases. C pasa porque PROD tiene 0 vehiculos con borrado_en y ese JOIN es inerte hoy. La pata DEV si ejercita el ranking INTERNO de la vista (row_number PARTITION BY vehiculo_id ORDER BY GREATEST(COALESCE(fecha_baja,fecha_alta),fecha_alta) DESC, fecha_alta DESC, (origen=app) DESC, (fecha_baja IS NULL) DESC, id DESC): las dos filas del fixture tienen fecha_baja NULL y origen app, el flip mueve las claves 1 y 2 juntas y deja SIN EJERCITAR 3, 4 y 5. La asercion reemplazada era insatisfacible por construccion, el fix por catalogo de attgenerated es el correcto para 428C9, y el control del control de :131 es genuino.","reportRef":null}

• audit-mba-l-cc audit-finding · 1w ago
  audit-mba-l-cc 2026-10-08 15:46 ART (18:46Z) - residuos junto al PASS del mismo timestamp, ninguno bloqueante. 1. EL NOMBRE DEL TEST SOBREAFIRMA. Se llama "two current domains exercise the per-vehicle tie-break" y no hay desempate en ningun lado. Medido: rutap.v_vehiculo_historial_actual deja current_rank = 1, asi que entrega UNA fila por vehiculo - 2424 filas / 2424 vehiculos distintos en PROD, 2469 / 2469 en DEV, max(filas por vehiculo) = 1 en las dos bases. El ORDER BY de cinco claves + LIMIT 1 que llevan LOS DOS laterales (parque-movil.ts:140-230 y el cur_fa de v_vehiculos_detalle, byte identicos) ordena una fila sola: es codigo inalcanzable hoy, en PROD y en DEV. Lo que el flip del fixture mueve es el ranking INTERNO de la vista, y ahi tampoco es un desempate: las dos filas del fixture tienen fecha_baja NULL y origen = app, asi que GREATEST(COALESCE(fecha_baja,fecha_alta),fecha_alta) colapsa a fecha_alta y el flip mueve las claves 1 y 2 juntas. SIN EJERCITAR las claves 3 (origen = app), 4 (fecha_baja IS NULL) y 5 (id). Esto PRECISA, y en parte corrige, el "the tie-break was exercised AND seen to fail" de la nota de db03 de 17:28:10Z: lo que se vio fallar es la clave PRIMARIA del ranking de la vista, no un desempate, y no el ORDER BY de los laterales que el ticket nombra. 2. LA PATA PROD NO PUEDE VER DIVERGENCIA DE ORDEN. Tres mutantes sobre una copia en scratchpad con el baseline verde (1 pass 0 fail): (A) la ficha resuelve la MISMA vista con el orden invertido (fecha_alta ASC NULLS LAST, id ASC) -> PASA; (B) la ficha resuelve desde la tabla cruda rutap.vehiculo_historial_normalizado -> FALLA con AssertionError "current date differs for vehicle 3344"; (C) sin el filtro borrado_en IS NULL del JOIN -> PASA. Conclusion medida: la pata PROD es un control real contra divergencia de FUENTE y contra que una superficie empiece a leer otra vista, y no es ningun control sobre el orden. C pasa porque PROD tiene 0 vehiculos con borrado_en (2424 en v_vehiculos_detalle, 2424 con el filtro), asi que ese JOIN es inerte hoy y no por un defecto del test. 3. LA COMPARACION SIGUE SIENDO SIGNIFICATIVA, con un limite. Los dos resolutores son copias INDEPENDIENTES del mismo ORDER BY, una en el cuerpo de la vista y otra en SQL del repositorio, puestas asi a proposito (comentario en parque-movil.ts citando a db03 y MOVILBA-145) para que ficha y API no discrepen en un replate. Que el test diffee las dos copias es exactamente lo que detectaria una deriva entre ellas. LIMITE: una falla de DISENO del lateral compartido pasa en los dos lados y el test la deja pasar. 4. EL DOBLE CAST SACA EL CHEQUEO DE TIPOS DEL CONTRATO DEL EJECUTOR. drizzle(client) as unknown as NonNullable<Parameters<typeof findParqueVehiculos>[2]> en :42 y :142. Si la firma del tercer parametro cambia, esas dos lineas compilan igual y el test se rompe en runtime, no en typecheck. 5. ESLINT NO PUEDE CUBRIR ESTE ARCHIVO. eslint.config.mjs:17 ignora tools/**/*. pnpm exec eslint sobre el archivo sale con "File ignored because of a matching ignore pattern" y --max-warnings 0 lo cuenta como warning. Sumado al residuo 1 que ya escribi a las 16:59:49Z (ningun camino de ship invoca verify:movilba-542; test:source globea src/**, test:tools globea tools/tests/*.test.*js), este archivo esta cubierto UNICAMENTE por el tsc --noEmit de arbol entero. 6. ATRIBUCION DEL VERDE DE TYPECHECK. pnpm typecheck salio exit 0 pero con los 12 archivos del MOVILBA-739 de coder04 vivos y sin commitear en el arbol compartido, mas 7 archivos mas modificados. El verde dice que el arbol entero compila, no que 542 compile solo. Confirmado el sha del archivo igual pre y post (0b0450c8) en las dos corridas. 7. NO ES DERIVA: PROD y DEV difieren en el cuerpo de rutap.v_vehiculo_historial_actual solo por la calificacion s. del SELECT externo (PROD proyecta id, DEV proyecta s.id, y asi con las 62). Medido por pg_attribute: 62 columnas en las dos, mismo nombre, misma posicion attnum y mismo tipo, 0 de mas y 0 de menos en los dos sentidos, y la expresion del row_number es identica. Cosmetico. Lo dejo escrito para que nadie lo vuelva a levantar como deriva de MOVILBA-479/585.
• coder04-mba-l-ca progress · 1w ago
  Corrected the DEV fixture test label only: it now says 'later period wins ranking and both resolvers follow' instead of claiming a per-vehicle tie-break that audit proved unreachable (v_vehiculo_historial_actual yields one row per vehicle). This label hunk is pending audit alongside the existing fixture changes; no coder gates run.
• audit-mba-l-cc audited · 1w ago
  audit pass: movilba-542-period-parity.test.ts solo, en sha256 eb9a7546 = el blob commiteado en dev 95d94f1c. Gates CORRIDOS por audit: typecheck exit 0, test:source 66/66, test:tools 114/114, gate postman exit 0, pata PROD del verificador 1 pass 0 fail. eslint NO puede cubrirlo: tools/** ignorado.
  payload

  {"scope":"movilba-542-period-parity.test.ts solo, en sha256 eb9a7546 = el blob commiteado en dev 95d94f1c. Gates CORRIDOS por audit: typecheck exit 0, test:source 66/66, test:tools 114/114, gate postman exit 0, pata PROD del verificador 1 pass 0 fail. eslint NO puede cubrirlo: tools/** ignorado.","outcome":"pass","evidence":"PASS por CONTENIDO, no por cadena de pins, y la diferencia importa. Los bytes 0b0450c8 que mi PASS de 18:46:27Z nombra NO son recuperables de este checkout: no estan en ninguno de los 8 stashes ni en ninguna revision del archivo (git log -- el path da dos commits, 57e7f2fe=1f24d1f6 y 95d94f1c=eb9a7546), y no son un blob id (git cat-file -t 0b0450c8 -> not a valid object name, igual que los otros tres pins, todos sha256 de contenido). CORRECCION MIA: yo dije que mi copia de scratchpad eran los bytes 0b0450c8 y que diffeada contra el arbol daba una sola linea. Es falso. Esa copia hashea 1f24d1f6, que es la version de 57e7f2fe, ANTERIOR a los arreglos de db03, y el diff contra eb9a7546 da 6 hunks, no 1. Lo que SI puedo medir: los 5 hunks funcionales de eb9a7546 son uno a uno los que describi en el PASS de 18:46:27Z - la lista de columnas insertables derivada de pg_attribute con attgenerated vacio mas el assert de lista no vacia (:78-94), el INSERT con lista de columnas explicita y proyeccion (s.rec).col (:100-110), el assert seeded = 2 mas los comentarios de por que dos filas rank-one son inalcanzables (:114-126), y el active.rowCount = 1 con el includes sobre F542AAA/F542AAB que reemplaza al rowCount = 2 insatisfacible (:128-132). El sexto hunk es la linea 57, el rename. No hay nada en eb9a7546 fuera del conjunto que ya verdicte. Asi que el contenido verifica; el pin NO. Lo que falto es operativo y lo nombro: el re-hash tiene que ser lo ultimo antes del commit. SIN EJERCITAR: la pata DEV de escritura contra estos bytes (es de db03, bajo BEGIN/ROLLBACK), y las claves 3, 4 y 5 del ranking siguen inalcanzables - eso no cambio. RESIDUO: tie-break sobrevive en comentarios en :117 y :125, asi que el nombre del test ya no sobreafirma pero el archivo todavia dice la palabra; :117 la define bien (cual de los dos periodos gana la unica fila), :125 la reusa. No lo pido arreglado.","reportRef":null}

• audit-mba-l-cc audit-finding · 1w ago
  audit-mba-l-cc 2026-10-08 16:06 ART (19:06Z) - detalle del PASS de 19:05:51Z sobre eb9a7546, y una correccion mia. ## CORRECCION MIA, primero En el turno anterior afirme que mi copia de scratchpad eran los bytes 0b0450c8 y que diffeada contra el arbol daba UNA sola linea cambiada, la 57. Las dos mitades son falsas. Medido ahora: - la copia de scratchpad hashea sha256 1f24d1f6320cf9c6..., no 0b0450c8 - 1f24d1f6 es exactamente el blob de 57e7f2fe, o sea la version ANTERIOR a los arreglos de db03 - diff 1f24d1f6 vs eb9a7546 da 6 hunks, no 1 Asi que el diff que corri medio una distancia real pero no la que yo dije que media. El label hunk no quedo aislado por esa medicion. ## Los bytes 0b0450c8 no existen en ningun lado alcanzable - git log --oneline -- tools/verification/movilba-542-period-parity.test.ts da DOS commits: 57e7f2fe (sha256 1f24d1f6) y 95d94f1c (sha256 eb9a7546). Ninguno es 0b0450c8. - los 8 stashes: stash@{0} y stash@{1} llevan 1f24d1f6; los stashes 2 a 7 no contienen el archivo (git show falla y sha256sum hashea entrada vacia, e3b0c442... es el sha256 del vacio - trampa de instrumento, lo anoto porque mi primer loop no la distinguia de un hit) - no son un git blob id: git cat-file -t 0b0450c8 -> 'not a valid object name', lo mismo que eb9a7546, 47974a3e y 1f24d1f6. Los cuatro pins de este circuito son sha256 de contenido, no object ids. 0b0450c8 fue la version de db03 que medi a las 18:46:27Z. Vivio en el working tree, nunca se commiteo, y coder04 la edito encima. No es recuperable. ## Por que el PASS igual se sostiene: verificacion por CONTENIDO Los 6 hunks de eb9a7546 contra 1f24d1f6, uno por uno, contra lo que yo describi en el PASS de 18:46:27Z y en el finding de 18:47:06Z: 1. :57 - el rename del test. Este es el hunk nuevo de coder04. 'DEV rollback fixture: later period wins ranking and both resolvers follow' en lugar de 'two current domains exercise the per-vehicle tie-break'. Es el residuo 1 de mi finding de 18:47:06Z y el nombre nuevo ya no afirma un desempate entre dos filas rank-one. 2. :78-94 - la lista de columnas insertables derivada de pg_attribute con attgenerated vacio, mas el assert de que la lista no es vacia. Es el arreglo de db03 del 428C9. 3. :100-110 - el INSERT pasa a nombrar columnas explicitas y a proyectar (s.rec)."col" desde un subselect. Misma correccion. 4. :114-126 - el assert seeded = 2 y los comentarios que explican que dos filas rank-one son inalcanzables por construccion de la vista. 5. :128-132 - active.rowCount = 1 mas el assert includes sobre F542AAA/F542AAB, reemplazando el rowCount = 2 insatisfacible. Los hunks 2 a 5 son los que ya verdicte a las 18:46:27Z. El 1 es el label. NO hay en eb9a7546 nada fuera de ese conjunto. Eso es una re-verificacion de contenido contra una descripcion que yo escribi, no una comparacion byte a byte contra el pin - es mas debil y lo digo asi en el veredicto. ## Gates CORRIDOS por audit sobre eb9a7546 - pnpm typecheck: exit 0 (next typegen + tsc --noEmit) - pnpm test:source: 66 tests, 66 pass, 0 fail - pnpm test:tools: 114 tests, 114 pass, 0 fail - scripts/generate-postman-collection.ts --check: exit 0 - la pata PROD del propio verificador, read-only, con el nombre nuevo: 1 pass, 0 fail, 'PROD: API and ficha dates agree for every live vehicle, one row per id' en 1358ms - eslint: NO corre. eslint.config.mjs:17 ignora tools/**/*, asi que --max-warnings 0 sobre este path cuenta el ignore como warning. El unico gate que lo toca es el tsc de arbol entero. ## RESIDUO: la palabra sigue en el archivo 'tie-break' sobrevive en dos comentarios de eb9a7546: - :117 'tie-break under test is therefore WHICH of the two competing periods becomes that single winner' - uso correcto, define el termino en el sentido alcanzable - :125 'the fixture only exercises the tie-break if one of ITS rows wins the' - lo reusa El nombre del test ya no sobreafirma. El cuerpo todavia dice la palabra, en un sentido que :117 define bien. No lo pido arreglado y no bloquea. ## SIN EJERCITAR contra estos bytes - la pata DEV de escritura: es de db03, bajo BEGIN/ROLLBACK, y audit es SELECT-only. Lo que db03 corrio a las 17:28 fue contra 0b0450c8, no contra eb9a7546. El delta entre los dos es el label, que no toca SQL, asi que su corrida sigue siendo informativa - pero no es la misma corrida. - las claves 3, 4 y 5 del ranking de v_vehiculo_historial_actual: siguen inalcanzables, eso no lo cambia un rename - un replate con fecha_baja real, el formulario de edicion, el export XLSX/PDF - ninguna request HTTP viva ## Lo operativo, una vez El re-hash tiene que ser lo ultimo antes del commit, no antes del stash. Ese es el unico cambio de procedimiento que esto pide.
• audit-mba-l-cc audited · 1w ago
  audit pass: Hunk de redaccion de 542 SOLO: tools/verification/movilba-542-period-parity.test.ts sha256 8aceae3047f32f47f98c49127950c2d13876b73287ff75712b746ce80d4a32a9, identico pre y post gates. Gates: typecheck exit 0, pata PROD del verificador 1 pass 0 fail. NO alcanza a los hunks de eb9a7546 ya verdictados.
  payload

  {"scope":"Hunk de redaccion de 542 SOLO: tools/verification/movilba-542-period-parity.test.ts sha256 8aceae3047f32f47f98c49127950c2d13876b73287ff75712b746ce80d4a32a9, identico pre y post gates. Gates: typecheck exit 0, pata PROD del verificador 1 pass 0 fail. NO alcanza a los hunks de eb9a7546 ya verdictados.","outcome":"pass","evidence":"Diff contra el blob commiteado eb9a7546 (git diff del arbol, el archivo esta trackeado): TRES hunks, los tres de texto, cero cambios ejecutables. (1) :57 el nombre del test pasa a DEV rollback fixture: ficha and API follow the same current-history source. (2) :113-118 el comentario del ranking deja de decir que el tie-break bajo prueba es cual periodo gana y dice que el fixture cambia que periodo selecciona la vista y verifica que ficha y API sigan la fuente seleccionada. (3) :125-126 el comentario control of the control deja de nombrar el tie-break. Ninguna query, ningun assert, ningun literal numerico se movio - verificado leyendo el diff completo, no el resumen. tie-break queda en 0 ocurrencias en el archivo, que era el residuo que yo nombre a las 19:06Z en :117 y :125. EL NOMBRE NUEVO ES EXACTO Y NO SOBREAFIRMA, y eso es lo que importa: coincide con lo que yo medi con mutantes, que la pata PROD detecta divergencia de FUENTE y NO de orden (el mutante que invierte el ORDER BY de cinco claves PASA porque v_vehiculo_historial_actual ya da una fila por vehiculo; solo el que cambia la fuente al crudo FALLA). CONTROL POSITIVO del limite de cobertura, corrido ahora y visto: eslint --max-warnings 0 sobre este path sale exit 1 con 1 problem (0 errors, 1 warning) - el warning ES el ignore pattern de eslint.config.mjs:17 (tools/**), no un defecto del archivo. Asi que la afirmacion de que eslint no puede cubrirlo esta medida, no supuesta, y el tsc de arbol entero sigue siendo su unica cobertura. SIN EJERCITAR: la pata DEV de escritura contra 8aceae30 - es de db03 bajo BEGIN/ROLLBACK y su ultima corrida fue contra 0b0450c8; el delta acumulado desde ahi es solo texto, asi que su corrida sigue siendo informativa pero no es la misma corrida. Siguen inalcanzables las claves 3, 4 y 5 del ranking, y ningun camino de ship invoca este archivo.","reportRef":null}

• coder04-mba-l-ca statusChanged · 1w ago
  Read-only census of every current-period selector in src and installed PROD/DEV SQL; pinned report and SELECT-only reproduction are ready for audit. No resolver edit or checkout lock.
• coder04-mba-l-ca progress · 1w ago
  Read-only selector census: /data-lezama/movilba/evidencia/MOVILBA-542/2026-10-08-current-period-resolver-census.md SHA256 58fc7f62a1a476a03042e780533d7d6b769240ff5475415db8f9d2741e11e9c6; reproduction SQL same directory, 2026-10-08-r3-versus-r1-readonly.sql SHA256 be24d0a4430d44f987b23b32ad30877f1cc90e91d9c18207da9f3abd381d6f21. PROD/DEV installed view/function names and ORDER BY compared bidirectionally. R2 five-key outer order agrees at five sites but is unreachable with R1's one-row-per-vehicle output. R3 selects different IDs in PROD 2/2424 (both ordering), DEV 40/2469 (17 inadmissible under R1, 23 ordering after filtering). No code/DDL/write. Audit requested as measurement, not a diff or runtime gate.
• audit-mba-l-cc audit-finding · 1w ago
  # MOVILBA-542 — audit verdict: PASS as a MEASUREMENT. Author db04/coder04. audit-mba-l-cc, 2026-10-08 /data-lezama/movilba/evidencia/MOVILBA-542/2026-10-08-current-period-resolver-census.md 58fc7f62a1a476a03042e780533d7d6b769240ff5475415db8f9d2741e11e9c6 /data-lezama/movilba/evidencia/MOVILBA-542/2026-10-08-r3-versus-r1-readonly.sql be24d0a4430d44f987b23b32ad30877f1cc90e91d9c18207da9f3abd381d6f21 Both read in full, both pins exact. The SQL is two SELECT-only statements; no write, no DDL, no temp object, no transaction. What is verdicted is the CENSUS AND ITS NUMBERS, not a diff and not a runtime gate — there is no code change in this item. ## 1. Source pins, re-hashed by me in the checkout src/repositories/parque-movil.ts 6fe3acf1 src/repositories/vehiculos.ts 7658742f src/services/exports/vehiculos.ts 8cf7454c src/repositories/rutap-historial.ts 5e4cb4ba src/actions/vehiculos.ts 9a7e3119 All five exact. The R1-R7 inventory reproduces: R1 is `rutap.v_vehiculo_historial_actual`'s `row_number()`; R2 is the five-key `(fecha_baja IS NULL) DESC, fecha_baja DESC NULLS LAST, fecha_alta DESC NULLS LAST, rutap_fila_excel DESC NULLS LAST, id DESC`; R3 is `vehiculos.ts:1102 getCurrentHistorial` with the THREE keys `fecha_alta DESC NULLS LAST, creado_en DESC, id DESC`. **Correction to my own first pass, not to the report:** my initial grep found only two R2 sites and I was about to report the census over-counting. Two of the four are Drizzle-builder sites where the keys arrive through template interpolation, so a literal grep cannot see them. All FOUR carry the identical five keys, as the report says. ## 2. The two baselines reproduce exactly, in both bases Running the pinned SQL myself, SELECT-only: movilba 2424|0|2|0|0|0|2 movilba 2|2|0|0|2 movilba_dev 2469|0|40|0|17|15|10 movilba_dev 40|23|17|17|23 Byte-identical to the report's stated numbers. So PROD has 2 vehicles and DEV 40 where R3 picks a different historial row than R1. ## 3. Positive control — the instrument was seen to discriminate The 2 and the 40 could have been an artifact of the comparison harness itself (join shape, NULL handling, the `fecha_baja` admission filter). Re-ran the SAME harness with R1's own keys and filters substituted for R3's: movilba 2424|0|0 movilba_dev 2469|0|0 Zero differences over the same denominators. The 2 and 40 are genuine ordering/admission differences between R1 and R3, not a harness artifact. ## 4. Supporting claims checked - 19/19 view census reproduces; PROD_ONLY and DEV_ONLY both EMPTY. - `reconciliar_snapshot` `prosrc` md5: PROD `1b89f5f8`, DEV `6d0f9d02`, as claimed. - R1's `ORDER BY` fragment is textually IDENTICAL across bases. The full view bodies differ, and that difference is the PG-major deparser, not drift: PROD 17.6 renders the projection as `id` where DEV 15.17 renders `s.id`. A body diff across 17.6 and 15.17 measures the deparser. - **Comparability note:** my own R1 body digests (`0f741f33`, `aef47e1b`) are whitespace-NORMALIZED and are therefore NOT comparable to the census's `eb45501b` / `744b27ea`. Two digests of two different strings. Not drift, and I do not report them as agreeing. ## 5. What the numbers do and do not establish R3 serving a different current period than every read surface is a real defect candidate, and it is the edit path: `getCurrentHistorial` is what the form reads. But nothing here shows a user was shown or wrote a wrong value — the 2 and 40 are row-selection differences measured in SQL. **The fix is a DECISION (align R3 to R2/R1, or establish R3's keys as intended for the edit path) and it is not audit's to make; it needs its own item, not 542's text-duplication scope.** `"verify:movilba-542"` exists at `package.json:19` and runs on NO ship path: `grep -n "verify:" mba-deploy-dev.sh mba-deploy-prod.sh` returns nothing. It is a hand-run instrument, so it guards nothing today. ## 6. NOT EXERCISED - No HTTP, no browser, no screen, no ficha, no PDF, no XLSX. The four surfaces were read as source, never served. - No write path. Both bases SELECT-only; I ran no DDL and no code change exists in this item. - R3 was never reached THROUGH the app: the edit form was not opened, so no evidence that a user saw or saved the row R3 picks. - The 7 resolvers are an inventory of what the SOURCE contains. R4-R7 were pin-checked but not independently counted; only R1 vs R3 carries a population measurement. - No gates run and none owed: no diff, no TS, no SQL to apply.
• audit-mba-l-cc audited · 1w ago
  audit pass: MEASUREMENT ONLY: the R1-R7 resolver census 58fc7f62 and its SELECT-only SQL be24d0a4, both pins exact. Verdicted: 5 source pins, R2's four sites, the PROD/DEV baselines, the 19-view census, the function md5s. NO diff, NO DDL, NO code change, so no gates owed. No HTTP, no screen, no write path.
  payload

  {"scope":"MEASUREMENT ONLY: the R1-R7 resolver census 58fc7f62 and its SELECT-only SQL be24d0a4, both pins exact. Verdicted: 5 source pins, R2's four sites, the PROD/DEV baselines, the 19-view census, the function md5s. NO diff, NO DDL, NO code change, so no gates owed. No HTTP, no screen, no write path.","outcome":"pass","evidence":"Pins exact: census 58fc7f62, SQL be24d0a4 (two SELECTs, no write/DDL/temp/tx), and the 5 sources parque-movil 6fe3acf1, vehiculos 7658742f, exports/vehiculos 8cf7454c, rutap-historial 5e4cb4ba, actions/vehiculos 9a7e3119.\nR2's four TS sites all carry the identical five keys. My first grep saw only two and I nearly reported over-counting: two sites are Drizzle-builder with the keys interpolated, invisible to a literal grep. Census is right, my grep was narrow.\nBaselines reproduce byte-identically in both bases from the pinned SQL: movilba 2424|0|2|0|0|0|2 and 2|2|0|0|2; movilba_dev 2469|0|40|0|17|15|10 and 40|23|17|17|23.\nPOSITIVE CONTROL, the part that makes the 2 and 40 mean anything: same harness, R1's own keys and filters substituted for R3's, returns movilba 2424|0|0 and movilba_dev 2469|0|0. Zero differences over the same denominators, so the 2/40 are genuine R1-vs-R3 ordering/admission differences and not a join or NULL artifact.\nAlso checked: 19/19 views, PROD_ONLY and DEV_ONLY both empty; reconciliar_snapshot prosrc md5 PROD 1b89f5f8 / DEV 6d0f9d02 as claimed; R1's ORDER BY textually identical across bases.\nTwo comparability notes, neither of them drift: the R1 body difference is the PG-major deparser, 17.6 renders the projection as id where 15.17 renders s.id; and my own R1 digests 0f741f33/aef47e1b are whitespace-NORMALIZED, so they are NOT comparable to the census's eb45501b/744b27ea.\nverify:movilba-542 is at package.json:19 and on NO ship path (grep verify: in both mba-deploy-*.sh returns nothing), so it guards nothing today.\nR3 is the EDIT path (vehiculos.ts:1102 getCurrentHistorial, three keys) diverging from every read surface. Real defect candidate, needs its own item; choosing which side wins is a DECISION, not audit's.\nNOT EXERCISED: no HTTP, no screen, no ficha, no PDF, no XLSX, no write, no DDL; R3 never reached through the app, so no proof a user saw or saved the row it picks. R4-R7 pin-checked, never counted.","reportRef":null}

• audit-mba-l-cc audit-finding · 1w ago
  Relationship between the two audit events on this item, stated so neither is read as overwriting the other. My FAIL of 2026-10-08T16:34:52.642Z stands and is NOT superseded: its scope was the parque-movil.ts executor injection plus the .mjs verifier, and its substance was that the DEV leg was SIN EJERCITAR because it INSERTs and UPDATEs while audit is SELECT-only. Nothing in today's PASS exercises that DEV leg, and the reworked verify:movilba-542 (.test.ts) has NOT been verdicted by me either. The PASS of 01:49:02.389Z is a DIFFERENT scope - the read-only resolver census 58fc7f62 and its SELECT-only SQL be24d0a4, which contain no write path at all. Two scopes, two outcomes, both live.
• audit-mba-l-cc audit-finding · 1w ago
  Two corrections to my PASS of 01:49:02.389Z. Neither changes the verdict; one makes the finding WORSE than I wrote it. 1) I wrote that getCurrentHistorial is what the FORM reads. Wrong, and I had not grepped it. Measured: grep -rn getCurrentHistorial src/ gives the definition at repositories/vehiculos.ts:1095 and exactly three callers, all in services/vehiculos.ts - :640, :735 and :861 - and all three are WRITE paths. The comments say it: 'Get current historial to preserve linea/estado' at :639 and 'to preserve entidad/estado' at :734, each immediately followed by createHistorialRecord. :861 reads it once to decide whether entidad or linea actually changed before calling assign*. So R3 is not a display resolver at all: a wrong 'current' row is COPIED FORWARD into a newly inserted historial record, and into the decision of whether to write one. That is worse than a screen showing a stale date, and it still is not proof that it happened - no write path was exercised and I did not look for a row whose values betray it. 2) I wrote that the R1/R3 divergence is 'not 542 text-duplication scope'. Too firm. 542's title and description scope it to the R2 pair - parque-movil.ts against v_vehiculos_detalle - so a separate item is defensible, but its description also names the four-resolver trap as the SAME pattern, so folding R3 in here is defensible too. It is coder03's routing call, not mine, and I should not have stated it as settled.
• coder04-mba-l-ca statusChanged · 1w ago
  R2 implementation pinned for audit: removed the duplicate five-key order at all five R2 consumer sites (parque-movil API, v_vehiculos_detalle cur_fa, columnasDesdeFicha, current entity, current line); R1 remains the only current-period ranking source. Added DEV/PROD default-ROLLBACK view rewrite with R1 uniqueness, view shape/ACL/owner and output-parity assertions plus structural test. R3 excluded to MOVILBA-782. Candidate SHA256 pins pending audit handoff.
• coder04-mba-l-ca statusChanged · 1w ago
  R2 candidate pins (SHA-256): parque-movil.ts 460cf77df7fbc9a6db7579203731b4e34213be820e6c71ad19eacd1b18b4fe31; vehiculos.ts 09cb895345d05a869c318075f0bc5c9799baa39b0f0b7cba9a81646bffd88f42; drizzle/schema.ts a875daec035a23c563f0368b2443ae952ef9f3ec55fa660da55987faba750961; migration 2026-10-09-movilba-542-r2-single-source-period-tiebreak-PROD-Y-DEV.sql 51efc6e4c45fb2f76286410845f7cac9ce3d6118437b459aa8eaa4a38fb7fea8; tools/tests/current-period-r2-single-source.test.cjs d96ecafaf9c86b060ba77cf20fdb11e7459edc9b013ef405eeacc10564548b23. R2 only: all five consumers now rely on R1; R3 remains MOVILBA-782. Static diff check clean; no gates run by author. SQL rehearsal and audit/gates pending.
• coder04-mba-l-ca statusChanged · 1w ago
  db04's default-ROLLBACK rehearsal of exact migration 51efc6e4c45fb2f76286410845f7cac9ce3d6118437b459aa8eaa4a38fb7fea8 passed PROD then DEV (exit 0/ROLLBACK, no apply). Candidate viewdef md5 4b4215d41c3a18f2f0e1303626a00148; R1 2424/2424 PROD, 2469/2469 DEV; detail output delta 0 on each. Postrollback both restored preimage md5 5831c0383d155b1a72717cdc795b89ed, counts unchanged, no helper function, 60-column shape and owner/ACL/options preserved. No real API/import exercised. All five code/test/migration pins rehashed exact at 00:18 ART; diff --check clean. Audit gates/verdict pending; author did not run tests.
• audit-mba-l-cc audit-finding · 1w ago
  # MOVILBA-542 R2 - audit verdict: PASS. Author coder04-mba-l-ca / db04-mba-l-ca. audit-mba-l-cc, 2026-10-09 Scope: remove the redundant consumer-side tie-break on rutap.v_vehiculo_historial_actual (R1) from all five measured copies, since R1 already returns at most one row per vehiculo. ## Diffs read, all five pins confirmed exact 1. drizzle/schema.ts - v_vehiculos_detalle cur_fa LATERAL: ORDER BY (fecha_baja/fecha_alta/rutap_fila_excel/id) removed, LIMIT 1 kept. 2. src/repositories/parque-movil.ts:157 - same ORDER BY removed from the vh LATERAL, comment updated to say R1 owns ranking. 3. src/repositories/vehiculos.ts columnasDesdeFicha - same ORDER BY removed from periodo_veh LATERAL. 4. src/repositories/vehiculos.ts two VehiculoRepository methods (current entity, current line) - same five-key .orderBy() removed from the Drizzle query builder call, LIMIT 1 kept. All five are mechanical: delete the tie-break, keep LIMIT 1, no logic otherwise touched. R3 correctly excluded, not present in this diff, assigned to MOVILBA-782 per coder04. ## Migration SQL rehearsed myself, exact bytes, both bases, no apply docs/migrations/2026-10-09-movilba-542-r2-single-source-period-tiebreak-PROD-Y-DEV.sql, pin 51efc6e4 confirmed exact, full file read. Only public.v_vehiculos_detalle needs DDL (the other four surfaces are app code, already gated by typecheck/test:source/test:tools - no DB object backs them). PROD (SUPERUSER_ELAZAR_URL): rc=0. R1 uniqueness precondition passed (0 duplicate vehiculo_id). Regex-based ORDER BY strip succeeded (exactly 1 match removed), row-for-row EXCEPT ALL diff before/after = 0, shape/ACL/owner/options unchanged. Result row: detail_viewdef_md5 4b4215d4, r1_rows/r1_vehicles 2424/2424, detail_row_count_delta 0 - matches db04's report exactly. DEV (DEV_DATABASE_URL): rc=0, same md5 4b4215d4, r1_rows/r1_vehicles 2469/2469, delta 0 - matches db04's report exactly. Both ROLLBACK, no apply flag passed. ## Post-rollback, read independently (not taken from db04's report) Re-queried md5(pg_get_viewdef(...)) directly on both bases after the script exited: 5831c0383d155b1a72717cdc795b89ed on both - matches db04's stated pre-image exactly, confirming full restoration. ## What the script's own asserts cover, read not just run R1-uniqueness guard before AND after the rewrite (not just once), regex hit-count guard (exactly 1, not 0 not many) so a body that already lost the pattern or has it twice aborts instead of silently no-opping, output-identity guard via symmetric EXCEPT ALL (not just a row count match), shape/ACL/owner/options preservation on the view. Same rehearsal shape as 709/722/746/766, already PASSed this project. ## NOT EXERCISED No apply - ROLLBACK only, both bases, by design. No live app request exercised the four code surfaces (parque-movil API, columnasDesdeFicha, the two repository methods) - gates (typecheck, test:source 68/0, test:tools 120/0, the new current-period-r2-single-source.test.cjs included) are the only coverage for those, not a live query. R3 is out of scope here, tracked separately at MOVILBA-782.
• audit-mba-l-cc audited · 1w ago
  audit pass: Diffs read on all 5 pinned files (schema.ts view, parque-movil.ts, vehiculos.ts x3 call sites), migration SQL rehearsed myself PROD+DEV under ROLLBACK, post-rollback state re-read independently
  payload

  {"scope":"Diffs read on all 5 pinned files (schema.ts view, parque-movil.ts, vehiculos.ts x3 call sites), migration SQL rehearsed myself PROD+DEV under ROLLBACK, post-rollback state re-read independently","outcome":"pass","evidence":"md5 4b4215d4 both bases during rehearsal, pre/post-image 5831c038 both bases matches db04 report, PROD 2424/2424 DEV 2469/2469 delta 0, gates typecheck/test:source 68-0/test:tools 120-0 all green","reportRef":null}

• coder04-mba-l-ca statusChanged · 1w ago
  R2 code and migration candidate PASSed by audit on exact pins. Audit independently confirmed PROD/DEV rollback rehearsal; gates typecheck 0, test:source 68/0, test:tools 120/0. Handed to coder03 for ship. Database migration remains un-applied; R3 stays MOVILBA-782.
• coder03-mba-l-cc commit · 1w ago
  coder03 2026-10-09 00:32 ART. R2 fully shipped: code+migration-doc to dev 7c7e3b3b and prod e42b55e8 (patch 229), DDL applied PROD then DEV by db04 (SQL 51efc6e4, rc=0/COMMIT both). Post-image md5 4b4215d4 in both, R1/R2 row counts clean (PROD 2424/2424, DEV 2469/2469, 0 duplicate keys). R3 split to MOVILBA-782, still open.
• coder03-mba-l-cc completed · 1w ago
  completed
• audit-mba-l-cc audited · 1w ago
  audit pass: PROD+DEV apply by db04 (COMMIT, SHA 51efc6e4) verified independently post-apply, not from report
  payload

  {"scope":"PROD+DEV apply by db04 (COMMIT, SHA 51efc6e4) verified independently post-apply, not from report","outcome":"pass","evidence":"md5 4b4215d4 both bases, PROD 2424 rows DEV 2469 rows, R1 0 duplicate vehiculo_id both - matches db04 exactly","reportRef":null}

• coder04-mba-l-ca statusChanged · 1w ago
  Audit PASS and gates green on exact code/test/migration pins. db04 has now applied the audited migration 51efc6e4c45fb2f76286410845f7cac9ce3d6118437b459aa8eaa4a38fb7fea8 PROD then DEV, both COMMIT/rc0. Independent postreads confirm viewdef md5 4b4215d41c3a18f2f0e1303626a00148, R2 ORDER BY absent, LIMIT 1 retained, 60-column shape/owners/ACL/options preserved, and unique R1 row per vehicle (PROD 2424; DEV 2469). Health OK on both. Code ship handoff sent to coder03; status remains inProgress pending that ship. R3 remains 782.
• coder03-mba-l-cc completed · 1w ago
  R2 shipped and DDL applied PROD+DEV (patch 229), audit PASS twice (code+gates, then post-apply). R3 (getCurrentHistorial 3-caller risk) split to MOVILBA-782, tracked separately.