Evidence-backed governance from pull request to production
Warestack combines deterministic validators with pinned agentic checks. Every check must return a complete, server-validated outcome before it can pass or block delivery.
Flag pull requests that exceed the configured maximum lines of code, excluding changes to lock files.
pr.diff.lines_changed > $maxLinesFlag pull requests that are not linked to a Linear or GitHub issue.
pr.linked_ticket IS NULLFlag pull requests that introduce changes unrelated to the linked Linear or GitHub issue.
pr.scope_similarity = "LOW"How it works
Warestack matches each pull request, issue, workflow run, deployment review, or deployment to the active scoped rules. It gathers the declared evidence, evaluates the persisted checks, validates every per-check outcome, and derives the final result.
Supported governance catalog
These are the same stable rule keys and default severities exposed in Warestack. The catalog covers pull requests, GitHub issues, workflow runs, deployment reviews, and deployments.
| Rule key | What it checks | Severity |
|---|---|---|
| pull_request.size_limit | Flag pull requests that exceed the configured maximum lines of code, excluding changes to lock files. | high |
| pull_request.commit_size_limit | Flag commits that exceed the configured lines of code per commit, regardless of the pull request size. | medium |
| pull_request.branch_reviewer_routing | Route review requests to specific team members based on configurable pull request branch prefixes. | medium |
| pull_request.path_reviewer_routing | Route review requests to specific team members based on configurable file paths. | medium |
| pull_request.reviewer_capacity | Flag reviewers who receive more review requests than the configured threshold. | medium |
| pull_request.linked_ticket | Flag pull requests that are not linked to a Linear or GitHub issue. | high |
| pull_request.linked_ticket_assignee | Flag pull requests with a linked Linear or GitHub issue without an assignee. | medium |
| pull_request.linked_ticket_state | Flag pull requests with a linked Linear or GitHub issue that is inactive or not in progress. | medium |
| pull_request.review_acknowledgment_sla | Flag pull requests that do not receive reviews or acknowledgments within the configured time limit. | medium |
| pull_request.draft_staleness | Flag draft pull requests as stale when they have no updates within the configured time limit. | low |
| pull_request.urgent_ticket_review_sla | Flag pull requests that do not receive reviews or acknowledgments within the configured time limit when the linked Linear task is marked as "Urgent" or the linked GitHub issue is tagged as "Critical"/"Urgent". | high |
| pull_request.scope_alignment | Flag pull requests that introduce changes unrelated to the linked Linear or GitHub issue. | high |
| pull_request.branch_approval_policy | Mark pull requests that reach merge with fewer human approvals than their branch prefix requires. Bot approvals never count. | high |
| pull_request.review_findings_resolved | Flag pull requests with current actionable review-bot findings that have not been resolved or addressed. | high |
| pull_request.sensitive_change_approval | Flag sensitive-path changes without an independent approval from an observed code owner. | critical |
| pull_request.urgent_fix_failure_evidence | Flag corrective pull requests linked to an urgent Linear issue when the issue does not document observable evidence of the broken behavior. | high |
| issue.implementation_evidence | Flag closed GitHub implementation issues that have no linked merged pull request. | medium |
| issue.acceptance_criteria | Flag assigned GitHub issues whose description does not define verifiable acceptance criteria. | medium |
| workflow_run.release_jobs_successful | Flag release workflows when an observed required job does not complete successfully. | high |
| workflow_run.duration_budget | Flag workflow runs whose observed elapsed time exceeds the configured duration budget. | medium |
| deployment_review.independent_approval | Flag production deployment reviews without an observed approval from someone other than the requestor. | critical |
| deployment.production_verification | Flag successful production deployments without observed health, smoke, or verification evidence. | high |
| deployment.production_change_traceability | Flag production deployments that cannot be traced to an observed pull request. | critical |
| deployment.production_failure_diagnostics | Flag failed production deployments whose status history does not expose actionable diagnostic evidence. | high |
Capabilities
Persisted rule contracts
Agentic rules run persisted checks instead of being reinterpreted during every evaluation. A rule without a usable pin cannot produce a trusted pass or violation.
Complete evidence coverage
Every check reports passed, failed, not applicable, or not evaluated. Warestack validates selectors, conjunctive alternatives, and applicability before deriving the rule result.
Fail-closed merge gates
Optional merge blocking never turns an incomplete evaluation into a pass. The Warestack Rules check names unavailable blocking rules and can be rerun after evidence or provider recovery.
Revision-bound acknowledgement
A space admin can acknowledge an eligible blocking finding with a required, audited reason. The exception applies only to the exact pull-request revision and finding.
Delivery-wide coverage
One catalog covers pull requests, GitHub issues, workflow runs, production approvals, and deployments instead of treating merge time as the whole delivery process.
Scoped findings and provenance
Findings preserve the rule, event, evidence, and evaluation outcome. Pull-request rules can also publish the Warestack Rules check for the evaluated head revision.
Evidence contracts
Each rule declares the capabilities and selectors it may use. Missing or partial evidence remains explicit instead of being filled with an assumption.
Pull request and diff
Title, body, branches, commits, changed files, and complete diff evidence
Linked tickets
Stored GitHub or Linear associations, assignment, workflow state, priority, and description completeness
Reviews and discussions
Effective human review state, requested reviewers, and reconciled actionable review threads
Ownership and actors
Observed CODEOWNERS, author identity, reviewer identity, and independent approval evidence
Workflow runs and jobs
Workflow identity, timestamps, status, conclusion, and observed job outcomes
Deployment lifecycle
Environment, deployed revision, approval actors, status history, verification, and diagnostic links