73 de 92 pares de chasis del libro no resuelven ni por resolver ni por catalogo vivo: el resolver de MOVILBA-199 se sembro con tres casos y no siguio

Sub-tickets — 0/1 done

Activity

• wi-cli-venus created · 5w ago
• wi-cli-venus note · 5w ago
  RE-ENCUADRE. Medido por db02-mba-l-cc, senalado por Elazar en CLI. La frase con la que abri este item - que no existe mapeo libro->catalogo de chasis al que apelar - es FALSA y no se puede usar como fundamento. EXISTE: rutap.chasis_resolver y rutap.unidad_propulsora_resolver (MOVILBA-199, migracion 2026-09-02, aplicada en DEV y PROD). En DEV viven 9 filas de chasis y 4 de propulsion. LO QUE SIGUE EN PIE es la conclusion, no el razonamiento: 'MT 15.0 V 5500' no tiene fila en ese mecanismo. Y la doctrina del propio archivo ya cubre lo que hizo el ensayo - su cabecera dice que toda variante equivalente necesita una fila de resolver evidenciada por separado, y que los datos del resolver son PROCEDENCIA, no una lista de alias adivinados. Cinco de las nueve filas vivas son exactamente eso: estado 'pendiente', chasis_id NULL, con evidencia del tipo "el candidato 114 es OH 1718 L-SB/62, pero ninguna evidencia revisada prueba esa equivalencia de sufijo omitido". Una esta en estado 'conflicto'. ENTONCES EL DESENLACE CORRECTO PARA FB444EP no es un hallazgo nuevo ni un vinculo guardado al chasis 130: es una fila PENDIENTE de resolver que nombre AGRALE / MT 15.0 V 5500 con su dominio como evidencia. Eso es trabajo rutinario de MOVILBA-199, con forma ya establecida. LO UNICO QUE ES PARA EUGENIA es si las seis grafias de MT 15.0 son un modelo o varios. Ya esta como pregunta 11 del tracker. Todo lo demas de este item se resuelve adentro del mecanismo que ya existe. QUEDA EN PIE Y NO SE MIDIO: si la cobertura de 0.5% del resolver de chasis (102 de 21514 filas) es su alcance previsto o un backfill que se freno.
• wi-cli-venus titleChanged · 5w ago
  MT 15.0 V 5500 necesita una fila pendiente en rutap.chasis_resolver (MOVILBA-199); para Eugenia solo queda si las seis grafias son un modelo o varios
• wi-cli-venus note · 5w ago
  RE-ESCALADO. Medido por db02-mba-l-cc, DEV only, SELECT only. La pregunta abierta que deje anotada - si el 0.5% de cobertura era alcance previsto o un backfill frenado - esta contestada, y contesta EN CONTRA de la lectura rutinaria de este item. NO ES NINGUNA DE LAS DOS: es un resolver que se sembro con tres casos y nunca se siguio. No hay nada trabado; el trabajo no se hizo. DENOMINADOR: 92 pares distintos (raw_chasis_marca, raw_chasis_modelo) en el libro, sobre las 21514 filas origen='import', comparando trim+mayusculas de los dos lados. - 3 pares tienen fila de resolver APROBADA (los tres sembrados por MOVILBA-199). - 6 pares tienen fila NO aprobada (5 pendiente, 1 conflicto). - 83 pares no tienen fila de resolver. Y sobre esos 83, la pregunta que evita repetir el error anterior - una fila faltante solo es hueco si el par no resuelve ya de forma directa: - 10 matchean un chasis VIVO exacto por modelo + fabricante. No necesitan nada; el resolver existe para las variantes que NO matchean. - 73 no matchean NI fila de resolver NI entrada viva del catalogo. ENTONCES FB444EP ES UNO DE 73, NO UNO DE UNO. Este item, tal como lo re-encuadre, es correcto en la FORMA y equivocado en el TAMANO: agregar la fila pendiente de AGRALE / MT 15.0 V 5500 y parar deja 72 variantes del libro que van a frenar el ensayo exactamente igual, de a una, a medida que el operador las alcance. Ya paso: EG111AA quedo SIN GUARDAR por 'AGRALE MT 17.0 LE V 6200 6.' - la segunda de las 73 en aparecer, quince minutos despues de la primera. ALCANCE NUEVO: las 73, con FB444EP como ejemplo trabajado. La decision por variante sigue necesitando evidencia y la mayoria va a quedar PENDIENTE, y esta bien: una fila pendiente es un desconocido REGISTRADO, y 73 desconocidos registrados son mejores que 73 sorpresas durante un ensayo. LO QUE PUEDE ACHICAR EL NUMERO, y no lo decidimos nosotros: la pregunta 11 del tracker - si varias grafias son el mismo modelo fisico. Si Eugenia dice que si en bloque, las 73 colapsan bastante. Por eso el orden es preguntar primero y sembrar despues. NO EJERCITADO: PROD, si alguna de las 73 es el mismo modelo bajo otra grafia, y el camino del importer.
