Tracker Eugenia 2026-09-17: items abiertos de la hoja Para Elazar

Sub-tickets — 8/8 done

Activity

• wi-cli-venus created · 4w ago
• wi-cli-venus descriptionChanged · 3w ago
  was: Umbrella for every open item in /data-lezama/movilba/import-reports/2026-09-17-1412-todo-rutap-importacion-prestaciones.xlsx sheet 'Para Elazar' (rows 13,20-28 open; rows 1-3,5-8,12,17 marked Corregido/Solucionado but rows 24/25 observed 15/09 after those fixes show the same defects). Children are filed by MECHANISM, not by row.
• wi-cli-venus assigned · 3w ago
  coder03-mba-l-ca / coder
• wi-cli-venus note · 3w ago
  2026-09-23 direct review of BOTH /data-lezama/movilba/import-reports/{todo-rutap-importacion-prestaciones.xlsx,2026-09-23-1128-todo-rutap-importacion-prestaciones.xlsx}, including full Resueltos. Do NOT bulk replace live with downloaded: download Resueltos47 restores older PPF407/AC098EJ unresolved-origin wording; live47 and126/127 record source fixes, DEV evidence only, and live126-128 are absent online copy. Live128 old/current plate direction conflicts with MOVILBA-526 example: H128 AI086HB Baja/AH846SI Alta versus ticket AH846SI old/AI086HB current; clarification requested from db03. Other documentary conflicts: Resueltos G7 says Observaciones column removed but H7 verifies RUTAP values in download; rows37/38 ask again while43/44 withdraw same questions under SSOT rule (do not re-ask); PDF #70-72 are code-only/pending deployment, not verified fixes, and Para Elazar #6-8 explicitly reopen. Resueltos #65 already requires M2/M3, so Para Elazar #14 is implementation/retest, not a new product decision. Date hazard: Bajas D5 text03/07/2026 becomes datetime2026-03-07 in download, D7 text11/08/2026 becomes2026-11-08. Resueltos dates I39:I42 say Aug9 despite Sep8 prose; I43:I49 Oct9 predate current Sep23. Do not use ambiguous dates to choose newest decision. Full coordination questions sent to coder03/db03. Workbooks unchanged.
• wi-cli-venus note · 3w ago
  Elazar explicit instruction 2026-09-23: once an item/question in Para Elazar or Para Eugenia is resolved, document it in BWI FIRST, then move it to Resueltos. Preserve answer/decision, evidence and BWI reference; conflicting/partial items remain open. Clarification to prior review: Resueltos #70-72 tracker wording is not deployment evidence; actual deployment UNMEASURED pending coder git check. Exact blocks A86:I94/A95:I103/A104:I112 cite c4fc618c; related reopened refs414/525/456. Resueltos G7 literally requests stopping column emission in download/API; does NOT authorize dropping populated vdc.observaciones (MOVILBA-537). Export projection and physical deletion are distinct. Cross-file differences do not establish source-generation provenance or automatic precedence. Rows37/38 versus43/44 preserve contrary asking/withdrawal text; no questions moved or retired in this review. New SUBE item10 recorded as MOVILBA-543 before any workbook move; it is unresolved.
• wi-cli-venus note · 3w ago
  2026-09-23 coder deployment clarification (peer report tag coder03-mba-l-cc-mue7rf1svs8g): c4fc618c is not ancestor of CURRENT dev/main and no current branch contains it. This does NOT establish historical never-deployed status. Coder inspected /srv/movilba-web: GenericReport.tsx:136 header contains app name without timestamp; historial-vehiculo.ts:124 esEventoDeBaja exists as successor logic. IMPORTANT SCOPE: these correspond to Resueltos #68 (timestamp) and #67 (baja-as-alta), NOT requested #70-72. #70 repeated fields / MOVILBA-414, #71 original alta date /525, #72 changed-value PDF diffs /456 remain unverified by that report. Actual PDF outputs were not tested. Do not close reopened Para Elazar #6-8 from this evidence. Coder acknowledged G7 export/API column omission is projection, not MOVILBA-537 physical DROP; no DDL authorization follows from G7. Requested remaining scoped code/output checks directly.
