observabilitylisted

# Purpose Instrument the project's services with structured logging and OpenTelemetry distributed tracing, and provide the patterns for correlating logs, traces, and metrics when diagnosing issues. Code-level instrumentation only — what to log, how to propagate trace context, how to correlate signals. Placeholders `<mainApp>` and `<device>` resolve from `project.json`. # Rules - Logs are JSON with required fields `timestamp`, `level`, `service`, `message` — plus `trace_id`/`span_id` when tracing is active. - NEVER log PII, passwords, tokens, API keys, or secrets; review every context field. - High-frequency per-message events (several Hz per device) log at DEBUG, never INFO; INFO is for summaries and state changes. - Span names are meaningful with domain-specific attribute keys (`device.id`, not `id`); no unbounded span attributes (request bodies, user input). - Propagate trace context at every service boundary (WebSocket, HTTP) — a missing injection breaks the trace and loses correlation. - Logging and tracing only: metrics, dashboards, and alerts belong to `monitoring`; Helm health probes and log routing belong to the project's infra pack skills. # Resources - Read `resources/logging-and-tracing-patterns.md` when instrumenting — the log format, Python/TypeScript logger wrappers, OTel span code, context propagation, the five-step correlation path, inputs/outputs and length budgets. - Read `resources/checks-and-failure-modes.md` before returning or when something misbeha