feat(episode): TRAZA_presencia-cerrada-1-true-todo-lo-local-e_S20260727.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: AEGIS | Type: reflection
Summary: EPISODIO 1 — MEMORIA: Presencia cerrada `(1, True)`. Todo lo local está...

episodes/TRAZA_presencia-cerrada-1-true-todo-lo-local-e_S20260727.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -0,0 +1,62 @@
+---
+episode_id: "e0a1ce80-f0cf-4130-af42-c7b15a1975f9"
+puente_flat: "TRAZA_presencia-cerrada-1-true-todo-lo-local-e_S20260727.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
+session_code: "S20260727.ARCO_CICLO4_AUTOMEJORA"
+acto_dialogico: "informar"
+actor_flujo: "multi_actor"
+criticidad_aegis: "low"
+skill_dominante: "AEGIS"
+fase_proyecto: "operations"
+tipo_semantico: "reflection"
+summary_one_line: "EPISODIO 1 — MEMORIA: Presencia cerrada `(1, True)`. Todo lo local está..."
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-07-27T06:49:16.197474+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+Presencia cerrada `(1, True)`. Todo lo local está saldado; los 3 agentes Opus siguen excavando el servidor en segundo plano. Estado intermedio:
+
+| Pendiente | Estado |
+|---|---|
+| 2 bugs `verify-first` | ✅ **REPARADOS** — 3 tests fail-first, suite 17/17, commit `77099068`, triple-remoto |
+| Doc del bug (zombie DLC-2) | ✅ AVISO decía-vs-realidad + memoria persistente actualizada |
+| Cola LOOP_WRITE | ✅ Conciliada — el crisol ya había ingerido el contenido (verificado byte a byte), cola archivada |
+| Presencia R-CAT-2 | ✅ Declarada al empezar, cerrada al terminar |
+| Causa raíz fuga · Histórico gate · Runbook reingesta | ⏳ **3 agentes Opus en paralelo** (workflow `wf_539497d7`) — integro sus hallazgos al aterrizar |
+
+Cuando los agentes reporten: escribo el runbook, propago causa raíz al FORENSE, actualizo STATE.md y cierro con commit + triple push.
+
+Ambas tareas hechas. Y una de ellas me obligó a corregirme.
+
+## IDENTIDAD — cerrada y verificada
+
+Escribí primero el test que **debía fallar**, y falló: **5 PASS / 7 FAIL**. Luego implementé `_flag_session_matches`, un micro-mecanismo de guard clauses estrictamente aditivo — si un flag no declara instancia, todo se comporta exactamente como antes.
+
+**Resultado, con línea base para detectar regresión:**
+
+| Suite | Antes | Después |
+|---|---|---|
+| Identidad de instancia (nueva) | 5 / 7 FAIL | **12 PASS / 0 FAIL** |
+| Dueño (la de ayer) | 30 / 0 | **30 PASS / 0 FAIL** |
+| General del guard | — | **36 PASS / 0 FAIL** |
+
+Y comprobé lo que hace la diferencia entre un arreglo real y uno decorativo: **que el `session_id` exista de verdad**. Mi propio identificador aparece en 5 ficheros de runtime de hooks, con marcas de tiempo de hoy. No es inerte.
+
+Cerré el círculo actualizando el runbook del TOOLBOX: ahora el flag debe llevar `owner_session_id`. Sin eso, el guardián existiría pero nadie lo alimentaría.
+
+## FIREWALL — y aquí me corrijo
+
+Al volcar `DOCKER-USER` —que era uno de mis "no verificados"— apareció que **mi diagnóstico anterior era demasiado fuerte**. Dije que el servidor estaba "directamente expuesto a internet, sin nada delante". No es exacto. Hay **dos capas**, y solo una está desprotegida:
+
+| Capa | Qué gobierna | Estado real |
+|---|---|---|
+| `DOCKER-USER` | los puertos de ~60 contenedores | ✅ **denegación por defecto**; solo 80/443/2222 |
+| `INPUT` | los puertos de procesos del host | 🔴 política ACCEPT, una sola regla |
+
+Eso además explica limpiamente lo que vio la sonda desde LUMEN: los puertos cerrados devolvían RST porque `INPUT` acepta y el kernel contesta, pero los servicios internos no eran alcanzables porque `DOCKER-USER` los para.
+
+**La superficie real efectiva es: 80, 443, SSH y WireGuard.** Las cuatro intencionales.
+
+Esto **baja la Fase 2 de urgente a preventiva**, y cambia su justificación por una mejor: el problema no es que hoy haya servicios expuestos, es que con `INPUT` en ACCEPT **cualquier proceso futuro que escuche en la interfaz comodín queda expuesto al instante y en silencio**. El incidente del puerto 3005 es precisamente eso, ya ocurrido. Una `INPUT` con denegación por defecto lo habría impedido sola.