edsger 0.76.0 → 0.78.0

package/assets/benchmark/base.yaml

@@ -0,0 +1,286 @@
+id: base
+name: Universal Engineering Baseline
+version: 0.1.0
+kind: benchmark
+extends: null
+appliesTo: ["*"]
+# Each criterion is scored 0..4. 0 = absent/harmful, 4 = exemplary.
+scoreScale: 4
+
+categories:
+  # ----------------------------------------------------------------------------
+  - id: security
+    name: Security
+    weight: 22
+    description: >
+      Protecting the software, its data, and its users from misuse. Weighted
+      highest because security defects are the most expensive class of failure.
+    criteria:
+      - id: no-hardcoded-secrets
+        title: No secrets committed to the repository
+        weight: 2
+        guidance: >
+          Search source, config, CI files, and history-adjacent files for API
+          keys, passwords, tokens, private keys, and connection strings. Verify
+          secrets are sourced from environment variables or a secret manager and
+          that a .gitignore / secret-scanning setup exists.
+        rubric:
+          excellent: No secrets present; .env is gitignored; secret scanning (e.g. gitleaks/trufflehog or platform scanning) is configured.
+          good: No secrets present and .env files are ignored.
+          adequate: No obvious secrets, but no preventative tooling.
+          poor: Hardcoded credentials or private keys are present.
+        references:
+          - "OWASP ASVS V2 (Authentication) & V6 (Stored Cryptography)"
+          - "https://owasp.org/www-project-top-ten/"
+      - id: input-validation
+        title: Untrusted input is validated and output is encoded
+        guidance: >
+          Check that data crossing trust boundaries (HTTP params, CLI args, file
+          contents, message payloads) is validated, and that queries use
+          parameterisation and output is contextually encoded to prevent
+          injection (SQLi, command injection, XSS, path traversal).
+        rubric:
+          excellent: Centralised validation/escaping; parameterised queries everywhere; no string-built shell/SQL.
+          adequate: Validation present in most entry points but inconsistent.
+          poor: Raw concatenation of untrusted input into queries, shells, or markup.
+        references:
+          - "OWASP Top 10 A03:2021 Injection"
+      - id: dependency-security
+        title: Dependencies are tracked, pinned, and scanned for vulnerabilities
+        guidance: >
+          Confirm a lockfile exists, that there is automated vulnerability
+          scanning (Dependabot/Renovate/audit in CI), and that known-vulnerable
+          or unmaintained dependencies are not in use.
+        rubric:
+          excellent: Lockfile committed; automated update + audit in CI; no known high/critical advisories.
+          adequate: Lockfile present but no automated scanning.
+          poor: No lockfile, or known critical advisories left unaddressed.
+        references:
+          - "OWASP Top 10 A06:2021 Vulnerable and Outdated Components"
+          - "https://slsa.dev/"
+      - id: authz-and-secrets-handling
+        title: Sound authn/authz and least-privilege handling of credentials
+        guidance: >
+          Where the project authenticates users or services, check for sound
+          session/token handling, authorization checks on every privileged
+          action, and least-privilege scopes for tokens and service accounts.
+          For libraries/CLIs, check that credentials are not logged.
+        rubric:
+          excellent: Centralised authz checks; least-privilege tokens; no credential logging.
+          adequate: Authz present but ad hoc; some over-broad scopes.
+          poor: Missing authorization checks or credentials written to logs.
+        references:
+          - "OWASP Top 10 A01:2021 Broken Access Control"
+
+  # ----------------------------------------------------------------------------
+  - id: maintainability
+    name: Maintainability & Code Quality
+    weight: 20
+    description: How easily the code can be understood, changed, and extended.
+    criteria:
+      - id: structure-and-modularity
+        title: Clear structure with cohesive, loosely-coupled modules
+        guidance: >
+          Assess directory layout, separation of concerns, and whether modules
+          have a single clear responsibility. Look for god files, circular
+          dependencies, and leaky abstractions.
+        rubric:
+          excellent: Intuitive layout; small cohesive modules; dependencies flow one direction.
+          adequate: Generally reasonable structure with some large or tangled areas.
+          poor: Monolithic files, tangled dependencies, no discernible architecture.
+      - id: readability-and-naming
+        title: Readable code with meaningful names and consistent style
+        guidance: >
+          Check naming, function length, nesting depth, and the presence of an
+          enforced formatter/linter so style is consistent rather than debated.
+        rubric:
+          excellent: Self-documenting names; small functions; auto-formatted and linted.
+          adequate: Mostly readable; style enforced loosely or not at all.
+          poor: Cryptic names, very long functions, inconsistent style.
+        references:
+          - "https://google.github.io/styleguide/"
+      - id: error-handling
+        title: Robust, intentional error handling
+        guidance: >
+          Verify errors are handled at the right layer, not swallowed; that
+          failures produce actionable messages; and that resources are released
+          on error paths.
+        rubric:
+          excellent: Errors are typed/categorised, surfaced with context, never silently swallowed.
+          adequate: Errors handled but messages are thin or inconsistent.
+          poor: Empty catch blocks, ignored return codes, crashes without context.
+      - id: complexity-and-duplication
+        title: Low duplication and managed complexity
+        guidance: >
+          Look for copy-pasted logic, deeply nested conditionals, and functions
+          doing too much. Reasonable use of abstractions to remove duplication
+          without over-engineering.
+        rubric:
+          excellent: DRY without premature abstraction; complex logic isolated and documented.
+          adequate: Some duplication or hotspots of complexity.
+          poor: Pervasive copy-paste and unmanaged complexity.
+
+  # ----------------------------------------------------------------------------
+  - id: testing
+    name: Testing & Verification
+    weight: 18
+    description: Confidence that the software works and stays working.
+    criteria:
+      - id: test-presence-and-coverage
+        title: Meaningful automated tests covering core logic
+        guidance: >
+          Determine whether a test suite exists, whether it covers the important
+          behaviour (not just trivial getters), and roughly how much of the code
+          base is exercised. Prefer evidence (coverage config/reports) over
+          guessing.
+        rubric:
+          excellent: Comprehensive tests on critical paths; coverage measured and reported.
+          good: Solid coverage of core logic.
+          adequate: Some tests but major paths untested.
+          poor: No automated tests.
+      - id: test-quality
+        title: Tests are deterministic, isolated, and assert behaviour
+        guidance: >
+          Check for flaky patterns (real network/time/sleep dependence), shared
+          mutable state between tests, and assertions that actually verify
+          behaviour rather than just executing code.
+        rubric:
+          excellent: Fast, deterministic, isolated tests with clear assertions.
+          adequate: Tests work but are slow, order-dependent, or shallow.
+          poor: Flaky, networked, or assertion-free tests.
+      - id: tests-run-in-ci
+        title: Tests and checks run automatically on every change
+        guidance: >
+          Confirm CI executes the test suite (and linters/type checks) on pull
+          requests, and that a green pipeline is required.
+        rubric:
+          excellent: CI runs tests + static checks on every PR and is required to merge.
+          adequate: CI exists but is partial or not enforced.
+          poor: No CI, or tests not run automatically.
+
+  # ----------------------------------------------------------------------------
+  - id: documentation
+    name: Documentation & Onboarding
+    weight: 12
+    description: How quickly a newcomer can understand, run, and contribute.
+    criteria:
+      - id: readme-quality
+        title: README explains what, why, install, and usage
+        guidance: >
+          A good README states the purpose, prerequisites, install steps, a
+          minimal usage example, and where to go next. It should let a newcomer
+          run the project in minutes.
+        rubric:
+          excellent: Purpose, install, runnable examples, configuration, and links to deeper docs.
+          adequate: Basic README with install/usage but gaps.
+          poor: Empty or placeholder README.
+        references:
+          - "https://www.makeareadme.com/"
+      - id: api-and-code-docs
+        title: Public interfaces and non-obvious decisions are documented
+        guidance: >
+          Public APIs/exports carry doc comments; non-obvious decisions are
+          explained (in code comments or docs/ADRs). Comments explain "why",
+          not restate the code.
+        rubric:
+          excellent: Documented public API plus ADRs/design notes for key decisions.
+          adequate: Some doc comments; rationale often missing.
+          poor: No meaningful documentation of interfaces or decisions.
+      - id: contribution-guidance
+        title: Contribution, license, and governance basics are present
+        guidance: >
+          Look for LICENSE, CONTRIBUTING, a code of conduct where appropriate,
+          and clear instructions for the dev setup and how to propose changes.
+        rubric:
+          excellent: LICENSE + CONTRIBUTING + dev setup + change process documented.
+          adequate: LICENSE present; contribution guidance thin.
+          poor: No license or contribution guidance.
+
+  # ----------------------------------------------------------------------------
+  - id: delivery
+    name: Delivery & Operations
+    weight: 16
+    description: Reproducible builds, releases, configuration, and observability.
+    criteria:
+      - id: reproducible-build
+        title: Reproducible, automated build and dependency install
+        guidance: >
+          One documented command should install dependencies and build/run the
+          project. Pinned toolchain/runtime versions and committed lockfiles
+          support reproducibility.
+        rubric:
+          excellent: Single-command setup; pinned toolchain; reproducible from a clean clone.
+          adequate: Build works but requires undocumented manual steps.
+          poor: Build is broken, manual, or undocumented.
+        references:
+          - "https://12factor.net/"
+      - id: config-and-env
+        title: Configuration via environment, separated from code
+        guidance: >
+          Configuration (especially secrets and per-environment values) is read
+          from the environment or config files, not hardcoded, with sane
+          defaults and documentation of required variables.
+        rubric:
+          excellent: Clean config separation; documented env vars; safe defaults.
+          adequate: Mostly externalised config with gaps.
+          poor: Environment-specific values hardcoded in source.
+        references:
+          - "https://12factor.net/config"
+      - id: ci-cd-pipeline
+        title: Automated pipeline for build, test, and release
+        guidance: >
+          Beyond tests, check for an automated path to a release/artifact, and
+          that the pipeline fails the build on lint/type/test errors.
+        rubric:
+          excellent: CI/CD builds, tests, and publishes artifacts/releases automatically.
+          adequate: CI present; release is manual.
+          poor: No automation.
+      - id: observability
+        title: Logging and diagnosability appropriate to the project
+        guidance: >
+          For services: structured logs, error reporting, and health/metrics.
+          For libraries/CLIs: actionable error output and optional debug logging.
+          Avoid logging secrets or PII.
+        rubric:
+          excellent: Structured, levelled logging; no sensitive data; diagnosable failures.
+          adequate: Basic logging present.
+          poor: No logging, or noisy logs leaking sensitive data.
+
+  # ----------------------------------------------------------------------------
+  - id: vcs-hygiene
+    name: Version Control & Release Hygiene
+    weight: 12
+    description: Healthy history, change communication, and dependency upkeep.
+    criteria:
+      - id: commit-and-history
+        title: Clean, meaningful commit history and branching
+        guidance: >
+          Look for descriptive commits (ideally Conventional Commits), absence
+          of committed build artifacts/large binaries, and a sensible .gitignore.
+        rubric:
+          excellent: Descriptive, scoped commits; clean tree; no generated artifacts committed.
+          adequate: Reasonable history with some noise.
+          poor: Uninformative commits ("fix", "wip") and committed build output.
+        references:
+          - "https://www.conventionalcommits.org/"
+      - id: changelog-and-versioning
+        title: Versioning and change communication
+        guidance: >
+          For released software, check for SemVer tags/releases and a changelog
+          (or generated release notes) so consumers understand what changed.
+        rubric:
+          excellent: SemVer releases with a maintained changelog / release notes.
+          adequate: Some tags/releases but no changelog.
+          poor: No versioning or release communication.
+        references:
+          - "https://keepachangelog.com/"
+          - "https://semver.org/"
+      - id: dependency-currency
+        title: Dependencies are reasonably current and maintained
+        guidance: >
+          Check for severely outdated or abandoned dependencies and whether an
+          update mechanism (Renovate/Dependabot) keeps them current.
+        rubric:
+          excellent: Dependencies current; automated update PRs configured.
+          adequate: Mostly current; manual updates.
+          poor: Many years-stale or abandoned dependencies.

