Documento histórico

Este documento se conserva solo para trazabilidad. Consulte el índice maestro para la fuente vigente.

Documento histórico — no usar como fuente de decisiones actuales

Reemplazado por la versión canónica del 2026-07-11. Conservar solo como trazabilidad histórica.

Auditoria de flujos de la APK IslaBox¶

Informe ejecutivo de los hallazgos detectados al cruzar la documentacion funcional con el codigo real de la APK. Generado el 2026-06-07 a partir de la revision de tareas.md, discrepancias.md, gap-mvp.md, los archivos del grafo de navegacion, las pantallas de consolidacion, el detalle del reporte y FakeDataSource.

1. Resumen ejecutivo¶

Bloque	Avance	Tareas	Bloqueantes para usuario final
Modelos de dominio	100 %	17/17	No
Drawables, manifest, permisos	100 %	3/3	No
Pantallas KYC completas	100 %	6/6	No
Pantallas Auth (Welcome, Login, Register)	100 %	5/5	Parcial (validaciones)
Pantalla de lista de consolidaciones	100 %	1/1	No (solo lectura)
Pantalla de detalle de consolidacion	100 %	1/1	No (solo lectura)
Stack y configuracion (AGP 9.1.1, Java 17, etc.)	100 %	5/5	No
Pantalla de CREAR consolidacion (CU-007, sin backend)	0 %	0/9 pasos	Si (T-406)
Pantalla de pago con datos mockeados coherentes	0 %	hardcodeado QUO-001	Si (T-422)
Perfil con navegacion a sub-pantallas (maquetacion)	12 %	1/8 items	Si (T-423)
Dashboard con seccion "Requiere tu atencion"	100 %	1/1	No
Validaciones de cliente en Login / Register	0 %	0/2	Si (T-426, T-427)

Veredicto (alcance maquetacion visual, sin backend): la base tecnica (modelos, enums, KYC, drawables, manifest, ViewModels) esta solida. El objetivo del Bloque D en tareas.md es avanzar la maquetacion visual sin backend ni autenticacion real: las pantallas navegan entre si, las validaciones son de cliente (regex, longitud), los datos se leen de FakeDataSource. No se pretende reemplazar la logica de servidor (login real, cobro real, conciliacion real).

2. Tareas que se han cumplido bien¶

De las 27 tareas originales mas 9 nuevas, 27 (71 %) estan completadas y la base tecnica es solida.

2.1 Datos y dominio (capa modelo)¶

Tarea	Estado	Resolucion
T-001 Drawables faltantes	✅	4 PNG creados en `res/drawable/` (isotipo, logo horizontal, isotipo-texto, success)
T-002 Identificador Mod-10	✅	`lockerId = "CP-001042-8"` correcto en `CurrentUser.kt`
T-003 Permisos Manifest	✅	5 permisos declarados (Internet, Camara, Media, Storage, Notifications)
T-101 `FakeDataSource` central	✅	Object con `currentUser`, `recipients`, `reports`, `serviceRequests`, `charges`, `invoices`, `quotes`, `consolidations`, `packageSummary`, `attentionItems`
T-102 Datos leidos de `CurrentUser`	✅	Dashboard y Perfil leen de `CurrentUser.user`
T-103 Iniciales calculadas	✅	`User.initials` para "Kleudy Victor Torno Peña" -> "KT"
T-104 Separar `Reporte` (hibrido)	✅	`Reporte` con `purchaseStatus` + `packageStatus` + propiedad derivada `estado`
T-105 Enums en lugar de String	✅	10 enums: `KycStatus`, `DocumentType`, `PurchaseReportStatus`, `PhysicalPackageStatus`, `ConsolidationStatus`, `PaymentStatus`, `ShipmentStatus`, `ServiceType`, `ServiceStatus`, `Acceptance`, `RiskLevel`, `LockerCodeStatus`
T-106 `LockerCode` con Mod-10	✅	Data class + `LockerCodeGenerator` con `calculateCheckDigit`, `normalize`, `validate`, `format`, `generate`
T-107 `KycRecord`	✅	13 campos con `expiresAt` (10 anios), `reviewedBy`, `rejectionReason`
T-108 `ServiceRequest`	✅	4 `ServiceType` + 10 `ServiceStatus`
T-109 `CustomsCategory`	✅	15 categorias operativas con metadata (`accepted`, `requiresInvoice`, `riskLevel`, `allowsAir`, `allowsSea`, etc.)
T-110 `Consolidation` + `ConsolidationPackage`	✅	8 estados + relacion N:N
T-111 `Quote`, `Payment`, `Charge`, `Invoice`	✅	Modelos con `PaymentMethodMix` (real/credit/card)

