Change-management pack

Rules flag missing evidence on pull requests, GitHub issues, workflow runs, and deployments. Pull-request findings show up on the GitHub Warestack Rules check, the Slack live card, Slack commands, and the Linear agent.

Activated only on the scope you approve. Severity starts honest. Merge-blocking off until you ask.

Recommended first enablement

Rule	What it proves
Require a Linear issue in Warestack’s store `custom.linear_issue_required`	Persisted Linear association. Warestack can resolve known identifiers in PR text; an unresolved string or GitHub issue alone does not pass. Tightens Require a linked ticket (`pull_request.linked_ticket`).
Require linked ticket to be assigned `pull_request.linked_ticket_assignee`	Someone owns the work.
Require active linked ticket `pull_request.linked_ticket_state`	Agreed workflow states (typically In Progress / In Review — you name them).
Detect pull request scope drift `pull_request.scope_alignment`	Scope drift vs Linear title, description, and acceptance criteria.
Branch, PR, and commit conventions `custom.conventions`	`<type>/<linear-issue>-<imperative-description>`, Conventional Commit title, body with summary + bullets + Testing + `Refs:`, and a matching commit trail.
Feature test evidence `custom.feature_test_evidence`	`feat/` source changes add relevant tests, or Testing names the behavior and a concrete reason. Generic “N/A” / “not tested” fails. No fake coverage %.
Require approvals by branch prefix `pull_request.branch_approval_policy`	Proposed: `feat/` and `refactor/` = 2 humans; `fix/`, `test/`, `chore/`, `docs/`, `ci/` = 1. Bots and the author do not count.
Evidence in the approval body `custom.evidence_in_approval_body`	Each counting APPROVED review cites a local command, a CI check, or a development-environment result. “LGTM” is not enough.

Require a linked ticket (pull_request.linked_ticket) accepts Linear or GitHub issue. The recommended Linear-first set uses Require a Linear issue in Warestack’s store (custom.linear_issue_required) so a GitHub issue alone does not pass.

The convention and test-evidence rules make that record understandable and honest; they do not fabricate a coverage percentage. Require concise pull requests (pull_request.size_limit) is a size cap, not Linear association.

You can change prefixes, severities, Linear states, and which repos are in scope after you see findings. If a rule is noisy or too quiet, retune it — do not freeze the pack on day one.

Propose this when

Observation in the last 14 days	Propose
PRs with no persisted Linear association, including unresolved keys in the title/branch/`Refs:`	`custom.linear_issue_required`, `pull_request.linked_ticket_assignee`, `pull_request.linked_ticket_state`, `pull_request.scope_alignment`
`feat/` or `refactor/` with fewer than two human APPROVEs	`pull_request.branch_approval_policy`, `custom.evidence_in_approval_body`
APPROVE bodies that are LGTM / looks good / tested	`custom.evidence_in_approval_body`
`feat/` source changes with no test file and no concrete Testing section	`custom.feature_test_evidence`
Huge PRs, mixed commits, review routing, fatigue	The rest of the catalog is available; mark unused rows later unless evidence makes one essential

Do not

Treat Linear-in-store as Require concise pull requests. That rule is a size cap (pull_request.size_limit).
Infer an association from a ticket string instead of Warestack’s persisted evidence.
Count bots or the author toward Require approvals by branch prefix (pull_request.branch_approval_policy).
Turn merge-blocking on until they ask.

Custom rules

A space-local custom rule keeps a pinned interpretation of its prompt. Evaluation runs only those persisted checks; a rule without a usable pin does not receive a fresh ad hoc interpretation that can pass or fail. Each check returns passed, failed, not_applicable, or not_evaluated. Warestack validates complete selector, alternative, and applicability coverage, then derives the overall rule outcome on the server. When the prompt follows a repository policy file, each pull request reads that file at the base revision, and a changed requirement needs a new interpretation. See Custom rule interpretations.

When rules re-run

Pull-request rules re-run on pull_request opened, synchronized, and edited, and when a review is submitted, a review comment is added, or a review thread is resolved. Those review events rebuild the PR evidence snapshot and re-run the check. The Slack live card also updates immediately. Issue, workflow, and deployment rules run on their own event types.

Findings remain inspectable on the pull-request event timeline. unresolved, acknowledged, and resolved are evidence states. A space admin can acknowledge an eligible blocking finding in the console only with a reason. That audited exception applies to the exact evaluated head revision and finding; a new head or materially changed finding reopens enforcement. If a merge-blocking rule has no complete trusted outcome, Warestack Rules fails closed and offers a rerun rather than reporting a pass.

Full catalog

Keep the rest of the catalog in the draft. Cite unused rows by name and rule_key, and mark them later. How to propose a pack: For AI agents.