El reporte historico emite el contrato de maquina en dos campos de catalogo

Sub-tickets

Activity

• audit-mba-l-cc created · 1w ago
• coder03-mba-l-cc priorityChanged · 1w ago
  1
• coder03-mba-l-cc assigned · 1w ago
  coder03assistant-mba-l-ca / solo
• coder03assistant-mba-l-ca statusChanged · 1w ago
  Starting the scoped three-projection fix after handing MOVILBA-761 to audit.
• coder03assistant-mba-l-ca note · 1w ago
  Implementation ready for audit (2026-10-08). Historical-report route only: unidadPropulsora, carroceriaCategoria, tipoMotor now project nombre_mostrable; the eight-field MOVILBA-465 fix remains intact. No borrado_en filter added. rutap.v_export_libro and its applied MOVILBA-574 machine-value decision were not changed. Source pins in src/lib/rutap-history-values.test.ts require all three nombre_mostrable projections and reject their prior valor_opcion projections, giving a regression assertion that should fail against the pre-change route. No tests/lint/typecheck run before audit per coder handoff rules; git diff --check passed. Exact SHA-256: src/app/api/reportes/vehiculos-historico/route.ts 2e79efb2e1dc2f62fc1ea1ac5587531653163008af258bdadfe0bac74ab38107; src/lib/rutap-history-values.test.ts ab534089e7295345bb55c80c68f5307738007ae94b0a3e83284ecd35cd9489f6.
• coder03assistant-mba-l-ca proposal · 1w ago
  Read-only fix plan: keep the change confined to src/app/api/reportes/vehiculos-historico/route.ts and its source pin in src/lib/rutap-history-values.test.ts. Change unidadPropulsora to op_unidad_propulsora.nombre_mostrable while retaining the qualified motor/unidad_propulsora join; change tipoMotor to op_tipo_motor.nombre_mostrable while retaining its period emissions-catalog ID join; change carroceriaCategoria to op_categoria_regulatoria.nombre_mostrable while retaining the existing qualified ID/text join exactly as-is. Do not add borrado_en to that join. Do not change rutap.v_export_libro or its applied MOVILBA-574 valor_opcion decision. Update the three source pins to require the display-label projections and add a negative pin rejecting valor_opcion on these three aliases. Audit should demonstrate the source test fails against the pre-fix route and passes on the candidate; emitted values remain unexercised because the test only reads SQL source. This plan matches the current candidate, which is already handed to audit; no further checkout edit is made while coder04 holds the lock.
• coder03assistant-mba-l-ca titleChanged · 1w ago
  El reporte historico emite el contrato de maquina en dos campos de catalogo
• coder03assistant-mba-l-ca note · 1w ago
  Narrowed per PM decision 2026-10-08: only unidadPropulsora and carroceriaCategoria change to nombre_mostrable in the historical-report route. tipoMotor stays on valor_opcion; restored the original MOVILBA-535 comment and test pin because id 174's nombre_mostrable='Eléctrico' conflicts with the canonical book spelling 'Electrico' on 57 PROD rows, and that applied choice requires Elazar's decision to revisit. No comment churn, no borrado_en predicate, no rutap.v_export_libro changes. Current candidate SHA256: route 738da661e183e719c6f5d77f256cc71bc5dbad95cb97b65683a37e064b4e3364; test edb79a1ed97cc643c200b8c9dcdc93c56e7d68a3bd6ffb3ffe28be49ef9371ce. git diff --check passed; lint/typecheck/tests left for audit per handoff protocol. Emitted values remain unexercised; test pins source projections only.
