Amadeus — Análisis del backlog Jira

CSV importado de C:\Users\sevao\Downloads\Jira.csv (51 tasks, todas en To Do, prioridad Medium). Analizado contra el estado actual del código (HEAD 008118c) y las decisiones documentadas en amadeus.md.

Objetivo: que Sergio decida una por una si hacer, descartar, rescoperar o deferir. Nada se ejecuta automáticamente.

Leyenda de columnas

• Estado vs lo que ya existe en el código / decisiones recientes:
  • DONE — ya está implementado y funcional.
  • PARTIAL — implementado a medias o un alcance distinto.
  • STALE — contradice una decisión más reciente o depende de algo que ya se descartó.
  • OK — pendiente válido sin overlap con el código actual.
  • AMBIGUO — title de una palabra o muy vago; necesita aclaración.
  • BUG — reporte de bug verificable.
  • DUP — duplicado o subsumido por otro item del backlog.
• Dificultad estimada (orden de magnitud, no horas):
  • S — small, 1-3 h (UI tweak, validation, copy fix, una migración trivial).
  • M — medium, 0.5-2 días (feature contenida, varios archivos, un endpoint).
  • L — large, 2-5 días (feature mayor, schema + UI + policy, integración externa).
  • XL — extra large, semana+ (módulo nuevo o reescritura).
• Capa (cuando aplica):
  • C1 — depende de permisos (capa 1 de inventarios). Hoy ON solo para Selene.
  • C2 — depende del flag INVENTARIO_VIAJE_LINK (capa 2). Hoy OFF.

Tabla de análisis

Resúmenes por bucket

Cerrar (ya están hechos — 5 ítems)

• AM-46, AM-47, AM-84, AM-134.
• AM-141 cerrar si se elige NO eliminar la página (AM-132).

Probablemente descartar (8 ítems)

• AM-9, AM-10, AM-71, AM-85, AM-91, AM-98 — epics de una palabra abandonados.
• AM-97 — contradice decisión reciente.
• AM-58, AM-107, AM-142 — ambigüedad bloquea estimación.

Quick wins (S, sin dependencias — 8 ítems)

• AM-52, AM-53, AM-66, AM-89, AM-94, AM-95, AM-130, AM-133, AM-138.
• Sugerencia: bloque “quick wins” en una sola sesión, todos pequeños, podrían entrar en 1 día.

Decisiones de producto antes de hacer (5 ítems)

• AM-55 (¿layer de roles encima de permisos?).
• AM-72 (SMS vs push interno, costo).
• AM-132 vs AM-141 (eliminar reporte o protegerlo — ambos no).
• AM-146 (¿watching por orden?).
• AM-143 (reproducir el caso real antes de tocar).

Features medianos (M — 13 ítems)

AM-59, AM-65, AM-69, AM-90, AM-93, AM-99, AM-100, AM-119, AM-129, AM-131, AM-135, AM-136, AM-137, AM-144, AM-145.

Features grandes (L+ — 3 ítems)

• AM-49 traducciones (decidir antes: end-to-end o gradual).
• AM-139 multi-destino (Fase 2 explícita; ya tiene plan).
• AM-57 base de datos de equipos (pedir contexto antes de tasar).

Depende de capa 2 (defer — 2 ítems)

• AM-140, AM-144 (parcialmente).

Consolidar (overlap entre ellas)

• AM-65 + AM-73 + AM-90 + AM-99 + AM-136 — todas son variantes de “notas por entidad con/sin notif”. Recomendado: un solo modelo Nota polimórfico con notificar=bool, una UI, varios entry points. Si Sergio acepta, sustituye 5 tickets por 1 epic de M-L.

Cómo trabajar este doc

Sergio decide ítem por ítem. Marcadores:

• [x] el ticket queda resuelto (sea por done, descarte, rescope, o consolidación).
• [ ] sigue abierto.
• [~] consolidado con otro — indicar cuál.
• Anotar en Notas lo que se decidió y porqué (append, no sobreescribir).

