ember-memory-test/episodes/EXPLORA_1-regla-entregada_S20260519.R16_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
a83127dd-20e2-4687-b32b-63fd7eb23839	EXPLORA_1-regla-entregada_S20260519.R16_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260519.COMMIT_MASIVO_PRESERVACION	informar	multi_actor	low	NONE	operations	design	EPISODIO 16 — BLINDADAS: 1. Regla entregada	claude_code	internal	2026-05-22T02:00:07.657744+00:00	false	pending

1. Regla entregada

rules/routeo-activacion.md creada (~190 líneas, estado dogfooding_advisory_v1). Formaliza como doctrina canónica el sesgo de routeo: ante la duda, activar; la forma escala al problema; único override = GAUGE ROJO, nunca el juicio del router. Incluye RA-1..RA-6 + 3 anti-patrones. Por BLINDADA-7, el import @rules/routeo-activacion.md en CLAUDE.md raíz aguarda tu aprobación —dime "aprobada" y lo hardcodeo (con tu OK explícito, porque CLAUDE.md es D3 infra-crítico).

2. Lo que veo en los 4 documentos (lectura directa, mía, sin panel)

Los cuatro apuntan al mismo lugar: EMBER cruzó un umbral de escala, y los 4 proponen —desde ángulos distintos— el mismo refactor estructural. Tres observaciones que solo se ven con los cuatro juntos:

• Convergencia y conflicto. Doc 1 (sub-agentes), Doc 3 (Public API + boundaries) y Doc 4 (progressive disclosure) son tres vocabularios del mismo problema —"los skills pesados saturan, falta estructura"— pero dan respuestas rivales: Doc 4 dice "mantén los skills pesados como skills, externaliza a bundle L3"; Doc 1 dice "promueve los skills pesados a sub-agentes". Analizarlos por separado pierde esto: necesitan reconciliación, no 4 análisis aislados.

• Punto ciego compartido —la lección Edmundio otra vez. Los 4 los escribió Ember-AI/Ember en claude.ai web, sin el estado real de este repo. Prueba dura: toda la auditoría de Doc 4 (Apéndice A, wc -c de 36 SKILL.md en /mnt/skills/user/) es de otro filesystem —este repo tiene los skills como skills/<nombre>/CLAUDE.md (48 CLAUDE.md + 2 SKILL.md). El plan de 6 fases de Doc 4 está montado sobre un layout que no coincide con el repo real. Y Doc 3 propone W-1 "Public API por SKILL.md" cuando rules/contratos-universales.md ya exige un bloque CONTRACT por skill. Ninguno es adoptable al pie de la letra —cada uno necesita filtrarse contra el repo real.

• Doc 1 ya se dogfooding esta sesión. El experimento CONCILIO que corrí usó el Agent tool = sub-agentes; 12 entre Doc B y Doc C del Edmundio. El patrón central de Doc 1 ya está en uso, y los hallazgos de Doc C son dato empírico para evaluarlo —no en abstracto.

3. Cómo analizarlos — decisión de método (te la presento, no la elijo en silencio)

La pregunta no es "analizo o no" —los analizo. Es: ¿4 experimentos base-vs-CONCILIO separados, o un CONCILIO que reconcilie los 4 como conjunto?