logginglisted

# Logging This skill is self-contained for day-to-day use. Deeper reference (needs the full harness checkout): `patterns/logging/LOGGING_STANDARDS.md` (full mandate and config schema), `patterns/logging/logging.yaml.example` (tested YAML template), `patterns/logging/config_loader.py` (Python reference implementation with 99% test coverage). ## When this applies Full structured logging with YAML config, multiple backends, and rotation is required at **Production tier**. Prototypes: `print()`/`console.log()` is fine. Internal tools: structured logging recommended, single-backend acceptable. Check the project's rigor tier first. ## Log levels — pick the right one | Level | Use for | |---|---| | `TRACE` | High-frequency per-call details; disabled in production by default | | `DEBUG` | Developer diagnostic info; disabled in production by default | | `INFO` | Normal operational events (startup, request completed) | | `WARNING` | Something unexpected but recoverable; worth investigating | | `ERROR` | A real failure that the system couldn't recover from | | `CRITICAL` | The process must stop or data is corrupted | Rule of thumb: if you'd page someone at 3am, it's `ERROR` or `CRITICAL`. ## Structured logging: message + fields, never string interpolation ```python # WRONG: unstructured — can't query or filter by user_id or duration logger.info(f"Request completed for user {user_id} in {duration}ms") # RIGHT: message is a static label; context is in structured fields logger.inf