3 months ago
25cc7e0a 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