Review in a pull request and CI gates

A rule change is a code change. It goes through a pull request, a reviewer, and CI. CI runs the same rcas check you ran, on every ruleset, so a change that breaks a load check or a golden test cannot merge.

Hands-on

1. Add a CI step that checks every ruleset. This is the step the Rule Cascade repository runs on its own example rulesets, unchanged:

   - name: The command checks the example rulesets
     run: >
       packages/go/dist/rcas${{ runner.os == 'Windows' && '.exe' || '' }} check
       examples/contracts/*.ruleset.yaml examples/catalog/*.ruleset.yaml
       examples/derived/*.ruleset.yaml conformance/sources/*.ruleset.yaml

   In your repository, build or download the command first, then list your own ruleset files.

2. Make the step required. In the repository settings, mark the check as required for the main branch, so a red check blocks the merge.

3. Review the change in this order:

   • the golden tests: do they say what the business asked for?
   • metadata.version: raised, with a minor version for a new rule and a major version for a change that denies what was allowed before;
   • the rule itself: its severity, its enforcement (does a secret limit stay server?), and its overridePolicy (may a child loosen it?).

Done when

• The pull request shows the check step, and it is green.
• A pull request with a failing golden test cannot be merged.
• The reviewer approved the tests and the version, not only the rule.

Go deeper

• Ship a rule change, step "Open the pull request; CI checks and compiles".
• Authoring guidelines: what a reviewer looks for.