Saltar a contenido

Próximos pasos

Backlog vigente de cambios documentales y del prototipo. Se mantiene aquí para que no dependa de entregables externos.

Avance de implementación (2026-07-11)

La APK tiene implementado en el árbol de trabajo el recorrido demo centralizado:

Acceso demo → Home → Prealerta → Paquete recibido → KYC → Consolidación → Cotización → Pago manual pendiente → Despacho → Seguimiento.

  • P0-01: recuperación con OTP demo, contraseña nueva, confirmación y reenvío temporizado.
  • P0-02/P0-03: prealerta sin tracking, persistida durante la sesión y visible en Reportes.
  • P0-04/P0-05: KYC persistido durante la sesión y bloqueo de consolidación/pago para todo estado distinto de aprobado.
  • P0-06: pago manual con comprobante demo y factura pago_reportado; una herramienta demo valida y habilita el despacho.
  • P0-07: valores de almacenaje alineados (15 días, $0.50/día, aviso a 3 días), fixtures relativos y etiqueta de demostración.
  • P0-08: capa de presentación que mapea estado interno, estado documental, texto y siguiente acción.

La compilación y las pruebas unitarias siguen pendientes de ejecución: el entorno de trabajo no dispone de Java ni de JAVA_HOME. No declarar estos cambios como verificados en dispositivo hasta ejecutar bash ./gradlew testDebugUnitTest en un entorno Android configurado.

Etapas

1. Cerrar decisiones pendientes

Resolver las decisiones abiertas en producto/decisiones-vigentes.md. Las dependencias inmediatas son D-200 (autenticación), D-201 (recuperación), D-202 (tracking) y D-208 (canal del pago manual). D-207 trata datos aduaneros y legales, no pagos.

2. Corregir prototipo (P0)

ID Cambio Verificable cuando
P0-01 Recuperación pide nueva contraseña con confirmación y reenvío de OTP. Implementado en demo; pendiente de prueba automatizada.
P0-02 Prealerta permite reportar sin tracking. Implementado en demo; crea reportada_sin_tracking.
P0-03 "Enviar reporte" persiste y muestra confirmación. Implementado en demo; navega al detalle y queda en Reportes durante la sesión.
P0-04 KYC pasa a SUBMITTED tras enviar y se refleja en dashboard. Implementado en demo; el expediente permanece en DemoSessionRepository.
P0-05 Gates KYC en consolidación, pago y despacho. Implementado: consolidación y pago bloquean antes de entrar; despacho demo exige KYC aprobado y pago validado.
P0-06 Pago MVP único (manual) sin opciones futuras. Implementado: pago_reportado no confirma el pago hasta que el operador demo lo aprueba.
P0-07 Fixtures coherentes: fechas relativas a "hoy", tarifas centralizadas. Implementado; las referencias legales históricas no se consideran fixtures.
P0-08 Equivalencias entre enums de código y estados canónicos. Implementado mediante capa de presentación; aún debe actualizarse el puente documental de enums legacy.

3. Iterar UX y accesibilidad (P1)

  • P1-01: tutorial solo primera vez con "Saltar".
  • P1-02: formulario de prealerta en 2 pasos.
  • P1-03: desglose único en consolidación. Implementado en la cotización persistente demo.
  • P1-04: enrutamiento de ServiceRequestsList y CTAs hoy sin salida. Implementado para las solicitudes del flujo demo.
  • P1-05: conexión del flujo de incidencia con un caso demo. Implementado con número de caso y cambio de estado demo.
  • P1-06: notificaciones separadas por fase, con deep links y estado leído/no leído. Implementado para eventos generados en la sesión demo.
  • P1-07: accesibilidad. Se elevó el texto explícito a 12sp y se mantienen mínimos de 48dp en botones; queda pendiente validación manual con TalkBack y escalado de fuente.

4. Iterar diseño y plataforma (P2)

  • P2-01: persistencia de cambios de perfil/contactos durante la sesión.
  • P2-02: aclarar tema (solo claro o construir modo oscuro real).
  • P2-03: empaquetar fuente Inter y validar fallback.

5. Cerrar documentación

  • Mantener producto/decisiones-vigentes.md y matriz-funcionalidad-fase.md sincronizados con cada cambio funcional.
  • Regenerar apk/estado-actual-prototipo.md, apk/navegacion.md y apk/catalogo-pantallas.md cuando se cierre un P0.
  • Actualizar CHANGELOG_DOCUMENTACION.md por cada ola de cambios.

Validación de cierre (CHECKLIST resumido)

  • mkdocs build --strict sin warnings ni enlaces rotos.
  • Cero enums técnicos en UI.
  • Cero CTAs principales sin resultado observable.
  • Estados UI completos (loading, vacío, error, éxito, offline, demo, bloqueo) en pantallas de datos.
  • Decisiones pendientes aplicables al hito cerradas y propagadas.
  • Datos demo centralizados y relativos a hoy.

Referencias

  • Este documento es el único backlog vigente del prototipo y de su documentación.
  • Las decisiones pendientes se mantienen exclusivamente en producto/decisiones-vigentes.md.