• wi-cli-venus titleChanged · 5w ago
  73 de 92 pares de chasis del libro no resuelven ni por resolver ni por catalogo vivo: el resolver de MOVILBA-199 se sembro con tres casos y no siguio
• wi-cli-venus note · 5w ago
  RETIRADO DEL TRACKER por Elazar: no es una pregunta para Eugenia. Las dos filas que yo habia agregado a la hoja Para Eugenia - la de las seis grafias de MT 15.0 y el informe de MERCEDES BENZ/AGRALE - se sacaron (snapshots en archivo/2026-09-08-0655-...). POR QUE ESTABAN MAL PLANTEADAS. Si dos grafias de chasis son el mismo modelo es un hecho tecnico del fabricante, no una decision del duenno del libro; y una atribucion de marca cruzada tampoco se le consulta ni se le informa a quien no la puede cambiar. Ademas MOVILBA-200 ya midio la direccion correcta: el libro nombra VERBATIM a las filas de catalogo borradas, asi que la correspondencia se resuelve contra el catalogo y su historia de borrado, no preguntando. Se resuelve del lado nuestro. Nada de esto vuelve a la hoja.
• wi-cli-venus note · 5w ago
  db03 2026-09-08 DEV SELECT-only remeasurement requested by coder02 after366:21514 imported source-linked rows; current actual projector join keys produce204 approved,261 pendiente,4 conflicto,21045 no resolver entry. Resolver currently32 entries=3 approved/28 pendiente/1 conflicto (older9-entry census stale). These are row-weighted counts, not distinct model pairs. Only102 stored chasis_id populated. The other102 approved-but-null rows belong to snapshots9(50) and11(52), tracked separately in367. No new alias, catalog update or history write. Source raw marca/modelo match rutap_rows in all21514. Do not conflate resolver coverage with historical application gap.
• wi-cli-venus note · 5w ago
  coder04 live DEV SELECT: AB126BE6692 chasis_id NULL. No vehiculos.chasis_fabricante_id column exists; manufacturer derives through chassis. 2412 live vehicles,50 with NULL chasis_id. Catalog1721 family contains no exact OH 1721/62; live116 is OH 1721 L-SB/62 under fabricante3 MERCEDES BENZ. v94 diff in ficha removes only optional TypeScript declaration, not rendering. Requested db03 literal-model catalog/resolver/link correction under Elazar GO; no display fallback.
• wi-cli-venus note · 5w ago
  Correction scope: all50 live NULL chassis links, not AB126BE-only. Read-only population grouped by vehiculos.chasis_modelo yields22 literal strings,49 nonblank rows and1 blank ZZ900QA. OH1721/62 occurs on AB126BE/BG/CZ. db03 requested exact source-backed catalog/resolver correction, preserving nonnull links and app edits; db02 asked read-only manufacturer/model population mapping while db03 has not yet replied. No new write executed.
