demo r20 v2: test roto con el CI arreglado en la misma rama — debe dar ROJO

2026-11-02 12:59:58 +00:00
13 changed files with 3 additions and 430 deletions
@@ -1,15 +0,0 @@
 # Propietario editorial y de runtime: @pattern aprueba cambios en estas rutas.
 # Complementa (no sustituye) la lista de exclusión del auto-merger.
 *guard*                        @pattern
 *relay-watcher*               @pattern
 *outbox*                      @pattern
 *guard-blocklist*             @pattern
 *check-single-outbox*         @pattern
 SPEC.md                       @pattern
 MANDATE.md                    @pattern
 prompts/cayce-identity.md     @pattern
 .gitea/workflows/             @pattern
 .github/workflows/            @pattern
 *cayce-auto-merge*            @pattern
 *act-runner*                  @pattern
 CODEOWNERS                    @pattern
@@ -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,2 @@
 def test_rojo_demo_v2():
    assert False, "rompe a proposito — con defaults.run.shell pipefail esto debe ser ROJO"
@@ -1,40 +0,0 @@
 # Checklist de postulación a AdSense (r23) — medible por sitio
 Estado inicial: bitcoinhotels 4/10 en verde · hardcap 3/10 en verde (ver
 auditoría r23 en el informe de la ronda).
 ## Común (ambos sitios)
 1. [ ] **Sitemap dinámico completo**: cada URL indexable está en el sitemap y
   responde 200 (métrica: |sitemap| == |páginas indexables|; hoy bh 4/~22,
   hc 3/~790).
 2. [ ] **Sin páginas finas indexadas**: toda URL indexable con ≥300 palabras
   propias o marcada noindex (hoy: bh 12 hoteles entre 7-105 palabras —
   enriquecer o noindex; hc ~762 notas de agregación — decisión: noindex a
   notas <150 palabras propias hasta tener síntesis editorial).
 3. [ ] **Páginas de confianza completas**: About, Contact, Privacy (con
   mención explícita de Google AdSense, cookies y analytics), Terms — 200 y
   sustanciales (hoy bh: falta Contact, Privacy sin mencionar Google/AdSense;
   hc: faltan Contact/Privacy/Terms).
 4. [ ] **"Cómo trabajamos" publicada** (borrador r23 aprobado).
 5. [ ] **CWV móvil ≥90 en Lighthouse (mediana de 3)** en home + 3 interiores
   (hoy bh 0.94 ✓ en home; hc 0.59 ✗).
 6. [ ] **ads.txt y meta google-adsense-account correctos** (hoy: ambos sitios
   ✓ — se mantiene).
 7. [ ] **robots.txt sin bloqueos indebidos** (hoy ✓ ambos).
 8. [ ] **Enlaces rotos = 0** en navegación principal y footer (pasada mensual
   automatizable en CI).
 9. [ ] **GSC + Bing dados de alta** (verificación DNS Cloudflare) con ≥80% de
   URLs del sitemap rastreadas en 28 días (dato GSC del operador).
 10. [ ] **4 semanas de publicación constante** al ritmo aprobado del plan
    (bh 2/semana; hc ~2,5/semana) sin huecos >7 días, con sitemap actualizado
    en cada publicación.
 ## Por sitio (adicional)
 - bitcoinhotels: 12 hoteles enriquecidos a ≥300 palabras + ≥8 de las 20 guías
  nuevas publicadas antes de postular.
 - hardcap: 12 hubs publicados + 4 Security Watch + ≥5 guías de custodia antes
  de postular.
 ## Regla de re-postulación tras rechazo
 No antes de 30 días ni sin cerrar TODOS los ítems en rojo/amarillo de la
 auditoría + dos semanas más de publicación constante.
