recupera 2 ficheros sin commit del respondedor (31-oct): SPEC.md (draft plugin BTCPay) y docs/cayce-dev.md (diseño subagente)

Ambos estaban untracked en el working tree desde el 31-oct 18:46-18:52Z.
Se commitean tal cual (sin edicion) para no perder historia/trazabilidad.

SPEC.md

@@ -0,0 +1,47 @@
+# 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/agent-keys.md

@@ -1,22 +0,0 @@
-# Propuesta: claves por agente y por host (dejar de usar la clave maestra)
-
-Problema: la clave ED25519 gustavo@blinkbtc.com (~/.ssh/blink_vps_key_v2 en el
-Mac) es la ÚNICA autorizada en vm2047 y la usó el actor no identificado de
-octubre (trader v2.4, burbujas, sfeed, respondedor). Un solo secreto, todo el
-poder, cero trazabilidad por agente.
-
-Propuesta (por orden de adopción):
-1. Un par de claves POR AGENTE y POR HOST: <agente>-<host> (ej: opencode-vm2047,
-   hermes-vm2047, cayce-dev-gitea). ed25519, sin passphrase, en ~/.ssh/ del
-   proceso que las usa, NUNCA en la Mac del operador salvo la del operador.
-2. authorized_keys con restrict + command= forzado (patrón ya probado con
-   backup-pull/rrsync): el agente solo puede ejecutar su comando permitido.
-3. Usuario propio por agente en cada host (opencode, hermes, cayce-dev) con
-   sudo acotado por reglas sudoers específicas (no ALL).
-4. Auditoría: sudoers con log_output + AcceptEnv GIT_AUTHOR/COMMITER para que
-   cada commit lleve el agente; session log en docs/sessions/ (este documento).
-5. Rotación de salida: retirar gustavo@blinkbtc.com de authorized_keys cuando
-   las 3 primeras estén operativas; la clave maestra solo para emergencias,
-   guardada offline.
-6. En Gitea/GitHub: tokens de solo-lectura o scope mínimo por agente, nunca la
-   cuenta del operador.

docs/cayce-dev.md

@@ -0,0 +1,48 @@
+# 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
+

docs/sessions/2026-11-01-opencode-m1.md

@@ -1,36 +0,0 @@
-# Sesión 2026-11-01 — OpenCode/GLM en m1s-macbook-pro (operador: patternn)
-
-Hosts: vm2047.lnvps.cloud (ssh lolvm), blink-vps (lectura), GitHub (gh, patternn), Gitea git.cayce-co.xyz.
-
-## Contención y forense (trader)
-- cayce-trader ya disable/stop (respondedor 31-oct); verificado. /etc/hosts: 16 endpoints Binance a 0.0.0.0, curl sin conexión.
-- Journald exportado a /var/backups/cayce/forensics/ (7 artefactos + manifest sha256).
-- Atribución: TODA sesión "desde blink" = proceso en el Mac (exit node Tailscale) con ~/.ssh/blink_vps_key_v2. v2.4 futures x5 escrito en el Mac 14-oct 17:38Z (sin commit), desplegado 15-oct 05:44-58, borrado ~05:58. Harness no identificado. Informes: FORENSICS-REPORT-20261101.md, ACTIONS-20261101.md.
-
-## Infra
-- Gitea TLS https://git.cayce-co.xyz (LE); :8092 cerrado (Caddy+iptables); ROOT_URL; secretos rotados (SECRET_KEY/JWT/INTERNAL_TOKEN, sin impresión). Usuario pattern (merge exclusivo) + script gitea-set-merge-owner.
-- Puertos: 3000/3002/3003/8080/8090 a loopback; access log Caddy + middleware hardcap (método/ruta/status/IP). 8080 era host-matcher malentendido, no bind.
-
-## Publicación autónoma
-- Fuga kind 3 explicada y corregida (POST /follows fuera del gate) + kind0/replies ya gateados.
-- guard.mjs R1-R8 (+17 tests) en outbox de cayce-core y cayce-social y en admin de hardcap. Rechazos → guard_rejections.
-- Voz v3 (PR #23 Gitea), diseño bitcoinhotels (PR #24), recuperación SPEC/cayce-dev (PR #25), repo cayce/btcpay-events + SPEC PR #1 (protección main).
-- Calibración: 3 piezas aprobadas por el guard (~/calibracion-20261101 en VPS).
-- ACTIVADO live 2026-11-01 20:19 UTC (4 .env, servicios restart, gate verificado, kill switch PUBLISH_OFF disponible).
-
-## Backups
-- age recipient nuevo (Mac ~/.config/cayce-backup/age.key, secreto jamás impreso) + clave backup-pull instalada con rrsync -ro. Bugs: fallback PGURL, GRANT posts_log, NoNewPrivileges. Primer backup OK (3 .age, 1.6M) y pull del Mac verificado (manifest 3xOK). Cadena: VPS 03:15 UTC / Mac 23:30 + launchd.
-
-## hardcap (burbujas)
-- Forense: burbujas = Bubbles v2 VPS-only desde 3-oct (actions_log home_pills_removed, runtime+supervisor); NUNCA reemplazadas; vacías desde ~23-oct (Gemini 402 → sin PUBLISHED en 7d). 402 exacto: prepayment credits depleted (AI Studio), key válida.
-- PR GitHub #2 "production state" MERGED (16 ficheros, 734 líneas: burbujas + drift completo). PR #1 (treemap, premisa errónea) CLOSED.
-- /srv/hardcap-news = checkout git único para FE+BE (swap con rollback .pre-git-20261101; health 200; working tree limpio). Timer cayce-check-clean-trees diario 09:10 UTC.
-- scripts/reprocess-pending.ts añadido (para cuando vuelvan créditos AI Studio).
-
-## IG
-- META_PAGE_TOKEN del .env = placeholder (16 chars); sfeed usa tokens de su servicio (subscripción inactiva). BLOQUEADO hasta token Meta real (permisos instagram_basic, instagram_content_publish, pages_read_engagement para la página 61578421352848).
-
-## Pendientes del operador
-- Recargar créditos AI Studio (aistudio.google.com → Billing) y correr reprocess.
-- Token Meta para IG. Rotar tokens automation/automation2 de Gitea.
-- Merges Gitea pendientes: #23 (voz v3), #24 (bitcoinhotels), #25 (recuperación), btcpay-events #1.