Testing Watchflow rules in feature branches

[dkargatzis]

This discussion follows an observation by @dimeloper in Issue #9, where he highlighted the lack of a safe and traceable workflow for testing .watchflow/rules.yaml before pushing to production branches.

We observed a critical limitation:

There's currently no safe, traceable way to test .watchflow/rules.yaml changes without pushing them to main, making iteration on rules error-prone and high-risk.

We want to define a testing workflow that supports iterative development of governance logic without introducing production risk.

Current workflow friction

• No staging mode: Rule changes apply immediately if pushed to main
• Multi-step testing: Developers must create test PRs after pushing unverified rules
• No feedback loop: Can't preview how a rule will behave until it’s live
• High coupling: Production rules and test rules live in the same file with no isolation
• Unintended breakage: Rule changes can silently break protections if misconfigured

Potential solutions

Option 1: rules-test.yaml + Draft PRs

• Behavior:

  • Draft PRs apply rules from .watchflow/rules-test.yaml in the branch
  • Ready PRs must conform to main's .watchflow/rules.yaml
  • Optional enforcement: block merge if rules-test.yaml still exists

• Security: Test rules cannot override production rules in ready PRs

• Pros:

  • GitHub-native workflow
  • Clear lifecycle: test while in draft, enforce before merge

• Cons:

  • Adds file cleanup responsibility
  • Slightly more logic complexity inside Watchflow engine

• Example workflow:

  1. Create feature branch with .watchflow/rules-test.yaml
  2. Create Draft PR → Watchflow uses test rules
  3. Test rule behavior safely
  4. Remove test file, mark PR ready → Watchflow uses production rules

Option 2: local CLI rule simulator

• Command:

  watchflow test-rules --file .watchflow/rules-dev.yaml --pr https://github.com/org/repo/pull/123

• Purpose: Allows local testing of rules against any live PR (via GitHub API)

• Pros:

  • Zero production impact
  • Fast iteration loop for advanced users

• Cons:

  • Requires CLI support
  • Testing feedback is decoupled from GitHub UI/UX

Have thoughts? Drop them below. We're looking for an approach that will help your team iterate on governance rules without fear of breaking production?