Write the standard once. Check every change against it.
Turn your delivery standards into checks for pull requests and deployments. Start with a catalog rule or write your own, review its interpretation, and enable it where it applies.
Rules report findings first. You choose when to require the Warestack check in branch protection.
Plain English in. Objective checks out.
You write what the standard is. Warestack proposes the checks, names the evidence each one reads, and shows you the diff when a newer interpretation would change them. Nothing changes until you adopt it.
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.
Delivery standards, grouped by the work they protect.
Each comes with its checks already written and its parameters exposed. Enable it on a team, a repository or a path.
Require a linked work item · require it to be assigned · require it to be active · acceptance criteria before assignment · failure evidence for urgent fixes · deployment traceability
Approvals by branch prefix · owner approval for sensitive changes · independent production approval · production verification evidence · review fatigue · review routing by path or branch
Concise pull requests · atomic commits · scope drift against the linked work item · successful release jobs
Timely acknowledgment of urgent work items · stale pull requests · merges outside the change window
Migration rollback notes · plan artifacts for infrastructure changes · description format · finance approval on pricing tables
Where it runs, and when it starts to block.
A rule is enabled per team, repository or path. New repositories join as they arrive. The result is a GitHub check; whether that check gates the merge is a branch protection setting you control, per repository.
The check reports. The comment names the finding and the next step. Nobody is blocked.
A chain picks it up: a live card in Slack, a message to the reviewer, the owner if nobody responds.
When you are ready, require the Warestack check in branch protection. The same rule, now a gate.
A pull request from a coding agent is held to the rules a person’s would be. Approval rules count humans only; an approving bot never satisfies them.
Deployment reviews and production deployments run through their own rules: independent approval, verification evidence, traceability to a merged pull request.
Every evaluation is kept with the change.
Which standards ran, on which commit, with what evidence and what result. Reports answer questions over it; the auditor gets the export.
Each push re-evaluates. Each result is stored with the commit it ran on.
Pass rate by repository and week. Which standards hold, which drift, where.
Unreviewed merges, review turnaround, lead time and deployment frequency, weekly.
Two rules, then your own.
Most teams begin with a linked work item and approvals by branch prefix, both from the catalog, then write the first custom rule in week two.
