syntropylog 0.9.2 → 0.9.4

package/CHANGELOG.md

@@ -5,6 +5,22 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.9.4] - 2026-03-07
+
+### 🔧 Maintenance
+- **Security**: Excluded `docs/` folder from npm package to resolve false positive security alerts in Socket.dev regarding example URLs.
+
+## [0.9.3] - 2026-03-07
+
+### 📝 Documentation
+- **README intro**: Added to the "What is SyntropyLog?" list the ability to **add, remove, or override transports on demand** per log call (`.override()`, `.add()`, `.remove()`), without creating new logger instances.
+- **package.json**: Added `funding` field for open-source visibility.
+
+### 🔧 Maintenance
+- No breaking changes. Patch release for documentation and second publication.
+
+---
+
 ## [0.9.2] - 2026-03-04
 
 ### ⚠️ Breaking changes

package/README.md

@@ -17,7 +17,7 @@
   <a href="https://github.com/Syntropysoft/SyntropyLog/blob/main/LICENSE"><img src="https://img.shields.io/npm/l/syntropylog.svg" alt="License"></a>
   <a href="https://github.com/Syntropysoft/SyntropyLog/actions/workflows/ci.yaml"><img src="https://github.com/Syntropysoft/SyntropyLog/actions/workflows/ci.yaml/badge.svg" alt="CI Status"></a>
   <a href="#"><img src="https://img.shields.io/badge/coverage-84.64%25-brightgreen" alt="Test Coverage"></a>
-  <a href="#"><img src="https://img.shields.io/badge/status-v0.9.2-brightgreen.svg" alt="Version 0.9.2"></a>
+  <a href="#"><img src="https://img.shields.io/badge/status-v0.9.3-brightgreen.svg" alt="Version 0.9.3"></a>
   <a href="https://socket.dev/npm/package/syntropylog"><img src="https://socket.dev/api/badge/npm/package/syntropylog" alt="Socket Badge"></a>
 </p>
 
@@ -32,6 +32,7 @@ The core idea is simple: **you declare what your logs should carry, and Syntropy
 That means:
 - A **declarative Logging Matrix** that controls exactly which context fields appear at each log level — lean on `info`, full context on `error`.
 - A **fluent logger API** (`withRetention`, `withSource`, `withTransactionId`) that lets you create specialized loggers carrying arbitrary organization-defined metadata.
+- **Add, remove, or override transports on demand** — per log call you can send only to specific transports (`.override()`), add extra destinations (`.add()`), or drop one (`.remove()`), without creating new logger instances.
 - A **MaskingEngine** that redacts sensitive fields before they reach any transport — built-in strategies and fully custom rules.
 - An **Intelligent Serialization Pipeline** that automatically detects and neutralizes circular references, limits object depth, and enforces execution timeouts — making logs immune to application crashes.
 - A **UniversalAdapter** that routes logs to any backend (PostgreSQL, MongoDB, Elasticsearch, S3) via a single `executor` function — no coupling, no lock-in.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "syntropylog",
-  "version": "0.9.2",
+  "version": "0.9.4",
   "engines": {
     "node": ">=20.0.0"
   },
@@ -112,7 +112,6 @@
   "files": [
     "dist",
     "assets",
-    "docs",
     "LICENSE",
     "README.md",
     "CHANGELOG.md",
@@ -123,10 +122,44 @@
     "examples/*",
     "modules/@syntropylog/types"
   ],
+  "scripts": {
+    "example:transport-pool": "npx tsx examples/TransportPoolExample.ts",
+    "setup": "node scripts/setup-env.js",
+    "build": "npm run clean && npm run build:types && rollup -c",
+    "build:types": "tsc -p src/tsconfig.json",
+    "dev": "rollup -c -w",
+    "clean": "rm -rf dist",
+    "lint": "eslint . --fix",
+    "format": "prettier --write \"src/**/*.ts\"",
+    "test": "vitest --run --reporter=verbose --config vitest.config.mjs",
+    "test:coverage": "vitest run --coverage --config vitest.config.mjs",
+    "test:integration": "vitest run -c vitest.integration.config.mjs",
+    "test:all": "npm test && npm run test:integration",
+    "check:deps": "depcheck",
+    "prepublishOnly": "npm run build",
+    "prepare": "husky",
+    "changeset": "changeset",
+    "version-packages": "changeset version",
+    "release": "npm run build && changeset publish",
+    "version:patch": "npm version patch",
+    "version:minor": "npm version minor",
+    "version:major": "npm version major",
+    "version:alpha": "npm version prerelease --preid=alpha",
+    "version:beta": "npm version prerelease --preid=beta",
+    "version:rc": "npm version prerelease --preid=rc",
+    "publish:alpha": "./scripts/release-alpha.sh patch",
+    "publish:alpha:minor": "./scripts/release-alpha.sh minor",
+    "publish:alpha:major": "./scripts/release-alpha.sh major",
+    "publish:stable": "npm run test:all && npm run build && npm publish",
+    "release:alpha": "./scripts/release-alpha.sh"
+  },
   "repository": {
     "type": "git",
     "url": "git+https://github.com/Syntropysoft/SyntropyLog.git"
   },
+  "funding": {
+    "url": "https://github.com/Syntropysoft/SyntropyLog"
+  },
   "publishConfig": {
     "access": "public"
   },
@@ -162,7 +195,8 @@
     "tslib": "^2.8.1",
     "typescript": "^5.7.3",
     "typescript-eslint": "8.56.1",
-    "vitest": "^4.0.18"
+    "vitest": "^4.0.18",
+    "@changesets/cli": "^2.27.1"
   },
   "peerDependencies": {
     "chalk": "^5.4.1",
@@ -178,31 +212,5 @@
   },
   "lint-staged": {
     "src/**/*.ts": "eslint --fix --max-warnings=0"
-  },
-  "scripts": {
-    "example:transport-pool": "npx tsx examples/TransportPoolExample.ts",
-    "setup": "node scripts/setup-env.js",
-    "build": "npm run clean && npm run build:types && rollup -c",
-    "build:types": "tsc -p src/tsconfig.json",
-    "dev": "rollup -c -w",
-    "clean": "rm -rf dist",
-    "lint": "eslint . --fix",
-    "format": "prettier --write \"src/**/*.ts\"",
-    "test": "vitest --run --reporter=verbose --config vitest.config.mjs",
-    "test:coverage": "vitest run --coverage --config vitest.config.mjs",
-    "test:integration": "vitest run -c vitest.integration.config.mjs",
-    "test:all": "npm test && npm run test:integration",
-    "check:deps": "depcheck",
-    "version:patch": "npm version patch",
-    "version:minor": "npm version minor",
-    "version:major": "npm version major",
-    "version:alpha": "npm version prerelease --preid=alpha",
-    "version:beta": "npm version prerelease --preid=beta",
-    "version:rc": "npm version prerelease --preid=rc",
-    "publish:alpha": "./scripts/release-alpha.sh patch",
-    "publish:alpha:minor": "./scripts/release-alpha.sh minor",
-    "publish:alpha:major": "./scripts/release-alpha.sh major",
-    "publish:stable": "npm run test:all && npm run build && npm publish",
-    "release:alpha": "./scripts/release-alpha.sh"
   }
 }

package/docs/ANALISIS_TIMEOUT_SERIALIZATION.md

