# 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.

```plaintext
pr.diff.lines_changed > $maxLines
```

### Require a linked ticket

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

```plaintext
pr.linked_ticket IS NULL
```

### Detect review fatigue

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

```plaintext
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.

- **PR / Push Event**  
- **Rules Loaded**  
- **Conditions Evaluated**  
- **Rule Run + Comment**

## 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|chore)              | low       |
| 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.

- **Size risk**: Many files changed, thousands of lines, many commits  
- **Critical path**: Changes to auth, payments, config, secrets, database schemas  
- **Test coverage**: PR removes tests or adds code without tests  
- **Dependency changes**: New deps, version bumps, unverified packages  
- **Contributor history**: First-time contributor, low PR acceptance rate  
- **Reverts**: PR reverts previous changes  
- **Security-sensitive**: Modifies CI/CD, infra code, secrets handling  
- **Breaking changes**: Modifies public APIs, migrations  
- **Rule matches**: Severity of matched contribution standards compounds the risk score

## 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:  
- Review latency – how long a review took  
- LOC change volume – code churn and size metrics  
- Reviewer density – number and type of reviewers involved  
- Risk and anomaly scores – based on learned historical data  
- Cross-tool context – Slack mentions, Jira/Linear issues, CI test failures

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:

```yaml
- 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.