Wetopi Knowledge & Documentation Plane¶
Estado: Proposed
Fecha: 2026-09-06
Ámbito: Wetopi Platform / Infrastructure / Wetopi App / Agent Fleet
Tipo: Project / Architecture & Documentation Policy
1. Objetivo¶
Definir el sistema documental y de conocimiento de Wetopi para que pueda ser utilizado de forma consistente por:
- Operadores humanos.
- Agentes Hermes.
- Futuros agentes ADK standalone.
- Automatizaciones SRE/DevOps.
- Sistemas de memoria como Hindsight.
El sistema debe resolver simultáneamente:
- Documentación técnica navegable para humanos.
- Source of Truth versionado para decisiones y arquitectura.
- Almacenamiento de artifacts y evidencias generadas por agentes.
- Memoria semántica de hechos, aprendizajes y relaciones.
- Trazabilidad entre objetivos, investigaciones, artifacts, decisiones y cambios.
- Evitar duplicación y document rot.
- Permitir que una futura flota numerosa de agentes produzca información sin convertir Git, BookStack o Hindsight en vertederos.
Principio fundamental:
Raw → Artifact Store. Knowledge → BookStack. Contract → Git. Wisdom → Hindsight.
Cada sistema tiene una responsabilidad diferente.
2. Modelo conceptual¶
Wetopi tendrá cuatro almacenes principales de conocimiento:
┌─────────────────────────┐
│ HINDSIGHT │
│ │
│ Facts │
│ Experiences │
│ Observations │
│ Relations │
│ Learned knowledge │
│ Wisdom │
└────────────┬────────────┘
│
semantic pointers
│
┌───────────────────────────┼───────────────────────────┐
│ │ │
▼ ▼ ▼
┌────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ GIT │ │ BOOKSTACK │ │ OBJECT STORE │
│ │ │ │ │ Ceph/S3 │
│ Canonical │ │ Living │ │ │
│ Source of Truth│ │ Knowledge │ │ Raw artifacts │
│ │ │ │ │ Evidence │
│ ADR │ │ Guides │ │ Reports │
│ Architecture │ │ Investigations │ │ Logs │
│ Policies │ │ Explanations │ │ Dumps │
│ Contracts │ │ Workbench │ │ Captures │
└────────────────┘ └─────────────────┘ └─────────────────┘
▲ ▲ ▲
│ │ │
└───────────────────────────┴───────────────────────────┘
▲
│
Hermes / ADK
Humans / CI/CD
Ninguno de estos sistemas sustituye a los demás.
3. Responsabilidad de cada sistema¶
3.1 Git — Canonical Source of Truth¶
Git contiene aquello que constituye un contrato técnico o histórico de Wetopi.
Ejemplos:
- ADR.
- Architecture Packs.
- Arquitectura formal.
- Policies.
- Standards.
- Runbooks críticos.
- Interfaces y contratos.
- Documentación asociada directamente al código.
- Configuración.
- Manifests.
- GitOps.
- Documentación cuyo cambio debe pasar por PR/review.
Características:
- versionado;
- diff;
- branches;
- PR;
- review;
- commit SHA;
- historial inmutable;
- fácil consumo por agentes;
- referencias exactas.
Git responde principalmente:
¿Qué hemos decidido y cuál es actualmente el contrato?
4. BookStack — Living Knowledge¶
BookStack será la base de conocimiento navegable de Wetopi.
Su misión no es sustituir Git.
BookStack responde principalmente:
¿Cómo entendemos, usamos, operamos e investigamos Wetopi?
Contendrá:
- explicaciones;
- documentación operativa;
- conocimiento consolidado;
- troubleshooting;
- investigaciones relevantes;
- guías;
- procedimientos;
- conocimiento transversal;
- documentación en evolución;
- workbench de agentes.
Una página útil debería responder, cuando aplique:
- ¿Qué es?
- ¿Cómo funciona?
- ¿Cómo se opera?
- ¿Cómo puede romperse?
- ¿Cómo se diagnostica?
- ¿Dónde está su Source of Truth?
- ¿Qué decisiones lo gobiernan?
BookStack no debe convertirse en una copia de Git.
5. Footprint de BookStack¶
La organización principal será por dominio de conocimiento, no por repositorio ni por agente.
5.1 00 — Start Here¶
Punto de entrada al conocimiento de Wetopi.
Contenido:
- Wetopi Overview.
- Architecture Map.
- Systems Map.
- Ownership & Responsibilities.
- Naming Conventions.
- Documentation Policy.
- Knowledge Lifecycle.
- Cómo buscar información.
- Cómo documentan humanos y agentes.
Debe permitir que un operador o agente nuevo pueda orientarse rápidamente.
6. 10 — Infrastructure¶
Infrastructure representa aquello que seguiría existiendo aunque Kubernetes desapareciera.
Incluye:
Infrastructure
│
├── Physical Infrastructure
│ ├── Datacenters
│ ├── OVH
│ ├── Physical Nodes
│ ├── Hardware Inventory
│ ├── IPMI / Management
│ └── Power
│
├── Networking
│ ├── VRACK
│ ├── VLAN
│ ├── Addressing
│ ├── BGP
│ ├── WAN
│ ├── VRRP
│ ├── IPVS
│ └── NAT Gateways
│
├── Proxmox
│ ├── Clusters
│ ├── Nodes
│ ├── VMs
│ └── Operations
│
├── Ceph
│ ├── Architecture
│ ├── MON
│ ├── OSD
│ ├── RBD
│ ├── Pools
│ ├── Networking
│ └── Operations
│
└── Backup Infrastructure
Regla conceptual:
Si Kubernetes desapareciese mañana y el componente continuase existiendo, probablemente pertenece a Infrastructure.
7. 20 — Platform¶
Platform contiene los servicios que convierten la infraestructura en la plataforma sobre la que funciona Wetopi.
Ejemplo:
Platform
│
├── Kubernetes / RKE2
├── Cilium
├── Traefik / Gateway API
├── Argo CD
├── GitOps
├── Infisical
├── Zot Registry
├── Observability
│ ├── Metrics
│ ├── Logs
│ ├── Traces
│ └── Alerting
│
├── LiteLLM
├── Hindsight
├── BookStack
├── Agent Runtime
└── Platform Security
Aquí se documenta cómo está formada y operada la plataforma común.
8. 30 — Wetopi App¶
Wetopi App contiene el software propietario que implementa el control plane del SaaS.
Ejemplo:
Wetopi App
│
├── Control Plane Overview
│
├── app-api
├── app-sites
├── app-worker
├── app-provisioner
├── app-backup
├── app-domains
├── app-billing
├── app-events
└── ...
Cada app-* debería disponer de una ficha identificable.
Ejemplo:
con:
id: SVC-APP-SITES
domain: wetopi-app
owner: wetopi
status: production
last_verified: 2026-09-06
repository: ...
dependencies:
- ...
9. 40 — WordPress Hosting¶
Describe específicamente el runtime que Wetopi proporciona a los clientes.
WordPress Hosting
│
├── Runtime Architecture
├── Site Lifecycle
├── WordPress
├── PHP
├── Database
├── Cache
├── Storage
├── Backup / Restore
├── Clone
├── Staging
├── Domains
├── TLS
├── Security
└── Troubleshooting
Permite separar claramente:
Wetopi App
del
producto/runtime WordPress que Wetopi App administra.
10. 50 — Operations¶
Conocimiento transversal de operación.
Operations
│
├── SRE
├── Runbooks
├── Procedures
├── Incident Response
├── Disaster Recovery
├── Maintenance
├── Capacity Management
├── Security Operations
├── Change Management
└── Troubleshooting
Un runbook específico de un servicio puede vivir junto al servicio.
Un procedimiento transversal debe vivir aquí.
Nunca deben existir dos copias.
11. 60 — Agents & Automation¶
Describe la infraestructura y comportamiento de la flota agentic.
Agents & Automation
│
├── Architecture
│
├── Hermes
│ ├── Lead
│ ├── Builder
│ ├── Approver
│ └── Workers
│
├── ADK
│ ├── Platform
│ ├── WordPress
│ └── Support
│
├── Harness
├── Skills
├── Tools
├── MCP
├── Delegation
├── Memory Architecture
├── Hindsight
├── Agent Policies
└── Security Model
Esta sección describe cómo funcionan los agentes.
No almacena automáticamente todo lo que producen.
12. 70 — Decisions & Architecture¶
Índice humano del conocimiento arquitectónico formal.
Decisions & Architecture
│
├── ADR Index
├── Architecture Packs
├── RFC
├── Designs
├── Standards
└── Decision Log
BookStack puede contener resúmenes, índices y explicaciones.
El documento formal puede residir en Git.
13. 80 — Product & Business¶
Documentación no puramente técnica relacionada con Wetopi como producto.
Product & Business
│
├── Product
├── Customer Lifecycle
├── Plans
├── Features
├── Billing
├── Support Processes
├── Internal Processes
└── Business Operations
14. 90 — Agents Workbench¶
Área de trabajo documental no institucionalizada.
Ejemplo:
Agents Workbench
│
├── Hermes
│ ├── Lead
│ ├── Builder
│ └── Approver
│
├── ADK
│ ├── Platform
│ ├── WordPress
│ └── Support
│
└── Shared Investigations
Aquí pueden aparecer:
Pero Workbench no debe convertirse en el almacén de cada output producido por los agentes.
Para eso existe Artifact Storage.
15. Agent Artifact Store¶
Wetopi debe disponer de un almacenamiento S3 compatible dedicado a artifacts generados por agentes.
La opción natural dentro de la infraestructura actual es:
Ceph RGW / S3 compatible.
Conceptualmente:
Su misión es almacenar evidencia y material generado, no conocimiento consolidado.
Ejemplos:
- RECON.
- informes extensos;
- logs;
- outputs de kubectl;
- métricas;
- JSON;
- CSV;
- YAML renderizado;
- screenshots;
- pcaps;
- support bundles;
- benchmark results;
- dumps;
- outputs de scanners;
- artifacts intermedios;
- documentos
.mdgenerados automáticamente.
16. Estructura del Artifact Store¶
Ejemplo:
wetopi-agent-artifacts/
│
├── infrastructure/
│
├── platform/
│ ├── rke2/
│ ├── cilium/
│ ├── argocd/
│ ├── bookstack/
│ ├── litellm/
│ └── hindsight/
│
├── wetopi-app/
│
├── wordpress/
│
├── incidents/
│
└── objectives/
Cada ejecución relevante genera un artifact identificable.
Ejemplo:
ART-20260906-00182/
│
├── manifest.yaml
├── report.md
│
├── evidence/
│ ├── kubectl.txt
│ ├── metrics.json
│ └── topology.json
│
└── attachments/
└── diagram.png
17. Manifest de Artifact¶
Cada artifact debe ser autocontenido e identificable.
Ejemplo:
artifact_id: ART-20260906-00182
created_at: 2026-09-06T14:23:21+02:00
agent:
type: hermes
id: wetopi-lead
domain: platform
service: cilium
type: investigation
status: completed
objective: OBJ-0042
incident: null
files:
- report.md
- evidence/kubectl.txt
- evidence/metrics.json
- evidence/topology.json
relations:
adr: null
investigation: INV-0192
record: null
promotion:
bookstack: null
git: null
retention:
class: standard
18. Lifecycle de artifacts¶
No todos los artifacts deben conservarse eternamente.
Se definirán clases como:
Ejemplo inicial:
| Clase | Retención |
|---|---|
| ephemeral | 7 días |
| standard | 90 días |
| extended | 1 año |
| permanent | indefinida |
Un artifact referenciado por:
- ADR;
- incidente importante;
- record;
- arquitectura formal;
- investigación histórica relevante;
puede pasar automáticamente a permanent.
El lifecycle debe implementarse mediante políticas S3 siempre que sea posible.
19. Architecture Packs¶
Los Architecture Packs formales deben vivir en Git.
Ejemplo:
docs/
└── architecture/
└── platform/
└── egress-security/
├── README.md
├── context.md
├── architecture.md
├── threats.md
├── decisions.md
├── implementation.md
└── diagrams/
└── architecture.mmd
Razones:
- múltiples archivos;
- diff;
- revisión;
- PR;
- versionado;
- referencias;
- Mermaid;
- evolución ligada a implementación.
BookStack puede presentar un resumen y enlazar al Architecture Pack.
20. ADR¶
Los Architecture Decision Records son Source of Truth y deben vivir en Git.
Ejemplo:
docs/decisions/
ADR-0014-edge-allowlist.md
ADR-0015-egress-nat.md
ADR-0016-agent-artifact-store.md
ADR-0017-documentation-plane.md
Lifecycle:
Los ADR históricos no se reescriben para reflejar una realidad nueva.
Una decisión posterior crea un ADR nuevo y referencia al anterior.
21. Operational Records¶
Se introduce el concepto REC-*.
Un Record registra un hecho operativo relevante e histórico, pero que no constituye necesariamente una decisión arquitectónica.
Ejemplos:
REC-0031 — BookStack production deployment
REC-0032 — Cilium ipBlock behaviour verified
REC-0033 — CephFS retired
REC-0034 — Documentation runtime cutover
Formato aproximado:
id: REC-0032
date: 2026-09-06
domain: platform
service: cilium
actor: hermes-wetopi-lead
event: >
Behaviour of ipBlock 0.0.0.0/0 verified under
current Cilium/RKE2 deployment.
evidence:
- ART-20260906-00182
related:
- INV-0192
Un REC debe considerarse esencialmente inmutable.
22. Identificadores globales¶
Para permitir relaciones entre humanos, Hermes, ADK, BookStack, Git, S3 y Hindsight se utilizarán IDs globales.
Inicialmente:
OBJ-* Objective
SVC-* Service
ADR-* Architecture Decision
RFC-* Request for Comments
DES-* Design / Architecture Pack
INV-* Investigation
INC-* Incident
RUN-* Runbook
ART-* Artifact
REC-* Operational Record
Esto permite expresar relaciones como:
Estas relaciones son especialmente importantes para Hindsight.
23. Hindsight Memory Plane¶
Hindsight constituye una cuarta dimensión del sistema.
No es:
- documentación;
- object storage;
- Git;
- una base de datos de documentos.
Hindsight representa la memoria semántica de Wetopi.
Su misión es transformar actividad histórica en conocimiento recuperable.
Principio:
Hindsight almacena significado, no documentos.
24. Qué debe entrar en Hindsight¶
Los agentes deben retener principalmente:
Facts¶
Hechos verificados.
Ejemplo:
o:
Experiences¶
Resultados de acciones y operaciones.
Ejemplo:
Durante el despliegue de BookStack se observó que una
NetworkPolicy con ipBlock 0.0.0.0/0 provocaba problemas
de conectividad bajo la configuración Cilium existente.
Observations¶
Información relevante todavía contextual o potencialmente cambiante.
Ejemplo:
Learned knowledge / Wisdom¶
Conclusiones generalizables obtenidas a partir de experiencias.
Ejemplo:
En el patrón edge hostNetwork actual de Wetopi no se deben
introducir NetworkPolicies basadas en ipBlock 0.0.0.0/0
sin validar previamente cómo Cilium traduce la identidad world.
Aquí aparece una diferencia fundamental.
El artifact puede decir:
estos fueron los 273 comandos ejecutados.
BookStack puede decir:
así diagnosticamos este tipo de problema.
Git puede decir:
ésta es la arquitectura que hemos decidido.
Hindsight puede aprender:
cuando aparece este patrón de síntomas en Wetopi, comprobar X antes de Y.
Eso es sabiduría operacional.
25. Hindsight debe guardar punteros¶
Siempre que sea posible, una memoria debe contener referencias a su evidencia.
Ejemplo conceptual:
type: learned
subject: cilium-network-policy
knowledge: >
Under Wetopi's current edge hostNetwork topology,
broad ipBlock policies require explicit validation.
confidence: high
occurred_at: 2026-09-06
derived_from:
- INV-0192
- ART-20260906-00182
- REC-0032
canonical:
- ADR-0023
Así Hindsight puede responder rápidamente y un agente puede posteriormente recuperar la evidencia original.
26. De información a sabiduría¶
El Knowledge Plane debe permitir este proceso:
EVENT
│
▼
Raw observations
│
▼
ARTIFACT
│
ART-* / Ceph S3
│
▼
INVESTIGATION
│
INV-*
│
┌──────────┴──────────┐
│ │
▼ ▼
KNOWLEDGE DECISION
BookStack Git
│
ADR-*
│ │
└──────────┬──────────┘
▼
HINDSIGHT
│
facts / experience
observations
relationships
│
▼
WISDOM
Hindsight no recibe indiscriminadamente cada output.
Debe recibir el resultado destilado.
27. Ejemplo completo¶
Un agente detecta problemas de conectividad.
Paso 1 — Scratch¶
Ejecuta:
Los outputs temporales viven en su workspace.
Paso 2 — Artifact¶
La investigación merece conservarse.
Se crea:
en S3.
Contiene:
Paso 3 — Investigation¶
Se registra:
con referencia al artifact.
Paso 4 — Knowledge¶
El diagnóstico tiene valor operacional futuro.
BookStack recibe:
No necesita contener los 20 MB de evidencia.
Enlaza a:
Paso 5 — Decision¶
Se determina que Wetopi no utilizará determinado patrón de NetworkPolicy.
Se crea:
en Git.
Paso 6 — Record¶
Se registra el evento:
Paso 7 — Hindsight¶
Se retienen:
Fact
Experience
INV-0192 demonstrated connectivity loss caused by the
tested policy under the current Cilium configuration.
Learned knowledge
When debugging remote connectivity failures after introducing
NetworkPolicy in Wetopi, validate Cilium identities and policy
translation before investigating the application itself.
Y referencias:
El siguiente agente no necesita empezar desde cero.
28. Knowledge promotion¶
No todo lo producido debe ascender.
Scratch
│
│ worth keeping?
▼
Artifact
│
│ contains reusable knowledge?
▼
BookStack
│
│ establishes a contract/decision?
▼
Git
Hindsight es transversal:
Puede aprender de diferentes etapas, pero la calidad/confianza de la memoria debe depender de la madurez de la fuente.
29. Confidence derivada de la fuente¶
Como política futura, puede resultar útil considerar:
raw observation → low / contextual
INV verified → medium/high
BookStack consolidated→ high
REC → high
ADR accepted → authoritative
Esto no implica que Hindsight deba implementar exactamente esos niveles internamente.
Es una regla conceptual para el proceso de curación.
30. Memory Curator¶
A medida que crezca la flota será necesario un proceso de curación de memoria.
El curator deberá poder:
- detectar duplicados;
- fusionar conocimiento equivalente;
- detectar contradicciones;
- detectar conocimiento obsoleto;
- aumentar confianza mediante evidencia repetida;
- reducir confianza ante contradicciones;
- convertir experiencias repetidas en conocimiento general;
- relacionar memoria con ADR/REC/INV/ART;
- marcar candidatos a eliminación.
Nunca debería borrar agresivamente una memoria simplemente porque parece obsoleta.
Un posible lifecycle:
ACTIVE
│
├── reinforced ─────► ACTIVE
│
├── superseded ─────► SUPERSEDED
│
└── obsolete? ──────► DELETE_CANDIDATE
│
│ grace period
▼
REVIEW
/ \
KEEP DELETE
De esta manera la flota puede olvidar de forma controlada.
31. Diferencia entre memoria y documentación¶
Una regla crítica:
Un documento no debe convertirse en una memory simplemente copiándolo entero.
Incorrecto:
Correcto:
Fact:
Wetopi uses dedicated NAT gateways for controlled egress.
Source:
ADR-0041
Architecture:
DES-EGRESS-001
Evidence:
ART-03921
La memoria sabe qué sabemos y dónde demostrarlo.
32. Agent Documentation Contract¶
Todos los agentes Wetopi, independientemente de que sean Hermes o ADK, deberán seguir el mismo contrato documental.
Al finalizar trabajo relevante deberán evaluar:
1. ¿Hay artifacts que conservar?
→ ART / S3
2. ¿Hemos descubierto conocimiento reutilizable?
→ BookStack
3. ¿Hemos tomado o propuesto una decisión?
→ ADR / Git
4. ¿Ha ocurrido un evento operativo históricamente relevante?
→ REC
5. ¿Qué hechos/experiencias/aprendizajes merece recordar la flota?
→ Hindsight
6. ¿A qué OBJ/SVC/INC/INV está relacionado?
→ establecer relaciones
Esto debe formar parte del harness, no depender exclusivamente de que el agente "se acuerde" de documentar.
33. Separar Agent Identity de Knowledge Ownership¶
Aunque Workbench puede tener áreas:
el conocimiento consolidado nunca debe organizarse principalmente por quién lo generó.
Incorrecto:
Correcto:
La identidad del agente pertenece a metadata/provenance.
El conocimiento pertenece al sistema sobre el que habla.
34. Single Source of Truth¶
Un mismo contenido no debe mantenerse simultáneamente en varios sistemas.
Cuando un draft se promociona:
la página original debe quedar como:
No debe mantenerse una segunda versión editable.
Lo mismo aplica a Architecture Packs y documentación formal.
35. Doc Rot¶
La documentación desactualizada debe ser visible.
Metadata recomendada:
Estados posibles:
Un documento stale no debe desaparecer.
Debe señalar claramente que necesita revisión.
36. Machine-readable metadata¶
Siempre que el soporte lo permita, la documentación producida por agentes debe incluir metadata estructurada.
Ejemplo:
id: INV-0192
type: investigation
domain: platform
service: cilium
status: completed
created_at: 2026-09-06
last_verified: 2026-09-06
owner: platform
agents:
- hermes-wetopi-lead
objective:
- OBJ-0042
artifacts:
- ART-20260906-00182
decisions:
- ADR-0023
records:
- REC-0032
Esto permitirá construir posteriormente índices, knowledge graphs y herramientas de navegación sin tener que interpretar únicamente lenguaje natural.
37. BookStack no debe reflejar los repositorios¶
No crear:
como estructura primaria.
Los repositorios son una decisión de organización de código.
BookStack representa la arquitectura conceptual de Wetopi.
Por ejemplo:
aunque la implementación viva en:
38. Política de creación de Books¶
Las Shelves principales pueden existir desde el principio para proporcionar el mapa conceptual.
Los Books deben crearse sólo cuando exista contenido real.
Evitar estructuras aspiracionales vacías.
Principio:
Empty taxonomy is noise.
Especialmente para agentes, una estructura vacía puede parecer una fuente válida de información cuando en realidad no contiene conocimiento.
39. Knowledge Graph implícito¶
Los identificadores globales permiten construir progresivamente un grafo:
SVC-CILIUM
│
├── governed_by → ADR-0023
│
├── investigated_by → INV-0192
│
├── evidence → ART-02881
│
├── changed_by → OBJ-0042
│
└── event → REC-0032
Hindsight puede aportar encima relaciones semánticas:
Esto permite evolucionar hacia un verdadero Wetopi Knowledge Graph sin necesitar diseñar desde el primer día una base de datos de grafos independiente.
40. Search strategy para agentes¶
Cuando un agente necesita responder una cuestión sobre Wetopi, conceptualmente debería buscar en este orden según la naturaleza de la pregunta.
Para realidad contractual:
Para explicación y operación:
Para experiencia histórica y conocimiento previo:
Para evidencia:
Pero Hindsight puede actuar como primera capa de descubrimiento:
Es decir:
Memory discovers; sources prove.
41. Modelo final¶
WETOPI KNOWLEDGE PLANE
HINDSIGHT
┌─────────────────────────┐
│ Memory │
│ Facts │
│ Experiences │
│ Observations │
│ Learned knowledge │
│ Relations │
│ Wisdom │
└────────────┬────────────┘
│
semantic index
+ references
│
┌─────────────────────────┼──────────────────────────┐
│ │ │
▼ ▼ ▼
┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│ GIT │ │ BOOKSTACK │ │ CEPH S3 │
│ │ │ │ │ │
│ Canonical │ │ Living │ │ Artifact │
│ Source of Truth│ │ Knowledge │ │ Store │
│ │ │ │ │ │
│ ADR │ │ Guides │ │ Evidence │
│ Architecture │ │ Operations │ │ Logs │
│ Policies │ │ Troubleshoot │ │ Dumps │
│ Contracts │ │ Investigations │ │ Reports │
│ Code docs │ │ Workbench │ │ Captures │
└───────▲────────┘ └───────▲────────┘ └───────▲────────┘
│ │ │
│ PR │ API │ S3 API
│ │ │
└────────────────────────┼─────────────────────────┘
│
▼
┌─────────────────────────┐
│ AGENT FLEET │
│ │
│ Hermes │
│ ADK │
│ Humans │
│ CI / Automation │
└─────────────────────────┘
42. Regla resumida¶
La política completa puede condensarse en cuatro preguntas:
¿Es evidencia o output bruto?¶
Artifact Store / S3
¿Es conocimiento que necesitamos consultar y comprender?¶
BookStack
¿Es una decisión, arquitectura o contrato que debe versionarse?¶
Git
¿Es algo que queremos que Wetopi recuerde y reutilice?¶
Hindsight
O, de forma aún más compacta:
Raw → S3
Knowledge → BookStack
Contract → Git
Wisdom → Hindsight
43. Próximos pasos¶
Fase 1 — Taxonomía¶
Crear las Shelves principales de BookStack:
00 Start Here
10 Infrastructure
20 Platform
30 Wetopi App
40 WordPress Hosting
50 Operations
60 Agents & Automation
70 Decisions & Architecture
80 Product & Business
90 Agents Workbench
Crear únicamente los Books que tengan contenido real.
Fase 2 — Artifact Store¶
Desplegar/configurar Ceph RGW o seleccionar el endpoint S3 compatible definitivo.
Crear:
Definir:
- naming;
- manifest;
- IAM;
- credenciales por agente;
- lifecycle;
- retention classes.
Fase 3 — Global IDs¶
Formalizar:
y definir generación/registro de IDs.
Fase 4 — Agent Documentation Contract¶
Añadir al harness Hermes el cierre documental:
El mismo contrato deberá reutilizarse posteriormente por ADK.
Fase 5 — Hindsight integration¶
Formalizar el bridge documental hacia Hindsight.
Cada cierre de objetivo/investigación deberá evaluar:
facts_to_retain
experiences_to_retain
observations_to_retain
learned_knowledge
relations
source_pointers
Nunca realizar un retain indiscriminado del documento completo.
Fase 6 — Memory Curator¶
Diseñar el proceso periódico de:
deduplicate
consolidate
reinforce
contradiction detection
supersede
decay
DELETE_CANDIDATE
grace period
validated deletion
El objetivo no es acumular memoria.
El objetivo es aumentar progresivamente la calidad del conocimiento disponible para la flota.
44. Visión final¶
Wetopi no debe tener simplemente "documentación".
Debe disponer de un Knowledge Plane.
Los agentes generan continuamente datos y experiencia.
El sistema transforma progresivamente:
Ceph/S3 conserva la evidencia.
BookStack convierte información en conocimiento navegable.
Git mantiene las decisiones y contratos que definen la realidad de la plataforma.
Hindsight conecta hechos, experiencias, observaciones y decisiones para que la flota pueda aprender de su propia historia.
El resultado buscado es que un agente nuevo no sólo pueda averiguar:
"¿Cómo está desplegado Cilium?"
sino también:
"¿Por qué está desplegado así?"
"¿Qué problemas hemos tenido antes?"
"¿Qué intentamos y qué ocurrió?"
"¿Qué decisión tomamos?"
"¿Qué evidencia soporta esa decisión?"
"¿Qué aprendió Wetopi de todo ello?"
Ese conjunto constituye el Wetopi Knowledge & Documentation Plane.