@@ -1,127 +0,0 @@
-# Análisis: Timeouts en el pipeline de serialización
-
-Documento de análisis para revisar cómo se usan los timeouts (config vs. estrategias) y si el código de `selectTimeoutStrategy` / estrategias por tipo de dato sigue teniendo sentido.
-
----
-
-## 1. Dónde está el timeout que **sí** limita la ejecución
-
-El único lugar que **corta** la ejecución por tiempo es el loop del pipeline en `SerializationPipeline.process()`:
-
-```ts
-// SerializationPipeline.ts, ~línea 55-79
-const globalTimeout = context?.serializationContext?.timeoutMs || 50;
-
-for (const step of this.steps) {
-  const stepExecution = step.execute(currentData, context);
-  const timeoutPromise = new Promise<SerializableData>((_, reject) => {
-    setTimeout(() => reject(new Error(`Timeout in step '${step.name}' (> ${globalTimeout}ms)`)), globalTimeout);
-  });
-  currentData = await Promise.race([stepExecution, timeoutPromise]);
-}
-```
-
-- **Origen del valor:** `context.serializationContext.timeoutMs` (si no viene, se usa **50 ms**).
-- **Efecto:** Cada step (serialization, hygiene, sanitization, timeout) tiene como máximo `globalTimeout` ms; si se pasa, se rechaza la promesa y el pipeline devuelve `success: false` con el error.
-- **Conclusión:** Cualquier serializador (o step) corre dentro de este límite; el que “manda” es este `globalTimeout`.
-
----
-
-## 2. De dónde sale `serializationContext` y si lleva `timeoutMs`
-
-Flujo actual:
-
-1. **Config de la app:** `logger.serializerTimeoutMs` (en `config.schema.ts`, default **50**).
-2. **LifecycleManager** crea `SerializationManager` con:
-   - `timeoutMs: this.config.logger?.serializerTimeoutMs`
-   → queda en `SerializationManager.config.timeoutMs`.
-3. **LoggerFactory** también crea un `SerializationManager` con:
-   - `timeoutMs: config.logger?.serializerTimeoutMs`
-   → mismo valor en `SerializationManager.config.timeoutMs`.
-4. Cuando el **Logger** hace un log, llama a:
-   ```ts
-   this.dependencies.serializationManager.serialize(logEntry, {
-     depth: 0,
-     maxDepth: 10,
-     sensitiveFields: [],
-     sanitize: true,
-   });
-   ```
-   Ese segundo argumento es el `context` (SerializationContextConfig). **No incluye `timeoutMs`**.
-5. **SerializationManager.serialize()** arma el contexto del pipeline así:
-   ```ts
-   const pipelineContext: SerializationPipelineContext = {
-     serializationContext: context,  // el que pasó el Logger (sin timeoutMs)
-     sanitizeSensitiveData: this.config.sanitizeSensitiveData,
-     ...
-   };
-   ```
-   No inyecta `this.config.timeoutMs` en `serializationContext`.
-
-**Consecuencia:** El pipeline siempre recibe `serializationContext.timeoutMs === undefined` y usa el fallback **50 ms**. El valor de `logger.serializerTimeoutMs` de la config **no llega** al pipeline en el flujo actual del Logger.
-
-Para que “cualquier serializador respete el timeout de la configuración”, habría que pasar ese valor al pipeline, por ejemplo:
-- que el Logger pase `timeoutMs` en el context (leyéndolo de algún sitio que tenga la config), o
-- que `SerializationManager.serialize()` complete `serializationContext` con `timeoutMs: this.config.timeoutMs` cuando el caller no lo envíe.
-
----
-
-## 3. Qué hace `operationTimeout` y `selectTimeoutStrategy` (no limitan ejecución)
-
-Después del loop de steps, el pipeline hace:
-
-```ts
-const timeoutStrategy = this.selectTimeoutStrategy(currentData);
-const operationTimeout = timeoutStrategy.calculateTimeout(currentData);
-this.metrics.operationTimeout = operationTimeout;
-this.metrics.timeoutStrategy = timeoutStrategy.getStrategyName();
-// y se mete en result.metadata
-```
-
-- **`selectTimeoutStrategy(data)`:** Siempre usa **DefaultTimeoutStrategy** (5000 ms). Los adaptadores por tipo (Prisma, TypeORM, MySQL, etc.) se eliminaron; solo queda la estrategia `default`.
-- **`operationTimeout`:** Es un número que se escribe en **métricas y metadata** (p. ej. “recomendación” de timeout para esa operación). **No se usa** para hacer `Promise.race` ni para cortar ningún step.
-- **`timeoutStrategy`:** Nombre de la estrategia usada, también solo metadata (métricas, `timeoutStrategyDistribution`). En el código actual siempre es `default`.
-
-Es decir: todo esto es **informativo**. El límite real de ejecución sigue siendo solo `globalTimeout` (derivado de `serializationContext.timeoutMs` o 50 ms).
-
----
-
-## 4. Estrategia de timeout en el pipeline
-
-El pipeline usa **una única estrategia de timeout**: **DefaultTimeoutStrategy** (nombre `default`, 5000 ms). No existe ya selección por `data.type`; los adaptadores por tipo (Prisma, TypeORM, MySQL, PostgreSQL, SQL Server, Oracle) se eliminaron. Todo el flujo (Logger, log entry, metadata, etc.) usa siempre la estrategia `default`.
-
----
-
-## 5. TimeoutStep (step “timeout”)
-
-- Recibe el `Map` de estrategias del pipeline (`this.pipeline['timeoutStrategies']`).
-- En su `execute()` hace su propio `selectTimeoutStrategy(data)` y añade al dato:
-  - `operationTimeout`, `timeoutStrategy`, `timeoutDuration`, `timeoutApplied`, etc.
-- Tampoco aplica ningún límite de tiempo a la ejecución; solo **anota metadata** en el objeto que circula por el pipeline. El límite real sigue siendo el `Promise.race` con `globalTimeout` en el pipeline.
-
----
-
-## 6. Resumen y conclusiones
-
-| Concepto | Dónde está | Efecto real |
-|----------|------------|-------------|
-| **Timeout que limita** | `SerializationPipeline.process()` → `globalTimeout = context.serializationContext?.timeoutMs \|\| 50` | Máximo tiempo por step; cualquier serializador está acotado por este valor. |
-| **Config del usuario** | `logger.serializerTimeoutMs` (default 50) | Se guarda en `SerializationManager.config.timeoutMs` pero **no se inyecta** en el context que recibe el pipeline cuando el Logger llama a `serialize()`. |
-| **operationTimeout / timeoutStrategy** | Calculados con `selectTimeoutStrategy()` → siempre `default` | Solo **metadata y métricas**. No controlan ni cortan la ejecución. |
-| **Estrategia de timeout** | Solo **DefaultTimeoutStrategy** (`default`, 5000 ms) | Los adaptadores por tipo (Prisma, TypeORM, MySQL, etc.) se eliminaron. |
-
-Conclusiones para decidir qué hacer:
-
-1. **Que el serializador respete el timeout de configuración:** Hoy no ocurre del todo, porque `serializerTimeoutMs` no llega al pipeline. Habría que conectar `config.timeoutMs` (o equivalente) con `serializationContext.timeoutMs` en las llamadas a `serialize()` (p. ej. en SerializationManager o en el Logger).
-2. **selectTimeoutStrategy:** Simplificado a “siempre default”. No hay estrategias por tipo; solo **DefaultTimeoutStrategy**.
-3. **Estado del código:** Eliminadas las estrategias por adaptador (Prisma, TypeORM, MySQL, PostgreSQL, SQL Server, Oracle); solo queda la estrategia `default`.
-
----
-
-## 7. Referencias rápidas de código
-
-- Timeout que limita: `src/serialization/SerializationPipeline.ts` (~líneas 55–79).
-- Selector de estrategia: `src/serialization/SerializationPipeline.ts` ~`selectTimeoutStrategy`, `initializeDefaultStrategies`, `DefaultTimeoutStrategy` (única estrategia).
-- Context del pipeline: `src/serialization/SerializationManager.ts` ~`serialize()` (construcción de `pipelineContext`).
-- Llamada desde el Logger: `src/logger/Logger.ts` ~`_log()` → `serializationManager.serialize(logEntry, { depth, maxDepth, sensitiveFields, sanitize })`.
-- Config: `config.schema.ts` `serializerTimeoutMs`; `LifecycleManager` / `LoggerFactory` donde se crea `SerializationManager` con `timeoutMs`.

