opentelemetrylisted

# OpenTelemetry Adapted from [codewithmukesh/dotnet-claude-kit](https://github.com/codewithmukesh/dotnet-claude-kit) (MIT). ## Check for an existing setup first Before adding any telemetry, search the repo for an existing `ActivitySource`, `Meter`, or telemetry abstraction. Most codebases that have OpenTelemetry at all have exactly one wiring point, and a second parallel `ActivitySource` fragments the trace — spans land in different sources and no backend stitches them back together. If a setup exists, extend it rather than duplicating it: - **Spans** — go through the repo's telemetry abstraction if it has one, not a raw `ActivitySource`. - **Span and tag names** — use the repo's constants file; never inline string literals. Inconsistent names are unqueryable, and a renamed literal silently breaks dashboards. - **Cross-process context** — propagate trace context explicitly across any queue or broker boundary (inject on send, extract on receive). Context does not cross a message broker on its own. - **Naming by functionality** — per the `coding-conventions` rule, name spans and types by what they do (`Queue.Send`), never by vendor (`ServiceBus.Send`). Swapping the transport should not rename the span. - **No secrets or PII in attributes** — this is a gate-3 check in `/ship-review`, and attributes are far more widely exported than logs. The guidance below is the reference for SDK wiring, custom metrics, and OTLP export when starting fresh or extending an existing setup.