cayce-ops/docs/bitcoinhotels-publish.md

Vía de publicación de bitcoinhotels (diseño mínimo)

Objetivo: las guías del sitio entran como PRs, y si pasan publish-guard + build, se mergean y despliegan solas (directiva 2026-11-01, punto 4). El código del sitio NO entra aquí: sigue siendo PR con merge humano.

Piezas

1. Repo cayce/bitcoinhotels-content (privado): SOLO content/guides/*.md
   • manifest.json (orden, títulos). Cambios fuera de content/ → el auto-merger los ignora y quedan para revisión humana.
2. Auto-merger (cayce-ops/cayceops/plugins/bitcoinhotels_prague.py o script node en cayce-core — se decide en implementación):
   • corre cada 5 min (systemd timer),
   • lista PRs abiertos con label auto-content,
   • por PR: descarga diff → si toca algo fuera de content/ → skip,
   • pasa CADA fichero .md nuevo/modificado por el mismo guard.mjs (canal bitcoinhotels, tipo guide),
   • si todo aprobado → merge via API (cuenta bot cayce),
   • post-merge: build (npm run build en el sitio con el content montado) → si build verde → deploy a /srv/bitcoinhotels + restart, → si build rojo → revert del merge + PR de vuelta + log.
3. Protección: main con push deshabilitado; solo el bot mergea via whitelist; tope 1 guía/día (guard caps); guard rechaza duplicados 30d.
4. Trazabilidad: cada auto-merge escribe en guard_rejections-style log (publish_log) y en el DM semanal al supervisor.

Lo que NO hace la V1

• No publica sin PR (no hay escritura directa al sitio).
• No toca código/diseño del sitio (eso es PR humano).
• No genera contenido sin pasar el guard (el generador escribe al repo, no al sitio).

Pendiente de decisión

• Bot dedicado (cayce-content) vs usar la cuenta cayce (recomendado: bot dedicado cuando exista cuenta personal del operador).