package/assets/benchmark/csharp.yaml

@@ -0,0 +1,68 @@
+id: csharp
+name: C# / .NET Overlay
+version: 0.1.0
+kind: benchmark
+extends: base
+appliesTo: [csharp]
+scoreScale: 4
+
+categories:
+  - id: language
+    name: C# / .NET Language Quality
+    weight: 14
+    description: Idiomatic, safe, and well-tooled .NET code.
+    criteria:
+      - id: nullable-and-analyzers
+        title: Nullable reference types and analyzers enabled
+        guidance: >
+          Check the project enables `<Nullable>enable</Nullable>` and
+          `TreatWarningsAsErrors`, and uses analyzers (.editorconfig + Roslyn
+          analyzers). Penalise `#nullable disable` and pervasive `!` null-forgiving.
+        rubric:
+          excellent: Nullable enabled solution-wide; analyzers on; warnings treated as errors.
+          adequate: Nullable on in some projects; analyzers loosely applied.
+          poor: Nullable disabled; no analyzers.
+        references:
+          - "https://learn.microsoft.com/dotnet/csharp/nullable-references"
+      - id: async-disposal
+        title: Correct async/await and resource disposal
+        guidance: >
+          Async methods avoid `async void` (except event handlers), avoid
+          `.Result`/`.Wait()` deadlock patterns, flow CancellationTokens, and
+          use `using`/`await using` for IDisposable/IAsyncDisposable resources.
+        rubric:
+          excellent: No async void/blocking-on-async; tokens flowed; deterministic disposal.
+          adequate: Mostly correct with isolated blocking calls.
+          poor: Blocking on async / leaked disposables.
+      - id: style-format
+        title: dotnet format / EditorConfig style enforced
+        guidance: >
+          A shared .editorconfig defines style and `dotnet format` (or analyzers)
+          enforces it, ideally in CI.
+        rubric:
+          excellent: .editorconfig + dotnet format enforced in CI.
+          adequate: Style defined but not enforced.
+          poor: No shared style.
+      - id: di-and-structure
+        title: Dependency injection and layered structure
+        guidance: >
+          For applications, dependencies are injected rather than newed up
+          statically, enabling testability and clear layering.
+        rubric:
+          excellent: Constructor DI; clear layers; testable seams.
+          adequate: Some DI with static dependencies mixed in.
+          poor: Pervasive static/`new` coupling.
+
+  - id: testing
+    name: Testing & Verification
+    weight: 18
+    criteria:
+      - id: dotnet-test
+        title: xUnit/NUnit suite runnable via dotnet test
+        guidance: >
+          A test project exists and `dotnet test` runs it; coverage collected
+          via coverlet or similar.
+        rubric:
+          excellent: Solid xUnit/NUnit suite; coverage collected; runs in CI.
+          adequate: Some tests; not in CI.
+          poor: No test project.