2.2 Pantallas de auth y KYC¶

✅ T-301 a T-306: 7 pantallas KYC completas, KycViewModel con StateFlow, banner diferenciado por estado.
✅ Register: valida origen US, dropdown bloqueado a +1 (RegisterScreen.kt:73-76).
✅ Login: placeholders, toggle de visibilidad, links a ForgotPassword / Register.
✅ Welcome / Success: usan los PNG reales de IslaImages.kt.

2.3 Pantallas de envio y servicios¶

✅ T-401: 4 secciones en el dashboard (en almacen / en transito / enviados / entregados), con PaquetesFilter por enum.
✅ T-402 / T-203: ShipmentDetailScreen con timeline de 16 estados (ShipmentStatus.step).
✅ T-501 / T-502 / T-503: lista, alta de inspeccion y alta de devolucion, con FilterChip.

2.4 Stack y configuracion¶

✅ Java 17, AGP 9.1.1, Kotlin 2.2.10, Compose BOM 2026.02.01 (todo vigente).
✅ Reglas ProGuard para kotlinx-serialization agregadas.
✅ Permisos (Internet, Camara, Media, Notifications).
✅ ViewModel + StateFlow adoptados en DashboardViewModel y KycViewModel (cumple T-409 parcialmente).

3. Estado de la vista de consolidacion¶

Hay pantalla, pero el flujo de consolidacion no funciona como dice la doc. Veamos que hay y que falta.

3.1 Lo que existe¶

Componente	Archivo	Estado
`ConsolidationListScreen`	`ui/screens/reporte/ConsolidationListScreen.kt`	Lista con cards + status badge, navega a detalle
`ConsolidationDetailScreen`	`ui/screens/reporte/ConsolidationDetailScreen.kt`	Resumen + paquetes incluidos, status badge
`Consolidation` + `ConsolidationPackage`	`domain/model/`	Modelos correctos con 8 estados
`ConsolidationStatus` enum	`domain/enums/`	8 valores (`BORRADOR`, `EN_PREPARACION`, `COTIZADA`, `PENDIENTE_PAGO`, `PAGADA`, `DESPACHADA`, `ENTREGADA`, `CANCELADA`)
Card en Dashboard	`ConsolidationsActionCard` (Dashboard)	Se muestra solo si `consolidationCount > 0`
Rutas en NavGraph	`Screen.ConsolidationList`, `Screen.ConsolidationDetail`	Registradas y conectadas

3.2 Lo que falta para que el flujo sea correcto (alcance maquetacion visual)¶

Nota: el objetivo de T-406 es dejar el flujo navegable y visible (con datos mockeados en FakeDataSource). No se pretende reemplazar la logica de backend: el lock distribuido de Redis, el calculo real contra la agencia aliada, la persistencia en PostgreSQL son todos temas de la Fase 2.

Comparado con CU-007 el flujo esta roto en su origen:

Paso del CU-007	Estado en APK
1. Acceder a Consolidar desde detalle de paquete o lista "En almacen"	❌ No existe ningun punto de entrada para crear una consolidacion
2. Lista de paquetes con checkbox	❌ No existe `ConsolidationCreateScreen`
3. Seleccion 2+ paquetes -> "Continuar"	❌ No existe
4. Pantalla de resumen (peso, via, destinatario, costo)	❌ No existe
5. Selector de via (Barco $2.40 / Avion $3.35)	❌ No existe (no hay constantes en `AppSettings` para estas tarifas)
6. Validacion KYC aprobado	❌ No existe
7. Lock distribuido / creacion de `Consolidation` + `ConsolidationPackage`	❌ No existe
8. Generacion de `Quote` (vigencia 7 dias)	❌ No existe (el `Quote` actual es mockeado, no se genera desde consolidacion)
9. Cambio de paquetes -> recalculo	❌ No existe

Resultado: las dos consolidaciones que muestra el dashboard (CON-001, CON-002) son estaticas de FakeDataSource. El usuario:

