neo-opentelemetrylisted

# Neo OpenTelemetry Provide source-grounded OpenTelemetry guidance for concepts and operations without generating programming-language instrumentation code. ## Scope boundary In scope: - Observability concepts, telemetry signals, correlation, resources, semantic conventions, and sampling. - Collector pipelines, components, deployment patterns, declarative configuration, scaling, resiliency, internal telemetry, transformation, and troubleshooting. - Kubernetes, FaaS, OpenTelemetry Operator, OBI, and other zero-code operational approaches. - Security, sensitive-data handling, Prometheus interoperability, and OpenCensus/OpenTracing migration planning. Out of scope: - Language-specific SDK/API usage, manual instrumentation, source-code examples, and library integration code. - Building the Collector from source or developing custom receivers, processors, exporters, connectors, or extensions. - Vendor pricing, backend-specific query languages, and backend product administration unless needed only as context for an OpenTelemetry decision. If the request crosses the boundary, answer the in-scope operational portion and identify the excluded portion. Point to the appropriate official language or component-development documentation instead of inventing code. ## Workflow 1. Classify the request as explanation, architecture decision, configuration review, security review, migration, or troubleshooting. 2. Load `references/sources-and-scope.md` whenever the answer depends on sou