exis_ray 0.8.0 → 0.10.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 95101aa6f502c3c839070a556ab984244493d9f8bbabaad2b3b4e2e83b19cc67
-  data.tar.gz: af2097e279144370005dd457effbeaf961a11938f191a9aa30053efe717f9b12
+  metadata.gz: 78d2b6cbc5e3da104fee7f3d2f481311acd2da7971d80295edf0bbad6eaab178
+  data.tar.gz: c54ebfc75e0c5abf640506b97b41b4b86bfe1f05a8d17a2d484941dae0fb21d4
 SHA512:
-  metadata.gz: 62e1bf2fe943f02976ba69b73ba9d76e698f93f6b9d1284a02354c01c4ab4d5b18411212da27ffe0ea315616184dfce0d3b66dc9a871c6cebbb50320656f5342
-  data.tar.gz: 10cf92356274c0da04446c96a109f298eb2c94a8eacb3787762e9785cf42915b877304161f70aeb6ac8478598b29c6aca127057a0db8d7f089f29b046a9bd954
+  metadata.gz: e6642e744b2b9fc0d798e419664d76ebe2a0beba38722b1db09ac501d408938695990d4d752a0b0bf9cad78aa1a62a3939113e1444a623df890cabb8a4f0ad31
+  data.tar.gz: e96e7936add04a739ac1f325d1b768437c82381f5252420f2ab0eb72d6ad51e50bc272c7b136e4f1c0096d59f50b4b9fdc227ec05086e374e385ad543d5d47e8

data/CHANGELOG.md

