adsense r23: plan de contenido (20 bh + hubs/watch/guias hc) + borrador como-trabajamos + checklist de postulacion

Reviewed-on: #44

.gitea/workflows/ci.yml

@@ -8,6 +8,12 @@ on:
 jobs:
   lint-test:
     runs-on: ubuntu-latest
+    # r20: pipefail a nivel job — un - run: set -o pipefail en paso aparte NO
+    # persiste (cada paso es un shell nuevo) y el test roto de la demo #43
+    # siguio dando verde hasta ser auto-mergeado a main.
+    defaults:
+      run:
+        shell: bash --noprofile --norc -eo pipefail {0}
     steps:
       - uses: actions/checkout@v4
         with:

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-r18-autodeploy-voz-promo.md

@@ -0,0 +1,34 @@
+# Ronda 18 — Autodeploy, promo v3, bitcoinhotels (OpenCode/GLM, operador patternn)
+
+## 1. Autodeploy (nuevo)
+- /usr/local/bin/cayce-autodeploy + timer cada 3 min (User=ubuntu).
+- cayce-ops: pull ff-only de main cuando main adelanta al tree (working tree en main @ 6dec319).
+- entity → /srv/cayce-core: PUBLISH_OFF durante el swap; solo se retira tras tests >=27/27 y watcher sin VIOLACION; rollback automatico (en fallo de watcher PUBLISH_OFF queda ACTIVO). Restart de cayce-nostr; los ciclos timer levantan codigo nuevo solos.
+- PROBADO end-to-end con remote local falso (bare con main adelantado): "[autodeploy] main nuevo detectado … PUBLISH_OFF activo" → "entity → 706bb49 (tests 27/27, watcher OK, live)".
+
+## 3. PRs
+- cayce-ops PR #34 (r16-r9-gemini → main): elimina runtime/ + docs r16/r17.
+- bitcoinhotels PR #3 (guides-sin-bitbox): ultima marca fuera (BitBox02 la dejo el PR #1).
+
+## 4. Promo (voz v3, sin hashtags)
+- 12 captions reescritos en voz v3 (hardcap=señal con fuente+fecha; bitcoinhotels=guía numerada verificable). Guard: 12/12 APROBADOS.
+- Bugs: unit sin EnvironmentFile (corria en draft y sin IG_USER_ID) — añadido; sfeed escribe el URL en stderr (spawnSync combinando salidas) — fix.
+- PUBLICADO REAL: d1-fb-lightning → facebook.com/1013900045145494_122134510088947378 (sfeed operativo). Cadencia 1/ciclo según horas 13/19 UTC. IG activo (IG_USER_ID set).
+- Estado de campaña reseteado; backups en forensics/promo-pre-r18.
+
+## 5. Scout
+- Unit archivada en forensics/scout-20261102 y eliminada (daemon-reload). Sigue deshabilitado.
+
+## 6. Token id 10
+- ES de ci-bot (uid 3): lo genera el propio /usr/local/bin/cayce-auto-merge por CLI en cada run (sin token embebido). Per operator: no requiere reemplazo. Scopes write:repository,write:issue (los minimos para mergear+comentar).
+
+## 7. kind 5 (99cc75f4)
+- Recheck agendado 06:44 UTC → /var/log/r17-recheck-99cc.log. Resultado: (ver abajo).
+
+## 8. bitcoinhotels
+- PR #1 MERGED. El deploy (/srv/bitcoinhotels, sirvió via tunnel CF → localhost:3002) NO estaba actualizado: sin umami, con marcas, sin flag. Bloqueo: deploy no es checkout git y el repo no trackea ficheros raiz.
+- Actualizado a mano: layout (umami+Organization JSON-LD), guides page (flag affiliates), guides.json (sin marcas) + rebuild + restart. Live: umami ✓, 0 marcas, box afiliados oculto (flag off), 200.
+- PR #3 queda para el ultimo resto (BitBox02).
+
+## 2. Voz v3
+- PR #23 sigue open — NO VERIFICADO. Al mergear, el autodeploy actualiza ~/cayce-ops (identity ff2cd822 → v3 c0f0ec05) y los ciclos publican con v3.

docs/sessions/2026-11-02-r19-automerge-bh-sistema.md

