ember-memory-test/episodes/DEPURA_no-pude-verificar-mi-fix-desde-ah-el_S20260812.R12_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
ad0f34be-e726-46c8-bf78-00660dac2e35	DEPURA_no-pude-verificar-mi-fix-desde-ah-el_S20260812.R12_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260812.PIPELINE_FIXES	informar	multi_actor	low	NONE	operations	troubleshooting	EPISODIO 12 — MNEMO_PRE_DIGEST: No pude verificar mi fix desde ahí: **el...	claude_code	internal	2026-08-14T04:26:38.949178+00:00	false	pending

No pude verificar mi fix desde ahí: el reporte agrega por hook (TP/FP/FN) y no expone el campo authority. Así que la comprobación de ese cambio sigue apoyada en los 29 tests y en la lectura directa del dataclass, no en este reporte. Lo digo porque medir en el sitio equivocado y darlo por bueno es el error que llevo todo el día cazando. Pero el reporte trae dos cosas que sí valen:

Confirmación cruzada de un pendiente. mega-hook-gap-detector.py sale con 2 FN (fugas) — y es exactamente el punto #21 de mi barrido, el que toma como "documentado" lo que el índice maestro lista. Dos análisis independientes, que no se conocen entre sí, señalando el mismo hook. Y el reporte se comporta como debe: cada fila dice UNRELIABLE (n=1) en vez de publicar una precisión inventada con una sola muestra. Es justo lo contrario de los ocho defectos de hoy — un instrumento que declara cuándo no puede concluir. Sin cambios este turno. La pila sigue igual: #21/#22 (auto-generados en diagnóstico, ahora con respaldo independiente), las constantes de arranque, y la unidad systemd que necesita tu mano. Cerrados los dos (c42cb6a3). Pero lo que más valor tiene de este turno es un error mío. ## Acusé al barrido de exagerar y el equivocado era yo

Reporté que el barrido inflaba las cifras 4,5× — que decía 39,1% cuando "en realidad" era 8,6%. Al ejecutar el generador de verdad: 2607 de 6661 = 39,1%, su cifra exacta. Mi medición escaneaba todos los .md del repo sin aplicar los filtros del propio generador (worktrees, copias, runtime), inflando el denominador de 6.661 a 30.449.