FocusHub

Módulos

El sistema se organiza en superficies independientes, cada una resolviendo una parte del trabajo diario.

Capa de inteligencia artificial

Una capa de IA propia estructurada como un sistema de agentes jerárquicos, accesible como overlay full-screen y con su propia base de datos separable del resto del sistema.

• Un oráculo central agrupa 8 agentes distribuidos en 5 categorías, cada uno con 5 subagentes verticales — 40 en total.
• Tres bibliotecas globales reutilizables entre agentes: skills (capacidades), prompts (con versionado) y memorias compartidas.
• El system prompt de cada sesión se arma dinámicamente combinando el manifiesto del agente con sus skills, prompts y memorias asignadas.
• Exportación de agentes a un ZIP portable (manifiesto, skills, prompts, memorias y galería) para llevarlos fuera del sistema.

Arquitectura

• Monorepo con frontend React + Vite, API REST en Express y base de datos SQLite con servidor propio.
• Tres bases de datos separadas por dominio: la operativa del día a día, la del perfil profesional y la de la capa de IA — cada una independiente y extraíble.
• Migraciones idempotentes: cada sentencia se ejecuta y verifica de forma aislada, permitiendo correr el mismo script varias veces sin romper la base.
• BuildMode, un panel técnico de administración que se actualiza en paralelo cada vez que se suma infraestructura nueva (bases, componentes, endpoints de import/export).

Proceso

1. Creció por capas, no desde un plan cerrado: arrancó por el control del tiempo y fue sumando módulos a medida que el uso los pedía. Varios pasaron por versiones descartadas antes de quedar — Objetivos se rediseñó dos veces, y funciones que sonaban bien en texto pero no aportaban en código se frenaron antes de escribirse.
2. La arquitectura se separó en tres bases de datos por dominio —operación diaria, perfil profesional y capa de IA—, de modo que los módulos grandes se pueden mantener, desactivar o extraer sin tocar el núcleo del sistema.
3. Al madurar el sistema se reescribieron módulos enteros que habían quedado chicos: Estadísticas pasó de un archivo monolítico a una estructura modular de pestañas independientes, y Notas se rehízo por completo, priorizando la coherencia por sobre parchar lo existente.
4. El desarrollo siguió un protocolo propio: planificación antes de programar, entregas por fases, migraciones idempotentes y rollback controlado —usado de verdad para revertir cambios que rompieron el sistema—, con una política estricta de no introducir errores nuevos sobre la base existente.
5. Los problemas transversales se resolvieron a nivel sistema y no por parche: un manejo consistente de fechas locales (el bug más recurrente, que rompía al cruzar la medianoche), una única fuente de verdad para el temporizador entre las distintas pantallas, y la reducción de renderizados innecesarios.

Lo que aprendí

Desarrollar una herramienta para uso diario obliga a justificar cada decisión técnica. Cada nueva funcionalidad incorpora también mantenimiento, complejidad y deuda técnica, por lo que muchas veces la mejor decisión fue no implementar una idea hasta que existiera una necesidad real que la respaldara. Ese criterio terminó definiendo la arquitectura del proyecto tanto como el propio código.