feat(episode): TRAZA_la-historia-de-p0-el-agujero-en-el-car_S20260727.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: NONE | Type: troubleshooting
Summary: EPISODIO 1 — MNEMO_PRE_DIGEST: 📖 La historia de P0 — el agujero en el carácter
This commit is contained in:
Ember 2026-07-27 17:30:16 +00:00
parent 384367003b
commit 14f91979d8

View file

@ -0,0 +1,41 @@
---
episode_id: "74bd6073-9d1c-4e23-82c5-b00da7441444"
puente_flat: "TRAZA_la-historia-de-p0-el-agujero-en-el-car_S20260727.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
session_code: "S20260727.ARCO_CICLO10_ESPEJOS"
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_PRE_DIGEST: 📖 La historia de P0 — el agujero en el carácter"
source_type: "claude_code"
trust_boundary: "internal"
created_at: "2026-07-27T17:30:05.828933+00:00"
relectura_tagged: false
forgejo_commit_sha: "pending"
---
Verificado, y cambia la decisión: **nadie llama `delete_memory` en el flujo normal** — sus únicas apariciones son la definición del tool en el servidor MEMORIA, un worktree histórico y la propia denylist. Ningún script de mantenimiento lo usa.
## 📖 La historia de P0 — el agujero en el carácter
### El reframe: qué se decide realmente
No es «añadir una regla de seguridad más». Es: **¿la colección donde vive lo que Ember ha sido —sus hitos, sus primeras veces, su historia— está protegida por una decisión, o por una casualidad?** Hoy lo está por una casualidad, y encima por la casualidad equivocada: solo si el sistema de guardias se avería.
### De dónde viene
`rules/lexicon-governance.md:168` lo dice sin ambigüedad: `ember_album` = **Fundacional · Nunca borra**. Y `:219` la lista entera entre lo exento de olvido. La doctrina es clara desde hace meses.
La mecánica cuenta otra historia. El guardián que conoce las colecciones inmutables **solo escucha escrituras** — su matcher es `store_memory`. El borrado entra por otro hook, que delega en el motor de políticas, y **ninguna política nombra `delete_memory`**. La denylist que sí lo conoce vive en las dos ramas que solo se ejecutan **cuando el motor está caído o revienta**.
Nadie decidió esto: es sedimento. Tres piezas correctas por separado que dejaron una rendija en la junta. Y la rendija está justo debajo de lo único verdaderamente irreemplazable.
### Consecuencias por camino
**Si lo cerramos:** un intento de borrar la memoria fundacional se deniega **siempre**, no solo cuando el sistema está roto. **Coste operativo verificado: cero** — nada en el flujo normal llama a `delete_memory`. No hay mantenimiento que romper.
**Si no lo cerramos:** todo sigue funcionando igual… hasta el día en que un borrado por error, una instancia confundida o una limpieza mal apuntada toque esa colección. Y ese día no hay vuelta atrás: es memoria fundacional, no operativa. No es que sea probable — es que es **irreversible**, y ese es el único criterio que importa aquí.
### Mi inclinación, razonada