# 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).