Cuando un ticket se va a trabajar, se mueve a projects/amadeus.md sección “En progreso” y se sigue el flujo normal del hub.

Asignación a sprints (aprobada 2026-05-20)

29 tickets abiertos distribuidos en 7 sprints (15-21) + backlog diferido. Suponiendo que el próximo sprint en Jira sea el 15; si la numeración real es otra, renombrar pero mantener orden.

Sprint 15 — Quick wins + bug fixes (~2 días, 9× S)

• AM-52 indicador cargando consumos
• AM-53 mensaje flash móvil
• AM-66 notas por consumo (justificación compras)
• AM-89 fecha manual en depósitos
• AM-94 subtotal e IVA en consumos
• AM-95 entradas/salidas con servicio/lugar
• AM-130 select buscable en filtro productos
• AM-133 buscar movimientos por número de serie
• AM-138 cancelar órdenes sin viáticos ni depósitos

Sprint 16 — Reportes y visualizaciones (~1 semana, 4× M)

• AM-69 correo diario de saldos con viáticos
• AM-93 consumos por usuario/fecha/categoría sumarizado
• AM-131 vista detalle de producto con inventario+historial
• AM-100 múltiples fotos en consumos

Sprint 17 — Roles + notif scheduled (~1.5 semanas)

• AM-55 layer de roles persistidos (L) — refactor de policies + Nova
• AM-72 push+email scheduled job 16:00 (S+) — reusa VAPID + Gmail Workspace

Sprint 17 debe ir antes que sprint 18 para evitar migrar policies dos veces (notas necesitarán autorización por rol/permiso).

Sprint 18 — EPIC-NOTAS (~1-2 semanas, M-L)

• EPIC-NOTAS modelo Nota polimórfico + nota_fotos opcional + UI inline + listener al crear viaje
• Cubre AM-65, AM-73, AM-90, AM-99, AM-136

Precondición: validar uso real con técnicos antes de codificar.

Sprint 19 — UX y mobile (~1 semana, 3× M)

• AM-129 paginación estandarizada en todas las páginas
• AM-137 form de creación de viajes en móvil
• AM-142 estilo de info de materiales/productos ⚠️ aclarar qué pantalla antes de empezar

Sprint 20 — Datos del módulo de inventarios (~1 semana, 2× M + S)

• AM-119 inventarios pertenezcan a sitio O usuario (schema change + check OR)
• AM-120 verificar que cambio de estatus cubre rechazado/cancelado además de entregado (puede ser S si ya está implementado)
• AM-59 fotos de estado de unidad en salida/llegada

Sprint 21 — Features de viaje (~1 semana, 3× M)

• AM-135 viajar sin unidad (avión/camión) con detalles del vuelo/camión
• AM-145 actualizar órdenes y notificar cambios (extiende listener viaje creado a updated con diff)
• (slot libre para overflow del sprint 16 o adelantar de backlog)

Backlog diferido (fuera de sprint, requiere precondición)

• AM-49 traducciones a español (L, sprint dedicado cuando se decida alcance: end-to-end vs página por página)
• AM-57 BD equipos en sitios con identificadores (L, pide aclaración sobre “hacia dónde están apuntados”)
• AM-139 Fase 2 N vehículos: múltiples destinos/cuadrillas/vehículos por viaje (L, después de validar Fase 1 en prod)
• AM-140 editar productos en viaje recién creado (depende de capa 2 activada)
• AM-144 existencia de productos al hacer viaje (parcialmente depende de capa 2)
• AM-143 checklist sin botón OK + mensaje falso (en pausa hasta reproducir caso real)

Notas operativas de la asignación

• Capa 2 (INVENTARIO_VIAJE_LINK) queda intencionalmente fuera de toda asignación — su activación sigue siendo decisión independiente de Sergio. Cuando la actives, AM-140 y AM-144 (parcial) entran al próximo sprint disponible.
• AM-120 puede cerrarse sin trabajo si InventarioService::aplicarEntrada ya cubre todos los estatus. Verificar al inicio del sprint 20.
• AM-100 podría moverse al sprint 21 si quieres mantener “todas las fotos” agrupadas con AM-59.