• audit-mba-l-cc audit-finding · 1w ago
  # MOVILBA-765 correction by audit-mba-l-cc, 2026-10-08, signed by this event's createdAt **Item 2 of my own description, `tipoMotor`, is WITHDRAWN.** The objection raised against it is correct and I verified it against the shipped bytes rather than accepting it: `git show HEAD:src/app/api/reportes/vehiculos-historico/route.ts` carries, immediately above the projection: -- MOVILBA-535: el catalogo motor/estandar_emisiones usa valor_opcion con la grafia canonica -- del libro para E3/E5/GNC (17='E3', 59='E5', 173='GNC'). Tipo_Motor se emite desde ese -- catalogo, nunca desde raw_tipo_motor; el texto original queda solo como evidencia historica. -- La opcion 174 difiere en nombre_mostrable ('Eléctrico') y valor_opcion ('ELECTRICO'); -- el libro escribe 'Electrico' sin tilde y no habia filas actuales con 174 al medirse. So for THIS catalog `valor_opcion` is not the machine contract — it is the DECIDED rendering, chosen on 2026-09-22 because it carries the book's spelling. My description cited only the `:52` line of that block ("catalogo, nunca desde raw_tipo_motor") and missed the decision recorded three lines below it. **That is the same defect I have been grading in others: reading one line of a comment block instead of the block.** `tipoMotor` must not be flipped to `nombre_mostrable`, and the 535 comment must not be deleted. **What survives of item 2 is one measured fact, and it is not a defect either.** The comment's own premise is now stale. Measured by me in PROD over all 5558 rows of `rutap.vehiculo_historial_normalizado`: `estandar_emisiones_id` is 4006 on id 59 (`E5`/`E5`), 874 on 17 (`E3`/`E3`), 621 on 173 (`GNC`/`GNC`) and **57 on id 174** — the one id where the two spellings differ, and the id the comment says had "no filas actuales ... al medirse". There are 57 today. That changes the factual basis of 535's choice, so whether 535 is now reversed is a DECISION for Elazar, not a defect for this item; routing it to him is already in hand on the wire. Until he answers, `valor_opcion` stands here. **Items 1 and 3 stand unchanged, re-checked just now against the shipped file:** - `:35 unidadPropulsora` — the only comment above it (`:39-40` of HEAD) says catalog IDs are authoritative over raw text. **There is no MOVILBA-535-style decision for `motor/unidad_propulsora`**, so the defect stands: 57 of 5558 rows on id 37 emit `ELECTRICO` where the label is `Eléctrico`. - `:47 carroceriaCategoria` — 5558 of 5558 rows on id 72 emit `M3` where the label is `M3 - Colectivos`. Nothing in the file or in `docs/migrations/` decides otherwise for this campo; MOVILBA-709's comment at `:44-46` is about ID-over-raw-text, not about which catalog column is emitted. So this item's scope is now **two projections, not three**, and the deletion of the 535 comment block is not part of it. My verdict on the narrowed SHA will be scoped per hunk for exactly the reason raised: a PASS by intention would not have seen a comment deletion inside a hunk whose stated purpose is a label change.
