Restore Knowledge Platform

Fecha: 2026-06-01

Objetivo

Recuperar la plataforma documental O6 si alguien borra, pisa o desordena informacion del repo.

Que protege este runbook

• docs/governance/
• documentos maestros como ROADMAP.md y PROJECT-STATE.md
• diagramas Mermaid
• catalogos y runbooks

Prevencion diaria

• trabajar siempre en Git
• no cerrar cambios sin git status -sb
• revisar diferencias antes de commitear
• commitear cambios documentales juntos y con mensaje claro
• no borrar docs grandes sin revisar referencias

SAFE POINT minimo antes de tocar docs

1. correr git status -sb
2. correr git rev-parse HEAD
3. si el arbol no esta limpio, entender que cambios ya existen
4. si el cambio es grande, dejar el SHA previo anotado en el documento de turno

Si alguien piso o borro informacion

Caso 1 - el cambio todavia no fue commiteado

1. correr git status -sb
2. identificar archivos afectados
3. revisar el diff con git diff -- <archivo>
4. restaurar solo si hay confirmacion humana clara de que ese cambio fue un error

Caso 2 - el cambio ya fue commiteado

1. ubicar el commit sano con: git log --oneline -- docs/governance
2. inspeccionar el contenido sano con: git show <sha>:docs/governance/...
3. recrear el documento faltante o corregido con un commit nuevo
4. no reescribir historia salvo necesidad extrema y aprobada

Caso 3 - la realidad cambio y la doc quedo vieja

1. no hacer rollback ciego de la documentacion
2. correr una nueva auditoria de realidad
3. actualizar docs para que vuelvan a reflejar el VPS actual
4. registrar la diferencia en el documento operativo correspondiente

Auditoria periodica reality vs docs

Frecuencia recomendada:

• despues de cada cambio de infraestructura
• antes de updates mayores
• al menos una vez por mes si no hubo cambios grandes

Chequeos minimos:

• docker ps
• docker network ls
• docker volume ls
• docker inspect de contenedores clave
• validacion de targets Prometheus
• revision de ROADMAP, PROJECT-STATE, VALIDATION-STATE y control towers

Recuperacion por Git

• para revisar historial: git log --oneline
• para revisar un archivo anterior: git show <sha>:ruta/al/archivo
• para recuperar una version entera por commit nuevo: aplicar el contenido correcto y commitear

Recuperacion por remoto

Si el repo local se pierde pero GitHub sigue sano:

1. clonar el repo otra vez
2. abrir docs/governance/
3. comparar con el VPS real
4. correr una auditoria corta antes de declarar la restauracion como cerrada

Cierre correcto de recuperacion

• git status -sb limpio
• docs maestros actualizados
• diferencias reality vs docs revalidadas
• commit claro
• push hecho