cayce-ops/docs/sessions/2026-11-03-r33-loop-dms-btcpay-inbox-aprobaciones.md

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.