• audit-mba-l-cc audited · 1w ago
  audit pass: PER HUNK, 5 hunks at -U0 on route.ts 738da661 and the test edb79a1e, re-hashed by me before and after the gates: route :35, route :47, test :144, test :147, and the new assert. No sixth hunk - tipoMotor and the MOVILBA-535 block measured untouched. Supersedes 2e79efb2, which I did not verdict.
  payload

  {"scope":"PER HUNK, 5 hunks at -U0 on route.ts 738da661 and the test edb79a1e, re-hashed by me before and after the gates: route :35, route :47, test :144, test :147, and the new assert. No sixth hunk - tipoMotor and the MOVILBA-535 block measured untouched. Supersedes 2e79efb2, which I did not verdict.","outcome":"pass","evidence":"PASS on 738da661 / edb79a1e, per hunk; full body in the audit-finding.\n\n5 HUNKS AT -U0, ALL FIVE NAMED: route :35 unidad_propulsora and :47 categoria_regulatoria flipped to nombre_mostrable, test :144 and :147 pins updated, and the new assert at :165-169. NO sixth hunk.\n\nTHE WITHDRAWN THIRD IS MEASURED UNTOUCHED, which a PASS by intention would have missed: route :55 is still op_tipo_motor.valor_opcion AS \"tipoMotor\" and grep -c MOVILBA-535 is 1, so the rationale survives.\n\nTHE NEW CONTROL WAS SEEN TO FAIL: git show HEAD:route.ts gives 2 hits for the alternation and the assert FAILS; the candidate gives 0 and passes. Reverting either ONE field fails it. test:source prints the file executing.\n\nGATES, RUN BY ME: eslint 0 on both files, typecheck 0, test:source 66/66, test:tools 118/118, with drizzle/schema.ts at f34b4bea before and after.\n\nWHAT CHANGES, measured in PROD over all 5558 rows: unidad_propulsora_id is 4875 on 124 and 626 on 157, where both columns agree, and 57 on 37 (ELECTRICO, now accented), so 57 rows change; carroceria_categoria_id is 5558 of 5558 on id 72 (M3, now \"M3 - Colectivos\"), every row.\n\nTHE (BORRADO) SUFFIX QUESTION IS ANSWERED, NOT LEFT OPEN: id 72 is soft-deleted and MOVILBA-123, applied in both bases today, gives 12 public views a '(borrado)' marker - but its header :37-42 excludes vehiculo/categoria_regulatoria entirely, since marking 5558 rows would teach the operator to ignore the marker, and says a future view projecting it does NOT get the CASE. The plain label is decided.\n\nNOT EXERCISED: no test runs the SQL - all five hunks assert over source text, so the labels are derived, not observed; no fixture, live request, XLSX or PDF; the other three surfaces unmeasured; the book mirror still emits valor_opcion for unidad_propulsora by 574's applied decision and must stay so; lint:strict and next build not run. The tree carries 20 modified files from several lanes and the three suite gates are whole-tree, so only eslint is scoped to 765.","reportRef":null}

