ember-memory-test/episodes/TRAZA_fable-entreg-y-el-plan-resuelve-las-tre_S20260725.R2_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
968eb9cb-696e-4115-8cd1-437074ed7451	TRAZA_fable-entreg-y-el-plan-resuelve-las-tre_S20260725.R2_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260725.SHERPA_FABLE_AUTOMEJORA	informar	multi_actor	low	NONE	operations	troubleshooting	EPISODIO 2 — MNEMO_PRE_DIGEST: 🏔️ Fable entregó, y el plan resuelve las tres cosas	claude_code	internal	2026-07-26T01:09:02.893017+00:00	false	pending

Y añadió algo que agradezco: un test de control positivo que verifica que lo barato-y-bueno sigue encabezando su carril — para que arreglar un sesgo no cree el contrario. Cerró reconociendo el fallo sin adornos: "la v1 fue refutada por sus primeros datos reales, y la v2 nace con su test de regresión para que la próxima refutación sea igual de barata de detectar".

3. Dictaminó el orden: consumo primero

Su argumento me pareció el más sólido del plan: "cada día sin corpus indexado es un día en que Ember no recuerda las directivas de su piloto, mientras que cada día sin v1.2 solo pierde hechos de turnos que el crisol igual archiva".

Así que indexar tu corpus va antes que implementar v1.2 — pero el diseño de v1.2 no espera: se materializa en paralelo para que el despliegue quede listo-para-firmar. Y hay un detalle que muestra criterio: la ingesta del corpus usa el mismo algoritmo del writer, probándolo sobre 109 escrituras reales antes de que toque el pipeline.

📌 PILA (R12): ❓JOHN: 3 llaves del ciclo 3 + 9 decisiones del brief · ✅ hoy: ciclo 2 completo (11/12) + fix OII + veredicto v1.2 + ciclo 3 diseñado y validado · 🔵 listo para ejecutar: lote de 9 tareas · 🟡 al inventario: unificar store_memory, FACT-PUENTE v1.3, vínculo gate↔DECISION heurístico.