• wi-cli-venus note · 3w ago
  ASIGNACION relayada por db04-mba-l-ca 2026-09-23 12:30 ART: Elazar me pide (coder03-mba-l-cc) revisar el trabajo de db04 sobre los trackers Excel y, si no coincido, completar/corregir YO MISMO el vivo todo-rutap-importacion-prestaciones.xlsx. Alcance segun db04: no toco ninguno de los dos XLSX todavia; su entregable es comparacion, decisiones/evidencia sobre 449/454/461/536, el nuevo 543, e instrucciones de flujo en agents/db04-mba-l/AGENTS.md + import-reports/README.md (este ultimo fuera de git). Regla de Elazar que rige el orden: se documenta la resolucion en bwi PRIMERO, recien despues se mueve la entrada COMPLETA a Resueltos y se saca de la hoja de preguntas. Restricciones: leer las dos copias y Resueltos, aclarar conflictos, preservar items parciales y trabajo local, NO sobrescribir en bloque la bajada. db04 no tiene lock del workbook. NO ARRANCADO todavia: estoy a 214k de 250k con orden de compact del monitor y el XLSX vivo es un archivo compartido - se arranca con contexto limpio y tomando el lock del hub sobre el recurso del workbook, no en la cola de una ventana. Queda escrito aca para que sobreviva al compact.
• wi-cli-venus note · 3w ago
  SPLIT completo/parcial entregado por db04-mba-l-ca 2026-09-23 12:31 ART, para la pasada sobre el XLSX. RUTAS: vivo/trabajo = /data-lezama/movilba/import-reports/todo-rutap-importacion-prestaciones.xlsx ; bajada de solo lectura revisada = /data-lezama/movilba/import-reports/2026-09-23-1128-todo-rutap-importacion-prestaciones.xlsx (coincide con la convencion: con timestamp = bajada, sin timestamp = el de trabajo). COMPLETOS, SOLO DOS, los dos con reserva: (1) MOVILBA-454, Para Eugenia#3 fila 5, completo SOLO como aprobacion de FORMATO (D5 'Si, esta ok el modelo.', E5 respondido); NO es verificacion general de los exports; hay que reconciliar D5 en la entrada viva ANTES de mover. (2) MOVILBA-461, Para Eugenia#6 fila 6, completo como criterio de cambio de empresa: alta en la nueva + baja en la anterior. PARCIALES, NO SE MUEVEN: #7 fila 7 (contestado interno-solo=modif y cambio-de-empresa=alta+baja, pero falta revisar la lista de casos y las discrepancias fuente/aplicacion; preservar la respuesta ENTERA y no marcar completo ni #7 ni Para Elazar#26/#27); MOVILBA-536 Para Eugenia#9 fila 9 (la correccion en base esta COMPLETA y verificada, pero el pedido a Eugenia de corregir la FUENTE sigue sin confirmar; se puede archivar el hecho de base con 536 reteniendo el seguimiento de fuente; la OMISION en la bajada no es una respuesta); Para Eugenia#8 fila 8 (trae 'Corregido' del stakeholder pero el chequeo de linea/servicio lo debe db03); #1 y #2 sin contestar. 449 como paraguas NO esta completo: Para Elazar #6-8 reabiertos, #9-21 y #26-28 sin establecer, 543 sin resolver, y las contradicciones de Resueltos sin adjudicar. CONCLUSION OPERATIVA: la pasada sobre el XLSX es mover DOS filas con reserva, no un barrido.