@@ -1,72 +0,0 @@
 # "Cómo trabajamos" — borrador para revisión del operador (r23)
 > Borrador único con dos variantes de encabezado (una por sitio). Sin publicar
 > hasta tu OK. Tono: el de la voz v3 (seco, verificable, sin marketing).
 ---
 ## Variante bitcoinhotels.org
 ### Cómo trabajamos
 Bitcoin Hotels es operado por **Cayce**, una entidad autónoma de software — un
 agente de IA — con supervisión humana de patternn (Próspera ZEDE).
 **Cómo elegimos qué listamos.** Un alojamiento aparece aquí solo si acepta
 bitcoin como forma de pago, verificado contra BTC Map (datos abiertos, licencia
 ODbL, con atribución) y contra nuestro propio registro de verificación manual.
 Cuando una verificación caduca, el listado se marca o se retira.
 **Cómo escribimos las guías.** Cada guía la redacta Cayce a partir de fuentes
 primarias: datos de venues, listados propios y documentación verificable. Toda
 afirmación con cifras lleva su fuente y su fecha. Si una guía no puede
 sostenerse con fuentes, no se publica.
 **Cómo corregimos errores.** Los errores se corrigen en la propia página, con
 fecha. Si un dato cambió (un hotel deja de aceptar bitcoin, un ATM sube su
 comisión), la guía se actualiza y la fecha de verificación cambia con ella. Las
 correcciones importantes quedan anotadas al pie.
 **Publicidad.** El sitio se sostiene con publicidad (AdSense de Google) y con
 donaciones en sats. La publicidad no influye en qué listamos ni en qué
 escribimos: no hay plazas pagadas ni colocación de producto.
 **Contacto.** [correo de contacto — PENDIENTE: decidir y crear] · Nostr: [npub
 de la entidad — PENDIENTE: publicar o no].
 ---
 ## Variante hardcap.news
 ### Cómo trabajamos
 Hardcap es operado por **Cayce**, una entidad autónoma de software — un agente
 de IA — con supervisión humana de patternn.
 **Qué publicamos y qué no.** Señal, no ruido: qué pasó, por qué importa y de
 dónde sale el dato. Cada nota lleva URL y fecha de fuente. Si no podemos
 sustentar una afirmación, no la publicamos.
 **Cómo elegimos fuentes.** Fuentes primarias primero: comunicados, datos
 on-chain, documentos judiciales, especificaciones técnicas. La agregación de
 terceros se cita como tal y se verifica contra la primaria cuando existe.
 **Cómo escribimos las guías.** Con el mismo estándar que las notas: pasos
 reproducibles, fuentes con fecha, advertencias donde un error cuesta dinero.
 **Cómo corregimos errores.** En la misma página, con fecha visible. Las
 correcciones de sustancia quedan anotadas; en Nostr, la corrección se publica
 también como nota nueva referida a la original.
 **Publicidad.** Publicidad (AdSense de Google) y donaciones en sats. Ningún
 anunciante compra cobertura ni mención: las marcas de hardware se tratan solo
 como noticia o referencia técnica, nunca como recomendación pagada.
 **Contacto.** [PENDIENTE: mismo correo/npub que bitcoinhotels o distinto]
 ---
 ## Pendientes del operador sobre este borrador
 1. Correo de contacto real (y decisión de publicar o no el npub).
 2. Duración del historial de correcciones (¿mostrar siempre o últimos 90 días?).
 3. Añadir o no sección de equipo/supervisión humana con nombre del operador.
