Maintain Knowledge Platform

Fecha: 2026-06-01

Objetivo

Mantener viva la capa docs/governance/knowledge/ cuando cambia la realidad del VPS.

SAFE POINT minimo

1. correr git status -sb
2. correr git rev-parse HEAD
3. si hay cambios previos, entender si son tuyos o de otra tarea

Fuentes permitidas

• repo actual
• VPS auditado por SSH
• archivos reales ya existentes

No inventar futuro como realidad.

Cuando aparece un contenedor nuevo

1. correr docker ps
2. confirmar nombre, imagen, puertos, redes y mounts
3. actualizar: knowledge/docker/containers/README.md
4. si pertenece a observabilidad o runtime critico, crear o actualizar su ficha atomica
5. revisar si cambia algun diagrama Mermaid
6. revisar si cambia alguna alerta o dashboard

Cuando aparece un volumen nuevo

1. correr docker volume ls o confirmar bind mount real
2. identificar dueño, datos que guarda y backup asociado
3. actualizar: knowledge/docker/volumes/README.md
4. si es un volumen Docker nombrado relevante, crear su ficha individual
5. revisar restore y backup correspondiente

Cuando aparece una red nueva

1. correr docker network ls
2. identificar quien se conecta y para que sirve
3. actualizar: knowledge/docker/networks/README.md
4. crear ficha propia de la red
5. revisar diagramas 01, 02 y 05 si cambia exposicion

Cuando cambia un puerto

1. confirmar el cambio en runtime real
2. actualizar la tabla de contenedores
3. actualizar la ficha del stack o servicio afectado
4. revisar tests, diagramas y seguridad si el puerto es publicado

Cuando cambia una alerta

1. revisar infra/observability/prometheus/rules/*.yml
2. actualizar la ficha del componente protegido
3. actualizar knowledge/observability/README.md si cambia el inventario
4. revisar O4-ALERTS-CATALOG.md y diagramas de alerting

Cuando cambia un dashboard

1. revisar infra/observability/grafana/dashboards/
2. actualizar la relacion servicio -> dashboard
3. actualizar la ficha del componente o servicio afectado
4. revisar O4-DASHBOARDS-CATALOG.md

Cuando aparece una integracion nueva

1. buscar evidencia real en runtime, config o logs
2. crear una ficha en knowledge/integrations/
3. separar: realidad comprobada, dependencia declarada, futuro posible y pendientes
4. no marcar VERDE si no hay evidencia funcional real

Cuando se elimina un servicio

1. confirmar que de verdad ya no corre
2. actualizar contenedores, redes, volumenes y diagramas
3. mover la referencia a legado si todavia quedan artefactos
4. actualizar O8.0-KNOWLEDGE-COVERAGE-AUDIT.md

Checklist de cierre

• SAFE POINT documentado
• evidencia real citada
• navegacion principal actualizada si cambia estructura
• diagramas revisados
• auditoria O8.0 revisada si cambia cobertura
• PROJECT-STATE y ROADMAP revisados si el cambio es estructural
• git status -sb revisado antes de commit