No puede crear una consolidacion propia.
No puede agregar paquetes a una consolidacion desde el detalle del paquete.
No ve costo calculado por peso x via.
No puede elegir barco o avion.
No se le exige KYC aprobado.
No ve flujo a pago/cotizacion tras consolidar.

Ademas hay problemas de navegacion cruzada entre el sub-grafo de la bottom nav y el grafo raiz:

ConsolidationListScreen esta en rootNavController (es ruta top-level, no del bottom nav) -> el usuario pierde la bottom bar al entrar.
ReporteDetalleScreen.onPackageClick en ConsolidationDetailScreen (linea 273) navega a Screen.ReporteDetalle desde la lista de paquetes, pero al volver el usuario termina en la bottom nav, no en la consolidacion (porque popBackStack lo devuelve a la ultima ruta del grafo raiz, que es otra cosa).

3.3 Faltan los flujos alternativos del CU-007¶

FA-1: mensaje "necesitas 2+ paquetes" -> no existe.
FA-3: pantalla de bloqueo KYC -> no existe.
FA-7: cancelar consolidacion (liberar paquetes a en_almacen) -> no existe.
Boton "Ver envio" desde ReporteDetalleScreen para paquetes CONSOLIDADO -> esta en TODO (ReporteDetalleScreen.kt:344).

Conclusion: la vista de consolidacion solo sirve para leer, no para operar. T-406 (ahora en 🔴 Critica) cubre la maquetacion completa: ConsolidationCreateScreen, selector de paquetes, resumen con cálculo de costo, bloqueo KYC, generación de Quote mockeada. Todo guardado en memoria (no PostgreSQL). La integracion con backend llegara en Fase 2.

4. Otros flujos incorrectos o incompletos para el usuario final¶

4.1 🔴 Criticos (bloquean el uso real)¶

4.1.1 Flujo de Pago esta desconectado de Consolidacion¶

ReporteDetalleScreen linea 360: onPayClick = { onPayClick("QUO-001") } -> usa un ID hardcodeado (QUO-001) en vez de buscar la Quote real del envio. Si el paquete no tiene cotizacion, igual lo manda a QuoteScreen mostrando datos de la cotizacion de muestra.
No existe la pantalla CU-008 "Cotizacion y Pago" ligada al Shipment. Las pantallas QuoteScreen, PaymentScreen, InvoiceScreen existen pero nadie las navega de forma natural desde consolidar.

LoginScreen.kt:90-91: onClick = { onLoginClick(email, password) } navega a Main sin validar nada (sin email, sin contrasena, sin rate-limit).
Cumple la doc (gap-mvp.md lo marca como ❌), pero para el usuario final no es un flujo correcto: cualquier toque entra a la app.

4.1.3 `Register` no valida formato email ni requisitos de contrasena¶

gap-mvp.md lo lista como ❌ y sigue asi. El boton se habilita con isFormValid que solo chequea no-vacio y longitud 10 del telefono.
phoneError solo se muestra si hay texto y no es US, pero el selector de pais esta forzado a +1 (linea 154 availableCountries = listOf(countries[0])), asi que en la practica el error nunca se ve.

4.1.4 El campo telefono de destinatarios sigue siendo +53 hardcodeado¶

FakeDataSource.recipients (linea 32) tiene phone = "+53 5555 5555". La doc T-415 (🟠 Alta) pide que el campo phone de Contact/Recipient acepte +53 (8 digitos) y +1 (10 digitos), pero la IslaPhoneField actual solo soporta +1.
El usuario no puede agregar destinatarios con telefonos reales de Cuba o EE.UU. correctamente.

4.1.5 Busqueda de paquetes - el dashboard no tiene buscador¶

PaquetesScreen solo filtra por PaquetesFilter desde el dashboard. No hay busqueda por tracking, tienda, destinatario. La doc pantallas-mvp.md no lo exige explicitamente, pero para 50+ paquetes se vuelve inmanejable.

4.2 🟠 Altos (UX rota o confusa)¶

4.2.1 `ReportActionBanner` en el dashboard lleva a "Reportes" pero al usuario probablemente quiere crear un reporte nuevo¶

DashboardScreen.kt linea 199: onClick navega a Screen.Dashboard.Reportes (la lista), no a Screen.Dashboard.ReporteForm. El usuario que toca "Reportar compra" espera el formulario, no una lista donde debe volver a tocar el FAB.
La FAB si esta en la lista de reportes (ReportesScreen.kt:135), pero el banner no.

