r24 doc: causa raiz de PRs trancados + FASE A bh en produccion + hc PR#6

docs/adsense/checklist-postulacion.md

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

docs/adsense/como-trabajamos-borrador.md

@@ -0,0 +1,72 @@
+# "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.

docs/adsense/plan-contenido.md

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

docs/sessions/2026-11-02-r24-trancados-fase-a.md

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