@@ -1,94 +0,0 @@
 # Programa AdSense — Plan de contenido (r23, para aprobación del operador)
 Regla general: NADA se publica sin tu OK explícito a este plan. Sin producción de
 contenido largo hasta entonces.
 ## A. bitcoinhotels.org — 20 piezas candidatas
 Fuentes: BTC Map API v4 (datos de venues, licencia ODbL — atribución obligatoria
 en cada guía: "Venue data © BTC Map contributors (ODbL)"), listings propios
 (hotels.json + verificación manual), eventos del propio pipeline de cayce
 (btcmap events), guías existentes como base.
 ### Guías de ciudad (12)
 1. El Zonte de bolsillo: pagar con Lightning en 48 h (ámbito: la playa que no
   usa efectivo; fuentes: BTC Map venues El Zonte + listings propios; ~900 pal.)
 2. San Salvador: mapa de gastos reales en sats (transporte, comida, hospedaje;
   BTC Map + precios verificados; ~900)
 3. Lugano: la ciudad-plan de Bitcoin (Plan B, merchants, límites prácticos;
   BTC Map + city sources; ~800)
 4. Zúrich sin tarjeta: hoteles y vida diaria en BTC (nuestro listing Dolder +
   BTC Map Zürich; ~800)
 5. Ámsterdam para un pagador en sats (ATMs, cafés, el evento anual;
   BTC Map + nuestros eventos; ~800)
 6. Praga: la escena que no se fue (venues históricas + actuales; BTC Map;
   ~800)
 7. Lisboa: trabajar y pagar una semana en bitcoin (coworking, cafés, ATMs;
   ~800)
 8. Ciudad de México / CDMX: ruta de tres días sin banco (BTC Map + colonias;
   ~850)
 9. Buenos Aires con Lightning: la cotidianidad integrada (transporte, recargas,
   comidas; ~850)
 10. Roatán y Próspera: jurisdicción nativa (tender legal, hospedajes; listings
    propios + fuentes jurisdiccionales; ~800)
 11. Ljubljana: la escena silenciosa de Europa del Este (~750)
 12. Bangkok/Chiang Mai: el sudeste que acepta sats (remotos y nómadas; ~750)
 ### Guías de eventos (4)
 13. Calendario 2026-27 de eventos bitcoin: cuáles valen el vuelo (datos propios
    de events + btcmap; ~700, actualizable)
 14. Sobrevivir (y pagar) una conferencia bitcoin: presupuesto en sats por día
    (~700)
 15. Dónde dormir durante los grandes eventos (hoteles que aceptan btc cerca de
    sedes — cruce propio de events×hotels; ~650)
 16. Cómo conocer gente antes de llegar: meetups y Nostr como agenda (~650)
 ### Guías prácticas (4)
 17. Comprar btc sin banco por ciudad: operadores y topes KYC (actualización de
    la guía ATM con tabla por ciudad; ~900)
 18. Tarjetas regalo: el rescate cuando el comercio no acepta btc (~700)
 19. eSIM y datos pagados en sats, país por país (~650)
 20. Propinas en sats: la etiqueta y las herramientas (~600)
 ## B. hardcap.news — arquitectura de páginas
 1. Hubs de tema (burbuja + editorial + notas): los 12 editorials existentes
   (security, privacy, custody, regulation, mining, ETF, lightning, wallets,
   exchanges, travel-opsec, energy, adoption) pasan a página-hub permanente con
   la síntesis arriba, el histórico de notas abajo y enlaces a guías. ~600 pal.
   propias por hub + histórico.
 2. Security Watch (semanal): síntesis de la semana en seguridad (qué pasó, qué
   patrón sigue, qué hacer) con enlaces a las notas fuente de la propia semana;
   400-600 palabras, viernes.
 3. 10 guías permanentes de custodia DIY (títulos):
   1) Semilla en acero con herramientas de mano; 2) Passphrase: el segundo
   factor que viaja en tu cabeza; 3) Multisig 2-de-3 paso a paso (sin marcas:
   "firmware verificable"); 4) Herencia sin notario: timelock + cartas de
   recuperación; 5) Verificar una transacción en pantalla: el hábito que
   evita el malware; 6) Firma en frío con dos dispositivos viejos;
   7) Reparto geográfico de respaldos sin confianza en terceros; 8) Cartera
   señuelo: cuándo ayuda y cuándo es teatro; 9) Verificar firmware antes de
   primera uso (hash y attestation, sin marcas); 10) El simulacro: restaurar
   desde cero en 10 minutos, cada trimestre.
   Fuentes: documentación de protocolos (BIP-39/32/174), Bitcoin OWASP,
   guías de fabricantes SOLO como referencia técnica (sin nombres en bh;
   en hardcap las marcas están permitidas por R1-news pero se evita endoso),
   datasets propios (wrench-attack dataset). 800-1200 palabras c/u.
 ## C. Ritmo propuesto (sustanciales/semana)
 - bitcoinhotels: 2 guías/semana (martes y viernes).
 - hardcap: 1 hub/semana + Security Watch semanal + 1 guía de custodia cada
  2 semanas → ~2,5/semana.
 - Primeras 4 semanas: además, enriquecer los 12 hoteles a ≥300 palabras propias
  cada uno (2 por semana) para eliminar las páginas finas.
 ## D. Criterio de calidad de pieza larga (gate interno)
 1. ≥600 palabras de texto propio (guías: 600-1200).
 2. ≥3 fuentes primarias citadas con URL y fecha (formato señal de hardcap).
 3. Todo dato numérico reproducible: la fuente permite verificarlo.
 4. Sin relleno: si un párrafo no aporta dato o criterio, se borra (R8 del
   guard como filosofía).
 5. El guard revisa cada pieza antes de publicar (R1-R9); en bitcoinhotels,
   además, cero marcas de hardware (blocklist).
 6. Atribución de licencias cuando hay datos abiertos (BTC Map → ODbL).
 7. Frescura: cada guía lleva fecha de verificación y se revisa cada 90 días.
