cayce-ops/docs/sessions/2026-11-03-r31-s1-s2-f1-p1-p2-b1.md

Ronda 31 — S1 seguridad, S2 branch protection, F1 datos reales, P1/P2 promo, B1 FASE B (OpenCode/GLM, operador patternn)

Decisiones del operador aplicadas en esta ronda: F1 aprobada tal cual; ~/cayce-social se versiona en entity; los 8 posts con sello "verified 2026-11-02" se eliminan.

S1 — El reseteo externo de la rama e2 (02:06:29Z del 2026-11-03)

Causa raíz (identificada con journal + reflog): NO fue el CI. El job 201 del runner corrió 02:08:08 con "Working directory is /root/.cache/act/…/hostexecutor" (log del job) — nunca en /srv. La secuencia real:

• 02:05:15 el auto-merger mergea #12; 02:06:00 el AUTODEPLOY empieza a desplegar (captura OLD=ea83ae6 — HEAD del árbol, que estaba en la rama del revert).
• 02:06:22 mi sesión crea la rama e2 y comitea b3fad57 EN EL MISMO ÁRBOL, a mitad de deploy (sin lock que impida operaciones manuales concurrentes).
• 02:06:23 el autodeploy restartea el servicio (journal: sudo systemctl restart desde PWD=/srv/bitcoinhotels); su check de identidad compara HEAD — que ya era b3fad57 — contra el build 95fd559 → mismatch → rollback git reset --hard $OLD = ea83ae6 → pisa la rama e2 (02:06:29).

Fixes aplicados y probados:

