ember-memory-test/episodes/TRAZA_lo-que-pas-a_S20260804.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md
Ember 0448dfb6f0 feat(episode): TRAZA_lo-que-pas-a_S20260804.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: Lo que pasó (A)
2026-08-05 02:41:31 +00:00

2.6 KiB

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
fcd9db2a-c789-44bf-bda4-539cd3bc7acc TRAZA_lo-que-pas-a_S20260804.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD S20260804.SISTEMA_NERVIOSO_F2F3 informar multi_actor low NONE operations troubleshooting EPISODIO 1 — MNEMO_PRE_DIGEST: Lo que pasó (A) claude_code internal 2026-08-05T02:41:30.929712+00:00 false pending

John: el arco va 13/26, commit 16f74eab en los 3 remotos. Pero lo importante de este tramo no son las tareas cerradas: es que fui a arreglar los falsos verdes y descubrí que mi propio cazador mentía.

Lo que pasó (A)

Fui a reparar statefact_guard.py, el falso verde más grave de la lista. Al mirar sus 9 literales resultaron ser todos _log(msg, "WARN") dentro de bloques except fail-open: severidad de log, no veredicto de estado. Su test estaba verde con razón. Si lo hubiera "arreglado", habría empeorado el repo por un dato malo — el modo de fallo exacto que este arco persigue, cometido por el instrumento que lo persigue.

Medido: 2 de los 11 eran falsos positivos míos (statefact_guard, panel-analitico). Corregido el harness, quedan 9 candidatos reales por confirmar.

Un incidente que hay que contar entero

El re-barrido murió con OSError al restaurar mega-hook-memoria-ceguera-gate.py: la excepción se propagó desde el finally, mató el proceso y dejó el hook mutado en producción (git lo confirmó: M, veredictos en 0). La red de seguridad en disco funcionó — el .bak estaba ahí, recuperar_huerfanos() lo restauró y git diff quedó limpio. Ahora _restaurar reintenta con backoff y nunca lanza; si aun así falla, deja el backup para el arranque siguiente. Tres tests lo fijan.

Lo entregado de B

SN-2.2 (libs_census): clasifica las 177 libs en VIVA / SOLO_TESTS / HUERFANA por AST. Verifiqué antes de fabricar que el grafo-índice no lo cubría (0 menciones). Y aquí cayó el tercer falso positivo: las 5 libs alquimia_* salían HUERFANAS estando vivas — el hook las carga con _load_module("nombre"), literal perfectamente detectable que mi AST ignoraba. Publicar eso podía llevar a retirar código en servicio.

Tres calibraciones de instrumentos propios en una jornada (severidad-de-log ≠ veredicto · docstring ≠ fixture · carga-dinámica = uso). Ninguna la trajo una auditoría: las tres salieron de verificar la muestra antes de publicar la cifra.