Pull Request Rules – Deterministic Pre-merge Enforcement | Warestack

Org-level contribution standards, on every pull request

Deterministic pre-merge governance. AI can help author and analyze rules; enforcement runs through the Warestack Rules GitHub check — not an LLM in the merge path.

Feature

Require concise pull requests

Flag pull requests that exceed the configured maximum lines of code, excluding changes to lock files.

pr.diff.lines_changed > $maxLines

Require a linked ticket

Flag pull requests that are not linked to a Linear or GitHub issue.

pr.linked_ticket IS NULL

Detect review fatigue

Flag reviewers who receive more review requests than the configured threshold.

reviewer.pending_review_requests > $maxOpenReviewRequests

Optional merge blocking

12 curated governance rules

Warestack Rules GitHub check

How it works

On every PR and push, Warestack loads your active rules, enriches with PR data (files, reviews, CODEOWNERS), runs condition-based evaluation, and posts violations as GitHub check runs and PR comments.

Supported contribution standards

Each standard maps to a condition Warestack evaluates on every PR. Rules are configured and managed through the dashboard — no manual file editing required.

Parameter What it enforces Severity
require_linked_issue PRs must reference an issue (e.g. Fixes #123) high
require_code_owner_reviewers CODEOWNERS for modified paths must be requested as reviewers high
max_lines Total additions + deletions ≤ threshold per PR medium
min_approvals Minimum number of approvals before merge high
security_patterns Detect hardcoded secrets or sensitive data in diffs critical
diff_restricted_patterns Flag restricted patterns (console.log, TODO) in added lines medium
block_on_unresolved_comments Block merge when unresolved review threads exist high
require_tests Source changes must include corresponding test file changes medium
require_signed_commits All commits must be cryptographically signed (GPG/SSH) high
title_pattern PR title must match a defined convention (e.g. feat fix
no_force_push Reject force pushes to protected branches critical
block_self_approval PR authors cannot approve their own code high

Capabilities

Pre-merge approval

Validate every PR against org-level contribution standards before it reaches main. Enforce linked issues, CODEOWNERS reviewers, PR size limits, title conventions, and more — all managed from your Warestack dashboard.

Pre-deploy gates

Add deployment checkpoints that verify compliance, deployment freeze windows, and architectural constraints before code ships to production.

Risk scoring

Score each PR by policy violations, complexity, security surface, and contributor history. Route senior reviewers to what actually matters.

Progressive enforcement

Start with warnings, graduate to soft blocks, then hard blocks. Contributors can acknowledge violations with a reason when the rule does not fit the case.

Drift detection

Monitor for policy violations over time and compliance regression across teams and repos. Surface the gaps before they compound.

Spec-incomplete blocking

Block or warn on PRs linked to under-scoped Linear or Jira tasks — missing acceptance criteria, vague descriptions, or no linked design docs. Pairs with Unified Delivery Data for detection.

Risk signals

Each PR is scored across multiple risk dimensions. Scores compound — a large PR touching critical paths with no tests scores highest.

Frequently asked questions

What does "pattern-enriched metadata" mean in Warestack?

Pattern-enriched metadata means that Warestack automatically attaches additional context to every code-related event — from pull requests and commits to CI/CD pipelines and chat discussions. Instead of storing only what happened (e.g., a PR was merged), Warestack also tracks how it happened — such as review latency, file types, number of reverts, and links to discussion threads. This transforms raw activity into structured, queryable knowledge that can later be used for analytics, governance, or AI-powered insights.

What kind of metadata does Warestack attach to each event?

Each entity (PR, commit, issue, or deployment) is enriched with metrics like:

This rich metadata enables pattern recognition and cross-system reasoning, making it easier to spot regressions or risky behaviors early.

How does the YAML check system work?

Warestack allows you to define pattern checks declaratively in YAML format. Each check describes a dependency or rule that should be enforced — for example:

- description: "Pull requests that modify .sql files must provide a .migration.sql file."
  event_types: ["pull_request"]
  parameters:
    file_pattern_dependency:
      source_pattern: "*.sql"
      dependent_pattern: "*.migration.sql"

Once defined, these checks can be activated through the UI, automated via the CLI, or embedded in your organization's governance templates. This makes checks portable, auditable, and version-controlled alongside your code.

How are cross-tool correlations established?

Warestack maintains a shared reference graph between entities using temporal and semantic keys (e.g., PR ID, commit hash, message reference). This allows correlating a Slack discussion or Jira issue directly to the related PR or deployment, enabling causal and temporal analysis.

How can teams query and integrate Warestack data?

All normalized and enriched data is exposed via a REST and SQL API. Developers can query through natural language or deterministic SQL for reproducible analytics. Warestack supports event streaming for real-time dashboards and rule triggers through its agentic rule engine.