logging-standardslisted

# Logging Standards Apply consistent logging so operations are debuggable and compliant without leaking secrets or PII. ## When to Activate - Adding or refactoring log statements - User asks for "logging", "log format", or "what to log" - Defining or reviewing logging standards for the project - After an incident where logs were insufficient or leaked data ## Core Principles - **Define "working" before instrumenting** — Write the 2–4 questions on-call will actually ask ("did checkout succeed for this user?", "which dependency is slow?") and make every signal map to one of them. A log line that answers no operational question is noise. - **Structured** — Prefer key-value fields (e.g. JSON) over long prose so logs are queryable and parseable. Use the same structure across the app (timestamp, level, message, fields). - **Cardinality** — Never use unbounded values as index/label keys (user_id, email, full URL, raw error text) in metrics/labels — they explode cardinality; keep them as event fields instead. Alert on symptoms (user-visible failure), not causes (one host's CPU). - **Verify the telemetry itself** — After instrumenting, induce the failure and confirm you can locate it from the logs/metrics alone. Untested observability tends to be silently wrong — e.g. sampling upstream of metric generation skews a request-rate metric by the sampling ratio while nothing looks broken. - **Levels** — Use consistently: ERROR (failures, exceptions), WARN (recoverable issues, deprecati