0aaaf145e6
Skill: NONE | Type: troubleshooting Summary: EPISODIO 1 — ember-mcp: Lo que pasó cuando fui a ejecutar tu "A"
2.8 KiB
episode_id: "3cf90197-b74e-4231-aafe-1002ab4f57d9" puente_flat: "TRAZA_lo-que-pas-cuando-fui-a-ejecutar-tu-a_S20260828.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD" session_code: "S20260828.SID3E411925EAA3" acto_dialogico: "informar" actor_flujo: "multi_actor" criticidad_aegis: "low" skill_dominante: "NONE" fase_proyecto: "operations" tipo_semantico: "troubleshooting" summary_one_line: "EPISODIO 1 — ember-mcp: Lo que pasó cuando fui a ejecutar tu "A"" source_type: "claude_code" trust_boundary: "internal" created_at: "2026-09-04T01:38:01.197302+00:00" relectura_tagged: false forgejo_commit_sha: "pending"
Todo cerrado y respaldado. Cuatro commits en los tres remotos.
—
Lo que pasó cuando fui a ejecutar tu "A"
No borré nada, y esa es la buena noticia. Te pedí el GO con un diagnóstico mío que resultó falso.
La cadena, en orden
1. Preparé el borrado como es debido — respaldo con vectores en dos máquinas, script con tres guards (dry-run por defecto, conteo exacto, exclusión de procedencia mixta), test-vs-oráculo verde.
2. Al ir a ejecutarlo, la memoria estaba caída. Un script de rotación de claves había fallado a medias a las 01:16, vaciando los ficheros de credenciales de ember-mcp y de LiteLLM. Lo diagnostiqué, me diste GO, y lo restauré desde el respaldo que el propio script había tomado 8 segundos antes del fallo. Sigue sano tres horas después.
3. El panel adversarial me refutó. Dos de tres lentes dijeron NO_GO. Lo verifiqué yo mismo, sin fiarme:
| Comprobación | Resultado |
|---|---|
¿Son biyectivos con memoria_total_lockbox_v1.jsonl? |
Igualdad exacta: True |
| ¿Tienen script productor? | scripts/ingesta_uv1.py — escribe U-v1: a propósito |
| ¿Cerraron algo medido? | recall_literal: 0,0 → 1,0 |
| ¿Hubo GO tuyo? | Sí, 26-jul: "count 5.869→5.978, recall_literal 0.000→1.000" |
El 5.869 → 5.978 es exactamente el crecimiento que yo leí como "109 residuos sospechosos". Era tu ingesta autorizada, contada al revés.
Mi error fue de método: miré 5 campos de los 18 del payload y de ahí inferí el origen. Los cinco eran ciertos; la conclusión, no. Los campos que lo declaraban — origen: corpus_canonico, lote_ingesta: UV1_S20260726 — estaban ahí desde el principio.
De paso, dos arreglos reales
- B-1 cerrado: dos veredictos nacían en 0600 porque
mkstemplos crea así yos.replaceconserva los permisos. Reproducido con control negativo. El panel de arranque pasa de leer 16/18 a 18/18. - TOOLBOX corregido: su runbook mandaba a un directorio que no existe, y eso me costó minutos con el servicio caído.
—
🎯 En una frase: me diste permiso para tirar 109 "sobras", fui a comprobarlo antes de tirarlas, y resultó que no eran sobras: eran algo que tú mismo mandaste guardar en julio y que funcionaba.