• wi-cli-venus note · 3w ago
  RECONCILIACION XLSX hecha 2026-09-23 ~13:05 ART por coder03-mba-l-cc, con lock del hub sobre todo-rutap-importacion-prestaciones.xlsx. METODO: la copia de trabajo se RECONSTRUYO tomando como BASE la bajada online 2026-09-23-1245 (que trae la estructura nueva: columna Item en para-elazar-hecho, items 11-22 de Para Elazar, respuestas nuevas de Eugenia) y se le INYECTO el contenido que solo existia local. Se diffeo por CLAVE DE FILA (id/dominio + encabezado), no por coordenada: por coordenada daban 113 diferencias en para-elazar-hecho y 50 en regla-alta-modif-baja que NO eran contenido sino una columna insertada y fechas guardadas como texto contra datetime. Snapshot previo: todo-rutap-importacion-prestaciones.PREV-2026-09-23-1300.xlsx. INYECTADO (5 hojas, lo unico que la online no tiene): Para Eugenia fila 9 (AI230WN, B cirilica, MOVILBA-536) reubicada a continuacion del item 8; Convenciones filas 17 y 18 en el bloque de convenciones (Tipo_Servicio/Linea invertidos; B cirilica) y una fila mas en el bloque de divergencias (64/SP en dos filas); Datos 2 filas (AF206GP, AE335EU); Resueltos #78, #79 y #80; y la hoja para-hacer entera, que online no tiene. VERIFICACION sobre el archivo guardado: 0 filas de la bajada online ausentes del merge (por eso el pegado es seguro) y 15 hojas. Las 29 filas de la copia local vieja que no sobreviven son, todas, filas donde la online trae una version MAS NUEVA de la MISMA fila, confirmado casando por id: Bajas 3 (Eugenia contesto donde decia FALTA TU RESPUESTA), Para Eugenia 4 (#3,#6,#7,#8), Para Elazar 4, para-elazar-hecho 14 (corrimiento por la columna Item, ids identicos), Errores cronologia 3 (texto del encabezado y un nombre de columna) y Resueltos 1 (el conflicto #63). PENDIENTE DE ELAZAR, no resuelto en el archivo: Resueltos #63 AC098EJ - la local decia 'Solucionado: el SSOT del 19/09 corrigio la fecha de inicio de 17/07/2025 a 29/12/2025' y la online dice 'Retirada por criterio SSOT - decision de Elazar: importar el SSOT aun con contradicciones'. Gano la online por citar su decision, pero el hecho local (el origen se corrigio el 19/09) es cierto y no se tira. Ademas la online trae en esa fila la fecha 2026-10-09, que esta en el FUTURO: no se propago ni se corrigio, se reporta.
• wi-cli-venus note · 3w ago
  2026-09-23 13:07 ART, por orden de Elazar en CLI: en la hoja 'Para Eugenia' se saca el bloque 'Como leer' (ya no hace falta, la gente sabe leerlo) y se retiran las preguntas 3 (formato de modelo-ideal-exportacion, contestada 'Si, esta ok el modelo') y 8 (AF206GP y AE335EU con linea y tipo_servicio invertidos, contestada 'Corregido'), que pasan a 'Resueltos' como items 81 y 82. La pregunta 9 (AI230WN, B cirilica) queda en 'Para Eugenia' con estado 'IMPORTADO como B, sugerimos revisar el libro'. CORRECCION a la nota anterior de hoy: ahi se afirmo '0 filas de la bajada online ausentes del merge' y eso era FALSO - vuelto a medir sobre el archivo guardado, la hoja 'Para Eugenia' tenia 3 filas de la online ausentes (el bloque 'Como leer', la 3 y la 8). Son exactamente las tres que Elazar acaba de mandar sacar, asi que la ausencia hoy es deliberada, pero no lo era cuando se reporto: el numero se dio por bueno sin re-correr la verificacion despues del ultimo guardado. Estado medido ahora: 'Para Eugenia' 8 firmas de fila, 'Resueltos' 105, y la unica fila local que no sobrevive en 'Resueltos' sigue siendo el conflicto #63 AC098EJ, ya elevado.
• coder04-mba-l-ca progress · 3w ago
  coder04-mba-l-ca | 2026-09-24 04:01 ART. Measured BWI child status: MOVILBA-451, 455, 456 remain open and are now assigned to coder04-mba-l-ca. Tracker workbook ownership is coder03assistant-mba-l-ca; umbrella remains backlog on parked coder03-mba-l-ca and is not a code completion claim.
• coder03-mba-l-cc assigned · 2w ago
  coder03assistant-mba-l-ca
• researcher-mba-l-cc note · 1w ago
  researcher 2026-10-08 13:25 ART: not a single decision - this umbrella's own 2026-09-23 note already states it plainly: Para Elazar #6-8 reopened, #9-21 and #26-28 unestablished, MOVILBA-543 unresolved, Resueltos contradictions unadjudicated. It's tracker bookkeeping across many sub-items, several of which (219/246/387/461/653) are already being handled individually in other batches. No single letter choice fits the umbrella itself.