4.2.2 `NotificationsScreen` con notificaciones inventadas¶

FakeDataSource.notifications tiene 12 notificaciones estaticas, pero la pantalla las muestra como si fueran reales. No hay marca de "demo" o seed-data badge. El usuario podria pensar que paso todo eso en su cuenta recien creada.
Es un buen ejemplo de datos demo que se confunden con datos reales.

4.2.3 Seccion "Consolidaciones" del dashboard aparece condicional con logica rara¶

DashboardScreen.kt:213: solo se muestra if (consolidationCount > 0). Si el usuario no tiene consolidaciones, no tiene como saber que esa funcionalidad existe. La doc dice que consolidar es un caso de uso clave (CU-007).

4.2.4 El dashboard no muestra el estado KYC en la cabecera¶

Solo aparece el KycBanner cuando kycStatus != APPROVED. Si esta APPROVED, no hay confirmacion visual. Para un usuario que paso por un proceso de 6 pantallas, seria bueno un check verde pequeno.

4.2.5 `ReporteDetalleScreen` muestra `reporte.destinatarioId` como texto crudo¶

Linea 234: DetalleMini(label = "Destinatario (Cuba)", value = reporte.destinatarioId ?: "No asignado") -> deberia mostrar el nombre del destinatario, no el ID. El usuario ve CONT-001 en vez de "Juan Perez".

4.2.6 `ReporteDetalleScreen` Acciones disponibles tiene handlers vacios¶