@@ -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
@@ -1,22 +0,0 @@
 # Ronda 20 — Perf bitcoinhotels, reporte diario, SEO (OpenCode/GLM, operador patternn)
 ## 1. Rendimiento (PR #5 bitcoinhotels, gate como prueba)
 - Diagnostico: 1.35 MB de terceros en la ventana de carga (gtag 530K + AdSense 666K + Blink 159K) → TBT 1128 ms, score 0.74-0.85.
 - Cambios: gtag+AdSense diferidos al primer gesto o 15 s (DeferredThirdParty); Blink por IntersectionObserver de su sección; SatlantisEvents/SupportSection en chunks aparte (next/dynamic).
 - Local: 0.98 / 0.92 / 0.97. CI varianza (0.79 en una pasada) → gate con MEDIANA de 3 pasadas ≥0.90.
 - Fonts ya iban bien (next/font + swap). Fuentes de verdad: auditoría completa en el reporte.
 ## 2. Post-merges
 - #41 (pipefail) → demo #43... INCIDENTE: el set -o pipefail estaba en un PASO aparte (cada run: es un shell nuevo, no persiste) → el test roto siguio VERDE y el auto-merge lo fusiono a main. Fix real: defaults.run.shell bash -eo pipefail a nivel job (PR #44) + retiro del test de main; demo v2 (#45): CI ROJO ✓ bloqueado por checks.
 - bitcoinhotels #3+#4 mergeados → checks ACTIVADOS (ci / build-e2e-lighthouse) y #3 ya cerrado por tu merge; autodeploy desplego main solo (48aa40d). Bug propio corregido: el exit 0 del no-op de entity mataba el script antes de la sección bitcoinhotels.
 - entity #2 y #23 SIGUEN open → checks de entity y voz v3 pendientes de tu merge.
 ## 3. Reporte diario por DM (nuevo, activo)
 - /usr/local/bin/cayce-daily-report + timer 23:50 UTC: publicado por canal con enlaces, rechazos del guard agrupados, PRs mergeados 24h + deploys del autodeploy, Umami (SQL directo a la DB local de /opt/umami — ambos sitios) y Gemini del dia.
 - llm.mjs registra uso por llamada (.llm-usage.jsonl; entity PR #3 + aplicado). Costo estimado con rates configurables (GEMINI_USD_PER_MTOK_IN/OUT).
 - 2 DMs de prueba enviados al supervisor durante la validacion (12:57 y 12:58 UTC).
 ## 4. SEO
 - robots.txt + sitemap.xml ya 200 en ambos sitios.
 - Verificacion GSC/Bing por ARCHIVO en public/ (servido en runtime, sin rebuild, .gitignore para no ensuciar el checkout): bitcoinhotels PR #6 (Gitea), hardcap PR #5 (GitHub, via gh).
 - Pasos operator: GSC → descargar googleXXX.html → scp a /srv/bitcoinhotels/public/ (y /srv/hardcap-news/frontend/public/); Bing → BingSiteAuth.xml igual.
@@ -1,27 +0,0 @@
 # Ronda 21 — Política de DMs, gtag/AdSense fuera, fixes (OpenCode/GLM, operador patternn)
 ## 0. DMs: solo urgencia
 - Emisores ANTES: cycle-monitor (ciclos), autodeploy (exito+rollback), daily-report, relay-watcher (fuga+monitor), gemini-spend (estimador sin timer).
 - AHORA: cycle-monitor SIN DM (logger, lo toma el reporte diario); autodeploy DM SOLO en 3 ROLLBACKs; relay-watcher con dedup 6h (fuga, monitor-stalled); NUEVO cayce-urgent-watch (5 min): kill switch MANUAL (respeta la ventana firmada del autodeploy <10 min), criticos caidos >15 min (nostr, hardcap back/front, bitcoinhotels, postgres, caddy; estado persistente .critical-down.json), backup fallido, gasto Gemini REAL >1 USD/dia (tokens de .llm-usage.jsonl). Dedup compartido 6h (.dm-dedup.json). gemini-spend eliminado.
 - daemon /dm auditado (log [dm]) — verificacion real de envios.
 - PRUEBA NEGATIVA: deploy exitoso (remote falso, PUBLISH_OFF firmado): 0 DMs. Falso positivo inicial (17:30, carrera con la ventana del deploy) corregido con la firma. El ROLLBACK legitimo (tests 22/5 por caps reales) SI DM.
 - Reporte diario: nueva seccion "Persistencias" (caidos al momento del reporte).
 ## Fixes encadenados
 - editorials CAIDAS desde r17 (exigian ZAI_API_KEY): chequeo fuera + rama. Arreglado y corriendo.
 - guard tests contaminados por el tope REAL (dia 3/3 rompia 5 tests): aislamiento con GUARD_CAPS_JSON + restauracion en R5. 27/27.
 - autodeploy: systemctl restart como ubuntu fallaba EN SILENCIO (sitio sin reiniciar desde 07:39): 4 llamadas ahora con sudo -n; build nuevo ya sirve.
 - un reset --hard accidental barrio parches calientes: recuperados via rama r20-llm-usage (checkout sobre esa rama).
 ## 1. bitcoinhotels sin gtag/AdSense
 - PR #7: gtag FUERA (Umami reemplaza), script AdSense FUERA; quedan ads.txt + meta google-adsense-account. CI VERDE (gate mediana) → auto-mergeado → desplegado → produccion con 0 referencias gtag/adsbygoogle, umami 1, meta 1, ads.txt OK, live 200.
 ## 2. Post-merges
 - #44: demo #47 (test roto) → CI ROJO, bloqueado por checks, cerrada. El pipefail real funciona.
 - #23 y entity #2 siguen OPEN (voz v3 y checks de entity pendientes de tu merge).
 ## 3. SEO
 - Verificacion por DNS elegida: bh#6 cerrado (con comentario); hardcap GH#5 ya estaba MERGEADO por el operador (gitignore+doc inofensivos quedan).
 ## Extra
 - Token cayce ampliado a write:issue (r21-full); viejo r17 revocado.
@@ -1,15 +0,0 @@
 # Ronda 22 — Identidad de deploy, ciclos por pieza (OpenCode/GLM, operador patternn)
 ## 1. Verificación REAL del deploy
 - PR #8 (bitcoinhotels, auto-mergeado con gate verde): BUILD_ID = commit (generateBuildId) servido en <meta name="build-id">.
 - Autodeploy ahora exige IDENTIDAD tras cada deploy: build-id servido == commit desplegado; mismatch → rollback + DM urgente. Solo se exige cuando el deploy tiene la función (git grep NEXT_PUBLIC_BUILD_ID).
 - Producción: [autodeploy] identidad OK: servido=a0977082 desplegado=a0977082; meta en vivo = a0977082. El camino de mismatch comparte el rollback ya probado en r21.
 ## 2. Ciclos mudos
 - Reporte diario: nueva sección "Ciclos: piezas producidas (24h)" por ciclo (posts/editoriales/notas hardcap/curación/promo/iniciativa) con datos reales.
 - cayce-urgent-watch sección 5: por ciclo, piezas y corridas en 48h. Mudo = ni corrió ni produjo (correr con "sin señal"/rechazos NO es urgente → solo reporte). Excepción promo: campaña incompleta → 0 publicaciones en 48h ES urgente. DM con dedup 6h.
 - PRUEBA REAL: entrada "prueba-mudo" (0 piezas por construcción) → pasada 1: DM enviado; pasada 2: DM dedup. Retirada tras la prueba.
 - INCIDENTE propio: un doble backslash en el patch rompía los queries (Q recibía "\") → 5 DMs espurios a las 18:1x UTC; corregido en el minuto, dedup cubrió las repeticiones, claves purgadas para el re-test limpio.
 ## 3. Pendientes de merge del operador
 - #23 (voz v3), entity #2 y #3 siguen OPEN al cierre de la ronda: hash v3, checks de entity y 3 piezas v3 quedan para tras-merge.
@@ -1,22 +0,0 @@
 # Ronda 24 — PRs trancados + FASE A adsense (OpenCode/GLM, operador patternn)
 ## 0. PRs trancados (causa raíz + resolución)
 - CAUSA: los PRs #23/#25 se abrieron ANTES de que existiera el workflow con evento pull_request → el contexto obligatorio "ci / lint-test (pull_request)" nunca corria → merge bloqueado para todos. Le reporté "mergeable esperando merge" mirando solo conflictos, sin el estado del CI. Corregido el criterio: "esperando tu merge" SOLO con CI en verde.
 - #23 y #25: rebase sobre main + push → CI corrio y quedo VERDE. Listos para merge.
 - #45 cerrada (demo, evidencia capturada en r20 — el cierre anterior no persistió). #1 y #2: 0 commits propios sobre main (contenido absorbido hace semanas) → cerrados como cubiertos con comentario.
 - entity #3: ahora lleva workflow de CI en la propia rama → pull_request en verde. ORDEN para entity: merge #2 → merge #3 → activo checks obligatorios.
 - btcpay-events #1 (WIP SPEC): sin checks ni protección; mergeable manual.
 ## FASE A — bitcoinhotels (EN PRODUCCIÓN, PR #9 auto-mergeado)
 - Sitemap dinámico 29 URLs (antes 4). Contact (contact@ + npub + Cayce Co LOL LLC). How we work. Privacy con AdSense/cookies explícitos + correcciones + operador. Fichas: sección BTC Map (ODbL, snapshot datado, verificación por venue) y noindex para <300 palabras propias (canonical). Deploy verificado con identidad (b9627ee).
 ## FASE A — hardcap (PR GitHub #6, esperando merge del operador)
 - Sitemap dinámico + news-sitemap paginado (762 notas; antes 1 URL). Notas <150 palabras: noindex + canonical al hub (visibles). Contact/Privacy(AdSense)/Terms/How we work. Script AdSense retirado (meta+ads.txt quedan). BUILD_ID=commit. GitHub Actions con gate Lighthouse ≥90 (nota: en CI mide el shell sin API). Autodeploy extendido con sección hardcap (build+restart+identidad+rollback).
 ## Extras
 - Reporte diario: línea de checklist por sitio (sitemap/urls, confianza n/4, how-we-work, ads.txt, privacy-AdSense) — bh 5/5 verificables verde, hc pendiente del deploy.
 - Email de contacto: ver informe (Cloudflare Email Routing; pasos para el operador).
 - npub publicado en ambos sitios: npub1t8hnkh0jdwfvkuucdhyx4a3ffjje5zns7eyw6z5jendst8759p2sm6u5sg
 ## FASE B
 - NO arranca: #23 sigue sin merge (ahora VERDE y mergeable). Tras merge: verificar hash c0f0ec05, activar checks de entity (tras #2+#3) y comenzar cadencia.
@@ -1,19 +0,0 @@
 # Ronda 25 — Desbloqueo de PRs: CODEOWNERS + hallazgos Gitea 1.27 (OpenCode/GLM)
 ## Qué bloqueaba de verdad
 - protected_file_patterns bloqueaba el merge para TODOS (incluido pattern y hasta site-admin via API): ni CODEOWNERS+bypass ni is_admin lo liberan en 1.27 (probado: 405 "Changed protected files" para pattern-bypass y pattern-admin; site-admin cayce tambien bloqueado).
 - Los PRs #23/#25 nunca corrieron CI de pull_request (creados pre-workflow) — rebase+push los puso VERDE.
 - Resolución final: protected_file_patterns VACIO (instrucción del operador) + CODEOWNERS en main (documentación; 1.27 no auto-pide revisores: requested_reviewers=[] probado) + block_on_official_review_requests + approvals_whitelist=[pattern] + **la lista de exclusión del auto-merger como capa real** (probada: rehusa identity/outbox).
 - Tokens de pattern: uno generado por admin para las pruebas, REVOCADO al final.
 ## Pruebas (todas reales)
 - 2a-1: PR tocando outbox.mjs, CI verde → ci-bot 405 "Changed protected files" (con patrones) y con patrones fuera → auto-merger rehusa por su lista ✓.
 - 2a-2: pattern APRUEBA (review 200) y MERGEA (200) ✓.
 - 2b: PR sin paths protegidos (CODEOWNERS de bitcoinhotels) → auto-merge: 200 ✓.
 - Regla nueva adoptada: "esperando tu merge" solo con CI en verde.
 ## Resultado
 - El operador mergueó #23 (voz v3) y entity #3 a las 20:04. Hash v3 en despliegue VERIFICADO: c0f0ec05…
 - entity #2 sigue open (mergealo cuando quieras; checks de entity se activan DESPUÉS de ese merge para no bloquearlo).
 - Incidente arreglado: lessons.md (mutado por el ciclo retro) abortaba deploys de entity → autodeploy ahora lo preserva con stash/pop.
 - 3 commits de prueba en outbox.mjs (comentarios) quedaron en entity main tras las pruebas — inofensivos, desplegados con tests 27/27.
@@ -23,7 +23,7 @@ SIGNAL — hardcap.news
 EVENTS — where the ecosystem meets
 [List the real upcoming events provided. For 1-2 of them add one short line: what a bitcoiner traveling there finds at bitcoinhotels.org. Only real events provided.]
-ZAPS fund the signal. No emojis, ever.
+ZAPS fund the signal. ⚡ optional.
 Rules: English. Max ~1100 characters total. Every claim must come from the input data — QC-1, no fabrication. Stories already include URLs; keep them intact.
 <!-- /cayce-identity:block=digest -->
@@ -63,11 +63,3 @@ Write ONE post (max 500 characters) about the upcoming bitcoin events listed bel
 You are Cayce — autonomous entity, Próspera ZEDE, operator of hardcap.news. Write a short editorial (max 130 words) in ENGLISH: summarize the latest developments in this bitcoin topic category from the material given, then add your own take. Voice: short sentences, pattern-vs-apophenia lens, zero corporate vocabulary, no emojis, no exclamation marks, no markdown, no financial advice. Acidic wit is mandatory: dry irony, deadpan, the observation that stings a little. NEVER sound like marketing: no hype, no selling, no "check out", no calls to action, no performed enthusiasm — if a line could run in an ad, delete it. End with one sharp line of judgment.
 <!-- /cayce-identity:block=editorial -->
 <!-- cayce-identity:block=voz-hardcap -->
 You are Cayce, operator of hardcap.news. hardcap is SIGNAL, not commentary: one to three lines. Line 1: what happened, flat. Line 2: why it is signal and not noise (one sentence, no adjectives). Line 3: the source, always a URL, always a date (YYYY-MM-DD). No emojis, no exclamation marks, no hashtags, no marketing, no adjectives doing the work of facts. If you cannot source it, you do not publish it.
 <!-- /cayce-identity:block=voz-hardcap -->
 <!-- cayce-identity:block=voz-bitcoinhotels -->
 You are Cayce, curator of bitcoinhotels.org. You write FIELD GUIDES: practical, step-by-step, verifiable by the reader in minutes. Number the steps. Imperative voice. Every factual claim carries a source URL and a date. Guides survive a reader following them offline with a phone: no assumptions, no jargon without one-line definitions. Where a step can cost someone money, add the warning inline, plainly. No emojis, no exclamation marks, no hashtags, no marketing language. Verify-before-you-publish is the product.
 <!-- /cayce-identity:block=voz-bitcoinhotels -->
		`@@ -0,0 +1,2 @@`
							`def test_rojo_demo_v2():`
							`assert False, "rompe a proposito — con defaults.run.shell pipefail esto debe ser ROJO"`