Org engineering standards live in wikis. Nothing checks pull requests against them.
Two approvals on feature work, a work item behind every change, no billing change without its owner. Written down, rarely enforced, and found broken in the incident review. Warestack runs those standards on every pull request and deployment, reports where the change is, and keeps the record. It never reads the code, and nothing blocks a merge until you require the check.
Four weeks on one to three repositories. Success metric agreed before the install.
Warestack Rules— 1 blocking rule violation1 blocking Warestack rule violation detected.
Detect pull request scope drift: Linked Linear issue ORB-418, Batch mute alert rules by label, does not match this pull request. The change pins the kaniko executor and passes base_ref through the preview build.
Recommended action: Limit the pull request to ORB-418, or link the issue that describes this build change.
GitHub Technology PartnerMore code ships every week, from engineers and agents.
Review is the only gate, and it is already behind. The standards that should catch what review misses are not attached to anything.
CONTRIBUTING, the pull request template, the SOC 2 control list. Everyone agrees; nothing checks.
Nobody checks whether the change matches the work item, who approved it, or whether the only approval came from a bot.
Breakage reaches customers. Who approved what is rebuilt by hand from chat history.
Prevent before it ships. Prove afterwards.
Warestack acts at the pull request, the only point where a change can still be stopped, and keeps the record for the auditor, the board and the incident review.
Mark, then act, then block. Rules start informational. Chains escalate to the people who can act. Blocking is a branch protection setting you turn on per repository.
Humans and agents alike. A coding agent’s pull request is held to the same standards as a person’s. Bot approvals never count as human ones.
Nothing new to adopt. The check on GitHub, the live card in Slack, the timeline on the Linear or Jira issue. Reviewers stay where they are.
Pull requests that change files under db/migrations/ must include a Rollback section describing how to revert.
- When any changed file path starts with db/migrations/, the pull request body must contain a heading named Rollback followed by at least one sentence.
- Evidence: pull_request_files.path and pull_request.body. Returns Not evaluated only when the changed-file list is unavailable.
Four numbers you can hold the team to.
Rated against DORA bands, with what needs attention under them and the rows one click away.
Not a dashboard to visit. Posted to the channel you choose, weekly, with the CSV.
Evidence underneath. Every number opens into its trend, its data and its breakdown by repository.
Fewer changes reach customers unreviewed. The audit answers exist before anyone asks.
The time saved is the smallest part of the return.
Caught at the pull request. Scope drift, missing approvals and untested changes are flagged before merge, not in the incident review. A year of Warestack for 40 engineers is about $2,400; one churned account costs more.
Evidence before the auditor asks. Approver, checks, tests and linked work item on record for every production change, retained up to 365 days. An exception in the report stays for the whole observation period.
~1 hr → 20 min a day. SOC 2 reporting and enforcement per engineering leader. The record builds itself; the report is a query.
Four weeks on one to three repositories.
Paid, with the success metric agreed before anything is installed. Nothing blocks a merge during the pilot unless you decide it should.
From you. A GitHub organization admin for the install, five minutes. A Slack channel. The standards document you already have.
Success metric: unreviewed merges at zero and median time to first review under four hours on the pilot repositories, with the evidence to show it.