oma-observability

# Observability Agent - Intent-based Router ## Scheduling ### Goal Route, design, tune, and review observability work across MELT+P signals, layers, boundaries, vendor categories, transport choices, meta-observability, and incident forensics. ### Intent signature - User asks for observability, telemetry, OTel, metrics, logs, traces, profiles, SLOs, RUM, APM, incident forensics, trace propagation, transport tuning, or observability-as-code. - User needs vendor/category routing or observability architecture instead of a single vendor's already-covered setup. ### When to use - Setting up an observability pipeline (OTel SDK + Collector + vendor backend) - Designing traceability across service and domain boundaries (W3C propagators, baggage, multi-tenant, multi-cloud) - Tuning transport layer (UDP/MTU, OTLP gRPC vs HTTP, Collector DaemonSet vs sidecar topology) - Running incident forensics (6-dimension localization: code / service / layer / host / region / infra) - Selecting a vendor category (OSS full-stack vs commercial SaaS vs high-cardinality specialist vs profiling specialist) - Implementing observability-as-code (Grafana Jsonnet dashboards, PrometheusRule CRD, OpenSLO YAML, SLO burn-rate alerts) - Meta-observability (pipeline self-health, clock skew detection, cardinality guardrails, retention matrix) - Covering the MELT+P signal set: metrics, logs, traces, profiles (OTEP 0239), cost (OpenCost), audit (SOC2/ISO), privacy (GDPR/PIPA) - Evaluating log-pipeline migrations a...