• audit-mba-l-cc audit-finding · 1w ago
  # MOVILBA-765 @ 738da661 — audit verdict: PASS, scoped per hunk. 5 hunks at -U0, all five verdicted audit-mba-l-cc, under the hub lock `gates-checkout-movilba-web` (acquired for this run; bare `locks()` returned an empty list before the acquire). src/app/api/reportes/vehiculos-historico/route.ts 738da661e183e719c6f5d77f256cc71bc5dbad95cb97b65683a37e064b4e3364 src/lib/rutap-history-values.test.ts edb79a1ed97cc643c200b8c9dcdc93c56e7d68a3bd6ffb3ffe28be49ef9371ce Both re-hashed by me before and after the gates, unchanged. The producing lane ran no gates; I ran them. Supersedes `2e79efb2`, which I did not verdict. ## 1. Per-hunk census — 5 hunks at `-U0`, named individually `git diff -U0` on the two files, which is the count that does not merge adjacent hunks: | # | file:line | hunk | verdict | |---|---|---|---| | 1 | route.ts:35 | `op_unidad_propulsora.valor_opcion` → `.nombre_mostrable` | PASS | | 2 | route.ts:47 | `op_categoria_regulatoria.valor_opcion` → `.nombre_mostrable` | PASS | | 3 | test.ts:144 | existing projection pin updated to `nombre_mostrable` | PASS | | 4 | test.ts:147 | existing projection pin updated to `nombre_mostrable` | PASS | | 5 | test.ts:165-169 | NEW `assert.doesNotMatch` over the two aliases | PASS | **There is no sixth hunk.** The diff is exactly these five: no comment deletion, no comment rewrite, no churn on the file shipped minutes earlier. Verified by reading the whole `-U0` diff, not by trusting the summary. ## 2. The withdrawn third projection is demonstrably untouched `tipoMotor` was withdrawn from this item by my own correction event on it. Measured in the candidate tree, not assumed: route.ts:55 op_tipo_motor.valor_opcion AS "tipoMotor" <- unchanged grep -c "MOVILBA-535" route.ts -> 1 <- the rationale block survives That is the specific thing a PASS-by-intention would have missed, so it is measured and stated. ## 3. The new control was SEEN TO FAIL git show HEAD:...route.ts -> 2 hits for /op_(unidad_propulsora|categoria_regulatoria)\.valor_opcion\s+AS/ assert.doesNotMatch FAILS the candidate tree -> 0 hits, passes Alternation over both aliases, so reverting either ONE field fails it. The file is genuinely executed: `pnpm test:source` prints `✔ src/lib/rutap-history-values.test.ts (354.798767ms)`. ## 4. Gates — run by me | gate | result | |---|---| | `eslint` on both files | exit 0 | | `pnpm typecheck` (`next typegen` + `tsc --noEmit`) | exit 0 | | `pnpm test:source` | 66/66, exit 0 | | `pnpm test:tools` | 118/118, exit 0 | `drizzle/schema.ts` was `f34b4beaf82f1522f94af2e0c4c8fcba43a3c0c9c339e7402ccf72b57df7f20b` before and after, so this run is not the one that had to be repeated on MOVILBA-465. **Coverage boundary that belongs in this verdict:** the working tree carries 20 modified files from several lanes (`src/actions/contact-info.ts`, `src/app/vehiculos/page.tsx`, `src/actions/audit.ts` and others). `typecheck`, `test:source` and `test:tools` are whole-tree, so their green covers that whole tree as it stood, and the two 765 files are the only ones I verdict. A later change to any other modified file invalidates these three figures; the eslint run is the only one scoped to 765 alone. ## 5. The labels these two hunks now emit, measured in PROD over all 5558 rows - `unidad_propulsora_id`: 4875 on id 124 (`GO`/`GO`), 626 on 157 (`GNC`/`GNC`), **57 on 37** (`ELECTRICO` → now `Eléctrico`). So 57 of 5558 rows change what they emit; 5501 are unaffected because the two columns are equal for ids 124 and 157. - `carroceria_categoria_id`: **all 5558 rows on id 72** (`M3` → now `M3 - Colectivos`). Every row of the report changes on this field. No MOVILBA-535-style decision exists for either campo: the only comment above `:35` is the generic "catalog IDs are authoritative over raw text" at HEAD `:39-40`, and MOVILBA-709's note at `:44-46` is also about ID-over-raw-text, not about which catalog column is emitted. **The `(borrado)` suffix question is raised and answered, not left open.** I grepped `docs/migrations/` for these two campos and found `2026-10-08-movilba-123-sufijo-borrado-vistas-PROD-Y-DEV.sql`, applied in both bases TODAY, which gives 12 `public` views a `left(nombre_mostrable,40) || ' (borrado)'` marker for soft-deleted options. Since id 72 is soft-deleted and this hunk starts emitting its `nombre_mostrable`, the obvious next question is whether this route owes that marker too. **It does not, by that migration's own decision**, which I quote from its header `:37-42`: `vehiculo/categoria_regulatoria` is excluded from the suffix entirely, because all 10 of its options are deleted and marking 5558 rows would teach the operator to ignore the marker — MOVILBA-546 left that catalog deliberately retired-but-authoritative — and the header states that if a future view projects it, "el CASE no se le agrega y se cita esta linea". `M3 - Colectivos` with no marker is therefore the decided rendering. No question for Elazar here. ## 6. NOT EXERCISED — part of the verdict - **No test executes the SQL.** All five hunks' assertions are regexes over the query's SOURCE TEXT. That the report now emits `Eléctrico` and `M3 - Colectivos` is a DERIVATION from §5's catalog measurement, not an observed response body. No fixture, no live request, no XLSX or PDF inspected. - **The `borrado_en` question is settled, not re-opened**: `categoria_regulatoria` is wholly soft-deleted and the join deliberately does not filter it (`.claude/rules/catalogos.md:23`). This diff does not change the join, and a filter must not be added. - **The three other surfaces of these two fields are unmeasured by me** (vehicle page, edit form, JSON API). This verdict covers the historical-export route. - The book mirror `rutap.v_export_libro` still emits `valor_opcion` for `unidad_propulsora` by the applied decision in MOVILBA-574's migration header. Unchanged here, and it must stay that way. - `pnpm lint:strict` not run (baseline-red on vendored `public/scalar`, and on no ship path); `next build` not run.
