2026-11-03 16:40:01 +00:00
3 changed files with 242 additions and 0 deletions
@@ -0,0 +1,82 @@
 # PROPUESTA (r32, NO ejecutada) — campaña promo v4: solo afirmaciones con fuente primaria
 Estado: propuesta. La campaña sigue pausada (timer disabled); no se reanuda sin
 aprobación del operador. Reglas de construcción, aplicadas a cada caption antes
 de abrir este doc: cada afirmación con cifra, fecha o superlativo lleva SU
 fuente primaria citada en el texto (URL + fecha); sin sellos "verified" salvo
 registro real (snapshot datado o página oficial revisada en fecha); sin
 hashtags, sin exclamaciones, sin cifras sin fuente (guard R1-R9 en verde).
 ## Formato
 8 posts / 8 días (1 por día, 17:00 UTC), 4 por marca (bh/hc), imagen de marca
 generada como en v3. Cada caption termina con su enlace y la fuente de la
 afirmación principal. El guard corre por post (canal social) y el registro de
 posts_log documenta tema + enlace + estado.
 ## Posts propuestos
 1. **bh · El Zonte lodging** — "32 places to sleep on the El Zonte corridor,
   every one recorded with Lightning and on-chain acceptance, 26 of them
   re-verified between April and June 2026. The full list with each venue's
   last check date: bitcoinhotels.org/guides/el-zonte-where-to-sleep
   (source: btcmap.org, snapshot 2026-11-03)."
 2. **bh · Lugano** — "Lugano's Plan B counts roughly 400 merchants taking BTC,
   USD₮ and LVGA, and BTC Map carries 7 verified lodgings — the honest numbers
   for a bitcoin city. Guide: bitcoinhotels.org/guides/lugano-plan-b-stay
   (sources: planb.lugano.ch and btcmap.org snapshot 2026-11-03, both checked
   2026-11-03)."
 3. **bh · Roatán/Próspera** — "A special economic zone on Roatán adopted
   bitcoin as legal tender inside its jurisdiction in April 2022, and the
   island's verified lodging list now runs 5 entries — one of them with no
   recorded verification, and we say which. Guide:
   bitcoinhotels.org/guides/roatan-prospera-stay (sources: Reuters 2022-04-07;
   btcmap.org snapshot 2026-11-03)."
 4. **bh · San Salvador** — "11 lodgings recorded on BTC Map for San Salvador:
   6 verified in the last 15 months, 5 carrying survey dates from 2023-2024
   that we flag as old instead of hiding. Guide:
   bitcoinhotels.org/guides/san-salvador-base-camp (source: btcmap.org,
   snapshot 2026-11-03)."
 5. **hc · Physical security** — "Airlines mishandled 4.9 bags per 1,000
   passengers in 2025 — delays and damage included, not just loss. The travel
   kit's seed-custody patterns exist for exactly that tail risk:
   hardcap.news/learn/travel-security-kit (source: SITA Baggage IT Insights
   2026)."
 6. **hc · Rescue rail** — "Gift cards for bitcoin, instant delivery, service
   claim: over 186 countries. The liquidity layer of the travel kit:
   hardcap.news/learn/travel-security-kit (source: bitrefill.com, checked
   2026-11-03)."
 7. **bh · ATM reality** — "Bitcoin ATM median total fee runs about 16%, with a
   typical 10-15% band over spot. The city guide now links operator fee pages
   instead of publishing stale tables: bitcoinhotels.org/guides/
   best-bitcoin-atms-by-city (sources: coinatmradar.com fee statistics;
   spark.money fee comparison, checked 2026-11-03)."
 8. **bh · El Salvador law** — "Since January 2025 merchant acceptance of
   bitcoin in El Salvador is voluntary, and the capital-gains exemption
   stayed. What that means for a sats-first trip, without invented budgets:
   bitcoinhotels.org/guides/living-on-sats-in-el-salvador (sources: Reuters
   2025-01-30; Forbes 2025-02-28)."
 ## Tabla afirmación → fuente (auditoría completa)
 | # | Afirmación | Fuente primaria | Fecha |
 |---|---|---|---|
 | 1 | 32 lodgings, todos Lightning+on-chain; 26 re-verificados abr-jun 2026 | btcmap.org snapshot (API v2 dump) | 2026-11-03 |
 | 2 | ~400 merchants BTC/USD₮/LVGA + 7 lodgings | planb.lugano.ch · btcmap.org snapshot | 2026-11-03 |
 | 3 | Próspera adoptó BTC como legal tender en su jurisdicción (abr-2022); 5 lodgings, 1 sin verificar | Reuters 2022-04-07 · btcmap.org snapshot | 2026-11-03 |
 | 4 | 11 lodgings SSV; 6 frescos 15 meses; 5 con fechas 2023-2024 | btcmap.org snapshot | 2026-11-03 |
 | 5 | 4.9 bolsos maltratados / 1.000 pax (2025) | SITA Baggage IT Insights 2026 | 2026 |
 | 6 | Gift cards BTC "over 186 countries" | bitrefill.com | 2026-11-03 |
 | 7 | Mediana ~16%, rango típico 10-15% | coinatmradar.com · spark.money · cash2bitcoin.com | 2026-11-03 |
 | 8 | Aceptación voluntaria desde ene-2025; exención CG se mantuvo | Reuters 2025-01-30 · Forbes 2025-02-28 | 2026-11-03 |
 Sin presupuestos en sats, sin topes KYC por ciudad, sin "dataset" de wrench
 attacks, sin "verified 2026-XX-XX" — salvo los snapshot/evidencias con fecha
 real listados arriba.
 ## Si apruebas
 1. `sudo systemctl enable --now cayce-promo.timer` con la campaña v4 ya en
   `social/promo.mjs` (PR propio, sin tocar paths protegidos).
 2. Los 4 IG pendientes de borrado manual (r31) deberían borrarse antes de
   reactivar IG.
