Estado del vehiculo como estado GUARDADO con periodos propios, editable y con fecha, no como campo derivado
Blocked high
dmdb03-mba-l-cc
⛔ waiting Elazar's GO (routed via coder03) on the estado CHECK constraint before drafting migration
Elazar, 2026-09-03: 'estado_id should be a calculated field in a view, the result of transactions properly entered that result in a bus being alta_baja'. O sea el estado del vehiculo deja de ser una columna GUARDADA y pasa a DERIVARSE de los eventos. POR QUE ES AHORA Y NO DESPUES: hoy el estado tiene dos fuentes que se contradicen. La ficha (vehiculos_datos_colectivos.estado_id) y la superficie de historial dan respuestas distintas para los mismos 7 vehiculos - MOVILBA-147, medido por db02 el 03/09 en PROD y DEV. La ficha coincide con el libro 7 de 7 y el historial lo contradice 7 de 7. MOVILBA-212 tapa ese sintoma haciendo que un periodo cerrado publique NULL en vez de su estado estampado, pero es un parche: mientras estado_id sea una columna escrita a mano en dos lugares, se van a volver a separar. LA REGLA DE DERIVACION, que hay que escribir antes de codearla: el libro NO tiene columna de estado. El estado sale de Fecha_Baja - fila abierta es ALTA, fila cerrada es BAJA - y esa es la unica base que el SSOT ofrece. Cualquier otra cosa que la vista publique es invencion nuestra. DEPENDE DE LA TABLA ANCHA: derivar estado de los eventos solo sirve si los eventos guardan lo suficiente para derivarlo, que es exactamente lo que MOVILBA-125 esta construyendo. Por eso cuelga de 125 y no se hace antes. OJO CON EL CASO MANTENIMIENTO: opciones tiene un tercer estado vivo, 119 MANTENIMIENTO, que db03 midio el 03/09 y NO existe en ningun lado del SSOT - 0 hits en los 7 libros, todas las hojas, normalizado por acento y mayusculas, con control positivo de 2004 celdas para dominio. Uso real: DEV vdc 0 vivos y 2 borrados, DEV historial 0, PROD vdc 0 y PROD historial 0. Un estado que no se puede derivar de Fecha_Baja porque el libro no lo expresa. Si se deriva estado de los eventos, MANTENIMIENTO no tiene de donde salir: o se soft-deletea como se hizo con TRANSFERENCIA (118, borrado 2025-10-13), o se declara estado operativo propio de MovilBA que exporta como ALTA. Decision de Elazar, planteada, sin respuesta todavia. ACEPTACION: una sola fuente de estado en toda la app; la ficha y el historial no pueden discrepar porque no hay dos columnas que discrepar; y el estado derivado coincide con el libro fila por fila sobre el universo entero, no sobre una muestra.
Activity
-
parent=#3027
-
Estado del vehiculo como estado GUARDADO con periodos propios, editable y con fecha, no como campo derivado
-
REVISION DE ELAZAR el mismo dia, 2026-09-03, que revierte en parte el planteo original de este item. LA DISTINCION QUE HABIAMOS APLASTADO: Tramite y Estado son dos cosas distintas y el libro usa la misma palabra para las dos. Tramite es el TIPO de fila - Alta / Modificacion / Baja. Estado es si el colectivo presta servicio o esta retirado. Una fila con Tramite = Baja puede estar solo cerrando un periodo porque el colectivo cambio de linea o de empresa, mientras el colectivo sigue circulando. O sea 'Baja' significa dos cosas segun en que columna este, y todo lo que razone sobre la PALABRA en vez de sobre la COLUMNA queda sospechado. Palabras de Elazar: la columna que hoy se llama Tramite ANTES SE LLAMABA ESTADO y se retiro con ese nombre. Y se acuerda de un colectivo en Mantenimiento, o una palabra parecida, que seria ESTADO y no Tramite. POR ESO ESTE ITEM CAMBIA DE FORMA: derivar el estado de los eventos solo funciona si todo estado se puede deducir de Fecha_Baja, y MANTENIMIENTO no se puede - el libro no tiene como expresarlo. Entonces el estado NO se deriva: sigue siendo un campo GUARDADO, y ademas EDITABLE, con periodos propios igual que linea y entidad. LA FORMA QUE PIDIO: el campo Estado de /vehiculos/[id]/editar/colectivo se vuelve editable y exige una FECHA. Cuando el colectivo vuelve de Mantenimiento se pide una fecha de alta, y esa fecha se escribe como fecha de baja del ultimo evento de Mantenimiento. O sea los periodos de estado se cierran con la fecha que abre el siguiente, igual que los de linea. QUE SE EXIGE Y QUE NO: el EXPEDIENTE no se exige, porque a veces no hay. OBSERVACIONES SI se exige. Es la primera regla de validacion de esta pantalla que Elazar fija despues de haber levantado la regla B el 2026-08-20, y no es la regla B de vuelta: aquella pedia expediente O motivo sobre CUALQUIER edicion; esta pide observaciones sobre un cambio de ESTADO. ANTES DE CONSTRUIRLO SE LE PREGUNTA A EUGENIA. Tres preguntas nuevas en el tracker, hoja Para Eugenia: la 9 pregunta si existe el estado de fuera de servicio sin baja y como lo anota hoy; la 10 que fecha anota cuando el colectivo vuelve; la 11 si una fila con Tramite = Baja siempre significa que el colectivo dejo de circular o a veces es solo el cierre de un periodo. QUEDA EN PIE de la version anterior: que el estado tenga UNA sola fuente, y que la ficha y el historial no puedan contradecirse. Lo que se cae es que esa fuente sea una vista calculada.
-
unassigned
-
Eugenia's answer in 2026-09-10-1441-todo-rutap-importacion-prestaciones.xlsx resolves the pending product question: RUTAP currently records only BAJA, regardless of what is done with the vehicle. Together with Elazar's direction that Agregar expose only ALTA/BAJA, MANTENIMIENTO is not a supported vehicle state. Keep this item focused on one canonical ALTA/BAJA state source and period model; do not build the previously proposed MANTENIMIENTO state workflow.
-
db03-mba-l-cc
-
db04-mba-l-ca
-
db03-mba-l-cc / db
-
db03 2026-10-08: measured options, not a rewrite, per dispatch. The 09-03 blocker ("ANTES DE CONSTRUIRLO SE LE PREGUNTA A EUGENIA") is CLEARED - measuring that first since nothing else here can proceed until it is. EUGENIA'S GATE: ANSWERED. Tracker Resueltos row 77 ("Estados del vehiculo"), answer received 2026-09-13, resolved 2026-09-14: "independientemente de la situacion operativa, se utiliza unicamente BAJA." MANTENIMIENTO confirmed NOT a RUTAP-recorded state. This matches and finalizes the 2026-09-10 bwi decision event already on this ticket (MANTENIMIENTO out of scope, ALTA/BAJA only). Tracker was just re-imported fresh to sqlite as part of this same turn (18 Pendientes/146 Resueltos, sha256 3f042e1...351901a) - this is not a stale read. CURRENT IMPLEMENTATION STATE (measured, not built yet): - vehiculos_datos_colectivos.estado_id remains a plain stored column, NOT periods-based. No fecha/observaciones-gated edit flow exists for it today. - MOVILBA-212's fix (closed, done) is still the only protection in place: a VIEW-level patch that nulls a closed period's stamped estado rather than a real second source of truth. It is still the "parche" this ticket's own body names, not superseded. - Parent MOVILBA-125 (RUTAP full-history refactor, status=inProgress, owned db04) does NOT currently plan for estado periods - grepped docs/design/rutap-full-history-refactor-plan.md for "estado": zero hits. The dependency this ticket declared ("cuelga de 125") is not reflected in 125's own plan doc. TWO MEASURED OPTIONS for the implementation path, no code written either way: A) Ride on 125: wait for the wide-table historial infrastructure 125 is building and add estado periods into it, reusing the same deterministic rank mechanism already proven in production for linea/entidad periods (rutap.v_vehiculo_historial_actual, just re-verified clean closing MOVILBA-12 this session). Lowest duplication, but blocked on 125's own timeline, and 125's plan doc does not yet name this as in scope - someone needs to add it there first or it is silently dropped when 125 ships. B) Build a standalone estado_historial table now, independent of 125, following the same periods-with-explicit-close pattern (fecha required, observaciones required, closed by the next period's opening). Unblocks sooner, but risks a second periods implementation to reconcile with 125's later one. This is a product/schema-path decision (A vs B) plus a UI build (src/app/vehiculos/[dominio]/editar/colectivo per the ticket's own spec) - coder-lane work once the path is picked, not something to implement unilaterally from db. Leaving open, not closing.
-
researcher 2026-10-08, synthesis for Elazar - what options A/B change on the four surfaces (ficha, historial, export, API), built on db03's 2026-10-08 14:44 note. Eugenia's gate is CLEARED: tracker Resueltos row 77 (answered 2026-09-13) confirms only BAJA is RUTAP-recorded regardless of operational situation - MANTENIMIENTO is not a supported state, matching the 2026-09-10 bwi decision already on this ticket. TODAY, BEFORE EITHER OPTION: vehiculos_datos_colectivos.estado_id is a plain stored column, not periods-based. MOVILBA-212's fix is still the only protection - a VIEW-level patch that nulls a closed period's stamped estado on the historial surface rather than a real second source of truth. Ficha and historial read from two different places and can still disagree in principle; MOVILBA-212 only hides the symptom on one of the two surfaces. OPTION A - ride on parent MOVILBA-125 (wide-table historial refactor, status inProgress, owned db04): ficha, historial, export and API would all eventually read estado from the new wide-table periods once 125 ships, reusing the same deterministic-rank mechanism already proven for linea/entidad periods. MEASURED BLOCKER: 125's own plan doc (docs/design/rutap-full-history-refactor-plan.md) has ZERO mentions of "estado" - the dependency this ticket declares ("cuelga de 125") is not reflected in 125's scope. Until someone adds it there, none of the four surfaces change when 125 ships; MOVILBA-212's patch stays the de facto implementation indefinitely. OPTION B - standalone estado_historial table now, independent of 125: ficha surface gets a new edit UI (src/app/vehiculos/[dominio]/editar/colectivo per the ticket's own spec, fecha+observaciones required, no expediente requirement) as the only write path for estado. Historial surface switches to reading the new periods table instead of the raw column, converging with ficha onto one source. Export and API surfaces keep the same estado_id output shape, just sourced from the new table instead of the raw column - no contract change for consumers. Ships sooner than A, but creates a second periods mechanism that has to be reconciled with 125's own periods implementation later - duplicated logic risk, not duplicated UI risk. DECISION OWED: A vs B is a product/schema-path call, not a DB-lane call - no code has been written for either.
-
2026-10-08T13:09:04-03:00 researcher-mba-l-cc follow-up - four-surface line for a letter answer. Option A (ride on MOVILBA-125, add estado periods to its scope first): ficha - unchanged until 125 ships, then reads estado from the new wide-table periods, same deterministic-rank mechanism as linea/entidad; edit form - no new UI, estado continues to have no fecha/observaciones-gated edit flow until 125's periods land; export - unchanged until 125 ships (same output shape, new source); API - unchanged until 125 ships (same estado_id shape, new source). Net: zero surface change on any near-term timeline unless 125's plan doc is amended to include estado, which it is not today. Option B (standalone estado_historial table now): ficha - reads from the new table, converges with historial on one source immediately; edit form - new UI at src/app/vehiculos/[dominio]/editar/colectivo (fecha+observaciones required, no expediente) ships as the only write path for estado; export - same estado_id output shape, re-sourced from the new table, no contract change; API - same, no contract change. Net: all four surfaces converge now, at the cost of a second periods mechanism to reconcile with 125 later. A or B is the whole answer.
-
coder03 2026-10-08 13:30 ART: Elazar chose A. Estado rides on MOVILBA-125 and no surface changes until 125's scope is amended to include estado; no standalone estado_historial table and no duplicated periods logic. Amend 125's scope to carry estado explicitly, and until that lands 219 stays blocked on 125 rather than on a decision.
-
Elazar chose Option A (2026-10-08, via coder03): estado rides on MOVILBA-125, no standalone estado_historial table. Blocked on 125's own scope doc (docs/design/rutap-full-history-refactor-plan.md, zero 'estado' mentions, re-grepped 2026-10-09) being amended to carry estado explicitly - that amendment is 125's owner's (db04) call, not db03's to make unilaterally on someone else's epic. DM sent to db04 2026-10-09.
-
db04 created docs/design/rutap-full-history-refactor-plan.md (sha256 2b6fd1636eab6455fe0266cee73b6d2eb1640c3a3b7c7a88468bf4bae58620f1, confirmed by db03), recording Elazar's Option A: estado periods in common wide history, no standalone table, same deterministic rank as linea/entidad, ALTA/BAJA only. Blocker cleared - file is untracked, not yet committed. Moving to backlog.
-
cleared: Elazar chose Option A (2026-10-08, via coder03): estado rides on MOVILBA-125, no standalone estado_historial table. Blocked on 125's own scope doc (docs/design/rutap-full-history-refactor-plan.md, zero 'estado' mentions, re-grepped 2026-10-09) being amended to carry estado explicitly - that amendment is 125's owner's (db04) call, not db03's to make unilaterally on someone else's epic. DM sent to db04 2026-10-09.
-
MOVILBA-125 scope amendment is present and verified: docs/design/rutap-full-history-refactor-plan.md SHA256 2b6fd1636eab6455fe0266cee73b6d2eb1640c3a3b7c7a88468bf4bae58620f1, 15 estado mentions. Explicitly includes estado periods in shared wide history with deterministic rank; no standalone table. File is untracked pending coder-lane commit; implementation can proceed against this scope.
-
db03 2026-10-09 ART: blocker cleared. coder03 reports docs/design/rutap-full-history-refactor-plan.md committed dev 13d9e65f / prod 977b6cc9 - sha256 matches the version I already verified earlier today (2b6fd163...), estado explicit (15 mentions). Starting own-scope design read now.
-
db03 2026-10-09 ART. Measured the estado contract in docs/design/rutap-full-history-refactor-plan.md §Estado contract against DEV's live rutap.vehiculo_historial_normalizado. STORAGE SIDE (acceptance #4) IS ALREADY SHIPPED for real data: vocabulary is clean (1714 ALTA / 36 BAJA / 0 MANTENIMIENTO among 5558 import-origin rows), open-period=ALTA/closed-period=BAJA holds 100% for import-origin rows. App-origin (169 rows): 148/169 (87.6%) correctly stamped; the 21 exceptions are ALL dominio ~ '^ZX[0-9]' synthetic DEV test fixtures (confirmed: 21/21), not a writer defect against real data - out of scope per project CLAUDE.md's DEV-test-data rule. GAP FOUND: no DB-level CHECK enforces this coupling (estado_id ALTA when fecha_baja IS NULL, BAJA when NOT NULL, no third value) - it holds today by writer discipline only, not by constraint. rutap.v_vehiculo_historial_actual already applies the single deterministic ranking (confirmed earlier this session, already consumed by 3 of 4 named reader surfaces per MOVILBA-99's finding). Per the MOVILBA-738 precedent, adding that CHECK is new validation that could reject a future write - needs its own GO, not routine-DDL cover, even pre-live. RECOMMENDATION: no DDL to draft yet. (a) reader-surface cutover (#5) is already in flight via MOVILBA-99/coder04, not db-lane scope. (b) the CHECK constraint is the only remaining db-lane deliverable on this ticket - routing the GO ask to Elazar via coder03 before drafting it. Scope-wise this ticket may be close to done once the CHECK lands; no standalone estado_historial work needed, confirming Option A fully holds at the storage layer already.
-
waiting Elazar's GO (routed via coder03) on the estado CHECK constraint before drafting migration
feature
6w ago by wi-cli-venus
1w ago