• coder03assistant-mba-l-ca note · 1w ago
  Cross-surface source census (read-only, 2026-10-08; no live DB/value execution). Ficha and per-vehicle PDF share VehiculoService.findById -> repositories/vehiculos.ts:501-523. unidadPropulsora comes from v_vehiculos_detalle; drizzle/schema.ts:2324 projects op_propul.nombre_mostrable (label). carroceriaCategoria is a separate scalar query at repositories/vehiculos.ts:511 selecting o.valor_opcion; rendered in page.tsx:1399-1401 and reused by ficha PDF page.tsx:850-853. So ficha/PDF: unit label OK, category still machine value. Bulk XLSX/PDF at api/export/route.ts:34-39 uses fetchParqueMovilExportRows (services/parqueMovilExportService.ts:5-8), sharing lib/exports/vehiculos.ts:107-159. Unit comes from v_vehiculos_export; drizzle/schema.ts:3790 projects op_propul.nombre_mostrable. Category is independently selected as o.valor_opcion at lib/exports/vehiculos.ts:138-148 and mapped at :154-158. Both bulk XLSX/PDF therefore emit category valor_opcion but unit label. The API-key /api/v1/exports/vehiculos route is XLSX/CSV and uses the same builder (route.ts:1-6, 66-70). Parque JSON detail/search routes are app/api/v1/parque/vehiculos/[id]/route.ts:11-20 and search/route.ts:11-17; both use findParqueVehiculos, whose SELECT at repositories/parque-movil.ts:213-240 does not select either field, so neither is emitted in that JSON contract. Census identifies two category query sites to consider (one shared by ficha+individual PDF, one by bulk XLSX/PDF); no third API JSON fix. No edits made.
• researcher-mba-l-cc note · 1w ago
  2026-10-08T19:52:23-03:00 / 2026-10-08T22:52:23Z researcher-mba-l-cc Censo estatico de las otras superficies para unidadPropulsora/carroceriaCategoria, docs/reference/movilba-765-other-surfaces-census.md, sha256 123cc32a06f89b808d4b2a3ef23e17a6f2aa66600a5be6f7bf6c550caf94189a. Solo lectura, ningun arreglo. No son tres superficies, son dos reales mas una que no publica el campo: ficha, y XLSX/PDF/CSV export + /api/v1/exports/vehiculos (MISMO builder, src/lib/exports/vehiculos.ts, no dos codigos distintos). /api/v1/parque/vehiculos/[id] no expone ninguno de los dos campos (confirmado contra data-contract.md). carroceriaCategoria: CONFIRMADO ROTO en las dos superficies reales, mismo patron SQL o.valor_opcion en dos archivos - src/repositories/vehiculos.ts:511 (ficha) y src/lib/exports/vehiculos.ts:140/157 (export). No es una correccion, son dos. unidadPropulsora: NO SE PUDO MEDIR por codigo en ninguna de las dos - en la ficha sale de la columna unidad_propulsora de la vista v_vehiculos_detalle (src/repositories/vehiculos.ts:501-524), en el export de la vista v_vehiculos_export (src/lib/exports/vehiculos.ts:117); las dos son un select pelado sobre la vista entera, la resolucion (si existe) vive en el CUERPO de la vista, no en el repo. Hace falta pg_get_viewdef en las dos bases, carril db - no lo hice yo. El alcance final (1 campo en 2 archivos, o 2 campos en 2 vistas + 2 archivos) lo decide esa medicion de vista, no esta nota.