• wi-cli-venus note · 5w ago
  Elazar directs chassis SSOT matching against DB catalog with primary-source research and reusable rules. Confirmed official fleet VIN evidence for AB126BE/BG/CZ and five further Mercedes cases; manufacturer Scania GAS link resolves to GNC sheet. Rules written in coder04 worktree docs/reference/ssot-overrides.md. DB02 asked to implement and apply narrow DEV batch with VIN guards; no DB apply confirmation yet. Literal catalog creation withdrawn. KingLong E/G and Mercedes O500U1723/1826 are distinct variants, not fuzzy aliases.
• wi-cli-venus assigned · 4w ago
  coder03-mba-l-cc / coder
• coder03-mba-l-cc assigned · 2w ago
  db03-mba-l-cc
• coder03-mba-l-cc assigned · 2w ago
  db04-mba-l-ca
• researcher-mba-l-cc note · 1w ago
  Researcher note (2026-10-05). Re-measured the 92-pair inventory (2026-09-08-movilba-398-inventario-modelos-vs-resolver-y-catalogo-DEV.tsv) against current status. ALREADY RESOLVED since this item was opened (398b/398c/398f, applied 2026-09-08, confirmed in bwi history): generic MT17.0LE GO->127, MT15.0LE GO->130, OH1721 family->116, XMQ6127G->117, OH1618 L-SB/55->131, K250UB4X2->121, O500U1826/59->125, ZK6128HG->126, FL BMO368 VERSION1->58, OF1621->122. These account for most of the original 92 pairs by vehicle count. OUT OF SCOPE here (separate ticket): 55 ternas whose only match is a RETIRED catalog row, including generic O500U (471 rows, retired target 10) -- that bucket is MOVILBA-200 rama A, not re-litigated. REMAINING ZERO-TRACE PAIRS (no live match, no retired match, no approved terna) -- proposed row per pair, dominio not available at this grain (evidence file is pair-level, not per-vehicle): 1. AGRALE MT17.0 GNV / 52-MT17.0 GNV CA620 / 52-MT17.0 GNV CA6200 / 52-MT17.0 GNV / 52-MT17.0 GNV CA62 / MT17.0 GNC / MT17.0 GNV CA6200 7.8 6 272 AUTR NEU (GNC, 21 vehicles total) -> proposed chasis 123 (MT17.0 LE GNV, live catalog row, currently no approved terna). Why: GNV/GNC propulsion stated explicitly in book, matches 123's known designation. 2. AGRALE 20-MT17.0 LE V 6000 6.75 226 AUTR (GO,2) + MT17.0 LE V 6200 6. (GO,1) -> proposed 127. Why: same diesel family as the already-approved base pair, just more engine-spec suffix. 3. AGRALE 45-MT17.0 LEE (ELECTRICO-CABA,2) -> proposed 129 (MT17.0 LEe, live catalog row, no terna yet). Why: electric propulsion explicit in book. 4. AGRALE MT15 (GO,1, truncated) -> proposed 130. Why: single-char truncation of MT15.0 LE, same family. 5. MERCEDES-marca-tagged Agrale models: MT15.0 LE V 5500 (1), MT15.0 LE V 5500 6.75 226 AUTR (1), MT17.0 LE V 6000 (1), all filed under marca=MERCEDES BENZ -> marca is a data-entry error (these are Agrale models). Propose: correct marca to AGRALE, then resolves to 130/127 same as correctly-tagged siblings. 6. MERCEDES BMO 368 VESION 1618 (typo VESION, GO,3) -> proposed 131 (OH1618 L-SB/55). Why: same family as correctly-spelled sibling already resolved to 131. 7. MERCEDES FU BMO-368 VERSION 1721 L62CA (GO,1) -> proposed 116. Why: same BMO368/1721 family as base pair already resolved to 116. 8. YUTONG 007-ZK6128HG (GNC,1) -> proposed 126. Why: prefix junk on already-resolved base model. 9. MERCEDES OH 1618/55 (GO,3, no L-SB/55 suffix) -> proposed 131. Why: pattern-consistent truncation, same as resolved sibling. EUGENIA/UNRESOLVED (genuinely can't resolve from book+catalog): - KING LONG XMQ6127E (ELECTRICO,1): not in CNRT catalog at all, no live/retired trace. XMQ6127E is a plausible distinct King Long electric trim (vs XMQ6127G=117, GNC). Needs catalog research/new row decision, not a text-matching fix -- flagging for coder/db, not Eugenia (model identity is not her call per 2026-09-08 ruling). - MERCEDES OH 1718 (GO,1, bare, truncated): ambiguous between OH1718 L/62 and OH1718 L-SB/62, two DISTINCT canonical CNRT models, neither with a live catalog target (both retired-only, MOVILBA-200 scope). 1 vehicle -- recommend VIN-level lookup on that single dominio rather than a blanket text rule. - Remaining spacing variants of O500U and 897-O500UA with zero trace (767- 0 500 U, 767-0 500U, 897-O 500 UA) join the existing retired-id MOVILBA-200 bucket, no new decision needed. Total newly proposed: ~33 vehicles across 9 live-target rows + 2 flagged unresolved. All proposals are catalog-id targets only; no DB writes made by me, db04 applies per standing protocol.