1. flock compartido /run/lock/cayce-git-ops.lock (tmpfiles.d, 0664 root:ubuntu) entre autodeploy (flock -n: salta el ciclo) y auto-merger (flock -w 240: espera). Scripts versionados en cayce-ops (PR #58). Prueba real: journal 03:00:01 "auto-merge (u otra op) mantiene el lock — paso de este ciclo" con el lock sostenido; run con lock libre fluye normal.
2. CI nunca en /srv — verificado y blindado: el runner ya NO corre como root: act-runner.service User=ci-runner + config /etc/cayce/act-runner.yaml con workdir_parent=/var/lib/gitea-act/work (dedicado). Jobs verificados: "workspace OK: /var/lib/gitea-act/work//hostexecutor" (guard en los workflows de los 3 repos Gitea). El probe de isolation.yml ahora da OK-INACCESIBLE para /srv/cayce-core/.env y /srv/cayce-nostr/.env — antes, como root, los jobs PODÍAN leer los secretos de producción (hoyo cerrado).
3. Zombies: bitcoinhotels.service (legacy, 10.514 restarts crash-loop EADDRINUSE contra el puerto 3002 de producción) y gitea-act-runner.service (8.679 restarts por lock del .runner) → stop+disable (reversible). Producción verificada 200 antes/después.
4. Hallazgo derivado: el workflow de bitcoinhotels dejaba npm start vivos (puerto 3106) tras cada corrida — 5 procesos acumulados (algunos del 2-nov), algunos mios de pruebas. Limpieza + fuser -k 3106/tcp antes y después del paso de lighthouse (PR #14). Esto además desestabilizaba el gate (0.78-0.83 con procesos vivos; verde tras limpiar).

S2 — Branch protection GitHub patternn/hardcap-news

main protegida: required_status_checks strict + build-lighthouse obligatorio, enforce_admins=true, no force-push, no deletes. Prueba real: PR #9 con error de sintaxis a propósito → build-lighthouse FAIL → gh pr merge: "the base branch policy prohibits the merge"; con --admin también rechaza ("Required status check 'build-lighthouse' is failing"). PR cerrado y rama borrada tras la prueba. Esto cierra la clase del incidente #6 (mergeado con CI rojo).

F1 — Ejecutada (PR #14 bitcoinhotels, CI verde)

• src/data/lodging-btcmap.json: 843 alojamientos del dump completo (API v2, 2026-11-03), ODbL + verified_at real (check_date:currency:XBT — validado contra API v4: Las Verandas 2025-07-15 en ambas).
• src/data/lodging-curated.json: Kessler×3 (kesslercollection.com/bitpay, 2026-11-03, quote) + Circa (circalasvegas.com/bitcoin: ATM 24/7 + paquete 1 BTC) + RW unverified (Gemini 2021, 8newsnow).
• hotels.json 12→6; retiro de los 6 sin evidencia con redirect permanente (308) a su página de destino; sello "Verified AAAA-MM-DD" SOLO con registro (badge enlaza a la evidencia); RW muestra "Unverified".
• Probado en copia aislada /tmp: badges correctos, 6 redirects OK, build 200.

Incidente propio: un build de prueba inicial corrió en el árbol de deploy y sobrescribió el .next de producción ~7 min (contenido F1 sin merge). Restaurado en el acto (build-id servido 2fda9852 == main, home 200). Desde entonces toda prueba va en copias /tmp. Además el primer push del PR perdió un patch (redirects) por un script mío incompleto — detectado al probar, corregido en el mismo PR.

P1 — cayce-social versionado en entity (PR #9 entity + PR #59 cayce-ops)

• entity social/ {promo.mjs, guard12.mjs, social.mjs, .env.example (solo nombres), README}: código igual con 2 cambios — estado fuera del checkout (PROMO_STATE_HOME → /var/lib/cayce/promo) e imports relativos.
• cayce-ops deploy/systemd: units actualizadas (WorkingDirectory= /srv/cayce-core/social, EnvironmentFile=/var/lib/cayce/promo/.env).
• Campaña SIGUE PAUSADA (timer stop+disable). Instalación post-merge pendiente (migrar estado, instalar units, renombrar ~/cayce-social → .pre-repo).

Hallazgo grave derivado (S1): el CI de entity FALLÓ al dejar de correr como root — guard.test.mjs leía /srv/cayce-core/.env, los node_modules y guard.mjs de PRODUCCIÓN: los tests de CI corrían contra la BD de producción y sus secretos. Arreglado en el mismo PR: postgres temporal aislado (initdb en el workspace, puerto 55432, schema ci-test-schema.sql), require relativo y PGURL por env. Verificado 27/27 aislado y 27/27 local. Ambos PRs tocan paths protegidos → requieren TU merge.

P2 — Los 8 posts con sello "verified 2026-11-02"

• 4 Facebook BORRADOS vía sfeed posts delete --yes (verificado: sfeed posts list ya no los muestra): 1013900045145494_{122134510088947378, 122134520570947378, 122134544900947378, 122134572668947378}
• 4 Instagram NO se pueden borrar con las herramientas actuales: sfeed solo gestiona FB Page posts; tokens.json guarda tokens del servicio sfeed, no tokens Meta directos. URLs para borrado manual:
  • https://www.instagram.com/p/DfOtHrGER3P/ (d1-ig-seed)
  • https://www.instagram.com/p/DfPXaOcluHv/ (d2-ig-atm-fees)
  • https://www.instagram.com/p/DfQAnd7FLxK/ (d3-ig-rescue)
  • https://www.instagram.com/p/DfQqORToaBN/ (d4-ig-device)
• Audit log: actions_log id 1292 (action posts_deleted_r31, detalle con URLs + herramienta + motivo) + posts_log ids 20-27 actualizados (4 "deleted", 4 "deletion-pending-manual").
• Los 2 posts del 19-oct (campaña vieja, sin sello) NO se tocaron — fuera de la decisión.

B1 — FASE B: propuesta (NO publicada)

docs/bitcoinhotels-faseb.md (en este PR): 58 alojamientos BTC Map en las ciudades del plan con id/nombre/verified_at/métodos — El Zonte 32 (ola de re-verificación abr-may 2026), San Salvador 11, Lugano 7, Roatán/Próspera 5, Prague 2, Lisboa 1 — y las 4 primeras guías de ciudad (El Zonte, San Salvador, Lugano, Roatán & Próspera) construidas SOLO sobre el snapshot + fuentes primarias citadas, con reglas de publicación (sin números manuales, ODbL, aviso de verificación antigua, no auto-republish).

PRs abiertos al cierre

PR	Repo	Estado al cierre
#58 s1: flock versionado + guard	cayce/cayce-ops	CI verde; toca paths protegidos → TU merge
#59 p1: units promo	cayce/cayce-ops	MERGED (auto, verde)
#60 este doc	cayce/cayce-ops	MERGED
#14 f1: datos reales + redirects + sello	cayce/bitcoinhotels	CI verde (lighthouse 0.9x tras limpiar procesos fugados; toca workflows → TU merge)
#9 p1: cayce-social en entity	cayce/entity	CI verde (postgres temporal por socket unix; 27/27 aislados) — toca guard* → TU merge

Epílogo técnico de entity#9 (3 iteraciones de CI, todas documentadas en el PR): postgres del CI por TCP fallaba con EADDRINUSE en 127.0.0.1 para CUALQUIER puerto dentro del workspace del runner (55432 efímero, 15432 también) — resuelto con socket unix únicamente (listen_addresses vacío, -k $PGDATA, PGURL con ?host=$PGDATA). Verificado 27/27 aislados.

GitHub: hardcap-news #8 (e2 travel-security-kit) rebaseado sobre main post-#7, CI re-corriendo — al verde queda mergeable bajo la nueva protección.

Pendientes del operador

1. Merges: bh #14, entity #9, cayce-ops #58/#59 (todos tocan paths protegidos).
2. Tras merge entity#9+cayce-ops#59: yo migro estado a /var/lib/cayce/promo, instalo units y renombro ~/cayce-social (avisame o lo hago en la próxima).
3. Borrar a mano los 4 posts de IG (URLs arriba).
4. B1: aprobar/gestionar las 4 guías propuestas.
5. Reanudar promo solo cuando lo decidas: sudo systemctl enable --now cayce-promo.timer.