See it in action

These scenarios show the product response when evidence exists, is incomplete, or is missing. They are representative outcomes, not a live GitHub or Linear page.

One change, every surface


Linear issue
  → GitHub pull request
  → Warestack Rules finding
  → one Slack live card, updated in place
  → requested-reviewer DM, then individual-owner escalation
  → human approval with named evidence
  → successful production deployment changelog
  → scheduled weekly population for sampling

The same identifiers, reviewers, checks, and findings stay attributable across the surfaces. A missing association or missing human stays missing; Warestack does not fill the gap with a guess.

Four pull requests, four outcomes

Scenario	What Warestack observed	Result
Linked documentation change	Stored Linear association; branch/PR body missed the agreed conventions	The card showed the linked issue and one high conventions finding
Linked feature below the review bar	Stored Linear association; fewer than two human approvals	An approval finding stayed on the card until two evidence-rich reviews and a later PR event re-ran the rule
Feature with no stored Linear association	Ticket key only in the branch or `Refs:`; no tests or concrete Testing section	The card omitted Linear and showed ticket and test findings
Linked but unrelated change	Stored association whose issue did not match the diff	A scope-drift finding stayed visible; Review SLA DMed the requested reviewer, then the individual owner

Merge-blocking stays off until you decide to require Warestack Rules in GitHub branch protection. Findings are inspectable before that decision.

One card, not webhook noise

Opening a pull request creates one top-level Slack card. Review, check, issue-link, thread, and rule events update that message. Request Update replies in the same thread, and webhook redelivery does not create a duplicate card.


pull request #42 · feat: add slug helper
acme/payments · feat/pay-184-add-slug-helper
Status          Ready · Open
Linear issue    PAY-184
Review          Approved by alex, sam
Checks          passing
Review threads  0 actionable threads
Rules           No rule issues

The fields are the stable live-card anatomy. Names and numbers here are examples.

One issue, three pull requests

When several pull requests are associated with the same Linear issue, the workspace agent assesses each PR separately against that issue:

On scope. A small helper in the issue’s repository, with tests and passing checks. Blocker: two human approvals.
Scope drift. A large backend refactor in another repository that does not match the issue’s acceptance criteria.
Out of scope. A frontend UI change that does not implement the issue.

The response separates evidence, finding severity, blocker, next action, and confidence. It does not flatten three associated PRs into one “ticket linked” pass.

Parent issue, three repos

An end-to-end feature should not put every PR on the parent ticket.


PAY-180  Checkout (parent — outcome only)
  PAY-181  Checkout API     → acme/payments#42
  PAY-182  Checkout UI      → acme/web#88
  PAY-183  Checkout schema  → acme/migrations#12

Each PR is associated with its sub-issue. Scope, assignee, and active state are evaluated per layer. Linking all three PRs to PAY-180 makes the UI and schema diffs look like drift against a broad parent description. Warestack does not walk Linear parent/child to fix that. See How to ticket.

No linked pull request

When Warestack’s snapshot has no associated PR:


What needs attention
- No pull request is currently linked to this issue in Warestack.
- The issue remains In Progress but has no associated code changes yet.

Suggested next action
- Create or link a pull request if one exists but is not yet synced.
- Otherwise name the blocker, confirm the assignee and timeline, or update status.

Confidence / missing data
- Warestack shows no linked PR.

If someone asks the agent to “compare the linked pull request,” it stays at unknown, lists the empty snapshot, and asks for owner/repo#n if one exists. It does not invent one.

Review SLA: private escalation

With Review SLA enabled:

The requested reviewer receives a private Slack reminder after the configured delay (product default 4 hours).
The named individual repository owner receives the escalation if a human review is still missing (product default 24 hours).
The channel keeps only the live card — no public reminder spam.

A bot review does not stop the clock. A person with no confirmed Slack identity is not silently DMed. See Review SLA.

Production means deployed

The changelog fires on a successful GitHub deployment in production or prod. Merge, and a deployment still waiting for approval, do not.

When no PR can be associated, the announcement can show the deployed commit instead of inventing a pull request. See Production changelog.

A scheduled report really posts

A weekly report and its scheduled_report chain are different objects:

Run now rebuilds the SQL result and run history.
The chain calendar runs the report, then posts one Slack announcement.

That distinction prevents “the query ran” from being mistaken for “the team received the operating report.”

What to try first

Use one real pull request to test the full loop:

Link an assigned, active Linear issue.
Open a small feat/ PR with a concrete Testing section.
Request two human reviewers.
Watch one Slack card update as checks and approvals arrive.
Ask the Linear agent to assess alignment.
Let the next successful production deployment produce the changelog.

Start the pack →