@@ -1,3 +1,19 @@
+## [0.10.0] - 2026-05-25
+
+### Documentación
+- **`SKILL.md`/`README` describían la auto-inyección como incondicional** (#11): la prosa de "Flujo runtime" en `SKILL.md` y "Flujo de propagación" en `README.md` listaba los campos auto-inyectados (`root_id`, `trace_id`, `source`, `request_id`, ...) sin desglosar los guards. `JsonFormatter#inject_tracer_context` corta su bloque con `return unless Tracer.root_id`, y `request_id` se emite **fuera** de ese guard (distinto ciclo de vida — fix de #9). Sin esa precisión, un implementador en `box_radius_manager` concluyó (apoyándose en la doc) que "`root_id` ya cubre la trazabilidad, `request_id` es redundante" y removió un workaround necesario; en su entrypoint sin trace header `root_id` era nil → logs sin `request_id`/`source`/`root_id`. Agregada subsección "Condiciones de emisión por campo" en `SKILL.md` con tabla "campo → condición → entrypoint que la garantiza", callout en el README arriba de "Campos auto-inyectados", y enlace cruzado a `docs/behavior/behavior.md` + `docs/glossary/glossary.md` (que ya tenían el detalle).
+
+### Correcciones
+- **Clave `task` duplicada en JSON cuando `TaskMonitor.run` loguea lifecycle** (#12): `TaskMonitor` emitía `task=#{task_name}` en los KV strings de `task_started`/`task_finished` (3 sites: `task_monitor.rb:32,41,48`); `JsonFormatter#inject_tracer_context` ya inyecta la misma clave desde `Tracer.task` con Symbol — al colapsar Symbol/String en `JSON.generate`, `json` emitía `warning: detected duplicate key "task"` y la línea entera va a romper en `json` 3.0. **Fix B** (origen): los KV de lifecycle ya no emiten `task=...`; la clave viene exclusivamente del formatter vía `Tracer.task`. **Fix A** (defensa en profundidad): `JsonFormatter` normaliza todas las claves del payload a String antes de `JSON.generate`, deduplicando con precedencia "última inserción gana" (developer payload pisa contexto canónico inyectado por Tracer, igual que `log_fields`). Cubre futuros casos análogos Tracer ↔ developer KV sobre la misma clave.
+
+## [0.9.0] - 2026-05-19
+
+### Correcciones
+- **HTTP entrypoint sin trace header no emitía `root_id`/`source`/`request_id`** (#9): `HttpMiddleware` era el único entrypoint sin fallback de `root_id`. Un servicio que es punto de entrada (no eslabón intermedio de un trace distribuido) emitía log lines sin `root_id` y, por efecto cascada en `JsonFormatter#inject_tracer_context` (`return unless root_id`), sin `source` —campo mandatorio del estándar Wispro—. Ahora `HttpMiddleware` genera un `root_id` fresco cuando no llega trace header, igual que `Sidekiq::ServerMiddleware`/`BugBunny::ConsumerTracingMiddleware`/`TaskMonitor`. Además `JsonFormatter` emite `request_id` fuera del guard de `root_id` (distinto ciclo de vida: UUID v4 de Rails vs formato X-Ray), así un servicio puede correlacionar por request aunque no haya trace context activo.
+
+### Documentación
+- **Artefactos dev-\* (RFC-008/010)**: nuevos `docs/behavior/behavior.md` (RFC-007 — secuencia de hidratación de trace por entrypoint y emisión en logs, cobertura declarada) y `docs/glossary/glossary.md` (RFC-009 — lenguaje ubicuo del bounded context: `root_id`, `trace_id`, `source`, `request_id`, `entrypoint`, ...). `README.md` y `skill/SKILL.md` recompuestos indexando el detalle (indexa, no duplica): índice de artefactos, nota de coexistencia transitoria para capas F2, version-lock declarado y `description` endurecida como contrato de discoverability.
+
 ## [0.8.0] - 2026-05-14
 
 ### Nuevas funcionalidades

data/CLAUDE.md

@@ -105,9 +105,10 @@ ExisRay.configuration.json_logs?                # => true/false
 | `service` | Siempre |
 | `service_version` | Siempre (de `config.version` o `config.x.version`) |
 | `deployment_environment` | Siempre (de `Rails.env`) |
+| `request_id` | Cuando `Tracer.request_id` está presente (independiente de root_id) |
 | `root_id` | Cuando hay trace context activo |
 | `trace_id` | Cuando hay trace context activo |
-| `source` | Cuando hay trace context activo |
+| `source` | Cuando hay trace context activo (HTTP siempre genera root fresco si no llega header) |
 | `correlation_id` | Cuando `Current.correlation_id` está presente |
 | `user_id` | Cuando `Current.user_id` está presente |
 | `isp_id` | Cuando `Current.isp_id` está presente |

data/README.md

@@ -51,11 +51,24 @@ ExisRay opera en tres capas que se combinan automáticamente:
 
 **Flujo de propagación:**
 
-1. Un request/job/mensaje llega al servicio. El middleware correspondiente hidrata el `Tracer` con el header entrante (o genera un nuevo `root_id` si no trae uno).
-2. `JsonFormatter` inyecta automáticamente `root_id`, `trace_id`, `source` y el contexto de negocio (`user_id`, `isp_id`, `correlation_id`) en cada línea de log.
+1. Un request/job/mensaje llega al servicio. El middleware correspondiente hidrata el `Tracer` con el header entrante. **Todo entrypoint garantiza un `root_id`**: si no llega trace header (servicio que es punto de entrada, no eslabón intermedio), genera uno fresco. En HTTP además captura el `request_id` de Rails.
+2. `JsonFormatter` inyecta `root_id`, `trace_id`, `source`, `request_id` y el contexto de negocio (`user_id`, `isp_id`, `correlation_id`) en cada línea de log. **Cada campo tiene un guard:** `root_id`/`trace_id`/`source`/`task`/`sidekiq_job` salen solo si `Tracer.root_id` está presente; `request_id` se emite fuera de ese guard (distinto ciclo de vida). Como todo entrypoint asegura `root_id` (genera uno fresco si no llega header), `source` (mandatorio) nunca falta. Detalle por campo: tabla [Campos auto-inyectados](#campos-auto-inyectados) más abajo.
 3. Cuando el servicio llama a otro servicio (HTTP, Sidekiq, RabbitMQ), el middleware de salida genera un nuevo header con `Tracer.generate_trace_header`, que incluye el `root_id` original, el `self_id` del servicio actual, el `CalledFrom` y el tiempo acumulado.
 4. El servicio destino repite desde el paso 1. El `root_id` se mantiene constante a lo largo de toda la cadena.
 
+## Documentación de detalle
+
+Artefactos de detalle (RFC-008 — el contrato y el significado viven acá; este README indexa y resume, no duplica):
+
+| Capa | Artefacto | Estado |
+|:-----|:----------|:-------|
+| Comportamiento | [`docs/behavior/behavior.md`](docs/behavior/behavior.md) — secuencias de hidratación de trace por entrypoint y emisión en logs | parcial, incremental por PR |
+| Glosario | [`docs/glossary/glossary.md`](docs/glossary/glossary.md) — lenguaje ubicuo (`root_id`, `trace_id`, `source`, `request_id`, `entrypoint`, ...) | sembrado inicial, acreta |
+| Datos | — | n/a (gema sin DB) |
+| Operaciones · Interfaz · Topología | — | F2 `dev-structure`, no implementado |
+
+> **Coexistencia transitoria (RFC-008 §2):** las secciones _Cómo funciona_, _Campos auto-inyectados_ y _Referencia del Tracer_ de este README contienen contrato/arquitectura cuyo destino estructural (`docs/interface`, `docs/topology`) es **F2 no implementado**. Permanecen embebidas hasta que esas capas existan; el significado y las secuencias ya migraron a `docs/glossary` y `docs/behavior` y se referencian desde acá.
+
 ## Instalación
 
 ```ruby
@@ -326,7 +339,9 @@ config.logger.formatter = ExisRay::JsonFormatter
 
 ### Campos auto-inyectados
 
-`JsonFormatter` inyecta estos campos automáticamente en cada línea. **Nunca** los incluyas manualmente en tus logs:
+`JsonFormatter` inyecta estos campos automáticamente en cada línea. **Nunca** los incluyas manualmente en tus logs.
+
+> **No es incondicional.** `root_id`/`trace_id`/`source`/`task`/`sidekiq_job` están gateados por `inject_tracer_context`'s `return unless Tracer.root_id`. Los 4 entrypoints (HTTP, Sidekiq server, BugBunny consumer, TaskMonitor) garantizan el `root_id` (fresco si no llega header), por eso `source` (mandatorio) nunca falta — pero si el código loguea fuera de un entrypoint (boot, código inicializador, hilos sueltos), esos campos pueden faltar. `request_id` se emite fuera de ese guard y tiene distinto ciclo de vida.
 
 | Campo | Condición |
 |:------|:----------|
@@ -336,9 +351,10 @@ config.logger.formatter = ExisRay::JsonFormatter
 | `service` | Siempre (nombre de la app Rails en snake_case) |
 | `service_version` | Siempre (lee de `config.version` o `config.x.version`) |
 | `deployment_environment` | Siempre (lee de `Rails.env`) |
-| `root_id` | Cuando hay trace context activo |
-| `trace_id` | Cuando hay trace context activo |
-| `source` | Cuando hay trace context activo (`http`, `sidekiq`, `task`, `system`) |
+| `request_id` | Cuando `Tracer.request_id` está presente (independiente del trace context — ver [glosario](docs/glossary/glossary.md)) |
+| `root_id` | Siempre en cualquier entrypoint (genera uno fresco si no llega trace header) |
+| `trace_id` | Cuando hay trace header entrante parseado (eslabón intermedio) |
+| `source` | Siempre en cualquier entrypoint (`http`, `sidekiq`, `task`, `system`) |
 | `correlation_id` | Cuando `Current.correlation_id` está presente |
 | `user_id` | Cuando `Current.user_id` no es nil |
 | `isp_id` | Cuando `Current.isp_id` no es nil |

data/docs/behavior/behavior.md

@@ -0,0 +1,75 @@
+# Comportamiento — exis_ray
+
+> meta: artefacto · RFC-007 (UML 2.x sequence / BPMN 2.0, render Mermaid) · generado dev-enrich · anclado a commit `00cf803` (v0.8.0 + fix issue #9) · cobertura **parcial incremental**
+
+## 1. Resumen
+
+Comportamiento runtime de la trazabilidad distribuida: hidratación del `Tracer` en cada entrypoint y emisión del contexto en cada línea de log. Documentación **incremental** — este artefacto se inició con el PR del issue #9 (flujo de entrypoint HTTP); el resto de flujos se acreta cuando se tocan.
+
+## 2. Cuerpo
+
+### Cobertura (obligatoria — RFC-007 §2.a)
+
+| Flujo | Estado | Origen |
+|---|---|---|
+| Hidratación de trace en entrypoint HTTP + emisión en logs | **documentado** | PR issue #9 |
+| Hidratación en entrypoint Sidekiq (server middleware) | **referenciado** (no diagramado) | — |
+| Hidratación en entrypoint BugBunny consumer | **referenciado** (no diagramado) | — |
+| Hidratación en entrypoint TaskMonitor (Rake/Cron) | **referenciado** (no diagramado) | — |
+| Propagación saliente (Faraday / ActiveResource / BugBunny publisher) | **NO documentado** | — |
+| Ciclo de vida RPC reply (BugBunny) | **NO documentado** | — |
+
+Ausencia de un flujo en este artefacto ≠ inexistencia del flujo. Acreta por PR.
+
+### Flujo: Hidratación de trace en entrypoint HTTP + emisión en logs
+
+Invariante de paridad: los 4 entrypoints (`HttpMiddleware`, `Sidekiq::ServerMiddleware`, `BugBunny::ConsumerTracingMiddleware`, `TaskMonitor`) garantizan un `root_id` aunque no llegue trace header entrante. Antes del fix de issue #9, `HttpMiddleware` era el único sin ese fallback: un servicio que es **punto de entrada** (no eslabón intermedio) emitía logs sin `root_id`, y por efecto cascada sin `source` (campo mandatorio del estándar Wispro).
+
+```mermaid
+sequenceDiagram
+    participant Cliente
+    participant HM as HttpMiddleware
+    participant T as ExisRay::Tracer
+    participant App as Rack app / Controller
+    participant JF as JsonFormatter
+
+    Cliente->>HM: request (con o sin trace_header)
+    HM->>T: hydrate(trace_id: env[trace_header], source: "http")
+    T->>T: created_at, source="http", trace_id=...
+    T->>T: parse_trace_id
+    alt trace_header presente (eslabón intermedio)
+        T->>T: root_id = data["Root"] (parseado del header)
+    else sin trace_header (servicio entrypoint)
+        T-->>HM: root_id queda nil
+        HM->>T: root_id ||= generate_new_root  %% fix issue #9 Gap A
+        T->>T: root_id = "Root=1-<ts>-<rand>" (fresco)
+    end
+    HM->>T: request_id = env["action_dispatch.request_id"]
+    HM->>HM: ExisRay.sync_correlation_id
+    HM->>App: @app.call(env)
+    App->>JF: Rails.logger.info "event=..."
+    JF->>T: request_id?  %% issue #9 Gap C: fuera del guard de root_id
+    JF->>JF: payload[:request_id] = T.request_id (si presente)
+    JF->>T: root_id?
+    alt root_id presente (siempre en entrypoint, post-fix)
+        JF->>JF: payload += root_id, trace_id, source, ...
+    end
+    JF-->>App: línea JSON con source + correlación
+    Note over HM,App: rescue StandardError ⇒ @app.call(env) igual<br/>(logging nunca rompe el flujo principal)
+```
+
+Contexto: `JsonFormatter#inject_tracer_context` corta todo su bloque con `return unless root_id` (Gap B — efecto cascada de Gap A). El fix de Gap A (root fresco en `HttpMiddleware`) des-gatea ese bloque y `source` vuelve a emitirse. `request_id` se emite **fuera** de ese guard (Gap C): tiene distinto ciclo de vida que `root_id` (UUID v4 de Rails vs formato X-Ray) y un servicio puede querer correlación por request aunque no haya trace context.
+
+## 3. Inferencias
+
+| Afirmación | confidence | a verificar por humano |
+|---|---|---|
+| Los 4 entrypoints comparten la invariante "siempre hay root_id" | `declared` | código de los 4 middlewares lo confirma (issue #9 lo tabula) |
+| `request_id` no se emitía en ninguna línea pre-fix | `declared` | confirmado: `JsonFormatter` solo lo usaba interno vía `clean_request_id` |
+| Orden de emisión (request_id antes del guard de root_id) | `declared` | `json_formatter.rb#inject_tracer_context` post-fix |
+
+## 4. Cobertura y fronteras
+
+- **Incremental:** solo el flujo de entrypoint HTTP está diagramado. Sidekiq/BugBunny/TaskMonitor referenciados por paridad pero no diagramados (acretan cuando se toquen).
+- **Fuera de alcance:** estructura de datos (gema sin DB → no aplica), interfaz Ruby pública / topología (capas F2 de `dev-structure`, no implementadas).
+- **Significado de términos** (`root_id`, `source`, etc.) → `docs/glossary/glossary.md`.

data/docs/glossary/glossary.md

@@ -0,0 +1,76 @@
+# Glosario — exis_ray
+
+> meta: artefacto · RFC-009 (DDD ubiquitous language / bounded context + ISO 11179) · generado dev-enrich · anclado a commit `00cf803` · cobertura **parcial — sembrado inicial, acreta por PR**
+
+## 1. Resumen
+
+Lenguaje ubicuo del bounded context **exis_ray** (observabilidad/trazabilidad del ecosistema Wispro). Significado de cada término **en esta gema**. Gema sin capa de datos (`docs/data` = n/a): el `Binding` apunta al símbolo público estable que *es* el concepto (ISO 11179, materialización no-tabular), no a tablas.
+
+## 2. Cuerpo
+
+## entrypoint
+
+Punto donde la ejecución entra al servicio y nace (o se continúa) un contexto de trazabilidad. Hay exactamente 4: HTTP, Sidekiq, BugBunny consumer, TaskMonitor. **Invariante:** todo entrypoint garantiza un `root_id` — si no llega trace header entrante, genera uno fresco. Un servicio que es entrypoint sin trace upstream (ej. collector/ingest) igual emite logs correlacionables y con `source`.
+
+**Binding:** `ExisRay::HttpMiddleware`, `ExisRay::Sidekiq::ServerMiddleware`, `ExisRay::BugBunny::ConsumerTracingMiddleware`, `ExisRay::TaskMonitor`.
+
+## root_id
+
+Identificador raíz de un trace distribuido (formato AWS X-Ray: `1-<ts_hex>-<rand_hex>`, prefijado `Root=`). **Constante a lo largo de toda la cadena** de servicios: nace en el primer entrypoint y se propaga sin cambiar. Es el campo de correlación primario de logs.
+
+**Binding:** `ExisRay::Tracer.root_id`.
+
+## trace_id
+
+Header de traza entrante completo, sin parsear: `Root=...;Self=...;CalledFrom=...;TotalTimeSoFar=...ms`. Presente solo cuando el servicio es **eslabón intermedio** (recibió header upstream). Un entrypoint sin trace upstream tiene `root_id` (fresco) pero no `trace_id`.
+
+**Binding:** `ExisRay::Tracer.trace_id`.
+
+## self_id
+
+Identificador del span del servicio actual dentro del trace. Se genera por servicio y viaja en el header saliente como `Self=`.
+
+**Binding:** `ExisRay::Tracer.self_id`.
+
+## source
+
+Entrypoint de ejecución que originó la línea de log. Valores válidos: `http`, `sidekiq`, `task`, `system`. **Campo mandatorio** del estándar Wispro de logging — toda línea debe tenerlo. Se emite dentro del bloque de tracer context, que está gateado por `root_id`; por eso la invariante "todo entrypoint garantiza root_id" es lo que hace que `source` nunca falte.
+
+**Binding:** `ExisRay::Tracer.source`.
+
+## request_id
+
+UUID v4 del request HTTP, provisto por `ActionDispatch::RequestId` (`env["action_dispatch.request_id"]`). **Distinto ciclo de vida que `root_id`**: identificador por-request de Rails, no formato X-Ray, no constante a lo largo de la cadena. Se emite en logs fuera del guard de `root_id` — un servicio puede querer correlación por request aunque no haya trace context activo.
+
+**Binding:** `ExisRay::Tracer.request_id`.
+
+## correlation_id
+
+ID de correlación de negocio compuesto `ServiceName;RootID`, sincronizado al `Current` configurado por la app host. Liga logs de negocio con el trace.
+
+**Binding:** `ExisRay::Tracer.correlation_id`, `ExisRay::Current#correlation_id`.
+
+## trace context
+
+Conjunto thread-safe de atributos de trazabilidad activos en la request/job actual (`root_id`, `trace_id`, `self_id`, `source`, `request_id`, `created_at`, ...). Vive en `ActiveSupport::CurrentAttributes`; se hidrata en el entrypoint y se resetea al finalizar. "Hay trace context activo" ≡ `root_id` presente.
+
+**Binding:** `ExisRay::Tracer` (subclase de `ActiveSupport::CurrentAttributes`).
+
+## propagation header
+
+Header saliente que lleva el trace al siguiente servicio (`X-Amzn-Trace-Id` por default): `Root=...;Self=...;CalledFrom=<service>;TotalTimeSoFar=<acc>ms`. Lo genera `Tracer.generate_trace_header`. Distinto del header **entrante** (formato Rack `HTTP_X_AMZN_TRACE_ID`).
+
+**Binding:** `ExisRay::Tracer.generate_trace_header`, `ExisRay.configuration.propagation_trace_header`.
+
+## 3. Inferencias
+
+| Término | confidence | a verificar |
+|---|---|---|
+| Significado de negocio de cada término | `inferred` (LLM ancló al código; significado lo confirma humano) | revisar que la prosa refleje el uso real en servicios consumidores |
+| `trace context activo ≡ root_id presente` | `declared` | `JsonFormatter#inject_tracer_context` lo implementa literal |
+
+## 4. Cobertura y fronteras
+
+- **Sembrado inicial** disparado por PR issue #9; cubre los términos del núcleo trace/log. Acreta por PR (ausencia ≠ inexistencia).
+- **Términos no cubiertos aún:** `Reporter`/Sentry context, `total_time_so_far`, `called_from`, `log_fields`, `sidekiq_job`, `task`.
+- **Frontera:** comportamiento/secuencias → `docs/behavior/behavior.md`. Estructura de datos → n/a (gema sin DB).

data/lib/exis_ray/http_middleware.rb

@@ -13,6 +13,13 @@ module ExisRay
         trace_id: env[ExisRay.configuration.trace_header],
         source: "http"
       )
+      # Si la request no trae trace header entrante (servicio que es punto de
+      # entrada, no eslabón intermedio de un trace distribuido), generamos un
+      # root_id fresco igual que el resto de entrypoints
+      # (Sidekiq::ServerMiddleware, BugBunny::ConsumerTracingMiddleware,
+      # TaskMonitor). Sin esto root_id queda nil y JsonFormatter dropea todo
+      # el bloque de tracer, incluido `source` (campo mandatorio). Ver issue #9.
+      ExisRay::Tracer.root_id ||= ExisRay::Tracer.send(:generate_new_root)
       ExisRay::Tracer.request_id = env["action_dispatch.request_id"]
       ExisRay.sync_correlation_id
 

data/lib/exis_ray/json_formatter.rb

@@ -61,13 +61,29 @@ module ExisRay
       inject_current_tags(payload)
       process_message(payload, msg)
 
-      "#{JSON.generate(payload.compact, { ascii_only: false })}\n"
+      "#{JSON.generate(normalize_keys(payload), { ascii_only: false })}\n"
     rescue StandardError
       fallback_message(severity, timestamp, msg)
     end
 
     private
 
+    # Normaliza todas las claves del payload a strings y deduplica con precedencia
+    # "última inserción gana" (developer payload pisa contexto canónico inyectado
+    # antes, igual que `log_fields`). Previene el warning `duplicate key` que `json`
+    # emite cuando coexisten `:task` (Symbol, vía Tracer) y `"task"` (String, vía
+    # KV string developer) — `json` 3.0 lo va a transformar en error.
+    #
+    # @param payload [Hash]
+    # @return [Hash{String => Object}]
+    def normalize_keys(payload)
+      payload.each_with_object({}) do |(key, value), result|
+        next if value.nil?
+
+        result[key.to_s] = value
+      end
+    end
+
     # @return [String, nil]
     def service_version
       ExisRay.configuration.service_version
@@ -102,6 +118,12 @@ module ExisRay
     # @param payload [Hash] El diccionario del log donde se insertarán los datos.
     # @return [void]
     def inject_tracer_context(payload)
+      # `request_id` (UUID v4 de Rails) tiene distinto ciclo de vida que
+      # `root_id` (formato X-Ray). Se emite fuera del guard de `root_id`:
+      # un servicio puede querer correlación por request_id aunque no haya
+      # trace context activo. Ver issue #9 (Gap C).
+      payload[:request_id] = ExisRay::Tracer.request_id if ExisRay::Tracer.request_id
+
       return unless ExisRay::Tracer.root_id
 
       payload[:root_id]  = ExisRay::Tracer.root_id

data/lib/exis_ray/task_monitor.rb

@@ -29,7 +29,7 @@ module ExisRay
         curr.correlation_id = ExisRay::Tracer.correlation_id
       end
 
-      log_event(:info, "component=exis_ray event=task_started task=#{task_name} outcome=started")
+      log_event(:info, "component=exis_ray event=task_started outcome=started")
 
       # Bloque de ejecución con o sin tags dependiendo de la configuración
       execute_with_optional_tags(&block)
@@ -38,14 +38,14 @@ module ExisRay
       human_time = ExisRay::Tracer.format_duration(duration_s)
 
       log_event(:info,
-                "component=exis_ray event=task_finished task=#{task_name} " \
+                "component=exis_ray event=task_finished " \
                 "outcome=success duration_s=#{duration_s} duration_human=\"#{human_time}\"")
     rescue StandardError => e
       duration_s = ExisRay::Tracer.current_duration_s
       human_time = ExisRay::Tracer.format_duration(duration_s)
 
       log_event(:error,
-                "component=exis_ray event=task_finished task=#{task_name} " \
+                "component=exis_ray event=task_finished " \
                 "outcome=failed duration_s=#{duration_s} duration_human=\"#{human_time}\" " \
                 "error_class=#{e.class} error_message=#{e.message.inspect} " \
                 "exception.type=#{e.class} exception.message=#{e.message.inspect} " \

data/lib/exis_ray/version.rb

@@ -2,5 +2,5 @@
 
 module ExisRay
   # Versión actual de la gema.
-  VERSION = "0.8.0"
+  VERSION = "0.10.0"
 end

data/skill/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: exis-ray
-description: Skill de conocimiento completo sobre ExisRay, la capa de observabilidad y trazabilidad distribuida del ecosistema Wispro. Consultame para integración, arquitectura, API, errores y antipatrones.
+description: Conocimiento completo de ExisRay, la capa de observabilidad y trazabilidad distribuida del ecosistema Wispro (logging JSON estructurado, trace context AWS X-Ray, propagación entre servicios). ACTIVAR cuando un servicio o gema Rails integra/configura ExisRay, emite o debuggea logs JSON estructurados, propaga trace context (header X-Amzn-Trace-Id) entre HTTP/Sidekiq/BugBunny, usa ExisRay::Tracer/Current/Reporter/JsonFormatter/TaskMonitor, edita el initializer de ExisRay, o resuelve errores/antipatrones de logging-trazabilidad Wispro.
 ---
 
 # ExisRay Expert
@@ -9,6 +9,14 @@ Observabilidad y trazabilidad distribuida para microservicios Rails (AWS X-Ray c
 
 Para el complemento del estándar de logging Wispro (regla Data First, mapeo OpenTelemetry, ciclo de vida de jobs/requests), ver `references/standard.md`.
 
+### Artefactos de detalle (RFC-008)
+
+Este SKILL.md **resume e indexa**; el contrato y el significado de detalle viven en `docs/<capa>/`. **Version-lock por construcción:** `gemspec.files` empaqueta `docs/**` en el mismo tag que este `SKILL.md`; los links son rutas relativas dentro del paquete del release (nunca rama/`HEAD`/URL flotante). Contrato resumido anclado a **v0.10.0** (post fix issues #9, #11, #12):
+
+- [`docs/behavior/behavior.md`](../docs/behavior/behavior.md) — secuencias de hidratación de trace por entrypoint + emisión en logs (parcial, incremental).
+- [`docs/glossary/glossary.md`](../docs/glossary/glossary.md) — lenguaje ubicuo del bounded context (`root_id`, `trace_id`, `source`, `request_id`, `entrypoint`, ...).
+- Datos = n/a (gema sin DB). Operaciones/Interfaz/Topología = F2 `dev-structure`, no implementado: contrato Ruby permanece embebido abajo (coexistencia transitoria RFC-008 §2).
+
 ---
 
 ## Glosario
@@ -67,11 +75,11 @@ ExisRay unifica trazabilidad distribuida, logging estructurado JSON, contexto de
 
 ### Flujo runtime (HTTP request)
 
-1. `HttpMiddleware` lee `trace_header` del env Rack, llama `Tracer.hydrate(trace_id:, source: "http")`
+1. `HttpMiddleware` lee `trace_header` del env Rack, llama `Tracer.hydrate(trace_id:, source: "http")`. **Si no llega header** (servicio entrypoint, no eslabón intermedio) genera un `root_id` fresco — paridad con `Sidekiq::ServerMiddleware`/`BugBunny::ConsumerTracingMiddleware`/`TaskMonitor`. Captura `request_id` de `action_dispatch.request_id`. Secuencia detallada: `docs/behavior/behavior.md`.
 2. `Tracer.parse_trace_id` extrae `root_id`, `self_id`, `called_from`, `total_time_so_far`
 3. `ExisRay.sync_correlation_id` asigna `Tracer.correlation_id` a `Current.correlation_id`
 4. Controller ejecuta `before_action` para setear `Current.user_id`, `Current.isp_id`
-5. `JsonFormatter` intercepta cada `Rails.logger.*` e inyecta automaticamente: `time`, `level`, `severity_number`, `service`, `service_version`, `deployment_environment`, `root_id`, `trace_id`, `source`, `user_id`, `isp_id`, `correlation_id`. El developer aporta `component` (modulo de negocio) y `event` (que paso); estos NO son auto-inyectados porque dependen del call site, no del contexto de ejecucion.
+5. `JsonFormatter` intercepta cada `Rails.logger.*` e inyecta el contexto de ejecucion en cada linea. **No es incondicional:** cada campo tiene un guard especifico (ver tabla "Condiciones de emision" mas abajo). En particular `inject_tracer_context` corta el bloque `root_id`/`trace_id`/`source`/`task`/`sidekiq_job` con `return unless Tracer.root_id` — la invariante "todo entrypoint garantiza `root_id`" es lo que hace que `source` (mandatorio) nunca falte. `request_id` se emite **fuera** de ese guard (distinto ciclo de vida que `root_id`). El developer aporta `component` (modulo de negocio) y `event` (que paso); estos NO son auto-inyectados porque dependen del call site, no del contexto de ejecucion.
 6. `LogSubscriber` emite un unico Hash al finalizar el request con campos default (`component`, `event`, `method`, `path`, `http_route`, `format`, `controller`, `action`, `http_status`, `duration_s`, `duration_human`, `view_runtime_s`, `db_runtime_s`, `user_agent_original`, `server_address`, y en error `error_class`/`error_message`/`exception.*`).
 7. En llamadas salientes, `FaradayMiddleware`/`ActiveResourceInstrumentation` inyectan `propagation_trace_header` con `Tracer.generate_trace_header`
 8. Al finalizar, `ActiveSupport::CurrentAttributes` hace reset automatico
@@ -287,6 +295,26 @@ Casteo automatico: integers, floats, objetos JSON (`{...}`, `[...]`). Filtra cla
 
 Por eso `component` y `event` jamas se auto-inyectan, aunque el estandar Wispro los exija.
 
+#### Condiciones de emision por campo
+
+La auto-inyeccion **no es incondicional**: cada campo tiene un guard. `inject_tracer_context` corta su bloque con `return unless Tracer.root_id`, asi que `root_id`/`trace_id`/`source`/`task`/`sidekiq_job` solo se emiten cuando hay trace context activo. Los 4 entrypoints (HTTP, Sidekiq server, BugBunny consumer, TaskMonitor) garantizan ese `root_id` (fresco si no llega header), por eso `source` (mandatorio) nunca falta en una linea originada por un entrypoint. `request_id` se emite **fuera** del guard de `root_id` — distinto ciclo de vida.
+
+| Campo | Condicion de emision | Entrypoint que la garantiza |
+|:------|:---------------------|:----------------------------|
+| `time`, `level`, `severity_number`, `service`, `service_version`, `deployment_environment` | Siempre (no depende de Tracer/Current) | — |
+| `request_id` | `Tracer.request_id` presente. **Fuera del guard de `root_id`** (issue #9 Gap C): distinto ciclo de vida (UUID v4 de Rails vs formato X-Ray). | HTTP (via `ActionDispatch::RequestId`). Otros entrypoints solo si la app lo setea explicitamente. |
+| `root_id` | `Tracer.root_id` presente. **Gatea todo el bloque de tracer context.** | Los 4 entrypoints garantizan `root_id` fresco si no llega trace header (issue #9 Gap A). |
+| `source` | `Tracer.source` presente **y** `root_id` presente (esta dentro del bloque gateado). | Idem `root_id`. Como `source` es mandatorio del estandar Wispro, la invariante "todo entrypoint garantiza `root_id`" es lo que evita que falte. |
+| `trace_id` | `Tracer.trace_id` presente **y** `root_id` presente. Solo cuando el servicio es **eslabon intermedio** (recibio trace header upstream). | — (entrypoint que no recibe header tiene `root_id` fresco pero `trace_id` nil). |
+| `sidekiq_job` | `Tracer.sidekiq_job` presente **y** `root_id` presente. | Sidekiq `ServerMiddleware`. |
+| `task` | `Tracer.task` presente **y** `root_id` presente. | `TaskMonitor.run`. |
+| `correlation_id` | `Current.correlation_id` presente. | `ExisRay.sync_correlation_id` (HTTP middleware lo llama; otros entrypoints solo si la app lo invoca). |
+| `user_id`, `isp_id` | `Current.<attr>` no nil. | Lo setea la app (login, before_actions, etc.). |
+| `Current.log_fields` (cualquier key) | La subclass de `Current` overrideo el hook y retorno un Hash no vacio. | — |
+| `tags` | Rails tagged logging activo. **Antipatron con JSON** (rompe el formato) — ver FAQ. | — |
+
+Para el detalle por entrypoint (que setea que y cuando), ver [`docs/behavior/behavior.md`](../docs/behavior/behavior.md). Para el significado de cada campo, [`docs/glossary/glossary.md`](../docs/glossary/glossary.md).
+
 #### Ejemplos: KV vs Hash producen output equivalente
 
 ```ruby

data/skills.yml

@@ -2,48 +2,34 @@ mcps:
   - github
   - clickup
 skills:
-  skill-manager:
-    repo: sequre/ai_knowledge
-    scope: local
   yard:
     repo: sequre/ai_knowledge
-    scope: local
   quality-code:
     repo: sequre/ai_knowledge
-    scope: local
   gem-release:
     repo: sequre/ai_knowledge
-    scope: local
-  skill-builder:
+  dev-structure:
     repo: sequre/ai_knowledge
-    scope: local
-  ai-reports:
+  dev-compose:
     repo: sequre/ai_knowledge
-    scope: local
-    environment:
-      space_id: "${AI_REPORTS_SPACE_ID}"
-      bug_reports_list_id: "${AI_REPORTS_BUG_REPORTS_LIST_ID}"
-      improvements_list_id: "${AI_REPORTS_IMPROVEMENTS_LIST_ID}"
-  agent-review:
+  dev-enrich:
     repo: sequre/ai_knowledge
-    scope: local
-    environment:
-      space_id: "${AGENT_REVIEW_SAPCE_ID}"
-      list_id: "${AGENT_LIST_ID}"
-  action-plan:
+  skill-feedback:
+    repo: sequre/ai_knowledge
+  agent-issue:
+    repo: sequre/ai_knowledge
+  dev-flow:
+    repo: sequre/ai_knowledge
+  matrix-element:
     repo: sequre/ai_knowledge
     environment:
-      space_id: "${AGENT_REVIEW_SAPCE_ID}"
-      list_id: "${AGENT_ACTION_PLAN_LIST_ID}"
+      homeserver: "https://matrix.cloud.wispro.co"
+      auth_token: "${MATRIX_AUTH_TOKEN}"
+      rooms:
+        agents: "!VCHwQXgmXdyhhhPhoz:matrix.cloud.wispro.co"
   documentation-writer:
     repo: github/awesome-copilot
     path: skills/documentation-writer
-    scope: local
-  find-skills:
-    repo: vercel-labs/skills
-    path: skills/find-skills
-    scope: local
   opentelemetry:
     repo: bobmatnyc/claude-mpm-skills
     path: universal/observability/opentelemetry
-    scope: local

data/spec/exis_ray/http_middleware_spec.rb

@@ -0,0 +1,68 @@
+# frozen_string_literal: true
+
+require "spec_helper"
+
+RSpec.describe ExisRay::HttpMiddleware do
+  subject(:middleware) { described_class.new(app) }
+
+  let(:app) { ->(_env) { [200, {}, ["ok"]] } }
+  let(:trace_header) { ExisRay.configuration.trace_header }
+
+  after { ExisRay::Tracer.reset }
+
+  describe "#call" do
+    context "cuando la request NO trae trace header entrante (entrypoint, issue #9 Gap A)" do
+      let(:env) { { "action_dispatch.request_id" => "req-uuid-123" } }
+
+      it "genera un root_id fresco igual que los demás entrypoints" do
+        middleware.call(env)
+
+        expect(ExisRay::Tracer.root_id).to match(/\ARoot=1-/)
+      end
+
+      it "setea source=http (des-gatea el bloque de tracer en JsonFormatter, Gap B)" do
+        middleware.call(env)
+
+        expect(ExisRay::Tracer.source).to eq("http")
+      end
+
+      it "setea request_id desde el env de Rails" do
+        middleware.call(env)
+
+        expect(ExisRay::Tracer.request_id).to eq("req-uuid-123")
+      end
+    end
+
+    context "cuando la request trae trace header entrante (eslabón intermedio)" do
+      let(:env) do
+        {
+          trace_header => "Root=1-5759b146-abc123;Self=1-5759b146-def456;CalledFrom=upstream",
+          "action_dispatch.request_id" => "req-uuid-456"
+        }
+      end
+
+      it "respeta el root_id entrante y no genera uno nuevo" do
+        middleware.call(env)
+
+        expect(ExisRay::Tracer.root_id).to eq("1-5759b146-abc123")
+      end
+
+      it "setea source=http y request_id" do
+        middleware.call(env)
+
+        expect(ExisRay::Tracer.source).to eq("http")
+        expect(ExisRay::Tracer.request_id).to eq("req-uuid-456")
+      end
+    end
+
+    it "invoca la app y retorna su respuesta" do
+      expect(middleware.call({})).to eq([200, {}, ["ok"]])
+    end
+
+    it "no rompe el flujo principal si la hidratación falla" do
+      allow(ExisRay::Tracer).to receive(:hydrate).and_raise(StandardError)
+
+      expect(middleware.call({})).to eq([200, {}, ["ok"]])
+    end
+  end
+end

data/spec/exis_ray/json_formatter_spec.rb

@@ -15,6 +15,7 @@ RSpec.describe ExisRay::JsonFormatter do
       def self.service_name = "test-service"
       def self.root_id      = nil
       def self.trace_id     = nil
+      def self.request_id   = nil
     end)
 
     allow(ExisRay).to receive(:current_class).and_return(nil)
@@ -406,6 +407,128 @@ RSpec.describe ExisRay::JsonFormatter do
     end
   end
 
+  describe "inyección de contexto de tracer (issue #9)" do
+    def stub_tracer(root_id:, request_id:, source:, trace_id: nil)
+      stub_const("ExisRay::Tracer", Module.new do
+        define_singleton_method(:service_name) { "test-service" }
+        define_singleton_method(:root_id) { root_id }
+        define_singleton_method(:trace_id) { trace_id }
+        define_singleton_method(:request_id) { request_id }
+        define_singleton_method(:source) { source }
+        define_singleton_method(:sidekiq_job) { nil }
+        define_singleton_method(:task) { nil }
+      end)
+    end
+
+    context "cuando hay trace context activo (root_id presente)" do
+      before { stub_tracer(root_id: "1-abc-def", request_id: "uuid-1", source: "http", trace_id: "Root=1-abc-def") }
+
+      it "emite root_id, trace_id, source y request_id" do
+        result = call("event=acct.received")
+
+        expect(result).to include(
+          "root_id" => "1-abc-def",
+          "trace_id" => "Root=1-abc-def",
+          "source" => "http",
+          "request_id" => "uuid-1"
+        )
+      end
+    end
+
+    context "cuando NO hay trace context (root_id nil) pero sí request_id (Gap C)" do
+      before { stub_tracer(root_id: nil, request_id: "uuid-2", source: "http") }
+
+      it "emite request_id aunque root_id esté ausente" do
+        result = call("event=acct.received")
+
+        expect(result["request_id"]).to eq("uuid-2")
+      end
+
+      it "no emite root_id ni trace_id" do
+        result = call("event=acct.received")
+
+        expect(result).not_to have_key("root_id")
+        expect(result).not_to have_key("trace_id")
+      end
+    end
+
+    context "cuando no hay request_id" do
+      before { stub_tracer(root_id: "1-x-y", request_id: nil, source: "http") }
+
+      it "no incluye la clave request_id" do
+        result = call("event=acct.received")
+
+        expect(result).not_to have_key("request_id")
+      end
+    end
+  end
+
+  describe "dedup de claves Symbol/String (issue #12)" do
+    def stub_tracer_with_task(task_value)
+      stub_const("ExisRay::Tracer", Module.new do
+        define_singleton_method(:service_name) { "test-service" }
+        define_singleton_method(:root_id) { "1-abc-def" }
+        define_singleton_method(:trace_id) { nil }
+        define_singleton_method(:request_id) { nil }
+        define_singleton_method(:source) { "task" }
+        define_singleton_method(:sidekiq_job) { nil }
+        define_singleton_method(:task) { task_value }
+      end)
+    end
+
+    it "no emite warning de `duplicate key` cuando KV string y Tracer setean la misma key" do
+      stub_tracer_with_task("billing:invoices")
+
+      warning = nil
+      original_warn = Warning.method(:warn)
+      Warning.singleton_class.define_method(:warn) { |msg, **| warning = msg }
+
+      begin
+        call("event=task_started task=billing:invoices outcome=started")
+      ensure
+        Warning.singleton_class.define_method(:warn, original_warn)
+      end
+
+      expect(warning).to be_nil
+    end
+
+    it "developer payload (KV string) pisa al contexto canónico inyectado por Tracer" do
+      stub_tracer_with_task("billing:invoices")
+
+      result = call("event=foo task=override outcome=success")
+
+      expect(result["task"]).to eq("override")
+    end
+
+    it "emite la key como String aunque internamente fuese Symbol" do
+      stub_tracer_with_task("billing:invoices")
+
+      json_str = formatter.call(severity, timestamp, progname, "event=task_started outcome=started")
+
+      # Si quedaran ambas (`:task` y `"task"`) el JSON tendría dos veces la key.
+      expect(json_str.scan(/"task"\s*:/).size).to eq(1)
+      expect(JSON.parse(json_str)["task"]).to eq("billing:invoices")
+    end
+
+    it "no incluye keys con valor nil en el output" do
+      stub_const("ExisRay::Tracer", Module.new do
+        define_singleton_method(:service_name) { "test-service" }
+        define_singleton_method(:root_id) { nil }
+        define_singleton_method(:trace_id) { nil }
+        define_singleton_method(:request_id) { nil }
+        define_singleton_method(:source) { nil }
+        define_singleton_method(:sidekiq_job) { nil }
+        define_singleton_method(:task) { nil }
+      end)
+
+      result = call("event=foo")
+
+      expect(result).not_to have_key("root_id")
+      expect(result).not_to have_key("task")
+      expect(result).not_to have_key("source")
+    end
+  end
+
   describe "#filter_sensitive_hash (privado)" do
     it "filtra claves sensibles en el nivel raíz" do
       result = formatter.send(:filter_sensitive_hash, { user: "gabriel", password: "secret" })

data/spec/exis_ray/task_monitor_spec.rb

@@ -49,7 +49,22 @@ RSpec.describe ExisRay::TaskMonitor do
         expect(start_log[0]).to eq(:info)
         expect(start_log[1]).to include("outcome=started")
         expect(start_log[1]).to include("event=task_started")
-        expect(start_log[1]).to include("task=billing:invoices")
+      end
+
+      it "no emite `task=` en el KV (la clave viene del formatter vía Tracer.task)" do
+        captured_task = nil
+        described_class.run("billing:invoices") { captured_task = ExisRay::Tracer.task }
+
+        # task_name vive en el Tracer durante la ejecución del bloque
+        expect(captured_task).to eq("billing:invoices")
+
+        # Los KV de lifecycle NO incluyen `task=...` — evita la duplicación con
+        # `JsonFormatter#inject_tracer_context` (issue #12).
+        lifecycle = captured_logs.map { |_, msg| msg }.select { |m| m.include?("event=task_") }
+        expect(lifecycle).not_to be_empty
+        lifecycle.each do |msg|
+          expect(msg).not_to match(/\btask=/)
+        end
       end
 
       it "loguea task_finished con outcome=success (breaking rename v0.6.0)" do

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: exis_ray
 version: !ruby/object:Gem::Version
-  version: 0.8.0
+  version: 0.10.0
 platform: ruby
 authors:
 - Gabriel Edera
 autorequire:
 bindir: exe
 cert_chain: []
-date: 2026-05-14 00:00:00.000000000 Z
+date: 2026-05-25 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: activesupport
@@ -51,6 +51,8 @@ files:
 - LICENSE.txt
 - README.md
 - Rakefile
+- docs/behavior/behavior.md
+- docs/glossary/glossary.md
 - lib/exis_ray.rb
 - lib/exis_ray/active_resource_instrumentation.rb
 - lib/exis_ray/bug_bunny/consumer_tracing_middleware.rb
@@ -75,6 +77,7 @@ files:
 - skills.yml
 - spec/exis_ray/configuration_spec.rb
 - spec/exis_ray/current_spec.rb
+- spec/exis_ray/http_middleware_spec.rb
 - spec/exis_ray/json_formatter_spec.rb
 - spec/exis_ray/log_subscriber_spec.rb
 - spec/exis_ray/reporter_spec.rb
@@ -87,8 +90,8 @@ licenses:
 metadata:
   homepage_uri: https://github.com/gedera/exis_ray
   source_code_uri: https://github.com/gedera/exis_ray
-  changelog_uri: https://github.com/gedera/exis_ray/blob/v0.8.0/CHANGELOG.md
-  documentation_uri: https://github.com/gedera/exis_ray/blob/v0.8.0/skill
+  changelog_uri: https://github.com/gedera/exis_ray/blob/v0.10.0/CHANGELOG.md
+  documentation_uri: https://github.com/gedera/exis_ray/blob/v0.10.0/skill
 post_install_message:
 rdoc_options: []
 require_paths: