feat(config): Add postChecks toggle to disable GitHub Check-run posting

[CalebKAston]

Summary

Adds a postChecks boolean (action input post-checks, default true; overridable per-repo via warden.toml's [defaults] postChecks) that disables creation/update of GitHub Check runs — the core warden check and every per-skill warden: <skill> check, including their inline annotations — while leaving PR review comment posting untouched.

Why

Check-run creation is entirely write-only today: nothing in the codebase reads it back via the API, and it isn't load-bearing for the findings-output file or for comment dedup (which reads back PR review comments instead, a separate mechanism). Some teams want PR review comments as the single review surface without a second, non-threaded, non-dedup'd GitHub Checks UI surface running alongside it — this makes that toggleable without losing the option to fail a required status check via fail-check/fail-on when wanted.

Implementation

• Single choke point: checkOptionsForPullRequest(context, postChecks) returns undefined when postChecks is false. Two call sites that previously bypassed it with inline option objects (setupGitHubState, finalizeWorkflow's core-check update) were refactored to route through it too, so every check-creation path in pr-workflow.ts shares one gate.
• postChecks resolves with the same enforced-baseline precedence already used for runnerConcurrency/auxiliary-model settings in initializeWorkflow: org base config (via base-config-path) wins over the repo's own warden.toml, which wins over the post-checks action input default. This matters because it's the same class of workflow-level (not per-trigger) setting, and a repo-level override should not be able to silently defeat an org-wide policy set via the base config.
• ActionInputs.postChecks is non-optional (unlike the default-false booleans requestChanges/failCheck) because its default is true and gets resolved at parse time rather than deferred to each call site — the opposite polarity needs the default applied once, explicitly.

Verification

Applied this change to a local fork (babylist/warden) and verified it against real PRs in a downstream consumer repo before opening this PR:

• With post-checks unset (default true): unchanged existing behavior — checks and comments both post, as today.
• With post-checks: false: confirmed via the GitHub API that no warden / warden: <skill> check runs were created on the PR, while a PR review comment still posted for a real finding.
• With post-checks: true set explicitly at the repo level (overriding an org base-config default of false): confirmed the full check-run set (core + every configured skill) was created again, alongside the review comment.

Also added regression tests exercising postChecks: false end-to-end through runPRWorkflow (both legacy run mode and report mode) asserting checks.create/checks.update are never called while pulls.createReview still is, plus config/schema tests for the warden.toml override and its precedence against the org base config.

pnpm lint && pnpm build && pnpm test all pass (two unrelated, pre-existing flaky tests in cli/files.test.ts/cli/output/jsonl.test.ts fail only under full-suite parallel load and pass in isolation — not touched by this change).

[CalebKAston]

@dcramer I've updated this as it had conflicts with main after the output file updates merged.

If it's helpful context, we added this control in our fork because we were getting complaints about "double posting" from our engineers when they would see both a comment and an annotation check. We aren't using the checks in our CI as our current implementation is non-blocking by design, so this control was added to prevent posting the checks we aren't using.

[vercel]

@CalebKAston is attempting to deploy a commit to the Sentry Team on Vercel.

A member of the Team first needs to authorize it.

[gricha]

sweet this is good, thank you

[gricha]

@CalebKAston you can ask your clanker to clean up the typecheck, it's failing on current main, I can merge afterwards

[gricha]

btw. i can fix some of those myself in the future, i just think you'd have to submit PRs from personal fork vs. org fork because org security overrides the "maintainerCanModify" flag, but up to you, that just gives you a little bit longer back and forth with us

[CalebKAston]

btw. i can fix some of those myself in the future, i just think you'd have to submit PRs from personal fork vs. org fork because org security overrides the "maintainerCanModify" flag, but up to you, that just gives you a little bit longer back and forth with us

Good to know! Thanks for the explanation. With these last couple of PRs we should fully be at feature parity with this maintained version of Warden, so the goal is to deprecate our local fork. But I'll keep that in mind if I need to submit additional PRs.

[CalebKAston]

@gricha , I've fixed the typecheck 👍

[gricha]

thank you!