package/docs/IMPROVEMENT_OPPORTUNITIES.md

@@ -1,84 +0,0 @@
-# Oportunidades de mejora — SyntropyLog
-
-Documento generado a partir de una revisión del código para usar como backlog o como base para issues en GitHub.
-
----
-
-## 1. Consistencia de idioma (prioridad alta) ✅ Hecho (v0.9.2)
-
-Implementado en v0.9.2:
-
-El proyecto está documentado en inglés (README, JSDoc, mensajes de usuario), pero hay comentarios y mensajes de error en español en el pipeline de serialización.
-
-| Ubicación | Actual | Sugerencia |
-|-----------|--------|------------|
-| `src/serialization/SerializationPipeline.ts` | `Timeout en etapa '${step.name}' (> ${globalTimeout}ms)` | `Timeout in step '${step.name}' (> ${globalTimeout}ms)` |
-| `src/serialization/SerializationPipeline.ts` | Comentarios "Ejecutar pasos", "Carrera de mates", "Seleccionar estrategia..." | Traducir a inglés |
-| `src/serialization/pipeline/TimeoutStep.ts` | `'Error en timeout'` | `'Timeout error'` |
-| `src/serialization/pipeline/TimeoutStep.ts` | Comentarios "Seleccionar estrategia...", "Calcular timeout..." | Traducir a inglés |
-
-**Beneficio:** Consistencia para contribuidores y usuarios que esperan mensajes en inglés; mejor experiencia en entornos internacionales.
-
----
-
-## 2. ~~TODO pendiente: `BeaconRedis.multi()`~~ ✅ Hecho (v0.9.2)
-
-Implementado en v0.9.2:
-
-- `RedisCommandExecutor.multi()` devuelve la transacción nativa del cliente.
-- `BeaconRedis.multi()` devuelve una `BeaconRedisTransaction` que envuelve la transacción nativa; todos los comandos encolables están delegados y `exec()` / `discard()` pasan por `_executeCommand` (logging, timing, errores).
-- `executeScript` dentro de una transacción no está soportado y lanza un error claro.
-- Tests añadidos: transacción retornada por `multi()`, instrumentación de `exec()` y `discard()`.
-
----
-
-## 3. Tipado y uso de `as any`
-
-En `SerializationPipeline.ts`, al construir el resultado se usa `(currentData as any)` para `serializer`, `serializationComplexity`, etc. (aprox. líneas 98, 106-107, 112-113).
-
-**Sugerencia:** Definir un tipo (por ejemplo `SerializableDataWithMeta`) que extienda `SerializableData` con campos opcionales como `serializer`, `serializationComplexity`, y usarlo en lugar de `as any`. Así se mantiene type-safety y se documenta la forma del dato en ese punto del pipeline.
-
----
-
-## 4. Tests y cobertura
-
-- Hay buena cobertura de tests unitarios (README indica ~84.64%).
-- `BeaconRedis.multi()` está cubierto (se espera que lance).
-- Los tests de integración viven en `test_integration/`.
-
-**Posibles mejoras:**
-
-- Añadir tests que fuercen timeout en el pipeline (pasos lentos) para validar mensajes de error y que no se pierdan datos críticos.
-- Revisar si hay ramas de `LifecycleManager` (por ejemplo init con/sin HTTP, con/sin brokers) sin cubrir.
-
----
-
-## 5. Documentación y DX
-
-- README y docs en `docs/` están muy completos.
-- **Sugerencia:** En la sección de Redis del README (o en una guía de Redis), mencionar que `multi()` no está implementado en el cliente real y que para transacciones en tests se use `BeaconRedisMock`.
-
----
-
-## 6. Seguridad y mantenimiento (ya abordados recientemente)
-
-Por el CHANGELOG (0.9.1, 0.8.13):
-
-- Código ofuscado eliminado en el módulo Redis.
-- `executeScript` refactorizado para evitar falsos positivos de "eval" en scanners.
-
-**Sugerencia:** Mantener esta línea en futuros cambios (evitar patrones que puedan disparar alertas de seguridad sin necesidad).
-
----
-
-## 7. Resumen de acciones sugeridas
-
-| # | Acción | Esfuerzo | Impacto |
-|---|--------|----------|---------|
-| 1 | Unificar mensajes y comentarios a inglés en serialization pipeline y TimeoutStep | Bajo | Consistencia, profesionalismo |
-| 2 | Decidir e implementar o documentar `BeaconRedis.multi()` | Medio/Alto | Completitud de API Redis |
-| 3 | Reemplazar `as any` por tipos explícitos en `SerializationPipeline` | Bajo | Type-safety, mantenibilidad |
-| 4 | Tests de timeout en pipeline y revisión de cobertura de LifecycleManager | Medio | Confiabilidad |
-| 5 | Documentar limitación de `multi()` en README o guía Redis | Bajo | DX |
-
-Si querés, el siguiente paso puede ser implementar el punto 1 (mensajes y comentarios en inglés) o el 3 (tipado en el pipeline); ambos son cambios acotados y de bajo riesgo.

package/docs/PR_DESCRIPTION_0.9.2.md

@@ -1,22 +0,0 @@
-# PR description (copy into your Pull Request)
-
----
-
-## Breaking changes
-
-- **Config**: `syntropyLog.init()` no longer accepts `http` or `brokers`; the core only manages Redis.
-- **API**: `SyntropyLog.getHttp()` and `SyntropyLog.getBroker()` have been removed. Callers must obtain HTTP/broker clients from their own app or from `syntropylog/http` / `syntropylog/brokers` directly.
-
-## Migration
-
-- **If you used `getHttp()` or `getBroker()`**: Migrate to whatever your app uses to expose those clients (e.g. dependency injection, or instantiating from `syntropylog/http` / `syntropylog/brokers`).
-- **If you passed `http` or `brokers` in `init()`**: Remove those options; the core no longer uses them.
-
-## Context for reviewers (High Risk)
-
-This PR is marked **High Risk** because it removes public config/API surface and changes logger transport selection and Redis transaction behavior. To mitigate:
-
-- **Tests**: Unit and integration tests cover the new flows; pre-commit runs lint, tests, and build.
-- **Breaking changes and migration** are documented in `CHANGELOG.md` (section [0.9.2], including the Migration subsection) so existing integrations can plan the upgrade.
-
----

package/docs/REVISION_MOCKS_SOLID_FP.md

