# 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/<id>/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 |
|---|---|---|
| #58 s1: flock versionado + guard | cayce/cayce-ops | CI verde; toca paths protegidos → TU merge |
| #59 p1: units promo | cayce/cayce-ops | CI corriendo |
| #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 re-corriendo con postgres temporal (27/27 verificado local) — toca guard* → TU merge |

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`.