feat(episode): TRAZA_prlogo-completo-la-decisin-del-dispatc_S20260618.R5_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: NONE | Type: design
Summary: EPISODIO 5 — Nextcloud: 📖 Prólogo completo — la decisión del dispatcher
This commit is contained in:
Ember 2026-06-18 21:57:29 +00:00
parent c81c5cc3a0
commit 4a68d24790

View file

@ -0,0 +1,38 @@
---
episode_id: "edc94a1b-9a1e-4d5e-94df-c1ca56cfab8d"
puente_flat: "TRAZA_prlogo-completo-la-decisin-del-dispatc_S20260618.R5_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
session_code: "S20260618.VERIFY_FIRST_PASSPORT_FIX"
acto_dialogico: "informar"
actor_flujo: "multi_actor"
criticidad_aegis: "low"
skill_dominante: "NONE"
fase_proyecto: "operations"
tipo_semantico: "design"
summary_one_line: "EPISODIO 5 — Nextcloud: 📖 Prólogo completo — la decisión del dispatcher"
source_type: "claude_code"
trust_boundary: "internal"
created_at: "2026-06-18T21:57:17.342236+00:00"
relectura_tagged: false
forgejo_commit_sha: "pending"
---
Tienes razón el hook — surface una decisión sin contarte la historia completa. La completo, John, porque mereces el marco entero antes de elegir:
## 📖 Prólogo completo — la decisión del dispatcher
**Reframe:** no es *"¿reinicio un servicio que se cayó?"* — es **"¿con qué disciplina operamos la capa de réplica (Forgejo+Nextcloud) de aquí en adelante?"**
**De dónde viene (historia):** el outbox nació en abril como fanout-a-4-stores. Después crisol ganó las 3 escrituras inline del núcleo (para que el retrieval no esperara). El dispatcher murió el 12-jun **sin alarma**, y nadie lo notó en 6 días — precisamente porque el núcleo nunca falló. Esta pregunta no nace de un incidente que te dolió; nace de tu olfato arquitectónico: *"el sistema funciona, pero una pata de respaldo lleva 6 días muda y eso no me cuadra."* Y tienes razón en que no cuadra.
**Consecuencias por camino (en tu situación real: operador solo, Forgejo+Nextcloud = respaldo):**
- 🟢 **A — revivir + alerta de liveness:** en minutos vuelve la réplica + nunca más muere en silencio (la alarma es el verdadero fix). Costo: dejas el doble-write Qdrant+Neo4j como está (cosmético). Totalmente reversible.
- 🟡 **B — ADR primero:** documentas el patrón y la decisión antes de tocar. Vale si crees que esto se re-discutirá o si quieres que una instancia futura entienda *por qué* la asimetría. Costo: más lento, no arregla nada hoy; la pata sigue muda mientras escribes.
- ⚪ **C — diferir:** el núcleo sigue verde, pero Forgejo+Nextcloud siguen sin recibir nada y la deuda crece (154 `partial` → más cada día).
**Hacia dónde me inclino:** **A ahora.** Es barato, reversible, y ataca el defecto *real* (el fallo silencioso, no la asimetría — que ya vimos que es correcta). El ADR (B) lo haría **después** de A, documentando lo ya hecho + el patrón Outbox, no antes: no quiero que el papeleo retrase recuperar una pata caída hace 6 días. **Lo que cambiaría mi inclinación:** que Forgejo+Nextcloud resulten ser *críticos* y no respaldo — ahí la urgencia y el diseño cambian.
**La pregunta esencial, aislada (lo único que solo tú pones):** **¿Forgejo + Nextcloud son capas de respaldo —y entonces A (revivir + alarma) basta— o son stores de primera clase que SIEMPRE deben estar consistentes, y entonces esto merece cirugía y ADR antes de tocar?**
### 📍 PARA JOHN — R10
- **Mi consejo:** respóndeme esa única pregunta (respaldo vs primera-clase) y con eso ejecuto A, o paro a diseñar. No toco nada sin tu GO.
- 🟢 **A** revivir + alerta (mi reco, si son respaldo) · 🟡 **B** ADR/cirugía primero (si son primera-clase) · ⚪ **C** diferir