# Diseño: evidencias reales para verificar prestadores ## Objetivo Impedir que un prestador solicite verificaciones que no puede demostrar por sí mismo. El portal sólo permitirá enviar evidencias para identidad, empresa/comercio y documentos de respaldo. El correo se derivará de la cuenta, el teléfono permanecerá deshabilitado hasta existir SMS/OTP y la certificación MyCode será exclusivamente administrativa. ## Decisiones funcionales ### Tipos disponibles para el prestador El formulario y el endpoint del propietario aceptarán únicamente: - `identity`: documento que permita comprobar la identidad del responsable. - `business`: documento comercial y/o fotografía del comercio. - `documents`: otro documento de respaldo pertinente. La restricción se aplicará en la API y nuevamente en el puente web. Ocultar opciones en la interfaz no será considerado una medida de seguridad. Los enums conservarán `email`, `phone` y `mycode` para poder leer registros históricos y mantener los contratos administrativos existentes, pero el propietario no podrá crear nuevos registros de esos tipos. ### Correo, teléfono y MyCode - El portal mostrará el estado del correo como información de sólo lectura, obtenido de `email_verified_at` en la sesión de la cuenta. - El teléfono no aparecerá como opción de verificación mientras no exista una prueba server-side generada por SMS/OTP. Declarar un número no será equivalente a verificarlo. - `mycode_verified` seguirá disponible para la administración, pero `mycode` desaparecerá del formulario del prestador y será rechazado por los endpoints de propietario. ## Evidencias múltiples Una solicitud de verificación aceptará uno o dos archivos en `evidence[]`. Cada archivo podrá ser: - PDF (`application/pdf`) - JPG/JPEG (`image/jpeg`) - PNG (`image/png`) Cada archivo tendrá un máximo de 10 MB. Al menos uno será obligatorio para los tres tipos disponibles. Esto permite enviar sólo un documento, sólo una fotografía o ambos respaldos en la misma solicitud. El formulario utilizará un selector múltiple con ayuda explícita y mostrará los nombres de los archivos elegidos antes de enviar. ## Modelo de datos Se agregará `service_provider_verification_evidences` con: - UUID primario. - UUID de `service_provider_verifications` con borrado en cascada. - Ruta privada del archivo. - MIME validado. - Nombre original saneado sólo para presentación. - Tamaño en bytes. - Timestamps. Cada verificación tendrá una relación `evidences`. No se guardarán rutas en JSON. Los registros existentes que tengan `document_path` se migrarán a la nueva tabla sin mover el archivo físico. `document_path` permanecerá temporalmente para compatibilidad de rollback, pero las lecturas nuevas usarán la relación. No se perderán verificaciones ya revisadas. ## Almacenamiento y seguridad Los archivos continuarán en el disco privado `service-provider-private`. La creación de la verificación y sus evidencias será atómica desde la perspectiva de la aplicación: 1. Se validan tipo, cantidad, MIME real y tamaño. 2. Se guardan los archivos con nombres generados por servidor. 3. Se crea la verificación pendiente y sus evidencias dentro de la mutación bloqueada del prestador. 4. Ante cualquier fallo se eliminan todos los archivos ya almacenados. Las respuestas públicas y del propietario nunca incluirán rutas. La administración recibirá sólo UUID, MIME, nombre y tamaño. ## Revisión administrativa El detalle administrativo mostrará una acción de descarga por evidencia. Cada descarga comprobará: - permiso `verify_service_providers`; - pertenencia de la evidencia a la verificación solicitada; - existencia del archivo privado; - respuesta `private, no-store`. La aprobación o rechazo seguirá ocurriendo sobre la solicitud completa, no sobre archivos individuales. La certificación `mycode_verified` continuará siendo una decisión administrativa separada. El endpoint singular de documento se mantendrá durante la transición para registros antiguos, mientras las nuevas evidencias usarán rutas identificadas por UUID. ## Interfaz bilingüe El portal español e inglés actualizará: - opciones del selector; - estado de correo de cuenta; - ayuda para documento/fotografía; - contador de archivos; - validaciones de cantidad, formato y tamaño; - listado de evidencias enviadas. La administración mostrará nombres neutrales de evidencia y conservará el idioma actual del panel. ## Compatibilidad y manejo de errores - Las solicitudes antiguas con `verification_type=email`, `phone` o `mycode` recibirán `422`. - El campo singular `document` dejará de ser el contrato de creación nuevo; el puente sólo enviará `evidence[]`. - Las respuestas inválidas no crearán verificación ni dejarán archivos huérfanos. - Borrar una verificación pendiente eliminará todas sus evidencias privadas. - Archivar un prestador conservará los registros de auditoría definidos, pero mantendrá la política existente de purga de medios privados cuando corresponda. ## Pruebas de aceptación ### API - Rechaza tipos de propietario `email`, `phone` y `mycode`. - Acepta `identity`, `business` y `documents`. - Exige entre uno y dos archivos. - Acepta PDF/JPG/PNG y rechaza otros MIME o archivos mayores a 10 MB. - Guarda uno o dos registros de evidencia sin exponer rutas. - Limpia todos los archivos si falla la persistencia. - Migra documentos históricos sin duplicarlos. - Autoriza y descarga cada evidencia sólo para administración. ### Web - El selector contiene exactamente tres opciones. - El correo aparece sólo como estado derivado de la cuenta. - No hay opción de teléfono ni MyCode. - El formulario admite uno o dos archivos y rechaza tres. - El puente revalida tipos y archivos antes de llamar a la API. - Los textos y errores funcionan en español e inglés. - Administración lista y descarga ambas evidencias. ### Regresión - Login clásico y verificación de correo de cuenta no cambian. - Moderación, archivado, catálogos y perfiles públicos siguen funcionando. - Los registros de verificación históricos siguen siendo legibles.