• coder03assistant-mba-l-ca note · 1w ago
  2026-10-08 tracker reconciliation: after confirming BWI completion and the answered stakeholder responses, moved only Pendientes #87 (MOVILBA-547, Eugenia) and #90 (MOVILBA-288, Eugenia) to Resueltos. Their F-column stakeholder answers are preserved; resolution evidence records deployment and the MOVILBA-547 caveat that a real DEV01 create/edit write was not exercised. Snapshot 42; live SHA-256 3cb6949f2ebc0713f89e7882cc768deaa8400eead53eb50ed4b722d67880c79d. Pre-write archive: /data-lezama/movilba/import-reports/archived/2026-10-08-1417-pre-449-rows-todo-rutap-importacion-prestaciones.xlsx. Remaining open tracker entries were not moved.
• coder03assistant-mba-l-ca note · 1w ago
  Post-write validation detail: the first transformation saved the workbook, then its readback assertion failed only because openpyxl read an Excel date as datetime while the assertion expected date. I did not treat that failed assertion as a pass. A separate read-only check reopened the saved workbook, normalized rows by (bwi, # anterior, stakeholder), verified both moved entries and the 18→16 / 146→148 counts, and compared all other original row values against the pre-write archive; all checks passed. Artifact Tool rendered the changed Resueltos tail for visual inspection. Final live SHA-256 remains 3cb6949f2ebc0713f89e7882cc768deaa8400eead53eb50ed4b722d67880c79d.
• coder03assistant-mba-l-ca statusChanged · 1w ago
  Starting a fresh reconciliation of the current RUTAP tracker against the remaining actionable scope; prior October 8 edits moved only verified rows and preserved open answers.
• coder03assistant-mba-l-ca note · 1w ago
  2026-10-08 tracker reconciliation, pre-write: live Pendientes has five MOVILBA-461 rows (#6/#7/#83/#85 and the AA114VT follow-up), plus rows 572, 713, 714 now backed by done BWI items. 461's latest PROD snapshot11 measurement resolves the 123 same-VIN domain-pass cohort; 572's catalog decision A has post-714 PROD ficha/PDF evidence; 713 and 714 are deployed. I will move only those eight rows to Resueltos after preserving stakeholder fields, correcting stale internal status text, and repairing 713's question text currently misplaced in Nuestra respuesta. Keep 543 deferred, 653/657/658 blocked, 634 partial, 665 pending, 727 awaiting Eugenia, and 244 pending upload.
• coder03assistant-mba-l-ca note · 1w ago
  Post-write reconciliation: live workbook /data-lezama/movilba/import-reports/todo-rutap-importacion-prestaciones.xlsx SHA-256 693a42737d515d3cf7e3e90309e70ec1b20f2d1674d0a0cdb326ee459a292e31. Archived pre-write copy /data-lezama/movilba/import-reports/archived/2026-10-08-1545-pre-449-rows-todo-rutap-importacion-prestaciones.xlsx SHA-256 beebe14e30dea67cac8bb5f6a01df9cd5434ba32b151c9ad98888f518db4bf04. Moved five MOVILBA-461 rows plus 572, 713, 714 to Resueltos (Contestada/Solucionado), resolution date 08/10/2026 from their BWI closedAt in ART. Final counts: 8 Pendientes rows, 156 Resueltos rows; snapshot 48 imported, 1730 cells. Remaining rows preserved: 543 deferred, 653/657/658 blocked, 634 partial, 665 pending, 727 awaiting Eugenia, 244 pending upload. Stakeholder answer cells are preserved; MOVILBA-572's F cell was corrected from placeholder 'Elazar' to the exact recorded answer 'Decidimos OPCION A.' No other stakeholder answer changed. Clarification: earlier pre-write note expected MOVILBA-713's question to be misplaced, based on an older BWI note; the current live workbook already had it correctly in Pregunta, so it was left there and the deployed response was added in Nuestra respuesta. Reopened/rendered after save and corrected display formats for existing date columns and moved-row dates.
• audit-mba-l-cc audited · 1w ago
  audit pass: La escritura de 449: los dos sha256 declarados, el movimiento de las 8 filas y la preservacion del resto, fila por fila contra el archivo pre-escritura. SIN EJERCITAR: snapshot 48 no se verifica desde el libro; el texto de "Hacer la prueba" afirma comportamiento shipeado que no re-verifique.
  payload

  {"scope":"La escritura de 449: los dos sha256 declarados, el movimiento de las 8 filas y la preservacion del resto, fila por fila contra el archivo pre-escritura. SIN EJERCITAR: snapshot 48 no se verifica desde el libro; el texto de \"Hacer la prueba\" afirma comportamiento shipeado que no re-verifique.","outcome":"pass","evidence":"Los dos sha256 coinciden exactos: vivo 693a42737d515d3cf7e3e90309e70ec1b20f2d1674d0a0cdb326ee459a292e31, archivo pre-escritura beebe14e30dea67cac8bb5f6a01df9cd5434ba32b151c9ad98888f518db4bf04. Conteos verificados iterando filas, NO por max_row (el libro vivo devuelve max_row None en modo read_only porque le falta <dimension>, asi que max_row ahi no es un conteo): Pendientes 16 -> 8 datos, Resueltos 148 -> 156. Diff de tuplas de fila completas como multiconjunto: de Pendientes salieron EXACTAMENTE 8 filas - MOVILBA-461 x5, 572, 713, 714 - y 0 entraron; en Resueltos entraron EXACTAMENTE esas 8, con las primeras 12 columnas identicas a las que salieron, y 0 filas preexistentes perdidas o modificadas. Las columnas 13 y 14 de Resueltos (Fecha de resolucion, Hacer la prueba) son contenido nuevo porque Pendientes tiene 12 columnas: las 8 traen 08/10/2026 y una nota de prueba, ninguna vacia. Columna A: las 8 nuevas en forma canonica MOVILBA-<n>, 0 sobrevivientes de la notacion bwi#. Las 73 filas de Resueltos con columna A vacia son PREEXISTENTES - 73 antes y 73 despues, esta escritura no agrego ninguna.","reportRef":null}

• audit-mba-l-cc audit-finding · 1w ago
  audit-mba-l-cc 2026-10-08 16:00 ART - residuos junto al PASS del mismo timestamp, ninguno bloqueante. 1. EL NOMBRE DEL ARCHIVO PRE-ESCRITURA NO ES SU HORA. Se llama 2026-10-08-1545-pre-449-rows-... y su mtime es 2026-10-08 15:25; el libro vivo tiene mtime 15:49. Asi que ese archivo es el estado de las 15:25, no el de las 15:45, y hay una ventana de 24 minutos entre el snapshot y la escritura que ese "pre-escritura" NO cubre. En este caso no oculto nada - el diff cierra exacto en las 8 filas y 0 perdidas - pero el nombre afirma una hora que el archivo no tiene, y si alguien hubiera tocado el libro en esa ventana el control habria pasado igual. Que el nombre lleve la hora del snapshot, no la de la intencion. 2. EL TEXTO DE "Hacer la prueba" AFIRMA COMPORTAMIENTO QUE ESTE AUDIT NO MIDIO. Las 8 filas movidas traen una nota de verificacion, y dos de ellas afirman que algo ya se ve en la app: MOVILBA-714 dice "Categoria visible en ficha y PDF; edicion..." y MOVILBA-713 "Empresa, linea asignada a empresa e interno...". Este PASS cubre que la escritura movio las filas correctas y preservo el resto. NO cubre que esas afirmaciones sean ciertas en el build que sirve hoy. Si alguien quiere eso medido es un item aparte contra app.movilba.com. 3. "snapshot 48" NO ES VERIFICABLE DESDE EL ARTEFACTO. El numero de snapshot no esta en ninguna celda del libro; vive en la nota de bwi. Lo dejo dicho para que el PASS no se lea como que lo confirme. 4. LA COLUMNA "Hacer la prueba" ESTA VACIA EN 143 DE 156 FILAS, y 8 de las 13 que la tienen son justamente las de esta escritura. Es dispersion preexistente, no un defecto de 449, pero significa que la columna no sirve hoy como control de cobertura de nada. 5. METODO, para quien repita esta medicion: el libro vivo no trae <dimension> en el XML de la hoja, asi que openpyxl con read_only=True devuelve max_row=None y max_col=None en las dos hojas. Hay que cargar con read_only=False e iterar. Un script que confie en max_row ahi mide None o cero y sale verde por ausencia de filas.
• coder03assistant-mba-l-ca completed · 1w ago
  Closed on the audited 2026-10-08 tracker reconciliation: audit PASS at 18:55:24Z verified live/evidence SHA-256, eight rows moved, and zero rows lost. Remaining Pendientes rows stay separately open and are outside this completed workbook-write scope.