Home

boring / v2

publicBoring-Software-Inc/v2
Overview Code History Branches Pull requestsIssuesInsights Campfire Docs
main
HomeOverview Code PRsIssues

feat: rule-check dev CLI — evaluate one rule against a real PR

3 months ago

25cc7e0
Authored
grim7/24/2026, 8:28:33 AM
a rule can look armed in the ui and be completely inert. every custom rule
in prod skipped with "forge reads unavailable" for days and nothing surfaced
it. this makes that visible in one command.

- checkRule() / listRules() as callable functions (a future "test this rule"
  button reuses them server-side); scripts/rule-check.ts is a thin wrapper.
- a single-rule run is a synthetic one-node workflow (trigger -> rule, NO
  action nodes) fed to the real executeWorkflow. structurally cannot comment,
  check, block, or notify; executor is pure so nothing is persisted — no
  activity/stats/insights pollution.
- reuses the worker's own path (buildRuleContext, makeEvaluator,
  customRuleSource, createForgeSignalCtx) so it never drifts from the worker.
- fetches the PR and runs it through the real webhook normalizer (zero field
  drift vs a hand-rolled event).
- output leads with the skip reason and reports per-signal resolved-vs-
  unavailable with the raw value the comparison read.

dev tool: holds DB + forge creds by design, never shipped. env: DATABASE_URL,
GITHUB_APP_ID, GITHUB_APP_PRIVATE_KEY.

Parent6566405

3 files changed
  • package.json+1−0
  • scripts/rule-check.core.ts+289−0
  • scripts/rule-check.ts+104−0