@yoltra/core 0.6.0 → 0.8.0

package/README.es.md

@@ -3,12 +3,14 @@
 # @yoltra/core
 
 > 👉 🇲🇽 Versión en Español  |
->  [ 🇺🇸 English Version](./README.md) 
+>  [ 🇺🇸 English Versión](./README.md) 
 
-![npm downloads](https://badgen.net/npm/dm/@yoltra/core)
-![License](https://badgen.net/npm/license/@yoltra/core)
+[![versión npm](https://img.shields.io/npm/v/@yoltra/core)](https://www.npmjs.com/package/@yoltra/core)
+[![descargas npm](https://img.shields.io/npm/dm/@yoltra/core)](https://www.npmjs.com/package/@yoltra/core)
+[![tipos](https://img.shields.io/npm/types/@yoltra/core)](https://www.npmjs.com/package/@yoltra/core)
+[![Licencia](https://img.shields.io/npm/l/@yoltra/core)](https://github.com/yoltra/yoltra/blob/main/LICENSE)
 
-**Contenedor de estado orientado a eventos, agnostico de framework, con suscripciones de grano
+**Contenedor de estado orientado a eventos, agnóstico de framework, con suscripciones de grano
 fino por ruta.**
 
 `@yoltra/core` es la base de [yoltra](../../README.md).
@@ -17,7 +19,7 @@ Proporciona el store, el pipeline de eventos, middleware, efectos y el sistema d
 
 ---
 
-## Instalacion
+## Instalación
 
 ```bash
 npm install @yoltra/core
@@ -27,14 +29,14 @@ npm install @yoltra/core
 
 ## El Pipeline de Eventos
 
-Cada llamada a `emit()` fluye a traves de un pipeline determinista:
+Cada llamada a `emit()` fluye a través de un pipeline determinista:
 
 ```
 emit(channel, type, payload)
   │
   ├─ 0. Dedup (opt-in) ─── Omite un duplicado solo si dedupWindowMs > 0 o se pasa un dedupKey
   │
-  │  ══ fase de reduccion SINCRONA — corre antes de que emit() retorne ══
+  │  ══ fase de reduccion SINCRONA: corre antes de que emit() retorne ══
   ├─ 1. Middleware ─── Hooks pre-reducer sincronos (devolver false para rechazar → evento "no confirmado")
   ├─ 2. Reducers ─── Cada slice que aplica se prepara, y todas se confirman bajo una sola raiz
   ├─ 3. Suscriptores de eventos ─── Notificaciones de eventos confirmados/no confirmados
@@ -43,11 +45,11 @@ emit(channel, type, payload)
   └─ 5. Efectos ─── Efectos secundarios ASYNC, una tarea independiente por evento (indexados para busqueda O(1))
 ```
 
-La fase de reduccion (1–4) es **sincrona**, asi que `getState()` es correcto en el instante en que
-`emit()` retorna — incluso con middleware. Los efectos (5) corren despues como una tarea async
+La fase de reducción (1–4) es **síncrona**, así que `getState()` es correcto en el instante en que
+`emit()` retorna, incluso con middleware. Los efectos (5) corren después como una tarea async
 independiente; la promesa de `emit()` se resuelve cuando terminan los efectos de ese evento. Cada
-etapa es interceptable, y `store.instrument()` expone todo el flujo — rutas hoja cambiadas, tiempos
-de reduccion, fase confirmado/rechazado — a las DevTools sin ningun `as any`. Ver la
+etapa es interceptable, y `store.instrument()` expone todo el flujo (rutas hoja cambiadas, tiempos
+de reducción, fase confirmado/rechazado) a las DevTools sin ningún `as any`. Ver la
 [Arquitectura del Pipeline de Eventos](../../docs/es/design/event-queue-architecture.md) para el
 modelo completo.
 
@@ -58,7 +60,7 @@ modelo completo.
 ### Eventos basados en canales
 
 Los eventos son tuplas `(channel, type, payload)`. Los canales proporcionan namespacing natural
-que escala en bases de codigo grandes:
+que escala en bases de código grandes:
 
 ```typescript
 await store.emit("auth", "login", credentials);
@@ -66,28 +68,85 @@ await store.emit("analytics", "track", { event: "page_view" });
 await store.emit("ui", "toast", { message: "Saved!" });
 ```
 
-### Suscripciones de grano fino via `connect()`
+### Suscripciones de grano fino vía `connect()`
 
-Suscribete a rutas de estado exactas usando notacion de puntos. Soporta wildcards `*` (un
-segmento) y `**` (cero o mas segmentos):
+Suscríbete a rutas de estado exactas usando notación de puntos. Soporta wildcards `*` (un
+segmento) y `**` (cero o más segmentos):
 
 ```typescript
-// Ruta exacta — se dispara cuando items[0].title cambia
+// Ruta exacta: se dispara cuando items[0].title cambia
 store.connect({ reducer: "todos", property: "items.0.title" }, (change) =>
   console.log("title:", change.oldValue, "→", change.newValue),
 );
 
-// Wildcard de un segmento — se dispara cuando el titulo de CUALQUIER item cambia
+// Wildcard de un segmento: se dispara cuando el titulo de CUALQUIER item cambia
 store.connect({ reducer: "todos", property: "items.*.title" }, (change) =>
   console.log("some title changed at", change.path),
 );
 
-// Wildcard profundo — se dispara cuando algo bajo items cambia
+// Wildcard profundo: se dispara cuando algo bajo items cambia
 store.connect({ reducer: "todos", property: "items.**" }, (change) =>
   console.log("items tree changed at", change.path),
 );
 ```
 
+### Slices que contienen un solo valor
+
+Una slice no tiene por qué ser un objeto. Un primitivo, un `Map`, un `Set` o una `Date` es un
+estado de slice válido, y se confirma igual que cualquier otro:
+
+```typescript
+const store = createStore({
+  name: "session",
+  reducer: {
+    token: {
+      state: null as string | null,
+      when: { keys: [["auth", "login"]] },
+      reducer: (_state, event) => event.payload.token,
+    },
+  },
+});
+
+await store.emit("auth", "login", { token: "abc123" });
+store.getState().token; // "abc123"
+```
+
+Una slice así no tiene ninguna propiedad debajo, así que sus cambios se reportan en la **raíz de
+la slice**, la ruta vacía. Suscríbete a ella con `property: ""`:
+
+```typescript
+store.connect({ reducer: "token", property: "" }, (change) =>
+  console.log("token:", change.oldValue, " --> ", change.newValue),
+);
+```
+
+Los tipos conocen la diferencia. `property` en una slice de valor raíz acepta `""` y nada más,
+porque no hay ninguna clave que direccionar, y el valor vuelve correctamente tipado:
+
+```typescript
+const token = useAtomicProp({ reducer: "token", property: "" }); // string | null
+```
+
+### `""` frente a `"**"`: observar una slice completa
+
+Dos suscripciones que suenan iguales y no lo son:
+
+| Patrón | Se dispara cuando |
+|---|---|
+| `""` | el **valor completo** de la slice se reemplaza: cambia un primitivo, se reconstruye un `Map`, una slice de objeto pasa a `null` |
+| `"**"` | cambia **cualquier cosa** dentro de la slice, a cualquier profundidad. También coincide con la raíz, porque `**` coincide con cero segmentos |
+| `"*"` | exactamente un nivel más abajo. Nunca coincide con la raíz |
+
+**`"**"` es la suscripción a la slice completa, y funciona para toda slice sin importar su forma.**
+Recurre a `""` solo cuando te refieras al valor raíz en sí; en una slice de objeto se queda
+callada, porque una slice así reporta sus cambios en las hojas.
+
+`Map` y `Set` se comparan por referencia, no por entrada: un reducer que devuelve un `Map` nuevo
+es un cambio, mutar uno en el sitio no lo es. Eso se desprende del contrato de inmutabilidad en
+vez de ser un caso especial. Construye una colección nueva en lugar de mutar la almacenada. Es
+también la razón de que no tengan rutas debajo: `"byId"` es suscribible, `"byId.get"` no, y los
+tipos lo dicen.
+
 ### Inmutabilidad
 
 El estado se congela profundamente antes de confirmarse. Las mutaciones lanzan error en modo
@@ -114,7 +173,7 @@ type AppEM = {
   system: { init: void; shutdown: void };
 };
 
-// Coincidir con claves de evento especificas (recomendado — preserva la correlacion de tipos)
+// Coincidir con claves de evento especificas (recomendado: preserva la correlacion de tipos)
 const counterReducer = {
   state: { value: 0 },
   when: {
@@ -156,7 +215,7 @@ const globalLogger = {
 
 ## Middleware
 
-El middleware se ejecuta **sincronamente, antes** de los reducers y puede cancelar la propagacion
+El middleware se ejecuta **sincronamente, antes** de los reducers y puede cancelar la propagación
 de eventos (devolver `false` para rechazar → evento "no confirmado"). El trabajo async va en los
 efectos, no en el middleware. Soporta tanto funciones directas (legacy) como objetos
 `MiddlewareSpec` con targeting:
@@ -164,7 +223,7 @@ efectos, no en el middleware. Soporta tanto funciones directas (legacy) como obj
 ```typescript
 import type { MiddlewareSpec } from "@yoltra/core";
 
-// Middleware con target — solo se ejecuta para eventos del canal admin
+// Middleware con target: solo se ejecuta para eventos del canal admin
 const adminGuard: MiddlewareSpec<AppState, AppEM> = {
   when: { channel: "admin" },
   middleware: (state, event) => {
@@ -174,7 +233,8 @@ const adminGuard: MiddlewareSpec<AppState, AppEM> = {
   meta: { type: "middleware", name: "adminGuard" },
 };
 
-// Middleware global — se ejecuta para todos los eventos (sincrono: devuelve un boolean, nunca una Promise)
+// Middleware global: se ejecuta para todos los eventos. Sincrono, nunca una Promise: solo un
+// `false` explicito veta, asi que un middleware que solo observa puede no devolver nada.
 const logger = (state, event) => {
   console.log("Event:", event.channel, event.type);
   return true;
@@ -189,7 +249,7 @@ const store = createStore({
 });
 ```
 
-### Middleware dinamico
+### Middleware dinámico
 
 ```typescript
 const off = store.registerMiddleware((state, event) => {
@@ -202,8 +262,8 @@ off(); // Remover despues
 
 ## Efectos
 
-Los efectos se ejecutan **despues** de los reducers y ven el estado final. Estan indexados por
-evento para busqueda O(1):
+Los efectos se ejecutan **después** de los reducers y ven el estado final. Están indexados por
+evento para búsqueda O(1):
 
 ```typescript
 // Via spec del store
@@ -244,16 +304,16 @@ const off2 = store.onEffect("ui", "save", async (payload, getState, emit) => {
 
 ## Suscripciones a Eventos
 
-Suscribete a eventos (no al estado) desde la capa de vista. Util para notificaciones,
+Suscríbete a eventos (no al estado) desde la capa de vista. Útil para notificaciones,
 animaciones y reaccionar a eventos rechazados:
 
 ```typescript
-// Eventos confirmados (por defecto) — eventos que pasaron el middleware
+// Eventos confirmados (por defecto): eventos que pasaron el middleware
 const off = store.onEvent("ui", "save", (event, getState, emit, phase) => {
   console.log("Save committed:", event.payload);
 });
 
-// Eventos no confirmados — eventos rechazados por el middleware
+// Eventos no confirmados: eventos rechazados por el middleware
 store.onEvent(
   "ui",
   "delete",
@@ -263,7 +323,7 @@ store.onEvent(
   "uncommitted",
 );
 
-// Todos los eventos — tanto confirmados como no confirmados
+// Todos los eventos: tanto confirmados como no confirmados
 store.onEvent(
   "ui",
   "action",
@@ -274,15 +334,34 @@ store.onEvent(
 );
 ```
 
+### Suscriptores de eventos y viaje en el tiempo
+
+**El replay no llama a tus handlers.** Recorrer una línea de tiempo de DevTools vuelve a reducir
+los eventos, así que el estado sigue el recorrido, pero los handlers de `onEvent` permanecen en
+silencio. Antes se ejecutaban igual que con un evento real, así que arrastrar la línea de tiempo
+volvía a publicar a los pares, a escribir en sockets y a disparar analítica por eventos que no
+estaban ocurriendo de nuevo, sin nada dentro del handler que permitiera notar la diferencia.
+
+Un handler que deriva estado de vista puramente del flujo de eventos, y que no hace E/S, puede
+activarlo:
+
+```ts
+store.onEvent("ui", "save", handler, "committed", { duringReplay: true });
+```
+
+`store.isReplaying` existe para lo que deba ramificar en lugar de simplemente omitirse. Los
+suscriptores gruesos de `subscribe` y las suscripciones de `connect` siguen disparándose, porque
+el estado sí cambió y la interfaz tiene que seguir el recorrido.
+
 ---
 
-## Los commits son atomicos entre slices
+## Los commits son atómicos entre slices
 
-Un evento que toca varias slices las escribe todas y despues notifica. Nadie observa un evento
-aplicado a medias: un suscriptor de una slice que lee `getState()` ve todas las demas slices del
+Un evento que toca varias slices las escribe todas y después notifica. Nadie observa un evento
+aplicado a medias: un suscriptor de una slice que lee `getState()` ve todas las demás slices del
 mismo evento ya aplicadas.
 
-Esto importa sobre todo donde un cambio se usa como senal para volver a leer, que es lo que hacen
+Esto importa sobre todo donde un cambio se usa como señal para volver a leer, que es lo que hacen
 los hooks de React.
 
 ---
@@ -290,7 +369,7 @@ los hooks de React.
 ## Rechazar una escritura
 
 Un reducer devuelve `Rejected(reason)` en lugar de estado para declinar. **Se rechaza el evento
-completo**: ninguna slice escribe, no se emite ninguna notificacion de cambio, y quien llamo sabe
+completo**: ninguna slice escribe, no se emite ninguna notificación de cambio, y quien llamo sabe
 por que.
 
 ```typescript
@@ -313,36 +392,36 @@ const store = createStore({
 
 const result = await store.emit("plan", "patch", { steps, expectedVersion: 1 });
 
-result.committed; // true — el middleware lo permitio
-result.written; // false — pero no se escribio nada
+result.committed; // true: el middleware lo permitio
+result.written; // false: no se escribio nada
 result.rejected?.reason;
 ```
 
 Rechazar **no** es lo mismo que devolver el estado sin cambios, que es indistinguible de "este
-evento no me concierne". Tampoco es lo mismo que lanzar: un reducer que lanza tiene un bug, asi
-que su slice queda aislada y las demas si escriben, mientras que un reducer que rechaza ha tomado
-una decision a la que cede el evento entero.
+evento no me concierne". Tampoco es lo mismo que lanzar: un reducer que lanza tiene un bug, así
+que su slice queda aislada y las demás sí escriben, mientras que un reducer que rechaza ha tomado
+una decisión a la que cede el evento entero.
 
 `emit` resuelve a un `EmitResult` cuando terminan los efectos:
 
 | | |
 |---|---|
-| `committed` | el middleware no lo veto |
-| `written` | un reducer cambio el estado de verdad |
-| `rejected` | presente cuando un reducer rechazo, con su `reason` |
+| `committed` | el middleware no lo vetó |
+| `written` | un reducer cambió el estado de verdad |
+| `rejected` | presente cuando un reducer rechazó, con su `reason` |
 
 La fase `written` de `onEvent` reporta lo mismo a los suscriptores. `committed` sigue
 significando **no vetado** y no se estrecho a proposito: se dispara para todo evento que el
-middleware permite, incluidos todos los eventos de un store sin reducers — la forma que toma un
-bus de notificaciones o de analitica.
+middleware permite, incluidos todos los eventos de un store sin reducers, la forma que toma un
+bus de notificaciones o de analítica.
 
 ---
 
-## Peticion y respuesta — `store.call()`
+## Petición y respuesta: `store.call()`
 
-Todo consumidor de un bus de eventos acaba escribiendo peticion/respuesta a mano: generar un id,
-suscribirse, emparejar, expirar, desuscribirse. Son unas ochenta lineas y siempre traen los
-mismos dos bugs: la suscripcion sobrevive a la llamada, y `Quien Responde` que olvida devolver el
+Todo consumidor de un bus de eventos acaba escribiendo petición/respuesta a mano: generar un id,
+suscribirse, emparejar, expirar, desuscribirse. Son unas ochenta líneas y siempre traen los
+mismos dos bugs: la suscripción sobrevive a la llamada, y `Quien Responde` que olvida devolver el
 id produce un timeout sin nada a lo que apuntar.
 
 ```typescript
@@ -364,7 +443,7 @@ store.registerEffect({
 
 ### Una llamada resuelve al evento, no al payload
 
-Porque muchas veces quien llama no sabe *cual* respuesta va a recibir. `reply` nombra los tipos
+Porque muchas veces quien llama no sabe *cuál* respuesta va a recibir. `reply` nombra los tipos
 **terminales**, y el evento trae el discriminante:
 
 ```typescript
@@ -388,45 +467,45 @@ for await (const step of call) await render(step.payload);
 const { payload } = await call;
 ```
 
-La contrapresion es real, no un buffer con limite. `emit` resuelve solo cuando terminan sus
-efectos, y el colector es un efecto que no retorna hasta que el consumidor tomo el elemento — asi
+La contrapresión es real, no un buffer con límite. `emit` resuelve solo cuando terminan sus
+efectos, y el colector es un efecto que no retorna hasta que el consumidor tomo el elemento, así
 que un `Quien Responde` que escribe `await emit("job", "tick", chunk)` **va al ritmo del lector**.
 
-La contrapresion entra en juego **cuando empiezas a iterar**. Una llamada que solo se espera con
-`await` nunca extrae nada, asi que bloquear a su productor causaria un interbloqueo de la propia
-llamada: el progreso que nadie lee impediria que se enviara el evento terminal. Por eso el
-progreso no iterado se almacena hasta `highWaterMark` y despues se cuenta en `call.dropped`.
+La contrapresión entra en juego **cuando empiezas a iterar**. Una llamada que solo se espera con
+`await` nunca extrae nada, así que bloquear a su productor causaría un interbloqueo de la propia
+llamada: el progreso que nadie lee impediría que se enviara el evento terminal. Por eso el
+progreso no iterado se almacena hasta `highWaterMark` y después se cuenta en `call.dropped`.
 
 ### Retroceso
 
 | | |
 |---|---|
 | `timeoutMs` | **Inactividad**, no total: todo evento correlacionado lo reinicia, incluido el progreso. Por defecto 30s. |
-| `signal` | Un `AbortSignal`, para una fecha limite real o una accion cancelada. |
+| `signal` | Un `AbortSignal`, para una fecha límite real o una acción cancelada. |
 | `call.cancel(reason)` | Deja de escuchar y liquida la llamada. |
 
-Termine como termine, la suscripcion se elimina y se libera cualquier productor detenido por la
-contrapresion. Un `Quien Responde` atascado es peor que el buffer sin limite que esto reemplazo.
+Termine como termine, la suscripción se elimina y se libera cualquier productor detenido por la
+contrapresión. Un `Quien Responde` atascado es peor que el buffer sin límite que esto reemplazo.
 
 ---
 
 ## Leer un valor al suscribirse
 
-`connect` empieza en "de ahora en adelante", asi que la primera lectura habia que repetirla en
-otro lado — la misma ruta en dos sitios, libres de divergir:
+`connect` empieza en "de ahora en adelante", así que la primera lectura había que repetirla en
+otro lado: la misma ruta en dos sitios, libres de divergir:
 
 ```typescript
 store.connect({ reducer: "todos", property: "items.0.title" }, render, { immediate: true });
 ```
 
-El primer cambio sintetico trae `oldValue: undefined` y **sin procedencia**, porque ningun evento
-lo causo. React no lo necesita: `useSyncExternalStore` ya lee una instantanea al montar.
+El primer cambio sintético trae `oldValue: undefined` y **sin procedencia**, porque ningún evento
+lo causó. React no lo necesita: `useSyncExternalStore` ya lee una instantánea al montar.
 
 ---
 
-## De donde vino un cambio
+## De dónde vino un cambio
 
-Un `Change` nombra el evento que lo causo, asi que un suscriptor ya no tiene que duplicar la causa
+Un `Change` nombra el evento que lo causó, así que un suscriptor ya no tiene que duplicar la causa
 dentro del estado:
 
 ```typescript
@@ -438,19 +517,41 @@ store.connect({ reducer: "orders", property: "status" }, (change) => {
 });
 ```
 
-La procedencia esta **ausente** cuando ningun evento causo el cambio — un salto de time-travel de
-DevTools, o la entrega `immediate` de arriba. La ausencia es la senal, en vez de un id inventado.
+La procedencia está **ausente** cuando ningún evento causó el cambio: un salto de time-travel de
+DevTools, o la entrega `immediate` de arriba. La ausencia es la señal, en vez de un id inventado.
 
 ---
 
-## Proteccion contra cascadas (activada por defecto)
+## Deduplicación de Eventos (opt-in)
+
+La deduplicación está **desactivada por defecto**. Yoltra nunca descarta en silencio eventos
+idénticos legítimos y rápidos (doble-clics, `+1` repetidos). Actívala solo cuando de verdad quieras
+coalescer:
+
+```typescript
+// Por contenido: coalescer (channel, type, payload) identicos dentro de una ventana.
+const store = createStore({
+  name: "App",
+  reducer: {
+    /* ... */
+  },
+  dedupWindowMs: 100, // default: 0 (desactivado)
+});
+
+// Por identidad: dedup por una clave explicita, p. ej. un doble-invoke de React Strict Mode en un efecto.
+await store.emit("analytics", "pageView", { page }, { dedupKey: `pageView:${page}` });
+```
 
-Dos consumidores conectados entre si — un suscriptor que emite lo que su propio reducer atiende, o
-dos slices que atienden los eventos de la otra — producen una cadena de eventos sin final. La cola
-de reduccion se drena de forma **sincrona**, asi que eso no es un programa lento: es una pestana
+---
+
+## Protección contra cascadas (activada por defecto)
+
+Dos consumidores conectados entre sí, ya sea un suscriptor que emite lo que su propio reducer atiende o
+dos slices que atienden los eventos de la otra, producen una cadena de eventos sin final. La cola
+de reducción se drena de forma **síncrona**, así que eso no es un programa lento: es una pestana
 congelada, o un core al 100%, sin error ni stack al que apuntar.
 
-Por eso cada evento lleva su posicion causal, y el store se niega a extender una cadena mas alla
+Por eso cada evento lleva su posición causal, y el store se niega a extender una cadena más allá
 de un tope:
 
 ```typescript
@@ -468,58 +569,95 @@ const store = createStore({
 });
 ```
 
-Un evento emitido mientras se atiende otro esta un nivel mas abajo que su causa, y lleva
-`parentId` y `depth` para que el ciclo sea legible despues. Ambos campos estan **ausentes** en un
-evento raiz, asi que los eventos que emite tu aplicacion siguen siendo identicos byte a byte.
+Un evento emitido mientras se atiende otro está un nivel más abajo que su causa, y lleva
+`parentId` y `depth` para que el ciclo sea legible después. Ambos campos están **ausentes** en un
+evento raíz, así que los eventos que emite tu aplicación siguen siendo idénticos byte a byte.
 
 Superar el tope no lanza. El emit ofensor se rechaza, lo ya confirmado se mantiene, y `onCascade`
-(mas un error en consola) lo nombra — lanzar apareceria en el suscriptor o efecto que casualmente
+(más un error en consola) lo nombra. Lanzar aparecería en el suscriptor o efecto que casualmente
 estuviera emitiendo, que es justo el fallo inatribuible que el tope existe para evitar.
 
 **Una rafaga ancha no es una cascada.** Un evento cuyo suscriptor emite quinientos hermanos es una
-forma legitima; la profundidad es lo que la distingue de un ciclo, y un bucle normal de
+forma legítima; la profundidad es lo que la distingue de un ciclo, y un bucle normal de
 `store.emit` nunca acumula profundidad. `maxTransitionsPerDrain` acota el *ancho* y por eso viene
 desactivado.
 
 ---
 
-## Deduplicacion de Eventos (opt-in)
+## Reducers Dinámicos
 
-La deduplicacion esta **desactivada por defecto** — yoltra nunca descarta en silencio eventos
-identicos legitimos y rapidos (doble-clics, `+1` repetidos). Actívala solo cuando de verdad quieras
-coalescer:
+Agrega o elimina slices de reducer en tiempo de ejecución:
 
 ```typescript
-// Por contenido: coalescer (channel, type, payload) identicos dentro de una ventana.
-const store = createStore({
-  name: "App",
-  reducer: {
-    /* ... */
-  },
-  dedupWindowMs: 100, // default: 0 (desactivado)
+const dispose = store.registerReducer("filters", {
+  state: { q: "" },
+  when: { keys: eventKeys<AppEM>()([["ui", "setQuery"]]) },
+  reducer: (state, event) => (event.type === "setQuery" ? { q: event.payload } : state),
 });
 
-// Por identidad: dedup por una clave explicita — p. ej. un doble-invoke de React Strict Mode en un efecto.
-await store.emit("analytics", "pageView", { page }, { dedupKey: `pageView:${page}` });
+// Despues: remover el slice y su estado
+dispose();
 ```
 
----
-
-## Reducers Dinamicos
+### Decorar un store, con sus tipos
 
-Agrega o elimina slices de reducer en tiempo de ejecucion:
+Una slice agregada en runtime era invisible para el sistema de tipos: `registerReducer`
+recibía un `string` y devolvía un disposer, así que nada aguas abajo sabía que la slice
+existía ni qué forma tenía. `withSlice` devuelve **el mismo store, re-tipado**:
 
 ```typescript
-const dispose = store.registerReducer("filters", {
-  state: { q: "" },
-  when: { keys: eventKeys<AppEM>()([["ui", "setQuery"]]) },
-  reducer: (state, event) => (event.type === "setQuery" ? { q: event.payload } : state),
+type TransferEM = { transfer: { granted: { id: string } } };
+
+const transfers = defineSlice<TransferEM>()({
+  state: { granted: [] as string[] },
+  when: { keys: [["transfer", "granted"]] },
+  reducer: (s, e) => (e.type === "granted" ? { granted: [...s.granted, e.payload.id] } : s),
 });
 
-// Despues: remover el slice y su estado
-dispose();
+const app = store.withSlice("transfers", transfers, { owner: "@scope/transfers" });
+
+app.getState().transfers.granted; // string[]
+app.emit("transfer", "granted", { id: "a1" }); // el canal nuevo ya es emitible
 ```
 
+`withMiddleware` y `withEffect` hacen lo mismo para el mapa de eventos. Las llamadas se
+encadenan, y una librería publica un decorador tomando un store y devolviendo otro:
+
+```typescript
+export function withTransfers<R extends string, S extends Record<R, any>, EM extends EventMapBase>(
+  store: StoreInstance<R, S, EM>,
+  config: TransfersConfig,
+) {
+  return store.withSlice("transfers", transfers, { owner: "@scope/transfers" });
+}
+
+// Los decoradores se anidan, en cualquier orden.
+const decorated = withTransfers(withDevtools(store, dtConfig), config);
+```
+
+**Por qué los builders.** El `when` de un spec lleva cadenas de canal y tipo, no tipos de
+payload, así que el mapa de eventos que aporta una decoración no puede inferirse de ahí, y
+TypeScript no tiene inferencia parcial de argumentos de tipo. `defineSlice<EM>()` lo coloca en
+posición de valor, donde la inferencia sí funciona, así que ningún sitio de registro necesita
+un argumento de tipo ni un cast. Una consecuencia que conviene conocer: **una función de
+middleware sin spec nunca puede ampliar el mapa de eventos**, porque el parámetro de evento de
+`MiddlewareFunction` es un tipo mapeado del que no se puede inferir nada de vuelta. Solo la
+forma de spec de `defineMiddleware` puede.
+
+**Es el mismo objeto.** Nada se vuelve a suscribir, ningún estado se mueve, y una llamada
+`store.call()` en vuelo no se ve afectada. Solo cambia el tipo.
+
+**Orden.** Decora en el ámbito del módulo, una vez, antes del primer render. Entre
+`createStore` y la decoración la slice realmente no existe, y un componente que la lea verá
+`undefined` hasta que exista.
+
+**Disposición.** `withSlice` no devuelve disposer a propósito: después de ejecutarlo, el tipo
+ampliado sigue prometiendo una slice que ya no está, y ningún sistema de tipos puede expresar
+"válido hasta esa llamada". Usa `registerSlice` cuando la slice sea tuya y necesites
+desmontarla, y mantén ese disposer privado a la librería. Leer una slice desmontada lanza un
+error con nombre en desarrollo, en lugar de devolver `undefined` desde un tipo que prometía un
+valor.
+
 ---
 
 ## Hot Module Replacement
@@ -548,26 +686,52 @@ if (import.meta.hot) {
 }
 ```
 
+### `replace*` reemplaza lo que tú escribiste, no lo que agregó una librería
+
+Un reducer, middleware o efecto registrado **después** de la construcción, con
+`registerReducer`, `registerMiddleware` o `registerEffect`, sobrevive a una llamada a
+`replace*`. Esos registros nunca formaron parte del conjunto que estás reemplazando: nadie que
+escribe `replaceReducers(myReducers)` quiere decir "y ademas borra la slice que montó devtools,
+junto con su estado".
+
+Antes ocurría lo contrario, lo que hacía que la línea de HMR de arriba borrara la slice de una
+librería y su estado al primer guardado de archivo, sin error y sin advertencia. Es también la
+razón por la que una llamada `store.call()` en vuelo ya no muere a mitad de recarga: su
+listener de respuesta pertenece al propio store.
+
+Pasa `{ scope: "all" }` para el comportamiento anterior, que un arnés de pruebas que reinicia un
+store entre casos sí puede querer:
+
+```typescript
+store.replaceReducers(nextReducers, { scope: "all" });
+store.hotReplace({ reducer: nextReducers, scope: "all" }); // se reenvía a los tres
+```
+
+Una aplicación que declara una slice que una librería ya montó recibe un error que nombra la
+slice, en lugar de una apropiación silenciosa que deja a la librería con un disposer de algo que
+ya no es suyo. En desarrollo, `replace*` registra en nivel debug cuando preservó algo, así que
+"por qué sigue disparándose ese efecto tras la recarga" tiene respuesta.
+
 ---
 
-## Mejores Practicas
+## Mejores Prácticas
 
-### El estado es sincrono; haz `await` solo por los efectos
+### El estado es síncrono; haz `await` solo por los efectos
 
-La fase de reduccion es sincrona, asi que el estado refleja tu evento en el instante en que `emit()`
-retorna — sin `await` para leerlo. Haz `await` de `emit()` cuando ademas quieras que los efectos de
+La fase de reducción es síncrona, así que el estado refleja tu evento en el instante en que `emit()`
+retorna, sin `await` para leerlo. Haz `await` de `emit()` cuando además quieras que los efectos de
 _ese evento_ hayan terminado:
 
 ```typescript
 emit("todo", "add", todo);
-store.getState(); // Ya refleja la nueva tarea — sin await
+store.getState(); // Ya refleja la nueva tarea. Sin await
 
 await emit("todo", "save", todo); // se resuelve cuando terminan los efectos de save
 ```
 
-### Mantener los reducers rapidos
+### Mantener los reducers rápidos
 
-Los reducers son sincronos y corren en el mismo tick que `emit()`. Mueve el trabajo costoso a los
+Los reducers son síncronos y corren en el mismo tick que `emit()`. Mueve el trabajo costoso a los
 efectos:
 
 ```typescript
@@ -600,96 +764,227 @@ store.registerEffect({
 
 ## Resumen de API
 
-### Creacion del Store
+### Creación del Store
 
-| API                                             | Descripcion                                           |
+| API                                             | Descripción                                           |
 | ----------------------------------------------- | ----------------------------------------------------- |
 | `createStore(spec)`                             | Crear un store (tipos inferidos de los reducers)      |
-| `createStore<S, EM>(spec)`                      | Crear un store con tipos de estado/eventos explicitos |
+| `createStore<S, EM>(spec)`                      | Crear un store con tipos de estado/eventos explícitos |
 | `store.emit(channel, type, payload)`            | Emitir un evento (retorna una promesa)                |
 | `store.getState()`                              | Obtener snapshot del estado actual (solo lectura)     |
-| `store.subscribe(listener)`                     | Suscripcion gruesa (cualquier cambio de estado)       |
-| `store.connect(spec, handler)`                  | Suscripcion de grano fino por ruta con wildcards      |
-| `store.onEvent(channel, type, handler, phase?)` | Suscripcion a eventos (committed/uncommitted/all)     |
+| `store.subscribe(listener)`                     | Suscripción gruesa (cualquier cambio de estado)       |
+| `store.connect(spec, handler)`                  | Suscripción de grano fino por ruta con wildcards      |
+| `store.onEvent(channel, type, handler, phase?, options?)` | Suscripción a eventos (committed/uncommitted/written/all). Silenciosa durante el replay salvo `{ duringReplay: true }` |
+| `store.onRegistrationChange(observer, opts?)` | Avisa cuando el store gana o pierde un reducer, middleware o efecto |
 | `store.onEffect(channel, type, handler)`        | Shorthand de efecto para un solo evento               |
 | `store.dispose()`                               | Limpiar timers y recursos                             |
 
-### Registro Dinamico
+### Registro Dinámico
 
-| API                                 | Descripcion                               |
+| API                                 | Descripción                               |
 | ----------------------------------- | ----------------------------------------- |
-| `store.registerReducer(name, spec)` | Agregar un slice en tiempo de ejecucion   |
-| `store.registerMiddleware(fn)`      | Agregar middleware en tiempo de ejecucion |
-| `store.registerEffect(spec)`        | Agregar un efecto en tiempo de ejecucion  |
+| `store.registerSlice(name, spec, opts?)` | Agrega un slice en runtime; devuelve el store re-tipado y un disposer |
+| `store.withSlice(name, spec, opts?)` | Igual, devolviendo el store re-tipado para encadenar |
+| `store.withMiddleware(mw)`, `store.withEffect(spec)` | Registra y amplía el mapa de eventos |
+| `defineSlice<EM>()`, `defineMiddleware<EM>()`, `defineEffect<EM>()` | Declara el mapa de eventos que aporta un spec |
+| `store.registerReducer(name, spec)` | Agregar un slice en tiempo de ejecución   |
+| `store.registerMiddleware(fn)`      | Agregar middleware en tiempo de ejecución |
+| `store.registerEffect(spec)`        | Agregar un efecto en tiempo de ejecución  |
 
 ### HMR
 
-| API                                     | Descripcion                                 |
+| API                                     | Descripción                                 |
 | --------------------------------------- | ------------------------------------------- |
-| `store.replaceReducers(reducers, opts)` | Reemplazar todos los reducers               |
-| `store.replaceMiddleware(middleware)`   | Reemplazar todos los middleware             |
-| `store.replaceEffects(effects)`         | Reemplazar todos los efectos                |
-| `store.hotReplace(partial)`             | Reemplazar cualquier subconjunto de una vez |
+| `store.replaceReducers(reducers, opts)`     | Reemplaza los reducers del spec; los de runtime sobreviven salvo `{ scope: "all" }` |
+| `store.replaceMiddleware(middleware, opts)` | Reemplaza el middleware del spec; misma regla |
+| `store.replaceEffects(effects, opts)`       | Reemplaza los efectos del spec; misma regla   |
+| `store.hotReplace(partial)`                 | Reemplaza cualquier subconjunto; reenvía `scope` |
 
 ### Helpers
 
-| API                      | Descripcion                                                      |
+| API                      | Descripción                                                      |
 | ------------------------ | ---------------------------------------------------------------- |
 | `eventKeys<EM>()([...])` | Arrays de claves de evento con seguridad de tipos sin `as const` |
 
 ---
 
+## Guardar y restaurar estado
+
+Dos funciones, porque las dos mitades ocurren en lados opuestos de la existencia del store.
+`hydrate` produce el *estado inicial de las slices*, así que el store nace con él:
+
+```ts
+import { createStore, createWebStorageAdapter, hydrate, persist, withHydration } from '@yoltra/core';
+
+const adapter = createWebStorageAdapter(localStorage);
+const hydration = await hydrate({ key: 'app', adapter, version: 3 });
+
+const store = createStore({
+  name: 'App',
+  reducer: withHydration({ todos: todosSpec, ui: uiSpec }, hydration),
+});
+
+const stop = persist(store, { key: 'app', adapter, version: 3, slices: ['todos'] });
+```
+
+Restaurar *después* de construir es la alternativa obvia y la equivocada: aplicar una
+instantánea a un store vivo emite un cambio en todas las rutas, lo que en el arranque es un
+parpadeo, una ráfaga de entradas de instrumentación que describen cambios que nadie hizo, y
+efectos observando una transición que nunca ocurrió.
+
+**Nada lanza en el arranque.** Un payload ausente, ilegible o no migrable recae en los valores
+por defecto que declaraste y se reporta por `onError`. Un store que no arranca porque el
+almacenamiento guarda JSON obsoleto es peor que uno que arranca de cero, y un disco lleno no
+debería tumbar una página, así que los fallos de escritura se reportan igual en vez de lanzarse.
+
+**Las versiones que no coinciden se rechazan, no se asumen.** Los reducers cambian, y una
+instantánea escrita contra una forma anterior puede no ser estado válido para este build en
+absoluto. Aporta `migrate` para actualizarla, o se descarta.
+
+Las escrituras las dirige la instrumentación, así que un cambio confinado a una slice que no
+estás persistiendo no cuesta nada, y una ráfaga se agrupa en una sola escritura. `Map`, `Set`,
+`Date`, `BigInt`, `undefined` y las referencias circulares sobreviven al viaje de ida y vuelta:
+`JSON.stringify` no falla con eso, los destruye en silencio.
+
+Para un render en servidor, `dehydrate(store, { version })` produce el payload y
+`hydrate({ source, version })` lo consume.
+
+---
+
+## Listas que se reordenan
+
+La notificación por ruta es posicional para los arrays. `items.0.title` nombra un *hueco*, no
+una cosa, así que `unshift`, `splice(0, 1)` y `sort` mueven casi todos los elementos a un hueco
+distinto, y el diff reporta correctamente que casi todas las hojas cambiaron. Insertar una fila
+al principio de mil despierta a mil suscriptores.
+
+Eso es honesto en vez de ruidoso: con rutas posicionales el valor de casi cada índice cambió de
+verdad. El remedio es la forma del estado, no un diff que se calle.
+
+```ts
+import { createEntityAdapter } from '@yoltra/core';
+
+const todos = createEntityAdapter<Todo>();
+
+// state is { ids: [...], entities: { abc: {...} } }
+todos.updateOne(state, { id: 'abc', changes: { done: true } });
+
+// and the adapter hands out the paths, so they are never typed by hand
+todos.pathTo('abc', 'title');  // "entities.abc.title"
+todos.idsPath;                 // "ids"
+```
+
+`entities.abc.title` sobrevive a insertar, eliminar y reordenar. Un contenedor de lista se
+suscribe a `ids` y reordena sus hijos; las filas se suscriben a su propia entidad y siguen
+dormidas durante un `sort`.
+
+`ids` sigue siendo un array, así que un reordenamiento todavía reporta `ids.0`, `ids.1` y así
+sucesivamente. Ese costo queda confinado, no eliminado. Lo que ganas es un costo proporcional a
+lo que realmente cambió.
+
+Para una lista pequeña que solo crece por el final, `items.0.title` está bien y es más simple.
+El adapter es para colecciones que se reordenan, o que son lo bastante grandes como para que la
+diferencia se note.
+
+### Lo que cuesta, medido
+
+Con 1000 filas, hacer el diff después de una inserción al principio cuesta 1200 µs para un array
+y 371 µs normalizado, y el array reporta alrededor de mil rutas cambiadas frente a dos. Ese es
+el caso para el que existe el adapter.
+
+Una actualización de un solo campo va al revés: 20 µs para el array frente a 470 µs normalizado.
+`detectChangedProps` indexa un array pero enumera las claves de un objeto, construyendo dos
+arrays de claves y un `Set` por comparación, así que un mapa de entidades ancho es más caro de
+recorrer aunque casi nada dentro se haya movido. Los números están en `benchmarks/`, y cerrar
+esa brecha es trabajo con seguimiento, no una propiedad de normalizar como tal.
+
+Así que: normaliza las colecciones que se reordenan o que rotan mucho. Una colección grande a la
+que solo se le editan campos individuales está mejor como array hoy.
+
+---
+
 ## Rendimiento
 
-| Metrica               | Valor                                       |
-| --------------------- | ------------------------------------------- |
-| **Tamano del bundle** | 9.2 KB para el store (minificado + gzipped) |
-| **Tree-shakeable**    | Si (modulos ES)                             |
-| **Dependencias**      | Cero                                        |
-| **TypeScript**        | Definiciones de tipos completas incluidas   |
+| Métrica               | Valor                                     |
+| --------------------- | ----------------------------------------- |
+| **Tamaño del bundle** | Medido en cada build, ver la tabla abajo |
+| **Tree-shakeable**    | Sí (módulos ES)                           |
+| **Dependencias**      | Cero                                      |
+| **TypeScript**        | Definiciones de tipos completas incluidas |
+
+El tamaño del bundle se verifica, no se afirma: `rush size` empaqueta el paquete como lo haría
+un consumidor (sacudido, minificado, comprimido con gzip) y falla cuando excede el
+presupuesto declarado en `package.json`. La tabla de abajo la escribe esa misma verificación,
+así que no puede desviarse de lo que se midió; editarla a mano hace fallar el CI.
+
+La cifra que importa es lo que importas, no lo que el paquete exporta:
+
+<!-- size-table:start -->
+| Import | Tamaño | Presupuesto |
+| --- | --- | --- |
+| `{ createStore }` | 11.5 KB | 14 KB |
+| `{ createStore, hydrate, persist }` | 12.8 KB | 16 KB |
+| todo | 14.2 KB | 18 KB |
+<!-- size-table:end -->
+
+Estas son cifras de **producción**: lo que públicas una vez que tu empaquetador define
+`NODE_ENV=production` y las guardas exclusivas de desarrollo desaparecen. La columna de
+presupuesto es el techo que `rush size` impone, y se verifica contra un build de desarrollo,
+que es el mayor de los dos: el código exclusivo de desarrollo no puede crecer sin que nadie lo
+note solo porque nunca llega a un usuario. Por eso el margen que se infiere aquí es
+deliberadamente conservador.
+
+La **distancia entre filas** es la afirmación de tree-shaking, y es lo que hay que vigilar: la
+persistencia añade 1.5 KB a quienes la importan y nada a los demás, y el barrel completo está
+2.9 KB por encima del store. La última fila es un detector de crecimiento; `import * as all` no
+es algo que nadie escriba.
 
 ---
 
-## Documentacion
+## Documentación
 
-- **[README raiz de yoltra](../../README.md)** --
-  Descripcion general y configuracion rapida
-- **[@yoltra/react](../react/README.md)** --
+- **[README raíz de yoltra](../../README.md)**:
+  Descripción general y configuración rápida
+- **[@yoltra/react](../react/README.md)**:
   Hooks de React y Suspense
-- **[Guia de Inicio Rapido](https://github.com/yoltra/yoltra/blob/main/docs/en/QUICK_START_GUIDE.md)**
-  -- Cinco pasos hacia una app funcional
-- **[Arquitectura de Cola de Eventos](https://github.com/yoltra/yoltra/blob/main/docs/en/design/event-queue-architecture.md)**
-  -- Inmersion tecnica profunda
-- **[Comparacion de Bibliotecas](https://github.com/yoltra/yoltra/blob/main/docs/en/design/state-management-library-comparison.md)**
-  -- Comparacion arquitectonica
+- **[Guia de Inicio Rápido](https://github.com/yoltra/yoltra/blob/main/docs/en/QUICK_START_GUIDE.md)**:
+  Cinco pasos hacia una app funcional
+- **[Actualizar a 0.8.0](https://github.com/yoltra/yoltra/blob/main/docs/es/UPGRADE_0.8.md)**:
+  Cinco cambios de comportamiento, y un riesgo si haces rollback
+- **[Guía de Decoración](https://github.com/yoltra/yoltra/blob/main/docs/es/DECORATION_GUIDE.md)**:
+  Agregar una slice, middleware o efecto al store de alguien más, con los tipos
+- **[Arquitectura de Cola de Eventos](https://github.com/yoltra/yoltra/blob/main/docs/en/design/event-queue-architecture.md)**:
+  Inmersión técnica profunda
+- **[Comparación de Bibliotecas](https://github.com/yoltra/yoltra/blob/main/docs/en/design/state-management-library-comparison.md)**:
+  Comparación arquitectónica
 
 ---
 
 ## Ejemplos
 
-- **[App de Tareas](https://github.com/yoltra/yoltra/blob/main/examples/v0/yoltra-in-react)** --
+- **[App de Tareas](https://github.com/yoltra/yoltra/blob/main/examples/v0/yoltra-in-react)**:
   CRUD completo con perfilado de rendimiento · [▶ Abrir la demo en vivo](https://yoltra.dev/es/demos/in-react)
-- **[Logo Cinetico](https://github.com/yoltra/yoltra/blob/main/examples/v0/yoltra-kinetic-logo)**
-  -- 3000 círculos con simulación física. · [▶ Abrir la demo en vivo](https://yoltra.dev/es/demos/kinetic-logo)
-- **[Integracion con Next.js](https://github.com/yoltra/yoltra/blob/main/examples/v0/yoltra-in-nextjs)**
-  -- Pages Router, estado de cliente + cambio de tema · [▶ Abrir la demo en vivo](https://yoltra.dev/es/demos/in-nextjs)
+- **[Logo Cinético](https://github.com/yoltra/yoltra/blob/main/examples/v0/yoltra-kinetic-logo)**:
+  3000 círculos con simulación física. · [▶ Abrir la demo en vivo](https://yoltra.dev/es/demos/kinetic-logo)
+- **[Integración con Next.js](https://github.com/yoltra/yoltra/blob/main/examples/v0/yoltra-in-nextjs)**:
+  Pages Router, estado de cliente + cambio de tema · [▶ Abrir la demo en vivo](https://yoltra.dev/es/demos/in-nextjs)
 
 ---
 
 ## Contribuir
 
-- [Raiz del Monorepo](../../README.md)
-- [Guia de Contribucion](https://github.com/yoltra/yoltra/blob/main/CONTRIBUTING.md)
+- [Raíz del Monorepo](../../README.md)
+- [Guia de Contribución](https://github.com/yoltra/yoltra/blob/main/CONTRIBUTING.md)
 
 ---
 
 ## Estado
 
-**Release Candidate** -- Las APIs son estables, usadas en produccion, cambios menores posibles
+**Release Candidate**. Las APIs son estables, usadas en producción, cambios menores posibles
 antes de v1.0.0.
 
 ---
 
 ## Licencia
 
-**MIT** -- Libre para usar en proyectos comerciales y de codigo abierto.
+**MIT**. Libre para usar en proyectos comerciales y de código abierto.