10. Mantenimiento y Mejoras Futuras
STATUS: borrador (v1) Estimacion: 4-5 paginas
10.1 Posibles ampliaciones
El roadmap post-v1 de Quetzy ERP se organiza por horizonte temporal, priorizando las ampliaciones que consolidan la metodologia validada antes de añadir features nuevas.
Corto plazo (1-3 meses post-entrega)
Triage formal de las 15 issues GitHub abiertas. Durante el desarrollo se acumularon 15 issues sin clasificar (verificado via gh issue list). La primera accion post-TFG es una sesion de triage para asignar labels (tipo, prioridad, plataforma, feature afectada), milestones y fechas. Esta tarea no es administrativa: es la aplicacion directa de la metodologia validada en el propio proyecto. Issues como #83 Mensajes desaparecen tiempo conectado, #91 Compartir pantalla o #88 Acceso canales requieren investigacion previa, plan de commits atomicos y PR con criterios de aceptacion, exactamente el flujo que el TFG demuestra funcional.
Dev View y Git View multi-proveedor. Milestone aparcado el 9 de mayo de 2026 tras planning intensivo. El objetivo es añadir dos vistas nuevas al modulo de proyectos:
- Dev View en
/projects/[id]: tabs con header tipo GitHub (Code, Issues, Pull requests, Actions; Agents e Insights deshabilitados en v1). Proporciona contexto de desarrollo sin salir del ERP. - Git View en
/projects: lista alternativa con columnas Default branch, Open PRs, Last main merged, Open Issues (con creacion inline) y Last activity. Pensada para el lead tecnico que necesita una vista rapida del estado de todos los repositorios del equipo.
La decision arquitectonica clave es la interfaz GitProvider agnostica de proveedor. Se planifican 5 implementaciones (GitHub, Forgejo, Azure DevOps, Bitbucket, GitLab) con un identificador JSONB en tabla nueva project_repo. Solo GitHub se implementaria funcionalmente en v1; el resto devuelve NotImplementedError. Esta arquitectura valida empiricamente el OE8 aplicado al propio roadmap: la metodologia de tickets-como-planes-de-PRs y la capa de contratos permiten planificar una ampliacion multi-proveedor sin ambiguedad, demostrando que el flujo de trabajo no solo sirve para construir el ERP, sino para planificar su evolucion.
La comunicacion real-time de eventos Git seguiria la cadena Webhook GitHub -> Server -> WebSocket Server -> Browser, reutilizando la funcion publish_realtime_event de Insforge ya operativa en produccion para el chat.
La decision de aparcar este milestone fue defensiva y consciente: la calidad de la memoria y la estabilidad de la v1 desplegada prevalecieron sobre añadir una feature brillante a medio terminar. Esta priorizacion es en si misma un resultado metodologico.
Capturas reales de produccion. Sustituir los placeholders [CAPTURA-XX] de la memoria por capturas de uso real del sistema con el cliente Recotex modelado.
Medio plazo (3-6 meses)
M-Skills v1+ (ampliacion de la capa de IA). Mas alla del context_extractor actual, se diseñan tres skills adicionales:
ticket_classifier: clasifica tickets entrantes por tipo y complejidad a partir del titulo y descripcion, reduciendo el gate humano dereceivedaclassifieda una revision (no redaccion).pr_summary_generator: genera resumen estructurado de una PR a partir del diff, consumible comocontext_itempropuesto.context_obsolescence_detector: identificacontext_itemsque pueden haber quedado obsoletos comparando su contenido con cambios recientes del repositorio.
Dashboard de meetings v1.5. Vista centralizada de reuniones con actas generadas desde raw_context, vinculacion a tickets y context_items generados, y timeline de decisiones tomadas.
Llamadas WebRTC v2. Video ademas de audio, con grabacion server-side para generar actas automaticas post-reunion. Requiere upgrade de LiveKit y evaluacion de almacenamiento de grabaciones.
Cliente externo invitado. Acceso restringido a canales y proyectos especificos para clientes del equipo, con permisos limitados (solo lectura en tickets, escritura solo en chat del canal asignado). Requiere implementar RBAC granular (ver 10.2).
Largo plazo (6-12 meses)
Migracion GitHub Cloud a Forgejo self-hosted. Alineado con el OE7 (self-hosting completo) y reduce la dependencia del unico SaaS no autoalojado del stack. El plan incluye Forgejo como forge Git + Woodpecker CI como runner de pipelines, ambos desplegados en un VPS dedicado. La interfaz GitProvider diseñada en el corto plazo facilita esta transicion sin reescribir la capa de presentacion del ERP.
Landing publica quetzy.eu con enfoque comercial. Pagina publica que presente Quetzy como producto, con enfoque en consultoras tecnologicas pequeñas que buscan alternativa self-hosted a la fragmentacion SaaS.
M-Skills v2 con multi-provider LLM. Ampliar AIProvider para soportar Claude, OpenAI y Gemini simultaneamente, con seleccion por skill segun coste/calidad. Requiere implementar el Model Gateway de Insforge planificado para M7.
entity_context_link extendido a artefactos Git. Añadir tipos commit, pull_request e issue al campo entity_type de la tabla entity_context_link, permitiendo vincular context_items directamente a artefactos del repositorio. Esto cierra el ciclo: el contexto validado que alimenta a la IA queda trazablemente conectado al codigo que genero.
10.2 Mejoras pendientes
Deuda tecnica activa del proyecto, categorizada por area y prioridad. Todos los items estan verificados contra el codigo fuente del repositorio.
| ID | Area | Descripcion | Origen deteccion | Prioridad |
|---|---|---|---|---|
| D-01 | Llamadas | Bug audio asimetrico LiveKit post-reconnect. SDK livekit-client@2.18.9 con transceivers recvonly durante renegociacion SDP. Fix #1 desplegado sin exito. Plan: investigar downgrade SDK o pre-create transceivers recvonly antes de renegociacion. | Diagnostico con logs server LiveKit, mayo 2026 | Alta |
| D-02 | Auth | MOCK_ACTOR_EMAIL hardcoded en 12 archivos de produccion (erp-shell.tsx, use-client-detail.ts, use-client-list.ts, use-project-detail.ts, use-project-list.ts, use-ticket-detail.ts, use-ticket-list.ts, use-context-bucket.ts, use-add-raw-context.ts, use-extract-raw-context.ts, use-pending-review.ts, raw-context-detail-modal.tsx). Las mutaciones no usan el email del usuario autenticado real. | Revision de codigo, desarrollo | Alta |
| D-03 | BD | Schema drift: tablas time_entry y notification creadas en consola Insforge pero ausentes de data_model.sql versionado. Rompe el principio de source of truth en Git. | Documentado en Cap 3.6 | Alta |
| D-04 | Realtime | (c as any).tokenManager.setAccessToken(token) en insforge-realtime-client.ts:43 accede a propiedad privada del SDK. Fragil ante actualizaciones del SDK. | Revision de codigo | Media |
| D-05 | IA | Zero retry/backoff en GeminiProvider. Si la API de Gemini devuelve 429 o 503, la skill falla sin reintento. | Revision de codigo | Media |
| D-06 | Storage | Bucket chat-attachments usa URLs publicas sin signed URLs con expiracion. Cualquier usuario que conozca el patron de keys puede acceder a archivos sin autenticacion. | Analisis de seguridad (R-11, Cap 7) | Alta |
| D-07 | Auth | Refresh token flow no implementado. Al expirar el accessToken (antes del maxAge de 7 dias de la cookie), el usuario es redirigido a login sin intento de refresco transparente. | Documentado en Cap 7.3 | Media |
| D-08 | Auth | RBAC granular ausente. Todos los usuarios autenticados tienen acceso completo al sistema. Insuficiente para escenarios multi-rol o cliente invitado. | Documentado en Cap 3.6 | Media |
| D-09 | Seguridad | Rate limiting ausente en login y APIs (R-13 del Cap 7). Vulnerable a fuerza bruta. | Analisis de riesgos Cap 7.1 | Alta |
| D-10 | Infra | Cifrado on-disk PostgreSQL no implementado (LUKS o equivalente). Datos en reposo accesibles si se compromete el filesystem del VPS. | Analisis de seguridad Cap 7.4 | Media |
| D-11 | Infra | Observabilidad formal ausente. Sin Prometheus, Grafana ni Uptime Kuma. La monitorizacion se basa en docker logs y health endpoint manual. | Documentado en Cap 9.4 | Media |
| D-12 | Testing | Pruebas de carga formales ausentes (k6, Artillery). RNF-02 (20 personas concurrentes) no validado empiricamente. | Documentado en Cap 8.4 | Media |
| D-13 | CI/CD | SAST/DAST/SCA ausentes en pipeline. Sin SonarQube, Snyk, OWASP ZAP ni revision activa de Dependabot. | Documentado en Cap 7.6 | Media |
| D-14 | Seguridad | Pentest formal pre-produccion no realizado. | Documentado en Cap 7.6 | Baja |
| D-15 | Infra | Cuenta GitHub corporativa pendiente. Repo bajo cuenta personal (Fraancoboss). Plan: organizacion GitHub quetzy o cuenta servicio con PAT fine-grained repo:read. | Planning mayo 2026 | Baja |
| D-16 | BD | Migracion a data_model_v2.sql con sistema de migraciones versionado real (tipo migrations/001_initial.sql, 002_add_time_entry.sql). Actualmente un unico archivo monolitico. | Revision de arquitectura | Baja |
| D-17 | Legal | No existe archivo LICENSE en el repositorio. El codigo no tiene licencia explicita, lo que implica copyright por defecto sin permisos de uso. | Verificado con ls LICENSE* (no existe) | Baja |
10.3 Compatibilidad
Navegadores
El sistema soporta navegadores modernos con las siguientes versiones minimas: Chromium >= 100, Firefox >= 100, Safari >= 16. Estos umbrales garantizan soporte para las APIs criticas del sistema: Web Audio API (grabacion y reproduccion de mensajes de audio), getUserMedia (captura de microfono para llamadas) y WebSocket (realtime). No se configura browserslist explicito en package.json; la compatibilidad se garantiza por el target de compilacion de Next.js 16 y el soporte de las APIs Web usadas.
Movil
La estrategia de movilidad es responsive web; la aplicacion nativa fue descartada explicitamente en Cap 3.6 por coste de desarrollo y mantenimiento de dos plataformas. Las 15 issues abiertas incluyen varias relacionadas con la experiencia movil (#89 Vista movil, #92 Posicion sidebar movil, #96 UI Movil), confirmando que la adaptacion responsive es deuda activa. Queda pendiente una revision formal de accesibilidad WCAG 2.1 AA, especialmente en los controles de llamada y en la interaccion con la maquina de estados de tickets.
Sistemas operativos cliente
Agnostico. Al ser una aplicacion web, funciona en cualquier sistema operativo con un navegador compatible. No hay dependencias de APIs nativas del sistema operativo.
Servidor
Linux con kernel 5.x o superior. Testado y desplegado en produccion sobre Ubuntu LTS con kernel 6.8.0. Docker Engine 24.x y Docker Compose v2 son requisitos de la capa de orquestacion.
Compatibilidad hacia futuro
La arquitectura GitProvider agnostica de proveedor (diseñada para Dev View / Git View, ver 10.1) permite añadir Forgejo, Azure DevOps, Bitbucket o GitLab sin reescribir la capa de presentacion. El patron Repository con doble implementacion (mock + Insforge) permitiria añadir un backend alternativo (Supabase, PocketBase, Appwrite) sin tocar la UI: bastaria implementar las interfaces ErpRepository y ChatRepository contra el nuevo backend.
Compatibilidad de red
WebRTC requiere conectividad UDP saliente al rango 50000-50100 del VPS, o TCP al puerto 7881 como fallback. Redes corporativas con NAT estricto (carrier-grade NAT, firewalls que bloquean UDP saliente) requeririan un servidor TURN propio (por ejemplo coturn), no desplegado en v1. Esta limitacion esta documentada como deuda en Cap 3.6.
10.4 Escalabilidad
Capacidad actual
La arquitectura actual es mono-VPS: un unico servidor Hetzner CX33 (4 vCPU AMD EPYC, 7,6 GiB RAM, 75 GB SSD) ejecuta todos los servicios. La estimacion de capacidad es de 2-20 personas concurrentes, basada en el dimensionamiento del hardware y la naturaleza de las cargas observadas durante el desarrollo y uso con el equipo de 2 personas. Esta cifra NO esta validada con pruebas de carga formales (ver D-12 en 10.2).
Escalado vertical
Upgrade directo en el panel de Hetzner Cloud a instancias superiores (CX42: 8 vCPU / 16 GiB, CX52: 16 vCPU / 32 GiB) sin cambios de codigo ni de configuracion Docker. El proceso requiere un reinicio del VPS (minutos de downtime aceptables para un equipo interno).
Escalado horizontal
Migracion a arquitectura multi-VPS con los siguientes componentes:
- Load balancer frontal (Caddy en modo upstream con health checks).
- Replicas de la aplicacion Next.js (stateless, escalable horizontalmente sin restricciones).
- PostgreSQL primario + replicas read-only para consultas pesadas.
- LiveKit ya es nativamente escalable en horizontal (arquitectura SFU distribuida).
Insforge BaaS soporta este modelo de despliegue segun su documentacion. La red Docker quetzy-net actual se reemplazaria por una red overlay o por comunicacion inter-VPS via VPN (WireGuard).
CI/CD
GitHub Actions es el unico componente SaaS no autoalojado del stack. La migracion futura a Forgejo + Woodpecker CI (ver 10.1, largo plazo) eliminaria esta dependencia. Mientras tanto, los runners gratuitos de GitHub son suficientes para el volumen de PRs del equipo.
Almacenamiento
El bucket chat-attachments no tiene politicas de TTL ni de retencion. Con uso sostenido, el almacenamiento crecera indefinidamente. Se recomienda definir una politica de retencion (por ejemplo, 1 año para adjuntos, con archivado a cold storage tras ese periodo) para controlar el crecimiento del disco.
Base de datos
PostgreSQL 15.15 puede escalar a 100.000+ registros por tabla sin sharding, con indices adecuados. El bottleneck previsible a escala son los triggers SQL de realtime: si el volumen de mensajes por segundo supera los 1.000, los triggers notify_chat_message y notify_chat_reaction podrian saturar el canal de publicacion. Mitigable con Insforge Realtime en modo cluster o con un sistema de colas intermedio (Redis Pub/Sub).
Observabilidad como prerrequisito de escalado
Sin metricas no se puede escalar racionalmente. La deuda D-11 (observabilidad formal) es prerrequisito de cualquier decision de escalado: sin datos de latencia p95, uso de CPU por servicio, conexiones WebSocket activas y queries lentas, las decisiones de escalado serian especulativas. Por esta razon, la implementacion de un stack de monitorizacion (Prometheus + Grafana o equivalente) es la primera tarea de infraestructura post-TFG.