ActionButtonsGroup recibe la lista pero el when solo maneja "Solicitar inspeccion" y "Solicitar devolucion". Los botones "Solicitar reempaque", "Agregar a consolidacion" y "Enviar solo" no hacen nada al tocarse (linea 282: // TODO: Otras acciones).

4.2.7 `PerfilScreen` - la mayoria de items son `onClick` vacios¶

"Informacion personal", "Metodos de pago", "Notificaciones", "Ayuda", "Privacidad" -> todos sin handler (lineas 67-105). "Cerrar sesion" tampoco tiene logica (linea 119: /* Logout logic */).
El usuario ve un menu profesional pero todo esta roto.

4.3 🟡 Medios (calidad de codigo/extensibilidad)¶

4.3.1 `AppSettings.kt` tiene valores desactualizados¶

Linea 21-22: FREE_STORAGE_DAYS = 5 (debe ser 15), STORAGE_DAILY_COST = 1.00 (debe ser 0.50), STORAGE_WARNING_DAYS = 1 (debe ser 3 o 5).
Las decisiones de negocio estan resueltas en preguntas.md pero el codigo no las refleja. Tarea T-206b lo cubre.

4.3.2 No existen constantes para tarifas de envio¶

AppSettings no define SHIPPING_RATE_SEA = 2.40 ni SHIPPING_RATE_AIR = 3.35. La QuoteScreen muestra valores estaticos del FakeDataSource.quotes, no calcula nada.

4.3.3 Enums desalineados con la doc¶

Tarea T-405 documenta que faltan 6 estados fisicos, 1 estado de prealerta y los renombres de 3 estados. Ejemplo: REPORTADA_SIN_TRACKING esta como PENDIENTE_TRACKING en codigo. Esto rompe la trazabilidad con la doc.

4.3.4 `ConsolidationDetailScreen` navega mal al volver¶

Como vimos en §3, navegar a ReporteDetalle desde la consolidacion hace que el back del sistema cierre la app o vuelva a un destino inconsistente.

4.3.5 Strings en espanol hardcodeados¶

Varios strings de la seccion consolidacion estan en espanol hardcodeado en los .kt ("Consolidaciones", "No tienes consolidaciones activas", "Estado", "Peso Total") en vez de estar en res/values/strings.xml. La doc discrepancias.md §10 lo marca como deuda de ~80 strings.

4.3.6 Inconsistencia `namespace` en Manifest¶

Tarea T-413 critica: app/build.gradle.kts define namespace = "com.islabox.app" pero el AndroidManifest.xml declara com.example.islabox.MainActivity. El build tira warnings, R resuelve a com.islabox.app.R (lo cual ya se usa en RegisterScreen.kt:17).

5. Tabla resumen de prioridades¶

#	Problema	Impacto usuario	Tarea nueva	Recomendacion
1	Flujo de consolidacion no permite crear	🔴 Critica	T-406 (promovida)	Crear `ConsolidationCreateScreen` con seleccion multiple, calculo, via, KYC check, generacion de `Quote`
2	Pago hardcodeado `QUO-001` desde detalle	🔴 Critica	T-422	Cambiar `onPayClick` para que reciba la `Quote` real del `Shipment` o navegar a flujo de pago
3	Login entra sin validar	🔴 Critica	T-426	Validar email, contrasena, agregar estado `error`
4	Perfil 90 % de opciones sin handler	🔴 Critica	T-423	Implementar al menos los 3 mas importantes (editar info, direcciones, cerrar sesion)
5	`ReportActionBanner` lleva a lista, no a form	🟠 Alta	T-424	Cambiar `onClick` para que vaya a `ReporteForm`
6	Destinatario se muestra como ID	🟠 Alta	T-425	Hacer join con `FakeDataSource.recipients`
7	Botones de accion en `ReporteDetalle` sin handler	🟠 Alta	T-428	Conectar "Agregar a consolidacion" -> flujo nuevo; "Enviar solo" -> cotizacion individual
8	`AppSettings` desactualizado	🟠 Alta	T-206b	Actualizar a 15 / 0.50
9	`Register` no valida email ni password	🟠 Alta	T-427	Regex + requisitos minimos
10	`IslaPhoneField` no internacional para destinatarios	🟠 Alta	T-415	Crear variante `IslaPhoneFieldInternational`
11	6 estados fisicos + 1 prealerta faltan en enums	🟡 Media	T-405	Agregar al enum correspondiente
12	`namespace` vs Manifest	🟡 Media	T-413	Sincronizar
13	Strings hardcodeados en espanol	🟡 Media	Discrepancias §10	Mover a `strings.xml`
14	`consolidationCount == 0` no muestra entrada al feature	🟡 Media	T-406	Mostrar card "Crear tu primera consolidacion"
15	Notificaciones demo confundibles con reales	🟢 Baja	T-429	Marcar como seed con badge "Demo" en MVP

6. Recomendacion concreta para empezar (alcance maquetacion visual)¶

Si tuviera que elegir 3 tareas para que el usuario pueda recorrer el flujo visualmente sin backend, atacaria en este orden:

T-406 — Maquetar el flujo de Consolidacion completo: ConsolidationCreateScreen con checkboxes, resumen con peso/via/destinatario/costo, bloqueo visual de KYC, ConsolidationSummaryScreen con la Quote mockeada. Todo persiste en FakeDataSource.consolidations (memoria).
T-422 + T-428 — Enlazar ReporteDetalle con su Quote correspondiente: helper findQuoteForReporte en FakeDataSource, botones "Enviar solo" y "Ver envio" navegan a la Quote correcta. Ya no mas QUO-001 hardcodeado.
T-423 — Cablear navegacion del Perfil: reusar ContactosScreen para Direcciones, crear EditProfileScreen y PaymentMethodsScreen (mockeadas), "Cerrar Sesion" navega a Screen.Welcome.

El resto (validaciones de cliente T-426/T-427, enums T-405, strings a strings.xml, namespace T-413, consolidationCount==0 T-406, badge Demo T-429) se puede hacer en paralelo como limpieza visual sin afectar el flujo de cara al usuario en demos.

7. Trazabilidad con las tareas vigentes¶

Este informe se refleja en:

tareas.md -> Bloque B actualizado (T-406 promovida a Critica) + Bloque D con 8 tareas nuevas (T-422 a T-429) + Tabla resumen al 2026-06-07.
discrepancias.md -> Resumen actualizado + nueva seccion 12 con D-12.1 a D-12.9 (problemas de flujos de usuario).
gap-mvp.md -> pendiente: los Flujos 8, 9 y 10 siguen con la copia original (todo en ❌). Falta reescribirlos con la separacion "existe / falta / bloqueante para usuario final" y el alcance de maquetacion visual.
tareas.md -> Bloque D (T-422 a T-429) reorientado a maquetacion visual sin backend, con "Alcance MVP visual" explicito en cada tarea.
discrepancias.md -> Resumen actualizado + nueva seccion 12 con D-12.1 a D-12.9.