Mantener

Un nodo de Oasis no se instala y se olvida. Upstream publica versiones, los discos fallan. Esta puerta es para quien ya tiene algo corriendo.

Estado

• Subir de versión: ejercido en la demo · 2026-10-25 · reporte · falta: prueba en frío (WP-O118)
• Recuperar: ejercido en la demo · 2026-09-17 · reporte · falta: prueba en frío (WP-O118)

La última subida del pub de demostración, de 1.3.2 a 1.3.8, se hizo con este protocolo en 31 minutos de host: tres nodos, cada uno publicó exactamente lo que se había declarado antes de tocar el servidor, y nada más. El ensayo en local destapó que upstream había absorbido uno de los guards del fork (se retiró, con asiento), que la versión nueva trae un guardián que repara feeds por su cuenta (se mide, no se supone) y que las salas pueden salir a la web; las tres cosas se pararon, se decidieron con el custodio y quedaron escritas. En 1.3.2 fue el vídeo en las llamadas. En 1.2.8 fue la puntuación de karma, que un nodo publica solo. La de 1.1.10 a 1.2.1 fue un cambio de motor de base de datos, de los que no tienen vuelta atrás.

Qué le dices a tu agente

Para subir de versión:

Hay versión nueva de Oasis.
Sube mi pub siguiendo el protocolo de upgrade.
Lee docs/roles/mantener.md. Ensáyalo en local antes
y pídeme permiso en cada puerta.

Si algo se ha roto:

Algo va mal con mi nodo. No toques nada todavía.
Lee el protocolo de recuperación, haz el triaje y dime qué hay.

Qué necesitas tener

• Para subir: acceso al servidor, Docker en tu máquina para el ensayo y un rato sin prisa. Cada nodo se reinicia una vez.
• Para recuperar: paciencia. La regla es no usar nada hasta saber qué está sano.

Qué hará el agente al subir de versión

Paso	Qué	Salida esperada
1	Medir qué hay desplegado	versión de cada nodo, deriva del servidor frente al repo	solo lectura
2	De qué versión a cuál, y qué código cambia para cada rol	dos commits de upstream
3	Traer el código nuevo y reponer los 6 guards (6 ficheros)	exactamente 7 ficheros distintos de upstream
4	Sacar qué cambia de comportamiento y disponer cada línea por escrito	ninguna línea sin leer
5	Ensayo en local con identidades desechables: recrear cada nodo y medir qué publica	un anuncio de versión por nodo y nada más	si aparece otra cosa: parar
5b	Si la versión cambia el motor de base de datos: ensayar la migración sobre una copia	los mismos registros antes y después	DECISIÓN: tras migrar no hay vuelta atrás
6	Copias de seguridad y preparación del rollback en el servidor		PERMISO: escribe en el servidor
7	Subir el pub	sano, misma identidad	PERMISO: se reinicia y publica
8	Subir cada nodo de soporte	sano, misma identidad	PERMISO por nodo
9	Cerrar: medir, apuntar el despliegue, escribir el reporte

Detalle: protocolo de upgrade, con sus gates locales y el despliegue por rol.

Qué hará el agente si algo se ha roto

1. Nada, hasta haber comprobado qué está entero: disco, repo, identidad, historial.
2. Poner a salvo lo irremplazable: el secret y las claves.
3. Reconstruir lo derivable (código, imagen, índices) desde su fuente.
4. Si se perdió el historial de una identidad: nodo sin aplicación hasta sincronizar, y la aplicación al final. Es la parte delicada.

Detalle: protocolo de recuperación.

Lo que no tiene vuelta atrás

• Subir publica, y volver atrás también. Cada nodo anuncia su versión cuando cambia; un rollback publica otro anuncio. Ningún rollback es gratis.
• Arrancar una identidad con un historial más corto que el de la red parte la cuenta en dos.
• Borrar volúmenes se lleva estado que no se puede reconstruir.

La tabla completa: acciones irreversibles.

Cómo se comprueba

• npm run devops:status: versión por nodo, salud, directorio de la red.
• npm run devops:upgrade:gates -- --remote check con el delta declarado: lo que cada nodo ha publicado desde la foto previa es lo previsto.

Protocolo de fondo

• Protocolo de upgrade y sus anexos por pieza.
• Protocolo de recuperación.
• Reglas universales y trampas conocidas.