@@ -1,50 +0,0 @@
-# Revisión: mocks — funciones puras, SOLID, guardas
-
-Revisión en bloques de **BeaconRedisMock** aplicando guardas, helpers puros y menos duplicación.
-
----
-
-## 1. BeaconRedisMock.ts
-
-### Hecho
-- **Guardas**: `_getValidEntry`: orden claro (no entry → null, expired → delete + null, wrong type → throw). `expire`: early return `if (!entry) return false`. `incrBy` / `hIncrBy`: `Number.isNaN` y throw temprano.
-- **Puro**: `_serialize` ya era puro; añadido `_toKeyArray(keys)` estático puro para normalizar `string | string[]` → `string[]`.
-- **Menos mutación directa en loops**: `del` y `exists` usan `_toKeyArray` + `filter().length`. `hDel` usa `filter` para contar borrados. `hSet`: rama string con early return; uso de `Object.hasOwn` donde aplica.
-- **ILogger**: `updateConfig` corrige orden de argumentos a `(meta, message)`.
-
-### Opcional (siguiente bloque)
-- Extraer lógica de “clave expirada” a un helper que reciba `StoreEntry` y devuelva boolean (puro).
-- `scan`: extraer el filtro por MATCH a una función pura `(key, pattern) => boolean`.
-
----
-
-## Principios aplicados
-
-| Principio        | Aplicación                                                                 |
-|-----------------|----------------------------------------------------------------------------|
-| Guard clauses   | Early return / throw al inicio de método; un solo nivel de anidación.     |
-| Pure functions  | `_serialize`, `_toKeyArray`; helpers sin efectos.                         |
-| SOLID (SRP)     | Responsabilidades concentradas por componente.                              |
-| DRY             | Helpers reutilizables y un solo loop donde aplica.                          |
-| Menos mutación  | Uso de `filter`/`length` y returns tempranos en lugar de contadores en loops. |
-
-Los mocks siguen siendo wrappers de la interfaz original: la lógica extra es mínima y predecible (guardas + delegación).
-
----
-
-## 2. TimeoutStep.ts
-
-### Hecho
-- **Pure**: `buildSuccessPayload` y `buildErrorPayload` son funciones puras (data + duración + estrategia/error → objeto).
-- **Guardas**: `execute` intenta estrategia + cálculo; en catch solo construye payload de error. Constante `DEFAULT_TIMEOUT_MS`.
-- **Estrategia única**: Solo se usa la estrategia `default`; `selectTimeoutStrategy` devuelve `timeoutStrategies.get('default') ?? null` (sin lookup por tipo de data).
-
----
-
-## 3. SerializationPipeline.ts
-
-### Hecho
-- **selectTimeoutStrategy**: Obtiene solo `timeoutStrategies.get('default')`; guarda que lanza si no hay estrategia default.
-- **Pure**: `buildSuccessResult` y `buildErrorResult` estáticos que construyen `SerializationResult` sin efectos.
-- **Constantes**: `DEFAULT_SERIALIZER`, `UNKNOWN_STRATEGY`; `globalTimeout` con `??` 50.
-- **Estrategia única**: Solo **DefaultTimeoutStrategy** (5000 ms). Eliminadas las estrategias por adaptador (Prisma, TypeORM, MySQL, PostgreSQL, SQL Server, Oracle).

package/docs/SINGLETON_E_INSTANCE_REGISTRY.md

