Proyecto · DevOps

Cómo fluye Oasis SDK desde el código hasta el nodo corriendo. Las URLs concretas (repo, registry, CI, Pages) viven en el pie y la navegación de este portal — aquí va el flujo, no las direcciones duplicadas.

Flujo: código → registry → CI → Pages

1. Código. Fork dockerizado de Oasis en la forja. La app upstream vive bajo src/; la capa fork (Docker, compose, entrypoint, pub/, devops) se mantiene wholesale sobre ella.
2. Skills / tooling. Las skills de agente (@alephscript/skills-scriptorium) se instalan desde el registry privado y se materializan a .claude/skills/ con npm run skills:sync — espejo auditable, fuente de verdad en package-lock.
3. CI. GitHub Actions construye este portal de docs (VitePress) en cada push que toque docs/** o la versión de Oasis, y lo publica en Pages cuando el push es a main.
4. Pages. Este sitio, servido en o-sdk.escrivivir.co desde la propia forja.

Roles de despliegue (misma imagen, tres modos)

Rol	Cómo	Persistencia
Cliente (full)	docker compose up -d oasis-client	volumen .ssb (identidad) + modelos IA
Pub (server, VPS)	pub/scripts/deploy.sh	.ssb del pub + backup previo obligatorio
Nodo de soporte (backend: HUB, bots)	docker compose up -d --no-deps <servicio> en el compose del pub	.ssb propio de cada nodo

El invariante en los tres: preservar el .ssb (la clave secret es la identidad). Todo lo demás — índices, blobs, log — es derivable y se re-replica desde la red.

Quién llega a cada rol y qué le encarga a su agente: ¿Quién llega?.

Manuales operativos

• Protocolo para agentes — empieza aquí: qué leer según la intención, reglas universales, acciones irreversibles, trampas conocidas y convención de nombres de los bots. Datos de nuestro despliegue: ficha de instancia.
• Protocolo de upgrade — overlay del upstream, re-aplicación de los fork-guards, deploy por rol y healthcheck.
• Capacidad — inventario único de lo que crece en disco y en memoria, quién lo hace crecer, qué límite tiene y cómo se mide.
• Protocolo de recuperación — triaje de integridad, salvamento del repo por plumbing, rebuild de imagen y la secuencia sbot-puro → sync → GUI que evita bifurcar el feed.
• Protocolo del HUB clearnet — el HUB web /c como nodo de soporte (segundo nodo SSB, misma imagen, caché nginx en disco): activación, verificación, disco, memoria, upgrades y rollback; serie de bots de soporte y su renombrado.
• Protocolo de ECOin — hub-wallet del pub: ecoind en contenedor propio y bot de cartera; backup, disco, memoria, RBU.
• Protocolo del cliente — app cliente: alta, importar identidad, upgrade y cartera ECOin.
• Protocolo de plantillas — el organigrama de un colectivo convertido en tribus, salas, calendarios y listas de su pub: siembra por bloques con permiso, y su deshacer.
• Teatro: obra · curaduría · sidecar de RRSS · P2P.

Doctrina editorial del portal (qué se afirma, con qué referencia y con qué sello): BASE-1-ARGUMENTO.md, BASE-2-SISTEMA.md, BASE-3-MECANISMO.md, en la raíz del repo.

Contribuir

El trabajo va por paquetes pequeños, una rama por paquete y una pieza por commit; lo que toca un servidor vivo o publica algo se ensaya antes en local con una identidad desechable. El método está en plan/PRACTICAS.md y las decisiones en plan/DECISIONES.md, en el repo. La prueba de que un protocolo sirve es que un agente sin contexto lo complete: si quieres ayudar, coge una puerta que esté «en obras» o prueba en frío una ya ejercida.

Verificación

El portal se construye con ignoreDeadLinks: false y pasa un gate sobre el dist/ antes del deploy (npm run docs:verificar): enlaces internos y anclas deben resolver; la versión de Oasis sale leída del sistema, no escrita a mano; ninguna puerta dice «probado» o «ejercido» sin citar su reporte; y las páginas de rol no nombran a la instancia de demostración. Nada se publica roto.