From 1b17ea94a31b0cbc7645e8453022abf66dbb840c Mon Sep 17 00:00:00 2001
From: Ember <ember@brasaluz.com>
Date: Thu, 22 Oct 2026 06:55:01 +0000
Subject: [PATCH] feat(episode):
 TRAZA_la-guardia-f5-v112-ya-est-commiteada-en_S20261021.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Skill: NONE | Type: troubleshooting
Summary: EPISODIO 1 — MNEMO: La guardia F5 v1.1.2 ya está commiteada en...
---
 ...ot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)
 create mode 100644 episodes/TRAZA_la-guardia-f5-v112-ya-est-commiteada-en_S20261021.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

diff --git a/episodes/TRAZA_la-guardia-f5-v112-ya-est-commiteada-en_S20261021.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md b/episodes/TRAZA_la-guardia-f5-v112-ya-est-commiteada-en_S20261021.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md
new file mode 100644
index 00000000..7ab8a435
--- /dev/null
+++ b/episodes/TRAZA_la-guardia-f5-v112-ya-est-commiteada-en_S20261021.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md
@@ -0,0 +1,46 @@
+---
+episode_id: "9c0b2910-d3ca-414f-8383-1bfcbbda3ff4"
+puente_flat: "TRAZA_la-guardia-f5-v112-ya-est-commiteada-en_S20261021.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
+session_code: "S20261021.SID68B6F4DBF7DA"
+acto_dialogico: "informar"
+actor_flujo: "multi_actor"
+criticidad_aegis: "low"
+skill_dominante: "NONE"
+fase_proyecto: "operations"
+tipo_semantico: "troubleshooting"
+summary_one_line: "EPISODIO 1 — MNEMO: La guardia F5 v1.1.2 ya está commiteada en..."
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-10-22T06:54:52.043151+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+**Para John, sin tocar:**
+- **Posible clave en el repo.** `INFRA_MANIFEST.yaml` tiene commiteado, hacia la línea 1741, un texto con forma de master key de LiteLLM. No verifiqué si sigue vigente.
+- **Permisos en el servidor MEMORIA.** En `ember-mcp-server-v3/`, el `.env` y 10 copias `.env.bak*` son legibles por otros usuarios del sistema.
+- **`reality_check.py` escribe en el servidor MEMORIA.** Copia el dashboard por `scp` en cada ejecución, incluso con `--local-only`. Antes de saberlo, lo ejecuté yo dos veces y un agente una. No toca el pipeline de memoria, pero propongo una opción para desactivar esa copia.
+
+**Pendiente, con dueño Ember y fecha 2026-10-25 salvo lo indicado:**
+- **Veta C.** No la lancé porque el presupuesto se agotó. Queda lista: el guion y la copia congelada están preparados.
+- **10 secciones del manifiesto** con valores reales ya medidos.
+- **Restos de `[FILL]`.** Los 24 ficheros de reglas que carga `CLAUDE.md` esperan tu permiso hasta el 2026-11-04.
+- **Ítems del tablero de la veta F.**
+- **Un enlace roto reparable** de la veta I.
+- **4 límites declarados de la guardia.**
+
+Todo está en la sección 6 de [docs/OBSERVATORIO_ENJAMBRES_S20261021.md](docs/OBSERVATORIO_ENJAMBRES_S20261021.md).
+
+**Coste real:** la ola A gastó 9,28 M tokens, el doble de lo estimado, para solo 9 cierres. Para el próximo brief: si la comprobación automática previa ya anticipa poco rendimiento, conviene muestrear en vez de re-verificarlo todo.
+
+Texto para pegar en la próxima ventana (POSTA):
+
+El aviso pide contexto para la decisión que dejé a John sobre `reality_check.py`. Aquí va:
+
+- **Qué se decide de verdad.** No se trata de si arreglar algo roto. Se trata de si un comando de verificación debe poder escribir en el servidor MEMORIA (cx43).
+- **Origen.** `reality_check.py` publica el dashboard por `scp` desde que se creó, y el arranque lo ejecuta cada 2 horas. Nadie lo había marcado porque se usaba como si fuera de solo lectura.
+- **Si se añade una opción para desactivar la copia (desactivada por defecto):** el arranque sigue publicando como hoy, y los agentes y briefs pueden verificar sin escribir.
+- **Si no se cambia:** cada verificación de un agente seguirá tocando el servidor MEMORIA sin que nadie lo vea.
+- **Mi recomendación:** añadir la opción sin cambiar el comportamiento por defecto. Cambiaría de opinión si el dashboard tuviera que publicarse siempre, incluso desde verificaciones locales.
+
+**La pregunta para John:** ¿Ember puede añadir a `reality_check.py` una opción opt-in para no publicar el dashboard en el servidor MEMORIA?