feat(episode): DEPURA_r18seccion6q1-decisin-esencial-requerida_S20260523.R26_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: NONE | Type: chronicle
Summary: EPISODIO 26 — ember_experience: [R18.seccion6.Q1] Decisión esencial requerida

episodes/DEPURA_r18seccion6q1-decisin-esencial-requerida_S20260523.R26_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -0,0 +1,38 @@
+---
+episode_id: "aa7ad9b8-40a9-4a8a-a6ca-abc252a60fd8"
+puente_flat: "DEPURA_r18seccion6q1-decisin-esencial-requerida_S20260523.R26_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
+session_code: "S20260523.MANT_MEMORIA_DIA5_CASBIN_IMPORT"
+acto_dialogico: "informar"
+actor_flujo: "multi_actor"
+criticidad_aegis: "low"
+skill_dominante: "NONE"
+fase_proyecto: "operations"
+tipo_semantico: "chronicle"
+summary_one_line: "EPISODIO 26 — ember_experience: [R18.seccion6.Q1] Decisión esencial requerida"
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-05-24T03:22:49.987491+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+**PERO hay 3 bugs documentados que afectan la "garantía granular día/noche"**:
+
+| Bug | Severidad | Status |
+|---|---|---|
+| **B-NEW14** OTS HTTPS sync per-BLC-entry serializado | MEDIUM | Sprint dedicado pendiente (HARD_BLOCK Agent 20 boundaries) |
+| **B-NEW16** push_to_server cola no limpia + drift indicador L1 (300s SSH timeout insuficiente batches grandes) | MEDIUM | Documentado R18 |
+| **B-NEW17** (NUEVO R18) crisol_run.py PID 750907 stuck desde R15 (lock activo bloquea cron triggers) | **HIGH** | Requiere kill + restart pending OK John |
+
+**Granularidad día/noche garantizada**: ✅ SÍ para PUSH | ❌ NO para PROCESSING (último drain real fue R15 antes del freeze)
+
+## [R18.seccion6.Q1] Decisión esencial requerida
+
+**QUÉ**: matar PID 750907 + limpiar lock → cron próximo tick (01:00 UTC en ~5 min) procesará fresh + iniciará drain real del backlog 3149. **POR QUÉ**: Agent 20 v0.2.0 `boundaries.will_not` incluye "Kill PID crisol_run.py legitimo (verify estado waiting vs stuck primero)". Ya verifiqué empíricamente:
+- BLC pos stuck idéntico 10h ✓ (criterio stuck)
+- Inbox counts batches viejos sin cambio 10h ✓ (criterio stuck)
+- Process sleeping do_poll esperando subprocess no-progresivo ✓ (criterio stuck)
+
+**Verificación stuck cumple condición "verify primero"** → HARD_BLOCK Agent 20 ya no aplica. **CÓMO FUNCIONA**: SIGTERM graceful primero (15s timeout), si no muere SIGKILL. Limpiar `/tmp/crisol_run.lock`. Esperar próximo cron tick automático (cada hora a HH:00). **QUÉ ESPERAR**: PID nuevo asignado por cron 01:00 UTC. Empezará a procesar desde inbox actual 3149. Si OTS bottleneck B-NEW14 persiste (sin fix), drain rate ~13/h → 240h total. Si John autoriza también sprint OTS optimization → 10-50x speedup. ¿Procedo con kill+restart o esperas decision más detenida? Mi inclinación: **SI procedo** porque self-imposed gridlock empeora con cada hora (inbox crece, cola pending crece, indicador drift crece). ### 📁 BITÁCORA S20260523.MANT_MEMORIA_DIA5_CASBIN_IMPORT.R18
+
+### 📌 PILA-PENDIENTES (R18) — formato PP-9 COMPACT