package/assets/benchmark/dart.yaml

@@ -0,0 +1,70 @@
+id: dart
+name: Dart / Flutter Overlay
+version: 0.1.0
+kind: benchmark
+extends: base
+appliesTo: [dart]
+scoreScale: 4
+
+categories:
+  - id: language
+    name: Dart / Flutter Language Quality
+    weight: 14
+    description: Idiomatic, null-safe, well-analyzed Dart and Flutter code.
+    criteria:
+      - id: analysis-options
+        title: Strict analysis_options with recommended lints
+        guidance: >
+          An analysis_options.yaml enables a recommended lint set
+          (package:lints/recommended or flutter_lints) and ideally strict
+          language modes (strict-casts, strict-raw-types). `dart analyze` should
+          be clean and run in CI.
+        rubric:
+          excellent: Recommended/flutter lints + strict modes; `dart analyze` clean in CI.
+          adequate: Lints enabled but warnings tolerated.
+          poor: No analysis_options or many analyzer warnings.
+        references:
+          - "https://dart.dev/tools/analysis"
+      - id: null-safety
+        title: Sound null safety, no needless bang operators
+        guidance: >
+          The package is null-safe (SDK constraint >= 2.12) and avoids overusing
+          the `!` null-assertion and `late` where nullable handling is clearer.
+        rubric:
+          excellent: Null-safe with minimal, justified `!`/`late` usage.
+          adequate: Null-safe but liberal `!`/`late`.
+          poor: Not null-safe or unsound patterns.
+      - id: format-pub
+        title: dart format clean and healthy pubspec
+        guidance: >
+          Code is `dart format` clean; pubspec.yaml has bounded dependency
+          constraints and pubspec.lock is committed for apps. `dart pub outdated`
+          shows reasonable currency.
+        rubric:
+          excellent: Formatted; bounded constraints; lockfile committed (apps); deps current.
+          adequate: Mostly formatted; loose constraints.
+          poor: Unformatted; unbounded or stale dependencies.
+      - id: flutter-structure
+        title: Sensible widget/state structure (Flutter)
+        guidance: >
+          For Flutter apps, widgets are decomposed (const where possible), state
+          management is consistent (Provider/Riverpod/Bloc), and business logic
+          is separated from UI. Skip if not a Flutter project.
+        rubric:
+          excellent: Decomposed const widgets; consistent state mgmt; logic separated from UI.
+          adequate: Workable structure with large widgets.
+          poor: Monolithic widgets; logic tangled into UI.
+
+  - id: testing
+    name: Testing & Verification
+    weight: 18
+    criteria:
+      - id: dart-test
+        title: dart/flutter test suite with widget tests
+        guidance: >
+          A test suite runs via `dart test` / `flutter test`, including widget
+          tests for Flutter UIs, with coverage collected.
+        rubric:
+          excellent: Unit + widget tests; coverage collected; runs in CI.
+          adequate: Some tests; UI untested.
+          poor: No tests.

