movilba
MOVILBA-269
El espejo ancho no tiene escritor para el snapshot 11: el unico que lo escribe esta cableado al 10
Done urgent
dmdb02-mba-l-cc
MEDIDO por db03-mba-l-ca el 2026-09-05 07:05 y aceptado por coder02. ESTADO: rutap crudo esta en snapshot 11 en DEV y en PROD (libro 2026-09-05-0649-parque-rutap.xlsx, 5388 filas Base, 2407 dominios). El ESPEJO ANCHO de DEV sigue en snapshot 10 (5370 filas). PROD no tiene espejo ancho. EL HUECO: el unico archivo que escribe el espejo ancho es docs/migrations/2026-09-04-movilba-203-wide-refresh-snapshot10-DEV.sql, y tiene el snapshot 10 CABLEADO. MOVILBA-227 (el loader de aplicacion) no lo llama. Hoy nadie lleva el espejo ancho al 11 y el hueco no tenia numero. QUE HACE FALTA: un escritor del espejo ancho PARAMETRIZADO por snapshot_id, no un segundo archivo cableado al 11 - el proximo libro deja el problema igual. Y tiene que quedar integrado en la SECUENCIA del loader aceptado, no como un paso suelto que alguien se acuerda de correr: crudo -> espejo ancho -> aplicacion. OJO CON LA IDENTIDAD: la tabla ancha es un espejo de un SNAPSHOT, no un ledger, y su identidad es (snapshot_id, fila_excel). Un refresh no es un merge; v_rutap_latest califica al SNAPSHOT, no a la fila. DEV ONLY. Lo de PROD queda anotado en pending-prod-changes.md y no se toca.
Activity
-
GO DE ELAZAR 2026-09-06 05:20 ART via coder02-mba-l-cc. ARRANCA YA y BLOQUEA todo lo demas del plan de esta noche. db03-mba-l-ca ejecuta, db02-mba-l-cc verifica. MEDIDO por coder03-mba-l-cc y db02-mba-l-cc: rutap.vehiculo_historial_normalizado tiene UN SOLO snapshot - min y max rutap_snapshot_id = 10, 5370 filas, 2406 vehiculos, fa_min 2025-06-19 y fa_max 2026-09-03 - mientras el libro va por el 11. Una proyeccion de un solo snapshot NO es una historia: hasta que esto se destrabe, el export, el repunte de vistas y el rebuild miden un libro viejo. Desanclar el escritor, cargar el 11 y backfillear los libros que tenemos. Costo acotado: ~5370 filas por snapshot, doce libros conocidos, ~64k filas a carga completa.
-
Arranca por GO de Elazar; es el paso 1 y bloquea los otros cuatro.
-
2026-09-08 00:10 - RE-CONFIRMADO con el snapshot 12 (db02-mba-l-cc): el importer (tools/rutap-snapshot-import.py) escribe SOLO rutap.snapshots/rutap_rows/rutap_expedientes; nada proyecta un snapshot nuevo a rutap.vehiculo_historial_normalizado (filas de 9/10/11 escritas todas el 2026-09-06 05:33:28 por el rebuild de 299, normalizado_por movilba-202/203), y el unico escritor comprometido (203 wide-refresh) hace DELETE de la tabla entera, lo que borraria las 13 filas app. Consecuencia esta noche: la secuencia 'import primero, despues 333' que pidio Elazar no puede cumplirse; 333 corre sobre el snapshot 11 y el 12 queda en rutap.* sin consumidor. REQUISITO para el proyector por snapshot: aplicar la regla de 333 (estado_id de la ficha sobre el periodo abierto del ultimo snapshot; cerrados NULL) en la misma corrida, y no tocar origen='app'.
-
2026-09-08 00:12 - RIESGO QUE SUBE LA PRIORIDAD: src/repositories/vehiculos.ts:755-758 (dev) y v_vehiculos_hist_ultimo filtran los periodos import por rutap_snapshot_id = max(rutap.snapshots.id). Insertar un snapshot nuevo en rutap.snapshots SIN proyectarlo deja invisibles TODOS los periodos import para la app: cada vehiculo importado se lee sin periodo abierto. Por eso el snapshot 12 (2026-09-07-2350) NO se aplica en DEV hasta que exista el proyector: queda solo el rehearsal (db02, md5 33fd410d..., 5388 Base + 47 Hoja2). Cualquier import --apply a DEV o PROD queda condicionado a 269.
-
0
-
2026-09-08 00:14 - REVISION DE FUENTE (db03-mba-l-ca, solo lectura): el DELETE del 203 (docs/migrations/2026-09-04-movilba-203-wide-refresh-snapshot10-DEV.sql) es WHERE rutap_snapshot_id <> :snapshot_id, no incondicional - las filas app (rutap_snapshot_id NULL) no matchean - pero sigue siendo inutilizable: borra los otros snapshots importados, hardcodea el 10, lee solo el ultimo origen y usa ON CONFLICT DO NOTHING. Requisitos del proyector nuevo: snapshot explicito como entrada; escrituras acotadas por origen (jamas toca origen='app'); cobertura exacta de filas fuente; gates de cardinalidad de catalogo; proyeccion idempotente que preserva raw_*; publicacion ATOMICA (snapshot publicado + proyeccion completa en la misma tx, o un puntero explicito de snapshot publicado) - max(rutap.snapshots.id) crudo nunca puede exponer un snapshot sin proyectar (regresion medida esta noche: 2->376 vehiculos sin periodo, PMI013 'No hay registros'). Y aplica la regla de 333 (estado_id desde la ficha sobre abiertas) en la misma corrida.
-
2026-09-08 00:25 - DECISION DE ELAZAR (CLI 00:20): NO se revierte el snapshot 12; se construye el arreglo de largo plazo esta noche. DISEÑO (coder02): el proyector es una FUNCION rutap.proyectar_snapshot(p_snapshot_id bigint) RETURNS TABLE(filas_base, filas_proyectadas, conflictos, filas_app), creada por docs/migrations/2026-09-08-movilba-269-proyectar-snapshot-DEV.sql. Cuerpo = 203 lineas 118-319 parametrizado, fuente rutap.rutap_rows normalizada para p_snapshot_id (no v_rutap_latest_norm), SIN DELETE, mas la regla de 333 (estado_id desde la ficha sobre abiertas). RAISE si el snapshot no existe, si ya tiene filas proyectadas (idempotencia = rechazar), si proyectadas <> base, o si cambia el conteo de origen='app'. No toca la vista. El importer (tools/rutap-snapshot-import.py --apply) la llama en la misma transaccion, despues del insert de rutap_expedientes y antes del COMMIT: max(rutap.snapshots.id) nunca queda sin proyectar. Esta noche: la migracion crea la funcion y la corre para el 12. db02 escribe, db03 revisa, audit PASS, db02 aplica; coder02 cablea el importer. El revert (1ec5cbf8..., PASS de audit) queda como fallback.
-
2026-09-08 00:28 - REPARTO (Elazar: delegar): db02 escribe la funcion rutap.proyectar_snapshot + migracion y la aplica para el 12 tras PASS de audit; db03 revisa el SQL (solo lectura) y despues hace la migracion de las dos vistas; coder-mba-l-ca cablea el importer (tools/rutap-snapshot-import.py build_postgres, llamada en la misma tx antes del COMMIT, abort si proyectadas <> base o abiertas_sin_estado > 0); coder03 endurece los 6 lectores de codigo a 'ultimo snapshot PROYECTADO' con UN helper en rutap-historial.ts. coder02 coordina, commitea y relaya GOs.
-
coder-mba-l-ca: importer patch prepared from dev 6924c07f in persistent worktree coder-mba-l-ca/movilba-269-importer. Same-transaction projector call before publication checks; five-count report plus conflict reasons; rollback on projected count mismatch or nonzero abiertas_sin_estado; missing-function prerequisite; 333 header and PROD coupling notes. Python AST and git diff --check pass. Audit requested from audit-mba-l-cc (ca unavailable). Awaiting db02 function-applied confirmation before single existing 2026-09-07-2350 idempotent rehearsal; no fake snapshot and no DEV run yet. Deployment pending that dependency.
-
2026-09-08 00:24 - DISEÑO crear_fichas_faltantes(snapshot) (db03-mba-l-ca, revision solo lectura de los scripts faltantes del 08-21 y del correctivo MOVILBA-112): stagear dominios normalizados DISTINCT, no filas Base; >1 vehiculo vivo que matchea = abort; distinguir faltante real de solo soft-deleted (no duplicar ni resucitar en silencio). Un periodo fuente por dominio: el abierto unico si existe, si no el ultimo cerrado por fechas validadas; empates conflictivos se reportan, nunca se adivinan por expediente lexicografico. Toda opcion por vistas de catalogo con match exactamente-uno; sin IDs hardcodeados, sin blanco->NO, sin ORDER BY id LIMIT 1. Un vehiculo + un VDC por dominio faltante, RETURNING ids con procedencia; filas creadas por la app se preservan; la historia ancha la escribe SOLO el proyector. Estado desde fecha_baja del periodo elegido; BAJA jamas pone borrado_en (leccion 112: 131 colectivos invisibles por copiar fecha_baja a borrado_en). Gates: creados = candidatos distinct; conjuntos de dominios candidato-vs-creado iguales; una ficha viva por dominio; igualdad de campos resueltos; cada colectivo nuevo visible por la vista canonica con linea/entidad; segunda llamada crea cero. Secuencia en UNA tx: raw -> resolucion de catalogos/prerrequisitos -> crear fichas faltantes -> sync de fichas existentes -> proyeccion ancha -> gates de cobertura/publicacion -> commit. Snapshot 12: 0 dominios nuevos, no lo necesita; los proximos imports estan incompletos sin este paso. PROVENANCE del proyector (audit): el 203 en disco del checkout compartido (06e618f5) NO es el de dev (c9671a92): es 202 con nombre de 203, sin MOVILBA-248; el cuerpo sale del ref.
-
Importer audit received from audit-mba-l-cc: transaction structure PASS, not ship clearance. Ordering and additional filas_base gate referred to coder02 because original placement spec differs. Requested db02 confirmation of projector-owned app-row preservation and return-column contract. PROD59 privilege caveat disputed between supplied wording and audit evidence; awaiting resolution. Coverage explicitly corrected: permitted existing-MD5 snapshot12 rehearsal exits before projection; importer new-snapshot projection branch remains unexercised until next real book. No rehearsal or deploy yet.
-
MOVILBA-269 lector: control NO REPRODUCIBLE, medido por coder03-mba-l-cc en DEV movilba_dev el 2026-09-08 00:20 ART, solo mientras el snapshot 12 exista importado y sin proyectar. Cuando el proyector corra los dos punteros coinciden y el control pasa vacio para siempre (lo senalo audit-mba-l-cc). ESTADO MEDIDO: punta de rutap.snapshots = 12 (importado 00:09, 5388 filas en rutap.rutap_rows, 47 expedientes) con 0 filas en rutap.vehiculo_historial_normalizado; el snapshot 11 tiene las 5388. max(id) FROM rutap.snapshots = 12; max(rutap_snapshot_id) FROM vehiculo_historial_normalizado WHERE origen='import' AND borrado_en IS NULL = 11. CONTROL, dominios PMI013 y AA033TK, filas vivas: con el puntero VIEJO 0 filas de import cada uno (total 2, ambas origen='app'); con el puntero NUEVO 1 fila de import cada uno, snapshot 11 - AA033TK con su alta del 2026-09-04 cerrada el 09-07, PMI013 abierta desde el 2026-09-02. Los dos punteros corridos como SELECT, sin escribir. SUPERFICIE MEDIDA EN LA MISMA CORRIDA: rutap.v_vehiculo_historial_actual publica 6 filas en vez del parque; public.v_vehiculos_hist_ultimo 2418. Las dos vistas llevan el puntero viejo en su cuerpo (pg_get_viewdef), asi que el arreglo no es completo sin la migracion de db03. COBERTURA: DEV solamente, SELECT solamente. PROD no se toco y no tiene espejo ancho. No typecheck, no pantalla abierta.
-
CONDICION QUE EL LECTOR LE IMPONE AL PROYECTOR (la impone el lector, por eso es invisible desde el proyector si no queda escrita aca). Los seis sitios de codigo y las dos vistas resuelven el snapshot vigente como (SELECT max(rutap_snapshot_id) FROM rutap.vehiculo_historial_normalizado WHERE origen='import' AND borrado_en IS NULL) o sea el puntero sale de las FILAS PROYECTADAS, no del catalogo rutap.snapshots. 1. La proyeccion de un snapshot tiene que COMMITEAR ENTERA EN UNA TRANSACCION. Si commitea por lotes, el puntero salta al snapshot nuevo con la PRIMERA fila insertada y todo lector publica medio snapshot: falla silenciosa, peor que la de hoy, que al menos se lee vacia. audit-mba-l-cc reviso el diff de coder-mba-l-ca a las 00:23 y el importador ya cumple (una conexion, una transaccion, pg_advisory_xact_lock, rollback en except BaseException, commit solo bajo --apply); esto queda escrito para el que toque el proyector despues, no como pedido de cambio. 2. El borrado_en IS NULL dentro del puntero NO es un riesgo, es la definicion, y no se 'arregla': el puntero solo retrocede cuando el snapshot tope queda con CERO filas de import vivas, que es exactamente cuando deja de ser el snapshot proyectado. Borrar logicamente algunas filas del tope no lo mueve. (Correccion de audit-mba-l-cc a como yo lo habia anotado.) 3. Limite conocido, planteado por db03-mba-l-ca: el puntero asume conjuntos de import no vacios e inmutables. La solucion general durable es metadata explicita de snapshot publicado; no esta en este cambio. 4. Se deploya como UNIDAD: los seis sitios TS y las dos vistas en el mismo push, o ninguno. Con solo uno de los dos lados, una pantalla que lee vista resuelve 12 y no muestra nada mientras una que lee los seis sitios resuelve 11 y muestra el parque; la falla de hoy al menos es uniforme. (audit-mba-l-cc, BLOQUEANTE.)
-
2026-09-08 00:26 - Orden del importer: raw-load + checks de latest/unicidad, DESPUES proyectar_snapshot(), DESPUES gates, todo en la misma tx (audit); gate filas_base != len(data). svc_nextjs NO existe en DEV (pg_roles, db02): la rama GRANT quedo sin ejercitar en DEV, se mide en PROD antes de aplicar. Restriccion del puntero de lectura (coder03, rama movilba-269-reader-snapshot-pointer @ 65ddfe76, 4 archivos +41/-6, LATEST_PROJECTED_SNAPSHOT_ID en rutap-historial.ts:61 usado en 6 sitios): la proyeccion COMMITEA ENTERA en una tx o los lectores publican medio snapshot; soft-delete de la ultima fila import del tip retrocede el puntero un snapshot. Control no vacuo en DEV 00:20: AA033TK alta 04/09 y PMI013 vuelven con el puntero nuevo, 0 filas con el viejo.
-
coder03-mba-l-cc, rama movilba-269-reader-snapshot-pointer (worktree movilba-web-worktrees/movilba-269-reader-snapshot-pointer), base origin/dev 6924c07f. NO deployada: espera al proyector y a las dos vistas de db03-mba-l-ca. 65ddfe76 fix(MOVILBA-269): los seis lectores resuelven el ultimo snapshot PROYECTADO, no el ultimo importado. 4 archivos +41/-6. UNA definicion, seis usos: LATEST_PROJECTED_SNAPSHOT_ID en src/repositories/rutap-historial.ts:61, usado en rutap-historial.ts:140, vehiculos.ts 878/933/1047, src/app/api/vehiculos/[id]/entidad/history/route.ts:55 y .../linea/history/route.ts:58. Sin restos de max(id) FROM rutap.snapshots en src/. Auditado por audit-mba-l-cc a las 00:25: seis sustituciones confirmadas, un hallazgo BLOQUEANTE (deploy como unidad con las vistas, item 4 del spec). 2175c703 docs(MOVILBA-269): el borrado_en del puntero es la definicion y no un riesgo, mas la nota de transaccion unica del proyector. Solo comentario, sin cambio de comportamiento; responde a los items 2 y 3 de audit.
-
Applied coder02 audit resolution: raw-load/latest checks precede projector; assert filas_base and filas_proyectadas against input length; projector owns app-row/other-snapshot count preservation per db02 contract. Missing-function message names DEV migration and warns PROD needs its own artefact. Header forbids batched commits. MOVILBA-59 caveat corrected: svc_nextjs does not exist on DEV (pg_roles measured by db02 2026-09-08); GRANT branch and its check unexercised on DEV, must be measured on PROD before apply. Syntax/diff checks pass. Waiting for function-applied confirmation; no rehearsal/deploy yet.
-
PRE-ESTADO del control de acuerdo entre capas, medido por coder03-mba-l-cc en DEV movilba_dev el 2026-09-08 00:29 ART, SELECT solamente, con las vistas todavia en el puntero viejo y la rama sin deployar. Se toma AHORA porque despues del apply es inmedible. Conjunto de vehiculo_id que la CAPA CODIGO (puntero nuevo) resuelve con periodo de import vivo en el tope proyectado, contra el conjunto que publica rutap.v_vehiculo_historial_actual: codigo_sin_vista = 2405 vista_sin_codigo = 4 en_ambas = 2 Los 2405 son, en vehiculos, el desacuerdo que audit-mba-l-cc marco como bloqueante para deployar una capa sin la otra. INVARIANTE POST-APPLY (vistas de db03 aplicadas + proyector corrido): codigo_sin_vista = 0. vista_sin_codigo se queda en la cantidad de vehiculos con filas de app y sin fila de import en el snapshot tope -4 hoy- y NO se espera que llegue a cero. OJO: codigo_sin_vista = 0 se lee igual con las capas de acuerdo que con las dos vacias, asi que solo significa algo al lado de un en_ambas distinto de cero. Misma trampa que un control positivo que pasa por ausencia. Query exacta en el mensaje coder03-mba-l-cc-mts412rapisq a db03/coder02/audit.
-
2026-09-08 00:29 - CONTROL DE ACUERDO ENTRE CAPAS (coder03, DEV 00:29, SELECT-only, ANTES de aplicar): vehiculos con periodo import vivo en el tip proyectado segun la capa de codigo vs los que publica rutap.v_vehiculo_historial_actual: codigo_sin_vista=2405, vista_sin_codigo=4, en_ambas=2. Invariante DESPUES de proyector+vistas: codigo_sin_vista=0 con en_ambas>0 (cero con ambos vacios no prueba nada); vista_sin_codigo queda en los vehiculos con filas app sin import en el tip (4 hoy). Query en el mensaje coder03-mba-l-cc-mts412rapisq. Proyector: bytes 63693859 (db02), ensayo DEV 12 con ROLLBACK: 5388/5388, 322 conflictos (linea 175, entidad 140, emisiones 57, iguales a 11), 13 app, 0 abiertas sin estado, residual {6067,6720}; transcript /data-lezama/movilba/movilba-269-proyectar-snapshot12-dev-REHEARSAL-2026-09-08.log. Orden de ventana: funcion aplicada -> vistas db03 -> push coder03 2175c703 (lock dev01-deploy) -> importer coder-ca.
-
2026-09-08 00:31 - AUDIT PASS (audit-mba-l-cc) sobre acee962a (624 lineas, DEV only), leido de punta a punta. Hallazgos no bloqueantes: (1) el join a vdc de W5 :449-455 no tiene pick deterministico, lo cubre G0 :202-216 (abort por fichas vivas duplicadas): NO debilitar G0; (2) :409/:417 v_lista text reusada como integer, cosmetico; (3) reporte de conflictos :586-589 no filtra borrado_en, solo reporte. Cobertura: todos los gates ejecutaron una vez y PASARON, NINGUNO se vio rechazar; sin ejercitar: rechazo de re-proyeccion, abort por ficha duplicada, gate 1:1, mismatch raw_*/gemelos, cuit NULL, drift de app/otros snapshots, cerradas_con_estado, rama fallida del gate de identidad, y el call site del importer. Orden PROD: 59 PROD cut, 248c, esta funcion, importer. Pendiente: PASS nombrando 63693859 (trim de header comment-only) antes del apply.
-
2026-09-08 00:31 - Clearance movida al re-cut: PASS sobre 63693859 (623 lineas; audit recomputo el sha y releyo W3/W4/W5 y preambulo). acee962a queda superseded, no es ship target. Anclas en 63693859: G0 :201-215 cubre el join de W5 :447-454; v_lista :408/:416; reporte de conflictos :585-588. Cobertura sin cambio. Gate restante para el apply en DEV: no-BLOCK de db03.
-
Importer re-review PASS from audit-mba-l-cc, exact cleared files: tools/rutap-snapshot-import.py sha256 758e1951239823d44ade500d5efd35b9c64ac29a03dc511baf6a0325ce829cb6; docs/migrations/pending-prod-changes.md sha256 76d589825a1ce136a0b8df6d971f5d0050d66a2edca3c287dbdddf58f8a1b33b. All four findings resolved. Still awaiting db02 applied five figures before single existing-MD5 rehearsal and coordinated deployment; importer projection call remains unexercised until next real book.
-
2026-09-08 00:33 - GO de apply en DEV para snapshot 12 sobre 63693859: audit PASS (mts454ipdjl9) + db03 no-BLOCK (mts45oz5ii5m; medido en 12: 0 celdas si/no fuera de SI/NO con btrim en los 8 campos, asi que el defecto de W3 no afecta este libro). db02 aplica y el transcript debe imprimir el SET residual literal (el gate rechaza extras pero no exige que 6067 y 6720 existan). Importer re-review PASS (audit): rutap-snapshot-import.py 758e1951, pending-prod-changes.md 76d58982, +38/-3 off 6924c07f; call site del proyector queda SIN ejercitar hasta el proximo libro real. Followups de db03 a un item aparte.
-
2026-09-08 00:33 - GO de apply en DEV para snapshot 12 sobre 63693859: audit PASS (mts454ipdjl9) + db03 no-BLOCK (mts45oz5ii5m; medido en 12: 0 celdas si/no fuera de SI/NO con btrim en los 8 campos, asi que el defecto de W3 no afecta este libro). db02 aplica y el transcript debe imprimir el SET residual literal (el gate rechaza extras pero no exige que 6067 y 6720 existan). Importer re-review PASS (audit): rutap-snapshot-import.py 758e1951, pending-prod-changes.md 76d58982, +38/-3 off 6924c07f; call site del proyector queda SIN ejercitar hasta el proximo libro real. Followups de db03 a un item aparte.
-
DEV apply 2026-09-08 00:32:33 ART by db02-mba-l-cc: docs/migrations/2026-09-08-movilba-269-proyectar-snapshot-DEV.sql sha256 636938598c36e4b5ff738b1f70b57f1d6de6848c36b5c397e90b705154c7b23c (audit PASS mts454ipdjl9, db03 no-BLOCK), movilba_user@movilba_dev 10.9.10.54 PG 15.17. Created rutap.proyectar_snapshot(bigint) RETURNS TABLE(filas_base, filas_proyectadas, conflictos, filas_app, abiertas_sin_estado) and projected snapshot 12: 5388/5388/322/13/0. Residual via v_vehiculos_hist_ultimo 376 -> exactly [6720, 6067]. Body from dev:2026-09-04-movilba-203 (c9671a92) lines 118-319 inlined over rutap_rows; 333 rule applied in-run. Transcript /data-lezama/movilba/movilba-269-proyectar-snapshot12-dev-APPLY-2026-09-08.log. Not exercised: rejecting branch of every gate; importer call site. db03 followups recorded by coder02: W3 btrim overwrites W1 normaliser (NBSP/SI-accent), chasis lookup latest-only despite bigint arg, typed-twin gate subset-only, min(id) via text var, conflictos report unfiltered by borrado_en. PROD: 59 PROD cut -> 248c -> function -> importer wiring.
-
2026-09-08 00:32:33 - PROYECTOR APLICADO EN DEV para snapshot 12 (db02-mba-l-cc): sha 63693859, movilba_user@movilba_dev 10.9.10.54, PostgreSQL 15.17, COMMIT exit 0, transcript /data-lezama/movilba/movilba-269-proyectar-snapshot12-dev-APPLY-2026-09-08.log. proyectar_snapshot(12): base 5388 / proyectadas 5388 / conflictos 322 (chasis_no_resuelto 5336 pendiente, linea 175, entidad 140, emisiones 57) / app 13 / abiertas_sin_estado 0. Residual antes 376, set literal despues en conexion nueva: [6720, 6067] exacto. Por snapshot (import vivas / con estado): 9=5368/0, 10=5370/0, 11=5388/1600, 12=5388/1602; app 13 sin cambio. Sin ejercitar: rama de rechazo de cada gate, call site del importer. PROD intacto. Siguiente: vistas db03 -> push coder03 2175c703 -> importer coder-ca.
-
2026-09-08 00:33 - 2906c26c (v5.5.58) docs(MOVILBA-269): migracion proyectar_snapshot 63693859 en dev, la misma que se aplico. Conciliacion de conflictos (db02, aceptada por audit): el valor de retorno conflictos=322 son FILAS con normalizacion_estado='conflicto' en el snapshot 12; 5336 son lineas (fila,motivo) incluyendo el motivo pendiente chasis_no_resuelto (5039 solo pendiente + 297 tambien conflicto); 372 son lineas de motivo sobre 322 filas (272x1 + 50x2). Split 322/5039/27 = 5388. Nunca citar 5336 ni 372 como conflictos.
-
RETRACTACION del control de acuerdo de capas como GATE de la ventana - coder03-mba-l-cc, DEV movilba_dev, 2026-09-08 00:35 ART, SELECT solamente. Lo publique a las 00:29 con codigo_sin_vista=2405 y la invariante post-apply codigo_sin_vista=0. Cuando db02 commiteo el proyector del snapshot 12 (00:32:33) el control se volvio VACUO: los dos punteros pasaron a valer 12, o sea coinciden, y la invariante ya da PASS con las vistas VIEJAS en su lugar y 2175c703 SIN deployar. No distingue el arreglo de la ausencia del arreglo. MEDIDO AHORA, antes de las vistas de db03 y antes de mi push: max(id) rutap.snapshots = 12; max proyectado = 12; codigo_sin_vista = 0; vista_sin_codigo = 4; en_ambas = 2407; rutap.v_vehiculo_historial_actual = 2411; public.v_vehiculos_hist_ultimo = 2418; PMI013 y AA033TK una fila de import bajo CADA puntero. Pre-estado a las 00:29 era 2405/4/2 - el que movio el numero fue el proyector, no algo que hayamos shipeado. Lo habia marcado audit-mba-l-cc a las 00:25 (item 4): el control solo se mide mientras exista un snapshot importado y sin proyectar, y esa ventana se cerro sola. GATE DE REEMPLAZO, sobre la FORMA y no sobre la conducta de hoy, porque el estado que discrimina no se puede fabricar sin escribir: 1. Los dos cuerpos de vista releidos con pg_get_viewdef despues del apply: contienen la subconsulta del snapshot proyectado y CERO ocurrencias de max(id) FROM rutap.snapshots. Es el mismo chequeo que corri sobre src/, donde no queda ninguna fuera del comentario explicativo. 2. Paridad como control de regresion y no como prueba: en_ambas se queda en 2407, vista_sin_codigo en 4, codigo_sin_vista en 0. Una caida ahi dice que el apply rompio algo; que se mantenga no prueba nada nuevo. El espejo conserva todos los snapshots vivos (9: 5368, 10: 5370, 11: 5388, 12: 5388), que es por lo que el puntero es estructural y no cosmetico.
-
db02 confirms projector applied and snapshot12 projected on DEV at 00:32:33, migration sha636938598c36e4b5ff738b1f70b57f1d6de6848c36b5c397e90b705154c7b23c: 5388 base/5388 projected, 322 conflicto rows, 13 app unchanged, 0 abiertas_sin_estado. Latest coder02 sequence: db03 views -> coder03 push + layer agreement control -> my idempotent rehearsal and importer deployment. Waiting coder03 release with codigo_sin_vista=0 and en_ambas>0; no importer run yet.
-
2026-09-08 00:36 - VISTAS: audit PASS sobre 772590be (docs/migrations/2026-09-08-movilba-269-projected-reader-views-DEV.sql, 570 lineas, DEV only): unico cambio por vista es la subquery max(snapshots.id) -> max(rutap_snapshot_id) sobre historial import vivo, identica en predicado a LATEST_PROJECTED_SNAPSHOT_ID; ranking/columnas intactas, CREATE OR REPLACE conserva grants y dueño. GATE DE CAPAS VACUO (coder03 00:35, aceptado por audit): desde el commit del proyector ambos punteros resuelven 12, asi que codigo_sin_vista=0/en_ambas=2407 pasa igual con las vistas viejas; no distingue el fix de su ausencia. Se gatea por la FORMA: pg_get_viewdef post-apply con la subquery nueva y CERO 'max(id) FROM rutap.snapshots'; paridad 0/4/2407 solo como linea de regresion. Residual :560-564 es eco, no gate: el operador lo lee a ojo y frena si no es exactamente {6720,6067}. PROD: los bloques $expected$ se reconstruyen desde el pg_get_viewdef de PROD 17.6. GO a db03 para ensayar y aplicar.
-
2026-09-08 00:36:45 - VISTAS APLICADAS EN DEV (db03-mba-l-ca): 772590be recomputado antes del ensayo y del apply, movilba_user@movilba_dev PostgreSQL 15.17, ensayo exit 0 ROLLBACK, apply exit 0 COMMIT. Gate de FORMA en conexion nueva: ambos pg_get_viewdef iguales a los originales salvo el reemplazo del puntero, cero referencias a rutap.snapshots. Paridad 0/4/2407 sin cambio (regresion, no prueba nada nuevo). Residual leido a ojo antes y despues: exactamente {6067,6720}. Sin ejercitar: guardas negativas, comportamiento con punta sin proyectar. PROD intacto; los bloques expected se reconstruyen desde PROD. coder03 liberado para pushear 2175c703.
-
Deployment trigger corrected by coder03: codigo_sin_vista/en_ambas already passes before reader/view changes and is only a regression check, not proof of pointer migration. Await coder03 explicit dev01-deploy lock release after both view bodies are applied and pg_get_viewdef readback confirms zero max(snapshots.id) occurrences. Importer rehearsal/deployment still held; no new DB run.
-
DEPLOYADO por coder03-mba-l-cc: dev bcce69e0..fab6aece, 2026-09-08 00:38 ART, v5.5.60. Ventana bajo el lock dev01-deploy (tomado 00:38, liberado 00:40). Rebase: dev habia avanzado a bcce69e0 (migracion de vistas de db03 ya commiteada), asi que 65ddfe76/2175c703 rebasaron a aaa08003/c5bda58a. Los CUATRO blobs son byte-identicos a los auditados en 2175c703 (sha256 por archivo, IGUAL en los cuatro): cambio el sha, no el contenido. Contenido re-verificado en la rama dev misma: LATEST_PROJECTED_SNAPSHOT_ID en los cuatro archivos, cero punteros viejos fuera del comentario explicativo de rutap-historial.ts. VERIFICADO POR MI ANTES DE PUSHEAR, no sobre la palabra de db03: los dos cuerpos de vista aplicados leidos con pg_get_viewdef en conexion nueva - CERO ocurrencias de rutap.snapshots, DOS del puntero proyectado. Gates del deploy: typecheck OK, health OK intento 1/10, freshness OK sirviendo patch 60. Paridad de capas post-push 0 / 4 / 2407, sin cambio - control de REGRESION unicamente, no prueba nada nuevo (ver la retractacion de las 00:35). FREEZE: no habia. El freeze de dev01 del 2026-09-07 lo levanto Elazar a las 22:52 ART con la condicion con que se tomo. Ademas tres pushes a dev aterrizaron antes del mio esta noche (v5.5.57/58/59) y coder02 secuencio el mio explicitamente. El GO fresco por deploy es regla de PROD; esto no toco prod ni main. NO EJERCITADO: el camino de punta sin proyectar, que es para lo que existe el cambio. No se puede producir sin importar un libro.
-
2026-09-08 00:38 - PUSH coder03 fab6aece (v5.5.60): puntero de lectura LATEST_PROJECTED_SNAPSHOT_ID en 6 sitios (4 archivos), rebase de 2175c703 sobre bcce69e0 -> aaa08003/c5bda58a con los 4 blobs byte-identicos a lo auditado. Gates: typecheck OK, health OK 1/10, freshness patch 60. Paridad post-push 0/4/2407 sin cambio (regresion, no prueba). Lock dev01-deploy liberado 00:40 para coder-mba-l-ca. Sin ejercitar: el camino de punta sin proyectar (el que motiva el cambio), solo se produce importando un libro. Freeze dev01 del 09-07: levantado por Elazar 22:52 ART (coder03).
-
2026-09-08 00:40 - AUDIT PASS sobre fab6aece (v5.5.60) en origin/dev, sin hallazgos: git diff 2175c703..c5bda58a toca solo las 3 migraciones SQL y package.json, CERO archivos de src/ difieren; en src/ sobrevive UNA ocurrencia del puntero viejo, dentro del comentario de rutap-historial.ts:44. Clearance movida a fab6aece; la de 65ddfe76/2175c703 queda superseded. Perfil de riesgo de los 4 artefactos de esta noche: el camino de punta sin proyectar (el unico donde los dos punteros discrepan) NO fue ejercitado por proyector, vistas, push ni importer; el primer ejercicio real es el proximo import, con transcript.
-
Audited importer patch hashes 758e1951 / 76d58982 remain unchanged on fab6aece. Authorized repeat rehearsal snapshot12 exit0: IDEMPOTENTE, 5388 Base /47 Hoja2, no writes. Durable redacted transcript: /data-lezama/movilba/movilba-269-importer-rehearsal-snapshot12-2026-09-08.log. Importer projection call-site UNEXERCISED: existing-MD5 exits before projector; next real workbook needed. gitdeploydev.sh refused exit1: .env.local not found in isolated worktree; no commit/push/deploy. Coder02 notified; deploy lock released pending lane handoff.
-
2026-09-08 00:47 - IMPORTER shipeado: 8ea1b0fd (v5.5.61, coder-mba-l-ca): tools/rutap-snapshot-import.py 758e1951 + docs/migrations/pending-prod-changes.md 76d58982 + bump, byte-identicos a lo auditado; audit PASS de re-verificacion en origin/dev (sin .env.local ni artefactos del worktree). Ensayo idempotente autorizado (una repeticion, transcript /data-lezama/movilba/movilba-269-importer-rehearsal-snapshot12-2026-09-08.log): 'IDEMPOTENTE: snapshot 12 ... 5388 filas Base y 47 filas Hoja2. Sin escrituras.', exit 0; sale ANTES del call site del proyector, que sigue sin ejercitar hasta el proximo libro nuevo. Los 4 artefactos de 269 estan en DEV: proyector 63693859, vistas 772590be, lectores fab6aece, importer 8ea1b0fd. PROD: ninguno; cada uno con su cut, guarda, revision y GO. Pendiente: health de dev01 post-deploy.
-
DEV shipped importer 8ea1b0fd0045c9eaa1c68de7834c41d1457e3c38 v5.5.61 via gitdeploydev.sh exit0. Pre-hook/typecheck PASS; dev push and origin sync PASS; health attempt1/10 PASS; freshness patch61 MATCH. Audit post-ship PASS exact importer758e1951 and pending doc76d58982 plus version bump only. Existing snapshot12 rehearsal exit0 IDEMPOTENTE, Sin escrituras, durable transcript /data-lezama/movilba/movilba-269-importer-rehearsal-snapshot12-2026-09-08.log. Projection call-site UNEXERCISED: existing-MD5 exits before projector; first execution next real NEW workbook. PROD untouched. Nonfatal deploy log write warning; gcaba remote unconfigured skipped. Lock released. Next step observe real new-book import with coordinated DB/audit checks.
-
2026-09-08 00:48 - dev01 post-deploy 8ea1b0fd: gitdeploydev.sh exit 0, health PASS 1/10, freshness patch 61 MATCH (coder-mba-l-ca). Lock dev01-deploy liberado. Cadena DEV de 269 completa; queda abierto por: (a) el paso crear_fichas_faltantes para dominios NUEVOS (diseño db03 en este item), (b) call site del proyector sin ejercitar hasta el proximo libro real, (c) PROD: 59 PROD cut -> 248c -> proyector -> vistas (expected desde PROD 17.6) -> importer, cada uno con GO de Elazar.
-
db02 2026-09-08 00:56: crear_fichas_faltantes (db03) depends on MOVILBA-199 (canonical chassis resolver, 52 of 5388 rows resolved on snapshot 12) and MOVILBA-245 (no carroceria resolver exists at all). Both recorded on their own items. Neither blocks the fichas builder: it reproduces the approved-resolver joins over the explicit snapshot's raw rows and reports what it cannot resolve.
-
2026-09-10 DB lane: MOVILBA-435 pre-projection reconciler passed rollback-only DEV rehearsal. Positive run rebuilt snapshot 12 projection inside one transaction, dynamically named/repaired AA013AD and concurrent AC213TA, archive trigger fired, unchanged projector completed 5388 rows with W5 residual 0, then rollback restored state. Negative duplicate-open AA013AD aborted before mutation and rolled back. db02 APPROVED. Function rutap.reconciliar_estado_abierto_snapshot(bigint) then installed permanently in DEV only under lock and verified; no reconciliation/import called and 2026-09-10 11:50 workbook remains unimported. Evidence: /data-lezama/movilba/evidencia/MOVILBA-269/2026-09-10-w5-rollback-rehearsal.md. Coder integration/commit/push pending.
-
2026-09-10 coder shipped MOVILBA-435 importer integration to DEV: commit 2a9c2c2f, version 5.5.142, present on dev/dev and origin/dev. Wrapper typecheck passed; internal health freshness patch 142 and external dev01 health HTTP 200 matched patch 142. DB function was installed first and verified. Worktree clean. New 11:50 workbook remains deliberately unimported pending first real-run acceptance.
-
2026-09-10 post-ship audit PASS for commit 2a9c2c2f: migration, importer reconciler call/gate/logging, ssot-overrides wording, deploy stamp, and v5.5.142 version files match the reviewed diff byte-for-byte; worktree clean. Audit was diff-only (no DB/runtime execution); DB rollback rehearsal and DEV function verification are recorded separately. Real 11:50 snapshot import remains pending.
-
2026-09-10 16:26 ART live DEV SELECT: latest rutap.snapshots remains id 12 (2026-09-07-2350, 5,388 raw and 5,388 projected); 2026-09-10-1150 workbook is not imported. Exact shipped-v5.5.142 --apply command and existing user authorization relayed to db03; db03 is seeking the per-operation DB-write confirmation required by its lane.
-
db03-mba-l-cc
-
db02-mba-l-cc
-
PREMISA FALSIFICADA Y PROVENIENCIA ESTABLECIDA - db02-mba-l-cc, 2026-09-12 04:05, DEV y PROD, solo lectura. 1. El titulo dice que el espejo ancho no tiene escritor para el snapshot 11. Hoy el 11 esta escrito en LOS DOS entornos: DEV tiene rutap.vehiculo_historial_normalizado proyectada para 9, 10, 11 y 12; PROD la tiene para el 11, 5388 filas. 2. Lo que sustituye a esa premisa es mas interesante. PROD NO TIENE rutap.proyectar_snapshot. El schema rutap en PROD son 7 tablas y UNA sola funcion, vh_norm_reject_app_delete. O sea que PROD tiene filas proyectadas de un proyector que ahi no existe. 3. Proveniencia, medida por las columnas de autoria de la propia tabla y no inferida: las 5388 filas de PROD tienen normalizado_por = 'movilba-202', origen = 'import', y normalizado_en = creado_en = 2026-09-07 12:07:46.986446-03, las 5388 en el mismo instante. Ese literal se escribe en docs/migrations/2026-09-03-movilba-202-wide-rutap-history-DEV.sql:223 (y el mismo literal en el de 203, linea 231). Las filas las puso el BACKFILL de la migracion de MOVILBA-202, no el proyector. Y las puso el 09-07, dos dias DESPUES de que el snapshot 11 se importara (09-05 06:57:22), asi que tampoco fueron parte del import. 4. La misma columna cuenta la historia en DEV: snapshot 9 y 11 llevan 'movilba-202', el 10 lleva 'movilba-203', el 12 lleva 'movilba-269'. DEV paso al proyector en el snapshot 12; PROD se quedo en el backfill por migracion. La conclusion honesta es que DEV y PROD no comparten el camino de escritura de esta tabla, y una afirmacion sobre el espejo medida en DEV no vale para PROD. 5. Estadisticas de pg_stat_user_tables en PROD, coherentes con lo anterior: n_tup_ins 10776, n_tup_del 5388, n_live_tup 5388 - se cargo dos veces y se borro una. public.audit_log de PROD no tiene ninguna fila para esta tabla, asi que las columnas de autoria de la tabla son el UNICO testigo que quedo. 6. HALLAZGO LATERAL que toca a MOVILBA-224 y 354, no a este item: DEV tiene 70 filas en el espejo ancho con origen='app' y rutap_snapshot_id NULL - 22 'app-create-colectivo' y 48 'app-editar-colectivo', del 2026-09-11. El espejo ancho YA tiene escritor de aplicacion en DEV, y origen/normalizado_por SI distinguen escritura de app de escritura de import en esta tabla. Antes de trabajar 224 conviene re-medir sobre que tablas exactamente falta esa distincion. Nada escrito en ningun entorno.
-
db03 re-verified 2026-09-18 04:11: ticket's own scope (parameterized rutap.proyectar_snapshot, integrated crudo->espejo ancho->aplicacion sequence) shipped MOVILBA-435/v5.5.142; DEV+PROD both current, zero-lag, both processed 2026-09-17-0942 book end-to-end per db02/audit re-verification. No gap found in ticket text beyond what shipped.
task
5w ago by wi-cli-venus
4w ago
2026-09-18 07:11