Wetopi Knowledge Plane — Memoria Ejecutiva¶
1. Propósito¶
Wetopi adopta un modelo AI-first de documentación y conocimiento en el que la documentación operativa, técnica y arquitectónica será consumida tanto por humanos como por agentes.
La decisión central es:
Git + Markdown será la única fuente de verdad documental de Wetopi.
La documentación se publicará automáticamente en docs.wetopi.net mediante MkDocs y, en paralelo, será indexada para agentes mediante una capa de recuperación especializada.
BookStack deja de formar parte de la arquitectura objetivo y debe ser retirado junto con sus referencias documentales, GitOps, configuración e integraciones.
2. Decisiones ejecutivas¶
2.1 Fuente de verdad¶
La fuente de verdad será un repositorio Git dedicado, orientado a Wiki-LLM:
El contenido será:
- legible por humanos;
- legible directamente por LLM;
- versionable;
- revisable mediante PR;
- enlazable mediante
[[wikilinks]]; - estructurado mediante frontmatter;
- publicable automáticamente;
- indexable para recuperación semántica y mediante grafo.
MkDocs no será una fuente de verdad: será una vista web derivada.
2.2 Wiki-LLM como modelo documental¶
Wetopi adopta el patrón Wiki-LLM como base del sistema documental.
Hermes Agent ya incluye de serie la skill:
versión conocida:
La skill proporciona:
- ingestión de fuentes;
- destilación hacia Markdown;
- páginas interconectadas;
[[wikilinks]];- consultas sobre la wiki;
- lint de enlaces, frontmatter, páginas huérfanas y contenido obsoleto;
- integración opcional con Obsidian.
Por tanto, Wetopi no debe crear desde cero el concepto de Wiki-LLM: debe extenderlo para operación multiagente, gobierno documental y conocimiento de plataforma.
3. Modelo de conocimiento¶
La arquitectura se divide en cuatro responsabilidades.
Git Markdown
= conocimiento canónico
Knowledge MCP
= recuperación optimizada para agentes
Hindsight
= memoria, experiencia y sabiduría
Ceph/S3
= evidencia y artifacts
Git / Wiki¶
Responde:
¿Qué sabe oficialmente Wetopi y cuál es el estado actual de la plataforma?
Hindsight¶
Responde:
¿Qué recuerda Wetopi de lo que ocurrió, qué aprendimos y qué patrones hemos observado?
Artifact Store¶
Responde:
¿Qué evidencia demuestra lo ocurrido?
Knowledge MCP¶
Responde:
¿Qué contexto documental necesita ahora este agente?
4. Principio de diseño¶
La documentación y sus índices se separan.
SOURCE OF TRUTH
│
▼
Git / Markdown
│
├──────────────► MkDocs ─────► docs.wetopi.net
│
├──────────────► Knowledge Index
│ │
│ ▼
│ wetopi-knowledge-mcp
│ │
│ ▼
│ Agents
│
└──────────────► Wiki Curator
El índice MCP es estado derivado.
Puede borrarse y regenerarse completamente desde Git.
5. Knowledge MCP¶
Wetopi desarrollará o adaptará un MCP inspirado conceptualmente en codebase-memory-mcp, pero orientado a conocimiento documental.
No será un RAG puramente vectorial.
Combinará:
- estructura Markdown;
- frontmatter;
- IDs globales;
- wikilinks;
- relaciones explícitas;
- full-text search;
- embeddings;
- grafo de conocimiento;
- autoridad documental;
- estado temporal del documento.
El objetivo es proporcionar a los agentes una interfaz pequeña:
6. Wiki-LLM ampliado y multiagente¶
Wetopi extenderá Wiki-LLM con un modelo de contribución multiagente.
Los agentes podrán crear conocimiento, actualizar páginas, añadir evidencias, crear investigaciones, generar ADR, enlazar conceptos, actualizar estados y proponer síntesis.
No escribirán directamente sobre main.
Agent
↓
worktree / branch
↓
cambio Markdown
↓
llm-wiki lint
↓
validación de esquema y grafo
↓
PR
↓
review / curator
↓
merge
7. Wiki Curator¶
Se establecerá un rol/agente de curación documental para:
- detectar duplicados;
- consolidar páginas;
- mejorar relaciones;
- resolver conceptos equivalentes;
- detectar contradicciones;
- detectar documentación obsoleta;
- comprobar enlaces rotos;
- comprobar frontmatter;
- detectar páginas huérfanas;
- mantener índices;
- promover conocimiento de investigaciones hacia documentación estable;
- evitar divergencias terminológicas;
- vigilar que exista una sola fuente de verdad por tema.
8. Hindsight¶
Hindsight no sustituye la documentación.
Su función es almacenar:
- hechos;
- observaciones;
- experiencias;
- resultados operacionales;
- relaciones;
- conocimiento aprendido;
- sabiduría destilada;
- referencias a fuentes.
Principio:
Hindsight almacena significado y experiencia; Git almacena conocimiento canónico.
El agente debe poder hacer:
La memoria descubre; las fuentes prueban.
9. Evidencia y artifacts¶
Los resultados voluminosos o raw no deben entrar en Git:
- logs;
- pcaps;
- dumps;
- JSON/CSV grandes;
- screenshots;
- scanner output;
- support bundles;
- benchmarks completos;
kubectldumps.
Se almacenarán en Ceph/S3.
Git conservará el resumen, interpretación, conclusión y referencias al artifact.
10. BookStack¶
BookStack queda fuera de la arquitectura objetivo.
Debe ejecutarse una retirada controlada:
- inventariar contenido existente;
- identificar contenido único que deba conservarse;
- convertirlo a Markdown;
- incorporarlo al repositorio canónico;
- eliminar referencias a BookStack en documentación;
- retirar enlaces en agentes y prompts;
- retirar secrets y configuración;
- eliminar manifests/Helm/Argo CD;
- retirar DNS/Ingress;
- conservar backup temporal;
- destruir almacenamiento sólo tras validar migración y rollback.
11. Estructura organizativa inicial¶
infrastructure/
platform/
wetopi-app/
wordpress-hosting/
operations/
agents/
architecture/
decisions/
concepts/
investigations/
records/
La jerarquía representa conocimiento, no la estructura de repositorios de software.
12. Resultado esperado¶
- Humanos:
docs.wetopi.net. - Agentes:
wetopi-knowledge-mcp. - Memoria: Hindsight.
- Evidencia: Ceph/S3.
- Gobierno: Git + PR + CI.
13. Visión¶
REALIDAD
↓
AGENTES
↓
OBSERVACIONES / ARTIFACTS
↓
HINDSIGHT
↓
CURACIÓN
↓
WIKI CANÓNICA
↓
KNOWLEDGE MCP
↓
AGENTES MEJOR INFORMADOS
14. Decisión resumida¶
Git Markdown es el conocimiento.
MkDocs lo presenta a humanos.
Knowledge MCP lo compila para agentes.
Hindsight recuerda la experiencia.
S3 conserva la evidencia.