e11y 0.2.0 → 1.0.0

data/docs/use_cases/UC-001-request-scoped-debug-buffering.md

@@ -234,7 +234,7 @@ end
 > config.pipeline.use RoutingMiddleware         # 6. Buffer routing (LAST!)
 > ```
 > 
-> **See:** [ADR-001 Section 4.1: Middleware Execution Order](../ADR-001-architecture.md#41-middleware-execution-order-critical) and [ADR-015: Middleware Order Reference](../ADR-015-middleware-order.md) for detailed explanation.
+> **See:** [ADR-001 Section 4.1: Middleware Execution Order](../architecture/ADR-001-architecture.md#41-middleware-execution-order-critical) and [ADR-015: Middleware Order Reference](../architecture/ADR-015-middleware-order.md) for detailed explanation.
 
 ---
 
@@ -275,7 +275,7 @@ end
 
 ### Dual-Buffer Architecture
 
-**E11y использует ДВА независимых буфера:**
+**E11y uses TWO independent buffers:**
 
 ```
 ┌─────────────────────────────────────────────────────────────────┐
@@ -318,15 +318,15 @@ Background Flush Thread (200ms interval):
 ### Buffer Routing Logic
 
 ```ruby
-# Pseudo-code для понимания
+# Pseudo-code for understanding
 def track_event(event)
   if event.severity == :debug && E11y.request_scope.active?
     # → Request-scoped buffer (Thread-local)
-    Thread.current[:e11y_request_buffer] << event
+    Thread.current[:e11y_ephemeral_buffer] << event
   else
     # → Main buffer (Global SPSC ring buffer)
     E11y.main_buffer << event
-    # Фоновый поток заберет через 200ms (или раньше если батч заполнится)
+    # Background thread will pick up in 200ms (or sooner if batch fills)
   end
 end
 ```
@@ -401,11 +401,17 @@ module E11y::RequestScope
 end
 ```
 
+> **DevLog integration (development/test):** When the debug buffer is flushed on request
+> failure, events are delivered to all registered adapters — including
+> `E11y::Adapters::DevLog` (auto-registered in development/test via Railtie). Debug
+> events from failed requests automatically appear in `log/e11y_dev.jsonl` and become
+> visible in the TUI and Browser Overlay. See [UC-017](UC-017-local-development.md).
+
 ---
 
 ## 📈 Performance Impact
 
-> **Implementation:** See [ADR-001 Section 8.3: Resource Limits](../ADR-001-architecture.md#83-resource-limits) for architectural details and [ADR-002 Section 6: Self-Monitoring](../ADR-002-metrics-yabeda.md#6-self-monitoring) for metrics implementation.
+> **Implementation:** See [ADR-001 Section 8.3: Resource Limits](../architecture/ADR-001-architecture.md#83-resource-limits) for architectural details and [ADR-002 Section 6: Self-Monitoring](../ADR-002-metrics-yabeda.md#6-self-monitoring) for metrics implementation.
 
 ### Buffer Metrics
 
@@ -413,20 +419,20 @@ end
 
 ```ruby
 # Exposed via Yabeda (auto-configured)
-Yabeda.e11y_request_buffer_size  # Gauge: current buffer size per request
-Yabeda.e11y_request_buffer_flushes_total  # Counter: buffer flushes by trigger
+Yabeda.e11y_ephemeral_buffer_size  # Gauge: current buffer size per request
+Yabeda.e11y_ephemeral_buffer_flushes_total  # Counter: buffer flushes by trigger
 
 # Accessible via Prometheus metrics endpoint
 # Example queries:
 
 # 1. Average buffer size
-avg(e11y_request_buffer_size)
+avg(e11y_ephemeral_buffer_size)
 
 # 2. Buffer flush rate by trigger
-rate(e11y_request_buffer_flushes_total{trigger="error"}[5m])
+rate(e11y_ephemeral_buffer_flushes_total{trigger="error"}[5m])
 
 # 3. Buffer overflow alerts