@@ -0,0 +1,36 @@
+# Ronda 19 — Auto-merge, bitcoinhotels en el sistema, sfeed (OpenCode/GLM, operador patternn)
+
+## 1. Auto-merge
+- required_status_checks ACTIVO en cayce-ops main (contexto "ci / lint-test (pull_request)"). entity y bitcoinhotels: pendiente de que sus workflows lleguen a main (PRs #2 y #4) — activar checks antes dejaría los PRs bloqueados sin CI que correr.
+- Bug del CI hallado por la demo: | tail sin pipefail hacia que un test roto diera VERDE (PR #41 lo corrige — toca workflows, merge del operador).
+- Bug historico del auto-merge hallado y corregido: regenerar token "auto-merge" con nombre usado da ERROR → BOT vacio → el script llevaba rondas sin hacer nada. Ahora el token persiste en /etc/cayce/ci-bot.token (600). INCIDENTE: un token de ci-bot se imprimio en mi salida por un heredoc sin citar → fue revocado al instante y reemplazado.
+- Otro fix: usar /status (combinado) en vez de /statuses (los pending historicos bloqueaban PRs verdes).
+- ci-bot tenia MustChangePassword → su API daba 403: unset.
+- DEMA COMPLETA: #35 trivial verde → AUTO-MERGEADO (merge: 200); #40 rojo → merge rechazado "405 Not all required status checks successful"; #39 verde+SPEC.md → "TOCA PATH PROTEGIDO — no se auto-mergea". #38 (doc r18 recuperada) tambien auto-mergeado.
+- Timer cayce-auto-merge (cada 5 min) ACTIVO. Ciclo completo verificado: merge → autodeploy tiro "[autodeploy] cayce-ops → de73dd2" solo.
+
+## 2. bitcoinhotels en el sistema
+- PR #4 (bh-repo-completo): TODO para construir (package+lock sincronizado, configs, public/) + CI: npm ci + build + Playwright (375/768/1280, smoke home+guia sin marcas) + Lighthouse movil >=0.90.
+- Infra del runner arreglada: playwright install --with-deps necesita sudo → deps de sistema instaladas como root (persistentes), browser en cache del runner; dos versiones de @playwright/test → binarios locales del repo; lighthouse requiere CHROME_PATH + --no-sandbox; firewall del runner (uid 1002) bloqueaba loopback → regla OUTPUT -o lo ACCEPT (persistida en /etc/cayce/iptables.v4, antes inexistente pese a la unit enabled).
+- RESULTADO REAL: Playwright VERDE; Lighthouse performance(movil) = 0.85 → el umbral >=0.90 fallara hasta optimizar el sitio (detalles en /tmp/lh.json del runner). El workflow ya mide bien.
+- /srv/bitcoinhotels = checkout de bh-repo-completo (unit cayce-bitcoinhotels.service, PORT=3002); rollback pre-r19 en forensics (r19-bitcoinhotels-pre-*.tar.gz). Autodeploy extendido: pull main → build → restart → verifica 200+umami+0 marcas → rollback si falla. check-clean-trees lo cubre.
+- BitBox02 (PR #3) incluido en la rama; nada en caliente a partir de ahora.
+
+## 3. sfeed (solo lectura)
+- billing status: "○ No subscription" (el scheduling hospedado la requiere; el posting directo NO). Sin cobro.
+- Destinos activos: facebook "Bitcoin Travelers" (1013900045145494) e instagram @nodalntt (17841476274179708), con credencial activa.
+- Actividad desde 2026-10-19 04:50 (owner 8396006670…); config.json (telemetry/anonymousId) modificado 2026-10-31 18:50; tokens.json se refresca solo al postear.
+- Al rotar el api_token en el panel: actualizar /home/ubuntu/.sfeed/tokens.json (clave .api_token) — fichero 600.
+
+## 4. Voz v3
+- PR #23 sigue open → NO VERIFICADO. Despliegue sigue en ff2cd822 (v2). Al mergear, el autodeploy actualiza ~/cayce-ops y los ciclos publican con v3.
+
+## 5. posts_log
+- Completado a mano el post_url del FB (id 20). Los siguientes ya lo guardan solos: instagram|seed-strategy|ok|https://www.instagram.com/p/DfOtHrGER3P/ (spawnSync stderr fix verificado en produccion).
+
+## 6. Primer post IG
+- PUBLICADO: d1-ig-seed → https://www.instagram.com/p/DfOtHrGER3P/ (voz v3, sin hashtags).
+
+## Extras
+- Merge del operador (#34) detectado; mi doc r18 estaba perdido en el main local (push no-op de r18) → recuperado como PR #38 y auto-mergeado. Regen: nunca commitear en el main local de cayce-ops (es checkout de deploy).
+- Recheck kind5 06:44→07:13 ejecutado: target 99cc75f4 visible en 0/5 relays (borrado consolidado), kind5 1/5.

docs/sessions/2026-11-02-r20-perf-reporte-seo.md

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

docs/sessions/2026-11-02-r21-dm-urgencia-limpieza.md

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

docs/sessions/2026-11-02-r22-identidad-ciclos.md

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

docs/sessions/README-demo.md

@@ -0,0 +1 @@
+demo trivial r19 — 2026-11-02T06:42:28Z