package/assets/benchmark/go.yaml

@@ -0,0 +1,71 @@
+id: go
+name: Go Overlay
+version: 0.1.0
+kind: benchmark
+extends: base
+appliesTo: [go]
+scoreScale: 4
+
+categories:
+  - id: language
+    name: Go Language Quality
+    weight: 14
+    description: Idiomatic, simple, and well-structured Go.
+    criteria:
+      - id: gofmt-vet-lint
+        title: gofmt-clean, go vet, and a linter
+        guidance: >
+          Code is gofmt/goimports clean, `go vet` passes, and a linter
+          (golangci-lint) is configured. These should run in CI.
+        rubric:
+          excellent: gofmt clean; go vet + golangci-lint enforced in CI.
+          adequate: gofmt clean but no vet/lint enforcement.
+          poor: Unformatted code; no static analysis.
+        references:
+          - "https://go.dev/doc/effective_go"
+      - id: error-handling-go
+        title: Idiomatic error handling with wrapping
+        guidance: >
+          Errors are checked, wrapped with context using `fmt.Errorf("...: %w",
+          err)`, and not discarded with `_`. Panics are reserved for truly
+          unrecoverable states. Sentinel/typed errors used where callers branch.
+        rubric:
+          excellent: Errors consistently wrapped with context; no silently ignored errors.
+          adequate: Errors handled but context often lost.
+          poor: Errors ignored or panics used for control flow.
+        references:
+          - "https://go.dev/blog/go1.13-errors"
+      - id: concurrency-safety
+        title: Safe concurrency (no leaks or races)
+        guidance: >
+          Goroutines have clear lifetimes (context cancellation), shared state is
+          protected, and `go test -race` is part of CI. Look for goroutine leaks
+          and unguarded shared maps/slices.
+        rubric:
+          excellent: Context-scoped goroutines; -race in CI; no obvious leaks/races.
+          adequate: Concurrency used correctly but no race detector in CI.
+          poor: Leaky goroutines or unsynchronised shared state.
+      - id: module-layout
+        title: Clean module layout and minimal exported surface
+        guidance: >
+          go.mod is tidy (go mod tidy clean), package boundaries are sensible,
+          and the exported API surface is intentional rather than everything
+          public.
+        rubric:
+          excellent: Tidy modules; cohesive packages; intentional exported API.
+          adequate: Reasonable layout with some over-exposure.
+          poor: Dumping-ground packages; untidy go.mod.
+
+  - id: testing
+    name: Testing & Verification
+    weight: 18
+    criteria:
+      - id: table-tests-race
+        title: Table-driven tests run with the race detector
+        guidance: >
+          Tests use table-driven style where appropriate and CI runs
+          `go test ./... -race`.
+        rubric:
+          excellent: Table-driven tests; `go test -race` in CI; meaningful coverage.
+          adequate: Tests exist without race detection.
+          poor: No tests.

