Eres un/a arquitecto/a de software + full-stack senior. Diseña y genera (con código, migraciones y documentación) un sistema web llamado **“Reporta”** para **reporte de incidentes, actos y condiciones subestándar**, pensado para **uso principal en celular** y desplegado en **cPanel**. Debe funcionar con **PHP + MySQL**, idealmente con **Laravel** compatible con hosting compartido/cPanel). Prioriza: UX móvil, escalabilidad, seguridad, y que el sistema sea **configurable desde BD** (evitar hardcodear opciones del formulario). ======================== 1) OBJETIVO DEL SISTEMA ======================== - Los trabajadores deben poder **crear reportes rápidamente** desde el celular, con un formulario claro, rápido y tolerante a conexión lenta. - Para acceder al formulario no se necesitara logearse - Los supervisores/SUMA deben poder: - Ver todos los reportes, filtrarlos, completar la **Parte B** (acción correctiva), asignar supervisor, y gestionar plazos. - Exportar e imprimir reportes en **PDF** con firmas (reportante + supervisor). - Exportar datos a **Excel** y generar métricas/tablas. - Administrar usuarios y catálogos (opciones del formulario). ======================== 2) ROLES Y ACCESOS ======================== Implementa autenticación y autorización por roles (Laravel Gates/Policies o Spatie Roles si aplica): - Rol: TRABAJADOR - Crear reporte (Parte A + firma + fotos). - Ver su propio reporte creado (opcional) y estado. - NO ve dashboard global, NO gestiona usuarios. - No necesita logearse - Rol: SUPERVISOR - Ver reportes (según alcance: por área/campamento o global configurable). - Completar Parte B (acción correctiva), firmar, asignar plazo, cambiar estado. - Acceso a dashboard - Rol: ADMIN - Acceso a dashboard completo, métricas, exportaciones, gestión de catálogos, usuarios, permisos, configuración. IMPORTANTE: - El login NO debe estorbar al trabajador al momento de reportar. Diseña un flujo “rápido” (por ejemplo: QR / enlace directo a formulario que pide identificación simple y firma, pero sin exponer panel admin). - El dashboard es solo para SUPERVISOR/ADMIN. ======================== 3) FORMULARIO (REPORTE) ======================== Título visible: **“Reporte de incidentes, actos y condiciones subestándar”** Debe mostrar dos secciones claras: **Parte A** y **Parte B**. -------------------------------- Parte A (Trabajador) -------------------------------- Subtítulo: “Para ser llenado con letra clara y legible por el trabajador.” Campos: A1) Tipo (selección ÚNICA, radio o select): 1. Condición subestándar 2. Acto subestándar 3. Incidente ambiental 4. Incidente 5. Daño de propiedad 6. Número de tipo de causa REQUISITO: NO hardcodear. Debe venir de una tabla “catálogo” en BD, administrable (activar/desactivar, ordenar). A2) Lugar (select o autocomplete desde BD): - Ejemplos: Campamento de trabajadores, Área de Proveo, etc. REQUISITO: configurable en BD (catálogo de lugares). A3) Fecha: - Debe traer automáticamente la fecha y hora actual del servidor (y mostrarla). Guardar timestamp. A4) Reportado por: - Opción: escribir nombre o elegir de lista desplegable alimentada desde BD (usuarios activos). - Ideal: el usuario autenticado se preselecciona; permitir editar solo si rol lo permite. - añadir la opcion de anonimo , en este caso es obligartorio una foto como minimo A5) Área: - Catálogo desde BD. - en configuracion debe de poder debe de poder agregar areas -Cancha 1 -Cancha 2 -Cancha 3 -Cancha 4 -Cancha 5 -Cancha 6 -Cancha 7 -Cancha 8 -Planta - Chala A6) Turno: - Día / Noche (catálogo desde BD, no hardcodeado). A7) Descripción (campo PRINCIPAL): - Textarea grande, fácil de escribir en móvil. - Máximo 500 caracteres. - El diseño debe ser agradable para escribir en celular - Mostrar contador de caracteres y mensajes claros de validación. A8) Nivel de riesgo: - 1 Alto, 2 Medio, 3 Bajo (catálogo en BD). A9) Nivel de consecuencia (solo aplicable a “Incidente ambiental”, basado en ISO 14001 / Anexo 2): - Sin impacto, Bajo, Moderado, Mayor, Catastrófico (catálogo en BD). - Regla UX: si el tipo NO es “Incidente ambiental”, ocultar/deshabilitar y guardar NULL o “No aplica”. A10) Fotografías: - Permitir tomar y subir hasta **3 fotos** desde celular. - Guardar en storage (preferible: storage/app/public con symlink; compatible cPanel). - Validar tamaño y tipo (jpg/png/webp), comprimir/optimizar. A11) Firma del trabajador (firma digital): - Captura de firma con canvas táctil. - Guardar como imagen (PNG) o como vector/base64 que luego se renderiza a PNG. - Debe quedar asociada al reporte y aparecer en el PDF. -------------------------------- Parte B (Supervisor) -------------------------------- Subtítulo: “Para ser llenado de forma clara y legible por el supervisor.” Se llena A POSTERIOR, desde un módulo de revisión. Campos: B1) Acción correctiva (texto): - Ejemplo: “Derivación a RR.HH. para proceso disciplinario y sensibilización.” - Campo obligatorio al cerrar/firmar. B2) Supervisor asignado: - Desplegable desde BD (usuarios con rol SUPERVISOR activos). - Autoasignar al supervisor que edita, pero permitir reasignación si rol ADMIN/SUMA. B3) Firma del supervisor: - Se almacenan firmas de supervisores en PNG (cargadas en el sistema). - Al firmar/cerrar, asociar la firma PNG correspondiente al supervisor. - Opción: permitir que el supervisor firme en el momento también (si se decide), pero requisito mínimo: firma PNG guardada. B4) Plazo de ejecución: - Elegir en lista (por horas): por ejemplo 4, 8, 12, 24, 48, 72… (catálogo en BD). - Guardar fecha límite calculada (created_at + horas) y mostrar. B5) Estado del reporte: - Nuevo / En revisión / Acción definida / Cerrado (catálogo en BD). ======================== 4) DASHBOARD Y MÉTRICAS ======================== En panel SUPERVISOR/SUMA: - Lista de reportes con filtros: - Por fecha (rango), por mes, por lugar, área, turno, tipo, riesgo, estado, supervisor. - KPIs: - Total reportes por mes - Distribución por tipo - Distribución por lugar/área - Riesgo (alto/medio/bajo) por periodo - Incidentes ambientales y su consecuencia - Cumplimiento de plazos (vencidos vs a tiempo) - Exportación: - Excel/CSV de reportes filtrados. - Exportar PDF individual. - Exportar PDF masivo “por mes” o “rango”. ======================== 5) PDF / IMPRESIÓN ======================== Generar PDF con: - Encabezado con datos del reporte (tipo, lugar, fecha, reportado por, área, turno, riesgo, consecuencia). - Parte A (descripción) y fotos (miniaturas ordenadas). - Parte B (acción correctiva, supervisor, plazo, estado) y firma del supervisor. - Debe poder imprimirse sin romper el diseño. - añadir la firma del trabajador y firma del responsable Usar una librería típica Laravel (DOMPDF / Snappy / mPDF) ======================== 6) BASE DE DATOS (NO HARDCODE) ======================== Diseña un esquema normalizado donde: - Todas las opciones del formulario provengan de tablas catálogo: - tipos_reporte - lugares - areas - turnos - niveles_riesgo - niveles_consecuencia - plazos_horas - estados_reporte Cada catálogo debe soportar: id, nombre, activo, orden, created_at, updated_at. - Tabla principal: reportes - id, tipo_id, lugar_id, area_id, turno_id, riesgo_id, consecuencia_id (nullable), descripcion(<=500), reportado_por_user_id (nullable), reportado_por_texto (nullable), firma_trabajador_path, supervisor_id (nullable), firma_supervisor_path (nullable), accion_correctiva (nullable), plazo_horas_id, fecha_limite (nullable), estado_id, created_at, updated_at. - Tabla: reporte_fotos - id, reporte_id, path, orden, created_at. - Usuarios: - email/username, password hash, nombre completo, rol, activo, firma_png_path (para supervisores), etc. Incluye seeds iniciales para catálogos (pero que luego se editen en UI). ======================== 7) UI/UX MÓVIL (PRIORIDAD) ======================== - Interfaz “mobile-first”, clara, botones grandes, inputs cómodos. - Parte A: flujo tipo “paso a paso” o “secciones” para evitar scroll eterno (decide la mejor UX). - Validaciones en tiempo real (contador de caracteres, máximo 4 fotos). - Modo oscuro opcional (bonus). - Debe ser fácil firmar con el dedo. Tecnologías UI: - Puedes usar Blade + TailwindCSS o Bootstrap 5. - Evita componentes pesados. Debe ir fluido en celulares gama media. ======================== 8) SEGURIDAD Y BUENAS PRÁCTICAS ======================== - CSRF, validación robusta, sanitización, control de uploads, límites de tamaño. - Autorización por roles a nivel de rutas/controladores. - Password hashing (bcrypt/argon2). - Registro de auditoría (bonus): quién creó/actualizó Parte B, timestamps. - No exponer rutas admin. ======================== . ======================== 10) ENTREGABLES QUE DEBES GENERAR ======================== A) Arquitectura y explicación breve (módulos, flujo de datos). B) Modelo de BD: diagrama lógico (texto) + migraciones Laravel. C) Seeders para catálogos. D) CRUD UI para catálogos (solo admin/suma). E) Formulario Parte A (trabajador) con firma + fotos. F) Módulo de revisión para Parte B (supervisor) con firma PNG. G) Dashboard con filtros + export Excel + PDF individual y masivo. H) Pruebas mínimas (Feature tests básicos) y validaciones. I) Manual rápido de uso (trabajador y supervisor) + manual admin. J) Checklist final de seguridad y performance. ======================== 11) RESTRICCIONES Y DECISIONES ======================== - No hardcodees listas: todo debe venir de BD, editable. - Prioriza que el sistema sea mantenible y ampliable (más opciones/catálogos a futuro). - Mantén el código limpio: MVC, Services/Repositories si aporta valor, DTOs opcional. - Da nombres claros: “Reporta” en branding básico. ======================== 12) SALIDA ESPERADA DE LA IA ======================== Genera: 1) Estructura del proyecto Laravel (rutas, controladores, modelos, migraciones, vistas, componentes). 2) Código completo (o lo más completo posible) para ejecutar localmente y desplegar en cPanel. 3) Instrucciones de instalación y despliegue. Comienza por: - Proponer el esquema de BD final. - Luego generar migraciones y seeders. - Luego autenticación/roles. - Luego UI móvil Parte A. - Luego módulo Parte B. - Luego PDF/Exports. - Finalmente dashboard/métricas. Fin del prompt.