-e11y_request_buffer_size >= 100  # Alert if buffer limit reached
+e11y_ephemeral_buffer_size >= 100  # Alert if buffer limit reached
 ```
 
 **Monitoring Examples:**
@@ -436,18 +442,18 @@ e11y_request_buffer_size >= 100  # Alert if buffer limit reached
 
 # Panel 1: Buffer Size Distribution
 histogram_quantile(0.99, 
-  sum(rate(e11y_request_buffer_size[5m])) by (le)
+  sum(rate(e11y_ephemeral_buffer_size[5m])) by (le)
 )
 # Shows p99 buffer size
 
 # Panel 2: Flush Triggers Breakdown
 sum by (trigger) (
-  rate(e11y_request_buffer_flushes_total[5m])
+  rate(e11y_ephemeral_buffer_flushes_total[5m])
 )
 # Shows why buffers flush (error vs. slow_request vs. custom)
 
 # Panel 3: Memory Impact Estimate
-avg(e11y_request_buffer_size) * 500  # bytes per event
+avg(e11y_ephemeral_buffer_size) * 500  # bytes per event
 # Estimates per-request memory usage
 ```
 
@@ -609,13 +615,13 @@ end
 
 ---
 
-## 🔄 Взаимодействие с Flush Interval (200ms)
+## 🔄 Interaction with Flush Interval (200ms)
 
-### Вопрос: Не конфликтуют ли буферы?
+### Question: Do the buffers conflict?
 
-**Ответ: НЕТ. Они независимы.**
+**Answer: NO. They are independent.**
 
-### Детальная Логика
+### Detailed Logic
 
 ```ruby
 # config/initializers/e11y.rb
@@ -636,9 +642,9 @@ E11y.configure do |config|
 end
 ```
 
-### Поток Событий
+### Event Flow
 
-**Scenario 1: Обычный запрос (успешный)**
+**Scenario 1: Normal request (successful)**
 ```ruby
 # Request starts
 Events::DebugEvent.track(...)          # → Request buffer (thread-local)
@@ -650,7 +656,7 @@ Events::DebugEvent.track(...)          # → Request buffer (thread-local)
 # → Main buffer flushed every 200ms (success event sent)
 ```
 
-**Scenario 2: Запрос с ошибкой**
+**Scenario 2: Request with error**
 ```ruby
 # Request starts
 Events::DebugEvent.track(...)          # → Request buffer
@@ -662,20 +668,20 @@ Events::DebugEvent.track(...)          # → Request buffer
 # → Main buffer continues flush every 200ms (error event sent)
 ```
 
-**Scenario 3: Высоконагруженный сервис**
+**Scenario 3: High-load service**
 ```ruby
-# 1000 requests/sec, каждый с 5 debug events
-# → 5000 debug events/sec в request buffers (thread-local)
-# → 99% успешных → 4950 debug events/sec DISCARDED
-# → 1% ошибок → 50 debug events/sec FLUSHED
+# 1000 requests/sec, each with 5 debug events
+# → 5000 debug events/sec in request buffers (thread-local)
+# → 99% successful → 4950 debug events/sec DISCARDED
+# → 1% errors → 50 debug events/sec FLUSHED
 # 
-# Параллельно:
+# In parallel:
 # → 1000 info/success events/sec → Main buffer
-# → Flush каждые 200ms = 5 batches/sec
-# → 200 events per batch (в среднем)
+# → Flush every 200ms = 5 batches/sec
+# → 200 events per batch (on average)
 ```
 
-### Итого: Никакого Конфликта!
+### Summary: No Conflict!
 
 | Event Type | Buffer | Flush Trigger | Latency |
 |------------|--------|---------------|---------|
