feat(episode): TRAZA_pila-pendientes-r5-compact_S20260605.R8_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: NONE | Type: design
Summary: EPISODIO 8 — Spec-Driven Development: 📌 PILA-PENDIENTES (R5) — COMPACT

episodes/TRAZA_pila-pendientes-r5-compact_S20260605.R8_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -0,0 +1,52 @@
+---
+episode_id: "d432686d-8b46-4b3d-ae96-6ed400f86ea4"
+puente_flat: "TRAZA_pila-pendientes-r5-compact_S20260605.R8_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
+session_code: "S20260605.AGENTES_READINESS_PIPELINE"
+acto_dialogico: "informar"
+actor_flujo: "multi_actor"
+criticidad_aegis: "low"
+skill_dominante: "NONE"
+fase_proyecto: "operations"
+tipo_semantico: "design"
+summary_one_line: "EPISODIO 8 — Spec-Driven Development: 📌 PILA-PENDIENTES (R5) — COMPACT"
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-06-06T04:19:43.790789+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+Las dos deudas de alto valor son **D3** (el bug que hace inútil la declaración de presencia) y **D5** (la falta de puente, la raíz). Mi inclinación: **arreglar D3 ahora con FORENSE** (es el que rompe el sistema entero — si la presencia no se escribe `[ACTIVO]`, nada del file-based sirve), y luego proponerte el diseño de D5 (puente) como el fix estructural. D2 y D1 ya están cerrados.
+
+¿Le entro a **D3 (FORENSE del bug duplicado+CERRADO en `declare_presence`)** ahora mismo, o prefieres que primero documente todo el diagnóstico en un doc durable y luego ataco D3+D5 en secuencia? Dado tu mandato "cerrar todas las deudas en el acto", mi voto es **D3 ya**.
+
+## 📌 PILA-PENDIENTES (R5) — COMPACT
+✅ Z-003 [R5] Comunicación inter-instancia PROBADA (mensaje entregado a sibling vivo) [hard]
+✅ Z-004 [R5] D1 presencia declarada + D2 ccd_session_mgmt whitelisted [hard]
+🔴 B-006 [R5] D3: `declare_presence` escribe duplicado + `[CERRADO]` en vez de `[ACTIVO]` único → FORENSE [hard]
+🟠 B-007 [R5] D5: sin puente harness↔file-based (raíz del desync awareness) → fix estructural [hard]
+🟡 B-008 [R5] D4 ACTIVO.md stale/zombie 154KB → prune DLC [hard]
+🟡 B-009 [R5] D6 correos no-leídos acumulados → triage [soft]
+🟠 Q-002 [R5] ¿D3 FORENSE ya, o doc primero? — esperando John [hard]
+
+**¡El fix de B-6 FUNCIONÓ — verificado en vivo!**
+
+- crisol_run.py **arrancó** (PID 1379494) tras remover el lock stale.
+- Lock **re-creado legítimamente** (01:22, con dueño esta vez).
+- **Inbox: 758 → 473** y bajando — **está drenando ahora mismo**. El log muestra AROMA procesando episodios.
+
+Removí el lock huérfano y el pipeline **se destrabó**. Esa era la causa raíz real del backlog y del loop de re-push. (Y `origin` ahora dice "up-to-date" — los 3 remotos sincronizados, T-002 cerrado.)
+
+—
+
+## Respuesta a tu pregunta — qué hice y qué queda
+
+**Lo que acabo de hacer este turno (más allá de B-1):**
+
+| Hallazgo | Acción |
+|---|---|
+| 🔴 **B-6 (NUEVO, el real sistémico):** lock `/tmp/crisol_run.lock` huérfano (0 bytes, sin proceso) bloqueaba TODA corrida de crisol → inbox no drenaba (758) → cola no se limpiaba → loop de re-push → PG acumulaba re-inserts | ✅ **REMOVIDO** (con backup + guard) → crisol destrabado → inbox 758→473 drenando en vivo |
+| B-2 reshapeado | Confirmado: Qdrant>PG es por **edad** (PG reconstruido 2026-05-22) + dedup, no huérfanos |
+| origin push DNS | ✅ recuperado, 3/3 remotos |
+
+**Lo que QUEDA (honesto):**