Action plan: order of execution for the ecosystem roadmap and strict self-validation

Start with the linked roadmap issue #105 and the listed prerequisite issues to understand the planned ecosystem and practice work. The roadmap names its validation entry points, including tests/test_ecosystem_contract.py, tests/test_documentation.py, and tests/test_architecture.py; read the relevant contract before taking on a single step. A step is done when its stated repository requirements are met and its pull request passes all listed gates, including strict self-validation.

The order in which the planned work is done, and the rules every step follows. #105 lists the same work by kind; this issue says what comes next.

Rules for every step

• This project validates itself strictly. CI runs project-validator --strict --exclude tests/fixtures ., so a warning fails the build. A new check that applies to this project (to Python, or to every project) lands in the same pull request as whatever this repository needs in order to pass it. Each step below says what that is.
• One pull request per step, with all gates green: python -W error -m unittest, ruff check and format, mypy, branch coverage ≥ 95%, lizard, jscpd, and self-validation.
• A new ecosystem is one profile module and two fixtures, held to them by tests/test_ecosystem_contract.py. Nothing in project_validator/checks/ changes for it. The README's "Applies to" column follows from the registry (tests/test_documentation.py).
• A new practice is a rule type in project_validator/rules.py and one check, which must not import a profile or name a language (tests/test_architecture.py). Each existing profile then supplies its rule, or the check reports SKIP for it.
• Binary hardening means what the build inserts into a binary (#61). Static analysis counts toward security-scanning, and dependency audits toward dependency-audit.

Phase 0: land the ecosystem work and make self-validation strict

• Fix the formatting job on #106. ruff 0.17 formats Python code blocks in Markdown and failed on the README's Zig plugin example; fixed in ea084e1.
• Pin the tools CI installs. Every Python tool is pinned in .github/requirements/, and Dependabot keeps the pins current. jscpd is pinned in the workflow, because Dependabot does not update versions given to npx (f27146b).
• Run pip-audit in CI. The dependency audit workflow audits the project's dependencies and the tools CI installs, on every change and weekly (f27146b).
• Make self-validation strict: project-validator --strict --exclude tests/fixtures . (f27146b).
• Bring #105 up to date: it lists the checks that already grow with each profile, and links this issue.
• Merge #106 (ecosystem-profiles). Its description lists the breaking changes.
• Not our problem for now: GitHub is having trouble provisioning macOS runners, so macOS jobs are sometimes cancelled before they start (runs 41878897566 and 41874288899). We ignore those cancellations.

Phase 1: core prerequisites

Several profiles cannot be built until these land. Done in the core-detection pull request (477a85e).

• #62 build files by pattern. Needed by .NET, Ruby, Swift (Xcode), Haskell, OCaml, Lua, Common Lisp and Docker (*.Dockerfile).
• #63 detection by content, and ambiguous suffixes. Needed by R, Julia, Perl, Fortran, Shell, every data and schema profile, Kubernetes and Ansible.
• #64 --map lists file suffixes no ecosystem recognises.

Phase 2: checks for every project

One stacked pull request per check, to merge in this order: #109 → #110 → #111 → #112 → #113 → #114 → #115 → #116.
These are cheap, and each raises the bar for this repository too.

• #84 data-wellformed (#109). This repository passes already, as long as fixtures that are broken on purpose stay excluded.
• #99 license (#110). Passes already (LICENSE.txt).
• #104 large-files (#111). Passes already.
• #100 security-policy (#112). This repository needs a SECURITY.md (GitHub private vulnerability reporting is enough).
• #101 ci-lint (#113). This repository needs actionlint (and zizmor) in CI.
• #102 action-pinning (#114). This repository must pin every action to a commit SHA, e.g. actions/checkout@<sha> # v7. Dependabot already updates SHA pins.
• #103 secret-scanning (#115). This repository needs gitleaks (or another scanner) in CI.
• #58 status-badges (#116). Passes already (CI and Codecov badges in the README).

Phase 3: the practices most profiles refer to

Profile issues list these as later rows. Doing them before the language waves means each new profile supplies their rules once, instead of every profile being revisited.

• #56 committed-artifacts (#119). Extends the BuildOutputs rule that vcs-ignore already uses, so every profile gets both checks from one rule. Passes here.
• #24 dependency-management (#122). Brings back hash-checked Python dependencies. Decided: this project locks its development tools: .github/requirements/*.txt are compiled with pip-compile --generate-hashes and installed with --require-hashes.
• #13 static-analysis (#120). Passes here (ruff check).
• #57 type-checking (#121). Passes here (strict mypy).

Phase 4: languages, wave 1

• #65 JavaScript/TypeScript
• #66 JVM (Java and Kotlin, with Maven and Gradle)
• #69 PHP
• #68 Ruby (needs #62)
• #67 .NET (needs #62; research its hardening rule before writing one)
• #70 Swift (needs #62 for Xcode; confirm whether its coverage can report branches)

Phase 5: the remaining practices

• #10 sanitizers. Python is skipped.
• #16 fuzz-testing. Decide first: it applies to Python, and this repository has no fuzz tests. Either fuzz its parsers (CI files, YAML) with atheris, run in CI only so the Dependency Policy holds, or treat property-based tests as enough here.
• #21 build-tool-version. Python has no rule (a minimum interpreter was language-standard, #19, closed as not planned), so this repository is skipped.
• #30 packaging. Passes here (pyproject.toml with [build-system]); building a wheel in CI is a bonus.
• #31 build-cache. This repository needs cache: pip on actions/setup-python.
• #60 mutation testing. This repository needs a mutmut job, which can run on a pull request's changes only.
• C/C++ only, any time: #18 out-of-source-build, #23 compile-commands, #25 top-level-guard, #27 constexpr-tests.

Phase 6: languages, wave 2

• #73 Elixir/Erlang
• #75 Scala (reuses the JVM profile's JDK patterns)
• #76 Dart/Flutter (confirm its coverage granularity)
• #71 Lua (needs #62)
• #72 Haskell (needs #62)
• #74 OCaml (needs #62)
• #77 R (needs #63)
• #78 Julia (needs #63)
• #80 Perl (needs #63)
• #79 Zig: first move the plugin tests and the README's "Adding an ecosystem" example to a language with no planned built-in profile.
• #81 Fortran: decide first how CMake and Meson are shared between the C/C++ and Fortran profiles.
• #83 Lisp family (needs #62 for Common Lisp)
• #82 Shell and PowerShell: decide first when helper scripts make a project a shell project. This repository has no shell scripts today.

Phase 7: data, schemas and documents

• #85 schema practices and the JSON Schema profile (needs #63)
• #86 XML
• #87 OpenAPI/AsyncAPI
• #88 Protobuf
• #89 GraphQL
• #90 Jupyter notebooks
• #91 documentation sites
• #92 SQL, tabular data, LaTeX and Typst

Phase 8: infrastructure

• #93 Terraform/OpenTofu
• #94 Docker (needs #62)
• #95 Helm/Kubernetes (needs #63)
• #96 Ansible (needs #63)
• #97 Nix
• #98 GitHub Action repositories

Decisions needed

Each blocks only its own step:

• #24: are libraries exempt from committing a lockfile?
• #16: how does this repository meet fuzz-testing?
• #81: are CMake and Meson shared between profiles?
• #82: when do shell scripts make a project a shell project?
• #67: what is binary hardening for .NET (native AOT, <CetCompat>)?
• #70 and #76: do Swift's and Dart's coverage tools report branches?