john/ember-memory-test
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

feat(episode): TRAZA_s-el-ncleo-es-correcto-pero-el-criterio_S20260619.R4_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Browse source 
Skill: NONE | Type: design
Summary: EPISODIO 4 — BLINDADAS: Sí, el núcleo es correcto — pero el criterio fino no es
This commit is contained in:
Ember 2026-06-20 16:30:42 +00:00
parent 135c8250a1
commit 927737aa4b
1 changed files with 40 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

40
episodes/TRAZA_s-el-ncleo-es-correcto-pero-el-criterio_S20260619.R4_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md Normal file
View file

@ -0,0 +1,40 @@
---
episode_id: "d75ae209-8f40-4f52-baf8-6a0120e3ecb1"
puente_flat: "TRAZA_s-el-ncleo-es-correcto-pero-el-criterio_S20260619.R4_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: "NONE"
fase_proyecto: "operations"
tipo_semantico: "design"
summary_one_line: "EPISODIO 4 — BLINDADAS: Sí, el núcleo es correcto — pero el criterio fino no es "inm"
source_type: "claude_code"
trust_boundary: "internal"
created_at: "2026-06-20T16:30:41.776183+00:00"
relectura_tagged: false
forgejo_commit_sha: "pending"
---
Buenas, John. Me preguntas mi opinión genuina sobre una tesis de arquitectura — y es una buena, así que te respondo en serio, afirmando el núcleo pero afilándolo donde creo que se pasa de fuerte.
## Sí, el núcleo es correcto — pero el criterio fino no es "inmutable", es otro
**Lo que aciertas (y es buena arquitectura de sistemas):** un store muy estructurado (grafo, wiki con wikilinks) tiene **costo de escritura alto y rigidez** que un log o un vector-store no tienen. Meter un nodo/arista consistente exige conocer el esquema, evitar huérfanos y duplicados, y a veces re-embeber. Por eso **no quieres poner datos de alta rotación (churn) ahí**. Reservarlo para conocimiento estable es exactamente el trade-off clásico "OLTP vs OLAP / hot vs cold". Es sólido.
**Dónde matizo (te lo debo honesto, no aplausos):**
**1. No es "rehacer todo el grafo" para cualquier update.** Los grafos (Neo4j) actualizan **incrementalmente** — añades un nodo sin reconstruir el resto. El costo real no es "rebuild total", son tres cosas: (a) **re-embedding** si es grafo *semántico* (eso sí es caro — es justo el costo de V5 que discutimos), (b) mantener **invariantes globales** (dedup, consistencia), (c) la **curación humana** (HITL). Es "alto costo por-escritura + consolidación periódica", no "rehacer todo".
**2. La variable correcta no es inmutable↔mutable. Es PRIMARIO↔DERIVADO** (× necesitas-relaciones × read-heavy). Esta es la distinción que vuelve tu principio preciso y resuelve una aparente contradicción:
| | Grafo **DERIVADO** (vista materializada) | Grafo **PRIMARIO** (la fuente de verdad) |
|---|---|---|
| Qué es | Se **regenera** desde archivos fuente | Los nodos/aristas **SON** el dato, curados a mano/HITL |
| Costo de update | **Barato** (solo regenerar) | **Caro** (cada cambio cuesta) |
| Puede seguir fuentes... | **mutables** (se re-deriva y ya) | solo **perennes/append-once** |
| Ejemplo nuestro | grafo-índice (674 nodos, auto-actualiza en cada commit) · index.md V7 | wiki episódica · una constitución |
Tu principio aplica con TODA su fuerza al grafo **primario**. El derivado puede darse el lujo de seguir cosas que cambian, porque "rehacerlo" es automático y barato. Por eso nuestro grafo-índice puede auto-actualizarse con cada cambio de código sin violar tu regla.
## Y aquí está lo bonito: es exactamente lo que ya decidimos