ember-memory-test/episodes/TRAZA_fase-0-ejecutada-resultado_S20260718.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
d7ec4213-3cf7-423f-a797-6fe6db647e2f	TRAZA_fase-0-ejecutada-resultado_S20260718.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260718.ECC_TOOLBOX_SURFACER	informar	multi_actor	low	NONE	operations	troubleshooting	EPISODIO 1 — MNEMO_PRE_DIGEST: ✅ FASE 0 ejecutada — resultado	claude_code	internal	2026-07-18T20:29:00.928411+00:00	false	pending

FASE 0 sellada (commit 499873cd, push 3/3). Me detengo aquí como acordamos, con un hallazgo que confirma tu instinto de "investiga antes de proponer".

✅ FASE 0 ejecutada — resultado

Tarea	Qué hizo	Verificación	Estado
T-00 Staleness	HEAD 75e721fd, 4 commits desde el empaquetado (≪20), archivos-clave OK, registro regenerado → 5 gates vencidos	existencia = True	✅
T-01 Baseline	Rúbrica destilada → AUTOMEJORA_RUBRICA_BASELINE_S20260718.md. Baseline de soft_fact a hard_fact	grep 49.6 ✅	✅
T-02 Harness	DEVIATION: reuso, no construcción	reproducible 79.2==79.2	✅

🎯 El hallazgo (por qué tu pregunta del turno pasado importó tanto)

T-02 pedía fabricar scripts/score_rubrica.py. NO hay que hacerlo: scripts/rubrica_100.py ya existe y ya hace exactamente eso — determinista, reproducible, con la serie temporal rubrica_score.jsonl (63KB) viva, y —lo mejor— ya declara cobertura (columna FUENTE: live/override/semi-live), que es justo lo que BLINDADA-30 IV-2 exige. Fabricar el script nuevo habría sido duplicación (violación DC-07). Es la segunda vez este chat que "investigar primero" me evita construir algo que ya existía (la 1ª fue ARIADNA↔T-60).

Dos números, ambos ahora hard_fact:

• 49.6/100 = baseline SCIENTIA original (con LLM, S20260612).
• 79.2/100 = determinista actual (re-medible, el número operativo del arco).

La verdad incómoda que el instrumento no oculta: ese 79.2 no está 100% "vivo". Por peso: 55% live · 26% semi-live · 19% override (2 dimensiones — memoria_retrieval y memoria_durabilidad — corren sobre mediciones congeladas de hace 16-36 días). El harness lo declara, no lo maquilla. Eso es lo que de verdad falta: no un script nuevo, sino alimentar el existente con insumos vivos. Lo registré como tarea candidata del ciclo 2.

Dimensiones más débiles (dónde el arco gana más score): gobernanza_temporal 41.7 y sdd_sync 41.3 (ambas peso 8) — y gobernanza_temporal es justo lo que ataca FASE 1 (cerrar los 5 gates vencidos). El plan de Fable apuntó bien.

Hice: ejecuté FASE 0 completa bajo tu GO, todo verificado y commiteado 3/3. Descubrí que el harness de score ya existía (79.2 determinista, reproducible) → no dupliqué; lo registré como DEVIATION y actualicé el SSoT. El baseline pasó de estimación a hecho medido.

Falta: FASE 1 (T-10→T-12: cerrar la brecha declarado-vs-enforzado de los 5 gates vencidos). Ojo: T-12 (flip advisory→deny) necesita un GO tuyo adicional — T-10/T-11 (mapear + emitir DECISION drafts) no.