Epics derivados de la consolidación

EPIC-NOTAS — Modelo Nota polimórfico con foto opcional

Origen: consolidación de AM-65, AM-73, AM-90, AM-99, AM-136 (5 tickets que pedían el mismo patrón sobre entidades distintas).

Scope:

• Tabla notas: id, notable_type, notable_id, autor_id (FK usuarios), contenido text, notificar_al_abrir bool, timestamps.
• Tabla nota_fotos: id, nota_id (FK), path, timestamps. Soporta multi-foto por nota.
• MorphMap en AppServiceProvider: registrar Viaje, Sitio, MovimientoInventario (¿Orden si es modelo separado?).
• Trait HasNotas en cada modelo notable: morphMany(Nota::class, 'notable').
• Modelo Nota con belongsTo Usuario as autor, morphTo notable, hasMany NotaFoto.
• UI inline reusable: componente Vue <NotasInline notable-type=... notable-id=... :allow-create-photo="true"> con lista + form + drag&drop foto.
• Listener: al crear Viaje (y posiblemente al crear MovimientoInventario), buscar notas en Sitio correspondiente con notificar_al_abrir=true y disparar push+email al equipo asignado.
• Nova: resource Nota con polymorphic field para gestión admin.

Dificultad: M-L (1-2 semanas).

Dependencias:

• Modelo Orden — confirmar si existe como entidad propia o si “orden” en AM-73 = viaje.
• Storage para fotos: reutilizar el mismo path que ya usan otras fotos del proyecto.

Validación previa antes de codificar:

• Confirmar uso real: ¿el técnico va a tomar el teléfono y escribir una nota, o va a llamar por radio? Si la respuesta es la 2, la inversión no vale.
• Decidir si las fotos son obligatorias para algún tipo de nota o siempre opcionales.

Bitácora de decisiones

2026-05-20 — análisis inicial

• 51 tickets de Jira importados y categorizados.
• Sin acciones automáticas — pendiente que Sergio revise una por una.

2026-05-20 — sesión de decisiones (Sergio)

• Cerrados (5): AM-46, AM-47, AM-84, AM-134, AM-141. Confirmados como DONE.
• Descartados (12): AM-9, AM-10, AM-58, AM-71, AM-85, AM-91, AM-97, AM-98, AM-107 (epics de 1 palabra + stale + ambiguos) + AM-132 (consolidación previa de reportes) + AM-146 (over-engineering vs flag global existente).
• Decisiones de producto:
  • AM-55 → Opción A: layer de roles persistidos encima de permisos granulares. Pendiente ejecutar (L).
  • AM-72 → Opción C: push + email fallback, NO SMS pagado. Pendiente ejecutar (S+).
  • AM-143 → Opción D: reproducir caso real antes de decidir fix.
• Consolidación: AM-65, AM-73, AM-90, AM-99, AM-136 → epic EPIC-NOTAS (modelo polimórfico + foto opcional). 5 tickets reducidos a 1 epic M-L.

Pendiente: priorizar el resto de tickets abiertos (29 ítems).

2026-05-20 — priorización aprobada

• 29 tickets distribuidos en 7 sprints (15-21) + backlog diferido.
• Sprint 15 = quick wins (9× S, ~2 días).
• Sprint 16 = reportes y visualizaciones (4× M).
• Sprint 17 = roles persistidos + notif scheduled (la más invasiva, debe ir antes que EPIC-NOTAS).
• Sprint 18 = EPIC-NOTAS (consolidación 5→1).
• Sprint 19-21 = UX/mobile + datos inventarios + features viaje.
• Backlog diferido: AM-49 (traducciones), AM-57 (BD equipos), AM-139 (Fase 2), AM-140/144 (dep. capa 2), AM-143 (repro).
• Cada ticket en la tabla principal lleva ahora etiqueta SPRINT N o BACKLOG.