@@ -1,187 +0,0 @@
-# Singletons y registro de instancias — Diseño
-
-Documento de diseño para el **manejador de instancias** genérico del framework. Refleja lo acordado: estructura, política estricta, teardown en orden inverso y API solo para tests.
-
----
-
-## 1. Qué hay hoy
-
-### 1.1 Singleton global del framework
-
-- **SyntropyLog:** una sola instancia por proceso (`getInstance()`). Punto de entrada.
-- **Export** `syntropyLog`: llama a `getInstance()` al importar el módulo.
-
-### 1.2 Managers “por tipo” (registro por nombre)
-
-Tres managers con varias instancias por nombre:
-
-| Manager         | Config        | API en SyntropyLog | Qué guarda                    |
-|-----------------|---------------|--------------------|-------------------------------|
-| **RedisManager**  | `config.redis`  | `getRedis(name)`   | Clientes Redis instrumentados (BeaconRedis) |
-| **HttpManager**   | `config.http`   | `getHttp(name)`    | Clientes HTTP instrumentados  |
-| **BrokerManager** | `config.brokers`| `getBroker(name)`  | Clientes de broker instrumentados |
-
-Cada manager se crea en `LifecycleManager.init()` si viene su bloque en la config. En `shutdown()` se llama a `redisManager?.shutdown()`, `httpManager?.shutdown()`, `brokerManager?.shutdown()`.
-
----
-
-## 2. Objetivo acordado
-
-- **Mantener:** Solo el **cliente Redis instrumentado** (RedisManager + BeaconRedis). Único “tipo” con manager propio y config dedicada.
-- **Quitar:** HTTP/axios y brokers del core: HttpManager, BrokerManager, config `http`/`brokers`, `getHttp`/`getBroker`.
-- **Añadir:** Un **registro genérico de instancias** (nombre → entrada con valor y dispose) para que el desarrollador guarde lo que quiera: axios, Kafka, clases propias, diccionarios, etc.
-
----
-
-## 3. Estructura del registro
-
-### 3.1 Entrada (por llave)
-
-Cada entrada del registro tiene:
-
-| Campo     | Tipo     | Descripción |
-|----------|----------|-------------|
-| **nombre** | `string` | Llave para registrar y para `get(nombre)`. |
-| **valor**  | cualquiera | La instancia que se devuelve con `get(nombre)`. |
-| **dispose** | `() => void \| Promise<void>` (opcional) | Función de limpieza; se llama en el teardown del framework. |
-
-**Forma de la API (extensible):** se puede usar un objeto de opciones para poder añadir campos después sin romper la API:
-
-```ts
-syntropyLog.register('kafka-producer', {
-  value: producer,
-  dispose: async () => await producer.disconnect(),
-});
-```
-
-O firma corta cuando no hay dispose:
-
-```ts
-syntropyLog.register('api', axiosInstance);
-// equivalente a { value: axiosInstance }
-```
-
-### 3.2 Política estricta (producción)
-
-- **Si la llave ya existe → error.** No se permite sobrescribir. Comportamiento de diccionario estricto.
-- **Arranque:** Si algo falla (init, registro duplicado, etc.), la librería **informa el error y no levanta la API**. Fail fast.
-- **Teardown:** Se ejecuta en **orden inverso** al de registro (el último registrado se dispone primero). El registro debe preservar orden (p. ej. array o estructura ordenada).
-
-### 3.3 Dispose y errores
-
-- Si un valor tiene `dispose`, se llama en el teardown (en orden inverso al registro).
-- Si no tiene `dispose`, no se hace nada con ese valor.
-- Si un `dispose` falla (throw o reject), se recomienda usar algo tipo `Promise.allSettled`: ejecutar todos los dispose y luego reportar fallos (log o evento), para no dejar otros recursos sin cerrar.
-
----
-
-## 4. API pública (producción)
-
-- **`register(name: string, value: unknown): void**  
-  **`register(name: string, entry: { value: unknown; dispose?: () => void \| Promise<void> }): void**  
-  Registra una instancia. Si la llave ya existe, **lanza error**. Orden de registro se usa para el teardown inverso.
-
-- **`get<T>(name: string): T`**  
-  Devuelve la instancia registrada; lanza si no existe.
-
-- **`has(name: string): boolean`**  
-  Indica si hay una entrada con ese nombre.
-
-Redis sigue fuera del registro: se usa `getRedis(name)` como hasta ahora.
-
----
-
-## 5. Ejemplos de uso
-
-### Kafka (cliente con cierre)
-
-```ts
-const kafka = new Kafka({ clientId: 'my-app', brokers: ['localhost:9092'] });
-const producer = kafka.producer();
-await producer.connect();
-
-syntropyLog.register('kafka-producer', {
-  value: producer,
-  dispose: async () => await producer.disconnect(),
-});
-
-const producer = syntropyLog.get<KafkaProducer>('kafka-producer');
-await producer.send({ topic: 'events', messages: [...] });
-```
-
-### Axios (sin cierre)
-
-```ts
-const api = axios.create({ baseURL: 'https://api.ejemplo.com' });
-api.interceptors.request.use((req) => {
-  req.headers['x-correlation-id'] = syntropyLog.getContextManager().getCorrelationId();
-  return req;
-});
-
-syntropyLog.register('api', api);
-
-const api = syntropyLog.get<AxiosInstance>('api');
-const { data } = await api.get('/users');
-```
-
-### Diccionario común (objeto plano)
-
-```ts
-const featureFlags = { betaCheckout: true, newDashboard: false };
-syntropyLog.register('feature-flags', featureFlags);
-
-const flags = syntropyLog.get<typeof featureFlags>('feature-flags');
-if (flags.betaCheckout) { ... }
-```
-
----
-
-## 6. Tests: reemplazar y dejar a cero
-
-Objetivo: poder correr los tests **como la aplicación** (mismo init, mismos registros) y luego **reemplazar** entradas por mocks, y **dejar la instancia a cero** para el siguiente test. Todo esto **solo en test**, sin mezclar con producción.
-
-### 6.1 API solo para test (propuesta)
-
-- **Reemplazar una entrada:** p. ej. `_replaceForTesting(name, value, dispose?)`. Permite que el test, después del init, sustituya una entrada (p. ej. `'api'`) por un mock. Solo disponible o con efecto en entorno de test.
-
-- **Reemplazar toda la lista:** p. ej. `_replaceRegistryForTesting(entries)` o equivalente (vaciar y registrar una lista de entradas). El test puede tirar todo lo registrado en init y poner solo sus mocks.
-
-- **Dejar a cero para el siguiente test:** p. ej. `_clearRegistryForTesting()` que vacíe el registro. Si `_resetForTesting()` ya recrea el `LifecycleManager`, ese reset puede incluir un registro nuevo y vacío; así “a cero” = mismo reset que hoy para estado limpio.
-
-Nombres con prefijo `_` y sufijo `ForTesting` dejan claro que es API solo para tests.
-
-### 6.2 Mocks sin columna extra
-
-No se añade ninguna columna “es mock” en la entrada. En tests se usa el **mismo registro**: el test registra **el mock** en lugar del objeto real (o reemplaza con la API de test). Mismo nombre, mismo `get('api')`; lo que cambia es qué instancia se registró.
-
----
-
-## 7. Resumen de impacto (al implementar)
-
-| Área              | Acción |
-|-------------------|--------|
-| **LifecycleManager** | Quitar HttpManager y BrokerManager. Añadir registro genérico (ordenado). En shutdown: ejecutar dispose del registro en orden inverso, luego `redisManager?.shutdown()`. |
-| **SyntropyLog**   | Quitar `getHttp` y `getBroker`. Añadir `register` y `get` (y `has`). Mantener `getRedis(name)`. Exponer API de test: reemplazo y clear. |
-| **Config (schema)** | Quitar (o deprecar) `http` y `brokers`; mantener `redis`. |
-| **Tests / mocks** | Dejar de usar config HTTP/broker y getHttp/getBroker. Usar registro; en test usar reemplazo/clear según necesidad. Ajustar o eliminar tests de HttpManager/BrokerManager. |
-| **Documentación** | Explicar que solo Redis es “tipo integrado”; el resto va al registro genérico. Ejemplos (Kafka, Axios, diccionario) y uso en tests. |
-
----
-
-## 8. Cerrado vs pendiente
-
-**Cerrado:**
-
-- Estructura de entrada: nombre, valor, dispose (opcional); objeto de opciones para extensibilidad.
-- Política: llave existente → error; fail fast en arranque; teardown en orden inverso.
-- Ejemplos: Kafka, Axios, diccionario.
-- Tests: reemplazar por mocks y dejar a cero; API solo para test; sin columna “mock”.
-
-**Pendiente (detalle de implementación):**
-
-- Nombre exacto del registro: `InstanceRegistry`, `InstanceManager`, otro.
-- Nombre de métodos: `get` / `register` vs `getInstance` / `registerInstance`.
-- Registro solo en estado READY o también antes de `init()`.
-- Mantener o no los módulos `src/http` y `src/brokers` como utilidades opcionales.
-
-Cuando se implemente, este doc sirve como referencia del diseño acordado.

package/docs/TRANSPORTS_CONDICIONALES_POR_AMBIENTE.md