@@ -686,14 +692,14 @@ Events::DebugEvent.track(...)          # → Request buffer
 | `:error` | Main buffer (Global SPSC) | Every 200ms (background thread) | <200ms |
 | `:fatal` | Main buffer (Global SPSC) | Every 200ms (background thread) | <200ms |
 
-**Преимущества двойного буфера:**
-1. ✅ Debug события не засоряют main buffer
-2. ✅ Важные события (info+) идут быстро (200ms)
-3. ✅ Debug события идут мгновенно при ошибке (flush triggered)
-4. ✅ 99% debug событий вообще не обрабатываются (discard = zero cost)
-5. ✅ Thread-safety: request buffer изолирован в Thread.current
+**Benefits of dual buffer:**
+1. ✅ Debug events don't clutter main buffer
+2. ✅ Important events (info+) go fast (200ms)
+3. ✅ Debug events go instantly on error (flush triggered)
+4. ✅ 99% of debug events are never processed (discard = zero cost)
+5. ✅ Thread-safety: request buffer isolated in Thread.current
 
-### Визуальная Диаграмма
+### Visual Diagram
 
 ```
 Time: ──────────────────────────────────────────────────>
@@ -720,14 +726,14 @@ Background Flush Thread:   │  │
               200ms          400ms
 ```
 
-### Пример с Цифрами
+### Example with Numbers
 
-**Нагрузка:**
+**Load:**
 - 100 requests/sec
-- Каждый запрос: 3 debug события + 1 success событие
+- Each request: 3 debug events + 1 success event
 - Error rate: 1%
 
-**Что происходит:**
+**What happens:**
 
 | Time | Request Buffer (Thread-local) | Main Buffer (Global) | Flush |
 |------|------------------------------|---------------------|-------|
@@ -739,8 +745,8 @@ Background Flush Thread:   │  │
 | 210ms | Req21: [D, D, D] ERROR! | [S21, E21, **D, D, D from Req21**] | **Immediate flush debug** |
 | 400ms | - | [S21...S40] | **Flush next batch** |
 
-**Результат:**
-- Success events: ~100/sec → flush каждые 200ms → latency <200ms ✅
+**Result:**
+- Success events: ~100/sec → flush every 200ms → latency <200ms ✅
 - Debug events (99%): DISCARDED → zero overhead ✅
 - Debug events (1% errors): flushed IMMEDIATELY with error context ✅
 
@@ -804,7 +810,7 @@ end
 
 - **[UC-002: Business Event Tracking](./UC-002-business-event-tracking.md)** - Define structured events
 - **[UC-010: Background Job Tracking](./UC-010-background-job-tracking.md)** - Buffering in Sidekiq/ActiveJob
-- **[UC-015: Local Development](./UC-015-local-development.md)** - Test buffering locally
+- **[UC-017: Local Development](./UC-017-local-development.md)** - Test buffering locally
 
 ---
 

data/docs/use_cases/UC-002-business-event-tracking.md

