@opengroundplan/core 0.1.1

package/catalog/sources/testing.yaml

@@ -0,0 +1,652 @@
+# Groundplan template catalog - source research
+# category: testing
+# researched: 2026-07-19
+#
+# VERIFICATION METHOD - READ THIS FIRST
+# The GitHub REST API rate-limit window (60 req/hr, unauthenticated) was exhausted partway
+# through this pass, so two independent methods were used and cross-checked:
+#   1. https://api.github.com/repos/{owner}/{repo} -> stargazers_count, license.spdx_id,
+#      pushed_at, archived. Used for the first 24 candidates.
+#   2. github.com repo HTML (repo-stars-counter-star title attribute) + the default-branch
+#      commits.atom feed. Used for the remainder.
+# Both methods were run against microsoft/playwright and agreed exactly (93087 stars,
+# 2026-07-17), so the HTML/atom figures are treated as sound.
+#
+# lastCommit is the DEFAULT-BRANCH commit date from commits.atom, which is stricter than the
+# API's pushed_at (pushed_at counts any branch). Where the two differ by a day or two, the
+# atom date is recorded.
+#
+# License: every entry's license was read from the repository's actual LICENSE file via
+# raw.githubusercontent.com, not from the API's inferred spdx_id and not from memory. Three
+# API NOASSERTION values resolved to ordinary permissive licenses once the text was read
+# (xunit, pact-js, hypothesis) and one repo's real license contradicts its reputation
+# outright (fluentassertions). See licenseSurprises.
+#
+# licenseClass: vendorable = MIT/Apache-2.0/BSD/ISC/Unlicense/CC0/0BSD (copy and adapt, with
+#   attribution where the license requires it - Apache-2.0 and BSD need the notice);
+#   reference-only = MPL-2.0/LGPL/EPL (read for ideas, do not copy files);
+#   excluded = GPL/AGPL/SSPL/BUSL/source-available/unlicensed.
+# maintained = not archived AND default-branch commit within 18 months of the research date.
+#
+# ADVERSARIAL RE-VERIFICATION PASS - 2026-07-19
+# The GitHub REST API was rate-limited (403, 0/60 remaining) for the whole of this pass, so
+# every figure below was re-checked through API-independent endpoints:
+#   - stars + archived state: github.com repo HTML (repo-stars-counter aria-label)
+#   - lastCommit: default-branch commits.atom
+#   - licence: raw.githubusercontent.com LICENSE text, read in full and pattern-classified,
+#     for all 15 entries and all 14 dropped/bench candidates - not the API's spdx_id
+#   - default branch: git ls-remote --symref, cross-checked against git ls-remote --heads
+# Result: all 15 licences confirmed against the recorded spdx (0 mismatches, 0 drops). All 15
+# lastCommit dates matched exactly; 14 of 15 star counts matched exactly and playwright had
+# drifted 93087 -> 93088 (updated). No entry is archived or disabled; every URL returns 200.
+# Every file and directory named in whatToBorrow was probed and resolves, including the two
+# absences the entries explicitly assert (no root cypress.config.ts, no root vitest.config.ts).
+# The vitest examples/ listing matches the entry's claim exactly (basic, fastify,
+# in-source-test, lit, opentelemetry, profiling, projects, typecheck).
+# Corrected: the coveragepy default-branch note was inverted (it is `main`, not `master`), and
+# four master-only repos that the file's own convention says to flag were unflagged. See the
+# per-entry whatToAvoid text.
+
+category: testing
+
+sources:
+  - name: "microsoft/playwright"
+    url: "https://github.com/microsoft/playwright"
+    stars: 93088
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: "TypeScript/Node - cross-browser E2E runner, test fixtures, tracing, CI sharding"
+    complexity: enterprise
+    portability: "Config and fixture patterns are framework-agnostic; the browser download step needs network or a pinned image, which is the main CI-portability constraint."
+    proposedLayerIds:
+      - testing-e2e-playwright
+      - testing-e2e-fixtures
+      - testing-browser-docker-image
+      - ci-test-sharding
+      - testing-trace-artifacts
+    whatToBorrow: >-
+      The single best source for an E2E layer. Take tests/playwright-test/playwright.config.ts
+      as the canonical multi-project config - it is the repo's own runner config, so it shows
+      projects/, per-project `use` overrides and reporter wiring on a real workload rather than
+      a doc snippet. packages/playwright/types/test.d.ts is the authoritative surface for what
+      a config and a fixture may legally contain; read it when generating configs so the
+      generated file typechecks instead of guessing option names. utils/docker/Dockerfile.noble
+      is the browser-dependencies image recipe - vendor it (or the published
+      mcr.microsoft.com/playwright tag it produces) so CI does not reinstall system libs on
+      every run. .github/workflows/tests_primary.yml is the matrix-sharding reference: it fans
+      the suite across OS x browser x shard and is directly adaptable into a generated repo's
+      e2e workflow. The fixture model (test.extend with worker- vs test-scoped fixtures) is the
+      pattern to encode as the layer's default, not raw beforeEach hooks.
+    whatToAvoid: >-
+      Do not vendor the repo itself - it is a browser-automation monorepo with patched browser
+      builds under browser_patches/, and packages/ contains the shipped product. Copy config
+      and workflow shapes only. Playwright's own tests use internal helpers from tests/config/
+      that are not public API and will not resolve outside the monorepo. Also avoid making the
+      generated template pin @playwright/test and the browser image to different versions -
+      they must move together or CI breaks in a way that looks like a flaky test.
+
+  - name: "cypress-io/cypress"
+    url: "https://github.com/cypress-io/cypress"
+    stars: 50608
+    spdx: "MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: "TypeScript/Node monorepo - E2E + component testing runner, Electron app, dev-server adapters"
+    complexity: professional
+    portability: "Component-testing adapters are framework-coupled (React/Vue/Angular/Svelte); the E2E half is portable to any served app."
+    proposedLayerIds:
+      - testing-e2e-cypress
+      - testing-component-cypress
+      - testing-dev-server-adapter
+      - ci-test-sharding
+    whatToBorrow: >-
+      The component-testing story is what Playwright does not have, and it lives in npm/ - each
+      of npm/react, npm/vue, npm/angular, npm/mount-utils, npm/webpack-dev-server and
+      npm/vite-dev-server is a self-contained adapter showing how to boot the app's real bundler
+      inside the test runner. That mount-plus-dev-server pattern is the thing to adapt for a
+      component-test layer. system-tests/ is the more interesting half for template work: it is
+      a corpus of complete miniature projects, each with its own config, run against the real
+      binary - exactly the shape a generated template's smoke-test suite should take, and
+      system-tests/README.md explains the harness. Root docker-compose.yml plus .circleci/ show
+      a containerised CI run of a browser suite for teams not on GitHub Actions.
+    whatToAvoid: >-
+      Do not adopt Cypress as the default E2E layer for new templates without a reason -
+      Playwright has the better cross-browser story, parallel model and CI ergonomics; pick
+      Cypress when component testing in the real bundler is the requirement. The repo itself is
+      an Electron application build (electron-builder.json, gulpfile.js, packages/ with ~40
+      internal packages) and is not vendorable as a whole. Note the default branch is `develop`,
+      not `main` - path references that assume main will 404. There is no root cypress.config.ts
+      to copy; the configs live inside system-tests/projects/* and npm/*.
+
+  - name: "vitest-dev/vitest"
+    url: "https://github.com/vitest-dev/vitest"
+    stars: 16858
+    spdx: "MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: "TypeScript - Vite-native unit test runner, v8/istanbul coverage, browser mode, typecheck mode"
+    complexity: standard
+    portability: "Requires a Vite-compatible transform pipeline; outside Vite/Rollup projects Jest remains the better fit."
+    proposedLayerIds:
+      - testing-unit-vitest
+      - testing-vitest-projects
+      - testing-coverage-v8
+      - testing-typecheck-assertions
+      - testing-in-source
+    whatToBorrow: >-
+      examples/ is the layer catalogue, and its CURRENT contents matter because the old
+      react/react-testing-lib examples are gone - as of this pass it holds basic, fastify,
+      in-source-test, lit, opentelemetry, profiling, projects and typecheck. Two are
+      load-bearing for template generation: examples/projects/vitest.config.ts is the
+      monorepo/multi-environment config (the `projects` field that replaced the deprecated
+      `workspace` file - generating a vitest.workspace.ts today produces a deprecation warning),
+      and examples/typecheck shows expectTypeOf/assertType wired through `typecheck.enabled` so
+      type-level regressions fail the suite. examples/in-source-test is the pattern for
+      colocating tests inside source behind `import.meta.vitest`, which pairs with the
+      `define: { 'import.meta.vitest': 'undefined' }` production-build guard. examples/fastify
+      is the closest thing to a backend integration-test template. Root vitest.config.mjs-style
+      configs live per-package under packages/*; read packages/coverage-v8 for how the v8
+      provider is configured rather than inventing thresholds.
+    whatToAvoid: >-
+      Do not generate a vitest.workspace.ts - it is the superseded API; use `projects` inside
+      vitest.config.ts. Browser mode is powerful but pulls in a real browser and a provider
+      (playwright or webdriverio), so it should be its own opt-in layer, never the default unit
+      layer. v8 coverage is fast but its remapping is less exact than istanbul on heavily
+      transformed code; do not hard-fail a template on a 100% v8 threshold. There is no root
+      vitest.config.ts in this monorepo - references to one will 404.
+
+  - name: "jestjs/jest"
+    url: "https://github.com/jestjs/jest"
+    stars: 45459
+    spdx: "MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-06-24"
+    archived: false
+    stack: "TypeScript/Node monorepo - test runner, snapshot engine, module mocking, projects config"
+    complexity: professional
+    portability: "Runner-agnostic patterns (snapshots, projects, custom environments) transfer to Vitest with small renames."
+    proposedLayerIds:
+      - testing-unit-jest
+      - testing-snapshot
+      - testing-monorepo-projects
+      - testing-custom-environment
+    whatToBorrow: >-
+      examples/ is a ready-made set of starter configs per stack - examples/typescript,
+      examples/react, examples/angular, examples/snapshot and friends each ship a package.json
+      plus config that can be lifted almost verbatim into a generated repo. Root jest.config.mjs
+      is the reference for the `projects` array (Jest's multi-package pattern, the direct
+      analogue of Vitest's projects) together with transform, moduleNameMapper and
+      coverageThreshold on a real monorepo. packages/jest-snapshot is the place to read before
+      writing any snapshot-testing guidance - the serializer registration and obsolete-snapshot
+      handling are the parts teams get wrong. packages/jest-environment-node and
+      packages/jest-environment-jsdom show the custom-environment contract when a template needs
+      a non-standard global setup (e.g. a seeded DB handle on globalThis).
+    whatToAvoid: >-
+      Jest is still the right default for React Native, Angular CLI and non-Vite Node projects,
+      but for anything already on Vite it adds a second, redundant transform pipeline - do not
+      generate both. ESM support remains behind a flag and is the single largest source of
+      "works locally, breaks in CI" reports; a generated template that is ESM-first should
+      prefer Vitest. Automatic module mocking (`automock`) is legacy - do not enable it. The
+      examples/ directory is convenience code, not a maintained product surface, so pin the
+      dependency versions you copy rather than assuming they track the current release.
+
+  - name: "mswjs/msw"
+    url: "https://github.com/mswjs/msw"
+    stars: 18076
+    spdx: "MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-08"
+    archived: false
+    stack: "TypeScript - network-layer API mocking via Service Worker (browser) and interceptors (Node)"
+    complexity: simple
+    portability: "Highest portability in this catalog - the same handler file serves unit tests, component tests, E2E and the dev server, in any JS framework."
+    proposedLayerIds:
+      - testing-http-mock-msw
+      - testing-msw-node-setup
+      - testing-msw-browser-worker
+      - testing-fixtures-handlers
+    whatToBorrow: >-
+      The cleanest single-concern layer in this category and the easiest to strip down.
+      src/mockServiceWorker.js is the literal artifact that must land in the generated repo's
+      public/ directory - the `msw init` step just copies it, so a template can vendor it and
+      skip the postinstall entirely (re-copy it on every msw upgrade). The repo's own test tree
+      is the setup reference and is split by runtime: test/node holds the setupServer patterns,
+      test/browser the setupWorker patterns, test/native the React Native path, and
+      test/modules the ESM/CJS resolution checks - copy the shape of whichever runtime the
+      template targets. test/support and test/fixtures show how to keep handlers reusable across
+      suites, which is the pattern worth encoding: one handlers.ts exported to both the test
+      setup file and the dev entrypoint so mocks never drift from what the app sees.
+    whatToAvoid: >-
+      Do not let the mock layer become the contract - MSW handlers are hand-written and will
+      silently diverge from the real API; pair it with a schema or contract layer
+      (testing-contract-pact / testing-contract-openapi-schemathesis) rather than treating green
+      MSW tests as integration coverage. Do not ship the service worker file to production
+      builds. onUnhandledRequest defaults to a warning; a template should set it to 'error' in
+      tests so an unmocked call fails loudly instead of hitting the network. The v1-to-v2 API
+      change (rest -> http, res(ctx.json()) -> HttpResponse.json()) means most tutorial code
+      found online is wrong for current versions.
+
+  - name: "testcontainers/testcontainers-node"
+    url: "https://github.com/testcontainers/testcontainers-node"
+    stars: 2572
+    spdx: "MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-13"
+    archived: false
+    stack: "TypeScript/Node - throwaway Docker containers as test fixtures, ~40 prebuilt service modules"
+    complexity: standard
+    portability: "Needs a working Docker (or compatible) socket in CI; everything else is portable across Node test runners."
+    proposedLayerIds:
+      - testing-integration-testcontainers-node
+      - testing-db-ephemeral
+      - testing-compose-fixtures
+      - testing-integration-setup-teardown
+    whatToBorrow: >-
+      packages/modules/ is a catalogue of ~40 ready service fixtures - postgresql, redis, kafka,
+      mongodb, localstack, elasticsearch, clickhouse, cockroachdb, k3s, azurite,
+      azurecosmosdb, chromadb and more - and each module directory is a small, self-contained
+      pattern: a container class with the wait strategy and connection-URI builder already
+      solved. Lift the one module a template needs rather than writing raw docker commands; the
+      wait strategies are the hard-won part. packages/testcontainers/src holds the generic
+      GenericContainer and the DockerComposeEnvironment API for templates that already have a
+      compose file and want to reuse it as the test fixture. The repo's own root
+      docker-compose.yml and .devcontainer/ show running the suite inside a container that
+      itself talks to the host Docker socket - the exact configuration a generated devcontainer
+      needs to make integration tests work.
+    whatToAvoid: >-
+      Container startup is measured in seconds, so this must be a separate npm script and a
+      separate CI job from the unit layer, never folded into the default `test` script. Reuse
+      (withReuse / testcontainers.reuse.enable) speeds up local loops but leaks state between
+      runs and is a bad default for CI. Do not assume a Docker socket exists - hosted runners
+      differ, and Podman/Colima/Rancher need TESTCONTAINERS_* environment overrides, so the
+      layer must document the socket requirement and fail with a clear message rather than a
+      timeout. Pin image tags: `postgres:latest` in a fixture makes the suite non-reproducible.
+
+  - name: "testcontainers/testcontainers-dotnet"
+    url: "https://github.com/testcontainers/testcontainers-dotnet"
+    stars: 4334
+    spdx: "MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: ".NET / C# - ephemeral Docker fixtures, xUnit/NUnit integration, ASP.NET Core integration testing"
+    complexity: professional
+    portability: "Docker-socket dependent like the Node port; the WebApplicationFactory + fixture pattern transfers to any ASP.NET Core service."
+    proposedLayerIds:
+      - testing-integration-testcontainers-dotnet
+      - testing-webapplicationfactory
+      - testing-db-migrations-flyway
+      - testing-db-reset-respawn
+      - testing-integration-dotnet
+    whatToBorrow: >-
+      examples/ is the reason to pick this over the Java port for template work - it contains
+      three complete, small, runnable reference applications rather than library internals:
+      examples/WeatherForecast (an ASP.NET Core API wired to a containerised database and tested
+      end to end), examples/Flyway (running real schema migrations against the throwaway
+      container before the suite, which is the missing half of most integration-test templates)
+      and examples/Respawn (resetting database state between tests instead of recreating the
+      container, the pattern that makes a .NET integration suite fast enough to keep). At repo
+      root, Directory.Build.props and Directory.Packages.props are a clean Central Package
+      Management setup worth copying into any generated .NET solution, and compose.yml plus
+      .devcontainer/ cover the containerised-CI case. The default branch is `develop`.
+    whatToAvoid: >-
+      src/ is the shipped library (one project per service module) - read it, do not vendor it;
+      consume the NuGet packages. The build/ + cake.config + build.ps1 Cake pipeline is
+      project-specific ceremony that should not follow the examples into a template. Same
+      Docker-socket and pinned-tag caveats as the Node port. Do not combine Respawn-style state
+      reset with parallel xUnit collections without disabling parallelisation on the affected
+      collection - it produces exactly the kind of intermittent failure that erodes trust in the
+      suite.
+
+  - name: "pact-foundation/pact-js"
+    url: "https://github.com/pact-foundation/pact-js"
+    stars: 1791
+    spdx: "MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-15"
+    archived: false
+    stack: "TypeScript/Node - consumer-driven contract testing (Pact v3/v4), Rust core bindings"
+    complexity: professional
+    portability: "The consumer/provider split is language-agnostic; pact files are portable across every Pact implementation, so a polyglot template can mix pact-js with pact-jvm or pact-python."
+    proposedLayerIds:
+      - testing-contract-pact
+      - testing-contract-consumer
+      - testing-contract-provider-verification
+      - testing-contract-messaging
+      - ci-contract-broker-publish
+    whatToBorrow: >-
+      examples/ is unusually well-organised and maps one-to-one onto layer variants:
+      examples/http (the baseline consumer + provider pair), examples/messages (async/event
+      contracts, the case most contract-testing guides skip), examples/provider-state (state
+      handlers, which is where real provider verification actually lives), examples/matchers
+      (flexible matching so contracts assert shape rather than exact values - the difference
+      between a useful contract and a brittle one), examples/graphql, examples/xml and
+      examples/multipart. examples/vitest.config.ts shows the runner wiring for the whole
+      example set and is the file to adapt when generating a contract-test script. Dockerfile.
+      alpine and Dockerfile.debian at repo root document the native-binary requirements for
+      running Pact in a slim CI image - worth copying the base-image choice.
+    whatToAvoid: >-
+      Contract testing only pays off with two independently deployed services and a broker; for
+      a single app it is pure overhead and the layer should not be offered by default. The Rust
+      core means native binaries - musl/Alpine and ARM builds have historically lagged, so pin
+      the image and do not assume a random CI runner works. Do not generate a self-hosted
+      pact-broker as part of this layer (that is a separate service with its own database);
+      target an existing broker URL through config. The v2-to-v3 API shift (PactV3, message
+      pacts) makes older examples misleading - use only the examples/ tree from the current
+      default branch, which is `master` (there is no `main` ref, so `main` paths 404).
+
+  - name: "pytest-dev/pytest"
+    url: "https://github.com/pytest-dev/pytest"
+    stars: 14346
+    spdx: "MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-13"
+    archived: false
+    stack: "Python - test framework, fixture system, plugin architecture, parametrisation"
+    complexity: professional
+    portability: "conftest/fixture layout and the src-layout convention transfer to every Python project regardless of framework."
+    proposedLayerIds:
+      - testing-unit-pytest
+      - testing-pytest-fixtures
+      - testing-pytest-plugin
+      - testing-matrix-tox
+      - testing-python-layout
+    whatToBorrow: >-
+      doc/en/example/ is the highest-value directory in the repo for template generation - it is
+      a curated set of runnable layouts (parametrisation, fixture scoping, marker usage,
+      simple/ and special/ directory conventions) written specifically to be copied, with
+      doc/en/example/index.rst as the map. The repo's own testing/ directory plus root
+      pyproject.toml is the reference for the modern configuration shape: [tool.pytest.ini_options]
+      with testpaths, addopts, xfail_strict and filterwarnings set to error - that last pair is
+      the setting that keeps a generated suite honest as dependencies drift. src/_pytest/fixtures.py
+      is the authority on fixture scope and finalisation semantics when a template needs
+      session-scoped resources. Root tox.ini shows the interpreter-matrix layout that pairs with
+      a CI matrix. The src/ + testing/ split is itself the layout to generate.
+    whatToAvoid: >-
+      Do not vendor src/_pytest - it is the framework. Avoid deep conftest.py hierarchies in a
+      generated template: fixtures resolve by directory proximity and a three-level conftest
+      chain is unreadable to anyone who did not write it; keep one root conftest.py plus at most
+      one per test package. Do not enable `-p no:randomly`-style plugin juggling or a long
+      addopts string by default - every flag in addopts is a flag the user cannot easily turn
+      off. Bare `assert` is idiomatic here and needs no assertion library; do not generate an
+      unittest.TestCase class hierarchy alongside it.
+
+  - name: "xunit/xunit"
+    url: "https://github.com/xunit/xunit"
+    stars: 4591
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-03-23"
+    archived: false
+    stack: ".NET / C# - xUnit.net v3 test framework, in-process runner, MTP integration"
+    complexity: professional
+    portability: "Conventions (constructor setup, IAsyncLifetime, collection fixtures) map cleanly onto NUnit/MSTest equivalents if a template needs a different runner."
+    proposedLayerIds:
+      - testing-unit-xunit
+      - testing-dotnet-conventions
+      - testing-fixtures-dotnet
+      - testing-parallel-collections
+    whatToBorrow: >-
+      The v3 project layout under src/ is the reference for a modern .NET test setup -
+      src/xunit.v3.core/xunit.v3.core.csproj shows the current package/TFM targeting, and the
+      v3 shift matters for template generation because a v3 test project is an executable, not a
+      library, so the generated .csproj needs OutputType Exe and the v3 runner package rather
+      than the old xunit.runner.visualstudio arrangement. Copy the fixture conventions rather
+      than files: constructor + IDisposable for per-test setup, IAsyncLifetime for async setup,
+      IClassFixture for per-class shared state, ICollectionFixture plus [Collection] for
+      cross-class shared state and for opting specific suites out of parallel execution. Root
+      Directory.Build.props-equivalents (.config/, global.json, version.json) show pinning the
+      SDK and tool versions so a generated solution builds identically on every machine.
+    whatToAvoid: >-
+      Do not vendor src/ - consume the NuGet packages. Do not mix v2 and v3 packages in one
+      solution; the runner story is different and the failure mode is "no tests discovered",
+      which reads as a broken template. The docfx/ site and build.ps1 pipeline are
+      project-specific. Note this is the least recently touched entry in this catalog
+      (2026-03-23) - still comfortably maintained, but recheck before the next pass. Also do not
+      pair xUnit with FluentAssertions in a generated commercial template: FluentAssertions'
+      current licence is not open source (see licenseSurprises); use xUnit's built-in Assert,
+      Shouldly or AwesomeAssertions instead.
+
+  - name: "stryker-mutator/stryker-js"
+    url: "https://github.com/stryker-mutator/stryker-js"
+    stars: 2951
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: "TypeScript/Node - mutation testing, per-runner plugins (jest, vitest, mocha, jasmine, karma, cucumber)"
+    complexity: standard
+    portability: "Runner plugins mean it drops onto an existing suite without changing test code; the concept ports to stryker-net and mutmut for other stacks."
+    proposedLayerIds:
+      - testing-mutation-stryker
+      - testing-mutation-ci-gate
+      - testing-incremental-analysis
+    whatToBorrow: >-
+      e2e/test/ is a corpus of ~60 complete miniature projects, one per supported configuration,
+      and it is the best available answer to "what does a correct stryker.conf.json look like
+      for MY runner" - e2e/test/jest-node/stryker.conf.json is a working baseline, with siblings
+      covering jest-with-ts, jest-react-testing-library-ts, jest-custom-env, jasmine-ts,
+      cucumber-ts, karma-jasmine-e2e, angular-project, esm, babel-transpiling and more. Three
+      of those directories encode settings that make mutation testing survivable in CI rather
+      than a nightly-only luxury: e2e/test/incremental (reuse the previous run's results so only
+      changed code is re-mutated), e2e/test/coverage-analysis (perTest coverage analysis, the
+      single biggest runtime reduction) and e2e/test/ignore-static / e2e/test/hit-limit
+      (bounding pathological mutants). packages/vitest-runner and packages/jest-runner document
+      the runner-plugin contract. e2e/helpers.js shows asserting on a mutation score in CI.
+    whatToAvoid: >-
+      Mutation testing is order-of-magnitude slower than the underlying suite - never wire it
+      into the default test script or a per-PR required check on a large codebase; gate it on a
+      schedule or on changed files via incremental mode. Do not set a high mutation-score
+      threshold in a generated template; an aspirational break-on-score turns a useful signal
+      into a blocked pipeline on day one. Equivalent mutants mean 100% is unreachable by
+      definition. The e2e projects pin deliberately old dependency versions to prove
+      compatibility - copy the config shape, not the package.json. The default branch is
+      `master` (no `main` ref exists), so `main` path references will 404.
+
+  - name: "dubzzz/fast-check"
+    url: "https://github.com/dubzzz/fast-check"
+    stars: 5069
+    spdx: "MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-17"
+    archived: false
+    stack: "TypeScript - property-based testing, arbitraries, shrinking, model-based testing; runner-agnostic"
+    complexity: standard
+    portability: "Runner-agnostic by design - the same properties run under Vitest, Jest, Mocha or node:test with no adapter."
+    proposedLayerIds:
+      - testing-property-fast-check
+      - testing-model-based
+      - testing-fuzz-inputs
+      - testing-seeded-replay
+    whatToBorrow: >-
+      examples/ is small and deliberately pedagogical, and each numbered directory is a distinct
+      layer variant: examples/001-simple (basic properties over pure functions),
+      examples/002-recursive/isSearchTree (recursive data-structure arbitraries, the case that
+      teaches custom arbitrary composition), examples/004-stateMachine/musicPlayer (model-based
+      testing - generating command sequences against a model, which is where property testing
+      earns its keep on stateful code) and examples/005-race (detecting race conditions via
+      scheduler-based interleaving, a capability nothing else in this catalog provides).
+      examples/vitest.setup.ts plus examples/package.json show the minimal runner wiring, and
+      root vitest.config.mjs plus pnpm-workspace.yaml show the monorepo arrangement. Borrow the
+      seed/path reporting convention: a failing property prints a seed that reproduces it
+      exactly, and a generated template should surface that in its CI failure output.
+    whatToAvoid: >-
+      Do not make property tests the default unit layer - they are slow relative to example
+      tests and are the wrong tool for I/O-heavy or UI code. Unbounded runs make CI duration
+      nondeterministic; set numRuns explicitly in the generated config. Do not commit a fixed
+      global seed to make CI "stable" - that discards the entire point; instead capture the
+      failing seed into a regression example test. packages/ is the shipped library and should
+      be consumed from npm, not vendored.
+
+  - name: "schemathesis/schemathesis"
+    url: "https://github.com/schemathesis/schemathesis"
+    stars: 3474
+    spdx: "MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-19"
+    archived: false
+    stack: "Python + Rust core - property-based API testing driven from OpenAPI/GraphQL schemas; CLI and pytest integration"
+    complexity: standard
+    portability: "Language-agnostic in use - it tests any HTTP service from its schema, so a Python-based test job can guard a Node, Go or .NET API."
+    proposedLayerIds:
+      - testing-contract-openapi-schemathesis
+      - testing-api-fuzz
+      - testing-property-python
+      - ci-api-conformance
+    whatToBorrow: >-
+      The most under-used layer in this category: it turns an OpenAPI document into a generated
+      conformance suite with no hand-written cases, which is the cheapest real coverage a
+      generated API template can ship. examples/booking is a complete worked service showing the
+      schema-plus-tests arrangement to copy. Dockerfile and Dockerfile.trixie make it usable as
+      a CI step against any stack without installing Python into the app image - that is the
+      form the layer should take for non-Python templates. .github/workflows/build.yml shows the
+      CI invocation, codecov.yml the coverage upload, and ARCHITECTURE.md is genuinely worth
+      reading before wiring the pytest integration (it explains how checks, phases and the
+      Hypothesis-backed generation relate). Root pyproject.toml plus tox.ini are a clean modern
+      Python packaging/matrix reference in their own right.
+    whatToAvoid: >-
+      It is only as good as the schema - a loose or hand-maintained OpenAPI document produces
+      either noise or false confidence, so this layer belongs with schema-first templates
+      (FastAPI, NestJS + generated spec, ASP.NET Core minimal APIs with OpenAPI). Default
+      generation will happily send destructive requests, so never point it at a shared
+      environment; scope it to an ephemeral instance, ideally the Testcontainers layer. Full
+      stateful/all-checks runs are slow enough to warrant their own CI job. Note it builds on
+      Hypothesis, which is MPL-2.0 (reference-only) - that does not affect using schemathesis,
+      but do not copy Hypothesis source into a generated repo. The default branch is `master`
+      (no `main` ref exists), so `main` path references will 404.
+
+  - name: "locustio/locust"
+    url: "https://github.com/locustio/locust"
+    stars: 28007
+    spdx: "MIT"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-18"
+    archived: false
+    stack: "Python - distributed load testing, scenarios as plain Python, web UI, master/worker scaling"
+    complexity: simple
+    portability: "The permissively-licensed load-testing option - unlike k6 (AGPL-3.0), locustfiles and the harness can be vendored into a generated repo."
+    proposedLayerIds:
+      - testing-load-locust
+      - testing-load-distributed
+      - ci-load-smoke
+      - testing-load-docker
+    whatToBorrow: >-
+      examples/ is a flat, copy-ready library of locustfiles - examples/basic.py and
+      examples/locustfile.py are the strip-down-to-nothing starting points that make this the
+      `simple` rung of the load-testing ladder. The ones that matter for a template:
+      examples/docker-compose/docker-compose.yml (master + workers as a compose stack, the
+      distributed pattern without Kubernetes), examples/custom_shape/ (LoadTestShape classes for
+      ramp/step/spike profiles instead of a flat user count - this is what turns a smoke check
+      into a real load profile), examples/csrf_form_authentication.py and
+      examples/dynamic_user_credentials.py (authenticated scenarios, the part every load-test
+      template gets stuck on), examples/fast_http_locust.py (FastHttpUser for high throughput
+      per worker) and examples/grpc/ for non-HTTP protocols. Root Dockerfile, Dockerfile.ci and
+      Dockerfile.otel give a containerised runner plus an OpenTelemetry-exporting variant that
+      plugs straight into an existing observability layer. .coveragerc and .pre-commit-config.yaml
+      are reusable Python hygiene files.
+    whatToAvoid: >-
+      Do not run real load in a PR pipeline - generate a short, low-user smoke run for CI and
+      keep the full profile as a manually dispatched or scheduled workflow. Locust is
+      gevent-based: CPU-bound custom code inside a task blocks the greenlet and produces
+      throughput numbers that measure the load generator rather than the service; a single
+      worker process saturates around one core, so scale with workers, not users. Numbers from a
+      shared CI runner are not capacity-planning data. Do not point a generated load test at a
+      production host by default - make the target host a required config value with no default.
+      The default branch is `master` (no `main` ref exists), so `main` path references will 404.
+
+  - name: "nedbat/coveragepy"
+    url: "https://github.com/nedbat/coveragepy"
+    stars: 3393
+    spdx: "Apache-2.0"
+    licenseClass: vendorable
+    maintained: true
+    lastCommit: "2026-07-16"
+    archived: false
+    stack: "Python - statement/branch coverage measurement, combine/report/gate workflow, sys.monitoring core"
+    complexity: simple
+    portability: "The parallel-then-combine-then-gate workflow is the same shape in every language's coverage tool; the CI job design transfers directly."
+    proposedLayerIds:
+      - testing-coverage-python
+      - testing-coverage-gate
+      - testing-matrix-tox
+      - ci-coverage-report
+    whatToBorrow: >-
+      Read the repo's measurement of ITSELF, not the library - it is the most rigorous coverage
+      configuration available to copy. metacov.ini is the meta-coverage config and shows the
+      full parallel/combine arrangement (measuring coverage across a matrix of interpreters and
+      merging the results) that most projects get wrong by uploading one shard's data.
+      .github/workflows/coverage.yml is the matching CI job: run per-matrix-entry, upload the
+      partial .coverage data as artifacts, combine in a final job, then report and fail on the
+      threshold - that four-step shape is the layer. Root pyproject.toml holds the ordinary
+      [tool.coverage.run] / [tool.coverage.report] settings worth generating (branch coverage
+      on, source set, exclude_lines, fail_under). tox.ini shows the interpreter matrix, and
+      igor.py is a readable example of a repo-local task-runner script for the combine step.
+    whatToAvoid: >-
+      Do not generate fail_under = 100 - the correct starting value is roughly the project's
+      current number, ratcheted upward; a threshold nobody can meet gets deleted rather than
+      met. Coverage percentage is not test quality; pair the gate with the mutation layer if the
+      question is "are these tests any good". Parallel mode without a combine step silently
+      reports only the last shard, which looks like a coverage collapse. Do not vendor
+      coverage/ - it contains a C extension (and a sys.monitoring path) and must be installed,
+      not copied. The default branch is `main` (the repo was renamed from `master`; legacy
+      `master` URLs still resolve only because GitHub redirects them, and no `master` ref
+      exists) - generate `main` paths.
+
+droppedCandidates:
+  - "grafana/k6 (31050 stars) — AGPL-3.0, confirmed from LICENSE.md text. Excluded: the standard JS load-testing tool, and the one most people assume is permissive, but vendoring it or shipping derived scripts as part of a template would propagate AGPL terms. locustio/locust (MIT) and gatling/gatling (Apache-2.0) fill the load-testing slot instead."
+  - "HypothesisWorks/hypothesis (8790 stars) — LICENSE.txt is Mozilla Public License 2.0 (API reported NOASSERTION). reference-only: read the strategy/shrinking design, copy no files. Its capability reaches the catalog indirectly through schemathesis, which is MIT and built on it."
+  - "artilleryio/artillery (9027 stars) — MPL-2.0. reference-only; the YAML scenario format and phase/ramp model are worth studying, but no files may be copied. Locust covers the same need under MIT."
+  - "fluentassertions/fluentassertions (3818 stars) — LICENSE is the XCEED SOFTWARE INC. COMMUNITY LICENSE AGREEMENT, non-commercial use only. Excluded, and called out in licenseSurprises: this is the default assertion library in a large share of existing .NET codebases and is still widely believed to be Apache-2.0."
+  - "epicweb-dev/full-stack-testing (220 stars) — LICENSE.md is GPL-3.0 restricted to private, non-commercial use. Excluded despite being an excellent Playwright/Vitest/MSW reference workshop."
+  - "goldbergyoni/nodejs-testing-best-practices (4376 stars) — no root LICENSE file found on main or master under any common filename, and no licence shown in the repo sidebar; therefore all rights reserved. Excluded. Also stale (2025-04-08)."
+  - "mswjs/examples (731 stars) — no root LICENSE file found. Excluded even though it is the natural companion to the msw entry; use the msw repo's own test/ tree for setup patterns instead."
+  - "gatling/gatling (6939 stars, Apache-2.0 verified, 2026-07-01) — permissive and maintained, and the right choice for JVM-heavy templates, but the Scala/Java DSL raises the barrier for a generated template. Strong candidate for a testing-load-gatling layer in a JVM pass."
+  - "karatelabs/karate (8903 stars, MIT verified, 2026-07-18) — combined API/contract/load DSL, permissive and very active. Held back only because its single-DSL approach overlaps three layers here; revisit if a JVM-first template family is added."
+  - "wiremock/wiremock (7298 stars, Apache-2.0 verified, 2026-07-17) — excellent JVM-side HTTP stubbing and the standalone JAR is genuinely template-friendly. Cut against msw, which covers browser and Node from one handler file. Add for JVM templates as testing-http-mock-wiremock."
+  - "testcontainers/testcontainers-java (8690 stars, MIT verified, 2026-07-17) — the original and largest module ecosystem, but the .NET and Node ports carry better runnable examples/ for template extraction. Include when JVM templates land."
+  - "boxed/mutmut (1351 stars, BSD-3-Clause verified, 2026-07-16) — the Python mutation-testing counterpart to Stryker. Cut for entry budget; a clean addition as testing-mutation-mutmut."
+  - "VerifyTests/Verify (3457 stars, MIT verified — note the licence file is lowercase license.txt, 2026-07-18) — the .NET snapshot-testing standard, with received/verified file conventions and diff-tool integration worth a testing-snapshot-dotnet layer. Cut for budget."
+  - "tox-dev/tox (3911 stars, MIT verified, 2026-07-17) — the Python matrix runner; its patterns are already captured via the tox.ini references in the pytest and coveragepy entries rather than as a standalone source."
+  - "stryker-mutator/stryker-net (2036 stars, Apache-2.0 verified, 2026-07-17), pact-foundation/pact-jvm (1139, Apache-2.0), microsoft/playwright-python (14834), microsoft/playwright-dotnet (2976, MIT), robotframework/robotframework (11759, Apache-2.0), seleniumbase/SeleniumBase (12875, MIT), stretchr/testify (26086, MIT), nunit/nunit (2625, MIT) — all permissive, all maintained, all held as second-tier ports/alternatives of sources already represented above."
+  - "dotnet/eShop (10688 stars, MIT verified, 2026-04-21) — a full reference application with Aspire-based integration tests; strong enterprise material, but it is an application sample rather than a testing source, so it belongs in a fullstack pass."
+
+licenseSurprises:
+  - "fluentassertions/fluentassertions — LICENSE is the Xceed Software Inc. Community License Agreement, granting rights for Non-Commercial Use only. It is not an OSI licence. This is the highest-impact finding in this pass: FluentAssertions is the assumed default assertion library across the .NET ecosystem and is still described as Apache-2.0 in a great deal of documentation. Generated .NET templates must not reference it; use xUnit's built-in Assert, Shouldly, or the AwesomeAssertions fork."
+  - "xunit/xunit — API reported spdx_id NOASSERTION. The LICENSE file opens with 'Unless otherwise noted, the source code here is covered by the following license' before the Apache-2.0 text, which defeats the API's detector. Verified Apache-2.0 by reading the file; vendorable with attribution. The 'unless otherwise noted' clause is real and carries a carve-out: the LICENSE goes on to state that src/xunit.v3.runner.common/Utility/ConsoleHelper.cs was adapted from Microsoft/msbuild and is covered by the MIT License instead. Both licences are permissive so the vendorable classification stands, but anything copied from that path needs the MIT notice, not the Apache-2.0 one."
+  - "pact-foundation/pact-js — API reported spdx_id NOASSERTION. LICENSE is 'The MIT License (MIT)' with a dual 'Original work Copyright (c) 2014 DiUS' / modified-work preamble that trips the detector. Verified MIT."
+  - "HypothesisWorks/hypothesis — API reported spdx_id NOASSERTION. LICENSE.txt states MPL 2.0 for all code except explicitly noted third-party portions. reference-only, not vendorable."
+  - "grafana/k6 — AGPL-3.0. Frequently assumed permissive because it is a Grafana Labs project alongside Apache-2.0 repos such as docker-otel-lgtm. It is not."
+  - "VerifyTests/Verify — MIT, but the licence file is lowercase license.txt, so a probe for LICENSE/LICENSE.md/LICENSE.txt returns 404 and the repo looks unlicensed. A reminder that a missing-licence conclusion needs a case-insensitive check before it is acted on."
+  - "goldbergyoni/nodejs-testing-best-practices and mswjs/examples — both popular, both genuinely have no root LICENSE file. Unlicensed means all rights reserved, not public domain."
+
+notes: >-
+  Coverage by stack after this pass: JS/TS is deep (playwright, cypress, vitest, jest, msw,
+  testcontainers-node, pact-js, stryker-js, fast-check); Python is solid (pytest, coveragepy,
+  locust, schemathesis); .NET has integration and unit coverage (testcontainers-dotnet, xunit)
+  but no snapshot or mutation source — VerifyTests/Verify and stryker-mutator/stryker-net are
+  the obvious first additions. JVM is currently unrepresented: testcontainers-java, wiremock,
+  gatling, karate and pact-jvm are all verified permissive and maintained, and should be picked
+  up together when a JVM template family is added. Go has only stretchr/testify on the bench.
+  The complexity ladder spans msw and coveragepy at the simple end through
+  playwright/cypress/jest at the professional-to-enterprise end, so a generated repo can take a
+  single-file mock layer or a full sharded browser matrix from the same catalog. Two structural
+  gaps remain: no visual-regression source (the Playwright entry covers screenshot assertions
+  but nothing owns baseline management), and no flaky-test detection/quarantine source.