• db03-mba-l-cc note · 1w ago
  db03-mba-l-cc, 2026-10-08, server clock 19:56:24-03 PROD / 19:56:4x-03 DEV. The view-body measurement researcher left open. Read-only, no fix. Instrument tools/movilba-765-censo-vistas-unidad-propulsora.sql sha256 a75c0b78, report docs/reference/movilba-765-censo-vistas.md sha256 6677c69a. VERDICT: unidadPropulsora is NOT broken on either surface. v_vehiculos_detalle and v_vehiculos_export both project nombre_mostrable, with the MOVILBA-123 '(borrado)' suffix CASE, and the live population confirms it - both views return 'Eléctrico', not 'ELECTRICO'. So the cross-surface scope closes on the narrower of researcher's two options: only carroceriaCategoria remains, in src/repositories/vehiculos.ts:511 and src/lib/exports/vehiculos.ts:140/157. Nothing to change in the views. Both are plain views (relkind='v'), not materialized, in both bases - no pending REFRESH could be hiding an older body. Bodies read with pg_get_viewdef(...,true) and byte-identical between PROD and DEV, which is assertable here because I compared digests of the SAME string: v_vehiculos_detalle md5 5831c038, 121 lines, 6600 bytes; v_vehiculos_export md5 a6dfba7a, 122 lines, 7007 bytes. That is the result, not the assumption - a body diff across 17.6 vs 15.17 normally measures the deparser. Pattern control: nombre_mostrable|valor_opcion matches 16 lines in detalle and 25 in export, same figures in both bases, over 121- and 122-line bodies. The ONLY valor_opcion line in either view is a predicate, not a projection - WHERE o.grupo_nombre='vehiculo_historial' AND o.campo_nombre='tramite' AND o.valor_opcion='ALTA' AND o.borrado_en IS NULL, resolving fecha_alta in export. Comparing valor_opcion against a catalog constant to pick a row is the correct shape. What the views actually return. PROD, both views identically: GO 2028, GNC 359, Eléctrico 37. DEV, both views identically: GO 2045, GNC 372, Eléctrico 38, blank 12, Biodiésel 1, Nafta 1. Discriminant control: of the ten motor/unidad_propulsora options only ids 124 (GO) and 157 (GNC) have valor_opcion = nombre_mostrable, so ONLY rows on another id can distinguish a correct view from an incorrect one - 37 rows in PROD, 52 in DEV. The 2387 PROD rows on 124 and 157 prove nothing either way, and that belongs in the verdict. DEV's Biodiésel and Nafta are the options MOVILBA-371 measured as taken by two vehicles users CREATED in DEV - protected divergence, not drift. Denominators, so they do not get mixed: these views are per VEHICLE - 2424 rows in PROD, 2469 in DEV - while the item's 5558 counts rutap.vehiculo_historial_normalizado, one row per period. Both correct, not comparable. On the history table the field censuses PROD 124=4875, 157=626, 37=57 and DEV 124=4971, 157=662, 37=59, NULL=32, 31=2, 33=1. The 57 is exactly audit's figure for the historical-report route, already fixed and PASSed; the views were never in that group. carroceria_categoria does not pass through these views: neither view has a single column whose name names the category, zero of zero, in both bases. Verified from the database, not inferred from the repo, and it matches researcher's code reading. SIN EJERCITAR: no live HTTP request and no XLSX/PDF generated - that the ficha and the export paint 'Eléctrico' is measured on the view they both query, not observed in a response or a file. I did not verify that the selects at repositories/vehiculos.ts:501-524 and lib/exports/vehiculos.ts:117 project the column outward without renaming or overwriting it; that is code and researcher measured it. drizzle/schema.ts was deliberately NOT used as a source - it is a lossy mirror of view bodies; the two lines the earlier notes cite (:2324, :3790) agree with what I measured, but that agreement does not make them evidence. Other views projecting this catalog were not censused. tipo_motor and marca_motor appear in v_vehiculos_export and were not measured - tipoMotor is withdrawn from this item by audit's 22:30Z correction.
• coder03assistant-mba-l-ca completed · 1w ago
  Closed after shipment in patch 211 on PROD, DEV, and pod. Historical report route projections were changed and audit PASSed; per the 2026-09-24 rule, the report now uses catalog labels. The separate view-body census confirmed unidadPropulsora already emits nombre_mostrable and needed no change. No route HTTP, workbook/PDF output, or SQL was exercised in this item; do not interpret the code-only verification as live export execution.