@@ -42,7 +42,7 @@ Events::OrderPaid.track(
 
 # Result:
 # 1. Structured log in ELK/Loki (JSON)
-# 2. Auto-generated metrics (pattern-based)
+# 2. Event metrics (from metrics do block)
 # 3. Trace context (automatic correlation)
 ```
 
@@ -102,22 +102,13 @@ class OrdersController < ApplicationController
   end
 end
 
-# Step 3: Configure pattern-based metrics (config/initializers/e11y.rb)
-E11y.configure do |config|
-  config.metrics do
-    # Counter: orders.created.total
-    counter_for pattern: 'order.created',
-                name: 'orders.created.total',
-                tags: [:currency]
-    
-    # Histogram: orders.created.amount
-    histogram_for pattern: 'order.created',
-                  name: 'orders.created.amount',
-                  value: ->(e) { e.payload[:total_amount] },
-                  tags: [:currency],
-                  buckets: [10, 50, 100, 500, 1000, 5000]
-  end
-end
+# Step 3: Add metrics in event class
+# class Events::OrderCreated < E11y::Event::Base
+#   metrics do
+#     counter :orders_created_total, tags: [:currency]
+#     histogram :orders_created_amount, value: :total_amount, tags: [:currency], buckets: [10, 50, 100, 500]
+#   end
+# end
 ```
 
 **Result in Logs (Loki/ELK):**
@@ -231,21 +222,7 @@ class RegistrationsController < ApplicationController
   end
 end
 
-# Metrics configuration
-E11y.configure do |config|
-  config.metrics do
-    # Funnel counter
-    counter_for pattern: 'registration.*',
-                name: 'registration.funnel.total',
-                tags: [:event_name, :source]
-    
-    # Time to first login
-    histogram_for pattern: 'first.login',
-                  name: 'registration.time_to_first_login_hours',
-                  value: ->(e) { e.payload[:time_since_registration_hours] },
-                  buckets: [1, 6, 12, 24, 48, 72, 168]  # hours
-  end
-end
+# Add metrics do in each event class (Events::RegistrationStarted, Events::EmailVerified, etc.)
 ```
 
 **Funnel Analysis (Grafana/Prometheus):**
@@ -353,28 +330,7 @@ class ProcessPaymentJob < ApplicationJob
   end
 end
 
-# Metrics
-E11y.configure do |config|
-  config.metrics do
-    # Success rate (critical metric!)
-    success_rate_for pattern: 'payment.*',
-                     name: 'payments.success_rate',
-                     tags: [:payment_method]
-    # Auto-calculates: succeeded / (succeeded + failed) * 100
-    
-    # Payment duration (performance)
-    histogram_for pattern: 'payment.succeeded',
-                  value: ->(e) { e.duration_ms },
-                  name: 'payments.duration_ms',
-                  tags: [:payment_method],
-                  buckets: [100, 250, 500, 1000, 2000, 5000]
-    
-    # Failed payments by error code (debugging)
-    counter_for pattern: 'payment.failed',
-                name: 'payments.failed.total',
-                tags: [:error_code, :payment_method]
-  end
-end
+# Add metrics do in PaymentSucceeded, PaymentFailed event classes
 ```
 
 **Alerts (Prometheus):**
@@ -505,7 +461,7 @@ module Events
     rate_limit 1000
     sample_rate 1.0  # Never sample payments (high-value)
     retention 7.years  # Financial records
-    adapters [:loki, :sentry, :s3_archive]
+    adapters [:loki, :sentry]
     
     # Common PII filtering
     contains_pii true
@@ -605,7 +561,7 @@ module E11y
         rate_limit 10_000
         sample_rate 1.0  # Never sample
         retention 7.years
-        adapters [:loki, :sentry, :s3_archive]
+        adapters [:loki, :sentry]
       end
     end
     
@@ -669,7 +625,7 @@ module Events
         rate_limit 5000
         sample_rate 1.0
         retention 7.years
-        adapters [:loki, :elasticsearch, :s3_archive, :slack_business]
+        adapters [:loki, :elasticsearch, :slack_business]
         
         metric :counter,
                name: 'critical_business_events.total',
@@ -1051,9 +1007,7 @@ E11y.configure do |config|
     config.register_adapter :loki, E11y::Adapters::LokiAdapter.new(
       url: ENV['LOKI_URL']
     )
-    config.register_adapter :s3_archive, E11y::Adapters::S3Adapter.new(
-      bucket: 'payment-archive'
-    )
+    # Archival: external jobs filter Loki by retention_until (ISO8601) for tier migration
     config.default_adapters = [:loki]
     
   when 'staging'
@@ -1082,9 +1036,9 @@ module Events
       required(:amount).filled(:decimal)
     end
     
-    # Production: also archive to S3
+    # Production: retention_period 7.years → retention_until in payload; archival jobs filter by it
     if Rails.env.production?
-      adapters [:loki, :s3_archive]
+      adapters [:loki]
     end
     # Other envs: use default_adapters
   end
@@ -1095,36 +1049,13 @@ end
 
 ## 📊 Metrics Configuration
 
-### Pattern-Based Auto-Metrics
+Define metrics in each event class:
 
 ```ruby
-E11y.configure do |config|
-  config.metrics do
-    # Global counter for ALL events
-    counter_for pattern: '*',
-                name: 'business_events.total',
-                tags: [:event_name, :severity]
-    
-    # Domain-specific counters
-    counter_for pattern: 'order.*',
-                name: 'orders.events.total',
-                tags: [:event_name]
-    
-    counter_for pattern: 'user.*',
-                name: 'users.events.total',
-                tags: [:event_name]
-    
-    # Histograms for amounts/durations
-    histogram_for pattern: '*.paid',
-                  name: 'payments.amount',
-                  value: ->(e) { e.payload[:amount] },
-                  tags: [:currency],
-                  buckets: [10, 50, 100, 500, 1000, 5000, 10000]
-    
-    # Success rate (special metric type)
-    success_rate_for pattern: 'payment.*',
-                     name: 'payments.success_rate'
-    # Automatically calculates from :success and :error events
+class Events::OrderCreated < E11y::Event::Base
+  metrics do
+    counter :orders_created_total, tags: [:currency]
+    histogram :order_amount, value: :amount, tags: [:currency], buckets: [10, 50, 100, 500]
   end
 end
 ```
@@ -1542,7 +1473,7 @@ E11y is designed for **high-performance production environments** with strict SL
 ```ruby
 # Benchmark: 1000 events/sec
 Benchmark.ips do |x|
-  x.report("E11y.track") do
+  x.report("EventClass.track") do
     Events::OrderPaid.track(
       order_id: 'ORD-123',
       amount: 99.99
@@ -1551,7 +1482,7 @@ Benchmark.ips do |x|
 end
 
 # Results:
-# E11y.track: 100,000 i/s → ~0.01ms per call
+# EventClass.track: 100,000 i/s → ~0.01ms per call
 # p99 latency: <1ms ✅
 ```
 
@@ -1918,11 +1849,11 @@ end
 class Events::CriticalPayment < Events::BasePaymentEvent
   include E11y::Presets::HighValueEvent
   
-  adapters [:loki, :sentry, :s3_archive]  # Override base (add S3)
+  adapters [:loki, :sentry]
   
   # Final config:
   # - severity: :success (from base)
-  # - adapters: [:loki, :sentry, :s3_archive] (event-level override)
+  # - adapters: [:loki, :sentry] (event-level override)
   # - sample_rate: 1.0 (from base)
   # - rate_limit: 10_000 (from preset)
   # - retention: 7.years (from preset)
@@ -1943,7 +1874,7 @@ end
 ## 📚 Related Use Cases
 
 - **[UC-001: Request-Scoped Debug Buffering](./UC-001-request-scoped-debug-buffering.md)** - Debug vs business events
-- **[UC-003: Pattern-Based Metrics](./UC-003-pattern-based-metrics.md)** - Auto-generate metrics
+- **[UC-003: Event Metrics](./UC-003-event-metrics.md)** - Metrics in event classes
 - **[UC-005: PII Filtering](./UC-005-pii-filtering.md)** - Secure event data
 
 ---

data/docs/use_cases/UC-003-event-metrics.md

@@ -0,0 +1,66 @@
+# UC-003: Event Metrics
+
+**Status:** Implemented  
+**Complexity:** Intermediate  
+**Setup Time:** 15-30 minutes  
+**Target Users:** DevOps, SRE, Backend Developers
+
+---
+
+## Overview
+
+Define metrics directly in event classes. Metrics are registered at boot and updated automatically when events are tracked.
+
+### Event-Level Metrics DSL
+
+```ruby
+class Events::OrderPaid < E11y::Event::Base
+  schema do
+    required(:order_id).filled(:string)
+    required(:amount).filled(:float)
+    required(:currency).filled(:string)
+    required(:payment_method).filled(:string)
+  end
+
+  metrics do
+    counter :orders_paid_total, tags: [:currency, :payment_method]
+    histogram :orders_paid_amount, value: :amount, tags: [:currency], buckets: [10, 50, 100, 500, 1000, 5000]
+  end
+end
+
+Events::OrderPaid.track(order_id: '123', amount: 99.99, currency: 'USD', payment_method: 'stripe')
+# → orders_paid_total{currency="USD",payment_method="stripe"} += 1
+# → orders_paid_amount_bucket{currency="USD",le="100"} += 1
+```
+
+### Metric Types
+
+- **counter** — monotonically increasing
+- **histogram** — distribution (requires `value:` field, optional `buckets:`)
+- **gauge** — point-in-time value (requires `value:`)
+
+### Boot-Time Validation
+
+E11y validates metrics at Rails boot: label conflicts, type conflicts. Non-Rails: call `E11y::Metrics::Registry.instance.validate_all!` after loading events.
+
+### Shared Metrics via Inheritance
+
+```ruby
+class BaseOrderEvent < E11y::Event::Base
+  metrics do
+    counter :orders_total, tags: [:currency, :status]
+  end
+end
+
+class Events::OrderPaid < BaseOrderEvent
+  metrics do
+    histogram :order_amount, value: :amount, tags: [:currency]
+  end
+end
+```
+
+---
+
+## Yabeda Integration
+
+Register Yabeda adapter in `config.adapters`. Metrics flow to Prometheus via Yabeda.

data/docs/use_cases/UC-004-zero-config-slo-tracking.md

@@ -122,6 +122,45 @@ yabeda_slo_sidekiq_job_duration_seconds{class="ProcessOrderJob"}
 
 ---
 
+### Event-Level SLO (Business Logic)
+
+**Event-driven SLO** tracks business logic reliability (e.g., order created vs failed, payment processed vs rejected). Opt-in via `slo { enabled true }` in Event classes.
+
+> **Implementation:** See [ADR-014 Event-Driven SLO](../architecture/ADR-014-event-driven-slo.md) for full architecture.
+
+**Enable Event SLO in Event class:**
+
+```ruby
+module Events
+  class OrderCreated < E11y::Event::Base
+    schema do
+      required(:order_id).filled(:string)
+      optional(:status).filled(:string)
+    end
+
+    slo do
+      enabled true
+      contributes_to "order_creation_success_rate"
+      slo_status_from do |payload|
+        case payload[:status].to_s
+        when "failed", "cancelled" then "failure"
+        when "pending", "completed" then "success"
+        else "success"
+        end
+      end
+    end
+  end
+end
+```
+
+**Required when `slo { enabled true }`:**
+- `contributes_to "slo_name"` — which custom SLO this event feeds
+- `slo_status_from { |payload| ... }` — compute `"success"`, `"failure"`, or `nil` (not counted)
+
+**EventSlo middleware** (in default pipeline) emits `e11y_slo_event_result_total{slo_name, slo_status}` for events with SLO enabled.
+
+---
+
 ## 📐 Sampling Correction for Accurate SLO (C11 Resolution) ⚠️ CRITICAL
 
 **Reference:** [ADR-009 Section 3.7: Stratified Sampling for SLO Accuracy (C11 Resolution)](../ADR-009-cost-optimization.md#37-stratified-sampling-for-slo-accuracy-c11-resolution) and [CONFLICT-ANALYSIS.md C11](../researches/CONFLICT-ANALYSIS.md#c11-adaptive-sampling--slo-tracking)
@@ -499,107 +538,9 @@ resource "grafana_dashboard" "e11y_slo" {
 
 ---
 
-## 🚨 Auto-Generated Alerts
-
-> **Implementation:** See [ADR-003 Section 5: Multi-Window Multi-Burn Rate Alerts](../ADR-003-slo-observability.md#5-multi-window-multi-burn-rate-alerts) for Google SRE best practice alert architecture.
+## 🚨 PromQL & Alert Rules
 
-### Generate Prometheus Alerts
-
-```bash
-rails g e11y:prometheus_alerts
-
-# Output: config/prometheus/e11y_slo_alerts.yml
-```
-
-**Alerts include:**
-- High error rate (>1%)
-- Low availability (<99.9%)
-- High latency (p95 >200ms)
-- Job failure rate (>5%)
-
-**Example alerts.yml:**
-```yaml
-groups:
-  - name: e11y_slo
-    rules:
-      - alert: HighErrorRate
-        expr: |
-          (
-            sum(rate(yabeda_slo_http_requests_total{status=~"5.."}[5m])) /
-            sum(rate(yabeda_slo_http_requests_total[5m]))
-          ) > 0.01
-        for: 5m
-        annotations:
-          summary: "HTTP error rate >1%"
-      
-      - alert: HighLatency
-        expr: histogram_quantile(0.95, rate(yabeda_slo_http_request_duration_seconds_bucket[5m])) > 0.2
-        for: 5m
-        annotations:
-          summary: "HTTP p95 latency >200ms"
-```
-
----
-
-## 🎯 Error Budget Management
-
-> **Implementation:** See [ADR-003 Section 7: Error Budget Management](../ADR-003-slo-observability.md#7-error-budget-management) for detailed architecture and deployment gates.
-
-**Track your SLO error budget in real-time:**
-
-```ruby
-# Query error budget for any endpoint
-budget = E11y::SLO::ErrorBudget.new('OrdersController', 'create', slo_config)
-
-budget.total             # => 0.001 (0.1% for 99.9% target)
-budget.consumed          # => 0.0005 (50% of budget used)
-budget.remaining         # => 0.0005 (50% of budget left)
-budget.percent_consumed  # => 50.0
-budget.exhausted?        # => false
-budget.time_until_exhaustion  # => 14.5 days (at current burn rate)
-```
-
-### Deployment Gate (Optional)
-
-**Prevent deployments when error budget is exhausted:**
-
-```ruby
-# config/initializers/e11y.rb
-E11y.configure do |config|
-  config.slo do
-    error_budget do
-      # Block deployments if <20% budget remaining
-      deployment_gate enabled: true, minimum_budget_percent: 20
-    end
-  end
-end
-```
-
-**CI/CD integration:**
-
-```bash
-# Before deployment, check error budget
-rails e11y:slo:check_budget
-
-# Exit code 0: ✅ Budget available, deploy
-# Exit code 1: ❌ Budget exhausted, block deploy
-```
-
-**Example output:**
-
-```
-Checking SLO Error Budget...
-
-OrdersController#create:
-  ✅ Budget: 75% remaining (Target: 99.9%, Actual: 99.925%)
-  
-PaymentsController#process:
-  ❌ Budget: 5% remaining (Target: 99.95%, Actual: 99.902%)
-  ⚠️  DEPLOYMENT BLOCKED: Error budget below 20% threshold
-  
-Overall: ❌ FAILED
-Cannot deploy: 1 endpoint(s) below minimum error budget
-```
+> See [SLO-PROMQL-ALERTS.md](../SLO-PROMQL-ALERTS.md) for PromQL queries and Prometheus alert rules.
 
 ---
 
@@ -720,7 +661,7 @@ end
 ## 📚 Related Use Cases
 
 - **[UC-002: Business Event Tracking](./UC-002-business-event-tracking.md)** - Events vs SLO metrics
-- **[UC-003: Pattern-Based Metrics](./UC-003-pattern-based-metrics.md)** - Custom metrics
+- **[UC-003: Event Metrics](./UC-003-event-metrics.md)** - Custom metrics
 
 ---