@@ -1,178 +0,0 @@
-# Transports condicionales por ambiente
-
-Objetivo: poder habilitar o deshabilitar transports según el ambiente (NODE_ENV, APP_ENV, etc.) y repartir salida (consola, archivo, Azure, etc.) de forma condicional sin duplicar config.
-
----
-
-## Forma recomendada: transportList + env
-
-Lista de transports **separada** del criterio por ambiente: definís un pool (nombre → transport) y, por ambiente, qué nombres del pool se usan como default. Muy flexible y declarativo.
-
-- **`transportList`:** `Record<string, Transport>` — pool de todos los transports (nombre → instancia).
-- **`env`:** `Record<string, string[]>` — por cada ambiente, lista de **nombres** del pool que se usan como default.
-
-El ambiente actual se lee de `process.env[logger.envKey ?? 'NODE_ENV']`. Si el ambiente no está en `env`, el default queda vacío (conviene definir una entrada por cada env que usés).
-
-**Ejemplo (autocontenido: todo a consola con simulados):**
-
-En el ejemplo, `db`, `azure` y `archivo` se simulan con `AdapterTransport` + `UniversalAdapter` mandando a consola con una etiqueta. En producción reemplazás por el transport real (Azure, DB, archivo, etc.).
-
-```ts
-import { syntropyLog, ColorfulConsoleTransport, AdapterTransport, UniversalAdapter } from 'syntropylog';
-
-// Registro tipo mock: cada “destino” va a consola con etiqueta (solo para el ejemplo).
-const mockToConsole = (label: string) =>
-  new AdapterTransport({
-    name: label,
-    adapter: new UniversalAdapter({
-      executor: (data) => console.log(`[${label}]`, JSON.stringify(data)),
-    }),
-  });
-
-await syntropyLog.init({
-  logger: {
-    envKey: 'NODE_ENV',
-    transportList: {
-      consola: new ColorfulConsoleTransport({ name: 'consola' }),
-      db: mockToConsole('db'),
-      azure: mockToConsole('azure'),
-      archivo: mockToConsole('archivo'),
-    },
-    env: {
-      development: ['consola'],
-      staging: ['consola', 'archivo', 'azure'],
-      production: ['consola', 'db', 'azure'],
-    },
-  },
-  redis: { instances: [] },
-});
-
-const log = syntropyLog.getLogger('app');
-log.info('default según env');
-log.override('consola').info('solo consola');
-```
-
-Override/add/remove por llamada usan los mismos nombres del pool (`logger.override('consola').info('...')`). En producción, reemplazás `mockToConsole('db')` por tu transport real (p. ej. uno que use UniversalAdapter con un executor que persista en DB).
-
-**Prioridad:** Si están `transportList` y `env`, se usa esta forma. Si no, se usa la forma clásica `transports` (compatibilidad).
-
----
-
-## Forma clásica (compatibilidad): transports
-
-### Descriptor en config (declarativo, por env)
-
-En `logger.transports` (forma antigua) cada elemento puede ser:
-
-- **Un `Transport`** → siempre activo.
-- **Un descriptor** `{ transport: Transport, env?: string | string[] }` → el transport solo se incluye cuando el **ambiente actual** está en la lista. Si no se pone `env`, se considera activo en todos los ambientes.
-
-El "ambiente actual" se lee de una variable de entorno. Por defecto `NODE_ENV`. Se puede cambiar con `logger.envKey` (ej. `'APP_ENV'`).
-
-**Ejemplo:**
-
-```ts
-await syntropyLog.init({
-  logger: {
-    envKey: 'NODE_ENV',  // opcional; por defecto es 'NODE_ENV'
-    transports: [
-      // Siempre: consola colorida en desarrollo
-      new ColorfulConsoleTransport(),
-      // Solo en production: Azure
-      { transport: new AzureLogTransport({ ... }), env: 'production' },
-      // En production y staging: archivo
-      { transport: new FileTransport({ path: 'app.log' }), env: ['production', 'staging'] },
-    ],
-  },
-  // ...
-});
-```
-
-Comportamiento:
-
-- **development:** solo ColorfulConsoleTransport.
-- **staging:** ColorfulConsoleTransport + FileTransport.
-- **production:** ColorfulConsoleTransport + AzureLogTransport + FileTransport.
-
-Si no indicás `env`, el transport se usa en todos los ambientes. Así podés “partir” qué va a consola, a archivo o a Azure según el env, sin APIs adicionales.
-
----
-
-### 2. ConditionalTransport (flexible, por función)
-
-Para condiciones que no sean solo “env en lista” (por ejemplo “si existe cierta variable”, “si es martes”, etc.), un transport **wrapper** que delega solo cuando una función devuelve true:
-
-```ts
-import { ConditionalTransport } from 'syntropylog';
-
-new ConditionalTransport({
-  transport: new AzureLogTransport({ ... }),
-  enableWhen: () => process.env.NODE_ENV === 'production' && process.env.ENABLE_AZURE === '1',
-})
-```
-
-En `log(entry)`: si `enableWhen()` es true, se llama al transport envuelto; si no, no se hace nada. No requiere cambios en el schema; es composición.
-
----
-
-## 3. Override por llamada: .override(), .add(), .remove()
-
-Objetivo: tener un **pool de N transports** configurados y nombrados (por ambiente, etc.) y, **solo para un caso puntual**, decidir a dónde va ese log sin cambiar la config global. API declarativa y fluida.
-
-### 3.1 Pool de transports con nombre
-
-Todos los transports configurados deben tener **nombre** (ej. `name: 'consola'`, `name: 'db'`, `name: 'azure'`, `name: 'archivo'`). Esa lista N es el universo de destinos; en cada ambiente suelen estar activos solo algunos (ej. 2–4). Cualquier override/add/remove usa **solo nombres de ese pool**; no se inventan transports nuevos en la llamada.
-
-### 3.2 Tres formas (fluent, aplican al siguiente log)
-
-| Método | Significado | Ejemplo |
-|--------|-------------|---------|
-| **`.override("a", "b")`** | Para este log, **solo** estos transports. Lista exacta. | `logger.override("consola").info("solo consola")` |
-| **`.add("x")`** | Para este log, default **más** estos (de la lista configurada). Encadenable. | `logger.add("azure").info("transacción especial")` |
-| **`.remove("x").remove("z")`** | Para este log, default **menos** estos. Encadenable. | `logger.remove("db").remove("azure").info("debug, no guardar")` |
-
-- **Override** reemplaza la lista efectiva por exactamente la que indicás. Si usás override, no se mezcla con default.
-- **Add** y **remove** se aplican sobre el default (o sobre lo que quede tras add/remove). Se pueden encadenar: `logger.remove("db").add("archivo").info("...")` → default − db + archivo.
-- Aplica al **siguiente log**; la llamada siguiente sin override/add/remove vuelve al default.
-
-### 3.3 Ejemplos
-
-```ts
-// Solo a consola (override)
-logger.override("consola").info("buscando un error, no mandar a DB");
-
-// Solo consola y archivo
-logger.override("consola", "archivo").info("backup manual");
-
-// Default + Azure para esta línea
-logger.add("azure").info("transacción que también va a Azure");
-
-// Default menos DB y Azure (ej. debug)
-logger.remove("db").remove("azure").info("solo ver en consola");
-
-// Default − db + archivo
-logger.remove("db").add("archivo").info("auditoría a archivo sin DB");
-```
-
-### 3.4 Resumen de la idea
-
-- Configurás una lista N de transports (con nombre y por ambiente).
-- Para el 99,9 % de los casos usás el default que da esa config.
-- Para un caso puntual: **override** (“solo estos”), **add** (“default + estos”) o **remove** (“default − estos”), siempre sobre la lista que ya configuraste. Declarativo y fluido.
-
----
-
-## Resumen
-
-| Necesidad | Solución |
-|-----------|----------|
-| **Pool + env (recomendado)** | `logger.transportList` (nombre → Transport) + `logger.env` (env → nombres). Ej: `env: { development: ['consola'], production: ['consola','db'] }`. |
-| Habilitar transport solo en ciertos env (forma clásica) | Descriptor `{ transport, env: 'production' }` o `env: ['production', 'staging']` en `logger.transports`. |
-| Variable de ambiente distinta de NODE_ENV | `logger.envKey: 'APP_ENV'` (o la que uses). |
-| Condición arbitraria (función) | `ConditionalTransport({ transport, enableWhen: () => boolean })`. |
-| Algunos a consola, otros a archivo/Azure, según env | Mismo array de transports: algunos sin `env` (siempre), otros con `env` para filtrar por ambiente. |
-| **Por llamada: solo estos destinos** | `logger.override("consola", "archivo").info("...")` — solo esos transports (del pool configurado). |
-| **Por llamada: default + algunos** | `logger.add("azure").info("...")` — fluido, encadenable. |
-| **Por llamada: default − algunos** | `logger.remove("db").remove("azure").info("...")` — fluido, encadenable. |
-
-Implementación: en `LoggerFactory`, al construir la lista de transports, resolver el ambiente con `envKey`/NODE_ENV y filtrar los descriptores por `env`; el resto del código sigue recibiendo `Transport[]`. Transports con `name` para el pool nombrado. Logger expone `.override()`, `.add()`, `.remove()` que aplican al siguiente log y resuelven por nombre contra ese pool. Opcionalmente exportar `ConditionalTransport` para quien prefiera la API por función.

package/docs/configuration.md

