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

SPEC.md

@@ -1,47 +0,0 @@
-# BTCPay Server Plugin: Event & Travel Integration (V1)
-
-## 1. Data Sources & Verification
-- Event data: Curated from hardcap.news RSS/API feed (events aggregated by Cayce runtime §9). Source list documented in `sources/` directory with QC-3 citations.
-- Lodging data: `bitcoinhotels.org` static listings API. No real-time availability checking in V1 - listings are curated, not live.
-- Verification: Event dates/coords verified against hardcap.news primary sources only. No automated scraping of third-party calendars.
-
-## 2. Booking & Payment, Sellers & Refunds
-- Booking: Plugin displays curated BTC-friendly hotel/merchant listings with deep links to `bitcoinhotels.org`. Reservation/payment occurs off-site via the hotel's own system.
-- Seller: Individual hotels/merchants own their availability and booking terms. The plugin has no inventory control.
-- Refunds: Responsibility of the hotel/merchant, not the plugin or organizer. Plugin displays refund policy links where provided by the hotel.
-- Payment processing: BTCPay Server handles event ticket/registration payments (sats only). No hotel payments flow through BTCPay in V1.
-
-## 3. BTCPay Server Plugin API Capabilities (official sources)
-- Event feed ingestion: Plugin reads hardcap.news event RSS feed (curated by Cayce). Auto-generates event landing pages on bitcoinhotels.org.
-- Geolocation filtering: Hotel listings filtered by proximity to event venue coordinates (lat/lon).
-- BTCPay payment integration: Accept sats for event registrations via BTCPay Server's payment API. Plugin creates order → attendee pays → organizer receives notification.
-- Blink Donate Button: Embedded for voluntary zaps to support ongoing curation.
-- Limited V1 scope: RSS feed ingestion & template generation; Geolocation-based filtering; BTCPay payment acceptance for event tickets; Static Blink button embed; NO real-time availability checking; NO hotel inventory management; NO automated refund processing.
-
-## 4. Privacy: Data Requests & Storage
-- Data requested: Event title, dates, venue coordinates (lat/lon), hotel merchant name, brief description, deep link URL.
-- Data storage: Event coords stored in plugin's `data/events.json` (plain text, no personal data); Merchant names and URLs stored as provided by bitcoinhotels.org; NO IP addresses, NO user identifiers, NO location data beyond event venue coords.
-- Privacy rule: No "zero KYC" claims without substantiation. All data is publicly derivable from the event and hotel listings. No user tracking.
-
-## 5. What Each Party Gains (no marketing language)
-- Event organizers: Turnkey way to surface BTC-friendly lodging within event checkout. No platform fees. BTC-only payments expand circular economy.
-- Attendees: Find BTC-friendly lodging without leaving event checkout. Pay with sats. Merchant choices are curated (no altcoin-promoting hotels).
-- Hotel merchants: Exposure to Bitcoin-targeted audience. No platform fees for listing. Direct booking relationship.
-- Cayce/bitcoinhotels: Continuous curation output. Plugin is open-source under MIT license. Long-term sustainability via hardcap.news adinaction and Nostr zap-gating.
-
-## 6. V1 Minimal Scope
-- Plugin scaffold with MIT license
-- RSS feed ingestion from hardcap.news (events list)
-- Landing page template on bitcoinhotels.org (event-specific)
-- Geolocation filter: proximity within 50km of event venue
-- BTCPay payment acceptance for single-price event tickets
-- Blink Donate Button embed
-- Documentation: installation, API config, admin options
-- NO availability checking, NO real-time booking, NO refund handling, NO altcoin support
-
-## Appendix: Official Sources
-- BTCPay Server Plugin Development Guide: docs.btcpayserver.org/developer/plugins
-- BTCPay Server API docs: docs.btcpayserver.org/api
-- BTCPay Server payment flow: server-specific, involves order creation → payment link → webhook notification
-- hardcap.news event curation methodology: QC-3 sourced, daily digest process
-- bitcoinhotels.org listing format: static CSV/JSON, merchant-owned availability

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

docs/cayce-dev.md

@@ -1,48 +0,0 @@
-# cayce-dev Design Document
-
-*Authorized by operator merge to main. This design governs the cayce-dev sandbox.*
-
-## Flow
-- Cayce opens a PR with SPEC.md on a product repo. Operator's merge to main = authorization.
-- cayce-dev only takes specs already merged by the operator. Implements on a branch and opens a PR. Operator merges.
-- If the spec is ambiguous, ask in the PR; do not improvise.
-
-## Gitea Access
-- Token limited to product repos (branches and PRs only).
-- No merge access, no admin access, no access to cayce-ops or hardcap.
-- Commit author: cayce-dev.
-- Workflow: operator reviews SPEC.md PR → merges → cayce-dev creates feature branch → opens PR → operator merges.
-
-## Isolation
-- Own container or user. NO access to:
-  - nsec (operator key or agent identity)
-  - .env files (operator keys, API tokens, database credentials)
-  - Production database
-  - Tokens (sfeed, Facebook, Instagram, Mail, SSH)
-  - Docker socket or any container orchestration API
-  - Operator keys or agent identities
-- Network: only local Gitea and package registries. No outbound capability beyond.
-- No deploy or publish capability.
-
-## How Each Restriction Will Be Tested
-- Container isolation: verify cayce-dev user cannot read /srv/cayce-core/.env or /home/ubuntu/.sfeed/tokens.json
-- Network: verify cayce-dev container has no internet access beyond Gitea
-- Key access: verify no Cayce nsec or operator pubkey is exposed to the sandbox
-- Auth token access: verify no operator tokens are readable
-
-## Execution
-- Model/runtime options with pros/cons (operator decides):
-  - Local LLM (private, no cost per token, limited capability)
-  - Remote API (cost per token, broader capability, privacy tradeoff)
-  - Sandboxed execution environment
-- Time/iteration/cost limits per task (operator-defined):
-  - Max 3 iterations per task
-  - Max 15 minutes per iteration
-  - Max $0.10 USD per task (using cheapest available model)
-- Mandatory tests in sandbox: every implementation must have corresponding tests within the sandbox environment
-- Execution log without secrets: every execution step must be logged without exposing secrets, API keys, or private data
-
-## Report
-- Summary in the cycle DM toward the operator
-- Include: what was executed, outcomes, any restrictions encountered, compliance status
-