namht-observelisted

# namht-observe — instrument a service so it can be debugged from the outside When something breaks at 3am you don't have the code in front of you — you have logs, metrics and a trace ID. This skill puts those in place so a service can be diagnosed **without** re-reading its source. It is the producer side of `/namht-splunk-report`: instrument the right fields here, query them there. ## Ground it first - Read the target flow in the KB (`03-entry-points`, `10-core-flows`, `14-integrations`, `12-conventions`) and the real code. Follow the **existing** logging library/format — never introduce a second logging style. - Learn the **downstream schema** and emit its exact field names. If the team's Splunk uses `cai_app` / `cai_enviroment`, those are the field keys you write — not `app` / `env`. ## The instrumentation model (what "good" looks like) **One correlation ID, end to end.** Generate it at the edge (HTTP filter / first consumer), carry it through every log line, and **propagate it across service hops**: - HTTP: read/set `X-Request-Id` (or W3C `traceparent`); pass it on outbound calls. - **SQS/async:** put it in the message's `MessageAttributes` on send; the consumer reads it back and re-establishes it before doing any work. This is the piece most teams miss — without it, a request becomes untraceable the moment it crosses a queue. **Structured events, not prose.** Log key=value / JSON at meaningful boundaries only: request/message **entry**, each **external cal