@opengroundplan/core 0.1.1

package/catalog/sources/observability.yaml

@@ -0,0 +1,1364 @@
+# Groundplan template catalog - source research
+# category: observability
+# researched: 2026-07-18
+# adversarially verified: 2026-07-18
+# gap-fill pass + full re-verification: 2026-07-19
+# adversarial re-verification (3rd pass): 2026-07-19
+#
+# VERIFICATION STATUS - READ THIS FIRST
+# The 2026-07-19 adversarial pass independently re-verified all 38 pre-existing entries
+# (33 sources + 1 reference-only + 4 excluded) against primary sources, and added 4 new
+# source entries, giving 42 total: 37 sources + 1 reference-only + 4 excluded.
+#
+# License: read from each repository's actual LICENSE file via raw.githubusercontent.com,
+#   AND cross-checked against the GitHub API's license.spdx_id for all 42 entries once the
+#   rate-limit window allowed. The two agreed everywhere the API committed to an answer.
+#   Every recorded `spdx` matched the licence text actually served. NO license mismatches
+#   were found - the gate held on all 42 entries, and on all 38 pre-existing ones across
+#   three consecutive passes. Nothing was dropped for licence this pass.
+#   Three repos return spdx_id NOASSERTION, i.e. the API declines to classify them, and these
+#   are exactly the ones where reading the raw text is load-bearing:
+#     - hynek/structlog     -> dual "Apache-2.0 OR MIT" (LICENSE-MIT + LICENSE-APACHE + NOTICE,
+#                              no root LICENSE). Vendorable; reproduce one licence's notice.
+#     - SigNoz/signoz       -> MIT Expat core with a proprietary ee/ carve-out. Vendorable only
+#                              outside ee/ and cmd/enterprise/.
+#     - getsentry/sentry    -> FSL-1.1-Apache-2.0, source-available. EXCLUDED, and it is the
+#                              NOASSERTION case that would have been most damaging to guess.
+#   Anything trusting spdx_id alone would have mis-shelved all three. The three carve-out claims
+#   (SigNoz ee/, coroot absent ee/, structlog dual-licence file layout) were each re-read
+#   from source and confirmed verbatim; see the licenseNote on those entries.
+# Stars / archived / lastCommit: star counts read from the github.com repo star counter and
+#   lastCommit from the DEFAULT-BRANCH commits.atom feed. Default branch matters: two repos
+#   here do not use main/master (getsentry/sentry-javascript is `develop`,
+#   getsentry/sentry-python is `master` with a stale `main` still present), and reading the
+#   wrong branch understates lastCommit by months. Both were resolved against the default
+#   branch and both recorded dates are correct. All 42 URLs return HTTP 200, and the API
+#   confirms archived=false and disabled=false on every one. Every star count is within 0.1%
+#   of the recorded figure - no entry came close to the 20% drift threshold. Oldest pushed_at
+#   is OpenSLO at 2025-11-25, ~8 months, so no entry is anywhere near the 18-month gate.
+#   ONE REPO WAS RENAMED: dotnet/aspire is now microsoft/aspire. The old path still resolves
+#   over HTML and raw.githubusercontent because GitHub keeps rename redirects, so only the API
+#   exposes it - and it does so as a bare HTTP 301, which silently yields no repo object to
+#   tooling that does not follow redirects. Name and url updated to canonical. Worth repeating
+#   on future passes: a 301 from api.github.com/repos/{owner}/{repo} means renamed, not missing.
+# Note on pushed_at vs lastCommit: these legitimately differ. pushed_at advances on a push to
+#   ANY branch or tag; lastCommit here is the DEFAULT-branch commit date. Several entries show
+#   a later pushed_at for that reason (see google/slo-generator, where the gap is ~4 months).
+#   Neither figure is wrong; do not reconcile them by editing one.
+# Path claims: every file and directory named in a whatToBorrow was fetched. Negative
+#   controls (known-bad paths) were run to confirm the checker distinguishes 200 from 404.
+#
+# SYSTEMATIC DEFECT FOUND AND FIXED THIS PASS - CORE vs CONTRIB.
+#   The 2026-07-19 pass found the same error repeated across FOUR languages: artifacts that
+#   live in an OTel *-contrib repo were attributed to the corresponding core repo, so the
+#   cited paths 404 and a scaffolder following them would generate nothing.
+#     - opentelemetry-go: cited example/otel-collector and example/dice; core has no
+#       example/ directory at all. They are in opentelemetry-go-contrib/examples/.
+#     - opentelemetry-python: cited the opentelemetry-instrument zero-code CLI; that console
+#       script is declared in opentelemetry-python-contrib, not core.
+#     - opentelemetry-js: cited getNodeAutoInstrumentations() alongside NodeSDK as if both
+#       were core; NodeSDK is core, the auto-instrumentations are in opentelemetry-js-contrib.
+#     - opentelemetry-dotnet: its `stack` line advertised "ASP.NET Core and HttpClient
+#       instrumentation"; src/OpenTelemetry.Instrumentation.AspNetCore and .Http both 404 in
+#       core and live in opentelemetry-dotnet-contrib.
+#   Each core entry now states the split explicitly, and the four contrib repos were added as
+#   first-class gated entries (all Apache-2.0, all verified) rather than left as bare prose
+#   references - code we point at must clear the same licence gate as code we list.
+#   Two further stale-path defects were corrected outside that family:
+#     - opentelemetry-java-instrumentation cited docs/suppressing-instrumentation.md, which
+#       does not exist; the surviving docs are agent-features.md, supported-libraries.md and
+#       advanced-configuration-options.md.
+#     - SigNoz was told to borrow "the deploy/ compose files". Upstream has deprecated and
+#       DELETED them - deploy/ now holds only README.md, MIGRATION.md and a dead install.sh,
+#       and deploy/README.md says so in as many words. That entry was rewritten around what
+#       still exists (conf/example.yaml, pkg/telemetrystore/) and demoted in practice to
+#       reference reading.
+#   A licence nuance was also made explicit on grafana/docker-otel-lgtm: the repo is honestly
+#   Apache-2.0 and its own files are safe to copy, but its Dockerfile DOWNLOADS pinned Grafana
+#   and Loki binaries, so the built image is an AGPL-containing aggregate. Copying the repo is
+#   clean; redistributing the image as your own artifact is not.
+#   One stale API convention was corrected: getsentry/sentry-javascript's Next.js layout.
+#   The recorded three-file convention put client init in sentry.client.config.ts; the SDK
+#   source now logs a deprecation warning for that filename and states it stops working under
+#   Turbopack, having moved client init to instrumentation-client.ts. Read from
+#   packages/nextjs/src/config/webpack.ts, not from docs. Everything else resolved.
+# Staleness: the oldest entry is OpenSLO at 2025-10-09 (~9 months), comfortably inside the
+#   18-month gate. No entry marked maintained:true is stale.
+#
+# licenseClass: vendorable = MIT/Apache-2.0/BSD/ISC/Unlicense/CC0/0BSD (copy and adapt,
+#   with attribution where the license requires it - Apache-2.0 and BSD need the notice);
+#   reference-only = MPL-2.0/LGPL/EPL (read for ideas, do not copy files);
+#   excluded = GPL/AGPL/SSPL/BUSL/source-available/unlicensed.
+# maintained = not archived AND pushed_at within 18 months of the research date.
+
+category: observability
+
+sources:
+  - name: "grafana/docker-otel-lgtm"
+    url: "https://github.com/grafana/docker-otel-lgtm"
+    stars: 1939
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: "Docker image bundling OpenTelemetry Collector + Loki, Grafana, Tempo, Prometheus/Mimir, Pyroscope"
+    complexity: simple
+    proposedLayerIds:
+      - obs-stack-lgtm-single-container
+      - otel-collector-config
+      - obs-grafana-provisioning
+      - obs-local-dev-backend
+    whatToBorrow: >-
+      The single best "observability backend in one container" layer. Borrow docker/Dockerfile
+      plus docker/run-all.sh, the supervisor-style entrypoint that boots all five backends from
+      one image via the per-component run-*.sh scripts. Take docker/otelcol-config.yaml as a
+      minimal working collector config that fans OTLP out to Loki for logs, Tempo for traces and
+      Prometheus for metrics. For zero-click Grafana, the provisioning artifacts are FLAT FILES
+      in docker/, not a directory tree: docker/grafana-datasources.yaml,
+      docker/grafana-dashboards.yaml and docker/grafana-dashboard-*.json (red-metrics-classic,
+      red-metrics-native, jvm-metrics). The Dockerfile COPYs them to
+      /otel-lgtm/grafana/conf/provisioning/{datasources,dashboards}/ - that path is the
+      destination inside the image, so replicate the copy step, do not look for it in the repo.
+      The examples/ directory holds small per-language senders that convert directly into
+      template smoke tests.
+    whatToAvoid: >-
+      Explicitly not a production target - no persistence by default, admin/admin credentials
+      baked into the image, and all five components share one container so they cannot be
+      scaled, upgraded or restarted independently. Note the repo ships an IMAGE, not a compose
+      file, so the generated repo must supply its own compose service. Use it strictly as the
+      local/CI backend and keep a separate production backend layer; a generated repo that ships
+      this as its only observability story will lose all telemetry on container restart.
+    licenseNote: >-
+      Apache-2.0 confirmed from the LICENSE file, and every artifact this entry tells you to
+      copy (Dockerfile, run-*.sh, otelcol-config.yaml, the grafana-* provisioning files and
+      dashboards) is original work in THIS repo and therefore genuinely Apache-2.0.
+      But do not over-read that: the repo vendors no AGPL source, it DOWNLOADS AGPL binaries
+      at build time. docker/Dockerfile pins GRAFANA_VERSION and LOKI_VERSION as build args
+      (v13.1.0 and v3.7.3 at the time of checking) and fetches the released binaries, and
+      there is no NOTICE or third-party-license file in the repo to inherit. The practical
+      boundary: copying this repo's own files into a generated repo is clean, and running or
+      referencing the resulting image is clean, but the image itself is an aggregate
+      containing AGPL components - so a generated repo must never present that image as its
+      own redistributable artifact, and must never lift Grafana or Loki source out of it.
+      See the grafana/loki and grafana/grafana entries in `excluded` for the same boundary.
+
+  - name: "open-telemetry/opentelemetry-collector-contrib"
+    url: "https://github.com/open-telemetry/opentelemetry-collector-contrib"
+    stars: 4796
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: "Go - OpenTelemetry Collector components (receivers, processors, exporters, connectors)"
+    complexity: enterprise
+    proposedLayerIds:
+      - otel-collector-config
+      - obs-pipeline-processors
+      - obs-tail-sampling
+    whatToBorrow: >-
+      This is where real collector COMPONENT configuration lives. Borrow the processor
+      configuration patterns that every production pipeline needs - memory_limiter and batch
+      ordering, resourcedetection for cloud/host attributes, transform/filter with OTTL
+      statements, and tailsamplingprocessor policy blocks for keeping errors and slow traces
+      while dropping the rest. Each component directory carries its own README with a worked
+      config example; those examples are the copyable unit.
+    whatToAvoid: >-
+      Enormous surface - hundreds of components at differing stability levels, and alpha
+      components change their config schema between minor releases, so copied YAML silently
+      breaks on upgrade. Check each component's stability badge before a template depends on
+      it. Never vendor Go source from this repo; take YAML config only. The full contrib
+      distribution is far too heavy to be a sensible default runtime.
+      CORRECTION: the OCB builder does NOT live here. A previous revision of this file
+      attributed it to contrib and called it the highest-leverage artifact in this repo - that
+      was wrong and would have sent the scaffolder to a path that 404s. cmd/builder is in
+      open-telemetry/opentelemetry-collector; ready-made distribution manifests are in
+      open-telemetry/opentelemetry-collector-releases (distributions/). See the dedicated
+      entry below.
+
+  - name: "open-telemetry/opentelemetry-collector-releases"
+    url: "https://github.com/open-telemetry/opentelemetry-collector-releases"
+    stars: 488
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-15"
+    archived: false
+    stack: "OCB (OpenTelemetry Collector Builder) distribution manifests and release tooling"
+    complexity: standard
+    proposedLayerIds:
+      - otel-collector-custom-distro
+    whatToBorrow: >-
+      The correct home for the custom-distribution pattern that the contrib entry previously
+      misattributed. distributions/ holds real manifest.yaml files (otelcol, otelcol-contrib,
+      otelcol-k8s) showing the exact schema - dist: name/description/output_path, then explicit
+      receivers/processors/exporters/connectors lists pinned by gomod line. Generating one of
+      these plus an `ocb --config manifest.yaml` build step produces a slim purpose-built
+      collector binary instead of shipping the multi-hundred-megabyte contrib image. This is
+      the single highest-leverage collector artifact a scaffolder can generate.
+    whatToAvoid: >-
+      Every component gomod line carries a version that must match the collector core version
+      or the build fails with confusing Go module errors - generate the manifest with one
+      pinned version variable rather than per-line literals. The builder is a build-time
+      dependency, so the generated repo needs a Go toolchain in CI even if the app is not Go.
+    verificationNote: >-
+      Added during adversarial verification to carry the OCB layer that was wrongly attributed
+      to collector-contrib. Apache-2.0 confirmed from the LICENSE file; distributions/ path
+      confirmed to resolve.
+
+  - name: "open-telemetry/opentelemetry-dotnet"
+    url: "https://github.com/open-telemetry/opentelemetry-dotnet"
+    stars: 3731
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: ".NET / C# - OpenTelemetry SDK, OTLP/Prometheus/Console exporters, hosting extensions (instrumentation packages are in dotnet-contrib)"
+    complexity: standard
+    proposedLayerIds:
+      - otel-instrumentation-dotnet
+      - otel-exporter-otlp
+      - obs-metrics-prometheus
+    whatToBorrow: >-
+      The builder-extension wiring is the copyable artifact: a single
+      services.AddOpenTelemetry().ConfigureResource(...).WithTracing(...).WithMetrics(...)
+      block plus .UseOtlpExporter(), which collapses the whole setup into one file that drops
+      cleanly into a ServiceDefaults-style project. Borrow the ResourceBuilder construction
+      (service.name, service.version, deployment.environment from config rather than
+      literals), the ActivitySource/Meter singleton-per-assembly convention for custom spans
+      and metrics, and the docs/ plus examples/ trees which carry compiling reference setups
+      for console, ASP.NET Core and worker hosts.
+      Scope correction: this repo's src/ holds OpenTelemetry, OpenTelemetry.Api, the exporters
+      (OpenTelemetryProtocol, Prometheus.AspNetCore, Prometheus.HttpListener, Console, Zipkin),
+      Extensions.Hosting and Extensions.Propagators. It does NOT hold the AspNetCore or Http
+      instrumentation packages - those moved to opentelemetry-dotnet-contrib, and a previous
+      revision listed them here. AddAspNetCoreInstrumentation()/AddHttpClientInstrumentation()
+      therefore need a package reference resolved against contrib; see the entry below.
+      Note the LICENSE file here is LICENSE.TXT, not LICENSE - the attribution step in a
+      generated repo must copy the right filename.
+    whatToAvoid: >-
+      Instrumentation packages version independently from the core SDK and several remain
+      pre-release, so a template must pin a coherent set or restore resolves a mismatched pair
+      that fails at runtime. The logging story changed across major versions (ILogger bridge
+      vs OpenTelemetryLoggerProvider), so older snippets do not compile. Metrics exported
+      without an explicit view can produce very high cardinality from ASP.NET Core route
+      templates - constrain this in the generated config.
+
+  - name: "open-telemetry/opentelemetry-dotnet-contrib"
+    url: "https://github.com/open-telemetry/opentelemetry-dotnet-contrib"
+    stars: 646
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: ".NET - OTel instrumentation packages (ASP.NET Core, HttpClient, SQL, StackExchange.Redis) and resource detectors"
+    complexity: standard
+    proposedLayerIds:
+      - otel-instrumentation-dotnet
+      - obs-http-server-instrumentation
+    whatToBorrow: >-
+      Where the .NET instrumentation packages actually live, added during verification because
+      the core opentelemetry-dotnet entry claimed them.
+      src/OpenTelemetry.Instrumentation.AspNetCore and src/OpenTelemetry.Instrumentation.Http
+      are the two that matter for any web service - they are what make
+      AddAspNetCoreInstrumentation() and AddHttpClientInstrumentation() resolve, and without
+      them the ServiceDefaults-style block from the core entry compiles to a tracer that emits
+      no server spans. Each package README documents its options object, which is where request
+      filtering and route-template enrichment are configured. The resource-detector packages
+      are the clean way to populate cloud/host resource attributes without hand-rolling them.
+    whatToAvoid: >-
+      Independently versioned from the core SDK and several packages sit at -beta/-rc even
+      while core is stable, so a template must pin core and each instrumentation package as one
+      coherent set - this is the concrete cause of the version-mismatch failure the core entry
+      warns about. Its LICENSE file is LICENSE.TXT (same filename caveat as core). Prefer
+      individual packages over broad meta-references so the dependency surface stays small.
+    verificationNote: >-
+      Added 2026-07-19. Apache-2.0 read from LICENSE.TXT (there is no plain LICENSE - both
+      LICENSE and LICENSE.md 404); 646 stars, not archived, last commit 2026-07-17.
+
+  - name: "open-telemetry/opentelemetry-python"
+    url: "https://github.com/open-telemetry/opentelemetry-python"
+    stars: 2550
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-16"
+    archived: false
+    stack: "Python - OpenTelemetry API/SDK, OTLP exporters (auto-instrumentation is NOT here - see python-contrib)"
+    complexity: standard
+    proposedLayerIds:
+      - otel-instrumentation-python
+      - otel-exporter-otlp
+      - obs-tracing-python
+      - logging-trace-correlation-python
+    whatToBorrow: >-
+      Two distinct layers worth generating separately, but they come from TWO DIFFERENT REPOS
+      and a previous revision wrongly attributed both to this one. First, the zero-code path:
+      the opentelemetry-instrument CLI plus OTEL_* environment variables
+      (OTEL_SERVICE_NAME, OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_TRACES_SAMPLER), which gives a
+      Django/Flask/FastAPI app traces with no source changes and belongs in the Dockerfile
+      entrypoint - that CLI is NOT in this repo. This repo ships only opentelemetry-api,
+      opentelemetry-sdk, opentelemetry-proto, opentelemetry-semantic-conventions, exporter/
+      and propagator/; the console script is declared in
+      opentelemetry-python-contrib/opentelemetry-instrumentation/pyproject.toml. See the
+      dedicated python-contrib entry below.
+      Second - and this IS this repo - the explicit path in docs/examples/ - TracerProvider with a Resource
+      carrying service.name, BatchSpanProcessor wrapping an OTLPSpanExporter, and the
+      LoggingHandler bridge that attaches trace_id/span_id to stdlib log records so logs
+      correlate with traces.
+    whatToAvoid: >-
+      The auto-instrumentation agent monkey-patches at import time and interacts badly with
+      gunicorn/uvicorn pre-fork workers - the provider must be initialised post-fork or spans
+      vanish silently, which is the most common failure mode and must be handled in any
+      generated Dockerfile. API/SDK packages and the separately versioned contrib
+      instrumentation packages must be pinned together. Logs and some metrics APIs stabilised
+      later than tracing, so pin versions rather than tracking latest.
+
+  - name: "open-telemetry/opentelemetry-python-contrib"
+    url: "https://github.com/open-telemetry/opentelemetry-python-contrib"
+    stars: 1073
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: "Python - opentelemetry-instrument zero-code agent plus per-framework instrumentation packages"
+    complexity: standard
+    proposedLayerIds:
+      - otel-instrumentation-python
+      - otel-agent-python
+      - logging-trace-correlation-python
+    whatToBorrow: >-
+      This is where Python's zero-code story actually lives, added during verification because
+      the core opentelemetry-python entry claimed it. opentelemetry-instrumentation/ declares
+      both console scripts in its pyproject.toml - opentelemetry-instrument (wraps the app
+      process and patches libraries at startup) and opentelemetry-bootstrap (scans installed
+      packages and prints the matching instrumentation deps, which is the piece to run at
+      image-build time so the generated Dockerfile pins an explicit list rather than guessing).
+      The generated layer is therefore Dockerfile plus env, not source: install the framework
+      package, set OTEL_SERVICE_NAME / OTEL_EXPORTER_OTLP_ENDPOINT / OTEL_TRACES_SAMPLER, and
+      change the entrypoint to `opentelemetry-instrument python -m app`.
+      instrumentation/opentelemetry-instrumentation-{django,fastapi,flask,logging} are the
+      four to read first; the -logging one is what injects trace_id/span_id into log records
+      for correlation.
+    whatToAvoid: >-
+      Versioned separately from opentelemetry-python core with its own release cadence, and the
+      packages carry pre-1.0 version numbers even when the core API is stable - pin core and
+      contrib as a matched set or resolution produces a combination that fails at import. Do
+      not let opentelemetry-bootstrap auto-install at container start; run it at build time and
+      commit the resulting pins. The same post-fork initialisation caveat as the core entry
+      applies and is the most common silent failure under gunicorn/uvicorn.
+    portability: "Config-only - Dockerfile entrypoint plus env vars, transfers across Python web frameworks."
+    verificationNote: >-
+      Added 2026-07-19. Apache-2.0 read from the LICENSE file; 1073 stars, not archived, last
+      commit 2026-07-17. Promoted to a first-class gated entry rather than a bare cross-
+      reference because the zero-code layer is generated from this repo's tooling.
+
+  - name: "open-telemetry/opentelemetry-demo"
+    url: "https://github.com/open-telemetry/opentelemetry-demo"
+    stars: 3217
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: "Polyglot microservice demo - OTel across ~15 languages with a full backend stack"
+    complexity: professional
+    proposedLayerIds:
+      - otel-instrumentation-polyglot
+      - obs-stack-compose
+    whatToBorrow: >-
+      Canonical polyglot OTel reference. Borrow otel-config.yml and the split compose layering
+      (compose.yaml for services, compose.observability.yaml for backends, compose.full.yaml
+      for everything, plus compose.extras.yaml / compose.profiling.yaml / compose.tests.yaml),
+      which is exactly the composable pattern a scaffolder wants - the generated repo picks the
+      overlays it needs. Per-language bootstrap files under src/ show idiomatic SDK init for
+      each runtime. All file paths in this entry were confirmed to exist at main.
+    whatToAvoid: >-
+      It is a demo carrying an astronomy-shop domain, a load generator and a feature-flag
+      service, and it needs roughly 6GB of RAM. Take the wiring patterns, never the domain
+      code. Do not use it as a starting repo - strip to the compose overlay shape and the
+      collector config.
+
+  - name: "pinojs/pino"
+    url: "https://github.com/pinojs/pino"
+    stars: 18044
+    spdx: "MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-18"
+    archived: false
+    stack: "Node.js structured JSON logging"
+    complexity: simple
+    proposedLayerIds:
+      - logging-structured-node-pino
+      - logging-http-middleware
+      - logging-redaction
+    whatToBorrow: >-
+      The logger factory with redact paths for auth headers and cookies, custom serializers,
+      the pino-pretty-in-dev / raw-JSON-in-prod transport split, and pino-http for per-request
+      child loggers carrying a request id.
+    whatToAvoid: >-
+      Transports run in worker threads and can lose buffered logs on abrupt exit without an
+      explicit flush - wire a shutdown handler. Keep pino-pretty a devDependency; shipping it
+      to production costs throughput for no benefit.
+
+  - name: "hynek/structlog"
+    url: "https://github.com/hynek/structlog"
+    stars: 4878
+    spdx: "Apache-2.0 OR MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-18"
+    archived: false
+    stack: "Python structured logging"
+    complexity: simple
+    proposedLayerIds:
+      - logging-structured-python-structlog
+      - logging-context-vars
+      - logging-json-renderer
+    whatToBorrow: >-
+      The configure() processor chain (merge_contextvars, add_log_level, TimeStamper(iso),
+      format_exc_info, then JSONRenderer in prod and ConsoleRenderer in dev) and the
+      ProcessorFormatter bridge that routes stdlib logging from third-party libraries through
+      the same chain so output stays uniform.
+    whatToAvoid: >-
+      Configuration is global and import-order sensitive - configure() must run before any
+      module grabs a logger, so it belongs at the top of the app entrypoint, not in a package
+      __init__.
+    licenseNote: >-
+      Dual-licensed. There is no top-level LICENSE file; the repo carries LICENSE-MIT and
+      LICENSE-APACHE plus a NOTICE, all confirmed present. Pick one license and reproduce its
+      notice - do not omit attribution on the assumption that dual-licensing waives it.
+
+  - name: "getsentry/sentry-javascript"
+    url: "https://github.com/getsentry/sentry-javascript"
+    stars: 8710
+    spdx: "MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: "JavaScript/TypeScript error and performance monitoring SDKs"
+    complexity: standard
+    proposedLayerIds:
+      - observability-sentry-nextjs
+      - observability-sentry-node
+      - observability-sentry-react
+      - obs-sourcemaps-upload
+    whatToBorrow: >-
+      The Next.js file convention, withSentryConfig for source-map upload at build time, and
+      global-error.tsx for the React error boundary.
+      CONVENTION UPDATED - verify before generating. A previous revision described a three-file
+      layout of instrumentation.ts + sentry.client.config.ts + sentry.server.config.ts. The
+      client half of that is now deprecated: client init belongs in instrumentation-client.ts
+      (or src/instrumentation-client.ts). This was read from the SDK source, not from docs -
+      packages/nextjs/src/config/webpack.ts still resolves sentry.client.config.ts via
+      getClientSentryConfigFile() but logs "DEPRECATION WARNING: It is recommended renaming
+      your sentry.client.config.ts file, or moving its content to instrumentation-client.ts.
+      When using Turbopack sentry.client.config.ts will no longer work", while
+      getInstrumentationClientFile() resolves the replacement. Server-side registration through
+      instrumentation.ts / register() is unchanged. Generate instrumentation-client.ts, not
+      sentry.client.config.ts, or the output is born deprecated and breaks under Turbopack.
+    whatToAvoid: >-
+      The docs default tracesSampleRate to 1.0, which destroys a quota on any real traffic -
+      generate a low sampled default driven by an env var. Session Replay captures user input
+      and must default to off for privacy. Source-map upload needs an auth token that must come
+      from CI secrets, never a committed config file.
+    licenseNote: >-
+      MIT confirmed from the LICENSE file, read on BOTH `develop` and `master`. Note the
+      default branch here is `develop`, not master/main - a previous revision cited master
+      only, and any tooling that reads this repo must target develop or it will report a
+      months-stale commit date. This is the SDK repo and is genuinely MIT - distinct from
+      getsentry/sentry (the server), which is FSL source-available and excluded below.
+      Do not conflate the two.
+
+  - name: "Xabaril/AspNetCore.Diagnostics.HealthChecks"
+    url: "https://github.com/Xabaril/AspNetCore.Diagnostics.HealthChecks"
+    stars: 4369
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-04-16"
+    archived: false
+    stack: ".NET health-check packages, publishers and UI"
+    complexity: standard
+    proposedLayerIds:
+      - health-checks-dotnet
+      - health-checks-ui
+      - obs-readiness-liveness-probes
+    whatToBorrow: >-
+      Reference implementation of health-check patterns usable in any stack. Borrow the
+      tag-based split (register checks with ready/live tags, map /health/ready and /health/live
+      to tag-filtered predicates - exactly what Kubernetes probes need), the Degraded vs
+      Unhealthy distinction, and the publisher push model for reporting status outward.
+    whatToAvoid: >-
+      One NuGet package per backend and several are deprecated or lag their driver - pin and
+      check each one rather than adding the meta-package. The UI needs storage and is a
+      separate deployment concern; do not make it a default.
+
+  - name: "nestjs/terminus"
+    url: "https://github.com/nestjs/terminus"
+    stars: 741
+    spdx: "MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-03-08"
+    archived: false
+    stack: "NestJS health-check module"
+    complexity: simple
+    proposedLayerIds:
+      - health-checks-nestjs
+      - obs-readiness-liveness-probes
+    whatToBorrow: >-
+      The HealthController shape (@Get('health') @HealthCheck() returning
+      health.check([...indicators])) and the custom-indicator contract for app-specific checks.
+    whatToAvoid: >-
+      Tightly coupled to Nest DI, so it does not transfer to other Node frameworks. Optional
+      peer dependencies fail at boot with opaque errors when an indicator is registered without
+      its driver installed - generate the peer deps alongside each indicator.
+
+  - name: "slok/sloth"
+    url: "https://github.com/slok/sloth"
+    stars: 2515
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-05-26"
+    archived: false
+    stack: "Go - Prometheus SLO generator producing multi-window multi-burn-rate alert rules"
+    complexity: standard
+    proposedLayerIds:
+      - slo-prometheus-sloth
+      - obs-alerting-rules
+      - obs-slo-definitions
+    whatToBorrow: >-
+      The cleanest path from a short SLO spec to correct multi-window multi-burn-rate alerts,
+      which almost nobody writes correctly by hand. Borrow the spec format and the examples/
+      tree (confirmed present) including the generated output shape, plus the
+      PrometheusServiceLevel CRD for a GitOps flow.
+    whatToAvoid: >-
+      Prometheus-only. Generated rule sets are large and materially raise evaluation cost on a
+      small Prometheus - do not generate SLOs for every endpoint by default.
+
+  - name: "OpenSLO/OpenSLO"
+    url: "https://github.com/OpenSLO/OpenSLO"
+    stars: 1509
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2025-10-09"
+    archived: false
+    stack: "Vendor-neutral SLO specification (YAML schema)"
+    complexity: simple
+    proposedLayerIds:
+      - slo-definitions-openslo
+      - obs-slo-definitions
+    whatToBorrow: >-
+      Use as the schema layer, not a runtime. Borrow the Kubernetes-style kinds - SLO, SLI,
+      AlertPolicy, AlertCondition, AlertNotificationTarget, Service and DataSource, all seven
+      confirmed present in the spec README - as the shape for an slo/ directory so definitions
+      stay portable across backends. The current apiVersion is `openslo/v1`; generate that
+      literal rather than an unpinned reference.
+    whatToAvoid: >-
+      A specification only - nothing in this repo evaluates SLOs, so it must be paired with
+      sloth or slo-generator to produce anything that alerts. Pin apiVersion; the spec still
+      moves. Note this is the slowest-moving entry in the list at ~9 months since the last
+      commit - still inside the 18-month gate, but re-check before relying on it.
+
+  - name: "stefanprodan/dockprom"
+    url: "https://github.com/stefanprodan/dockprom"
+    stars: 6571
+    spdx: "MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-03-06"
+    archived: false
+    stack: "Docker Compose host/container monitoring stack - Prometheus, Grafana, Alertmanager, cAdvisor, node-exporter"
+    complexity: simple
+    proposedLayerIds:
+      - obs-stack-prometheus-compose
+      - obs-alertmanager-rules
+      - obs-host-container-metrics
+    whatToBorrow: >-
+      Classic host and container monitoring compose stack, small enough to read end to end.
+      Borrow docker-compose.yml, prometheus/prometheus.yml scrape configs for cAdvisor and
+      node-exporter, prometheus/alert.rules, alertmanager/config.yml routing, and
+      grafana/provisioning/. Paths confirmed at master.
+    whatToAvoid: >-
+      Infrastructure metrics only - no tracing, no logging, no OTel path, so it does not serve
+      an app-telemetry story on its own. The Caddy basic-auth front is not a real security
+      boundary. Bundled dashboards drift against newer exporter label schemas and often need
+      fixing after an exporter bump.
+
+  - name: "prometheus/client_golang"
+    url: "https://github.com/prometheus/client_golang"
+    stars: 6010
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: "Go Prometheus instrumentation client"
+    complexity: simple
+    proposedLayerIds:
+      - obs-metrics-prometheus
+      - obs-metrics-go-client
+    whatToBorrow: >-
+      The custom-registry pattern (prometheus.NewRegistry() with explicit MustRegister rather
+      than the global default, so tests stay isolated), promauto.With(reg) for declaration,
+      promhttp.HandlerFor mounted on a separate admin port rather than the public router, and
+      InstrumentHandlerDuration/InstrumentHandlerCounter for RED metrics. promauto path
+      confirmed present.
+    whatToAvoid: >-
+      Unbounded label values (user ids, URLs, request ids) cause cardinality explosions that
+      take down Prometheus - the generated code must use bounded label sets and route patterns
+      rather than raw paths.
+
+  - name: "microsoft/aspire"
+    url: "https://github.com/microsoft/aspire"
+    stars: 6172
+    spdx: "MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-18"
+    archived: false
+    formerName: "dotnet/aspire"
+    stack: ".NET cloud-native orchestration, ServiceDefaults, OTLP dashboard"
+    complexity: enterprise
+    proposedLayerIds:
+      - obs-dotnet-servicedefaults
+      - obs-dashboard-otlp
+    whatToBorrow: >-
+      The ServiceDefaults project is a ready-made observability layer - one AddServiceDefaults()
+      wiring OTel tracing/metrics/logging with OTLP export, AddDefaultHealthChecks() with
+      tag-filtered /health and /alive, resilience handlers and service discovery, plus
+      MapDefaultEndpoints() guarded to development. The exact artifact to lift is the
+      src/Aspire.ProjectTemplates/templates/aspire-servicedefaults template directory
+      (confirmed present) - that is the ServiceDefaults project in template form, so it can be
+      adapted wholesale rather than reconstructed from docs. The standalone Aspire Dashboard container
+      is a useful generic OTLP viewer for ANY language, not just .NET - worth a language-neutral
+      layer.
+    whatToAvoid: >-
+      AppHost orchestration is heavy and is over-engineering if all you want is observability -
+      take ServiceDefaults and the dashboard without adopting AppHost. LICENSE file is
+      LICENSE.TXT.
+    verificationNote: >-
+      RENAMED - recorded as dotnet/aspire in previous revisions; the repository has moved to
+      microsoft/aspire (canonical full_name confirmed via the GitHub API, repo id 696529789,
+      MIT, 6172 stars, not archived). github.com/dotnet/aspire still resolves because GitHub
+      keeps rename redirects, so an HTML or raw.githubusercontent check does NOT reveal this -
+      only the API does, and it answers HTTP 301 "Moved Permanently" rather than a repo object,
+      which is silently fatal to any tooling that does not follow the redirect. Both name and
+      url updated to the canonical form; use microsoft/aspire in generated references so the
+      catalog does not depend on a redirect that would break if the old path were ever reused.
+
+  - name: "SigNoz/signoz"
+    url: "https://github.com/SigNoz/signoz"
+    stars: 30828
+    spdx: "MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-18"
+    archived: false
+    stack: "Self-hosted OTel-native APM on ClickHouse"
+    complexity: enterprise
+    proposedLayerIds:
+      - obs-stack-signoz
+      - obs-dashboard-unified
+    whatToBorrow: >-
+      Self-hosted OTel-native alternative to Datadog, useful mainly as a READING reference for
+      how OTLP data is modelled on ClickHouse. conf/example.yaml is the annotated server
+      config. pkg/telemetrystore/ is the store abstraction - telemetrystore.go plus
+      clickhousetelemetrystore/ show the column layout and query construction for spans and
+      metrics, which is the genuinely instructive part and the reason to look at this repo at
+      all. All of the above sit outside the enterprise carve-out and are MIT.
+      IMPORTANT - the compose artifact this entry previously pointed at is GONE. deploy/ now
+      contains only README.md, MIGRATION.md and a deprecated install.sh; deploy/README.md
+      states plainly that "the `install.sh` script and the `docker-compose` manifests have
+      been deprecated" and that SigNoz now installs via its "Foundry" tooling documented
+      off-repo. Do not generate a SigNoz compose service from this repository - there is no
+      longer one to copy.
+    whatToAvoid: >-
+      Operationally heavy - ClickHouse plus several services, not a reasonable default for a
+      small generated repo. With the compose manifests removed, standing it up now means
+      following vendor-hosted Foundry docs rather than anything version-pinned in-repo, which
+      is a poor fit for a reproducible scaffolder; treat this entry as reference reading and
+      prefer docker-otel-lgtm or dockprom for an actual runnable local backend.
+      See the license carve-out below; it is a hard boundary and the ee/ directory does exist
+      at main, so the path filter is not hypothetical.
+    licenseNote: >-
+      MIXED LICENSE - verified by reading the root LICENSE and ee/LICENSE directly.
+      Root LICENSE states: content under "ee/" and "cmd/enterprise/" is governed by ee/LICENSE;
+      everything else is "MIT Expat". ee/LICENSE was fetched and confirmed to be the proprietary
+      "SigNoz Enterprise license", which restricts use to licensed customers.
+      Therefore: the core is vendorable under MIT, but ee/ and cmd/enterprise/ are EXCLUDED and
+      must never be copied. Any automated vendoring from this repo must apply a path filter that
+      rejects those two directories.
+
+  - name: "coroot/coroot"
+    url: "https://github.com/coroot/coroot"
+    stars: 7838
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-02"
+    archived: false
+    stack: "eBPF-based zero-instrumentation observability, service map, SLO tracking"
+    complexity: professional
+    proposedLayerIds:
+      - obs-ebpf-zero-instrumentation
+      - obs-slo-tracking
+      - obs-service-map
+    whatToBorrow: >-
+      The strongest zero-instrumentation option - eBPF captures service-to-service traffic with
+      no code changes, which makes it viable as a default-on layer that cannot break the user's
+      application. The deployment artifact is a single file - manifests/coroot.yaml (not a tree
+      of manifests) - which is small enough to read end to end and adapt. Borrow it plus the SLO
+      model derived from observed traffic rather than hand-written SLIs.
+    whatToAvoid: >-
+      Needs a recent Linux kernel and privileged or CAP_BPF containers, so it cannot be the only
+      local path on macOS or Windows hosts - always pair it with a portable fallback layer.
+    licenseNote: >-
+      The previous revision flagged an open question about an enterprise directory. Resolved:
+      there is NO ee/ directory in coroot/coroot at main (checked, 404). The root LICENSE is
+      plain Apache-2.0 with no carve-out clause. Clean to vendor with the Apache notice.
+
+  - name: "grafana/alloy"
+    url: "https://github.com/grafana/alloy"
+    stars: 3346
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: "Grafana's OpenTelemetry Collector distribution with a programmable config language"
+    complexity: professional
+    proposedLayerIds:
+      - otel-collector-alloy
+      - obs-pipeline-processors
+    whatToBorrow: >-
+      An official OTel Collector distribution with a programmable configuration language.
+      Borrow example-config.alloy and the example/ directory (both confirmed present) - the
+      component-and-forward_to syntax is far more readable in a generated repo than deeply
+      nested YAML, and the dataflow is explicit.
+    whatToAvoid: >-
+      The Alloy configuration language does NOT port to a vanilla OTel Collector. For a
+      vendor-neutral scaffolder that is genuine lock-in, so this must be an opt-in alternative
+      to the plain collector layer, never the default.
+
+  - name: "jaegertracing/jaeger"
+    url: "https://github.com/jaegertracing/jaeger"
+    stars: 23012
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-15"
+    archived: false
+    stack: "Distributed tracing backend; v2 is built on the OTel Collector"
+    complexity: professional
+    proposedLayerIds:
+      - obs-trace-jaeger
+      - obs-stack-compose
+    whatToBorrow: >-
+      The all-in-one compose service (OTLP ingest on 4317/4318, UI on 16686) as the dev default
+      when only tracing is needed. Jaeger v2 is built on the OTel Collector, so its config IS a
+      collector config - that keeps dev and prod in a single format and is the main reason to
+      prefer it over a bespoke tracing backend.
+    whatToAvoid: >-
+      Traces only - no metrics or logs, so it cannot be the whole observability layer. The
+      all-in-one image is in-memory and loses everything on restart. The v1-to-v2 transition
+      changed flags and config format, so most compose files found online are dead; generate
+      against v2 only.
+
+  - name: "micrometer-metrics/micrometer"
+    url: "https://github.com/micrometer-metrics/micrometer"
+    stars: 4871
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: "JVM metrics and observation facade, Spring Boot Actuator integration"
+    complexity: professional
+    proposedLayerIds:
+      - obs-metrics-jvm-micrometer
+      - obs-tracing-jvm
+    whatToBorrow: >-
+      The JVM observability layer. Borrow MeterRegistry injection, micrometer-registry-prometheus
+      wiring that exposes /actuator/prometheus, common tags applied through a
+      MeterRegistryCustomizer, and the micrometer-observation API where a single Observation
+      emits metrics, spans and logs together. The micrometer-observation module is in THIS repo
+      (confirmed alongside micrometer-core, micrometer-commons and the jetty/jakarta modules),
+      but the span half of that promise is not: turning an Observation into a trace needs
+      micrometer-tracing from the separate micrometer-metrics/tracing repo (also Apache-2.0).
+      A generated JVM layer that adds micrometer-observation alone gets metrics and no spans,
+      which looks like a broken tracing setup rather than a missing dependency.
+    whatToAvoid: >-
+      Naming translation (dots to underscores between Micrometer and Prometheus) reliably trips
+      up query authors - document the mapping in the generated repo. Do not layer the
+      Observation API and raw OTel instrumentation together; pick one or spans get duplicated.
+
+  - name: "google/slo-generator"
+    url: "https://github.com/google/slo-generator"
+    stars: 564
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-02-25"
+    archived: false
+    stack: "Python - multi-backend SLO and error-budget computation (Cloud Monitoring, Prometheus, Elasticsearch, Datadog, Dynatrace)"
+    complexity: standard
+    proposedLayerIds:
+      - slo-multi-backend-generator
+    whatToBorrow: >-
+      The multi-backend SLO layer for stacks that are not Prometheus-only, which is where sloth
+      stops being an option. The copyable artifacts are concrete: samples/config.yaml is the
+      shared config, and its four top-level keys (default_exporters, backends, exporters,
+      error_budget_policies) are the schema to generate; note every backend credential in it is
+      written as a ${ENV_VAR} interpolation rather than a literal, which is exactly the pattern
+      a generated repo should preserve. samples/<backend>/ holds
+      per-backend SLO specs - samples/prometheus/ alone gives four spec shapes worth adapting
+      (slo_prom_metrics_availability_ratio.yaml, ..._availability_query_sli.yaml,
+      ..._latency_distribution_cut.yaml, ..._latency_query_sli.yaml), which between them cover
+      good-events/total-events ratio, raw-query SLI, and latency-bucket-threshold indicators.
+      Sibling directories (datadog, dynatrace, elasticsearch, opensearch, cloud_monitoring,
+      custom) show the same SLO restated against each backend, which is exactly the evidence a
+      generator needs to keep one spec portable. slo_generator/backends/ and
+      slo_generator/exporters/ are the plugin interfaces to read if a custom source is needed.
+    whatToAvoid: >-
+      Heavier and less focused than sloth - if the target stack is Prometheus-only, sloth is the
+      better generated default. Backend plugins pull cloud-vendor SDKs, so only install the one
+      backend actually in use.
+    verificationNote: >-
+      STALENESS CLAIM CORRECTED, then re-confirmed 2026-07-19. An older revision marked this
+      "LIKELY STALE - most recent release v2.6.0 from February 2024" and told readers not to use
+      it; that read the last RELEASE date as the last COMMIT date and was wrong. An infrequent
+      release cadence is not staleness.
+      The two dates recorded here differ and BOTH are correct - do not "fix" one to match the
+      other. lastCommit 2026-02-25 is the last commit on the default branch (master), read from
+      the commits atom feed. The GitHub API reports pushed_at 2026-07-06, which is later because
+      pushed_at reflects a push to ANY branch or tag, not just the default one. Either way the
+      repo is not archived and clears the 18-month gate comfortably. The `maintained` flag here
+      is judged on pushed_at per this file's own definition at the top.
+
+  # -------------------------------------------------------------------------
+  # ADDED 2026-07-19 - gap-fill pass. Every figure below was read from
+  # github.com repo HTML (star counter), the default-branch commits.atom feed
+  # (lastCommit) and the LICENSE file fetched from raw.githubusercontent.com.
+  # The GitHub REST API was rate-limited during this pass; the HTML/atom/raw
+  # method is the same one cross-checked against the API in the 2026-07-18 pass.
+  # -------------------------------------------------------------------------
+
+  - name: "open-telemetry/opentelemetry-go"
+    url: "https://github.com/open-telemetry/opentelemetry-go"
+    stars: 6480
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: "Go - OpenTelemetry API/SDK, OTLP trace/metric/log exporters"
+    complexity: standard
+    proposedLayerIds:
+      - otel-instrumentation-go
+      - otel-exporter-otlp
+      - obs-graceful-shutdown
+    whatToBorrow: >-
+      Go has no auto-instrumentation agent, so the explicit bootstrap IS the layer. The core
+      repo ships the API/SDK and the exporters (exporters/otlp/otlptrace/otlptracegrpc,
+      confirmed present) but has NO example/ or examples/ directory - a previous revision
+      cited example/otel-collector and example/dice here and both 404. The runnable examples
+      live in the SEPARATE open-telemetry/opentelemetry-go-contrib repo (also Apache-2.0, so
+      still vendorable): examples/dice/instrumented/otel.go is the exact file to copy, and
+      examples/dice/uninstrumented/ beside it gives the before/after diff showing precisely
+      what instrumentation adds. examples/otel-collector/ adds main.go plus a working
+      docker-compose.yaml, otel-collector.yaml and prometheus.yaml for the backend side.
+      The copyable unit is a single setupOTelSDK(ctx) function
+      that builds a resource.New with semconv service.name/version, registers a
+      TracerProvider with sdktrace.NewBatchSpanProcessor over an otlptracegrpc exporter, a
+      MeterProvider with a PeriodicReader, sets otel.SetTextMapPropagator with a composite
+      TraceContext+Baggage propagator, and returns a single shutdown(ctx) func that joins
+      every provider's Shutdown error. That returned-shutdown-closure idiom is the piece
+      worth standardising - it is what makes spans actually flush on SIGTERM.
+    whatToAvoid: >-
+      The propagator default is a no-op: forget otel.SetTextMapPropagator and traces silently
+      break at every service boundary while each service still looks correctly instrumented
+      on its own. This is the single most common Go OTel bug. HTTP/gRPC instrumentation lives
+      in the separate opentelemetry-go-contrib module (otelhttp, otelgrpc) versioned apart
+      from core - pin them as a set. Metrics and logs stabilised later than tracing.
+    portability: "High - stdlib-only wiring, no framework assumptions; drops into any Go service."
+
+  - name: "open-telemetry/opentelemetry-go-contrib"
+    url: "https://github.com/open-telemetry/opentelemetry-go-contrib"
+    stars: 1652
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: "Go - OTel HTTP/gRPC instrumentation libraries, propagators, detectors, runnable examples"
+    complexity: standard
+    proposedLayerIds:
+      - otel-instrumentation-go
+      - obs-http-server-instrumentation
+    whatToBorrow: >-
+      The companion the core Go SDK entry depends on, added during verification because the
+      core repo's examples were cited there but actually live here. Two things to take.
+      First, the examples: examples/dice/instrumented/otel.go is a complete, compiling
+      setupOTelSDK bootstrap, and the instrumented/ vs uninstrumented/ pair is the clearest
+      before/after in the whole OTel ecosystem for showing what a template's instrumentation
+      layer actually changes. examples/otel-collector/ pairs main.go with a working
+      docker-compose.yaml, otel-collector.yaml and prometheus.yaml.
+      Second, the middleware: instrumentation/net/http/otelhttp wraps a handler
+      (otelhttp.NewHandler) and a client transport in one line each, and
+      instrumentation/google.golang.org/grpc/otelgrpc supplies the stats-handler equivalent.
+      Those two lines are what actually produce server spans, so a Go observability layer that
+      omits them emits an empty trace tree.
+    whatToAvoid: >-
+      Versioned as a SEPARATE Go module from opentelemetry-go core and released on its own
+      cadence, so otelhttp/otelgrpc and the core SDK must be pinned as a compatible set - this
+      mismatch is the usual cause of confusing Go module resolution errors. Each example
+      directory is its own module with its own go.mod, so copying one wholesale drags a module
+      boundary into the generated repo; lift the source file and re-declare the dependency
+      against the parent module instead. otelgrpc's older interceptor API is deprecated in
+      favour of the stats handler - do not copy interceptor snippets found in older docs.
+    portability: "High - otelhttp is a stdlib net/http wrapper and mounts on any Go router."
+    verificationNote: >-
+      Added 2026-07-19. Promoted to a first-class entry rather than left as a bare cross-
+      reference, so the code it points at passes the same license gate as everything else.
+      Apache-2.0 read from the LICENSE file; 1652 stars, not archived, last commit 2026-07-17.
+
+  - name: "open-telemetry/opentelemetry-js"
+    url: "https://github.com/open-telemetry/opentelemetry-js"
+    stars: 3419
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: "TypeScript/JavaScript - OpenTelemetry API/SDK for Node and browser"
+    complexity: standard
+    proposedLayerIds:
+      - otel-instrumentation-node
+      - otel-exporter-otlp
+      - logging-trace-correlation-node
+    whatToBorrow: >-
+      The NodeSDK quickstart plus the packages/opentelemetry-sdk-trace-node README give the
+      copyable unit: an instrumentation.ts that constructs new NodeSDK({ resource,
+      traceExporter: new OTLPTraceExporter(), instrumentations:
+      [getNodeAutoInstrumentations()] }) and calls sdk.start(). Note the split: NodeSDK is in
+      THIS repo at experimental/packages/opentelemetry-sdk-node, but getNodeAutoInstrumentations
+      comes from @opentelemetry/auto-instrumentations-node which lives in the separate
+      opentelemetry-js-contrib repo - the one-line snippet spans two repos and two release
+      trains. The load-order rule is the
+      real content - that file must be imported before any instrumented library, which in
+      practice means `node --import ./instrumentation.mjs app.js` or --require for CJS. Pair
+      it with pino's mixin reading trace.getActiveSpan() to stamp trace_id onto every log line.
+    whatToAvoid: >-
+      getNodeAutoInstrumentations() enables everything including fs, which floods the backend
+      with useless spans - disable @opentelemetry/instrumentation-fs explicitly in any
+      generated config. Auto-instrumentation relies on module patching and does not work under
+      bundlers or ESM without the --import hook, so serverless/bundled targets need the manual
+      path. API and SDK packages version separately; a mismatched @opentelemetry/api produces
+      silent no-op tracers rather than an error.
+
+  - name: "open-telemetry/opentelemetry-js-contrib"
+    url: "https://github.com/open-telemetry/opentelemetry-js-contrib"
+    stars: 917
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: "TypeScript - Node auto-instrumentation meta-package and per-library instrumentations"
+    complexity: standard
+    proposedLayerIds:
+      - otel-instrumentation-node
+      - obs-http-server-instrumentation
+    whatToBorrow: >-
+      The half of the Node OTel story that is not in core, added during verification because
+      the opentelemetry-js entry's snippet silently depended on it.
+      packages/auto-instrumentations-node is the meta-package exporting
+      getNodeAutoInstrumentations(), and its README documents the per-instrumentation config
+      object - that config object is the artifact worth generating, because it is where you
+      disable the noisy instrumentations by name rather than accepting the default set.
+      packages/instrumentation-fs is the specific one to switch off. The individual
+      packages/instrumentation-* directories each carry a README with a minimal manual-
+      registration example, which is the path to use when bundling or serverless rules out the
+      auto-instrumentation hook.
+    whatToAvoid: >-
+      Released independently of opentelemetry-js core, so the auto-instrumentations version and
+      the SDK version must be pinned as a compatible pair; a mismatch typically surfaces as
+      instrumentations that load but never emit spans rather than as an install error. The
+      meta-package pulls a large dependency tree for libraries the app may not use - for a lean
+      image, depend on the specific instrumentation-* packages instead of the meta-package.
+    verificationNote: >-
+      Added 2026-07-19. Apache-2.0 read from the LICENSE file; 917 stars, not archived, last
+      commit 2026-07-17.
+
+  - name: "open-telemetry/opentelemetry-java-instrumentation"
+    url: "https://github.com/open-telemetry/opentelemetry-java-instrumentation"
+    stars: 2581
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: "Java - bytecode-agent auto-instrumentation for JVM frameworks"
+    complexity: professional
+    proposedLayerIds:
+      - otel-instrumentation-java
+      - otel-agent-jvm
+      - obs-metrics-jvm
+    whatToBorrow: >-
+      The zero-code JVM layer. What a scaffolder generates is not source but Dockerfile and
+      env: download opentelemetry-javaagent.jar from the release assets, add
+      -javaagent:/otel/opentelemetry-javaagent.jar to JAVA_TOOL_OPTIONS, then configure
+      entirely through OTEL_SERVICE_NAME, OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_TRACES_SAMPLER
+      and OTEL_INSTRUMENTATION_<name>_ENABLED. docs/agent-features.md,
+      docs/supported-libraries.md and docs/advanced-configuration-options.md (all three
+      confirmed present at main) are the reference for trimming the agent down; there is no
+      docs/suppressing-instrumentation.md, which a previous revision cited and which 404s.
+      Borrow the
+      multi-stage Dockerfile pattern that pins the agent by version and checksum rather than
+      fetching latest at build time.
+    whatToAvoid: >-
+      The agent adds meaningful JVM startup time and patches hundreds of libraries by default -
+      for short-lived or serverless JVMs the cost is real, and for anything latency-sensitive
+      the instrumentation list should be narrowed. Never fetch the jar unpinned at container
+      build. Agent and SDK versions must be compatible if the app also uses the manual API.
+    portability: "Config-only - the layer is Dockerfile plus env vars, so it transfers across any JVM framework."
+
+  - name: "serilog/serilog"
+    url: "https://github.com/serilog/serilog"
+    stars: 8013
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-10"
+    archived: false
+    stack: ".NET structured logging with message templates and sinks"
+    complexity: simple
+    proposedLayerIds:
+      - logging-structured-dotnet-serilog
+      - logging-enrichers
+      - logging-trace-correlation-dotnet
+    whatToBorrow: >-
+      The message-template model is the point: log.Information("Order {OrderId} shipped to
+      {Customer}", id, customer) preserves OrderId and Customer as queryable fields instead of
+      flattening to a string. Borrow the two-stage bootstrap the repo documents - a minimal
+      Serilog.Log.Logger created before the host builds so startup crashes are still captured,
+      then ReadFrom.Configuration(context.Configuration) once the host exists so sinks and
+      levels come from appsettings.json rather than code. Take the enrichment chain
+      (FromLogContext, WithMachineName, WithEnvironmentName) and LogContext.PushProperty for
+      scoped correlation ids, plus CompactJsonFormatter for production output.
+      Scope note: this repo contains only src/Serilog - the core. Three of the pieces named
+      above ship from separate (also Apache-2.0) repos and need their own package references:
+      CompactJsonFormatter from serilog/serilog-formatting-compact, ReadFrom.Configuration
+      from serilog/serilog-settings-configuration, and UseSerilogRequestLogging from
+      serilog/serilog-aspnetcore. A generated repo that references only Serilog core will not
+      compile any of them.
+    whatToAvoid: >-
+      String interpolation in a log call defeats the entire structured model and produces
+      unqueryable text plus a cardinality explosion - forbid it with a Serilog analyzer in any
+      generated repo. Sinks are separate independently versioned packages. The file sink needs
+      an explicit rolling and retention policy or it will fill a disk. Serilog.AspNetCore's
+      UseSerilogRequestLogging replaces the noisy default request logging and should be enabled
+      rather than layered on top of it. The analyzer that catches interpolated log messages is
+      Suchiman/SerilogAnalyzer, a THIRD-PARTY repo outside the Serilog org (Apache-2.0) - vet
+      it as such rather than assuming it is an official Serilog component.
+
+  - name: "rs/zerolog"
+    url: "https://github.com/rs/zerolog"
+    stars: 12476
+    spdx: "MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-04-20"
+    archived: false
+    stack: "Go zero-allocation JSON structured logging"
+    complexity: simple
+    proposedLayerIds:
+      - logging-structured-go-zerolog
+      - logging-http-middleware
+      - logging-trace-correlation-go
+    whatToBorrow: >-
+      The chained-field API (log.Info().Str("k",v).Int("n",1).Msg("done")) and, more usefully
+      for a template, hlog - the bundled net/http middleware in the hlog subpackage that
+      attaches a request-scoped logger to the context, generates a request id, and emits one
+      access-log line per request with method, status, size and duration. Borrow the
+      zerolog.New(os.Stderr).With().Timestamp().Caller().Logger() constructor plus the
+      ConsoleWriter-in-dev / raw-JSON-in-prod switch, and the hook interface for stamping
+      trace_id from an OTel span onto every event.
+    whatToAvoid: >-
+      The zero-allocation guarantee is lost the moment you use the reflection-based
+      .Interface() or .Fields() helpers - keep to typed field methods on hot paths. An Event
+      is single-use and must be terminated by exactly one Msg/Send; forgetting it drops the
+      log with no error, and reusing an Event after Msg is a data race. Global log.Logger is
+      convenient but makes tests order-dependent - prefer injecting a logger.
+    portability: "High - stdlib io.Writer sink, no framework coupling."
+
+  - name: "uber-go/zap"
+    url: "https://github.com/uber-go/zap"
+    stars: 24576
+    spdx: "MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-04-28"
+    archived: false
+    stack: "Go high-performance structured logging"
+    complexity: standard
+    proposedLayerIds:
+      - logging-structured-go-zap
+      - logging-sampling
+      - logging-testable
+    whatToBorrow: >-
+      The config-driven constructor is what to adapt: zap.Config as a struct populated from
+      environment (level, encoding json|console, outputPaths, initialFields) then .Build(),
+      which gives dev and prod presets from one code path via NewDevelopmentConfig /
+      NewProductionConfig. Borrow the production sampling policy (SamplingConfig Initial/
+      Thereafter) - it is the built-in answer to a hot loop flooding the log pipeline, which
+      zerolog leaves to you. zaptest/observer is the other high-value piece: an in-memory core
+      that makes "assert this log line was emitted with these fields" a normal unit test.
+    whatToAvoid: >-
+      Two APIs coexist and mixing them confuses generated code - the typed zap.Logger is fast,
+      SugaredLogger is ergonomic but allocates; pick one per template and stay with it. Missing
+      defer logger.Sync() loses buffered entries on exit, and Sync on stderr returns a
+      spurious error on some platforms that naive code will log or panic on. The Config struct
+      is verbose enough that it belongs in one config module, never inline at call sites.
+
+  - name: "getsentry/sentry-python"
+    url: "https://github.com/getsentry/sentry-python"
+    stars: 2197
+    spdx: "MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: "Python error and performance monitoring SDK with framework integrations"
+    complexity: standard
+    proposedLayerIds:
+      - observability-sentry-python
+      - observability-pii-scrubbing
+      - obs-release-tracking
+    whatToBorrow: >-
+      The single sentry_sdk.init() block belongs in one config module: dsn and environment from
+      env vars, traces_sample_rate as a float setting, release stamped from the CI commit sha,
+      and an explicit integrations list (DjangoIntegration, FastApiIntegration,
+      CeleryIntegration) rather than relying on auto-discovery. Borrow the before_send hook for
+      scrubbing PII before transmission and the ignore_errors list for expected exceptions,
+      plus sentry_sdk.set_user / set_tag for request-scoped context. The integrations/
+      directory is a readable catalogue of how each framework hooks its error path.
+    whatToAvoid: >-
+      send_default_pii=True ships request bodies, headers and user data to a third party - it
+      must default to False in any generated repo and be an explicit opt-in. traces_sample_rate
+      of 1.0 will exhaust a quota under real traffic. The DSN is not secret but the auth token
+      used for release/sourcemap upload is, and belongs in CI secrets. Celery and ASGI
+      integrations need init() to run in each worker process, not only in the parent.
+
+  - name: "hellofresh/health-go"
+    url: "https://github.com/hellofresh/health-go"
+    stars: 589
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-04-17"
+    archived: false
+    stack: "Go library for HTTP health/readiness endpoints with pluggable dependency checks"
+    complexity: simple
+    proposedLayerIds:
+      - health-checks
+      - health-readiness-go
+      - obs-dependency-probes
+    whatToBorrow: >-
+      The smallest complete readiness pattern in Go, and a direct fit for the existing
+      health-checks layer. Borrow health.New() with health.WithChecks(health.Config{Name,
+      Timeout, SkipOnErr, Check: func(ctx) error}) - the per-check Timeout and the SkipOnErr
+      flag are the two fields that matter, because they encode the distinction between a
+      degraded dependency (report but stay serving) and a fatal one (fail readiness). The
+      checks/ subpackages give ready-made probes for postgres, mysql, redis, mongo, rabbitmq
+      and http, each a tiny file that is easy to read and adapt. The handler returns aggregate
+      status plus per-check detail as JSON, which is exactly the response shape a Kubernetes
+      readinessProbe and a status page both want.
+    whatToAvoid: >-
+      Do not point a liveness probe at an endpoint that checks dependencies - a slow database
+      then causes Kubernetes to kill otherwise healthy pods and cascade the outage. Generate
+      two endpoints: a trivial /livez returning 200 unconditionally, and /readyz running these
+      checks. Keep check timeouts well below the probe timeout, and do not expose the detailed
+      JSON publicly since it enumerates your internal dependencies.
+    licenseNote: >-
+      Apache-2.0, but the file is LICENSE.txt (lowercase extension), not LICENSE - the
+      attribution step in a generated repo must copy that exact filename, same caveat as
+      opentelemetry-dotnet and dotnet/aspire which both use LICENSE.TXT.
+    portability: "High - plain net/http handler, mounts on any Go router."
+
+  - name: "pyrra-dev/pyrra"
+    url: "https://github.com/pyrra-dev/pyrra"
+    stars: 1529
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-06-22"
+    archived: false
+    stack: "Go + React - SLO definitions compiled to Prometheus recording/alerting rules, error-budget UI"
+    complexity: standard
+    proposedLayerIds:
+      - slo-error-budget
+      - slo-prometheus-rules
+      - obs-alerting-burnrate
+    whatToBorrow: >-
+      The error-budget calculator the brief asks for, and the natural complement to sloth.
+      Borrow the ServiceLevelObjective spec shape from examples/ - target as a percentage,
+      window as a duration, and an indicator that is either a ratio (errors query over total
+      query) or a latency block with a bucket threshold. Pyrra compiles that into multi-window
+      multi-burn-rate recording and alerting rules, so the copyable artifact is the generated
+      rule YAML plus the filesystem/kubernetes operating modes: filesystem mode reads a
+      directory of SLO YAML and writes Prometheus rule files, which is exactly what a
+      generated repo can commit and diff in CI without running an operator. The UI showing
+      remaining budget and burn rate is the reference for what an error-budget dashboard needs.
+    whatToAvoid: >-
+      It expects Prometheus-compatible metrics that already exist and are correctly labelled -
+      an SLO layer is worthless without a working RED-metrics layer beneath it, so order the
+      layer dependencies accordingly. The Kubernetes operator mode pulls in CRDs and a
+      controller that a small repo does not need; prefer filesystem mode as the default. The
+      generated recording rules add real cardinality and evaluation cost at scale.
+
+  - name: "prometheus-operator/kube-prometheus"
+    url: "https://github.com/prometheus-operator/kube-prometheus"
+    stars: 7695
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-18"
+    archived: false
+    stack: "Jsonnet + generated Kubernetes manifests - Prometheus Operator, Alertmanager, Grafana, node-exporter, kube-state-metrics"
+    complexity: enterprise
+    proposedLayerIds:
+      - obs-stack-kubernetes
+      - obs-alerting-rules
+      - slo-prometheus-rules
+    whatToBorrow: >-
+      The production Kubernetes counterpart to dockprom's compose stack. The manifests/
+      directory is fully generated, committed YAML - it can be applied directly or read as the
+      reference for what a complete cluster monitoring install contains: ServiceMonitor and
+      PodMonitor custom resources, PrometheusRule objects carrying the battle-tested
+      kubernetes-apps / kubernetes-resources alert families, Alertmanager routing config, and
+      RBAC. Borrow the ServiceMonitor shape as the standard way an application declares its own
+      scrape target, and the PrometheusRule alert definitions (KubePodCrashLooping,
+      KubeDeploymentReplicasMismatch and friends) as a starting alert set rather than authoring
+      one from scratch. jsonnet/ shows the customisation path if a repo wants to regenerate.
+    whatToAvoid: >-
+      Enterprise weight - this is a whole cluster monitoring platform with a substantial
+      resource footprint, wholly inappropriate as a default for a small generated repo. Version
+      compatibility with the Kubernetes minor release is strict and documented in the README
+      matrix; applying a mismatched release breaks on CRD schema. The bundled Grafana is AGPL
+      as a deployed binary - configuring it is fine, vendoring Grafana source is not. Editing
+      manifests/ by hand is a dead end since it is regenerated from jsonnet.
+
+  - name: "prometheus/prometheus"
+    url: "https://github.com/prometheus/prometheus"
+    stars: 65222
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-18"
+    archived: false
+    stack: "Go - metrics TSDB, scrape engine, PromQL, alerting rules"
+    complexity: professional
+    proposedLayerIds:
+      - obs-metrics-prometheus
+      - obs-alerting-rules
+      - obs-recording-rules
+    whatToBorrow: >-
+      The upstream source of the config schemas every other layer here references. Borrow
+      documentation/examples/prometheus.yml as the canonical scrape_config skeleton - global
+      scrape_interval and evaluation_interval, rule_files, alerting.alertmanagers, and
+      relabel_configs, which is the part most templates get wrong. The config/testdata tree is
+      an unusually good reference for valid and invalid config shapes, and the unit-test format
+      consumed by `promtool test rules` lets a generated repo assert its alerts actually fire
+      against synthetic series - that promtool rule test is a genuinely underused CI gate worth
+      generating.
+    whatToAvoid: >-
+      Do not vendor Go source; take config, rules and promtool usage. Default retention is
+      local-disk only with no built-in HA or long-term storage - a template that implies
+      durability without adding remote_write is misleading. High-cardinality labels (user ids,
+      request ids, full URLs) are the standard way people destroy a Prometheus instance, so any
+      generated instrumentation guidance must call that out explicitly.
+
+# ---------------------------------------------------------------------------
+# REFERENCE-ONLY - weak copyleft. Read for design ideas, never copy files.
+# ---------------------------------------------------------------------------
+referenceOnly:
+  - name: "vectordotdev/vector"
+    url: "https://github.com/vectordotdev/vector"
+    spdx: "MPL-2.0"
+    licenseClass: reference-only
+    reason: >-
+      LICENSE fetched from raw.githubusercontent.com confirms Mozilla Public License 2.0.
+      File-level copyleft: modifying an MPL file obliges you to publish that file's source under
+      MPL, which does not infect the rest of a generated repo but is still a condition we do not
+      want to impose silently. Read its log-pipeline and transform design for ideas; do not copy
+      files into generated repos.
+    verificationNote: >-
+      Moved out of the `excluded:` block during verification. The previous revision filed it
+      under `excluded` while labelling it licenseClass reference-only, contradicting the file's
+      own taxonomy. The classification was right; the placement was wrong. MPL-2.0 is
+      reference-only, not excluded.
+
+# ---------------------------------------------------------------------------
+# EXCLUDED - license gate failed. Each verified from the LICENSE file itself.
+# ---------------------------------------------------------------------------
+excluded:
+  - name: "grafana/loki"
+    url: "https://github.com/grafana/loki"
+    stars: 28581
+    spdx: "AGPL-3.0"
+    licenseClass: excluded
+    lastCommit: "2026-07-18"
+    archived: false
+    reason: >-
+      Added 2026-07-19. AGPL-3.0 confirmed by fetching the LICENSE file from
+      raw.githubusercontent.com, which opens "GNU AFFERO GENERAL PUBLIC LICENSE Version 3,
+      19 November 2007". Same boundary as grafana/grafana: Loki may be RUN as a container and
+      pointed at by a collector exporter or a Grafana datasource we author ourselves, but no
+      source, no client library code and no bundled config from this repo may be vendored into
+      a generated repo. Worth stating explicitly because grafana/docker-otel-lgtm - which IS
+      promoted above as Apache-2.0 - bundles a Loki binary in its image. Running that image is
+      fine; copying Loki source out of it is not.
+  - name: "grafana/grafana"
+    url: "https://github.com/grafana/grafana"
+    stars: 75619
+    spdx: "AGPL-3.0"
+    licenseClass: excluded
+    lastCommit: "2026-07-18"
+    archived: false
+    reason: >-
+      AGPL-3.0 confirmed by reading the LICENSE file ("GNU AFFERO GENERAL PUBLIC LICENSE
+      Version 3"). Copying Grafana source would force AGPL terms onto every repo Groundplan
+      generates. Grafana may still be RUN as a container and configured via provisioning YAML
+      that we author ourselves - that config is our own work and carries no AGPL obligation -
+      but no source, plugin code or bundled dashboard JSON from this repo may be vendored.
+
+  - name: "openobserve/openobserve"
+    url: "https://github.com/openobserve/openobserve"
+    spdx: "AGPL-3.0"
+    licenseClass: excluded
+    reason: >-
+      AGPL-3.0 confirmed by fetching the LICENSE file directly ("GNU AFFERO GENERAL PUBLIC
+      LICENSE Version 3"), upgrading the previous revision's README-based claim to a primary
+      source. A separate commercial Enterprise Edition exists. The license gate excludes it
+      regardless of stars or activity.
+
+  - name: "getsentry/sentry"
+    url: "https://github.com/getsentry/sentry"
+    spdx: "FSL-1.1-Apache-2.0"
+    licenseClass: excluded
+    reason: >-
+      LICENSE.md fetched from raw.githubusercontent.com confirms "Functional Source License,
+      Version 1.1, Apache 2.0 Future License". Source-available with a competitive-use
+      restriction, not open source - excluded. This applies to the Sentry SERVER only; the
+      getsentry/sentry-javascript SDK is separately MIT and is promoted in sources above.