thalarch-observabilitylisted

# Thalarch Observability Observability should answer operational questions, not maximize telemetry volume. Use the repository's existing telemetry stack and conventions unless the task explicitly introduces or migrates observability infrastructure. ## 1. Start from operational questions Before adding signals, write the small set of questions an operator would need answered if this feature fails or degrades, for example: - Did the operation succeed, fail, retry, or fall back? - Which dependency or stage consumed the time? - How often is the failure happening? - Can one affected request/job be reconstructed end-to-end? Every new signal should answer a real question. Telemetry without a question becomes noise and cost. ## 2. Choose the right signal Use the smallest appropriate evidence channel: - structured logs for specific events and failure context; - metrics for aggregate rate/error/duration/resource trends; - traces for cross-boundary causal/latency paths; - events/audit records when durable business/security history is the actual requirement. Do not duplicate the same high-cardinality payload across logs, metric labels, and traces. ## 3. Structured logging Prefer stable event names plus machine-queryable fields over prose-only interpolation. Preserve or introduce correlation/request/job identifiers at system boundaries when the architecture supports them, and propagate them across downstream calls/queues where useful. Never log: - credentials/tokens/secrets;