logginglisted

Logs are the evidence trail. The bar: from a single log line, plus its siblings sharing the same trace-id, a reader should be able to reconstruct what happened without re-running the code. That's the whole game. Everything else in this skill is in service of that. **A log line is one sentence in a story.** Read on its own it answers four questions — *who* (identity anchor), *where* (service, operation), *what* (the specific event), *how it ended* (outcome, duration, error). Read in trace order with its siblings it becomes a narrative: request arrived → user resolved → payment attempted → card declined → 402 returned. If a line can't answer its four questions, or the sequence has a hole where something clearly happened, the story is broken and the next incident costs hours. Pairs with `errors` — the error is *designed* over there; here it gets *emitted*. Neither works without the other. The trace-id lives here; `errors` references it. ## Example prompts - "Add logging to the checkout flow" - "Why isn't there a log for this failure?" - "Set up structured logging for a new Fastify service" - "Review this handler for observability" ## Core principles 1. **Structured, always.** Key/value pairs. Never string-concat (`"user " + id + " failed"`). Never printf. A log entry is a JSON object; the message is one field among many. 2. **One log per outcome, not per line.** Log at the entry and exit of interesting operations. Do not log every branch — that's what DEBUG is for, in loc