package/assets/benchmark/java.yaml

@@ -0,0 +1,68 @@
+id: java
+name: Java / JVM Overlay
+version: 0.1.0
+kind: benchmark
+extends: base
+appliesTo: [java]
+scoreScale: 4
+
+categories:
+  - id: language
+    name: Java / JVM Language Quality
+    weight: 14
+    description: Idiomatic, safe, and well-built JVM code.
+    criteria:
+      - id: build-tooling
+        title: Maven/Gradle build with pinned plugin/dep versions
+        guidance: >
+          A declarative Maven (pom.xml) or Gradle build manages dependencies and
+          versions (BOM or version catalog), with a wrapper (mvnw/gradlew)
+          committed for reproducibility.
+        rubric:
+          excellent: Wrapper committed; versions centrally managed (BOM/catalog); reproducible build.
+          adequate: Build works but versions scattered / no wrapper.
+          poor: Ad hoc build or unmanaged versions.
+      - id: static-analysis
+        title: Static analysis and formatting enforced
+        guidance: >
+          Tools such as SpotBugs/Error Prone, Checkstyle/PMD, and a formatter
+          (Spotless/google-java-format) are configured and run in CI.
+        rubric:
+          excellent: Error Prone/SpotBugs + Checkstyle + Spotless enforced in CI.
+          adequate: Some tools configured, not enforced.
+          poor: No static analysis or formatting.
+        references:
+          - "https://google.github.io/styleguide/javaguide.html"
+      - id: null-safety-resources
+        title: Null-safety and try-with-resources
+        guidance: >
+          Nullability is communicated (Optional or annotations like JSpecify/
+          @Nullable) and resources use try-with-resources. Penalise returning
+          null collections and swallowing exceptions.
+        rubric:
+          excellent: Clear nullability contracts; try-with-resources throughout.
+          adequate: Inconsistent null handling; mostly closes resources.
+          poor: NPE-prone APIs; leaked resources; swallowed exceptions.
+      - id: immutability-di
+        title: Favour immutability and dependency injection
+        guidance: >
+          Value types are immutable (records/final fields), and dependencies are
+          injected (framework or constructor) rather than statically bound.
+        rubric:
+          excellent: Immutable value types; constructor/framework DI; testable seams.
+          adequate: Some immutability/DI with mutable static state mixed in.
+          poor: Mutable shared state and static coupling.
+
+  - id: testing
+    name: Testing & Verification
+    weight: 18
+    criteria:
+      - id: junit-suite
+        title: JUnit 5 suite with coverage
+        guidance: >
+          A JUnit 5 (or Spock) suite runs via the build tool, with coverage
+          (JaCoCo) collected and ideally a minimum threshold.
+        rubric:
+          excellent: JUnit 5 suite; JaCoCo coverage with threshold; runs in CI.
+          adequate: Tests exist; no coverage gate.
+          poor: No tests.

