@opengroundplan/core 0.1.1

package/catalog/sources/layer-plan.yaml

@@ -0,0 +1,3919 @@
+# Groundplan consolidated layer plan
+#
+# Generated: 2026-07-19 from the 17 category files in this directory.
+#
+# HOW THIS WAS BUILT
+# ------------------
+# The 313 catalog entries proposed 883 distinct `proposedLayerIds` between them. That number is
+# not a taxonomy, it is a cartesian product: the category researchers wrote one id per
+# (capability x stack x library) combination, so `db-postgres-drizzle`, `db-postgres-prisma`,
+# `db-mysql-drizzle`, `db-sqlserver-kysely` and thirty-one of their siblings are four ids for
+# what are really TWO orthogonal choices - which engine, and which access layer.
+#
+# This plan collapses those 883 ids onto 233 layers by separating the axes and turning each axis
+# into a `choiceSet`. Where the collapse was lossy - where an id encoded a genuine capability
+# rather than a combination - the id survives as its own layer. Every original id is reachable:
+# either it IS a layer here, or it is named in that layer's `absorbs:` list.
+#
+# `absorbs` is therefore the audit trail. If an id from a category YAML does not appear as a
+# layer `id` and does not appear in any `absorbs`, that is a bug in this plan, not a decision.
+#
+# STATUS
+# ------
+#   status: built     - a directory already exists in templates/layers/. 22 of these.
+#   status: proposed  - everything else. 211 of these.
+# The built set was read from templates/layers/ on 2026-07-19 and its `requires`/`conflicts`/
+# `provides` were read from each blueprint.yaml, so the edges below for built layers are the
+# real ones, not guesses.
+#
+# TIERS
+# -----
+#   foundation - repo scaffolding. Almost every generated repo wants these. No domain opinion.
+#   core       - the load-bearing choices: runtime, framework, datastore, auth. Mostly choice sets.
+#   capability - cross-cutting features layered onto a core. Composable, mostly independent.
+#   domain     - a business vertical: billing, commerce, CMS, game, data platform.
+#   specialist - narrow, high-effort, low-frequency. Build last or never.
+#
+# CHOICE SETS
+# -----------
+# `choiceSet: <name>` means pick-one. Groundplan's CLI must render these as radio groups. Without
+# them a user can select three conflicting databases and only discover the clash at resolve time.
+# Members of a choice set are implicitly mutually exclusive - `conflicts` below lists only
+# CROSS-set conflicts, the ones a pick-one widget cannot prevent.
+#
+# LICENSE
+# -------
+# Every url under `sources:` is `licenseClass: vendorable` in README.md unless the layer carries
+# an explicit `licenseNote`. Reference-only and excluded sources are NEVER listed as a layer
+# source; where such a source is the best prior art, the layer says so in `licenseNote` and is
+# marked `fromScratch: true`. See gaps.md.
+
+# UNRESOLVED: DANGLING EDGES IN THE SHIPPED BLUEPRINTS
+# -----------------------------------------------------
+# Four `conflicts` entries in templates/layers/*/blueprint.yaml name layer ids that do not exist
+# in templates/layers/ and do not match any id in this plan. They are reproduced verbatim below
+# rather than silently renamed, because guessing at them would hide a real inconsistency in the
+# shipped set. Each needs a human decision before the resolver can be trusted:
+#
+#   lint-format          conflicts: hono-api            -> probably this plan's `api-hono`.
+#   observability-otel   conflicts: dotnet-aspire       -> probably `infra-dotnet-aspire`.
+#   queue-broker         conflicts: react-vite-spa      -> probably `app-vite-spa`.
+#   queue-broker         conflicts: turborepo-monorepo  -> probably `monorepo-turborepo`.
+#
+# Two of these are also questionable on the merits, not just the naming. `queue-broker conflicts
+# turborepo-monorepo` reads as a guard against adding a worker to a repo with no server, but a
+# turborepo monorepo is precisely where a separate worker app belongs. And `lint-format conflicts
+# hono-api` has no obvious justification at all. Resolve the names first, then re-argue the edges.
+
+version: 1
+generated: "2026-07-19"
+generatedFrom: 17 category files, 313 entries, 304 unique repositories
+rawLayerIdsConsolidated: 883
+layerCount: 233
+builtCount: 22
+proposedCount: 211
+
+# ---------------------------------------------------------------------------------------------
+choiceSets:
+  - id: runtime-language
+    prompt: Primary language and runtime
+    required: true
+    virtual: true
+    note: >-
+      The root choice, and the only set with no layers of its own - it is a filter, not a
+      selection. The CLI should ask it first and hide inapplicable sets rather than offering
+      them and rejecting them at resolve time. `virtual: true` marks that no layer declares
+      `choiceSet: runtime-language`; a validator must not read that as an empty set.
+  - id: backend-framework
+    prompt: Backend HTTP framework
+    filteredBy: runtime-language
+  - id: frontend-framework
+    prompt: Frontend framework and router
+    filteredBy: runtime-language
+  - id: db-engine
+    prompt: Primary datastore
+    note: The engine only. Which library talks to it is a separate question.
+  - id: db-access
+    prompt: Database access layer
+    filteredBy: [runtime-language, db-engine]
+    note: >-
+      Orthogonal to db-engine. Drizzle/Prisma/Kysely all speak Postgres, MySQL, SQLite and
+      Turso; EF Core and Dapper both speak SQL Server and Postgres. Modelling these as one
+      combined choice was the single biggest source of id explosion in the raw catalog.
+  - id: migrations
+    prompt: Schema migration tool
+    filteredBy: db-access
+  - id: auth-strategy
+    prompt: Authentication strategy
+  - id: authz-model
+    prompt: Authorization model
+  - id: test-runner-unit
+    prompt: Unit test runner
+    filteredBy: runtime-language
+  - id: test-runner-e2e
+    prompt: End-to-end test runner
+  - id: queue-backend
+    prompt: Background job backend
+  - id: realtime-transport
+    prompt: Realtime transport
+  - id: broker
+    prompt: Message broker
+  - id: payments-provider
+    prompt: Payment provider
+  - id: cms-backend
+    prompt: Content backend
+  - id: commerce-backend
+    prompt: Commerce backend
+  - id: vector-store
+    prompt: Vector store
+  - id: agent-framework
+    prompt: LLM agent framework
+  - id: game-renderer
+    prompt: 3D renderer or engine
+  - id: game-physics
+    prompt: Physics engine
+    filteredBy: game-renderer
+  - id: mobile-desktop-shell
+    prompt: Mobile or desktop shell
+  - id: data-orchestrator
+    prompt: Data pipeline orchestrator
+  - id: data-transform
+    prompt: Transformation engine
+  - id: lint-toolchain
+    prompt: Lint and format toolchain
+    filteredBy: runtime-language
+  - id: obs-backend
+    prompt: Observability backend for local development
+  - id: iac-tool
+    prompt: Infrastructure-as-code tool
+  - id: deploy-target
+    prompt: Deployment target
+
+# ---------------------------------------------------------------------------------------------
+layers:
+
+  # ===========================================================================================
+  # TIER: foundation
+  # ===========================================================================================
+
+  - id: repo-scaffold
+    category: foundation
+    tier: foundation
+    status: proposed
+    what: >-
+      The empty-repo floor every other layer assumes - README skeleton, LICENSE selection,
+      .gitignore per stack, .editorconfig, CODEOWNERS, and the THIRD-PARTY-NOTICES.md file that
+      vendored-code attribution is appended to. Nothing here is optional; it is the substrate.
+    stacks: [any]
+    sources:
+      - https://github.com/github/spec-kit
+      - https://github.com/devcontainers/templates
+    requires: []
+    conflicts: []
+    absorbs: [config-typed-env, tsconfig-node-web-split]
+    note: >-
+      THIRD-PARTY-NOTICES.md belongs here rather than in each vendoring layer, so that layers
+      append to a file guaranteed to exist. See README.md#attribution.
+
+  - id: lint-format
+    category: foundation
+    tier: foundation
+    status: built
+    what: Lint, format and code-style config with an .editorconfig baseline.
+    stacks: [node, python, go, dotnet]
+    sources:
+      - https://github.com/biomejs/biome
+      - https://github.com/oxc-project/oxc
+    requires: []
+    conflicts: [hono-api]
+    provides: [lint, format, code-style, lint-config, editorconfig]
+    absorbs: [tooling-eslint-prettier, lint-eslint-flat, lint-very-good-analysis]
+    note: >-
+      Built. The conflict with hono-api is recorded in the shipped blueprint and is preserved
+      here verbatim; it is not a conclusion of this plan.
+
+  - id: lint-biome
+    category: foundation
+    tier: foundation
+    status: proposed
+    choiceSet: lint-toolchain
+    what: >-
+      Single-binary lint+format for JS/TS replacing the eslint+prettier pair. Borrow biome.json
+      and the migration command story.
+    stacks: [node, typescript]
+    sources:
+      - https://github.com/biomejs/biome
+    requires: [lint-format]
+    conflicts: []
+    absorbs: [tooling-biome]
+
+  - id: lint-oxlint
+    category: foundation
+    tier: foundation
+    status: proposed
+    choiceSet: lint-toolchain
+    what: Rust-based JS/TS linter for repos that want speed but keep prettier for formatting.
+    stacks: [node, typescript]
+    sources:
+      - https://github.com/oxc-project/oxc
+    requires: [lint-format]
+    conflicts: []
+    absorbs: [lint-oxlint]
+
+  - id: lint-precommit
+    category: foundation
+    tier: foundation
+    status: proposed
+    what: >-
+      .pre-commit-config.yaml wiring the language linters plus gitleaks and terraform hooks into
+      one local gate. The `stages` split (fast on commit, full on push) is the part worth copying.
+    stacks: [any]
+    sources:
+      - https://github.com/gitleaks/gitleaks
+      - https://github.com/antonbabenko/pre-commit-terraform
+    requires: [lint-format]
+    conflicts: []
+    absorbs: [lint-precommit-base, lint-precommit-terraform, security-precommit-hooks]
+
+  - id: hooks-commit-conventions
+    category: foundation
+    tier: foundation
+    status: proposed
+    what: husky + commitlint + lint-staged enforcing conventional commits at the client side.
+    stacks: [node]
+    sources:
+      - https://github.com/ixartz/Next-js-Boilerplate
+      - https://github.com/Blazity/next-enterprise
+    requires: [lint-format]
+    conflicts: []
+    absorbs: [hooks-husky-commitlint, tooling-husky-commitlint]
+
+  - id: docker
+    category: foundation
+    tier: foundation
+    status: built
+    what: Multi-stage Dockerfile with a non-root user and cached dependency layers.
+    stacks: [any]
+    sources:
+      - https://github.com/nickjj/docker-rails-example
+      - https://github.com/docker/awesome-compose
+    requires: []
+    conflicts: []
+    provides: [container-image, dockerfile, docker-compose, containerization]
+    absorbs: [container-docker-multistage, container-nonroot-user, deploy-docker]
+
+  - id: docker-compose
+    category: foundation
+    tier: foundation
+    status: built
+    what: Local service stack - app plus its backing services - with healthchecks and profiles.
+    stacks: [any]
+    sources:
+      - https://github.com/docker/awesome-compose
+      - https://github.com/nickjj/docker-rails-example
+    requires: []
+    conflicts: []
+    provides: [local-stack, container-runtime, dev-services, compose-network]
+    absorbs:
+      [compose-local-dev, compose-postgres, compose-mysql, compose-nginx-proxy,
+       infra-docker-compose, dev-docker-compose-postgres, deploy-docker-compose,
+       db-postgres-docker-compose, docker-compose-vector, testing-compose-fixtures]
+    licenseNote: >-
+      awesome-compose is CC0-1.0 - zero attribution burden, the cheapest source in the catalog.
+      But its stacks are demos: plaintext DB passwords inline, no restart policy, no resource
+      limits. Never emit one without replacing credentials and adding healthcheck/restart.
+
+  - id: devcontainer
+    category: foundation
+    tier: foundation
+    status: built
+    what: devcontainer.json plus editor settings for a reproducible containerised dev environment.
+    stacks: [any]
+    sources:
+      - https://github.com/devcontainers/templates
+      - https://github.com/devcontainers/features
+    requires: []
+    conflicts: []
+    provides: [devcontainer, dev-environment, containerized-dev, docker-in-dev, editor-settings]
+    absorbs:
+      [devcontainer-base, devcontainer-node, devcontainer-python, devcontainer-go,
+       devcontainer-features, devcontainer-docker-in-docker]
+    note: >-
+      devcontainers/features is the single best real-world model of a composable layer system.
+      The feature.json + install.sh pairing and the `installsAfter` dependency ordering map
+      almost one-to-one onto Groundplan's own layer model - borrow the concept, not the OCI
+      packaging assumption.
+
+  - id: nix-devshell
+    category: foundation
+    tier: specialist
+    status: proposed
+    what: flake.nix / devenv.nix pinning the whole toolchain, for teams already on Nix.
+    stacks: [any]
+    sources: []
+    requires: []
+    conflicts: [devcontainer]
+    absorbs: [nix-flake-base, nix-devenv, devenv-services-postgres]
+    fromScratch: true
+    licenseNote: >-
+      the-nix-way/dev-templates is MPL-2.0 - REFERENCE-ONLY, no files may be copied. A naive
+      matcher reads MPL as AGPL because the Secondary License clause names the Affero GPL;
+      it is neither. Read it, then author the flake fresh.
+
+  - id: task-runner
+    category: foundation
+    tier: foundation
+    status: proposed
+    what: >-
+      A plain shell file of named functions (`./run test`, `./run lint`) replacing a Makefile.
+      Works identically on host and inside the container, which a Makefile does not.
+    stacks: [any]
+    sources:
+      - https://github.com/nickjj/docker-rails-example
+    requires: []
+    conflicts: []
+    absorbs: [task-runner-shell]
+
+  - id: ci-github-actions
+    category: foundation
+    tier: foundation
+    status: built
+    what: >-
+      Build/test/lint/typecheck pipeline with dependency caching and required-checks wiring.
+    stacks: [any]
+    sources:
+      - https://github.com/nickjj/docker-rails-example
+      - https://github.com/step-security/harden-runner
+      - https://github.com/ixartz/Next-js-Boilerplate
+    requires: []
+    conflicts: []
+    provides:
+      [ci, ci-pipeline, build-pipeline, test-pipeline, lint-pipeline, typecheck-pipeline,
+       dependency-caching, required-checks, github-actions]
+    absorbs:
+      [ci-matrix-node, ci-matrix-python, ci-reusable-workflow, ci-coverage-report,
+       deploy-github-actions, ci-github-actions-release]
+    portability: github-actions-only
+
+  - id: ci-container-publish
+    category: foundation
+    tier: foundation
+    status: proposed
+    what: >-
+      Multi-arch image build and push to GHCR with buildx, layer caching, and digest-pinned
+      base images.
+    stacks: [any]
+    sources:
+      - https://github.com/nickjj/docker-rails-example
+    requires: [ci-github-actions, docker]
+    conflicts: []
+    absorbs: [ci-docker-publish, ci-release-multiarch]
+    portability: github-actions-only
+
+  - id: ci-test-sharding
+    category: foundation
+    tier: capability
+    status: proposed
+    what: >-
+      Matrix sharding for suites that have outgrown a single runner, plus the merge-reports step
+      that makes sharded runs produce one coverage artifact instead of N.
+    stacks: [node, python, dotnet]
+    sources:
+      - https://github.com/microsoft/playwright
+      - https://github.com/vitest-dev/vitest
+    requires: [ci-github-actions]
+    conflicts: []
+    absorbs: [ci-test-sharding, testing-incremental-analysis, testing-monorepo-projects]
+
+  - id: release-automation
+    category: foundation
+    tier: foundation
+    status: built
+    what: >-
+      Conventional commits to changelog to semver tag to GitHub release to package publish,
+      with trusted publishing rather than long-lived tokens.
+    stacks: [any]
+    sources:
+      - https://github.com/goreleaser/goreleaser
+    requires: []
+    conflicts: []
+    provides:
+      [release-automation, conventional-commits, commit-lint, changelog, semantic-versioning,
+       version-tags, github-release, package-publish, trusted-publishing]
+    absorbs: [release-changelog, release-semantic-release, release-goreleaser]
+
+  - id: monorepo-turborepo
+    category: foundation
+    tier: foundation
+    status: proposed
+    what: >-
+      turbo.json task graph with remote caching, plus the packages/* + apps/* split and the
+      import-boundary lint rule that stops the split decaying into a shared-everything blob.
+    stacks: [node, typescript]
+    sources:
+      - https://github.com/vercel/turborepo
+      - https://github.com/alan2207/bulletproof-react
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs: [tooling-turborepo, lint-import-boundaries, arch-feature-sliced]
+
+  - id: env-typed-config
+    category: foundation
+    tier: foundation
+    status: proposed
+    what: >-
+      Zod/pydantic-validated environment schema that fails at boot rather than at first use,
+      with the server/client split enforced at the type level. Directly implements this repo's
+      no-static-values rule - config is read here, once, and nowhere else.
+    stacks: [node, typescript, python]
+    sources:
+      - https://github.com/t3-oss/create-t3-app
+      - https://github.com/ixartz/Next-js-Boilerplate
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs: [tooling-t3-env, config-typed-env, config-env-zod-typed, config-env-tiered]
+
+  # ===========================================================================================
+  # TIER: core - backend
+  # ===========================================================================================
+
+  - id: api-fastapi
+    category: backend-api
+    tier: core
+    status: proposed
+    choiceSet: backend-framework
+    what: >-
+      FastAPI app with routers, dependency-injected sessions, pydantic settings and generated
+      OpenAPI. full-stack-fastapi-template is the reference repo layout; minimal-fastapi-postgres
+      is the strip-down.
+    stacks: [python]
+    sources:
+      - https://github.com/fastapi/fastapi
+      - https://github.com/fastapi/full-stack-fastapi-template
+      - https://github.com/rafsaf/minimal-fastapi-postgres-template
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs: [api-fastapi, db-session-dependency-fastapi, validation-pydantic, auth-oauth2-password]
+
+  - id: api-litestar
+    category: backend-api
+    tier: core
+    status: proposed
+    choiceSet: backend-framework
+    what: Litestar app - the ASGI alternative with first-class DI and msgspec serialisation.
+    stacks: [python]
+    sources:
+      - https://github.com/litestar-org/litestar
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs: [api-litestar]
+
+  - id: api-express
+    category: backend-api
+    tier: core
+    status: proposed
+    choiceSet: backend-framework
+    what: Express app with router modules, error middleware and a hardened helmet baseline.
+    stacks: [node]
+    sources:
+      - https://github.com/expressjs/express
+      - https://github.com/helmetjs/helmet
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs: [api-express, backend-express-hardening, server-node-express, build-tsx-watch]
+
+  - id: api-hono
+    category: backend-api
+    tier: core
+    status: proposed
+    choiceSet: backend-framework
+    what: >-
+      Hono app that runs unchanged on Node, Bun, Deno and Workers - the best pick when the
+      deploy target is not yet decided.
+    stacks: [node, edge, bun, deno]
+    sources:
+      - https://github.com/honojs/hono
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs: [api-hono]
+    note: >-
+      The shipped lint-format blueprint records a conflict with `hono-api`. If that id is this
+      layer under an older name, the conflict must be reconciled before either is used.
+
+  - id: api-nestjs
+    category: backend-api
+    tier: core
+    status: proposed
+    choiceSet: backend-framework
+    what: >-
+      NestJS modular app - module/provider/controller triad, class-validator DTOs, and the
+      brocoders boilerplate's swappable persistence layer.
+    stacks: [node, typescript]
+    sources:
+      - https://github.com/nestjs/nest
+      - https://github.com/brocoders/nestjs-boilerplate
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs: [api-nestjs, validation-class-validator, orm-repository-port-pattern, db-dual-persistence-hexagonal]
+
+  - id: api-go-http
+    category: backend-api
+    tier: core
+    status: proposed
+    choiceSet: backend-framework
+    what: >-
+      Go HTTP service in the clean-architecture layout - entity/usecase/adapter split, explicit
+      wiring, no framework magic. Gin and Fiber variants share the layout.
+    stacks: [go]
+    sources:
+      - https://github.com/evrone/go-clean-template
+      - https://github.com/amitshekhariitbhu/go-backend-clean-architecture
+      - https://github.com/goravel/goravel
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs: [api-go-gin, api-go-fiber, api-go-goravel, db-migrations-golang-migrate, db-migrations-goravel]
+
+  - id: api-dotnet
+    category: backend-api
+    tier: core
+    status: proposed
+    choiceSet: backend-framework
+    what: >-
+      ASP.NET Core Web API or Minimal API in the clean-architecture layout, with
+      FluentValidation and the MediatR request pipeline.
+    stacks: [dotnet]
+    sources:
+      - https://github.com/jasontaylordev/CleanArchitecture
+      - https://github.com/ardalis/CleanArchitecture
+      - https://github.com/dotnet/eShop
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs: [api-dotnet-webapi, api-dotnet-minimal, validation-fluentvalidation, cqrs-mediatr]
+
+  - id: arch-clean-architecture
+    category: backend-api
+    tier: capability
+    status: proposed
+    what: >-
+      The dependency-inversion project layout applied to whichever backend framework was chosen -
+      domain has no outward references, infrastructure depends inward, and an architecture test
+      fails the build when that is violated. The enforcement test is the borrowable part; the
+      folder names are not.
+    stacks: [dotnet, go, node, python]
+    sources:
+      - https://github.com/jasontaylordev/CleanArchitecture
+      - https://github.com/ardalis/CleanArchitecture
+      - https://github.com/evrone/go-clean-template
+      - https://github.com/alan2207/bulletproof-react
+    requires: []
+    conflicts: []
+    absorbs: [arch-clean-architecture, arch-ddd-aggregates, arch-microservices]
+
+  - id: api-openapi
+    category: backend-api
+    tier: capability
+    status: proposed
+    what: >-
+      Generated OpenAPI document, served docs UI, and the CI job that diffs the spec against the
+      previous commit so a breaking change fails review rather than production.
+    stacks: [python, node, go, dotnet]
+    sources:
+      - https://github.com/fastapi/fastapi
+      - https://github.com/honojs/hono
+      - https://github.com/litestar-org/litestar
+      - https://github.com/schemathesis/schemathesis
+    requires: []
+    conflicts: []
+    absorbs: [api-openapi-swagger, ci-api-conformance, testing-contract-openapi-schemathesis]
+
+  - id: api-versioning
+    category: backend-api
+    tier: capability
+    status: built
+    what: >-
+      Version negotiation, deprecation and sunset headers, contract snapshots and a
+      compatibility check.
+    stacks: [any]
+    sources:
+      - https://github.com/fastapi/fastapi
+    requires: []
+    conflicts: []
+    provides:
+      [api-versioning, version-negotiation, version-policy, deprecation-headers, sunset-headers,
+       contract-snapshots, contract-compatibility, api-version-config]
+
+  - id: api-graphql
+    category: backend-api
+    tier: capability
+    status: proposed
+    what: >-
+      Schema-first GraphQL server with generated resolvers and typed client artifacts. Saleor is
+      the reference for a large schema; Keystone for schema-from-model generation.
+    stacks: [node, python]
+    sources:
+      - https://github.com/keystonejs/keystone
+      - https://github.com/saleor/saleor
+      - https://github.com/nestjs/nest
+    requires: []
+    conflicts: [api-trpc]
+    absorbs: [api-graphql, api-graphql-server, api-graphql-schema-first, state-apollo-client]
+
+  - id: api-trpc
+    category: backend-api
+    tier: capability
+    status: proposed
+    what: >-
+      End-to-end typed RPC without codegen, for the case where client and server are the same
+      TypeScript repo. Loses its entire advantage the moment a non-TS consumer appears.
+    stacks: [typescript]
+    sources:
+      - https://github.com/t3-oss/create-t3-app
+      - https://github.com/calcom/cal.diy
+    requires: [monorepo-turborepo]
+    conflicts: [api-graphql]
+    absorbs: [api-trpc, api-server-functions]
+
+  - id: api-grpc
+    category: backend-api
+    tier: specialist
+    status: proposed
+    what: proto definitions, generated stubs, and the buf lint/breaking-change CI gate.
+    stacks: [go, dotnet]
+    sources:
+      - https://github.com/evrone/go-clean-template
+      - https://github.com/dotnet/eShop
+    requires: []
+    conflicts: []
+    absorbs: [api-grpc, service-rpc-request-reply]
+
+  - id: resilience-policies
+    category: backend-api
+    tier: capability
+    status: proposed
+    what: >-
+      Retry with jitter, circuit breaker, timeout and bulkhead as declared policy rather than
+      hand-rolled try/catch. Polly's pipeline builder is the clearest expression of the shape.
+    stacks: [dotnet, node, go, python]
+    sources:
+      - https://github.com/App-vNext/Polly
+    requires: []
+    conflicts: []
+    absorbs: [resilience-polly]
+
+  # ===========================================================================================
+  # TIER: core - frontend
+  # ===========================================================================================
+
+  - id: app-nextjs
+    category: frontend-ui
+    tier: core
+    status: proposed
+    choiceSet: frontend-framework
+    what: >-
+      Next.js App Router application - route groups, server components, server actions, metadata
+      API. next-enterprise and Next-js-Boilerplate are the two most complete opinionated bases.
+    stacks: [node, react, typescript]
+    sources:
+      - https://github.com/Blazity/next-enterprise
+      - https://github.com/ixartz/Next-js-Boilerplate
+      - https://github.com/Skolaczk/next-starter
+      - https://github.com/vercel/next.js
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs: [framework-nextjs-app-router, app-next-app-router, build-nextjs, forms-server-actions]
+
+  - id: app-nextjs-pages
+    category: frontend-ui
+    tier: specialist
+    status: proposed
+    choiceSet: frontend-framework
+    what: Next.js Pages Router, for brownfield repos that cannot migrate yet.
+    stacks: [node, react]
+    sources:
+      - https://github.com/nextacular/nextacular
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs: [framework-nextjs-pages-router]
+
+  - id: app-react-router
+    category: frontend-ui
+    tier: core
+    status: proposed
+    choiceSet: frontend-framework
+    what: React Router v7 framework mode - loaders, actions, and the epic-stack conventions.
+    stacks: [node, react, typescript]
+    sources:
+      - https://github.com/epicweb-dev/epic-stack
+      - https://github.com/remix-run/react-router
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs: [framework-react-router-7, framework-react-router-v7]
+
+  - id: app-tanstack-start
+    category: frontend-ui
+    tier: core
+    status: proposed
+    choiceSet: frontend-framework
+    what: TanStack Start with typed file routing and server functions.
+    stacks: [node, react, typescript]
+    sources:
+      - https://github.com/dotnize/react-tanstarter
+      - https://github.com/CarlosZiegler/fullstack-start-template
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs: [framework-tanstack-start]
+
+  - id: app-vite-spa
+    category: frontend-ui
+    tier: core
+    status: proposed
+    choiceSet: frontend-framework
+    what: >-
+      Vite + React SPA with the bulletproof-react feature-folder layout and import boundaries.
+      The right default when there is no server-rendering requirement.
+    stacks: [node, react, typescript]
+    sources:
+      - https://github.com/alan2207/bulletproof-react
+      - https://github.com/vitejs/vite
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs: [app-vite-spa, build-vite, build-vite-ts]
+
+  - id: ui-shadcn
+    category: frontend-ui
+    tier: core
+    status: proposed
+    what: >-
+      shadcn/ui copy-in component set over Radix primitives and Tailwind, with components.json
+      and the CLI's registry format. The registry format itself is the most valuable artifact
+      here - it is a working model of "distribute source, not a dependency", which is exactly
+      Groundplan's own thesis.
+    stacks: [react, tailwind]
+    sources:
+      - https://github.com/shadcn-ui/ui
+      - https://github.com/radix-ui/primitives
+      - https://github.com/satnaing/shadcn-admin
+    requires: [styling-tailwind]
+    conflicts: [ui-ant-design]
+    absorbs:
+      [ui-shadcn, ui-shadcn-tailwind, ui-radix-primitives, ui-headless-primitives, ui-base-ui,
+       component-registry-cli, icons-lucide]
+
+  - id: ui-ant-design
+    category: frontend-ui
+    tier: specialist
+    status: proposed
+    what: Ant Design component library for dense internal/admin tooling.
+    stacks: [react]
+    sources:
+      - https://github.com/ant-design/ant-design
+    requires: []
+    conflicts: [ui-shadcn]
+    absorbs: [ui-ant-design]
+
+  - id: styling-tailwind
+    category: frontend-ui
+    tier: core
+    status: proposed
+    what: Tailwind config, CSS-variable theme tokens, and the dark-mode strategy.
+    stacks: [react, vue, svelte]
+    sources:
+      - https://github.com/tailwindlabs/tailwindcss
+      - https://github.com/shadcn-ui/ui
+    requires: []
+    conflicts: []
+    absorbs: [styling-tailwind, ui-tailwind, theming-css-variables, theming-dark-mode, design-system-docs]
+
+  - id: state-client
+    category: frontend-ui
+    tier: capability
+    status: proposed
+    what: >-
+      Zustand store slices plus nuqs URL state, with the boundary rule that makes them coexist:
+      anything a user should be able to link to lives in the URL, everything else in the store.
+    stacks: [react]
+    sources:
+      - https://github.com/pmndrs/zustand
+      - https://github.com/47ng/nuqs
+    requires: []
+    conflicts: []
+    absorbs: [state-zustand, url-state-nuqs]
+
+  - id: data-fetching-tanstack-query
+    category: frontend-ui
+    tier: capability
+    status: proposed
+    what: >-
+      TanStack Query client with the query-key factory convention, suspense boundaries, and
+      optimistic-update patterns.
+    stacks: [react]
+    sources:
+      - https://github.com/TanStack/query
+      - https://github.com/alan2207/bulletproof-react
+    requires: []
+    conflicts: []
+    absorbs: [api-layer-tanstack-query, data-provider-rest]
+
+  - id: forms-validation
+    category: frontend-ui
+    tier: capability
+    status: proposed
+    what: >-
+      One Zod schema driving client validation, server validation and inferred TypeScript types.
+      react-hook-form, TanStack Form and Conform are three bindings of the same idea.
+    stacks: [react, typescript]
+    sources:
+      - https://github.com/react-hook-form/react-hook-form
+      - https://github.com/colinhacks/zod
+      - https://github.com/edmundhung/conform
+    requires: []
+    conflicts: []
+    absorbs: [forms-react-hook-form, forms-tanstack-zod, forms-conform-zod, validation-zod, content-schema-zod]
+
+  - id: table-tanstack
+    category: frontend-ui
+    tier: capability
+    status: proposed
+    what: >-
+      Headless TanStack Table with server-side pagination/sort/filter wired to URL state, plus
+      row virtualization for the large-dataset case.
+    stacks: [react]
+    sources:
+      - https://github.com/TanStack/table
+      - https://github.com/TanStack/virtual
+    requires: [data-fetching-tanstack-query]
+    conflicts: []
+    absorbs:
+      [table-tanstack, table-tanstack-server-pagination, table-virtualization,
+       data-table-server-side, ui-data-table-advanced]
+
+  - id: dashboard-shell
+    category: frontend-ui
+    tier: capability
+    status: proposed
+    what: >-
+      Admin shell - collapsible sidebar nav, breadcrumb header, KPI card grid, responsive
+      breakpoints. next-shadcn-dashboard-starter and shadcn-admin are the two cleanest bases.
+    stacks: [react]
+    sources:
+      - https://github.com/Kiranism/next-shadcn-dashboard-starter
+      - https://github.com/satnaing/shadcn-admin
+    requires: [ui-shadcn]
+    conflicts: []
+    absorbs: [dashboard-admin-shell, layout-sidebar-nav, ui-dashboard-shell, ui-kpi-cards, admin-dashboard-react]
+
+  - id: charts
+    category: frontend-ui
+    tier: capability
+    status: proposed
+    what: >-
+      Chart components with a shared token palette so every chart in the app reads as one system.
+      Recharts for the common case, visx when the chart is bespoke.
+    stacks: [react]
+    sources:
+      - https://github.com/recharts/recharts
+      - https://github.com/airbnb/visx
+      - https://github.com/tremorlabs/tremor
+    requires: []
+    conflicts: []
+    absorbs: [charts-recharts, charts-visx, charts-tremor, charts-custom-d3, dashboard-analytics-widgets]
+
+  - id: crud-admin-refine
+    category: frontend-ui
+    tier: specialist
+    status: proposed
+    what: >-
+      Refine's data-provider abstraction and schema-driven CRUD screens, for internal tools where
+      the UI is a thin shell over a REST/GraphQL backend.
+    stacks: [react]
+    sources:
+      - https://github.com/refinedev/refine
+    requires: []
+    conflicts: []
+    absorbs: [crud-admin-refine, crud-schema-driven]
+
+  - id: i18n
+    category: frontend-ui
+    tier: capability
+    status: proposed
+    what: >-
+      Message catalogs, locale routing, RTL handling and the CI check that fails on a missing
+      translation key rather than shipping the key name to users.
+    stacks: [node, react]
+    sources:
+      - https://github.com/amannn/next-intl
+      - https://github.com/i18next/react-i18next
+    requires: []
+    conflicts: []
+    absorbs:
+      [i18n-next-intl, i18n-next-i18next, i18n-multi-locale, i18n-i18next-rtl, i18n-backend,
+       i18n-message-catalog, i18n-content-locales]
+
+  - id: a11y-baseline
+    category: frontend-ui
+    tier: capability
+    status: proposed
+    what: >-
+      WAI-ARIA patterns from Radix, focus management on route change and modal open/close, and
+      an axe-core CI gate. The focus-management piece is what most starters skip.
+    stacks: [react]
+    sources:
+      - https://github.com/radix-ui/primitives
+      - https://github.com/dequelabs/axe-core
+    requires: []
+    conflicts: []
+    absorbs: [a11y-wai-aria, a11y-focus-management, a11y-testing]
+
+  - id: storybook
+    category: frontend-ui
+    tier: capability
+    status: proposed
+    what: Storybook workbench with a11y and interaction-test addons, plus visual regression.
+    stacks: [react, vue, svelte]
+    sources:
+      - https://github.com/storybookjs/storybook
+    requires: []
+    conflicts: []
+    absorbs: [storybook-workbench, tooling-storybook, visual-regression-testing]
+
+  - id: perf-bundle-budget
+    category: frontend-ui
+    tier: capability
+    status: proposed
+    what: CI-enforced bundle-size budget with a per-route breakdown, failing the PR not the deploy.
+    stacks: [node]
+    sources:
+      - https://github.com/Blazity/next-enterprise
+    requires: [ci-github-actions]
+    conflicts: []
+    absorbs: [perf-bundle-budget]
+
+  # ===========================================================================================
+  # TIER: core - database (two orthogonal axes)
+  # ===========================================================================================
+
+  - id: db-core
+    category: database
+    tier: core
+    status: built
+    what: >-
+      The storage-agnostic contract every driver sits behind - repository shape, unit of work,
+      typed errors, config surface, health hook. No driver may stand alone without it.
+    stacks: [any]
+    sources:
+      - https://github.com/brocoders/nestjs-boilerplate
+      - https://github.com/jasontaylordev/CleanArchitecture
+    requires: []
+    conflicts: []
+    provides: [db-abstraction, repository-pattern, unit-of-work, db-config, db-errors]
+    absorbs: [orm-repository-port-pattern]
+
+  - id: db-postgres
+    category: database
+    tier: core
+    status: built
+    choiceSet: db-engine
+    what: Pooled PostgreSQL access, plain-SQL migrations, and a local server, config from env.
+    stacks: [any]
+    sources:
+      - https://github.com/postgres/postgres
+      - https://github.com/supabase/supabase
+    requires: [db-core]
+    conflicts: [db-sqlite, db-mongo]
+    provides: [db, relational-db, sql-migrations, postgres]
+
+  - id: db-sqlite
+    category: database
+    tier: core
+    status: built
+    choiceSet: db-engine
+    what: Embedded SQLite - the right default for CLIs, desktop apps and single-node services.
+    stacks: [any]
+    sources:
+      - https://github.com/drizzle-team/drizzle-orm
+      - https://github.com/epicweb-dev/epic-stack
+    requires: [db-core]
+    conflicts: [db-postgres, db-mongo]
+    provides: [db-engine, sql-database, embedded-database]
+    absorbs: [db-sqlite-embedded]
+
+  - id: db-mongo
+    category: database
+    tier: core
+    status: built
+    choiceSet: db-engine
+    what: MongoDB document store behind the db-core repository contract.
+    stacks: [node, go, dotnet]
+    sources:
+      - https://github.com/brocoders/nestjs-boilerplate
+      - https://github.com/amitshekhariitbhu/go-backend-clean-architecture
+    requires: [db-core]
+    conflicts: [db-postgres, db-sqlite]
+    provides: [database, document-store, mongodb]
+    absorbs: [db-mongo-go, db-mongo-mongoose, db-mongodb-mongoose, db-mongodb-mongoose-nestjs, db-mongodb-prisma]
+
+  - id: db-mysql
+    category: database
+    tier: core
+    status: proposed
+    choiceSet: db-engine
+    what: MySQL/MariaDB engine behind db-core. Needed for brownfield and for the Ghost/WP world.
+    stacks: [any]
+    sources:
+      - https://github.com/TryGhost/Ghost
+      - https://github.com/drizzle-team/drizzle-orm
+    requires: [db-core]
+    conflicts: [db-postgres, db-sqlite, db-mongo]
+    absorbs: [db-mysql-drizzle, db-mysql-prisma, db-mysql-kysely, db-mysql-gorm, db-mysql-sqlc, db-mysql-knex, compose-mysql]
+
+  - id: db-sqlserver
+    category: database
+    tier: core
+    status: proposed
+    choiceSet: db-engine
+    what: SQL Server engine behind db-core, for .NET shops where it is not a choice.
+    stacks: [dotnet]
+    sources:
+      - https://github.com/jasontaylordev/CleanArchitecture
+      - https://github.com/DapperLib/Dapper
+    requires: [db-core]
+    conflicts: [db-postgres, db-sqlite, db-mongo, db-mysql]
+    absorbs: [db-sqlserver-efcore, db-sqlserver-dapper, db-sqlserver-prisma, db-sqlserver-kysely, db-sqlserver-gorm]
+
+  - id: db-turso
+    category: database
+    tier: specialist
+    status: proposed
+    choiceSet: db-engine
+    what: Turso/libSQL - SQLite semantics with an embedded replica and edge reads.
+    stacks: [node, edge]
+    sources:
+      - https://github.com/drizzle-team/drizzle-orm
+    requires: [db-core]
+    conflicts: [db-postgres, db-sqlite, db-mongo, db-mysql]
+    absorbs: [db-turso-drizzle, db-turso-prisma]
+
+  - id: db-d1-cloudflare
+    category: database
+    tier: specialist
+    status: proposed
+    choiceSet: db-engine
+    what: Cloudflare D1 with the Workers binding model and wrangler-driven migrations.
+    stacks: [edge, cloudflare]
+    sources:
+      - https://github.com/drizzle-team/drizzle-orm
+    requires: [db-core, deploy-cloudflare-workers]
+    conflicts: [db-postgres, db-sqlite, db-mongo, db-mysql]
+    absorbs: [db-d1-cloudflare, db-d1-drizzle, deploy-cloudflare-d1]
+
+  - id: db-clickhouse
+    category: database
+    tier: specialist
+    status: proposed
+    what: >-
+      ClickHouse as an analytical sidecar next to the primary OLTP store, not as a replacement
+      for it. Added because both the AI and observability categories reached for it independently.
+    stacks: [any]
+    sources:
+      - https://github.com/ClickHouse/ClickHouse
+    requires: []
+    conflicts: []
+    absorbs: [db-clickhouse]
+
+  # --- db access layer: orthogonal to engine -----------------------------------------------
+
+  - id: db-drizzle
+    category: database
+    tier: core
+    status: proposed
+    choiceSet: db-access
+    what: >-
+      Drizzle schema files, typed query builder and drizzle-kit migration generation. Speaks
+      Postgres, MySQL, SQLite, Turso and D1 - one layer, five engines.
+    stacks: [node, typescript]
+    sources:
+      - https://github.com/drizzle-team/drizzle-orm
+      - https://github.com/ixartz/SaaS-Boilerplate
+      - https://github.com/dotnize/react-tanstarter
+    requires: [db-core]
+    conflicts: []
+    supportsEngines: [db-postgres, db-mysql, db-sqlite, db-turso, db-d1-cloudflare]
+    absorbs:
+      [db-postgres-drizzle, db-mysql-drizzle, db-sqlite-drizzle, db-turso-drizzle,
+       db-d1-drizzle, db-neon-drizzle, db-planetscale-drizzle, db-supabase-drizzle,
+       auth-better-auth-drizzle, db-codegen-types]
+
+  - id: db-prisma
+    category: database
+    tier: core
+    status: proposed
+    choiceSet: db-access
+    what: >-
+      schema.prisma as single source of truth, generated client, and prisma migrate. The
+      prisma-examples repo is a per-engine matrix of working setups.
+    stacks: [node, typescript]
+    sources:
+      - https://github.com/prisma/prisma-examples
+      - https://github.com/t3-oss/create-t3-app
+      - https://github.com/epicweb-dev/epic-stack
+    requires: [db-core]
+    conflicts: []
+    supportsEngines: [db-postgres, db-mysql, db-sqlite, db-sqlserver, db-mongo, db-turso]
+    absorbs:
+      [db-postgres-prisma, db-mysql-prisma, db-sqlite-prisma, db-sqlserver-prisma,
+       db-mongodb-prisma, db-turso-prisma, db-cockroachdb-prisma, auth-better-auth-prisma]
+
+  - id: db-kysely
+    category: database
+    tier: core
+    status: proposed
+    choiceSet: db-access
+    what: >-
+      Typed SQL builder with no runtime schema - the pick when the team wants SQL but not
+      stringly-typed SQL. Dialects cover Postgres, MySQL, SQLite and SQL Server.
+    stacks: [node, typescript]
+    sources:
+      - https://github.com/kysely-org/kysely
+    requires: [db-core]
+    conflicts: []
+    supportsEngines: [db-postgres, db-mysql, db-sqlite, db-sqlserver]
+    absorbs: [db-postgres-kysely, db-mysql-kysely, db-sqlite-kysely, db-sqlserver-kysely]
+
+  - id: db-typeorm
+    category: database
+    tier: specialist
+    status: proposed
+    choiceSet: db-access
+    what: TypeORM entities and repositories, primarily for NestJS repos that already use it.
+    stacks: [node, typescript]
+    sources:
+      - https://github.com/brocoders/nestjs-boilerplate
+      - https://github.com/nestjs/nest
+    requires: [db-core]
+    conflicts: []
+    absorbs: [db-postgres-typeorm, db-postgres-typeorm-nestjs, db-postgres-mikroorm]
+
+  - id: db-sqlalchemy
+    category: database
+    tier: core
+    status: proposed
+    choiceSet: db-access
+    what: >-
+      SQLAlchemy 2.x async ORM with the session-per-request dependency, plus the SQLModel variant
+      where the pydantic model and the table are one class.
+    stacks: [python]
+    sources:
+      - https://github.com/fastapi/full-stack-fastapi-template
+      - https://github.com/rafsaf/minimal-fastapi-postgres-template
+      - https://github.com/litestar-org/litestar
+    requires: [db-core]
+    conflicts: []
+    absorbs:
+      [db-postgres-sqlalchemy, db-postgres-sqlalchemy-async, db-postgres-sqlmodel,
+       db-session-dependency-fastapi]
+
+  - id: db-gorm
+    category: database
+    tier: core
+    status: proposed
+    choiceSet: db-access
+    what: GORM models, hooks and auto-migration for Go, across Postgres/MySQL/SQLite/SQL Server.
+    stacks: [go]
+    sources:
+      - https://github.com/go-gorm/gorm
+      - https://github.com/goravel/goravel
+    requires: [db-core]
+    conflicts: []
+    absorbs: [db-postgres-gorm, db-mysql-gorm, db-sqlite-gorm, db-sqlserver-gorm]
+
+  - id: db-sqlc
+    category: database
+    tier: core
+    status: proposed
+    choiceSet: db-access
+    what: >-
+      Write SQL, generate typed Go. The inverse of an ORM and the better fit when the schema is
+      owned by a DBA rather than the app.
+    stacks: [go]
+    sources:
+      - https://github.com/sqlc-dev/sqlc
+    requires: [db-core]
+    conflicts: []
+    absorbs: [db-postgres-sqlc, db-mysql-sqlc, db-sqlite-sqlc, db-postgres-pgx]
+
+  - id: db-efcore
+    category: database
+    tier: core
+    status: proposed
+    choiceSet: db-access
+    what: >-
+      EF Core DbContext, configurations, and the interceptor pattern that stamps audit columns
+      and dispatches domain events without touching call sites.
+    stacks: [dotnet]
+    sources:
+      - https://github.com/jasontaylordev/CleanArchitecture
+      - https://github.com/dotnet/eShop
+      - https://github.com/ardalis/CleanArchitecture
+    requires: [db-core]
+    conflicts: []
+    absorbs: [db-postgres-efcore, db-sqlite-efcore, db-sqlserver-efcore, orm-efcore-interceptors-audit, auth-openiddict-efcore]
+
+  - id: db-dapper
+    category: database
+    tier: specialist
+    status: proposed
+    choiceSet: db-access
+    what: Dapper micro-ORM for hot paths where EF Core's change tracker is the bottleneck.
+    stacks: [dotnet]
+    sources:
+      - https://github.com/DapperLib/Dapper
+    requires: [db-core]
+    conflicts: []
+    absorbs: [orm-micro-dapper, db-postgres-dapper, db-sqlserver-dapper]
+
+  # --- migrations ---------------------------------------------------------------------------
+
+  - id: migrations-alembic
+    category: database
+    tier: capability
+    status: proposed
+    choiceSet: migrations
+    what: >-
+      Alembic env.py, autogenerate with a type-comparison hook, and the multi-database branch
+      layout. The naming-convention block is what makes autogenerate produce stable diffs.
+    stacks: [python]
+    sources:
+      - https://github.com/sqlalchemy/alembic
+      - https://github.com/fastapi/full-stack-fastapi-template
+    requires: [db-sqlalchemy]
+    conflicts: []
+    absorbs: [migrations-alembic-python, migrations-alembic-multidb, db-migrations-alembic]
+
+  - id: migrations-atlas
+    category: database
+    tier: capability
+    status: proposed
+    choiceSet: migrations
+    what: >-
+      Atlas declarative or versioned migrations plus `atlas migrate lint` in CI, which catches
+      destructive changes before merge rather than at deploy.
+    stacks: [go, any]
+    sources:
+      - https://github.com/ariga/atlas
+    requires: []
+    conflicts: []
+    absorbs: [migrations-atlas-declarative, migrations-atlas-versioned, migrations-atlas-ci-lint, db-migrations-golang-migrate]
+
+  - id: migrations-efcore
+    category: database
+    tier: capability
+    status: proposed
+    choiceSet: migrations
+    what: EF Core migrations with an idempotent-script CI artifact rather than migrate-on-startup.
+    stacks: [dotnet]
+    sources:
+      - https://github.com/jasontaylordev/CleanArchitecture
+    requires: [db-efcore]
+    conflicts: []
+    absorbs: [db-migrations-efcore]
+
+  - id: db-rls-multitenant
+    category: database
+    tier: capability
+    status: proposed
+    what: >-
+      Postgres row-level-security policies keyed on a session-local tenant claim, plus the test
+      that proves a cross-tenant read actually fails. Without that test RLS is decoration.
+    stacks: [postgres]
+    sources:
+      - https://github.com/supabase/supabase
+      - https://github.com/supabase/auth
+    requires: [db-postgres]
+    conflicts: []
+    absorbs: [db-postgres-rls-multitenant, db-postgres-rls-auth, security-rls-policies, authz-field-level-access]
+
+  - id: cache-redis
+    category: database
+    tier: capability
+    status: built
+    what: Distributed cache, session store and rate-limit store on Redis.
+    stacks: [any]
+    sources:
+      - https://github.com/redis/ioredis
+    requires: []
+    conflicts: []
+    provides: [cache, distributed-cache, redis, cache-config, session-store, rate-limit-store]
+    absorbs: [cache-redis-ioredis, session-store-redis]
+
+  # ===========================================================================================
+  # TIER: core - auth / authz
+  # ===========================================================================================
+
+  - id: auth-jwt
+    category: auth
+    tier: core
+    status: built
+    choiceSet: auth-strategy
+    what: Self-issued JWT auth with password hashing and a refresh-rotation flow.
+    stacks: [any]
+    sources:
+      - https://github.com/brocoders/nestjs-boilerplate
+      - https://github.com/lucia-auth/lucia
+    requires: []
+    conflicts: [auth-oidc]
+    provides: [auth, jwt-issuer, password-hashing]
+    absorbs: [auth-jwt-refresh, auth-jwt-refresh-rotation, auth-password-argon2, auth-jwks-rotation]
+
+  - id: auth-oidc
+    category: auth
+    tier: core
+    status: built
+    choiceSet: auth-strategy
+    what: OIDC/OAuth2 relying-party integration against an external identity provider.
+    stacks: [any]
+    sources:
+      - https://github.com/panva/node-oidc-provider
+      - https://github.com/keycloak/keycloak
+    requires: []
+    conflicts: [auth-jwt]
+    provides: [auth, oidc, oauth2]
+    absorbs:
+      [auth-oidc-client-keycloak, auth-client-credentials-api, auth-oauth-provider-configs,
+       auth-entra-id, auth-social-google, auth-social-apple]
+
+  - id: auth-better-auth
+    category: auth
+    tier: core
+    status: proposed
+    choiceSet: auth-strategy
+    what: >-
+      Better Auth as the TypeScript auth core, with its plugin set covering 2FA, passkeys,
+      magic links, organizations, admin and an OIDC provider mode. One config object rather
+      than seven integrations - the plugin architecture is the borrowable part.
+    stacks: [node, typescript]
+    sources:
+      - https://github.com/better-auth/better-auth
+      - https://github.com/CarlosZiegler/fullstack-start-template
+      - https://github.com/dotnize/react-tanstarter
+    requires: [db-core]
+    conflicts: [auth-jwt, auth-oidc, auth-nextauth]
+    absorbs:
+      [auth-better-auth, auth-better-auth-2fa, auth-better-auth-passkeys,
+       auth-better-auth-magic-link, auth-better-auth-organization, auth-better-auth-admin,
+       auth-better-auth-oidc-provider, auth-better-auth-drizzle, auth-better-auth-prisma,
+       auth-2fa-totp, auth-2fa-totp-webauthn, auth-passkeys, auth-passkeys-webauthn,
+       auth-magic-link-email, auth-oauth-arctic, auth-session-cookie, auth-session-cookie-scratch,
+       auth-schema-authjs-compatible]
+
+  - id: auth-nextauth
+    category: auth
+    tier: core
+    status: proposed
+    choiceSet: auth-strategy
+    what: Auth.js / NextAuth with a database adapter and provider config, across Next and SvelteKit.
+    stacks: [node, react, svelte]
+    sources:
+      - https://github.com/nextauthjs/next-auth
+      - https://github.com/t3-oss/create-t3-app
+      - https://github.com/Skolaczk/next-starter
+    requires: [db-core]
+    conflicts: [auth-better-auth]
+    absorbs: [auth-nextauth, auth-authjs-nextjs, auth-authjs-sveltekit, auth-authjs-express]
+
+  - id: auth-clerk
+    category: auth
+    tier: core
+    status: proposed
+    choiceSet: auth-strategy
+    what: >-
+      Clerk hosted auth - middleware, gated routes, organization support. Fastest path to
+      working auth; also the layer with the hardest exit, so pair it with auth-provider-port.
+    stacks: [node, react, react-native]
+    sources:
+      - https://github.com/ixartz/SaaS-Boilerplate
+      - https://github.com/Kiranism/next-shadcn-dashboard-starter
+      - https://github.com/flemingvincent/expo-clerk-convex
+    requires: []
+    conflicts: [auth-better-auth, auth-nextauth, auth-jwt]
+    absorbs: [auth-clerk]
+
+  - id: auth-supabase
+    category: auth
+    tier: core
+    status: proposed
+    choiceSet: auth-strategy
+    what: >-
+      Supabase GoTrue auth with JWT claims that RLS policies read directly - the auth and authz
+      layers become one thing, which is its main appeal and its main lock-in.
+    stacks: [node, postgres]
+    sources:
+      - https://github.com/supabase/auth
+      - https://github.com/supabase/supabase
+    requires: [db-postgres]
+    conflicts: [auth-better-auth, auth-nextauth, auth-clerk]
+    absorbs: [auth-supabase, auth-gotrue-postgres, auth-jwt-claims-supabase, auth-supabase-selfhost, db-postgres-supabase, db-supabase-postgres, db-supabase-selfhost-docker]
+
+  - id: auth-aspnet-identity
+    category: auth
+    tier: core
+    status: proposed
+    choiceSet: auth-strategy
+    what: ASP.NET Core Identity with either JWT bearer or an OpenIddict-backed authorization server.
+    stacks: [dotnet]
+    sources:
+      - https://github.com/openiddict/openiddict-core
+      - https://github.com/jasontaylordev/CleanArchitecture
+    requires: []
+    conflicts: [auth-better-auth, auth-nextauth, auth-clerk]
+    absorbs:
+      [auth-aspnet-identity, auth-aspnet-identity-jwt, auth-aspnet-identity-openiddict,
+       auth-openiddict, auth-openiddict-server, auth-openiddict-client,
+       auth-openiddict-validation, auth-dotnet-starter-kit]
+
+  - id: auth-idp-keycloak
+    category: auth
+    tier: capability
+    status: proposed
+    what: >-
+      Keycloak as a self-hosted IdP - compose service plus a version-controlled realm-import
+      JSON, so the IdP config is a reviewable artifact rather than clicks in an admin console.
+    stacks: [any]
+    sources:
+      - https://github.com/keycloak/keycloak
+    requires: [auth-oidc, docker-compose]
+    conflicts: []
+    absorbs: [auth-keycloak, auth-keycloak-compose, auth-keycloak-realm-import, auth-idp-config-as-code]
+
+  - id: auth-idp-ory
+    category: auth
+    tier: specialist
+    status: proposed
+    what: >-
+      Ory Kratos (identities, self-service flows) plus Hydra (OAuth2 server) as separate
+      services, with the identity schema as JSON Schema and flows as declarative config.
+    stacks: [any]
+    sources:
+      - https://github.com/ory/kratos
+      - https://github.com/ory/hydra
+    requires: [docker-compose]
+    conflicts: []
+    absorbs:
+      [auth-ory-kratos, auth-ory-kratos-compose, auth-ory-hydra, auth-identity-schema-json,
+       auth-selfservice-flows, auth-login-consent-app, auth-oauth2-server,
+       auth-oidc-provider-node, auth-oidc-provider-express, auth-oidc-provider-koa]
+
+  - id: auth-idp-authentik
+    category: auth
+    tier: specialist
+    status: proposed
+    what: >-
+      Authentik as a self-hosted IdP, deployed as containers and configured entirely through
+      version-controlled blueprint YAML - flows, stages, prompts, policies and providers as
+      declarative files with a published JSON Schema. The blueprint model is the idea worth
+      having; it is what turns IdP configuration into a reviewable artifact.
+    stacks: [any]
+    sources: []
+    requires: [auth-oidc, docker-compose]
+    conflicts: []
+    absorbs: [auth-authentik-deploy, auth-flow-stage-policy-model]
+    fromScratch: true
+    licenseNote: >-
+      goauthentik/authentik reports NOASSERTION and is split-licensed, with features drifting
+      into `authentik/enterprise/` over time - a path that is MIT today may not be next release.
+      REFERENCE-ONLY. Deploy it as a container and author the blueprints yourself; copy no files.
+      Its operational floor is also high (server + worker + Postgres + Redis). Prefer
+      auth-idp-keycloak unless the blueprint model is specifically wanted. See gaps.md.
+
+  - id: backend-baas
+    category: auth
+    tier: specialist
+    status: proposed
+    what: >-
+      A hosted backend-as-a-service - Convex or Firebase - owning database, auth and realtime
+      together. Fastest path to a working mobile or prototype app; the deepest lock-in in the
+      catalog, since the data model, the auth model and the query language all come from the
+      vendor at once.
+    stacks: [node, react-native, flutter]
+    sources:
+      - https://github.com/flemingvincent/expo-clerk-convex
+      - https://github.com/bizz84/starter_architecture_flutter_firebase
+    requires: []
+    conflicts: [db-core]
+    absorbs: [backend-convex, auth-firebase, db-firestore]
+    note: >-
+      Conflicts with db-core deliberately: a BaaS replaces the repository contract rather than
+      implementing it. Pair with auth-provider-port so at least the auth surface stays portable.
+
+  - id: auth-forward-proxy
+    category: auth
+    tier: specialist
+    status: proposed
+    what: >-
+      Forward-auth sidecar (Authelia / oauth2-proxy) putting SSO in front of an app that has no
+      auth of its own, via nginx auth_request or Traefik middleware.
+    stacks: [any]
+    sources:
+      - https://github.com/authelia/authelia
+      - https://github.com/oauth2-proxy/oauth2-proxy
+    requires: [docker-compose]
+    conflicts: []
+    absorbs:
+      [auth-authelia-portal, auth-forward-auth-nginx, auth-forward-auth-traefik,
+       auth-proxy-oauth2-proxy, auth-sso-sidecar]
+
+  - id: auth-saml-enterprise
+    category: auth
+    tier: specialist
+    status: proposed
+    what: SAML SSO and directory federation for the enterprise-sales checkbox.
+    stacks: [any]
+    sources:
+      - https://github.com/boxyhq/saas-starter-kit
+    requires: [auth-oidc]
+    conflicts: []
+    absorbs: [auth-saml-sso, auth-saml-idp, auth-ldap-federation]
+
+  - id: auth-provider-port
+    category: auth
+    tier: capability
+    status: proposed
+    what: >-
+      A thin interface over whichever auth choice was made - `getSession`, `requireUser`,
+      `signOut` - so application code never imports Clerk or Supabase directly and the auth
+      choice stays reversible. The single highest-leverage layer in this category.
+    stacks: [any]
+    sources:
+      - https://github.com/alan2207/bulletproof-react
+      - https://github.com/brocoders/nestjs-boilerplate
+    requires: []
+    conflicts: []
+    absorbs: [auth-provider-abstraction]
+
+  - id: authz-rbac
+    category: auth
+    tier: core
+    status: proposed
+    choiceSet: authz-model
+    what: >-
+      Role/permission matrix with a single `can(user, action, resource)` entry point, permission
+      claims in the token, and a seeded default role set.
+    stacks: [any]
+    sources:
+      - https://github.com/casbin/casbin
+      - https://github.com/keystonejs/keystone
+    requires: []
+    conflicts: [authz-rebac]
+    absorbs:
+      [authz-rbac-matrix, rbac-permissions, rbac-access-control, authz-permission-groups,
+       authz-permission-claims-dotnet, authz-access-control-rules, authz-casbin-rbac,
+       authz-casbin-rbac-domains, authz-casbin-abac, authz-policy-model-files]
+
+  - id: authz-rebac
+    category: auth
+    tier: specialist
+    status: proposed
+    choiceSet: authz-model
+    what: >-
+      Zanzibar-style relationship-based authorization on OpenFGA, with the model as a versioned
+      DSL file and model assertions run as tests in CI.
+    stacks: [any]
+    sources:
+      - https://github.com/openfga/openfga
+    requires: [docker-compose]
+    conflicts: [authz-rbac]
+    absorbs: [authz-openfga, authz-openfga-compose, authz-openfga-model-tests, authz-rebac-zanzibar]
+
+  - id: authz-gateway-policy
+    category: auth
+    tier: specialist
+    status: proposed
+    what: Ory Oathkeeper access rules enforcing authz at the gateway rather than in each service.
+    stacks: [any]
+    sources:
+      - https://github.com/ory/oathkeeper
+    requires: []
+    conflicts: []
+    absorbs: [authz-ory-oathkeeper]
+
+  - id: tenancy-organizations
+    category: auth
+    tier: capability
+    status: proposed
+    what: >-
+      Organization/workspace model - membership, invites, role-per-org, org switcher, and
+      subdomain or path-based tenant resolution.
+    stacks: [any]
+    sources:
+      - https://github.com/ixartz/SaaS-Boilerplate
+      - https://github.com/boxyhq/saas-starter-kit
+      - https://github.com/nextacular/nextacular
+    requires: [auth-provider-port]
+    conflicts: []
+    absorbs: [tenancy-organizations, tenancy-subdomain-multitenant, tenancy-finbuckle-multitenant]
+
+  # ===========================================================================================
+  # TIER: capability - testing
+  # ===========================================================================================
+
+  - id: testing-unit
+    category: testing
+    tier: foundation
+    status: built
+    what: Unit test runner, test doubles and a coverage report.
+    stacks: [any]
+    sources:
+      - https://github.com/vitest-dev/vitest
+      - https://github.com/pytest-dev/pytest
+    requires: []
+    conflicts: []
+    provides: [unit-tests, test-runner, test-doubles, coverage-report]
+
+  - id: testing-vitest
+    category: testing
+    tier: core
+    status: proposed
+    choiceSet: test-runner-unit
+    what: >-
+      Vitest config with the projects/workspace split, v8 coverage thresholds, in-source tests
+      and typecheck assertions (`expectTypeOf`), which no other JS runner does natively.
+    stacks: [node, typescript]
+    sources:
+      - https://github.com/vitest-dev/vitest
+    requires: [testing-unit]
+    conflicts: []
+    absorbs:
+      [testing-unit-vitest, testing-vitest, test-vitest, testing-vitest-projects,
+       testing-in-source, testing-typecheck-assertions, testing-coverage-v8]
+
+  - id: testing-jest
+    category: testing
+    tier: core
+    status: proposed
+    choiceSet: test-runner-unit
+    what: Jest config, custom environments and snapshot conventions, for repos already on it.
+    stacks: [node]
+    sources:
+      - https://github.com/jestjs/jest
+    requires: [testing-unit]
+    conflicts: []
+    absorbs: [testing-unit-jest, testing-custom-environment, testing-snapshot, test-jest-e2e, test-jest-rn]
+
+  - id: testing-pytest
+    category: testing
+    tier: core
+    status: proposed
+    choiceSet: test-runner-unit
+    what: >-
+      pytest layout, conftest fixture scoping, parametrize conventions, coverage.py thresholds
+      and a tox/nox version matrix.
+    stacks: [python]
+    sources:
+      - https://github.com/pytest-dev/pytest
+      - https://github.com/nedbat/coveragepy
+    requires: [testing-unit]
+    conflicts: []
+    absorbs:
+      [testing-unit-pytest, test-pytest, testing-pytest-fixtures, testing-pytest-plugin,
+       testing-python-layout, testing-coverage-python, testing-matrix-tox]
+
+  - id: testing-xunit
+    category: testing
+    tier: core
+    status: proposed
+    choiceSet: test-runner-unit
+    what: >-
+      xUnit conventions, collection fixtures for parallelism control, and WebApplicationFactory
+      integration tests against the real pipeline.
+    stacks: [dotnet]
+    sources:
+      - https://github.com/xunit/xunit
+    requires: [testing-unit]
+    conflicts: []
+    absorbs:
+      [testing-unit-xunit, test-xunit-integration, testing-dotnet-conventions,
+       testing-fixtures-dotnet, testing-parallel-collections, testing-webapplicationfactory,
+       testing-integration-dotnet]
+
+  - id: testing-go
+    category: testing
+    tier: core
+    status: proposed
+    choiceSet: test-runner-unit
+    what: Go table-driven tests with testify assertions and a build-tagged integration suite.
+    stacks: [go]
+    sources:
+      - https://github.com/stretchr/testify
+    requires: [testing-unit]
+    conflicts: []
+    absorbs: [test-testify, test-integration-go]
+
+  - id: testing-e2e
+    category: testing
+    tier: foundation
+    status: built
+    what: End-to-end and smoke test harness with its config.
+    stacks: [any]
+    sources:
+      - https://github.com/microsoft/playwright
+    requires: []
+    conflicts: []
+    provides: [e2e-tests, smoke-tests, e2e-config]
+
+  - id: testing-playwright
+    category: testing
+    tier: core
+    status: proposed
+    choiceSet: test-runner-e2e
+    what: >-
+      Playwright with the custom-fixture pattern, the webServer dev-server adapter, trace/video
+      artifacts on failure only, and the official Docker image pinned to the library version.
+    stacks: [any]
+    sources:
+      - https://github.com/microsoft/playwright
+    requires: [testing-e2e]
+    conflicts: [testing-cypress]
+    absorbs:
+      [testing-e2e-playwright, e2e-playwright, testing-playwright, testing-e2e-fixtures,
+       testing-dev-server-adapter, testing-trace-artifacts, testing-browser-docker-image]
+
+  - id: testing-cypress
+    category: testing
+    tier: specialist
+    status: proposed
+    choiceSet: test-runner-e2e
+    what: Cypress e2e plus component testing, for teams already invested in it.
+    stacks: [node]
+    sources:
+      - https://github.com/cypress-io/cypress
+    requires: [testing-e2e]
+    conflicts: [testing-playwright]
+    absorbs: [testing-e2e-cypress, testing-component-cypress]
+
+  - id: testing-maestro-mobile
+    category: testing
+    tier: capability
+    status: proposed
+    choiceSet: test-runner-e2e
+    what: Maestro YAML flows for mobile e2e, which survive re-renders that break selector-based tools.
+    stacks: [react-native, flutter]
+    sources:
+      - https://github.com/mobile-dev-inc/maestro
+    requires: [testing-e2e]
+    conflicts: []
+    absorbs: [e2e-maestro]
+
+  - id: testing-http-mocking
+    category: testing
+    tier: capability
+    status: proposed
+    what: >-
+      MSW handlers shared between the Node test setup and the browser worker, so one set of
+      mocks serves unit tests, Storybook and local development.
+    stacks: [node, typescript]
+    sources:
+      - https://github.com/mswjs/msw
+    requires: []
+    conflicts: []
+    absorbs: [testing-msw, testing-http-mock-msw, testing-msw-node-setup, testing-msw-browser-worker, testing-fixtures-handlers]
+
+  - id: testing-testcontainers
+    category: testing
+    tier: capability
+    status: proposed
+    what: >-
+      Real Postgres/Redis/Kafka in tests via Testcontainers, with a per-suite reset strategy
+      (Respawn or truncate) rather than a per-test container, which is the usual perf mistake.
+    stacks: [node, dotnet, python, go]
+    sources:
+      - https://github.com/testcontainers/testcontainers-node
+      - https://github.com/testcontainers/testcontainers-dotnet
+    requires: [docker]
+    conflicts: []
+    absorbs:
+      [testing-integration-testcontainers-node, testing-integration-testcontainers-dotnet,
+       testing-db-ephemeral, testing-db-reset-respawn, testing-integration-setup-teardown,
+       testing-db-migrations-flyway]
+
+  - id: testing-contract
+    category: testing
+    tier: capability
+    status: proposed
+    what: >-
+      Consumer-driven contracts - Pact consumer tests, broker publish from CI, and provider
+      verification as a required check on the provider's PRs. Also covers message contracts.
+    stacks: [node, dotnet, python, go]
+    sources:
+      - https://github.com/pact-foundation/pact-js
+      - https://github.com/schemathesis/schemathesis
+    requires: [ci-github-actions]
+    conflicts: []
+    absorbs:
+      [testing-contract-pact, testing-contract-consumer, testing-contract-provider-verification,
+       testing-contract-messaging, ci-contract-broker-publish, test-contract-conformance]
+
+  - id: testing-property
+    category: testing
+    tier: capability
+    status: proposed
+    what: >-
+      Property-based tests with fast-check or Hypothesis, plus the seeded-replay convention that
+      turns a flaky counterexample into a permanent regression test.
+    stacks: [node, python]
+    sources:
+      - https://github.com/dubzzz/fast-check
+      - https://github.com/HypothesisWorks/hypothesis
+    requires: [testing-unit]
+    conflicts: []
+    absorbs: [testing-property-fast-check, testing-property-python, testing-seeded-replay, testing-model-based, testing-fuzz-inputs, testing-api-fuzz]
+
+  - id: testing-mutation
+    category: testing
+    tier: specialist
+    status: proposed
+    what: >-
+      Stryker mutation testing with an incremental-analysis cache and a CI gate on the mutation
+      score, which measures whether the tests assert anything rather than whether they ran.
+    stacks: [node, dotnet]
+    sources:
+      - https://github.com/stryker-mutator/stryker-js
+    requires: [testing-unit, ci-github-actions]
+    conflicts: []
+    absorbs: [testing-mutation-stryker, testing-mutation-ci-gate]
+
+  - id: testing-coverage-gate
+    category: testing
+    tier: capability
+    status: proposed
+    what: Coverage thresholds enforced in CI with a per-directory floor, not one global number.
+    stacks: [any]
+    sources:
+      - https://github.com/nedbat/coveragepy
+      - https://github.com/vitest-dev/vitest
+    requires: [testing-unit, ci-github-actions]
+    conflicts: []
+    absorbs: [testing-coverage-gate, test-coverage-enforced, ci-coverage-report]
+
+  - id: testing-load
+    category: testing
+    tier: specialist
+    status: proposed
+    what: >-
+      k6 or Locust load scripts with thresholds as pass/fail, run as a smoke-sized job on every
+      PR and a full run on a schedule.
+    stacks: [any]
+    sources:
+      - https://github.com/locustio/locust
+      - https://github.com/grafana/k6
+    requires: []
+    conflicts: []
+    absorbs: [testing-load-locust, testing-load-distributed, testing-load-docker, ci-load-smoke]
+
+  - id: evals
+    category: ai-llm
+    tier: capability
+    status: built
+    what: >-
+      LLM eval harness - golden dataset, runner, budget caps, tracing and a CI gate on the
+      eval score.
+    stacks: [python, node]
+    sources:
+      - https://github.com/promptfoo/promptfoo
+      - https://github.com/pydantic/pydantic-ai
+    requires: []
+    conflicts: []
+    provides:
+      [llm-evals, eval-harness, golden-dataset, eval-runner, eval-budget-caps, eval-tracing, eval-gate]
+    absorbs:
+      [evals-promptfoo, evals-pydantic-evals, evals-deepeval, evals-pytest, evals-rag-metrics,
+       ci-evals-github-actions, redteam-promptfoo]
+
+  # ===========================================================================================
+  # TIER: capability - observability
+  # ===========================================================================================
+
+  - id: observability-otel
+    category: observability
+    tier: capability
+    status: built
+    what: >-
+      OpenTelemetry tracing, metrics and structured logging behind one OTLP exporter, so the
+      backend is a config change rather than a code change.
+    stacks: [any]
+    sources:
+      - https://github.com/open-telemetry/opentelemetry-collector-contrib
+      - https://github.com/open-telemetry/opentelemetry-demo
+    requires: []
+    conflicts: [dotnet-aspire]
+    provides:
+      [observability, opentelemetry, tracing, metrics, structured-logging, otlp-exporter]
+    absorbs:
+      [observability-opentelemetry, obs-opentelemetry, otel-exporter-otlp, obs-dashboard-otlp,
+       otel-instrumentation-polyglot]
+
+  - id: otel-instrumentation-node
+    category: observability
+    tier: capability
+    status: proposed
+    what: >-
+      Node SDK bootstrap loaded before app code, auto-instrumentations for http/express/pg, and
+      the resource attributes that make service.name/version/env show up correctly.
+    stacks: [node]
+    sources:
+      - https://github.com/open-telemetry/opentelemetry-js
+      - https://github.com/open-telemetry/opentelemetry-js-contrib
+    requires: [observability-otel]
+    conflicts: []
+    absorbs: [otel-instrumentation-node, obs-http-server-instrumentation]
+
+  - id: otel-instrumentation-python
+    category: observability
+    tier: capability
+    status: proposed
+    what: Python SDK plus the zero-code `opentelemetry-instrument` agent path and its trade-offs.
+    stacks: [python]
+    sources:
+      - https://github.com/open-telemetry/opentelemetry-python
+      - https://github.com/open-telemetry/opentelemetry-python-contrib
+    requires: [observability-otel]
+    conflicts: []
+    absorbs: [otel-instrumentation-python, otel-agent-python, obs-tracing-python]
+
+  - id: otel-instrumentation-go
+    category: observability
+    tier: capability
+    status: proposed
+    what: Go SDK with otelhttp/otelgrpc handlers - explicit wiring, no agent.
+    stacks: [go]
+    sources:
+      - https://github.com/open-telemetry/opentelemetry-go
+      - https://github.com/open-telemetry/opentelemetry-go-contrib
+    requires: [observability-otel]
+    conflicts: []
+    absorbs: [otel-instrumentation-go]
+
+  - id: otel-instrumentation-dotnet
+    category: observability
+    tier: capability
+    status: proposed
+    what: .NET OTel with ActivitySource, Meter, and the contrib instrumentation packages.
+    stacks: [dotnet]
+    sources:
+      - https://github.com/open-telemetry/opentelemetry-dotnet
+      - https://github.com/open-telemetry/opentelemetry-dotnet-contrib
+    requires: [observability-otel]
+    conflicts: []
+    absorbs: [otel-instrumentation-dotnet, obs-dotnet-servicedefaults]
+
+  - id: otel-instrumentation-jvm
+    category: observability
+    tier: capability
+    status: proposed
+    what: JVM javaagent attach plus Micrometer bridge for existing metrics.
+    stacks: [jvm]
+    sources:
+      - https://github.com/open-telemetry/opentelemetry-java-instrumentation
+    requires: [observability-otel]
+    conflicts: []
+    absorbs: [otel-instrumentation-java, otel-agent-jvm, obs-tracing-jvm, obs-metrics-jvm, obs-metrics-jvm-micrometer]
+
+  - id: otel-collector
+    category: observability
+    tier: capability
+    status: proposed
+    what: >-
+      Collector config - receivers/processors/exporters, batch and memory_limiter, attribute
+      redaction, and tail sampling. The processor pipeline is where PII scrubbing belongs, once,
+      rather than in every service.
+    stacks: [any]
+    sources:
+      - https://github.com/open-telemetry/opentelemetry-collector-contrib
+      - https://github.com/open-telemetry/opentelemetry-collector-releases
+      - https://github.com/grafana/alloy
+    requires: [observability-otel]
+    conflicts: []
+    absorbs:
+      [otel-collector-config, otel-collector-alloy, otel-collector-custom-distro,
+       obs-pipeline-processors, obs-tail-sampling, observability-pii-scrubbing,
+       obs-host-container-metrics]
+
+  - id: logging-structured
+    category: observability
+    tier: capability
+    status: proposed
+    what: >-
+      JSON logs with a per-language library (pino / structlog / zap / zerolog / Serilog), context
+      variables carried across async boundaries, trace_id and span_id injected on every line, and
+      a redaction list. The trace-correlation piece is what makes logs worth having next to traces.
+    stacks: [node, python, go, dotnet]
+    sources:
+      - https://github.com/pinojs/pino
+      - https://github.com/hynek/structlog
+      - https://github.com/uber-go/zap
+      - https://github.com/rs/zerolog
+      - https://github.com/serilog/serilog
+    requires: []
+    conflicts: []
+    absorbs:
+      [obs-structured-logging, logging-structured-node-pino, logging-structured-python-structlog,
+       logging-structured-go-zap, logging-structured-go-zerolog, logging-structured-dotnet-serilog,
+       logging-json-renderer, logging-context-vars, logging-enrichers, logging-redaction,
+       logging-sampling, logging-http-middleware, logging-testable,
+       logging-trace-correlation-node, logging-trace-correlation-python,
+       logging-trace-correlation-go, logging-trace-correlation-dotnet]
+
+  - id: metrics-prometheus
+    category: observability
+    tier: capability
+    status: proposed
+    what: >-
+      Prometheus client registry, a /metrics endpoint, the four RED/USE series worth having by
+      default, and recording rules so dashboards query pre-aggregated series.
+    stacks: [go, node, python, dotnet]
+    sources:
+      - https://github.com/prometheus/client_golang
+      - https://github.com/prometheus/prometheus
+    requires: []
+    conflicts: []
+    absorbs: [obs-metrics-prometheus, obs-metrics-go-client, obs-recording-rules]
+
+  - id: health-checks
+    category: observability
+    tier: foundation
+    status: built
+    what: Liveness, readiness and startup probes with dependency checks and a health endpoint.
+    stacks: [any]
+    sources:
+      - https://github.com/nestjs/terminus
+      - https://github.com/dotnet/aspnetcore
+    requires: []
+    conflicts: []
+    provides:
+      [health, liveness-probe, readiness-probe, startup-probe, dependency-probes,
+       health-endpoint, health-config]
+    absorbs:
+      [obs-health-checks, health-checks-dotnet, health-checks-nestjs, health-checks-ui,
+       health-readiness-go, obs-readiness-liveness-probes, obs-dependency-probes,
+       obs-graceful-shutdown]
+
+  - id: obs-stack-local
+    category: observability
+    tier: capability
+    status: proposed
+    choiceSet: obs-backend
+    what: >-
+      A one-command local observability backend so traces have somewhere to go in development.
+      docker-otel-lgtm is a single Apache-2.0 container; SigNoz and Jaeger are the alternatives.
+    stacks: [any]
+    sources:
+      - https://github.com/grafana/docker-otel-lgtm
+      - https://github.com/jaegertracing/jaeger
+      - https://github.com/SigNoz/signoz
+    requires: [docker-compose, observability-otel]
+    conflicts: []
+    absorbs:
+      [obs-local-dev-backend, obs-stack-compose, obs-stack-lgtm-single-container,
+       obs-stack-signoz, obs-trace-jaeger, obs-stack-prometheus-compose, obs-service-map]
+    licenseNote: >-
+      grafana/docker-otel-lgtm is Apache-2.0 and may be vendored, but the image it builds BUNDLES
+      Loki and Grafana binaries, both AGPL-3.0. Running that image is fine. Copying Loki or
+      Grafana source, plugin code or bundled dashboard JSON out of it is not. Any Grafana
+      provisioning YAML shipped by a Groundplan layer must be authored by us.
+
+  - id: obs-stack-kubernetes
+    category: observability
+    tier: specialist
+    status: proposed
+    choiceSet: obs-backend
+    what: kube-prometheus jsonnet stack - operator, exporters, default rules and alerts.
+    stacks: [kubernetes]
+    sources:
+      - https://github.com/prometheus-operator/kube-prometheus
+    requires: [k8s-manifests]
+    conflicts: []
+    absorbs: [obs-stack-kubernetes, observability-kube-prometheus]
+
+  - id: obs-slo
+    category: observability
+    tier: capability
+    status: proposed
+    what: >-
+      SLO definitions in the OpenSLO format, compiled by Sloth or Pyrra into Prometheus recording
+      and multi-window burn-rate alert rules. Alert on burn rate, never on raw error count -
+      that is the whole point and the thing most teams get wrong.
+    stacks: [any]
+    sources:
+      - https://github.com/OpenSLO/OpenSLO
+      - https://github.com/slok/sloth
+      - https://github.com/pyrra-dev/pyrra
+    requires: [metrics-prometheus]
+    conflicts: []
+    absorbs:
+      [obs-slo-definitions, obs-slo-tracking, slo-definitions-openslo, slo-prometheus-sloth,
+       slo-prometheus-rules, slo-multi-backend-generator, slo-error-budget,
+       obs-alerting-burnrate, obs-alerting-rules, obs-alertmanager-rules,
+       observability-alerting-rules]
+
+  - id: obs-error-tracking
+    category: observability
+    tier: capability
+    status: proposed
+    what: >-
+      Sentry SDK wiring per runtime, source-map upload in CI, release tracking tied to the
+      deploy, and a PII scrubbing config that is on by default rather than opt-in.
+    stacks: [node, python, react, react-native]
+    sources:
+      - https://github.com/getsentry/sentry-javascript
+      - https://github.com/getsentry/sentry-python
+    requires: []
+    conflicts: []
+    absorbs:
+      [observability-sentry, observability-sentry-nextjs, observability-sentry-node,
+       observability-sentry-python, observability-sentry-react, obs-sourcemaps-upload,
+       obs-release-tracking]
+    licenseNote: >-
+      The Sentry SDKs (getsentry/sentry-javascript, -python) are MIT and vendorable. The Sentry
+      SERVER (getsentry/sentry) is FSL-1.1-Apache-2.0, source-available, and EXCLUDED. Do not
+      conflate them.
+
+  - id: obs-dashboards
+    category: observability
+    tier: capability
+    status: proposed
+    what: >-
+      Dashboard JSON checked into the repo and provisioned as code, covering the RED signals for
+      each service plus one unified overview.
+    stacks: [any]
+    sources: []
+    requires: [obs-stack-local]
+    conflicts: []
+    absorbs: [obs-grafana-provisioning, obs-dashboard-unified, observability-grafana-dashboards]
+    fromScratch: true
+    licenseNote: >-
+      Grafana is AGPL-3.0 - EXCLUDED. No dashboard JSON, plugin code or provisioning file may be
+      copied out of grafana/grafana. Provisioning YAML and dashboard JSON that WE author is our
+      own work and carries no obligation. This layer must be written from scratch. See gaps.md.
+
+  - id: obs-ebpf-zero-instrumentation
+    category: observability
+    tier: specialist
+    status: proposed
+    what: eBPF auto-instrumentation for services that cannot be recompiled or re-deployed.
+    stacks: [linux]
+    sources:
+      - https://github.com/grafana/beyla
+    requires: []
+    conflicts: []
+    absorbs: [obs-ebpf-zero-instrumentation]
+
+  - id: audit-log
+    category: security-compliance
+    tier: capability
+    status: built
+    what: >-
+      Append-only, tamper-evident audit trail with field redaction and a compliance-shaped
+      event schema.
+    stacks: [any]
+    sources:
+      - https://github.com/jasontaylordev/CleanArchitecture
+    requires: []
+    conflicts: []
+    provides:
+      [audit-log, audit-trail, append-only-log, tamper-evident-log, compliance-logging,
+       audit-config, field-redaction]
+
+  # ===========================================================================================
+  # TIER: capability - security / supply chain
+  # ===========================================================================================
+
+  - id: security-supply-chain
+    category: security-compliance
+    tier: foundation
+    status: built
+    what: >-
+      Dependency updates, dependency review, SAST/code scanning, secret scanning, SBOM,
+      scorecard, pinned actions and a SECURITY.md.
+    stacks: [any]
+    sources:
+      - https://github.com/ossf/scorecard
+      - https://github.com/step-security/harden-runner
+      - https://github.com/gitleaks/gitleaks
+    requires: [ci-github-actions]
+    conflicts: []
+    provides:
+      [supply-chain-security, dependency-updates, dependency-review, sast, code-scanning,
+       secret-scanning, sbom, scorecard, pinned-actions, security-policy]
+    absorbs: [security-hardening-baseline, security-posture-scorecard]
+    licenseNote: >-
+      This layer ships a renovate.json. renovatebot/renovate is AGPL-3.0. Referencing a preset by
+      name (`config:recommended`) is use, not distribution, and is fine. Inlining a preset body
+      into this layer is distribution and is not. The file must stay reference-by-name.
+
+  - id: security-secret-scanning
+    category: security-compliance
+    tier: capability
+    status: proposed
+    what: >-
+      A repo-local .gitleaks.toml that `[extend] useDefault = true` rather than forking the 222
+      default rules, a lockfile/dist allowlist so the first run does not drown the user, a
+      pre-commit hook, and the `--baseline-path` flow for brownfield adoption.
+    stacks: [any]
+    sources:
+      - https://github.com/gitleaks/gitleaks
+    requires: []
+    conflicts: []
+    portability: ci-agnostic
+    absorbs: [security-secret-scanning, security-precommit-hooks]
+    licenseNote: >-
+      gitleaks is MIT - vendorable. trufflesecurity/trufflehog, the tool everyone reflexively
+      pairs with it, is AGPL-3.0 and EXCLUDED. Do not add it as a "companion scanner".
+
+  - id: security-sast-codeql
+    category: security-compliance
+    tier: capability
+    status: proposed
+    what: >-
+      CodeQL workflow with a curated query-suite selection rather than the default everything,
+      plus the SARIF upload that makes findings show as PR annotations.
+    stacks: [any]
+    sources:
+      - https://github.com/github/codeql
+    requires: [ci-github-actions]
+    conflicts: []
+    portability: github-actions-only
+    absorbs: [security-sast, security-sast-codeql, security-codeql]
+    licenseNote: >-
+      github/codeql is MIT and the QUERIES are copyable - the only MIT source in this category
+      whose value is its rule content. The CLI/engine ships from github/codeql-cli-binaries under
+      separate commercial terms for closed-source analysis and is NOT redistributable. Vendor
+      queries; reference the engine. semgrep/semgrep-rules is proprietary and EXCLUDED - it is
+      the obvious-looking substitute and it is the wrong one.
+
+  - id: security-sbom
+    category: security-compliance
+    tier: capability
+    status: proposed
+    what: >-
+      CycloneDX or SPDX SBOM generated by syft at build time, attached to the release, and fed
+      to grype for vulnerability scanning. VEX statements suppress the false positives that
+      otherwise make the scan output unreadable within a month.
+    stacks: [any]
+    sources:
+      - https://github.com/anchore/syft
+      - https://github.com/anchore/grype
+      - https://github.com/CycloneDX/specification
+    requires: [ci-github-actions]
+    conflicts: []
+    portability: ci-agnostic
+    absorbs: [security-sbom, security-sbom-cyclonedx, supply-chain-sbom, security-vex, security-license-compliance]
+    note: >-
+      .syft.yaml and .grype.yaml are NOT checked into their upstream repos - they are config
+      schemas this layer authors. Do not send anyone looking for a file to copy.
+
+  - id: security-vuln-scanning
+    category: security-compliance
+    tier: capability
+    status: proposed
+    what: >-
+      Trivy scanning of filesystem, image and IaC in one tool, with the ignore-file and the
+      exit-code policy that decides which severities actually fail a build.
+    stacks: [any]
+    sources:
+      - https://github.com/aquasecurity/trivy
+      - https://github.com/anchore/grype
+    requires: [ci-github-actions]
+    conflicts: []
+    absorbs: [security-vulnerability-scanning, security-iac-scanning]
+
+  - id: security-artifact-signing
+    category: security-compliance
+    tier: capability
+    status: proposed
+    what: >-
+      Keyless Sigstore signing of images and artifacts with an OIDC workload identity - no
+      long-lived keys to rotate or leak - plus cosign verify as a deploy-time admission gate.
+      gitsign extends the same identity model to commit signing.
+    stacks: [any]
+    sources:
+      - https://github.com/sigstore/cosign
+      - https://github.com/sigstore/gitsign
+    requires: [ci-container-publish]
+    conflicts: []
+    absorbs:
+      [security-artifact-signing, security-keyless-identity, security-commit-signing,
+       supply-chain-sigstore, security-attestation]
+
+  - id: security-slsa-provenance
+    category: security-compliance
+    tier: capability
+    status: proposed
+    what: >-
+      SLSA build provenance generated by the reusable workflow and attached as an attestation,
+      giving a verifiable link from artifact back to source commit and builder.
+    stacks: [any]
+    sources:
+      - https://github.com/slsa-framework/slsa-github-generator
+    requires: [ci-github-actions]
+    conflicts: []
+    portability: github-actions-only
+    absorbs: [security-slsa, security-build-provenance, supply-chain-slsa, supply-chain-provenance]
+    licenseNote: >-
+      The GENERATOR repo (slsa-framework/slsa-github-generator) is Apache-2.0 and vendorable.
+      The SPEC repo (slsa-framework/slsa) is the Community Specification License 1.0 -
+      reference-only. Cite the spec, vendor the generator.
+
+  - id: security-runner-hardening
+    category: security-compliance
+    tier: capability
+    status: proposed
+    what: >-
+      harden-runner egress policy plus SHA-pinned actions, so a compromised third-party action
+      cannot exfiltrate secrets. `block` mode after an audit-mode learning period.
+    stacks: [any]
+    sources:
+      - https://github.com/step-security/harden-runner
+    requires: [ci-github-actions]
+    conflicts: []
+    portability: github-actions-only
+    absorbs: [ci-runner-hardening, ci-security-gates]
+
+  - id: security-headers
+    category: security-compliance
+    tier: capability
+    status: proposed
+    what: >-
+      The fourteen helmet middlewares with a CSP that is actually restrictive, plus the
+      report-only rollout path that makes a strict CSP deployable without breaking the app.
+    stacks: [node]
+    sources:
+      - https://github.com/helmetjs/helmet
+    requires: []
+    conflicts: []
+    absorbs: [security-headers, security-csp, backend-express-hardening]
+
+  - id: security-policy-as-code
+    category: security-compliance
+    tier: specialist
+    status: proposed
+    what: >-
+      Rego policies run by conftest against Kubernetes manifests, Terraform plans, Dockerfiles
+      and CI config, with the policy unit tests that keep the policies honest.
+    stacks: [any]
+    sources:
+      - https://github.com/open-policy-agent/conftest
+    requires: []
+    conflicts: []
+    absorbs: [security-policy-as-code, compliance-policy-rego]
+    note: Terraform examples live under examples/hcl1 and examples/hcl2, not examples/terraform.
+
+  - id: compliance-oscal
+    category: security-compliance
+    tier: specialist
+    status: proposed
+    what: >-
+      OSCAL control catalogs and SSP authoring with compliance-trestle, plus ComplianceAsCode
+      control mappings (products/rhel9/controls/cis_rhel9.yml is the shape) and automated
+      evidence generation from CI runs.
+    stacks: [any]
+    sources:
+      - https://github.com/oscal-compass/compliance-trestle
+      - https://github.com/ComplianceAsCode/content
+    requires: []
+    conflicts: []
+    absorbs: [compliance-oscal, compliance-as-code, compliance-control-mapping, compliance-evidence-generation]
+    licenseNote: >-
+      ComplianceAsCode/content is BSD-3-Clause with exactly one root LICENSE and no sub-directory
+      overrides (checked). Attribution required. OWASP/ASVS and OWASP/CheatSheetSeries are
+      CC-BY-SA-4.0 and reference-only - restate control text in original words, never paste it.
+
+  - id: security-arcjet
+    category: security-compliance
+    tier: specialist
+    status: proposed
+    what: Bot detection, rate limiting and shield rules declared in application code.
+    stacks: [node]
+    sources:
+      - https://github.com/arcjet/arcjet-js
+    requires: []
+    conflicts: []
+    absorbs: [security-arcjet]
+
+  # ===========================================================================================
+  # TIER: capability - async / realtime
+  # ===========================================================================================
+
+  - id: queue-broker
+    category: realtime-messaging
+    tier: capability
+    status: built
+    what: >-
+      Background job queue with retry, dead-letter and worker lifecycle behind a broker-agnostic
+      config surface.
+    stacks: [any]
+    sources:
+      - https://github.com/taskforcesh/bullmq
+      - https://github.com/celery/celery
+    requires: []
+    conflicts: [react-vite-spa, turborepo-monorepo]
+    provides:
+      [queue, message-queue, background-jobs, async-worker, job-retry, dead-letter, queue-config]
+    absorbs: [queue-worker-process, queue-dashboard, queue-priority-queues, queue-concurrency-control]
+    note: >-
+      The conflicts are from the shipped blueprint and look like guards against adding a worker
+      process to a repo with no server. Preserved verbatim; worth re-examining, since a
+      turborepo monorepo is exactly where a separate worker app belongs.
+
+  - id: queue-bullmq
+    category: realtime-messaging
+    tier: capability
+    status: proposed
+    choiceSet: queue-backend
+    what: >-
+      BullMQ on Redis - repeatable cron jobs, flow DAGs for parent/child work, and the
+      QueueEvents stream. The flows feature is the differentiator; most queues have no DAG.
+    stacks: [node]
+    sources:
+      - https://github.com/taskforcesh/bullmq
+    requires: [queue-broker, cache-redis]
+    conflicts: []
+    absorbs: [queue-bullmq-redis, queue-redis-bullmq, queue-flows-dag, queue-cron-repeatable]
+
+  - id: queue-celery
+    category: realtime-messaging
+    tier: capability
+    status: proposed
+    choiceSet: queue-backend
+    what: Celery workers, beat scheduler and the Redis/RabbitMQ broker split.
+    stacks: [python]
+    sources:
+      - https://github.com/celery/celery
+    requires: [queue-broker]
+    conflicts: []
+    absorbs: [queue-celery-python, queue-celery-redis, queue-celery-beat-scheduler]
+
+  - id: queue-asynq
+    category: realtime-messaging
+    tier: capability
+    status: proposed
+    choiceSet: queue-backend
+    what: Asynq on Redis for Go - typed task payloads, priority queues, and a web dashboard.
+    stacks: [go]
+    sources:
+      - https://github.com/hibiken/asynq
+    requires: [queue-broker, cache-redis]
+    conflicts: []
+    absorbs: [queue-asynq-go, jobs-background-queue]
+
+  - id: queue-postgres-native
+    category: realtime-messaging
+    tier: capability
+    status: proposed
+    choiceSet: queue-backend
+    what: >-
+      Jobs as rows in the app's own Postgres, enqueued in the SAME transaction as the business
+      write - so job and data commit or roll back together and the dual-write problem simply
+      does not exist. No extra infrastructure. Throughput ceiling is Postgres's.
+    stacks: [postgres]
+    sources:
+      - https://github.com/hatchet-dev/hatchet
+    requires: [db-postgres]
+    conflicts: []
+    absorbs: [queue-postgres-native, queue-transactional-enqueue, queue-sql-storage-backed, queue-river-postgres, db-postgres-migrations]
+    licenseNote: >-
+      riverqueue/river - the cleanest expression of transactional enqueueing - is MPL-2.0,
+      REFERENCE-ONLY. Keep it a go.mod dependency if used at all; never vendor its source. The
+      IDEA is not copyrightable; the implementation is. Hatchet (Apache-2.0/MIT) is the
+      vendorable source here.
+
+  - id: queue-hangfire
+    category: realtime-messaging
+    tier: specialist
+    status: proposed
+    choiceSet: queue-backend
+    what: Background jobs for .NET stored in the app's existing SQL database.
+    stacks: [dotnet]
+    sources: []
+    requires: [queue-broker]
+    conflicts: []
+    absorbs: [queue-hangfire-dotnet]
+    fromScratch: true
+    licenseNote: >-
+      HangfireIO/Hangfire is a genuine trap: the API reports NOASSERTION and the internet calls
+      it "open source", but the free arm of its multi-license is LGPL-3.0 - REFERENCE-ONLY, no
+      file copying - and Pro/Ace (batches, Redis storage) are separately paid. Reimplement the
+      pattern (persistent storage in the app's existing SQL database, no extra infrastructure)
+      over a permissive base. See gaps.md.
+
+  - id: pattern-transactional-outbox
+    category: realtime-messaging
+    tier: capability
+    status: proposed
+    what: >-
+      Outbox table written in the business transaction, relayed to the broker by a separate
+      poller, with the consumer-side idempotency key that makes at-least-once delivery safe.
+      Solves the same dual-write problem as queue-postgres-native but keeps a real broker.
+    stacks: [any]
+    sources:
+      - https://github.com/dotnet/eShop
+      - https://github.com/debezium/debezium
+    requires: [db-core]
+    conflicts: []
+    absorbs: [pattern-transactional-outbox, msg-integration-events-outbox, pattern-event-driven, pattern-cqrs]
+
+  - id: broker-rabbitmq
+    category: realtime-messaging
+    tier: capability
+    status: proposed
+    choiceSet: broker
+    what: AMQP exchange/queue/binding topology as declarative config, plus a DLX policy.
+    stacks: [any]
+    sources:
+      - https://github.com/rabbitmq/rabbitmq-server
+    requires: [docker-compose]
+    conflicts: []
+    absorbs: [broker-rabbitmq-amqp, msg-rabbitmq]
+
+  - id: broker-nats
+    category: realtime-messaging
+    tier: capability
+    status: proposed
+    choiceSet: broker
+    what: >-
+      NATS core pub/sub plus JetStream for persistence, and the KV store that comes free with
+      JetStream and removes a Redis dependency for simple cases.
+    stacks: [any]
+    sources:
+      - https://github.com/nats-io/nats-server
+      - https://github.com/nats-io/nats.go
+    requires: [docker-compose]
+    conflicts: []
+    absorbs: [broker-nats-core, broker-nats-jetstream, broker-kv-store]
+
+  - id: broker-kafka
+    category: realtime-messaging
+    tier: specialist
+    status: proposed
+    choiceSet: broker
+    what: Kafka in KRaft mode (no ZooKeeper) with a schema registry and topic-as-code config.
+    stacks: [any]
+    sources:
+      - https://github.com/apache/kafka
+    requires: [docker-compose]
+    conflicts: []
+    absorbs: [broker-kafka, broker-kafka-kraft, pattern-schema-registry, data-streaming-kafka]
+
+  - id: broker-redis-streams
+    category: realtime-messaging
+    tier: capability
+    status: proposed
+    choiceSet: broker
+    what: Redis Streams with consumer groups, for teams that already run Redis and want no more.
+    stacks: [any]
+    sources:
+      - https://github.com/redis/redis
+    requires: [cache-redis]
+    conflicts: []
+    absorbs: [broker-redis-streams]
+
+  - id: pubsub-abstraction
+    category: realtime-messaging
+    tier: capability
+    status: proposed
+    what: >-
+      A publisher/subscriber interface over whichever broker was chosen, so the broker choice
+      stays reversible. Watermill is the reference implementation of the shape.
+    stacks: [go, any]
+    sources:
+      - https://github.com/ThreeDotsLabs/watermill
+    requires: []
+    conflicts: []
+    absorbs: [pubsub-watermill-go]
+
+  - id: realtime-websocket
+    category: realtime-messaging
+    tier: capability
+    status: proposed
+    choiceSet: realtime-transport
+    what: >-
+      Raw WebSocket server with the three things every hand-rolled implementation forgets:
+      heartbeat/ping-pong with a dead-connection timeout, auth on the HTTP upgrade rather than
+      in the first message, and backpressure on slow consumers.
+    stacks: [node, go, python]
+    sources:
+      - https://github.com/websockets/ws
+      - https://github.com/gorilla/websocket
+    requires: []
+    conflicts: []
+    absorbs:
+      [realtime-websocket-echo, realtime-websocket-node, realtime-websocket-go,
+       realtime-websocket-heartbeat, realtime-ws-auth-upgrade, realtime-python-async]
+
+  - id: realtime-socketio
+    category: realtime-messaging
+    tier: capability
+    status: proposed
+    choiceSet: realtime-transport
+    what: >-
+      Socket.IO server with rooms, the Redis adapter for multi-instance fanout, and the Next.js
+      custom-server integration that is the usual sticking point.
+    stacks: [node]
+    sources:
+      - https://github.com/socketio/socket.io
+    requires: [cache-redis]
+    conflicts: []
+    absorbs: [realtime-socketio-server, realtime-socketio-redis-adapter, realtime-socketio-nextjs, realtime-chat-fanout]
+
+  - id: realtime-sse
+    category: realtime-messaging
+    tier: capability
+    status: proposed
+    choiceSet: realtime-transport
+    what: >-
+      Server-sent events for one-way streaming - the right answer far more often than a
+      WebSocket, since it survives proxies, reconnects on its own, and needs no protocol upgrade.
+    stacks: [node, python, go]
+    sources:
+      - https://github.com/fastapi/fastapi
+      - https://github.com/centrifugal/centrifugo
+    requires: []
+    conflicts: []
+    absorbs: [realtime-sse-broadcast, realtime-sse-fastapi, realtime-sse-centrifugo]
+
+  - id: realtime-centrifugo
+    category: realtime-messaging
+    tier: capability
+    status: proposed
+    choiceSet: realtime-transport
+    what: >-
+      Centrifugo as a realtime sidecar - the app never holds a socket, it publishes over an API
+      and Centrifugo owns fanout, presence and connection tokens. The best fit when the app
+      language has no good socket story.
+    stacks: [any]
+    sources:
+      - https://github.com/centrifugal/centrifugo
+    requires: [docker-compose]
+    conflicts: []
+    absorbs: [realtime-centrifugo, realtime-sidecar-service, realtime-jwt-connection-token, realtime-broadcast-channels]
+
+  - id: realtime-supabase
+    category: realtime-messaging
+    tier: capability
+    status: proposed
+    choiceSet: realtime-transport
+    what: Postgres logical replication surfaced as client subscriptions, with presence built in.
+    stacks: [postgres, node]
+    sources:
+      - https://github.com/supabase/realtime
+    requires: [db-postgres]
+    conflicts: []
+    absorbs: [realtime-supabase, realtime-postgres-cdc, db-postgres-logical-replication]
+
+  - id: realtime-presence
+    category: realtime-messaging
+    tier: capability
+    status: proposed
+    what: >-
+      Who-is-online state with a Redis-backed set, TTL expiry for ungraceful disconnects, and
+      cross-instance fanout. The TTL is the part hand-rolled versions omit and then leak.
+    stacks: [any]
+    sources:
+      - https://github.com/centrifugal/centrifugo
+      - https://github.com/colyseus/colyseus
+    requires: [cache-redis]
+    conflicts: []
+    absorbs: [realtime-presence, scaling-redis-presence]
+
+  - id: realtime-rooms
+    category: realtime-messaging
+    tier: capability
+    status: proposed
+    what: >-
+      Authoritative room state with schema-based delta sync and a matchmaking/lobby entry point.
+      Colyseus is the reference; its room lifecycle maps cleanly onto non-game use cases too.
+    stacks: [node]
+    sources:
+      - https://github.com/colyseus/colyseus
+    requires: [realtime-websocket]
+    conflicts: []
+    absorbs:
+      [realtime-rooms, realtime-room-state-sync, realtime-matchmaking,
+       realtime-multiplayer-colyseus, netcode-colyseus, matchmaking-rooms, matchmaking-lobby,
+       state-sync-schema, test-colyseus-room]
+
+  - id: workflow-durable
+    category: realtime-messaging
+    tier: specialist
+    status: proposed
+    what: >-
+      Durable execution - workflows that survive process restarts, with signals/queries for
+      external interaction and an explicit versioning strategy so in-flight executions do not
+      break on deploy. The versioning story is what separates this from a job queue.
+    stacks: [any]
+    sources:
+      - https://github.com/temporalio/temporal
+      - https://github.com/hatchet-dev/hatchet
+      - https://github.com/triggerdotdev/trigger.dev
+    requires: []
+    conflicts: []
+    absorbs:
+      [workflow-durable-execution, workflow-temporal, workflow-hatchet, workflow-trigger-dev,
+       workflow-signals-queries, workflow-versioning, workflows-saga-compensation,
+       observability-task-monitoring, ai-scheduled-tasks]
+
+  - id: webhooks-inbound
+    category: payments-billing
+    tier: capability
+    status: proposed
+    what: >-
+      Signature verification before body parse, an idempotency table keyed on the provider event
+      id, an event log for replay, and a queue handoff so the handler returns 200 in
+      milliseconds. Every one of these is a production incident if omitted.
+    stacks: [any]
+    sources:
+      - https://github.com/stripe-samples/accept-a-payment
+      - https://github.com/nextjs/saas-starter
+      - https://github.com/useautumn/autumn
+    requires: [queue-broker]
+    conflicts: []
+    absorbs:
+      [webhooks-inbound-receiver, webhooks-signature-verify, webhooks-normalization,
+       billing-webhook-event-log, billing-idempotency, payments-stripe-webhooks,
+       webhooks-signed-events, events-cloudevents-ingest]
+
+  - id: webhooks-outbound
+    category: payments-billing
+    tier: capability
+    status: proposed
+    what: >-
+      Outbound webhook delivery with HMAC signing, exponential-backoff retry from a queue, a
+      per-endpoint circuit breaker, and a delivery log the customer can see.
+    stacks: [any]
+    sources:
+      - https://github.com/useautumn/autumn
+    requires: [queue-broker]
+    conflicts: []
+    absorbs: [webhooks-outbound, webhooks-outbound-delivery, webhooks-queue-retry]
+
+  # ===========================================================================================
+  # TIER: domain - payments and billing
+  # ===========================================================================================
+
+  - id: payments-provider-port
+    category: payments-billing
+    tier: domain
+    status: proposed
+    what: >-
+      An interface over the PSP - create checkout, fetch subscription, cancel, resolve
+      entitlement - so the provider choice is reversible and testable without network calls.
+      Build this BEFORE any concrete provider, not after the second one is needed.
+    stacks: [any]
+    sources:
+      - https://github.com/medusajs/medusa
+      - https://github.com/hyperswitch-io/hyperswitch
+    requires: []
+    conflicts: []
+    absorbs:
+      [payments-provider-abstraction, payments-multi-psp-connector, payments-orchestration,
+       payments-routing-retry, commerce-provider-adapter]
+
+  - id: payments-stripe
+    category: payments-billing
+    tier: domain
+    status: proposed
+    choiceSet: payments-provider
+    what: >-
+      Stripe Checkout and Elements flows, the customer/subscription sync table, and the webhook
+      set that actually matters. t3dotgg/stripe-recommendations is the shortest correct
+      description of the sync problem anywhere and should be read before writing a line of this.
+    stacks: [node, python, php, dotnet]
+    sources:
+      - https://github.com/stripe-samples/accept-a-payment
+      - https://github.com/stripe-samples/subscription-use-cases
+      - https://github.com/t3dotgg/stripe-recommendations
+      - https://github.com/nextjs/saas-starter
+    requires: [payments-provider-port, webhooks-inbound]
+    conflicts: []
+    absorbs:
+      [payments-stripe, payments-stripe-checkout, payments-stripe-elements,
+       payments-stripe-subscriptions, payments-one-time, payments-session-model,
+       billing-state-sync]
+
+  - id: payments-merchant-of-record
+    category: payments-billing
+    tier: domain
+    status: proposed
+    choiceSet: payments-provider
+    what: >-
+      Polar or Lemon Squeezy as merchant of record - they own VAT/sales-tax liability, which is
+      the entire reason to accept the higher fee. Different data model from Stripe: you get
+      orders and benefits, not charges and subscriptions.
+    stacks: [node]
+    sources:
+      - https://github.com/polarsource/polar
+    requires: [payments-provider-port, webhooks-inbound]
+    conflicts: []
+    absorbs: [payments-merchant-of-record, payments-polar, payments-lemon-squeezy]
+
+  - id: payments-framework-native
+    category: payments-billing
+    tier: domain
+    status: proposed
+    choiceSet: payments-provider
+    what: Laravel Cashier or dj-stripe - the framework's own Stripe integration and its models.
+    stacks: [php, python]
+    sources:
+      - https://github.com/laravel/cashier-stripe
+      - https://github.com/dj-stripe/dj-stripe
+    requires: [payments-provider-port]
+    conflicts: []
+    absorbs: [framework-laravel, framework-django, db-postgres-django]
+
+  - id: billing-subscription-model
+    category: payments-billing
+    tier: domain
+    status: proposed
+    what: >-
+      The local schema mirroring the PSP - plan catalog with versioned prices, subscription
+      state machine, trial and proration handling, upgrade/downgrade paths. Owning this locally
+      is what makes the app queryable without hitting the PSP on every request.
+    stacks: [any]
+    sources:
+      - https://github.com/useautumn/autumn
+      - https://github.com/lotus-data/lotus
+      - https://github.com/nextjs/saas-starter
+    requires: [payments-provider-port, db-core]
+    conflicts: []
+    absorbs:
+      [billing-subscription-model, billing-subscription-engine, billing-plan-catalog,
+       billing-catalog-versioned, billing-trials-proration, billing-upgrade-downgrade-proration,
+       billing-per-seat, billing-multi-tenant, billing-org-scoped]
+
+  - id: billing-usage-metered
+    category: payments-billing
+    tier: domain
+    status: proposed
+    what: >-
+      Usage event ingestion, aggregation windows, a credits ledger, and the sync job that pushes
+      metered usage to the PSP. OpenMeter is the strongest open source on the ingestion side.
+    stacks: [any]
+    sources:
+      - https://github.com/openmeterio/openmeter
+      - https://github.com/lotus-data/lotus
+      - https://github.com/useautumn/autumn
+    requires: [billing-subscription-model]
+    conflicts: []
+    absorbs: [billing-usage-metered, billing-credits-ledger, payments-stripe-usage-sync]
+
+  - id: billing-entitlements
+    category: payments-billing
+    tier: domain
+    status: proposed
+    what: >-
+      A single `hasAccess(user, feature)` derived from subscription state, with quota checks and
+      the graceful-degradation path for overdue accounts. Feature gating scattered across the
+      codebase is the failure mode this prevents.
+    stacks: [any]
+    sources:
+      - https://github.com/useautumn/autumn
+      - https://github.com/polarsource/polar
+    requires: [billing-subscription-model]
+    conflicts: []
+    absorbs: [entitlements-feature-gating, entitlements-benefits, entitlements-usage-quota, plugin-app-store]
+
+  - id: billing-invoicing-dunning
+    category: payments-billing
+    tier: domain
+    status: proposed
+    what: Invoice generation, tax fields, and the dunning email/retry ladder for failed payments.
+    stacks: [any]
+    sources:
+      - https://github.com/getlago/lago
+    requires: [billing-subscription-model, email-transactional]
+    conflicts: []
+    absorbs: [billing-invoice, billing-dunning-overdue]
+
+  - id: payments-vault-tokenization
+    category: payments-billing
+    tier: specialist
+    status: proposed
+    what: Card tokenization and vaulting so raw PAN never touches the application at all.
+    stacks: [any]
+    sources:
+      - https://github.com/hyperswitch-io/hyperswitch
+    requires: [payments-provider-port]
+    conflicts: []
+    absorbs: [payments-vault-tokenization]
+
+  # ===========================================================================================
+  # TIER: domain - CMS and commerce
+  # ===========================================================================================
+
+  - id: cms-payload
+    category: cms-ecommerce
+    tier: domain
+    status: proposed
+    choiceSet: cms-backend
+    what: >-
+      Payload CMS - collections as TypeScript config, generated types, admin UI, and the website
+      and ecommerce templates as ready starting shapes.
+    stacks: [node, typescript]
+    sources:
+      - https://github.com/payloadcms/payload
+    requires: [db-core]
+    conflicts: []
+    absorbs:
+      [cms-payload, admin-payload, cms-payload-website-template, cms-payload-ecommerce-template,
+       cms-strapi-reference, content-type-builder-runtime]
+    licenseNote: >-
+      strapi/strapi is the obvious comparison and is REFERENCE-ONLY: its MIT grant applies only
+      outside `ee/` AND only if you hold no registered Strapi Cloud account. Its
+      content-type-builder (schemas as JSON, editable at runtime through the admin) and its
+      draft/publish + i18n model are worth studying, which is why `cms-strapi-reference` and
+      `content-type-builder-runtime` land here - but they must be reimplemented, never vendored.
+
+  - id: cms-keystone
+    category: cms-ecommerce
+    tier: domain
+    status: proposed
+    choiceSet: cms-backend
+    what: >-
+      Keystone - schema-defined lists generating both an admin UI and a GraphQL API, with
+      field-level access control as first-class config.
+    stacks: [node, typescript]
+    sources:
+      - https://github.com/keystonejs/keystone
+    requires: [db-core]
+    conflicts: []
+    absorbs: [cms-keystone, auth-session-keystone]
+
+  - id: cms-sanity
+    category: cms-ecommerce
+    tier: domain
+    status: proposed
+    choiceSet: cms-backend
+    what: >-
+      Sanity with an embedded Studio route, Portable Text rendering, and live visual editing
+      with draft mode.
+    stacks: [node, react]
+    sources:
+      - https://github.com/sanity-io/sanity
+    requires: []
+    conflicts: []
+    absorbs: [cms-sanity, cms-sanity-studio-embedded, content-portable-text, preview-live-visual-editing, preview-draft-mode]
+
+  - id: cms-git-backed
+    category: cms-ecommerce
+    tier: domain
+    status: proposed
+    choiceSet: cms-backend
+    what: >-
+      Content as files in the repo - MDX or Markdoc with a typed schema, edited through Keystatic
+      or Nuxt Content. No database, no CMS to run, and content changes go through code review.
+    stacks: [node, react, vue]
+    sources:
+      - https://github.com/Thinkmill/keystatic
+      - https://github.com/nuxt/content
+      - https://github.com/markdoc/markdoc
+    requires: []
+    conflicts: []
+    absorbs:
+      [cms-keystatic, admin-keystatic-embedded, cms-nuxt-content, content-file-based,
+       content-git-backed, content-mdx, content-markdoc, content-schema-typed,
+       db-sqlite-embedded]
+
+  - id: cms-ghost-headless
+    category: cms-ecommerce
+    tier: specialist
+    status: proposed
+    choiceSet: cms-backend
+    what: Ghost as a headless publishing backend with members and paid subscriptions built in.
+    stacks: [node]
+    sources:
+      - https://github.com/TryGhost/Ghost
+    requires: []
+    conflicts: []
+    absorbs: [cms-ghost-headless, members-subscriptions]
+
+  - id: cms-content-api
+    category: cms-ecommerce
+    tier: capability
+    status: proposed
+    what: >-
+      The read-side contract in front of whichever CMS was chosen - read-only API keys, cached
+      queries, draft-vs-published resolution, and locale fallback.
+    stacks: [any]
+    sources:
+      - https://github.com/payloadcms/payload
+      - https://github.com/sanity-io/sanity
+    requires: []
+    conflicts: []
+    absorbs: [content-api-readonly-keys, rendering-streaming-deferred, seo-metadata-opengraph]
+
+  - id: commerce-medusa
+    category: cms-ecommerce
+    tier: domain
+    status: proposed
+    choiceSet: commerce-backend
+    what: >-
+      Medusa - modular commerce with workflow-based order orchestration, multi-region pricing,
+      and pluggable payment/fulfilment providers.
+    stacks: [node, typescript]
+    sources:
+      - https://github.com/medusajs/medusa
+    requires: [db-postgres]
+    conflicts: []
+    absorbs: [commerce-medusa, admin-medusa, commerce-inventory-fulfillment, db-postgres-mikroorm]
+
+  - id: commerce-saleor
+    category: cms-ecommerce
+    tier: domain
+    status: proposed
+    choiceSet: commerce-backend
+    what: Saleor - GraphQL-first commerce with channels for multi-market pricing and catalog.
+    stacks: [python]
+    sources:
+      - https://github.com/saleor/saleor
+    requires: [db-postgres]
+    conflicts: []
+    absorbs: [commerce-saleor, commerce-multichannel, queue-celery-redis]
+
+  - id: commerce-shopify-storefront
+    category: cms-ecommerce
+    tier: domain
+    status: proposed
+    choiceSet: commerce-backend
+    what: >-
+      Hydrogen storefront against the Shopify Storefront API - Shopify owns catalog, checkout,
+      payments and tax; you own presentation only.
+    stacks: [node, react]
+    sources:
+      - https://github.com/Shopify/hydrogen
+    requires: []
+    conflicts: []
+    absorbs: [storefront-shopify-hydrogen, commerce-cart-shopify, deploy-shopify-oxygen, storefront-nextjs-minimal]
+
+  - id: commerce-cart-checkout
+    category: cms-ecommerce
+    tier: domain
+    status: proposed
+    what: >-
+      Cart state with optimistic updates, server-authoritative price recalculation on every
+      mutation, and the checkout state machine. Never trust a client-supplied price - the
+      optimistic UI is a display concern only.
+    stacks: [node, react]
+    sources:
+      - https://github.com/medusajs/medusa
+      - https://github.com/vercel/commerce
+    requires: [payments-provider-port]
+    conflicts: []
+    absorbs: [commerce-cart-checkout, commerce-cart-optimistic]
+
+  - id: media-uploads
+    category: cms-ecommerce
+    tier: capability
+    status: proposed
+    what: >-
+      Presigned direct-to-S3 upload, MIME and size validation server-side, and an image
+      derivative pipeline. Direct upload keeps large files off the app server entirely.
+    stacks: [any]
+    sources:
+      - https://github.com/payloadcms/payload
+      - https://github.com/fastapi/full-stack-fastapi-template
+    requires: []
+    conflicts: []
+    absorbs: [media-uploads-s3, files-s3-upload, storage-supabase, storage-vercel-blob, assets-static-pipeline]
+
+  - id: email-transactional
+    category: fullstack-saas
+    tier: capability
+    status: proposed
+    what: >-
+      React Email templates rendered server-side and sent through a provider adapter, plus the
+      invite/verify/reset flows that every product needs and every product rewrites.
+    stacks: [node, react]
+    sources:
+      - https://github.com/resend/react-email
+      - https://github.com/nextacular/nextacular
+    requires: []
+    conflicts: []
+    absorbs: [email-react-email-resend, email-transactional-invites, mail-smtp-templates]
+
+  # ===========================================================================================
+  # TIER: domain - AI / LLM
+  # ===========================================================================================
+
+  - id: ai-sdk-core
+    category: ai-llm
+    tier: domain
+    status: proposed
+    what: >-
+      A provider-agnostic LLM call surface - streaming, tool calls, structured output via a Zod
+      schema - so the model choice is config, not code. Directly implements this repo's
+      role-to-env model resolution rule: no literal model id at any call site.
+    stacks: [node, typescript]
+    sources:
+      - https://github.com/vercel/ai
+    requires: [env-typed-config]
+    conflicts: []
+    absorbs:
+      [ai-sdk-core, ai-provider-openai, ai-provider-anthropic, ai-provider-gateway,
+       ai-structured-output, ai-tools-zod]
+
+  - id: ai-chat-ui
+    category: ai-llm
+    tier: domain
+    status: proposed
+    what: >-
+      Streaming chat UI - message list, tool-call rendering, generative UI components, stop and
+      regenerate. assistant-ui is shadcn-compatible so it drops into an existing design system.
+    stacks: [react]
+    sources:
+      - https://github.com/assistant-ui/assistant-ui
+      - https://github.com/vercel/chatbot
+    requires: [ai-sdk-core, ui-shadcn]
+    conflicts: []
+    absorbs: [ai-chat-nextjs-ai-sdk, ui-chat-assistant-ui, ai-generative-ui]
+
+  - id: ai-agent-framework
+    category: ai-llm
+    tier: domain
+    status: proposed
+    choiceSet: agent-framework
+    what: >-
+      Agent loop with tools, handoffs and typed outputs. PydanticAI for typed Python, OpenAI
+      Agents SDK for the OpenAI-native path, LangGraph when the control flow is a real graph
+      rather than a loop.
+    stacks: [python, node]
+    sources:
+      - https://github.com/pydantic/pydantic-ai
+      - https://github.com/openai/openai-agents-python
+      - https://github.com/langchain-ai/langgraph
+    requires: []
+    conflicts: []
+    absorbs:
+      [ai-agent-python-pydantic-ai, ai-agent-python-openai-agents, ai-agent-graph-langgraph,
+       ai-agent-cloudflare-workers, ai-human-in-the-loop, ai-guardrails]
+
+  - id: ai-agent-memory
+    category: ai-llm
+    tier: domain
+    status: proposed
+    what: >-
+      Session memory, long-term memory and graph checkpointing to Postgres, so an agent run
+      survives a process restart and a conversation survives a session.
+    stacks: [python, node]
+    sources:
+      - https://github.com/langchain-ai/langgraph
+    requires: [ai-agent-framework, db-postgres]
+    conflicts: []
+    absorbs: [ai-session-memory, ai-long-term-memory, ai-checkpoint-postgres]
+
+  - id: rag-pipeline
+    category: ai-llm
+    tier: domain
+    status: proposed
+    what: >-
+      Document ingestion, chunking, embedding, hybrid retrieval, reranking and citation-carrying
+      answers, with per-document ACL filtering applied at query time rather than after.
+    stacks: [python, node]
+    sources:
+      - https://github.com/pgvector/pgvector
+      - https://github.com/qdrant/qdrant
+    requires: [vector-store-pgvector]
+    conflicts: []
+    absorbs:
+      [rag-doc-ingestion, rag-retriever-interface, rag-citations, rag-acl-filtering,
+       vector-hybrid-search, rag-azure-ai-search]
+
+  - id: vector-store-pgvector
+    category: ai-llm
+    tier: domain
+    status: proposed
+    choiceSet: vector-store
+    what: >-
+      pgvector in the app's existing Postgres - no extra service, transactional with the rest of
+      the data, and correct up to a few million vectors.
+    stacks: [postgres]
+    sources:
+      - https://github.com/pgvector/pgvector
+    requires: [db-postgres]
+    conflicts: []
+    absorbs: [db-postgres-pgvector, db-migrations-vector]
+    licenseNote: >-
+      pgvector is licensed `PostgreSQL` - a two-clause permissive license, textually an ISC/BSD-2
+      variant, OSI-approved. Not literally on the vendorable allowlist; admitted by reading it.
+
+  - id: vector-store-qdrant
+    category: ai-llm
+    tier: domain
+    status: proposed
+    choiceSet: vector-store
+    what: Qdrant with payload filtering and named vectors, for when pgvector's ceiling is hit.
+    stacks: [any]
+    sources:
+      - https://github.com/qdrant/qdrant
+    requires: [docker-compose]
+    conflicts: []
+    absorbs: [vector-qdrant]
+
+  - id: vector-store-embedded
+    category: ai-llm
+    tier: domain
+    status: proposed
+    choiceSet: vector-store
+    what: Chroma or LanceDB embedded in-process - zero infrastructure, for prototypes and CLIs.
+    stacks: [python]
+    sources:
+      - https://github.com/chroma-core/chroma
+    requires: []
+    conflicts: []
+    absorbs: [vector-chroma, vector-embedded-local]
+
+  - id: mcp-server
+    category: agent-tooling
+    tier: domain
+    status: proposed
+    what: >-
+      An MCP server exposing tools, resources and prompts over streamable HTTP, with the OAuth
+      flow for authenticated servers. The reference servers are the authoritative shape.
+    stacks: [node, python]
+    sources:
+      - https://github.com/modelcontextprotocol/typescript-sdk
+      - https://github.com/modelcontextprotocol/python-sdk
+      - https://github.com/modelcontextprotocol/servers
+      - https://github.com/PrefectHQ/fastmcp
+    requires: []
+    conflicts: []
+    absorbs:
+      [mcp-server-typescript, mcp-server-python-fastmcp, mcp-transport-streamable-http,
+       mcp-auth-oauth, mcp-testing]
+
+  - id: mcp-client
+    category: agent-tooling
+    tier: domain
+    status: proposed
+    what: MCP client - server discovery, tool listing, and the connection lifecycle.
+    stacks: [node, python]
+    sources:
+      - https://github.com/modelcontextprotocol/typescript-sdk
+      - https://github.com/modelcontextprotocol/python-sdk
+      - https://github.com/modelcontextprotocol/registry
+    requires: []
+    conflicts: []
+    absorbs: [mcp-client-typescript, mcp-client-python]
+
+  - id: agent-skills
+    category: agent-tooling
+    tier: domain
+    status: proposed
+    what: >-
+      SKILL.md authoring - the three-key frontmatter shape, progressive disclosure so the
+      context window stays lean, and a lint rule that flags a skill which has outgrown it.
+    stacks: [any]
+    sources:
+      - https://github.com/obra/superpowers
+      - https://github.com/github/spec-kit
+    requires: []
+    conflicts: []
+    absorbs: []
+    licenseNote: >-
+      anthropics/skills (162k stars) has NO root LICENSE and its docx/pdf/pptx/xlsx skills carry
+      an explicit source-available LICENSE.txt forbidding extraction. EXCLUDED - nothing may be
+      vendored. Take the spec from agentskills/agentskills, which publishes the same text under
+      Apache-2.0, and take vendorable skill content from obra/superpowers (MIT). Four of the most
+      cited "awesome-claude-*" lists are unlicensed or CC-BY-NC-ND; see README.md.
+
+  - id: obs-llm-tracing
+    category: ai-llm
+    tier: capability
+    status: proposed
+    what: >-
+      OTel GenAI semantic conventions for LLM spans - token counts, model, cost - plus prompt
+      versioning. Makes LLM cost a metric on the existing dashboard rather than a separate tool.
+    stacks: [python, node]
+    sources:
+      - https://github.com/langfuse/langfuse
+      - https://github.com/open-telemetry/opentelemetry-python-contrib
+    requires: [observability-otel]
+    conflicts: []
+    absorbs: [obs-otel-llm, obs-langfuse, prompt-management-langfuse]
+
+  # ===========================================================================================
+  # TIER: domain - data engineering
+  # ===========================================================================================
+
+  - id: data-dbt
+    category: data-engineering
+    tier: domain
+    status: proposed
+    choiceSet: data-transform
+    what: >-
+      dbt project layout on the medallion staging/intermediate/marts split, with schema tests,
+      source freshness, and exposures. The tests are the part that makes a pipeline trustworthy.
+    stacks: [sql, python]
+    sources:
+      - https://github.com/dbt-labs/dbt-core
+      - https://github.com/dbt-labs/jaffle-shop
+    requires: []
+    conflicts: []
+    absorbs: [data-dbt, data-dbt-tests, data-dbt-governance, data-medallion]
+
+  - id: data-sqlmesh
+    category: data-engineering
+    tier: specialist
+    status: proposed
+    choiceSet: data-transform
+    what: >-
+      SQLMesh with virtual data environments and column-level lineage, so a model change can be
+      previewed without rebuilding the warehouse.
+    stacks: [sql, python]
+    sources:
+      - https://github.com/TobikoData/sqlmesh
+    requires: []
+    conflicts: []
+    absorbs: [data-transform-sqlmesh]
+
+  - id: data-duckdb
+    category: data-engineering
+    tier: domain
+    status: proposed
+    what: >-
+      DuckDB as the local analytical engine - dbt-duckdb makes the whole warehouse a file, which
+      collapses the dev-environment problem for data work entirely.
+    stacks: [python, sql]
+    sources:
+      - https://github.com/duckdb/duckdb
+      - https://github.com/duckdb/dbt-duckdb
+    requires: []
+    conflicts: []
+    absorbs: [data-duckdb, data-dbt-duckdb, data-lakehouse-ducklake]
+
+  - id: data-orchestration-dagster
+    category: data-engineering
+    tier: domain
+    status: proposed
+    choiceSet: data-orchestrator
+    what: >-
+      Dagster software-defined assets - declare what should exist, not what should run. Asset
+      lineage comes free; in Airflow it is a separate concern.
+    stacks: [python]
+    sources:
+      - https://github.com/dagster-io/dagster
+    requires: []
+    conflicts: []
+    absorbs: [data-orchestration-dagster]
+
+  - id: data-orchestration-airflow
+    category: data-engineering
+    tier: domain
+    status: proposed
+    choiceSet: data-orchestrator
+    what: Airflow DAGs with TaskFlow, deferrable operators and a compose-based local stack.
+    stacks: [python]
+    sources:
+      - https://github.com/apache/airflow
+    requires: [docker-compose]
+    conflicts: []
+    absorbs: [data-orchestration-airflow]
+
+  - id: data-ingestion-dlt
+    category: data-engineering
+    tier: domain
+    status: proposed
+    what: >-
+      dlt pipelines with schema inference/evolution and incremental cursors - the extract-load
+      half that dbt deliberately does not cover.
+    stacks: [python]
+    sources:
+      - https://github.com/dlt-hub/dlt
+    requires: []
+    conflicts: []
+    absorbs: [data-ingestion-dlt, data-cdc-incremental]
+
+  - id: data-cdc-debezium
+    category: data-engineering
+    tier: specialist
+    status: proposed
+    what: Change-data-capture off the database log rather than by polling, streamed to a broker.
+    stacks: [any]
+    sources:
+      - https://github.com/debezium/debezium
+    requires: [broker-kafka]
+    conflicts: []
+    absorbs: [data-cdc-debezium]
+
+  - id: data-lakehouse-table-format
+    category: data-engineering
+    tier: specialist
+    status: proposed
+    what: Iceberg or Delta table format on object storage - schema evolution and time travel.
+    stacks: [python, sql]
+    sources:
+      - https://github.com/apache/iceberg
+      - https://github.com/delta-io/delta
+    requires: []
+    conflicts: []
+    absorbs: [data-lakehouse-iceberg, data-lakehouse-delta]
+
+  - id: data-quality
+    category: data-engineering
+    tier: capability
+    status: proposed
+    what: >-
+      Expectation suites and freshness/volume anomaly monitors that fail the pipeline rather
+      than quietly publishing bad marts.
+    stacks: [python, sql]
+    sources:
+      - https://github.com/great-expectations/great_expectations
+      - https://github.com/elementary-data/elementary
+    requires: []
+    conflicts: []
+    absorbs: [data-quality-great-expectations, data-observability-elementary]
+
+  - id: data-transform-polars
+    category: data-engineering
+    tier: capability
+    status: proposed
+    what: Polars lazy frames for in-process transforms that outgrew pandas but not the machine.
+    stacks: [python, rust]
+    sources:
+      - https://github.com/pola-rs/polars
+    requires: []
+    conflicts: []
+    absorbs: [data-transform-polars]
+
+  # ===========================================================================================
+  # TIER: domain - mobile and desktop
+  # ===========================================================================================
+
+  - id: mobile-expo
+    category: mobile-desktop
+    tier: domain
+    status: proposed
+    choiceSet: mobile-desktop-shell
+    what: >-
+      Expo app with file-based expo-router, typed routes, auth-gated route groups, NativeWind
+      styling and EAS build/submit in CI.
+    stacks: [react-native]
+    sources:
+      - https://github.com/expo/expo
+      - https://github.com/obytes/react-native-template-obytes
+      - https://github.com/flemingvincent/expo-clerk-convex
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs:
+      [mobile-expo-router, mobile-expo-minimal, mobile-auth-expo-session,
+       mobile-auth-gated-routes, ui-nativewind, theme-tokens-rn, mobile-rn-components-kit,
+       ci-eas-build, ci-github-actions-eas, mobile-push-notifications, devtools-reactotron]
+
+  - id: mobile-flutter
+    category: mobile-desktop
+    tier: domain
+    status: proposed
+    choiceSet: mobile-desktop-shell
+    what: >-
+      Flutter app in the feature-first layered layout with Riverpod or BLoC, go_router,
+      Material 3 theming from design tokens, and dev/stg/prod flavors.
+    stacks: [flutter, dart]
+    sources:
+      - https://github.com/flutter/samples
+      - https://github.com/bizz84/starter_architecture_flutter_firebase
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs:
+      [flutter-app-core, flutter-app-minimal, flutter-feature-first-layers, flutter-riverpod,
+       flutter-bloc, flutter-mvvm-compass, flutter-stacked-mvvm, flutter-di-get-it,
+       flutter-routing-go-router, flutter-routing-generated, flutter-material3-theme,
+       flutter-design-tokens, flutter-flavors-dev-stg-prod, flutter-codegen-build-runner,
+       flutter-platform-runners, lint-very-good-analysis]
+
+  - id: desktop-tauri
+    category: mobile-desktop
+    tier: domain
+    status: proposed
+    choiceSet: mobile-desktop-shell
+    what: >-
+      Tauri v2 with the capabilities permission model (deny by default), external-link guard,
+      window-flash prevention on startup, and release size optimisation.
+    stacks: [rust, react, typescript]
+    sources:
+      - https://github.com/tauri-apps/tauri
+      - https://github.com/agmmnn/tauri-ui
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs:
+      [desktop-tauri-v2, tauri-capabilities-security, tauri-security-link-guard,
+       tauri-window-flash-prevention, tauri-release-size-optimization, tauri-icon-assets]
+
+  - id: desktop-electron
+    category: mobile-desktop
+    tier: domain
+    status: proposed
+    choiceSet: mobile-desktop-shell
+    what: >-
+      Electron with contextIsolation on, a preload contextBridge exposing a typed IPC surface
+      (never the raw ipcRenderer), a window factory, electron-builder packaging, code signing
+      and notarization, and auto-update.
+    stacks: [node, typescript]
+    sources:
+      - https://github.com/electron/electron
+      - https://github.com/alex8088/electron-vite
+      - https://github.com/daltonmenezes/electron-app
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs:
+      [desktop-electron, electron-security-baseline, electron-preload-contextbridge,
+       electron-typed-ipc, electron-window-factory, electron-multi-window-router,
+       packaging-electron-builder, electron-code-signing-notarization, electron-auto-update,
+       build-electron-vite, build-electron-webpack, ci-release-multiplatform]
+
+  - id: desktop-mobile-maui
+    category: mobile-desktop
+    tier: specialist
+    status: proposed
+    choiceSet: mobile-desktop-shell
+    what: .NET MAUI with the MVVM Community Toolkit, Shell navigation and multi-target csproj.
+    stacks: [dotnet]
+    sources:
+      - https://github.com/dotnet/maui
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs: [desktop-mobile-maui, maui-mvvm-toolkit, maui-shell-navigation, maui-di-mauiprogram, maui-multitarget-csproj, maui-resources-theming]
+
+  - id: mobile-local-storage
+    category: mobile-desktop
+    tier: capability
+    status: proposed
+    what: >-
+      On-device storage - SQLite/WatermelonDB for relational data, MMKV for key-value, and
+      SecureStore/Keychain for tokens. Tokens never go in MMKV; that is the mistake this prevents.
+    stacks: [react-native, flutter]
+    sources:
+      - https://github.com/Nozbe/WatermelonDB
+      - https://github.com/mrousavy/react-native-mmkv
+    requires: []
+    conflicts: []
+    absorbs: [db-sqlite-mobile, mobile-expo-sqlite, db-watermelondb, storage-mmkv, storage-secure-store, db-migrations-versioned]
+
+  - id: mobile-offline-sync
+    category: mobile-desktop
+    tier: specialist
+    status: proposed
+    what: >-
+      Offline-first sync - a local write queue, pull/push protocol, partial-replication rules so
+      a device does not download the whole table, and an explicit conflict policy. The conflict
+      policy must be chosen deliberately; last-write-wins by omission is a data-loss bug.
+    stacks: [react-native, flutter]
+    sources:
+      - https://github.com/powersync-ja/powersync-js
+      - https://github.com/Nozbe/WatermelonDB
+    requires: [mobile-local-storage]
+    conflicts: []
+    absorbs: [offline-first-sync, sync-powersync, sync-pull-push-protocol, sync-upload-queue, sync-partial-replication-rules, db-postgres-backend]
+
+  # ===========================================================================================
+  # TIER: domain - game / 3D
+  # ===========================================================================================
+
+  - id: render-r3f
+    category: game-3d
+    tier: domain
+    status: proposed
+    choiceSet: game-renderer
+    what: >-
+      React Three Fiber scene graph with drei helpers, HDRI environment lighting, postprocessing
+      and instancing for draw-call reduction.
+    stacks: [react, threejs, typescript]
+    sources:
+      - https://github.com/pmndrs/react-three-fiber
+      - https://github.com/pmndrs/drei
+      - https://github.com/mrdoob/three.js
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs:
+      [render-r3f, render-threejs, controls-orbit, lighting-environment-hdri,
+       postfx-postprocessing, perf-instancing, assets-gltf-loader, camera-third-person,
+       controls-character-ecctrl, ui-spatial, shaders-glsl, webgpu-renderer]
+
+  - id: render-babylon
+    category: game-3d
+    tier: domain
+    status: proposed
+    choiceSet: game-renderer
+    what: Babylon.js scene with the node material editor and built-in physics/XR integration.
+    stacks: [typescript]
+    sources:
+      - https://github.com/BabylonJS/Babylon.js
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs: [render-babylon, shaders-node-material, physics-havok]
+
+  - id: render-playcanvas
+    category: game-3d
+    tier: specialist
+    status: proposed
+    choiceSet: game-renderer
+    what: PlayCanvas engine with its ECS and the gaussian-splatting renderer.
+    stacks: [typescript]
+    sources:
+      - https://github.com/playcanvas/engine
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs: [render-playcanvas, ecs-playcanvas, render-gaussian-splatting]
+
+  - id: render-framework-bindings
+    category: game-3d
+    tier: specialist
+    status: proposed
+    what: Threlte (Svelte) and TresJS (Vue) - the same three.js scene graph in another framework.
+    stacks: [svelte, vue]
+    sources:
+      - https://github.com/threlte/threlte
+      - https://github.com/Tresjs/tres
+    requires: []
+    conflicts: []
+    absorbs: [render-threlte-svelte, render-tres-vue, build-nuxt]
+
+  - id: engine-phaser
+    category: game-3d
+    tier: domain
+    status: proposed
+    choiceSet: game-renderer
+    what: Phaser 2D game with scene routing, arcade physics and spritesheet atlases.
+    stacks: [typescript]
+    sources:
+      - https://github.com/phaserjs/phaser
+    requires: [repo-scaffold]
+    conflicts: []
+    absorbs: [engine-phaser, physics-arcade, physics-matter, assets-spritesheet-atlas, game-scene-router]
+
+  - id: engine-godot
+    category: game-3d
+    tier: domain
+    status: proposed
+    choiceSet: game-renderer
+    what: Godot project with scene/node structure, 3D physics, headless export in CI, and OpenXR.
+    stacks: [godot, gdscript]
+    sources:
+      - https://github.com/godotengine/godot
+    requires: []
+    conflicts: []
+    absorbs: [engine-godot, physics-godot-3d, ci-godot-export, netcode-godot-multiplayer, xr-openxr-godot]
+
+  - id: engine-bevy
+    category: game-3d
+    tier: specialist
+    status: proposed
+    choiceSet: game-renderer
+    what: Bevy ECS app with the bevy_new_2d template's system ordering and asset-loading states.
+    stacks: [rust]
+    sources:
+      - https://github.com/bevyengine/bevy
+      - https://github.com/TheBevyFlock/bevy_new_2d
+    requires: []
+    conflicts: []
+    absorbs: [engine-bevy, ecs-bevy, audio-bevy, build-cargo]
+    licenseNote: >-
+      bevy_new_2d is `MIT OR Apache-2.0 OR CC0-1.0` - a disjunction. Pick MIT to minimise the
+      notice burden and RECORD the choice in THIRD-PARTY-NOTICES.md. An unrecorded choice is
+      not a choice.
+
+  - id: engine-unity
+    category: game-3d
+    tier: specialist
+    status: proposed
+    choiceSet: game-renderer
+    what: Unity project conventions plus Mirror networking for the authoritative-server model.
+    stacks: [unity, csharp]
+    sources:
+      - https://github.com/MirrorNetworking/Mirror
+    requires: []
+    conflicts: []
+    absorbs: [engine-unity, netcode-mirror-unity, state-sync-syncvar, transport-kcp-udp]
+
+  - id: physics-rapier
+    category: game-3d
+    tier: capability
+    status: proposed
+    choiceSet: game-physics
+    what: >-
+      Rapier physics via react-three-rapier - rigid bodies, colliders, collision events and a
+      debug overlay that is on in development and stripped in production.
+    stacks: [react, threejs, rust]
+    sources:
+      - https://github.com/dimforge/rapier
+      - https://github.com/pmndrs/react-three-rapier
+    requires: [render-r3f]
+    conflicts: []
+    absorbs: [physics-rapier, collision-events, debug-physics-overlay]
+
+  - id: game-audio
+    category: game-3d
+    tier: capability
+    status: proposed
+    what: Web Audio positional sound with a sprite-based loader and an unlock-on-first-gesture path.
+    stacks: [typescript]
+    sources:
+      - https://github.com/goldfire/howler.js
+    requires: []
+    conflicts: []
+    absorbs: [audio-webaudio]
+
+  - id: game-input
+    category: game-3d
+    tier: capability
+    status: proposed
+    what: Keyboard/gamepad/pointer input mapped to named actions rather than raw key codes.
+    stacks: [typescript]
+    sources:
+      - https://github.com/pmndrs/drei
+    requires: []
+    conflicts: []
+    absorbs: [input-keyboard-gamepad, input-pointer-keyboard, input-hand-tracking]
+
+  - id: game-xr-webxr
+    category: game-3d
+    tier: specialist
+    status: proposed
+    what: WebXR session setup, controller/hand tracking and the XR-specific perf budget.
+    stacks: [react, threejs]
+    sources:
+      - https://github.com/pmndrs/xr
+    requires: [render-r3f]
+    conflicts: []
+    absorbs: [xr-webxr]
+
+  - id: game-perf-mobile
+    category: game-3d
+    tier: capability
+    status: proposed
+    what: Mobile GPU budget - texture compression, LOD, draw-call ceilings and a device tier map.
+    stacks: [threejs, typescript]
+    sources:
+      - https://github.com/pmndrs/drei
+    requires: []
+    conflicts: []
+    absorbs: [perf-mobile, editor-inspector-debug]
+
+  # ===========================================================================================
+  # TIER: capability - infrastructure and deploy
+  # ===========================================================================================
+
+  - id: k8s-manifests
+    category: devops-cicd
+    tier: capability
+    status: proposed
+    what: >-
+      Kustomize base plus staging/prod overlays, with resource requests/limits, PDBs and an HPA.
+      Overlays rather than Helm values when the difference between environments is small.
+    stacks: [kubernetes]
+    sources:
+      - https://github.com/kubernetes-sigs/kustomize
+    requires: [docker]
+    conflicts: []
+    absorbs:
+      [k8s-manifests-base, k8s-manifests-kustomize, k8s-overlays-staging-prod,
+       k8s-hpa-autoscaling, k8s-blue-green-upgrade]
+
+  - id: helm-chart
+    category: devops-cicd
+    tier: capability
+    status: proposed
+    what: A chart for the app with a values schema, so invalid values fail at lint not at install.
+    stacks: [kubernetes]
+    sources:
+      - https://github.com/helm/helm
+    requires: [docker]
+    conflicts: []
+    absorbs: [helm-chart-app, deploy-helm-chart]
+
+  - id: gitops-flux
+    category: devops-cicd
+    tier: specialist
+    status: proposed
+    what: Flux GitRepository/Kustomization/HelmRelease reconciliation from the repo.
+    stacks: [kubernetes]
+    sources:
+      - https://github.com/fluxcd/flux2
+    requires: [k8s-manifests]
+    conflicts: []
+    absorbs: [gitops-flux, helm-release-flux]
+
+  - id: iac-terraform
+    category: devops-cicd
+    tier: capability
+    status: proposed
+    choiceSet: iac-tool
+    what: >-
+      Terraform module layout (root/modules/environments), remote state with locking, the
+      terraform-aws-modules VPC and EKS modules, and Karpenter for node autoscaling.
+    stacks: [terraform, aws]
+    sources:
+      - https://github.com/terraform-aws-modules/terraform-aws-vpc
+      - https://github.com/terraform-aws-modules/terraform-aws-eks
+      - https://github.com/antonbabenko/pre-commit-terraform
+    requires: []
+    conflicts: []
+    absorbs:
+      [iac-terraform-module-layout, iac-terraform-aws-vpc, iac-terraform-aws-eks,
+       k8s-autoscaling-karpenter, iac-reference-architecture, lint-precommit-terraform]
+    licenseNote: >-
+      opentofu/opentofu is MPL-2.0 - reference-only. It is a drop-in CLI replacement and using
+      the binary is fine; copying its source is not. The terraform-aws-modules are Apache-2.0
+      and vendorable with attribution.
+
+  - id: iac-bicep-azd
+    category: devops-cicd
+    tier: specialist
+    status: proposed
+    choiceSet: iac-tool
+    what: Bicep modules driven by azd up, for Azure-native deployments.
+    stacks: [azure, bicep]
+    sources:
+      - https://github.com/Azure/azure-dev
+    requires: []
+    conflicts: []
+    absorbs: [iac-bicep-azd, deploy-azure-container-apps]
+
+  - id: deploy-vercel
+    category: devops-cicd
+    tier: capability
+    status: proposed
+    choiceSet: deploy-target
+    what: Vercel project config, preview deployments per PR, and env-var scoping per environment.
+    stacks: [node, react]
+    sources:
+      - https://github.com/vercel/next.js
+    requires: []
+    conflicts: []
+    absorbs: [deploy-vercel]
+
+  - id: deploy-cloudflare-workers
+    category: devops-cicd
+    tier: capability
+    status: proposed
+    choiceSet: deploy-target
+    what: >-
+      wrangler.toml with bindings for D1/KV/R2/Durable Objects, and the Workers runtime
+      constraints that force an edge-compatible design from the first commit rather than later.
+    stacks: [edge, cloudflare, typescript]
+    sources:
+      - https://github.com/cloudflare/workers-sdk
+      - https://github.com/honojs/hono
+    requires: []
+    conflicts: []
+    absorbs: [deploy-cloudflare-workers, runtime-edge-worker, edge-durable-objects]
+
+  - id: deploy-fly-io
+    category: devops-cicd
+    tier: capability
+    status: proposed
+    choiceSet: deploy-target
+    what: fly.toml with health checks, rolling deploys and a release command for migrations.
+    stacks: [any]
+    sources:
+      - https://github.com/epicweb-dev/epic-stack
+    requires: [docker]
+    conflicts: []
+    absorbs: [deploy-fly-io]
+
+  - id: infra-dotnet-aspire
+    category: devops-cicd
+    tier: specialist
+    status: proposed
+    what: >-
+      .NET Aspire AppHost as the local composition root, with ServiceDefaults carrying OTel,
+      health checks and resilience into every project.
+    stacks: [dotnet]
+    sources:
+      - https://github.com/microsoft/aspire
+      - https://github.com/dotnet/eShop
+    requires: []
+    conflicts: [observability-otel]
+    absorbs: [infra-aspire-apphost]
+    note: >-
+      The conflict with observability-otel is recorded in the shipped observability-otel
+      blueprint (`conflicts: [dotnet-aspire]`) and is real - ServiceDefaults already wires OTel,
+      so both layers would configure the same pipeline twice.
+
+  - id: scaffold-cli-generator
+    category: fullstack-saas
+    tier: specialist
+    status: proposed
+    what: >-
+      Groundplan's own reflection point - the prompt/template/post-generation-hook loop these
+      generators all implement. create-t3-app and the Flutter/RN template generators are the
+      closest prior art to what Groundplan itself is.
+    stacks: [node, typescript]
+    sources:
+      - https://github.com/t3-oss/create-t3-app
+      - https://github.com/devcontainers/features
+    requires: []
+    conflicts: []
+    absorbs:
+      [scaffold-cli-generator, generator-template-registry, generator-base-overlay-templates,
+       generator-adapter-per-framework, generator-post-gen-hooks,
+       generator-idempotent-feature-batteries, component-registry-cli]
+    note: >-
+      Read this one for Groundplan's own design, not to emit into a generated repo. The
+      devcontainers/features `installsAfter` ordering and the shadcn registry format are the two
+      most directly applicable artifacts in the entire catalog.