feat(episode): TRAZA_la-regla-prctica-3-preguntas-antes-de-me_S20260619.R5_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: TESSERA | Type: design
Summary: EPISODIO 5 — BLINDADAS: La regla práctica (3 preguntas antes de meter algo a un
This commit is contained in:
Ember 2026-06-20 16:30:43 +00:00
parent 927737aa4b
commit cc4149aa1b

View file

@ -0,0 +1,42 @@
---
episode_id: "fe77a2a2-803b-4d79-8c61-e79f21231e74"
puente_flat: "TRAZA_la-regla-prctica-3-preguntas-antes-de-me_S20260619.R5_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
session_code: "S20260619.WIKI_MEMORIA_SCRUB_AVISO"
acto_dialogico: "informar"
actor_flujo: "multi_actor"
criticidad_aegis: "low"
skill_dominante: "TESSERA"
fase_proyecto: "operations"
tipo_semantico: "design"
summary_one_line: "EPISODIO 5 — BLINDADAS: La regla práctica (3 preguntas antes de meter algo a un graf"
source_type: "claude_code"
trust_boundary: "internal"
created_at: "2026-06-20T16:30:41.781305+00:00"
relectura_tagged: false
forgejo_commit_sha: "pending"
---
Tu intuición **coincide con lo que el CONCILIO encodeó** sin que lo plantearas así:
- Wiki = dominio **episódico/conceptual** (decisiones, hitos, conceptos) = **append-once, bajo edit-churn**. Perenne-ish.
- Literatura churny (skills/rules/hooks) → al **grafo-índice derivado** que auto-actualiza.
- Estado operativo hot (alta rotación) → **ni se acerca** al grafo.
Y explica **por qué V1 (el write-reflex) es HITL, propose-only y cap-3**: porque escribir al store estructurado es caro → se **gatea deliberadamente**, no es un firehose. Tu principio *justifica* las restricciones que ya le pusimos.
## La regla práctica (3 preguntas antes de meter algo a un grafo/wiki)
1. **¿Necesito traversar relaciones** (multi-hop, lineage, "¿por qué?")? Si no → un grafo es sobre-ingeniería, usa vector/log.
2. **¿Se escribe-una-vez-se-lee-muchas** (bajo edit-churn)? Si cambia mucho → log/vector append-only.
3. **¿Es primario o derivado?** Primario → resérvalo para lo perenne. Derivado → puede seguir fuentes mutables barato.
> Tu frase "elementos más perennes en su estructura" es correcta **para el grafo primario**. Afínala así: *lo que va al grafo estructurado primario es lo **relacionalmente rico + escrito-una-vez + de alto valor de lectura** — lo perenne es el caso ideal, lo append-once el caso práctico.* Las "constituciones" son el extremo; los episodios/decisiones son el sweet spot realista (y por eso son el dominio de la wiki).
### 📍 PARA JOHN
- **Mi veredicto:** sí, tu instinto es correcto y es buen criterio de arquitectura. Lo único que corrijo es el "rehacer todo" (es incremental + re-embedding) y propongo el eje **primario-vs-derivado** como el criterio fino que vuelve tu regla operacional.
- **Por qué importa ya:** este principio **decide V5** — si construimos el `ember_wiki` (grafo semántico primario), debe alimentarse solo de lo episódico/conceptual estable, no de todo. Tu tesis es la guía.
- **Para avanzar, elige:**
- 🟢 **A** *(recomendado)* — Canonizo esto como **principio corto** (`docs/PRINCIPIO_GRAFOS_PERENNES_*.md` o regla mini) que guíe V5 y futuras decisiones de memoria. 2 min, queda como ground-truth.
- 🟡 **B** — Seguimos conversándolo; profundizo en algún punto (re-embedding, CQRS/vistas materializadas, o cómo aplicarlo a V5).
- ⚪ **C** — Solo era reflexión; lo dejamos aquí.
⛽ 🟢 GREEN ~880K | DE: 2 (canonizar / seguir / cerrar)