@@ -1,99 +0,0 @@
-# Master Configuration Guide
-
-This guide provides a complete reference for every configuration option in SyntropyLog.
-
-## 📋 Top-Level Configuration
-
-The configuration object passed to `syntropyLog.init()` follows this structure:
-
-```typescript
-await syntropyLog.init({
-  logger: { /* Logger specific settings */ },
-  loggingMatrix: { /* Context visibility control */ },
-  redis: { /* Managed Redis instances */ },
-  masking: { /* Data privacy & security rules */ },
-  context: { /* Correlation ID settings */ },
-  shutdownTimeout: 5000 // ms
-});
-```
-
----
-
-## 🌲 1. Logger Configuration (`logger`)
-
-Controls the core logging engine behavior.
-
-| Property | Type | Description |
-| :--- | :--- | :--- |
-| `serviceName` | `string` | The identifier for your application in traces and logs. |
-| `level` | `LogLevel` | Minimum severity level (`trace`, `debug`, `info`, `warn`, `error`, `fatal`, `silent`). |
-| `transports` | `Transport[]` or `Record` | Array of transport instances (e.g., `ConsoleTransport`) or a mapping of logger names to transport arrays. |
-| `serializerTimeoutMs` | `number` | Max time (ms) allowed for the security pipeline to process metadata. Default: `50ms`. |
-| `prettyPrint` | `object` | `{ enabled: boolean }`. Formats logs for readability in development. |
-
----
-
-## 📊 2. Logging Matrix (`loggingMatrix`)
-
-The **Logging Matrix** is a unique feature that controls which context properties (e.g., `userId`, `correlationId`) are included in the final log output based on the log level.
-
-```typescript
-loggingMatrix: {
-  default: ['correlationId', 'serviceName'], // Included in all levels
-  error: ['*'], // Include ALL context fields for errors
-  trace: ['correlationId', 'serviceName', 'requestId'],
-  audit: ['*'] // Audit logs typically include all available context
-}
-```
-
----
-
-## 💾 3. Managed Resources (`redis`)
-
-Centralize Redis connections with automatic observability.
-
-### **Redis (`redis`)**
-- `instances`: Array of Redis configurations.
-- `default`: Name of the default instance.
-
-**Per-instance Logging settings:**
-- `onSuccess`: Level for successful commands (Default: `debug`).
-- `onError`: Level for failed commands (Default: `error`).
-- `logCommandValues`: Boolean. Log the command arguments (e.g., keys/values).
-- `logReturnValue`: Boolean. Log what Redis returned.
-
----
-
-## 🛡️ 4. Masking & Security (`masking`)
-
-Define rules to automatically redact sensitive information.
-
-```typescript
-masking: {
-  rules: [
-    { pattern: 'password', strategy: MaskingStrategy.STAR },
-    { pattern: /card_number/, strategy: MaskingStrategy.REDACT }
-  ],
-  maskChar: '*',
-  preserveLength: true,
-  enableDefaultRules: true // Pre-mask common fields like 'token', 'apiKey'
-}
-```
-
----
-
-## 🔄 5. Context Propagation (`context`)
-
-Defines how the library identifies and tracks requests through headers.
-
-- `correlationIdHeader`: The header name used for tracing (e.g., `X-Correlation-ID`).
-- `transactionIdHeader`: The header name for external trace IDs (e.g., `X-Trace-ID`).
-
----
-
-## 📚 Related Guides
-- [🏢 Enterprise Implementation](./enterprise.md)
-- [📦 Persistence & Universal Adapters](./persistence.md)
-- [🧬 Serialization & Custom Formatting](./serialization.md)
-- [⚙️ Middleware & Framework Integration](./middleware.md)
-- [🧪 Testing Strategy](./testing.md)

package/docs/enterprise.md

@@ -1,44 +0,0 @@
-# Enterprise Implementation Guide
-
-SyntropyLog is designed for enterprise environments and can be easily integrated into your internal infrastructure.
-
-## Why SyntropyLog for Enterprise?
-
-1. **Security by Default**
-   - Built-in data masking for sensitive information.
-   - Compliance-ready logging with retention rules.
-   - No external telemetry or tracking.
-   - 100% open source and auditable.
-
-2. **Scalable Architecture**
-   - Singleton pattern prevents resource leaks.
-   - Automatic connection pooling.
-   - Kubernetes-ready with proper lifecycle management.
-   - Horizontal scaling support.
-
-3. **Performance Excellence**
-   - Zero measurable performance overhead.
-   - Minimal bundle size impact.
-   - Optimized for high-throughput applications.
-
-## Internal Implementation Strategy
-
-### Phase 1: Pilot Project (2-4 weeks)
-Start with a single microservice to validate the integration and observability benefits.
-
-### Phase 2: Service Mesh Integration (4-8 weeks)
-Standardize configuration across multiple services to enable cross-service tracing.
-
-### Phase 3: Full Enterprise Rollout (8-12 weeks)
-Integrate with all internal resources (Redis clusters, Kafka brokers, internal APIs) and compliance monitoring systems.
-
-## Enterprise Patterns
-
-### Environment-Based Configuration
-Centralize your configuration logic to switch between local development and production environments effortlessly.
-
-### Centralized Logging Infrastructure
-Use JSON transports for seamless ingestion into ELK (Elasticsearch, Logstash, Kibana) or Splunk stacks.
-
-### Security & Compliance
-Leverage the `audit()` level for critical actions that must bypass standard filters and be persisted for regulatory compliance.

package/docs/middleware.md

@@ -1,62 +0,0 @@
-# Middleware & Framework Integration
-
-SyntropyLog is framework-agnostic but provides patterns to integrate with the most popular Node.js web frameworks.
-
-## 🌊 How Middleware Works in SyntropyLog
-
-The goal of the middleware is to:
-1. **Initialize the Context**: Start an asynchronous storage scope.
-2. **Assign Correlation IDs**: Extract from headers or generate a new one.
-3. **Bind Loggers**: Provide a context-aware logger to the request.
-
----
-
-## 🚀 Native Integration Patterns
-
-### **Express.js**
-```typescript
-import { syntropyLog } from 'syntropylog';
-
-const syntropyMiddleware = (req, res, next) => {
-  const contextManager = syntropyLog.getContextManager();
-  
-  contextManager.run(async () => {
-    // Automatically detect incoming header or generate new ID
-    const correlationId = contextManager.getCorrelationId();
-    contextManager.set(contextManager.getCorrelationIdHeaderName(), correlationId);
-    
-    // Attach logger to request for convenience
-    req.logger = syntropyLog.getLogger('http');
-    
-    next();
-  });
-};
-
-app.use(syntropyMiddleware);
-```
-
-### **NestJS**
-Use a Global Interceptor or Middleware to wrap the execution context.
-```typescript
-@Injectable()
-export class ObservabilityMiddleware implements NestMiddleware {
-  use(req: Request, res: Response, next: NextFunction) {
-    syntropyLog.getContextManager().run(() => {
-        // Context setup logic
-        next();
-    });
-  }
-}
-```
-
----
-
-## 🛠️ "The Middleware that needs to be done"
-
-We are currently working on a unified `@syntropylog/middleware` package that will provide:
-- **Auto-masking** for body/headers out of the box.
-- **Performance tracking** (auto log request duration).
-- **Graceful Error Handling** middleware.
-
-Until the official package is released, we recommend using the **Express + Redis + Axios** example as a reference for a production-ready implementation:
-👉 [See Example 12: Express + Redis + Axios](./examples/12-express-redis-axios/)

package/docs/persistence.md

