docs: log de sesion 2026-11-01 (opencode) + propuesta de claves por agente/host

2026-11-01 20:35:16 +00:00
4 changed files with 58 additions and 95 deletions
@@ -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
@@ -0,0 +1,22 @@
 # 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.
@@ -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
@@ -0,0 +1,36 @@
 # 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.