Decision: is a re-plate (cambio de dominio) its own modification subtype?

Sub-tickets

Activity

• wi-cli-venus created · 5w ago
• wi-cli-venus blocked · 5w ago
  Elazar decision pending: re-plate as own subtype (A) or ADMINISTRATIVO (B), plus alta-card 'Primer valor' trim. Options sent as nqla in CLI 2026-09-05 ~00:00; no code until answered.
• coder04-mba-l-ca progress · 3w ago
  coder04-mba-l-ca | 2026-09-24 03:56 ART. Still waiting on Elazar choice for re-plate subtype versus ADMINISTRATIVO and Alta-card Primer valor wording. DEV dev src/lib/rutap-modification-subtype.ts remains the classifier; MOVILBA-526 old-plate retention does not answer this display choice.
• coder03-mba-l-cc assigned · 2w ago
  db03-mba-l-cc
• coder03-mba-l-cc assigned · 2w ago
  db04-mba-l-ca
• coder03-mba-l-cc assigned · 1w ago
  researcher-mba-l-cc / solo
• researcher-mba-l-cc note · 1w ago
  2026-10-08T12:34:26-03:00 researcher-mba-l-cc What the book shows for a re-plate (docs/audits/rutap-import-workflow-audit-2026-08-20.md:143-152, corrected finding, applies to the 130 PROD pairs including the cited vehicle 5806 AH850FS->AI239RA): RUTAP does not record a re-plate as one field-level edit on a continuing vehicle. It records two independent business events - one Alta row for the new plate and one Baja row for the closed plate, each with its own expediente, both retained (borrado_en IS NULL). The chassis is what later joins them into one continuity chain; the book itself treats them as close-one/open-another, not modify-one. src/lib/rutap-modification-subtype.ts currently maps the `domain` field to ADMINISTRATIVO (line 77, same bucket as cuit/companyIdentifier/startDate/observations/procedure/creator - the catch-all). This is a MovilBA-side artifact: the chassis-chain reconstruction synthesizes a "modification" event where Nro_dominio differs between consecutive rows of the same chain, even though the book itself never modeled it as a modification - it is two lifecycle events RUTAP opened and closed separately. Four surfaces, per option: - Option A (add REPATENTAMIENTO subtype above ADMINISTRATIVO, one map edit in rutap-modification-subtype.ts): ficha history badge on the synthetic modification card changes from "Administrativo" to "Repatentamiento"; edit form is unaffected (the classifier only drives the history/ficha badge, not form fields); export/PDF - if it surfaces the subtype badge text on the historical report, it picks up the new label too (same classifier, single source); /api/v1 - if the API exposes modificationSubtype as a field (needs confirming against docs/reference/parque-movil-api/ before shipping), its value for these 153 chains changes from ADMINISTRATIVO to REPATENTAMIENTO, which is a published-contract value change, not cosmetic. - Option B (leave as is): no surface changes; a re-plate continues reading as paperwork on the ficha badge, understating that 153/2258 chassis chains (db02 sizing) involve an actual plate swap rather than an address/CUIT/observation edit. Decision is Elazar's per the item's own blocked reason; this note adds the book evidence for the pattern, not a recommendation beyond what the item already frames.
• researcher-mba-l-cc note · 1w ago
  2026-10-08T13:08:48-03:00 researcher-mba-l-cc follow-up. Confirmed the open question from the prior note: grepped docs/reference/parque-movil-api/ and src/app/api/v1/ for modificationSubtype/modification_subtype - zero hits. The published external API does not expose this field at all, so Option A's /api/v1 line above is moot - drop it. Four surfaces for the letter answer: ficha badge changes (A) / stays (B), edit form unaffected either option, export/PDF badge text changes (A) / stays (B) if it surfaces the subtype at all, API: no change either option (field not published). A or B is the whole answer.
• coder03-mba-l-cc note · 1w ago
  coder03 2026-10-08 13:30 ART: measured before answering Elazar, and option A rests on a premise the book does not support. The corrected finding in docs/audits/rutap-import-workflow-audit-2026-08-20.md:143-152 says PROD's intended model for all 130 re-plate pairs is one Alta row for the new plate and one Baja row for the closed one, each retained with its own expediente, so a re-plate is an alta plus a baja and not a MODIF row with Nro_dominio changed. MOVILBA-461 says the same thing from the other direction, a dominio pass is ALTA and not MODIFICACION. A diff-driven badge is therefore the wrong instrument for it: on the book's own form there is no modification event to label. Second point, the subtype set is a hardcoded TypeScript union in src/lib/rutap-modification-subtype.ts:35-42 driving a user-visible badge, which is enumerated text living outside opciones, so adding a fourteenth member perpetuates a catalog violation rather than fixing a presentation gap. Third, src/lib/rutap-modification-subtype.ts:95-99 already states in code that the real hierarchy is Eugenia's to define and that it is open on MOVILBA-97, and subtipoPrincipal is only a default while grupos always carries the full set, so nothing is lost today. Recommendation: do not add REPATENTAMIENTO here; fold the question into MOVILBA-97's pending confirmation, and when it is answered move the subtypes into opciones instead of extending the union.