package/assets/benchmark/python.yaml

@@ -0,0 +1,72 @@
+id: python
+name: Python Overlay
+version: 0.1.0
+kind: benchmark
+extends: base
+appliesTo: [python]
+scoreScale: 4
+
+categories:
+  - id: language
+    name: Python Language Quality
+    weight: 14
+    description: Idiomatic, typed, and well-packaged Python.
+    criteria:
+      - id: type-hints
+        title: Type hints with a static checker
+        guidance: >
+          Public functions/classes carry type hints and a checker (mypy or
+          pyright) is configured, ideally in CI. Penalise pervasive `Any` and
+          `# type: ignore` without justification.
+        rubric:
+          excellent: Typed public API; mypy/pyright clean and enforced in CI.
+          adequate: Partial hints; checker present but not enforced.
+          poor: No type hints or checker.
+        references:
+          - "https://peps.python.org/pep-0484/"
+      - id: lint-format-toolchain
+        title: Ruff/flake8 + formatter (black/ruff format)
+        guidance: >
+          A linter and an auto-formatter are configured and runnable. Ruff
+          covers both well; black + flake8 is also fine.
+        rubric:
+          excellent: Lint + format configured and enforced in CI/pre-commit.
+          adequate: Configured but not enforced.
+          poor: None configured; inconsistent style (PEP 8 violations).
+        references:
+          - "https://peps.python.org/pep-0008/"
+      - id: packaging
+        title: Modern packaging with pyproject.toml and pinned deps
+        guidance: >
+          Project metadata and build config live in pyproject.toml (PEP 621);
+          dependencies are managed with a lockfile (uv/poetry/pip-tools) rather
+          than an unpinned requirements.txt.
+        rubric:
+          excellent: pyproject.toml + lockfile; reproducible install; clear entry points.
+          adequate: requirements.txt present but unpinned or partial metadata.
+          poor: No declared dependencies / ad hoc setup.
+        references:
+          - "https://peps.python.org/pep-0621/"
+      - id: env-isolation
+        title: Virtual environment / dependency isolation documented
+        guidance: >
+          Setup instructions use an isolated environment (venv/uv/poetry/conda);
+          the project does not assume global site-packages.
+        rubric:
+          excellent: Documented isolated env; reproducible from clean machine.
+          adequate: Isolation implied but not documented.
+          poor: Assumes global installs.
+
+  - id: testing
+    name: Testing & Verification
+    weight: 18
+    criteria:
+      - id: pytest-suite
+        title: pytest (or unittest) suite with fixtures
+        guidance: >
+          A runnable test suite using pytest/unittest with proper fixtures
+          rather than global setup, runnable via a single command.
+        rubric:
+          excellent: Well-structured pytest suite with fixtures; coverage measured.
+          adequate: Tests exist but rely on global state.
+          poor: No runnable test suite.