Roadmap
El trabajo de ingeniería planeado para madurar el ecosistema de agentes local: near term, medium term, long term y los criterios de madurez.
Propósito
Este roadmap trackea el trabajo de ingeniería necesario para hacer el ecosistema más fiable, observable, reproducible y más fácil de evaluar. Se actualiza según evoluciona el lab. La fuente de input para el roadmap son los hallazgos de auditoría (Modelo de auditoría) y el catálogo de fallos (Catálogo de fallos).
El roadmap es un documento vivo. Se actualiza cuando:
- Una auditoría surface un hallazgo nuevo.
- Un modo de fallo se vuelve común.
- Se añade una capacidad nueva.
- Se acepta un ADR.
Leyenda de status
Cada item tiene un status:
| Status | Significado |
|---|---|
Implemented | El trabajo está hecho y en producción. |
In progress | El trabajo se está haciendo activamente. |
Planned | El trabajo está scoped pero no se ha empezado. |
Deferred | El trabajo se pospone; la razón está documentada. |
Superseded | El trabajo se reemplaza por un enfoque distinto. |
Near Term (Próxima iteración)
El trabajo a hacer en la próxima iteración. Estos items están unblocked y listos para empezar.
- Normalizar
tools.jsoncontra el inventario actual de herramientas. - Añadir health checks automatizados para las herramientas CLI core.
- Añadir tests mínimos a las herramientas que aún dependen de verificación manual.
- Crear un audit de dependencias ejecutable para la capa de tooling.
- Refrescar diagramas y ejemplos desde el estado actual del sistema.
- Capturar lessons learned al lado de los case studies relevantes.
- Resolver todos los hallazgos Critical y High de la última auditoría mensual.
- Conectar el request journal del research framework al generador de audit reports.
- Añadir un health check del
media-lab-serveral script semanal. - Documentar los cuatro cheatsheets de
comandos_terminal/en un índice descubrible.
Medium Term (Próximos 3-6 meses)
El trabajo a hacer en los próximos 3-6 meses. Estos items están scoped pero pueden necesitar diseño adicional.
- Convertir los hallazgos de auditoría en tasks de implementación trackeadas.
- Correr pases de evaluación contra workflows de research representativos.
- Mejorar la trazabilidad de artefactos entre fases de research, reports y resúmenes.
- Añadir observabilidad para el lifecycle del worker, estado de la cola y jobs fallidos.
- Definir runtime boundaries entre Coordinator, worker, herramientas y adaptadores externos (como código, no solo documentación).
- Construir demos reproducibles con datos sintéticos o de ejemplo.
- Implementar ADR-010 (Smart Orchestrator V2).
- Añadir dashboards de rate limit por adaptador.
- Añadir un check estilo CI que corra la suite de tests del research framework en cada code change.
- Documentar el path de migración del research framework actual a ADR-010.
Long Term (Próximos 6-12 meses)
El trabajo a hacer en los próximos 6-12 meses. Estos items son aspiracionales; se re-scopen según evolucione el lab.
- Crear un dashboard de status local para el ecosistema.
- Unificar índices para herramientas, skills y agentes.
- Versionar las especificaciones de las herramientas.
- Añadir contract tests para las especificaciones de las herramientas y los artefactos generados.
- Documentar paths de migración cuando cambien las herramientas o los roles de los agentes.
- Implementar ADR-012 (SQLite o PostgreSQL para artefactos).
- Expandir case studies individuales:
- La capa de tooling.
- El research framework.
- Los project templates.
- Memoria y contexto en agentes locales.
- Seguridad y auditabilidad en workflows basados en herramientas.
- Implementar un modo de paralelismo multi-misión en el Research Worker.
- Añadir un modo de informe streaming (el informe se genera incrementalmente según completan las fases).
Criterios de madurez
El ecosistema es maduro cuando:
- Tiene health checks fiables para las herramientas core.
- Produce artefactos que se pueden trazar de vuelta a sus inputs y fase.
- Registra decisiones, trade-offs y gaps conocidos.
- Maneja fallo parcial sin esconder la degradación.
- Distingue el estado actual de la visión futura.
- Mantiene la documentación alineada con el estado observado del sistema.
- Soporta demos reproducibles y runs de evaluación.
- Tiene cero hallazgos Critical en las últimas 3 auditorías mensuales.
- Tiene como máximo 2 hallazgos High en las últimas 3 auditorías mensuales.
- Tiene un tool registry completo y actual.
- Tiene un failure catalog completo y actual.
- Tiene un generador de audit reports funcional que ingiere el request journal.
- Tiene misiones de research reproducibles (misma query → mismo informe, modulo la no-determinismo del provider).
Backlog de documentación
- Añadir diagramas para el lifecycle de artefactos y la recuperación del worker.
- Añadir un formato compacto de evaluation report.
- Añadir una matriz versionada para herramientas, skills, owners y status de verificación.
- Mantener cada página atada al sistema que describe: arquitectura, decisiones, workflows, artefactos, operaciones y lessons learned.
- Traducir la documentación a español (el idioma de cara al usuario) una vez que la versión en inglés esté estable.
Architecture Decision Records in flight
El lab tiene los siguientes ADRs in flight (además de los ya accepted):
| ADR | Title | Status |
|---|---|---|
| ADR-010 | Smart Orchestrator V2 | Planned |
| ADR-011 | Plugin system for custom domain tools | Drafting |
| ADR-012 | SQLite or PostgreSQL for artifact storage | Planned |
| ADR-013 | Cross-mission artifact reuse | Drafting |
Los ADRs están documentados en Decisiones de arquitectura.
Nota de cierre
El proyecto sigue siendo aprendizaje aplicado: una arquitectura de agentes local construida mediante iteración, con herramientas reales, memoria, auditorías y documentación. El roadmap mantiene ese aprendizaje conectado a la madurez operacional.
El roadmap es un documento vivo. Se actualizará según evolucione el lab. El usuario es el operator; el operator decide qué se hace y cuándo.