docs: diseño mínimo de la vía de publicación de bitcoinhotels (PRs + guard + build + auto-deploy)

docs/bitcoinhotels-publish.md

@@ -0,0 +1,35 @@
+# 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).