@@ -1,81 +0,0 @@
-# Universal Persistence (Storage Agnostic)
-
-Starting from v0.8.x, SyntropyLog includes a powerful way to persist logs to any destination without external dependencies. By using `UniversalAdapter` and `UniversalLogFormatter`, you can map your logs to any schema using JSON and provide an execution function.
-
-## 🎯 The Concept
-
-Instead of writing a complex class for every database, you provide:
-1.  **A Formatter**: Maps the log object to your desired schema.
-2.  **An Executor**: A simple function that takes the formatted data and saves it.
-
----
-
-## 🚀 Examples
-
-### **1. Capture Logs in Memory (for Debugging)**
-```typescript
-import { UniversalAdapter, syntropyLog } from 'syntropylog';
-
-const adapter = new UniversalAdapter({
-  executor: (data) => console.log('Captured by Adapter:', data)
-});
-
-// Use it in your configuration
-await syntropyLog.init({
-  logger: {
-    transports: [ new AdapterTransport({ adapter }) ]
-  }
-});
-```
-
-### **2. Persisting to MongoDB (Object-based)**
-```typescript
-import { UniversalAdapter, UniversalLogFormatter, syntropyLog } from 'syntropylog';
-
-const mongoAdapter = new UniversalAdapter({
-  executor: (doc) => db.collection('logs').insertOne(doc)
-});
-
-const mongoFormatter = new UniversalLogFormatter({
-  mapping: {
-    user: 'metadata.userId',
-    event: 'message',
-    level: 'level',
-    payload: 'bindings' // Full object path
-  }
-});
-
-await syntropyLog.init({
-  logger: {
-    transports: {
-      audit: [new AdapterTransport({
-        adapter: mongoAdapter,
-        formatter: mongoFormatter
-      })]
-    }
-  }
-});
-```
-
-### **3. Generic SQL (Postgres/MySQL)**
-```typescript
-const sqlAdapter = new UniversalAdapter({
-  // The executor receives the result of the formatter
-  executor: ({ sql, values }) => pool.query(sql, values)
-});
-
-const sqlFormatter = new UniversalLogFormatter({
-  mapping: {
-    column_user: 'bindings.userId',
-    column_msg: 'message'
-  }
-});
-```
-
----
-
-## 🛡️ Why use Universal Adapters?
-
-- **Storage Agnostic**: Move from SQL to NoSQL without changing your application code.
-- **Zero Dependencies**: You don't need `syntropylog-mongodb-adapter`—just use your existing database client.
-- **Pure JSON Mapping**: Define your schema in configuration, not in code.

package/docs/philosophy.md

@@ -1,15 +0,0 @@
-# Core Philosophy: Silent Observer
-
-SyntropyLog follows the **Silent Observer** principle: we report what happened and nothing more. We never interfere with the primary execution flow of your application.
-
-## Non-Blocking Execution
-Your application should continue running normally, even if the logging pipeline or a transport fails. SyntropyLog catches and reports its own internal errors to the console but prevents them from crashing your main process.
-
-## Error Handling Strategy
-
-1. **Configuration Errors**: Fatal. The application fails to start if the environment is incorrectly configured.
-2. **Pipeline/Serializer Errors**: Non-fatal. Reported to internal diagnostics, application continues.
-3. **Transport Errors**: Non-fatal. Logged to the fallback console, application continues.
-
-## Performance Benchmark
-SyntropyLog is designed to provide tracing and management with identical performance to **Pino**, the industry standard for high-performance logging in Node.js.

package/docs/serialization.md

@@ -1,67 +0,0 @@
-# Serialization & Resiliency
-
-SyntropyLog 0.9.1 introduces an **Intelligent Serialization Pipeline**. This system ensures that your application remains stable even when logging complex, circular, or deeply nested data structures.
-
-## 🛡️ The Security Pipeline
-
-Every piece of metadata passed to a log call flows through a multi-step pipeline before reaching any transport. This process is automatic and requires zero configuration.
-
-### 1. **Hygiene Step** (Circular References & Depth)
-Uses `flatted` to detect and neutralize circular references. It also enforces a maximum object depth to prevent stack overflow or excessive memory consumption.
-- **Goal**: Prevent recursion-based crashes.
-- **Output**: A "clean" object safe for standard JSON operations.
-
-### 2. **Serialization Step** (Internal Resiliency)
-Translates complex objects (Errors, BigInts, etc.) into structured JSON values using internal, optimized serializers.
-
-### 3. **Sanitization Step** (PII & Injection)
-Integrates with the **MaskingEngine** to redact sensitive fields and strips control characters to prevent log injection attacks.
-
-### 4. **Timeout Step** (Event Loop Protection)
-Every step in the pipeline is wrapped in a mandatory execution timeout (default: **50ms**). If serialization takes too long, it is aborted via `Promise.race`, and a safe subset of the data is logged instead.
-- **Goal**: Prevent "Death by Log" or Event Loop starvation in high-load scenarios.
-- **Configurable**: Adjust this value using the `logger.serializerTimeoutMs` property in your configuration (min: 1ms, recommended: 20ms - 200ms).
-
----
-
-## ⚖️ Comparison with Traditional Loggers
-
-In most logging implementations, serialization is a synchronous, blocking task. SyntropyLog differentiates itself by treating serialization as a **resilient asynchronous pipeline**:
-
-| Feature | Traditional Loggers | SyntropyLog v0.9.1 |
-| :--- | :--- | :--- |
-| **Circular Objects** | Often crash or throw `TypeError` | Auto-detected and neutralized via `HygieneStep` |
-| **Massive Objects** | Block the Event Loop until finished | Aborted after timeout (50ms) to protect latency |
-| **Safety** | May throw exceptions on bad data | Guaranteed never to throw ("Silent Observer") |
-| **Auditability** | Dropped logs leave no trace | Failure metadata is included in the log output |
-
-## 🧩 Extensibility (Universal Contracts)
-
-While SyntropyLog no longer allows "loose" serializer functions in the global config (for security reasons), advanced users can still extend the system by implementing the `ISerializer` contract and registering it with the `SerializationManager`.
-
-```typescript
-import { ISerializer, SerializationComplexity } from 'syntropylog';
-
-const MyCustomSerializer: ISerializer = {
-  name: 'my-serializer',
-  priority: 10,
-  canSerialize: (data) => data instanceof MyCustomClass,
-  serialize: async (data) => ({
-    success: true,
-    data: data.toCustomString(),
-  }),
-  getComplexity: () => SerializationComplexity.SIMPLE
-};
-
-// Register via the facade
-syntropyLog.getSerializer().register(MyCustomSerializer);
-```
-
----
-
-## 🏛️ The Silent Observer Principle
-
-The entire pipeline follows the **Silent Observer** philosophy:
-- **No Exceptions**: Logging should never throw. If a step fails, the pipeline recovers gracefully.
-- **Non-Blocking**: Timeouts ensure that serialization never starves the event loop.
-- **Information over Perfection**: If data is too complex to serialize safely, SyntropyLog will log as much as possible rather than dropping the message entirely.

package/docs/testing.md

@@ -1,28 +0,0 @@
-# Testing Guide
-
-SyntropyLog is designed to make testing easier by removing the need for complex connection management and boilerplate in your unit tests.
-
-## Zero Boilerplate Testing
-
-Use the built-in testing helper to inject mocks into your services without needing to initialize or shutdown actual connections.
-
-```typescript
-import { createTestHelper } from 'syntropylog/testing';
-const testHelper = createTestHelper();
-
-describe('MyService', () => {
-  beforeEach(() => {
-    testHelper.beforeEach(); // Resets all mocks automatically
-  });
-
-  it('works', () => {
-    const service = new MyService(testHelper.mockSyntropyLog);
-    // ...
-  });
-});
-```
-
-## Benefits
-- **No Connection Boilerplate**: No need for `init()` or `shutdown()` in your test files.
-- **Lightning Fast**: All operations run in-memory using highly optimized mocks.
-- **Assertion Ready**: Easily verify that your services are logging the correct information and using Redis/HTTP resources as expected.