Saltar a contenido

Roadmap DocuGraph v0.01

Este documento orienta el trabajo futuro de DocuGraph como herramienta personal del driver (DEC-011, research/99_DECISION_LOG.md), avanzando de las bases a lo avanzado. Reemplaza el objetivo Shipaton 2026 como meta de entrega (congelado en DEC-011); no elimina ninguna documentación previa, que permanece en el grafo como histórico trazable.

Propósito

Resolver el flujo real del driver: crear documentación → mantenerla ligada al grafo → entregar contexto correcto a los agentes de IA → hacer seguimiento de las tareas sin que la spec y el código diverjan (Regla 4 de AGENTS.md y §12 de MASTER-00).

Principios de ordenamiento

  1. Base primero: lo que el driver usa a diario (núcleo + MCP + contexto) se consolida antes de construir superficies nuevas.
  2. Cada nivel deja el grafo válido: validate_traceability debe quedar con 0 errores asociados al nivel al cerrarlo (los problemas históricos preexistentes se mantienen documentados).
  3. Sin duplicación: cada nivel cita operationId, tablas y herramientas existentes; no reescribe contratos.
  4. Nada se borra: las decisiones, hipótesis y docs Shipaton permanecen; el roadmap solo reorienta prioridades.

Niveles (de base a avanzado)

Nivel 0 — Fundaciones (en su mayoría completado)

# Ítem Estado Fuente
0.1 Núcleo documental (:docugraph-core): parser YAML, grafo, DAG, bundles HECHO RES-00, EXP-01 (research/00_RESEARCH_PLAN.md)
0.2 Servidor MCP (:docugraph-mcp) por STDIO con los 8 tools de la matriz HECHO GATE-0, DEC-005, DEC-008, ServerFactoryIntegrationTest (research/GATE_0_SPEC.md)
0.3 Gobernanza y metodología atómica HECHO MASTER-00, AGENTS
0.4 App KMP demo (:docugraph-app): S01–S12, F1–F5, gateway RevenueCat demo RETIRADO del repositorio; especificación histórica conservada DEC-009, DEC-010, DEC-011, DEC-012

Salida del nivel: base técnica validada, utilizable por STDIO desde cualquier cliente MCP.

Nivel 1 — Ciclo de documentación para el driver (prioridad inmediata)

# Ítem Justificación
1.1 Tool de escritura MCP (upsert_document / update_frontmatter) con validación DAG antes de aplicar Cierra el ciclo creación→uso→edición: el agente puede crear/actualizar docs y el grafo se mantiene íntegro. Estado: implementado y cubierto por tests de :docugraph-core/:docugraph-mcp; la publicación sigue el flujo Git explícito.
1.2 Flujo diario documentado: conectar :docugraph-mcp por STDIO a Claude Code/Codex/Antigravity desde cualquier workspace Hace que la IA "sepa qué tarea es y a qué está ligada" en el uso real del driver.
1.3 Plantillas de tareas (US/BE/FE) y convención de cronograma ligero sobre el grafo Unifica cómo el driver planifica y designa tareas a backend/frontend.
1.4 Metodología del driver documentada: requisitos funcionales (RF-XX), matriz de roles/casos de uso, diseño/mockups (DS-XX en docs/design/), NFRs y estrategia de pruebas (TEST-01) Alinea DocuGraph con las fases que el driver usa en el trabajo (problema/requisitos → roles → flujos → diseño → arquitectura/BD → historias de usuario → tareas), de punta a punta. Base: METODOLOGIA-00.

Criterio de salida: el driver usa DocuGraph en un proyecto real propio: crea una US, la liga al grafo, pide get_task_context al agente y cierra una tarea con el grafo válido.

Nivel 2 — Planificación y seguimiento de tareas

# Ítem Justificación
2.1 Estados por tarea (BACKLOG/TODO/IN_PROGRESS/BLOCKED/DONE) consultables vía MCP Seguimiento de cumplimiento dentro del mismo grafo.
2.2 Criterios de aceptación ligados a cada tarea y verificación automatizada El driver valida "si se cumplen satisfactoriamente" sin salir del flujo.
2.3 Vista de dependencias/críticos del grafo por tarea Evidencia el impacto de cambios (análisis de impacto).

