ember-memory-test/episodes/DEPURA_para-john-r41_S20260702.R42_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
6f6e9e89-a6b8-438f-ae7a-a6f58b6bc3cc	DEPURA_para-john-r41_S20260702.R42_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260702.MADUREZ_ECOSISTEMA_CONCILIO	informar	multi_actor	low	NONE	operations	troubleshooting	EPISODIO 42 — Vaultwarden: 📍 PARA JOHN — R41	claude_code	internal	2026-07-12T16:16:36.911510+00:00	false	pending

Hecho. Lo que empezó como "extender M0-01 con .mcp.json" terminó destapando algo más importante que cualquier runbook nuevo.

Hice — Verifiqué tu reporte y, al investigar los 7 secretos de .mcp.json, descubrí que ya existe el runbook canónico de rotación — no había que fabricar nada nuevo. Reconcilié el estado real en el plan (bloque RECONCILIACIÓN CRÍTICA en M0-01) y registré la lección en memoria.

El hallazgo real (más valioso que un M0-01b):

• Hubo un sprint de seguridad integral S20260623 (90 agentes, 41 hallazgos) con un runbook HITL completo: RUNBOOK_ROTACION_SECRETOS_JOHN_S20260623.md. Cubre 13 secretos (no 4+7) con método superior (store GPG cifrado, orden seguro, recableado-PRE, verificación viejo-muerto).
• Su Ola 1 (fixes de código) se ejecutó ✅ (cierre S20260624). Su Ola 2 (rotar los 13 secretos) sigue PENDIENTE ❌ (checkboxes 0/17).
• El CONSEJO de hoy subestimó: reportó "4 secretos vivos"; son ~13, e incluyen 2 más graves que hoy ni mencionamos: §A la passphrase del gate MCP (quien la tenga desbloquea las 67 tools = RCE en ember-mcp) y §B Vaultwarden (el gestor de secretos entero). Y §B escapó a git tracked: el BW_CLIENTSECRET está en AUDIT_SEARCH_TOOLS_SERVIDOR_MEMORIA_S20260408.md (commiteado, 3 remotos) — corrige mi "solo local".
• Estamos viviendo el fallo que la auditoría denunció: el CONSEJO no consultó el sprint de hace 10 días, y mi Ola 0 duplicaba una Ola 2 superior ya existente. Es exactamente el punto ciego de continuidad/memoria del informe, ocurriendo en vivo.

Corregí — M0-01b ya no es "fabricar nuevo" sino "ejecutar la Ola 2 pendiente del runbook S20260623", con su orden de prioridad correcto (§A RCE → §B vault → resto). M0-01 (settings.json) queda subsumido ahí.

La decisión que te elevo (PRÓLOGO) — La rotación es tu parte (CASBIN CA-3: yo no puedo rotar). El runbook ya te da el paso a paso. Lo único genuinamente urgente e irreversible-si-se-ignora es §A (passphrase MCP, RCE) y §B (Vaultwarden) — más que los 4 de settings.json. Mi inclinación: empezar la Ola 2 por §A y §B hoy, siguiendo el runbook existente; yo hago mi parte (recableado + limpieza de historia) cuando me avises que rotaste.

Para avanzar, elige:

• 🟢 A (recomendado) — Abrimos el runbook S20260623 y arrancas la Ola 2 por §A (passphrase MCP) + §B (Vaultwarden); te acompaño paso a paso y hago el recableado.
• 🟡 B — Primero reconcilio el CONSEJO/DECISION de hoy para que reflejen los 13 secretos reales (no 4) y enlacen el sprint S20260623, y luego rotas con calma.
• ⚪ C — Solo querías el gap de .mcp.json cubierto (hecho + reconciliado); paramos aquí.