@@ -0,0 +1,45 @@
 # Ronda 32 — Post-merge P1, FASE B publicada, reporte diario v2, campaña v4 propuesta (OpenCode/GLM, operador patternn)
 Regla nueva aplicada: **R7/D4** (nada de compilar/instalar/probar en /srv/*; copias en /tmp o workspace del runner) — en DECISIONS.md vía PR #62.
 ## 1. Post-merge P1 — HECHO
 - Estado migrado a `/var/lib/cayce/promo/` (.env 600 ubuntu, promo-state.json, campaign-start.json, media/) · units instaladas desde el checkout (`deploy/systemd/cayce-promo.{service,timer}`) + daemon-reload · **timer sigue disabled** (campaña pausada, verificado inactive).
 - `~/cayce-social` archivado: `/var/backups/cayce/forensics/cayce-social-pre-repo-20261103.tar.gz` (194 archivos) y el dir renombrado a `~/cayce-social.archived-pre-repo` (nada borrado).
 - **Autodeploy de entity incluye social/**: deploy del merge #9 a las 15:03:18 → `entity → 10b1aaf (tests 27/27, watcher OK, live)`; `ls /srv/cayce-core/social/` → promo.mjs, guard12.mjs, social.mjs, README.md.
 - Código desplegado verificado EN /tmp (R7): `node --check` ×3 OK y guard12 **12/12 aprobados**.
 ## 2. FASE B — 4 guías publicadas (PRs auto-mergeados)
 Cada PR: solo `src/data/guides.json` (sin paths protegidos), guard previo contra postgres temporal aislado en /tmp, auditoría factual en el cuerpo del PR, ≥600 palabras propias, ODbL + merchant id + snapshot datado, avisos de verificación antigua.
 | PR | Guía | Guard | Palabras | Estado |
 |---|---|---|---|---|
 | #16 (1º intento #15 cerrado por type error `heading` vs `title`) | el-zonte-where-to-sleep | APROBADO | 823 | MERGED, deploy 1ed847d, **200 en vivo** |
 | #17 | san-salvador-base-camp | APROBADO | 670 | MERGED, **200 en vivo** |
 | #18 | lugano-plan-b-stay | APROBADO | 643 | MERGED (deploy en el pase siguiente) |
 | #19 | roatan-prospera-stay | APROBADO | 647 | abierto al cierre de este doc (CI/automerge en curso) |
 Fuentes usadas (todas citadas en el texto): btcmap.org snapshot 2026-11-03 (lodging), Reuters 2025-01-30 y Forbes 2025-02-28 (reforma ES), planb.lugano.ch (Lugano), Reuters 2022-04-07 (Próspera), bitcoinbeach.com + wearebitcoin.org (El Zonte 2019). Corrección de honestidad durante la ronda: el sitio de Las Verandas NO documenta pago bitcoin (verificado) — la guía cita solo el survey de BTC Map.
 ## 3. Reporte diario — HECHO (PR #63 MERGED + instalado)
 Tres secciones nuevas en `cayce-daily-report`: **3b PRs que esperan tu merge** (Gitea, con motivo calculado contra la lista de paths protegidos; GitHub hardcap referenciado — el VPS no tiene token GitHub), **Contenido nuevo publicado hoy por sitio** con enlaces vivos (guías bh desde el git del árbol desplegado; notas hc por article_id), y **línea semanal AdSense los lunes** (checklist 5 puntos por sitio). Prueba en seco OK.
 ## 4. Campaña promo v4 — PROPUESTA (docs/promo-campana-r32.md, este PR)
 8 posts / 8 días, cada afirmación con fuente primaria citada (tabla completa afirmación→fuente en el doc). Sin sellos "verified" salvo snapshot/evidencias reales. NO se reanuda nada: requiere tu aprobación + idealmente borrar antes los 4 IG pendientes.
 ## Incidencias de la ronda (encontradas y arregladas)
 1. **hardcap-news llevaba sin desplegar desde el 1-nov**: el VPS no podía hacer `git fetch` de GitHub. Fix: deploy key **read-only** (`deploy-readonly-vm2047`, key id 168607734) + remote SSH. Fetch OK → main c453b2d visible.
 2. **hardcap entró en rollback eterno**: el check de identidad grep-ea `meta name="build-id"` que main NUNCA tuvo (NEXT_PUBLIC_BUILD_ID existe desde #6 pero no se renderizaba) → todo deploy rueda atrás. Fix: **GitHub PR #10** (meta en layout, patrón bh; CI verde tras re-run de un flaky de Google Fonts) — **espera tu merge**.
 3. **El rollback de hardcap abortaba el autodeploy completo**: `exit 1` antes de la sección bitcoinhotels → bh #16/#17 mergeados sin desplegar (15:32-15:43). Fix: sección hardcap en **subshell** (PR #64 + instalado). Evidencia de que funciona: 15:52:07 rollback hardcap y 15:52:32 `bitcoinhotels → 1ed847d (200 + umami + 0 marcas)`.
 4. PR #15 cerrado por mi error de tipo (heading vs title en sections) — reabierto como #16 con fix.
 ## Pendientes del operador
 1. **Merge de GitHub #10** (meta build-id) — desbloquea el deploy de hardcap (main lleva desde el 1-nov sin llegar a producción).
 2. Aprobar/rechazar campaña v4 (docs/promo-campana-r32.md).
 3. Borrar los 4 IG pendientes (URLs en doc r31) antes de reactivar promo.
 4. PR #62 (D4/R7 en DECISIONS) y #64 (subshell) esperan tu merge si quieres revisarlos; el resto se auto-mergea.
@@ -0,0 +1,115 @@
 # Ronda 33 — Loop hardcap, política de DMs, directiva BTCPay, inbox 10050, aprobaciones por reacción (OpenCode/GLM, operador patternn)
 > Deuda corregida: el doc de la r32 quedó sin PR al cerrar esa ronda — se
 > incluye aquí como archivo aparte (2026-11-03-r32-postmerge-faseb-reportes.md).
 ## 1. Loop de rollback en hardcap — RESUELTO
 - **Estado al abrir**: producción hardcap en `a5c2f59` (build del 1-nov),
  sirviendo 200; **34 rollbacks** entre 15:10:06 y 16:09:58 UTC (uno por ciclo
  de 3 min), todos `build-id '' != 'c453b2df'`.
 - **Causa raíz** (dos capas): (a) el fetch de GitHub del VPS llevaba roto
  desde el 1-nov (arreglado en r32 con deploy key read-only); (b) al revivir
  el fetch, el check de identidad grep-ea `meta name="build-id"` que main
  **nunca renderizó** (gh#10 lo añade; sigue abierto) → rollback eterno.
 - **Arreglos** (PR cayce-ops #65 + instalados):
  1. identidad de hardcap exigida **solo si ESTE main renderiza la meta**
     (`git grep name=.build-id. layout.tsx`) — con gh#10 mergeado y desplegado
     el check se reactiva solo;
  2. `dm_once`/`dm_clear`: **un DM por incidente** (subject `repo:causa`),
     limpiado por deploy exitoso; journal completo vía `say` (silencio en DM,
     no en audit).
 - **Resultado verificado**: deploy manual exit=0 → `hardcap-news → c453b2d
  (200)` — main del 3-nov EN producción (hubs /topics/* 200, texto del
  travel-security-kit corregido) — y `bitcoinhotels → 5dbff23` (4ª guía viva).
 - Sitio caído = urgencia real: cubierto por urgent-watch (caída >15 min),
  no por el rollback (que mantiene el sitio arriba en el build anterior).
 ## 2. Política de DMs — REEMPLAZADA (PR #66 + instalada)
 - urgent-watch v2: DM inmediato SOLO (1) kill switch manual o fuga (violaciones
  del watcher), (2) servicio/sitio caído >15 min, (3) backup fallido **2 días
  seguidos**, (4) gasto Gemini > umbral. Fuera: mudos, CODEOWNERS, initiative,
  rollbacks recuperados, publicaciones, rechazos → SOLO resumen diario 23:50
  (verificado OnCalendar=23:50). Ciclos pausados a propósito (promo) sin
  alertas.
 - Dedup por **tipo:sujeto** (24 h). **Tope 3 urgentes/día**: al 4º,
  diferido a `.dm-deferred.log` → una línea en el resumen (sección 2b nueva).
 - **Conteo 24 h (evidencia del antes)**: **83 DMs** — 18 rollback hardcap, 26
  codeowners, 6 mudos, 6 aborts dirty, 10 copias del reporte diario (bug de
  reenvío anotado), resto varios.
 - **Simulación DRYRUN de cada tipo** (estados falsos en /tmp, sin enviar):
  killswitch:manual ✓ · fuga:watcher ✓ · down:fake-down.service (20 min) ✓ ·
  backup:2días ✓ · gasto:gemini ($9>$1) ✓ · tope→deferred ✓ (evidencia en
  `.dm-deferred.log` del simulacro).
 ## 3. Directiva BTCPay — DESACTIVADA
 - `CAYCE_DIRECTIVE_BTCPAY=0` en /srv/cayce-core/.env (generación de nuevas
  oportunidades BTCPay cortada de raíz).
 - Archivados: drafts **#50, #51, #52** (los tres BTCPay generados HOY por la
  directiva: 02:00, 08:00 y 16:00) + verificación de que **#33** y la
  oportunidad **#106** ya estaban archived. Audit: actions_log id 1306.
 - **Qué publicó initiative hoy**: 3 ciclos (02:00/08:00/16:00) pero **UNA
  sola nota nostr publicada** — id 381, 08:00:15 UTC, event
  `7389a478df83e39f0648b6c42295b4205c454ea9277827245923af9578f92417`, texto:
  "Event ticketing infrastructure that forces custodial payment processors or
  third-party tracking degrades bitcoiner operational security. Open-source
  merchant rails like BTCPay Server paired with local, peer-to-peer
  directories eliminate trusted third parties at the physical layer."
  **Guard: APROBADO** (canal nostr, tipo initiative_note, postgres temporal
  aislado) → se queda; no hubo que borrar nada con kind 5.
 - Pendiente reportado: 20 oportunidades BTCPay en estado `identified`
  quedan en el pipeline (sin nueva generación); si las quieres archivadas,
  dilo y lo hago. El producto vive solo en cayce/btcpay-events (repo intacto).
 ## 4. Inbox de Cayce (kind 10050) — PUBLICADO
 - Diagnóstico: el daemon **lee** gift wraps NIP-17 (kind 1059 → seal 13 →
  chat 14 del supervisor, con manejo de comandos) pero **nunca publicó el kind
  10050** — de ahí "DM inbox relays not found" en tu cliente.
 - `publish-10050.mjs` (en /srv/cayce-nostr, herramienta operativa): consultó
  los 5 relays → **0 existentes** → publicó event
  `7694c0f61b747c45a76555d84a8c2281fa32db25039f5509afa8e4a4ddf05dee`
  (pubkey 59ef3b5d…, relays damnos/nos.lol/primal/snort/wellorder)
  **verificado en 5/5**. Idempotente (no república si hay uno <30 días).
 - **Prueba pendiente tuya**: mándame un DM NIP-17 — en el journal del daemon
  aparecerá `[DM supervisor NIP-17] …` (24 h últimas: 0, nunca llegó ninguno
  porque el cliente no encontraba el inbox). Nota: /srv/cayce-nostr no es repo
  git — drift pendiente de versionar (igual que el daemon).
 ## 5. Aprobación por reacción — IMPLEMENTADA (entity PR #10, WIP, LO MERGEAS TÚ)
 Diseño completo en `docs-approvals.md` (dentro del PR). Resumen:
 - Pregunta por DM NIP-17 con **ID único, acción, efecto y vencimiento 48 h**.
 - Aprobación = reacción 👍 o **+** a ESE mensaje, **seal NIP-17 firmado por
  SUPERVISOR_NPUB_HEX** (fallback: kind 7 pública con #e). 👎/otra/nada = no
  se hace nada.
 - Ejecución **idempotente** (FOR UPDATE + executed_at): `merge_pr` (ci-bot,
  para PRs de paths protegidos), `resume_promo`/`pause_promo`, registro
  `approved:` para campañas/zona roja. Audit en actions_log con el event id
  de la reacción; confirmación SOLO en el resumen diario.
 - **Tests 6/6 en CI** (postgres temporal): otra pubkey ignorada · otro
  mensaje ignorado · 👎 ignorada · vencida no ejecuta · válida ejecuta UNA
  vez · sweep de vencidas.
 - **Prueba real preparada**: tras tu merge, abro un PR de prueba tocando un
  path protegido, te llega la pregunta, reaccionas 👍 y verificamos el merge
  por ci-bot.
 ## Incidencias propias de la ronda
 1. Al instalar el autodeploy parcheado, un pase lo estaba ejecutando (bash
   lee incrementalmente) → errores transitorios por 1 ciclo (16:13:36,
   documentados en journal); el pase siguiente y el manual salieron limpios.
   Lección aplicada: instalar scripts solo tras `flock` o entre ciclos.
 2. El primer commit del PR entity arrastró el .pgtmp de pruebas → limpieza
   en el mismo PR antes de que lo tocaras.
 ## Pendientes del operador
 1. **Merge gh#10** (meta build-id de hardcap; CI verde) — reactiva el check
   de identidad de hardcap al desplegarse.
 2. **Merge entity PR #10** (aprobaciones, WIP a propósito) → instalo la unit
   y corremos la prueba real de reacción.
 3. Mándame un DM NIP-17 para cerrar la prueba del inbox.
 4. PRs cayce-ops #65/#66 (auto-mergeables) y el doc de esta ronda.