Nivel 3 — Interfaz de trabajo

# Ítem Justificación
3.1 Superficies de lectura: Obsidian, Gitea y visor MkDocs La aplicación Desktop no forma parte del perfil activo; la escritura pasa a los agentes vía MCP y la edición humana controlada se realiza sobre el clon Git.
3.2 App móvil de supervisión (H13) Fuera del foco actual: la app móvil, la app Desktop y los pagos quedaron retirados del código y conservados como histórico.

Nivel 4 — Ecosistema self-hosted gratuito (Oracle Always Free)

# Ítem Justificación
4.1 Server MCP remoto: transporte Streamable HTTP /mcp y compatibilidad /sse en :docugraph-mcp IMPLEMENTADO: Caddy exige X-MCP-API-KEY y los clientes remotos conservan el endpoint /mcp.
4.2 Deploy en Oracle Always Free (2 OCPU, 12 GB): docugraph-mcp + Gitea + Caddy HTTPS CONFIGURADO: Compose persistente, workspace separado y puerto 8080 interno; queda aplicar/reiniciar la pila en Oracle.
4.3 Visor web de la documentación: MkDocs Material + grafo JSON del núcleo IMPLEMENTADO localmente: mkdocs.yml, builder estático y página /graph/ con 47 nodos, 170 aristas y valid=true; publicación detrás de Caddy en Oracle pendiente.
4.4 Obsidian local sobre el clon git del workspace DOCUMENTADO: el vault local es la superficie diaria de lectura/edición controlada; Gitea queda para revisión web puntual.

Nivel 5 — Avanzado (sujeto a evidencia)

# Ítem Justificación
5.1 Multi-workspace: un servidor por proyecto con config aislada Uso en varios repos del driver.
5.2 Conexión entre dispositivos / sincronización Solo con evidencia de valor (§5.6 de MASTER-00).
5.3 Integraciones de ecosistema (CI, plugins de editor) Según uso real observado.

Qué NO se persigue en este roadmap

  • Publicación en tiendas ni configuración RevenueCat real (suspendido por DEC-011; eliminado del código por DEC-012).
  • App móvil, aplicación Desktop y superficies de pago (DEC-012/DEC-013): el foco es el ecosistema self-hosted sin cliente propio ni paywall.
  • Categorías del Shipaton 2026 (congeladas).
  • Monetización y validación comercial (H08/H09/H13) hasta que el driver lo decida.
  • Servicios cloud de pago o de terceros como fuente de verdad (DEC-013): la doc vive en Markdown + git; el ecosistema es self-hosted gratuito (Oracle Always Free).

Trabajo inmediato (siguiente sesión con Junie)

  1. Nivel 1.1: baseline local verificado con tests :docugraph-core / :docugraph-mcp, integración contra buildMcpServer y smoke test STDIO; queda conservar la evidencia en el commit de trabajo.
  2. Nivel 1.2: documentar el flujo de conexión STDIO a los agentes del driver.
  3. Nivel 1.3: definir plantillas de tareas y convención de cronograma.
  4. Nivel 1.4: aterrizar METODOLOGIA-00 en un proyecto real del driver (validar RF-XX, matriz de roles, DS-XX y TEST-01 como convenciones).
  5. Nivel 4 operativo: aplicar en Oracle el .env real, construir Compose con los perfiles proxy/viewer, ejecutar smoke tests autenticados y registrar la evidencia sin secretos.

Estado

  • Versión: 0.01 (perfil self-hosted actualizado por DEC-011, DEC-012 y DEC-013).
  • Nivel actual: Nivel 4 (ecosistema self-hosted); la configuración de MCP remoto, Gitea/Caddy, sincronización Git, visor y exportador del grafo está implementada en el working tree. La validación local del checkout operativo y del viewer está completa; falta ejecutar en Oracle la activación final, sincronización de un documento de prueba y smoke persistente con secretos locales.