reqfile 0.3.0

Check that a codebase meets its requirements
# Requirements for reqfile, checked by reqfile (https://reqfile.dev)
reqfile: 1

# Product requirements are macro: one durable promise each, at most 10 per
# Reqfile. Their details are micro: the names of the tests their checks run.
# Code and testing principles are inherited from the repository root Reqfile.

product:
  - id: REQFILE_FORMAT
    must: Requirements and their labeled examples live in files whose format is versioned and strictly validated, and every error names its file and line.
    why: A requirement or an example that is silently skipped looks exactly like one that passes, and a versioned format can evolve and be read by other tools.
    who: Reqfile authors; tools reading the format.
    checks:
      - command:
          run: cargo test --locked --test reqfile_format --test checks_declared
          violation_codes: [101]
          timeout: 900
          fix_hint: Make the failing tests in tests/reqfile_format.rs and tests/checks_declared.rs pass.

  - id: SCOPE
    must: The requirements and settings that apply to a file are those of the nearest block and config along its folder path, and excluded files are never checked.
    why: Shared rules are written once at the root, each folder can refine them, and vendored or generated code stays out.
    who: Teams with several projects in one repository; agents working in a subfolder.
    checks:
      - command:
          run: cargo test --locked --test cascade --test config_cascade --test exclude
          violation_codes: [101]
          timeout: 900
          fix_hint: Make the failing tests in tests/cascade.rs, tests/config_cascade.rs and tests/exclude.rs pass.

  - id: PACKAGES
    must: Any GitHub repository or folder whose Reqfile.yaml defines a requirement, with its checks and labeled examples under .reqfile/<ID>/, is a package anyone can use with one line pinned to a commit, or try for one run, and that requirement is checked, evaluated and explained exactly as if it were declared where it is used.
    why: A principle and its checker are written once, by anyone, and reused everywhere without copies; a package has the same format as a local requirement, so there is nothing new to learn; and a commit never changes, so every machine gets the same verdict, offline once fetched.
    who: Teams adopting shared or third-party requirements; authors publishing requirements.
    checks:
      - command:
          run: cargo test --locked --test imports
          violation_codes: [101]
          timeout: 900
          fix_hint: Make the failing tests in tests/imports.rs pass.

  - id: COMMAND_CHECK
    must: Any program enforces a requirement through a command whose exit code, or SARIF results carrying an optional probability of violation, map to a pass, a violation, an uncertain finding or a tool error, never to a silent pass.
    why: Mature linters are reused as they are, checkers are written in any language and fetched by their own ecosystem's runner, one protocol covers rules, heuristics and models alike, and a crash or an ignored result must never look like success.
    who: Reqfile authors.
    checks:
      - command:
          run: cargo test --locked --test command_check
          violation_codes: [101]
          timeout: 900
          fix_hint: Make the failing tests in tests/command_check.rs pass.

  - id: DECISION_CHECK
    must: Code no linter can judge is checked by asking Jev a yes/no question about each unit a decision check selects.
    why: Principles like decomplect or contracts still get a fast, cheap signal, with a probability that says how sure the model is.
    who: Agents fixing code; reviewers.
    checks:
      - command:
          run: cargo test --locked --test decision_check
          violation_codes: [101]
          timeout: 900
          fix_hint: Make the failing tests in tests/decision_check.rs pass.

  - id: SELECTION
    must: "`--changed` and `--fast` check everything a change can affect, so hooks stay fast without missing a redefined requirement."
    why: Agents need answers in seconds, and a rule that changed must be applied to unchanged code too.
    who: Agents via hooks; developers before pushing.
    checks:
      - command:
          run: cargo test --locked --test selection --test fast_path
          violation_codes: [101]
          timeout: 900
          fix_hint: Make the failing tests in tests/selection.rs and tests/fast_path.rs pass.

  - id: NO_FALSE_GREEN
    must: Exit 0 means every blocking check ran and passed, and a check that could not run is never reported as passing.
    why: CI and hooks read exit codes only, while an advisory check that cannot run must not block work it could never have blocked.
    who: CI; agent hooks; external contributors whose pull requests have no secrets.
    checks:
      - command:
          run: cargo test --locked --test no_false_green
          violation_codes: [101]
          timeout: 900
          fix_hint: Make the failing tests in tests/no_false_green.rs pass.

  - id: OUTPUT
    must: Every finding is actionable, with its requirement, location, probability and fix hint, names any other requirement its fix would break, and every run can be recorded for evaluation without changing its result.
    why: Agents fix violations directly from the output; requirements will contradict each other, and a contradiction is a product decision to make, not a fix for an agent to undo back and forth; and improving checks needs evidence of what they judged.
    who: Agents in the fix loop; maintainers of requirements.
    checks:
      - command:
          run: cargo test --locked --test output --test run_log
          violation_codes: [101]
          timeout: 900
          fix_hint: Make the failing tests in tests/output.rs and tests/run_log.rs pass.

  - id: INSPECTION
    must: Anyone can see which requirements apply to a path, where each one and its checks come from, and what the repository requires overall.
    why: With shared, local and imported requirements, nobody can reason about rules they cannot see resolved.
    who: Agents before editing; Reqfile authors; reviewers.
    checks:
      - command:
          run: cargo test --locked --test explain --test list
          violation_codes: [101]
          timeout: 900
          fix_hint: Make the failing tests in tests/explain.rs and tests/list.rs pass.

  - id: EVALS
    must: "`reqfile eval` measures each requirement's checks on its labeled examples, and every miss or false alarm met in real use can be added as a new example, so checks become more precise over time and a measurement is never presented as a verification."
    why: Checks only approximate requirements, and the gap closes only when their failures become evidence; examples keep their label outside the files checks see, so a check cannot read its answer, name the expected findings, so flagging the wrong file counts as a miss, and double as the requirement's documentation.
    who: Reqfile authors; anyone adopting a requirement.
    checks:
      - command:
          run: cargo test --locked --test examples
          violation_codes: [101]
          timeout: 900
          fix_hint: Make the failing tests in tests/examples.rs pass.

process:
  - id: CI_GATE
    must: Every pull request and every release runs the tests, `reqfile check` and `reqfile eval` on the exact revision.
    why: Hooks are feedback an agent can exhaust, and a public repository needs an acceptance gate that contributors cannot bypass.
    who: Maintainers; contributors; users trusting a release.
    checks:
      - command:
          run: $REQFILE_ASSETS/check.sh
          fix_hint: Restore the step of .github/check.sh or of the workflows that the check reports as missing.

  - id: REQUIREMENT_BUDGET
    must: A Reqfile holds at most 10 product requirements.
    why: A requirement is one durable promise whose details are the names of its tests; past 10, promises blur into specifications nobody reads.
    who: Reqfile authors; agents adding requirements.
    checks:
      - command:
          run: $REQFILE_ASSETS/check.sh
          fix_hint: Merge requirements into broader promises whose details become test names, or split the folder into subfolders with their own Reqfiles.