ember-memory-test/episodes/DEPURA_entregado-plan-de-implementacin-complet_S20260704.R99_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
6b099024-445c-4317-ac82-0fae4189fa77	DEPURA_entregado-plan-de-implementacin-complet_S20260704.R99_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260704.ANTI_OLVIDO_ESTADO_VIVO	informar	multi_actor	low	NONE	operations	troubleshooting	EPISODIO 110 — Docker: Entregado — plan de implementación completo	claude_code	internal	2026-07-12T16:18:39.223949+00:00	false	pending

Verificado — el contenido está íntegro y es de altísima calidad. El resultado supera lo pedido: el filtro adversarial PROBATOR/CRISOL rechazó (BLOCKED) las primeras versiones y las forzó a corregir errores reales antes de darlas por buenas. Ejemplos concretos que ves en el encabezado de FASE_A:

• Una spec proponía escribir 58/58 como conteo de containers → eso fabricaba estado vivo (viola BLINDADA-9). Corregido a null.
• El criterio de éxito de A-6 (ZERO DRIFT) era matemáticamente inalcanzable (el drift de catálogo dispara por count, +20 > umbral 2). Re-diseñado a un criterio honesto y alcanzable.
• Referencias a línea 1772 que se desplazarían cuando ediciones previas corren primero → cambiadas a grep sin número de línea.

Esos son exactamente los puntos donde Sonnet se habría estrellado. Fable los resolvió de antemano. Ese es el mecanismo que garantiza tu requisito.

Entregado — plan de implementación completo

Todos en docs/impl-selfaware/:

Archivo	Tamaño	Contiene
PLAYBOOK_MAESTRO.md	6 KB	Preámbulo para Sonnet, convenciones globales, orden/dependencias, KPIs, checklist de aceptación
FASE_A.md	54 KB	Higiene del sensor (6 ítems: bug PHAROS, tipo docker, auto-bump, INVENTARIO, clasificador, catálogo)
FASE_B.md	64 KB	Memoria longitudinal (agregador, comparador tendencia, serie C1-C6, rotación)
FASE_C.md	68 KB	Arco reflejo (clasificador riesgo, ejecutor, poller, tracker, escalador)
FASE_D.md	49 KB	Generador de planes Fable (plan causal, priorización por KPI)
FASE_E.md	88 KB	Meta-loop (scheduler, re-medición, auto-ajuste thresholds, cross-instancia)

Cada ítem trae: contrato I/O, micro-mecanismos ≤40 líneas con patrón canónico, el edit exacto (old→new anclado en firmas reales del código que los agentes recon leyeron), comando de verificación copy-paste con output esperado, y rollback. 380 KB de instrucciones ejecutables sin decisiones abiertas.

Hice: re-diagnóstico completo (CONSEJO+DECISION+ROADMAP) + plan de implementación máximo detalle de las 5 fases (playbook maestro + 6 specs, 380 KB), producido por 21 agentes Fable con lentes CONCILIO y verificación adversarial que atrapó bugs reales antes de escribirlos.

Falta: (1) commit triple-remoto — hay 9 archivos nuevos sin respaldar (BLINDADA-29 lo pide); (2) opcionalmente, arrancar la ejecución de F-A siguiendo el playbook.

Mi consejo: commit primero (proteger 380 KB de trabajo es barato y obligatorio), y luego arrancar F-A en esta misma sesión — que es la prueba de fuego de que el plan funciona end-to-end. F-A es local-safe y reversible.

Para avanzar, elige:

• 🟢 A (recomendado) — Commit triple-remoto ahora + arranco ejecución de F-A siguiendo FASE_A.md.
• 🟡 B — Solo commit ahora; la ejecución la decides luego con calma.
• ⚪ C — Revisas tú el playbook + specs antes de que toque nada (yo espero).