• db04-mba-l-ca note · 1w ago
  2026-10-05 SELECT-only recheck, PROD movilba first (elazar), then DEV movilba_dev (movilba_user). All nine researcher-proposed alias groups from the 18:32Z note ALREADY have approved rutap.chasis_resolver ternas in both bases; no INSERT/UPDATE is justified and no DB write was made. Groups 1/2/3/7/8/9 resolve to proposed live ids 123/127/129/116/126/131 in both bases. Group 4 AGRALE|MT 15|GO is approved to its own live MT 15 catalog row (PROD id134, DEV id140), not proposed MT 15.0 LE id130. Group 6 MERCEDES BENZ|BMO 368 VESION 1618|GO is approved to live BMO 1618 id137 in both, not proposed OH 1618 L-SB/55 id131. Group 5's MERCEDES BENZ-tagged MT variants already point to Agrale ids 130/127, but docs/reference/chasis-equivalencias.md explicitly forbids cross-manufacturer terna repair and records Eugenia's instruction to preserve the declaration per period; do not rewrite the book marca or add a new global alias. The proposed 9-row apply is therefore stale and would regress two catalog distinctions. KING LONG XMQ6127E and bare OH 1718 remain for researcher VIN-level lookup, then Eugenia suggestion if unresolved, per coder03. Query instrument: SELECT fabricante_normalizado,modelo_normalizado,unidad_propulsora_id,estado,chasis_id FROM rutap.chasis_resolver WHERE modelo_normalizado ~ '(MT.?17|MT.?15|BMO|ZK6128|OH 1618)' ORDER BY 1,2,3; SELECT id,chasis_modelo,fabricante_id,borrado_en FROM public.chasis WHERE id IN (123,126,127,129,130,131,134,135,137,140,144).
• db04-mba-l-ca note · 1w ago
  2026-10-05 SELECT-only DEV VIN handoff for researcher: current-period MERCEDES BENZ / OH 1718 / GO is AA247VF, numero_serie_chasis 8AB368187GA145888, rutap.vehiculo_historial_normalizado id315805, snapshot20 fila_excel4813, fecha_alta 2026-08-31. public.v_vehiculos_hist_ultimo selects historial_id315805 (positive current-row control). Current row links to live public.chasis id141 labelled bare OH 1718; prior 'zero catalog trace' is stale, but id141 itself does not disambiguate L/62 vs L-SB/62. Sent to researcher for VIN/manufacturer lookup. No write.
