Un flujo de soporte que puede entenderse de principio a fin
La aplicación nace de una necesidad cercana a mi experiencia en soporte técnico: registrar incidencias, conservar el contexto del problema y permitir que el usuario consulte el estado de su solicitud sin depender de mensajes dispersos.
Usuarios y alcance
El usuario puede iniciar sesión, consultar sus tickets, crear una incidencia y revisar el detalle con su historial. Existe un perfil administrativo de demostración en los datos, pero la interfaz todavía no implementa un panel administrativo con permisos diferenciados.
Una demo funcional antes de conectar servicios externos
Autenticación de demo
Login, registro y cierre de sesión para recorrer el producto sin configurar una infraestructura externa.
Tickets
Creación, listado y consulta del detalle de incidencias con categoría, prioridad, estado y descripción.
Historial
El detalle de un ticket puede mostrar comentarios y eventos almacenados en el modelo de prueba.
Evolución preparada
El repositorio incluye esquema y conexión opcional para migrar la persistencia hacia PostgreSQL/Supabase.
La persistencia local hace reproducible el primer recorrido
El modo predeterminado usa un archivo JSON y funciones de acceso local. Las API Routes aíslan al frontend del almacenamiento y permiten sustituir el adaptador sin rediseñar todas las pantallas.
Next.js App Router login / dashboard / ticket detail │ ├── React + TypeScript + Tailwind + Radix UI │ API Routes auth / tickets / comments │ ├── lib/mock-db.ts → data/mock-data.json │ └── lib/db.ts → PostgreSQL opcional Deployment: Vercel demo · no se garantiza persistencia del JSON en serverless
Decisiones técnicas y límites explícitos
- El modo JSON reduce la fricción para revisar el producto y ejecutar la demo sin credenciales de servicios externos.
- La documentación mantiene separado el modo demostrativo de la alternativa PostgreSQL, evitando confundir configuración con migración terminada.
- La UI se centra en el recorrido esencial de soporte, en lugar de simular un sistema empresarial que todavía no tiene sus permisos implementados.
- La sesión actual usa localStorage y es suficiente para la demostración, pero requiere cookies seguras o un proveedor de identidad antes de producción.
Mi participación
Diseñé y construí el flujo de la aplicación, sus pantallas y API Routes, y documenté la ruta de evolución hacia PostgreSQL con las diferencias que todavía deben resolverse.
IA aplicada con revisión del resultado
El proyecto forma parte de mi flujo de desarrollo asistido por IA: descomposición del requerimiento, exploración de componentes, implementación, depuración y documentación. No presento el sistema como código generado automáticamente ni atribuyo a este repositorio una instrucción de Copilot versionada que no está publicada aquí.
Iteración rápida
La IA ayuda a comparar alternativas y reducir el tiempo entre una idea de producto y un flujo navegable.
Validación humana
Las rutas, estados, mensajes y límites se revisan en ejecución; las decisiones de seguridad no se delegan al modelo.
Qué demuestra hoy y qué no
- La demo pública permite recorrer login, dashboard, creación y consulta de tickets.
- El README describe las rutas de API y la estructura necesaria para el modo JSON y PostgreSQL.
- El repositorio no debe presentarse todavía como un sistema productivo con autorización server-side completa.
- El workflow de GitHub Actions publicado es manual y está orientado a corregir el seguimiento de archivos; no es evidencia de CI/CD completo.
- La persistencia en JSON no es confiable para cambios permanentes en un despliegue serverless.
Convertir la demo en una aplicación operable
El siguiente paso es migrar las rutas a PostgreSQL, proteger sesiones y permisos en el servidor, implementar el panel administrativo real, añadir comentarios desde la interfaz, filtros, asignación de técnicos y pruebas de integración.