SLA no contractual
El tiempo de KYC "≤ 24 horas" sigue siendo una referencia operativa, no un compromiso contractual con el usuario (D-114). El mensaje en UI debe sustituirlo por "Te avisaremos por notificación".
Criterios de aceptación del MVP¶
Documento de cierre — 2026-06-08 (v2)
Define cuándo el MVP está realmente listo para salir a beta cerrada con los primeros 50–100 usuarios de EE.UU. Los 13 criterios son el checklist de salida del MVP.
Si un criterio de esta lista no se cumple, el MVP no está listo para lanzamiento beta, sin importar cuántas pantallas extras estén implementadas.
Relación con otros documentos:
- alcance-mvp.md → qué entra (alcance).
- Este documento → cómo se sabe que está terminado (los 13 CA con sus checklists).
1. Definición de "MVP listo"¶
El MVP de IslaBox está listo cuando un usuario de EE.UU. puede comprar en Amazon/SHEIN/Temu → recibir su casillero → consolidar → pagar → ver su envío salir hacia Cuba sin necesidad de asistencia manual externa (más allá del operador de almacén, que sí es parte del sistema).
Hay 13 criterios de aceptación. Si los 13 se cumplen → MVP listo.
2. Los 13 criterios de aceptación¶
CA-01 — Registro y verificación inicial¶
Un usuario nuevo debe poder:
- Registrarse con email, teléfono
+1(10 dígitos), nombre y contraseña. - Recibir OTP por SMS para verificar el teléfono.
- Verificar el email mediante enlace.
- Obtener su identificador
CP-XXXXXX-Dautomáticamente. - Ver su dirección de casillero en Miami, FL lista para copiar.
Reglas asociadas: RN-001, RN-002, RN-003, RN-004.
Verificación: Ejecutar TC-001, TC-002, TC-003 del plan de pruebas. Tiempo objetivo: ≤ 3 minutos desde el primer tap hasta ver la dirección.
CA-02 — Login y persistencia de sesión¶
Un usuario registrado debe poder:
- Iniciar sesión con email y contraseña.
- Mantener la sesión activa entre reinicios de la app (token persistente).
- Cerrar sesión y volver al login.
- Recuperar contraseña mediante el canal que se apruebe en D-201. Este criterio queda bloqueado hasta esa decisión.
Reglas asociadas: RN-008.
Verificación: TC-004, TC-005, TC-006.
CA-03 — Reportar una compra (prealerta)¶
Un usuario debe poder:
- Crear una prealerta con los campos mínimos que se aprueben en D-203. Las reglas de remitente y destinatario permanecen pendientes de D-206.
- Actualizar el tracking de la prealerta cuando lo tenga.
- Adjuntar al menos 1 foto de la orden.
- Ver sus prealertas en una lista con estado visible.
Reglas asociadas: RN-010, RN-011.
Verificación: TC-013, TC-014, TC-015, TC-017.
CA-04 — Recepción de paquete en almacén (backoffice)¶
Un operador debe poder:
- Recibir un paquete físico: tomar fotos (etiqueta + contenido), registrar peso, dimensiones, ubicación.
- Identificar el casillero al que pertenece (por
CP-XXXXXX-Do por tracking). - Crear el paquete en estado
en_almacencon suphysical_package_id. - Marcar como
pendiente_conciliacionsi no logra identificarlo. - Ver la cola de conciliación y asignar manualmente un paquete a un usuario.
Reglas asociadas: RN-010, RN-012, RN-015, RN-016, RN-017, RN-018.
Verificación: TC-018, TC-027, TC-028.
CA-05 — Ver paquete recibido y notificaciones¶
Un usuario debe poder:
- Ver sus paquetes con foto, estado, peso, dimensiones, días en almacén, fecha límite sin cargo.
- Ver el timeline de eventos del paquete (16 estados de
ShipmentStatus). - Recibir push cuando el paquete es recibido, identificado, o queda con 3 días para vencer el período gratis.
- Ver notificaciones agrupadas en una pantalla con marca de leídas/no leídas.
Reglas asociadas: RN-031, RN-033, RN-036.
Verificación: TC-019, TC-039, TC-041.
CA-06 — KYC completo (verificación de identidad)¶
Un usuario debe poder:
- Iniciar el KYC cuando intenta consolidar o despachar por primera vez.
- Cargar: tipo de documento, número, foto frente, foto reverso, selfie con documento, dirección de residencia en EE.UU.
- Ver el estado de su KYC en el dashboard con banner diferenciado.
- Recibir push cuando el KYC cambia de estado.
Un operador debe poder:
- Ver la cola de KYC pendientes.
- Aprobar, rechazar (con motivo) o requerir más información.
- Ver documentos adjuntos (con datos enmascarados en la previsualización).
Reglas asociadas: RN-040, RN-041, RN-042, RN-043, RN-044, RN-045, RN-102.
Verificación: TC-030, TC-031, TC-032.
CA-07 — Destinatarios y remitentes¶
Un usuario debe poder:
- Gestionar destinatarios y remitentes conforme a D-206. Este criterio queda bloqueado hasta definir conceptos, edición y valores predeterminados.
Reglas asociadas: RN-005, RN-006, RN-007, RN-021, RN-022.
Verificación: TC-042, TC-043, TC-044.
CA-08 — Crear consolidación¶
Un usuario con KYC aprobado debe poder:
- Seleccionar 2+ paquetes propios en estado
listo_para_consolidaroen_almacen. - Elegir la vía de envío (barco $2.40/lb o avión $3.35/lb).
- Elegir el destinatario conforme a D-206.
- Ver el resumen: peso total, costo de envío, costo de consolidación, aduana estimada, total.
- Confirmar y generar la
Consolidation+ConsolidationPackage+Quote(vigencia 7 días). - Ver la consolidación en su lista y en el detalle.
Reglas asociadas: RN-020, RN-023, RN-024, RN-026, RN-061, RN-063.
Verificación: TC-021, TC-022, TC-023, TC-024.
CA-09 — Pago y confirmación de envío¶
Un usuario debe poder:
- Aprobar la cotización.
- Ver el desglose y seguir el canal manual que se apruebe en D-208; no se muestran métodos alternativos.
- Ver la factura generada con sus 9 conceptos.
- Recibir push cuando el pago es confirmado y el envío está listo para despacho.
Un operador debe poder:
- Registrar y validar el pago manual según la evidencia y el canal que defina D-208.
- Confirmar el despacho de una consolidación pagada (asignar
master_guide,carrier, marcardespachado_desde_almacen). - Ver la cola de envíos por despachar.
Reglas asociadas: RN-025, RN-070, RN-071, RN-072, RN-073, RN-074, RN-075.
Verificación: TC-025, TC-026.
CA-10 — Tracking del envío en tránsito¶
Un usuario debe poder:
- Ver el estado actual de su envío en el detalle (uno de los 16 estados de
ShipmentStatus). - Ver el timeline de eventos.
- Recibir push en eventos clave:
despachado_desde_almacen,en_aduana,liberado_de_aduana,entregado.
Reglas asociadas: RN-041, RN-104.
Verificación: TC-019, TC-041.
CA-11 — Servicios adicionales (MVP subset)¶
Un usuario debe poder:
- Solicitar inspección visual sobre un paquete propio.
- Solicitar reempaque sobre un paquete propio.
- Solicitar devolución sobre un paquete propio.
- Aprobar el costo del servicio antes de su ejecución.
- Ver el estado del servicio solicitado.
- Ver la evidencia (fotos, videos) cargada por el operador.
Un operador debe poder:
- Cargar evidencia de un servicio ejecutado.
- Cambiar el estado del servicio (solicitado → en_proceso → completado).
Reglas asociadas: RN-050, RN-051, RN-052, RN-053, RN-054.
Verificación: TC-033, TC-034.
CA-12 — Incidencias y reclamos (MVP subset)¶
Un usuario debe poder:
- Abrir una incidencia sobre un paquete propio (categoría + descripción + fotos).
- Ver el estado de sus incidencias.
- Recibir notificación cuando hay respuesta del operador.
Un operador debe poder:
- Ver la cola de incidencias.
- Responder, cambiar estado, escalar.
- Cerrar con resolución (incluye iniciar reembolso si aplica).
Reglas asociadas: RN-100, RN-101, RN-104, RN-110 a RN-118.
Verificación: TC-035, TC-036, TC-037, TC-038.
CA-13 — Auditoría y seguridad básica¶
- Todo cambio de estado queda registrado en
audit_logsconactor_id,old_status,new_status,ip,timestamp(RN-100). - El acceso a documentos KYC ajenos se registra con datos enmascarados para
operator(RN-102). - Las URLs de MinIO para evidencia son prefirmadas con expiración de 5 minutos (RN-103).
- Los webhooks externos (cuando existan) se autentican por firma y quedan auditados (RN-105, RN-106, RN-108).
Verificación: Tests de seguridad + revisión manual de logs.
3. Cómo se usa este documento¶
- Antes de empezar un sprint: el equipo de producto revisa los CA cubiertos por el sprint y confirma cuáles se mueven a "Hecho".
- En cada demo: se muestra evidencia de los CA incrementales (capturas, grabaciones, métricas).
- Pre-lanzamiento: el PM y el tech lead hacen un walkthrough de los 13 CA y firman el "Listo para beta".
- Post-lanzamiento: el equipo mide las 9 métricas de éxito definidas en
alcance-mvp.md §5durante 60 días.
Si en el walkthrough pre-lanzamiento algún CA queda rojo, el lanzamiento se retrasa hasta que se cierre.