• researcher-mba-l-cc note · 1w ago
  MOVILBA-365 leftover resolved: bare "OH 1718" (dominio AA247VF). db04 (2026-10-05) provided the VIN: AA247VF, numero_serie_chasis 8AB368187GA145888, rutap.vehiculo_historial_normalizado id 315805, snapshot 20 fila_excel 4813, MERCEDES BENZ / OH 1718 / up 124 (GO), fecha_alta 2026-08-31. Currently auto-linked to live chasis_id 141 (bare "OH 1718" label) -- db04 flagged this as possibly too generic and asked whether L/62 vs L-SB/62 is still open. Checked the VIN directly against /data-lezama/movilba/research/chasis/parque-movil-2023-06.pdf (the same official parque movil document used as evidence in MOVILBA-398 for AB126BE/BG/CZ) rather than decoding the VIN structurally -- no documented VIN-decode method exists for this digit range (chasis-equivalencias.md explicitly notes WMI tables don't resolve this kind of case). Found the exact row (pdftotext -layout, line 20949): AA247VF | 2016 | MERCEDES BENZ | OH 1718 L/62 | 8AB368187GA145888 | METALPAR | ... The official document states the model as "OH 1718 L/62" literally, not "OH 1718 L-SB/62". This is the SAME distinction CNRT's own catalog treats as two separate canonical models (chasis-modelo.tsv rows 41/60: BMO 368 1718 L/62 -> OH 1718 L/62, and separately OH 1718 L/62 -> OH 1718 L/62 TRUE, distinct from OH 1718 L-SB/62). PROPOSAL: chasis_id 141 is correctly specific IF its catalog label is "OH 1718 L/62" (matches the official document) and NOT "OH 1718 L-SB/62" or a bare ambiguous label. Whoever applied the auto-link to 141 should confirm 141's stored chasis_modelo text says "L/62", not "L-SB/62" -- if it does, this vehicle is correctly resolved and needs no further action. If 141's label is bare/ambiguous, correct the catalog label to "OH 1718 L/62" per this document, same mechanism as the OH1721 L-SB/62 VIN evidence in MOVILBA-398. No EUGENIA needed -- resolved by official-document VIN match, not Eugenia's call per the 2026-09-08 ruling (model identity is ours to resolve).
• db04-mba-l-ca note · 1w ago
  2026-10-05 catalog label correction candidate, READ/ROLLBACK only so far. Independently inspected /data-lezama/movilba/research/chasis/parque-movil-2023-06.pdf page93 (pdftotext -raw line21067): AA247VF, VIN 8AB368187GA145888, MERCEDES BENZ, OH 1718 L/62, METALPAR. Both PROD and DEV: public.chasis id141 is live MERCEDES BENZ label bare OH 1718, id114 is distinct OH 1718 L-SB/62; id141 is referenced by exactly 1 vehiculo (AA247VF), 1 normalized-history row and 1 approved resolver terna (MERCEDES BENZ, OH 1718, GO). Current history selects AA247VF VIN on both bases (PROD snapshot8 id127093, DEV snapshot20 id315805). Draft /data-lezama/movilba/migration-evidence/2026-10-05-movilba-365-oh-1718-l62-PROD-Y-DEV.sql SHA256 4094d9d854b7b80e4c2f7317b6b3189479c17f6057a1856b3718a6fb536dc842 updates only id141.chasis_modelo to OH 1718 L/62; same file ROLLBACK rehearsal PASS in PROD then DEV. No committed DB write. Sending to audit.
• audit-mba-l-cc audited · 1w ago
  audit pass: catalog label fix, chasis.id=141, one-row
  payload

  {"scope":"catalog label fix, chasis.id=141, one-row","outcome":"pass","evidence":"Guarded by FOR UPDATE lock + exact pre-image check (fabricante=MERCEDES BENZ, old label=OH 1718), sole-reference checks on vehiculos/historial/resolver all keyed to id141+AA247VF+VIN, no other live row collides with target label OH 1718 L/62, postcondition re-verifies both id141 and id114 distinct. Default ROLLBACK; PROD-then-DEV rehearsal PASS per DM. Sourced from official parque-movil-2023-06.pdf p93.","reportRef":null}

• db04-mba-l-ca note · 1w ago
  2026-10-05 applied audit-PASSed SHA256 4094d9d854b7b80e4c2f7317b6b3189479c17f6057a1856b3718a6fb536dc842. PROD movilba COMMIT first; post-read chasis id141=OH 1718 L/62 (1 vehicle AA247VF), id114 remains OH 1718 L-SB/62 (112 vehicles). Then DEV movilba_dev COMMIT; same post-read counts/labels. Only public.chasis.id141.chasis_modelo changed. Repo migration docs/migrations/2026-10-05-movilba-365-oh-1718-l62-PROD-Y-DEV.sql checksum-identical to applied artifact. Next: coder03 SHIP/README/deploy; researcher VIN ambiguity closed by official PDF evidence. KING LONG XMQ6127E remains separate unresolved model research.
• researcher-mba-l-cc note · 1w ago
  MOVILBA-365 leftover: KING LONG XMQ6127E (ELECTRICO, 1 vehicle). RESULT: no manufacturer datasheet exists for this SKU -- it is not a genuine King Long factory designation. Checked King Long's own model list (Wikipedia, CPTDB wiki via search snippet) and manufacturer-adjacent dealer pages. Transit-bus variants that actually exist: XMQ6127G (GNC, already our catalog id 117), XMQ6127GH1, XMQ6127GH5, XMQ6127GHEV4 (hybrid-electric), XMQ6127J, XMQ6127Y. No "XMQ6127E" appears in that list. The only places "XMQ6127E"/"XMQ6127e" appears: a YouTube video title about a Red Santiago (Chile) bus route caption, and a WebSearch synthesized answer (374.65kWh battery, 200kW motor, etc.) whose own cited source links don't name that SKU anywhere -- those sources are for XMQ6127G (GNC dealer pages) and the Wikipedia model list above. The synthesis is not traceable to a real manufacturer source; discarding those specific numbers as unverified, not reporting them as fact. Most likely real identity: either (a) XMQ6127G mistagged by propulsion in the book (same trap as the other GNC/electric sibling pairs already fixed in this ticket), or (b) XMQ6127GHEV4, King Long's actual hybrid-electric trim, never catalogued here. EUGENIA -- genuinely ambiguous, no catalog/research path resolves which of (a)/(b) this vehicle is, and it's one vehicle. Suggested question: "El libro dice KING LONG XMQ6127E para electrico, pero ese modelo no existe en la lista de King Long -- los parecidos son XMQ6127G (GNC) o XMQ6127GHEV4 (hibrido-electrico). Cual es?" Suggested default if no reply: XMQ6127GHEV4 (electric propulsion in the book matches hybrid-electric closer than GNC).
• db04-mba-l-ca note · 1w ago
  2026-10-05 closure check requested at v5.6.163: DB label fix is committed in PROD and DEV, but applied migration docs/migrations/2026-10-05-movilba-365-oh-1718-l62-PROD-Y-DEV.sql is staged A in shared checkout and absent from git history/v163. Asked coder03 to commit applied artifact before closing. Researcher's 18:50Z note also leaves KING LONG XMQ6127E source ambiguity for Eugenia; do not silently count that as fixed by the OH 1718 label correction.
• db04-mba-l-ca completed · 1w ago
  All nine proposed resolver groups remeasured already approved in PROD and DEV; no duplicate aliases applied. OH 1718 ambiguity resolved by official fleet PDF VIN for AA247VF: audit-PASSed one-row chasis 141 label correction committed PROD then DEV, postverified, migration committed as 893bd194/v5.6.164. KING LONG XMQ6127E remains genuinely unresolved and is carried separately by blocked child MOVILBA-708 pending Eugenia tracker answer; no unsupported mapping applied.