El app registra Modificacion cuando cambia la LINEA y el stakeholder pide que sea Alta: la clasificacion de tramite no aplica la regla de Parodi

Sub-tickets

Activity

• wi-cli-venus created · 4w ago
• wi-cli-venus assigned · 3w ago
  coder02-mba-l-ca / coder
• wi-cli-venus note · 3w ago
  AUDIT TRIAGE - Coder batch #3. Implement stakeholder rule: a line change closes the prior assignment with BAJA and creates the new assignment with ALTA; internal-only edits remain MODIFICACION. Do not rewrite historical rows. Add transaction and regression tests. Estimate: 4-8h.
• wi-cli-venus statusChanged · 3w ago
  coder02-mba-l-ca started code-first investigation. Scope: transactional line-change split into BAJA old assignment + ALTA new assignment; internal-only remains MODIFICACION; no historical rewrite.
• wi-cli-venus progress · 3w ago
  Code-first fix committed as daefc8ae7172b1570cb322c1c8e8bda5ee438b5f. Atomic writer now records true line A->B transfer as recognized BAJA closure on old line plus open ALTA successor on new line; internal-only stays MODIF; combined line+interno captures old ficha before updates. No historical rewrite. Focused tests PASS 7 classifier + 19 transaction/reader contract; diff check PASS. Audit requested; DB historical measurement pending.
• wi-cli-venus progress · 3w ago
  Landed on dev 2026-09-20 at 801dde79051b8ea3e5b4f386dc54f49d70ba2bb6, five released blobs written by blob and re-hashed after write: src/repositories/vehiculos.ts f4e1074f, tools/movilba-344-writer-rehearsal.ts c1a9468f, src/lib/vehiculo-tramite.ts 4ae844ed, src/lib/vehiculo-tramite.test.ts b304e77a, src/repositories/vehiculos.line-transfer.test.ts d7e3ac6f. Audit verified all five on the commit. tsc 0 on the tree, classifier 7/7, deploy green, health 200 at 09:05:30Z. Rule implemented, Parodi via Eugenia relayed by Elazar 2026-09-18: 'Un dominio que cambia de interno es una modificacion, ya que sigue estando en la misma linea. Si cambia de linea hay que darlo de baja en la que deja y de alta en la nueva.' So a line or entity change classifies ALTA and the repository writes a separate closure event before the successor; an interno-only change stays MODIF. MUTANTS SEEN RED, since a harness that has not been seen to fail is a green line. db03 ran the rehearsal with ROLLBACK: unmutated exit 0 with all 8 results and rolledBack true; the 470-revert mutant went RED at the id assert ('286402' !== '275223'); a narrow mutant adding isNull(expteAlta) to the in-place-close WHERE went RED at 'the app predecessor must be closed in place by the second transfer' (predecesorCerrado.fecha_baja actual null, expected 2026-09-20). CONTRACT CORRECTION worth carrying, because two easy readings are both wrong. On a closing leg the view must return ANOTHER row than the closure - but asserting 'another row' passes for any stale earlier period, which is the bug you would want to catch, and asserting the WHOLE row deepEqual is also wrong: when the predecessor is an OPEN APP row (a transfer's successor) the writer closes it IN PLACE, so the same row comes back with fecha_baja set and estado BAJA, keeps its expte_alta, and is therefore not 470's closure shape - the view is right to keep returning it. The invariants are exactly two: the id of the row that answers, and its expte_alta. Both are captured immediately BEFORE the write and compared after. fecha_baja and estado_derivado do move and are checked against each other on the same row, never against a count over the partition. ASSERTS THAT RAN GREEN BUT WERE NEVER FALSIFIED, stated because an unfalsified assert is a green line and the harness is fail-fast, so one mutant only ever exercises the first reachable assert: vigentes=1 and abiertas=1 after the second transfer; the largo_cero count, which is by 451 FORM (fecha_alta=fecha_baja AND expte_alta IS NULL) rather than by zero length alone, since a period opened and closed the same day is a real period; the expte_alta invariance assert; the two closing legs other than the one the 470 mutant reached; and the transfer resolver asserts. The results.length literal is 8 and is maintained by hand with the legs - it is the control that catches a leg silently not running, so it is not derived. Ticket stays inProgress pending whatever remains on the UI side.
• coder03-mba-l-cc assigned · 2w ago
  db03-mba-l-cc
• db03-mba-l-cc note · 2w ago
  db03-mba-l-cc 2026-10-01 - deliverable (a) already closed by the shipped fix (daefc8ae/801dde79, 2026-09-20): clasificarTramiteEdicion in src/lib/vehiculo-tramite.ts implements the Parodi rule exactly (cambiaEntidad||cambiaLinea -> ALTA, cambiaInterno-only -> MODIF), writes to rutap.vehiculo_historial_normalizado via a line-transfer close+open pair, audited and tested (7 classifier + 19 transaction tests). Deliverable (c) is book data, out of this item's scope per its own text. Deliverable (b) - count of app-created periods already mislabeled before the fix - is NOT MEASURABLE right now: rutap.vehiculo_historial_normalizado WHERE origen='app' returns 0 rows in BOTH PROD and DEV as of today. PROD=0 is expected (no go-live yet, no real app users). DEV=0 is NOT expected - MOVILBA-588's investigation measured 54 app-origin rows in DEV as of 2026-09-24, and my own MOVILBA-155 catch-up apply purged 118 app-origin historial rows in DEV with no provenance gate (MOVILBA-649, still open, assigned db04). The specific evidence the stakeholder attached (EX-2026-41539951, Leandro Baez, 15/09, linea 34->4) predates the 09-20 fix and its row - if it ever lived in this table - is gone now, same unrecoverable-evidence shape as MOVILBA-623 (coder03 closed that one today as unrecoverable by construction). Recommend: close (b) as UNRECOVERABLE, chain the loss to MOVILBA-649, and close MOVILBA-511 itself unless the UI-side work the 09-20 note flagged as still open is tracked elsewhere.
• audit-mba-l-cc audited · 2w ago
  audit pass: Code claim (a) verified at src/lib/vehiculo-tramite.ts:21-22 - exact Parodi logic. (b)/(c) and the 649/623 unrecoverable-evidence chain are DB-state, not re-run.
  payload

  {"scope":"Code claim (a) verified at src/lib/vehiculo-tramite.ts:21-22 - exact Parodi logic. (b)/(c) and the 649/623 unrecoverable-evidence chain are DB-state, not re-run.","outcome":"pass","evidence":"DB EXECUTION NOT PERFORMED BY AUDIT - no DB creds. Chain to 649/588/623 internally coherent with prior bwi events read, not independently measured.","reportRef":null}

• coder03-mba-l-cc completed · 1w ago
  coder03-mba-l-cc 2026-10-05: closed at db03's report; audit PASS already recorded in bwi (2026-10-02).