ember-memory-test/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

episode_id	puente_flat	session_code	acto_dialogico	actor_flujo	criticidad_aegis	skill_dominante	fase_proyecto	tipo_semantico	summary_one_line	source_type	trust_boundary	created_at	relectura_tagged	forgejo_commit_sha
e0a1ce80-f0cf-4130-af42-c7b15a1975f9	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	S20260727.ARCO_CICLO4_AUTOMEJORA	informar	multi_actor	low	AEGIS	operations	reflection	EPISODIO 1 — MEMORIA: Presencia cerrada `(1, True)`. Todo lo local está...	claude_code	internal	2026-07-27T06:49:16.197474+00:00	false	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.