Repositories define the concrete delivery boundary Warestack monitors. Start with one or two production-path repositories, then expand from observed findings.

Monitor the right repositories

The repository list reflects the connected GitHub installation. Enabling monitoring brings future GitHub events into Warestack; stopping monitoring leaves the repository available to enable again.

First-run repository insights use recent GitHub activity to help choose a bounded starting set. They are suggestions, not governance verdicts.

Assign an individual owner

An owner is a workspace GitHub identity, ideally with a confirmed Slack binding.

• The owner is accountable context for the repository.
• Review SLA can escalate to that person.
• A team may describe coverage, but a team cannot receive a DM.
• Missing Slack readiness is shown before enablement.

See People and Teams and owners.

Inspect branch protection

Warestack shows the branch protection GitHub reports for the repository, including required reviews, status checks, and whether merge/deployment blocking is supported. Branch protection remains managed in GitHub; the repository view links there for changes.

A failing Warestack check is not automatically a merge gate. It blocks only when:

1. A Warestack rule has block_merge enabled; and
2. GitHub branch protection requires the Warestack Rules status check.

The recommended first enablement leaves merge-blocking off until the team has reviewed real findings.

Scope choices

• Use repository scope when owners, channels, or blast radius must stay isolated.
• Use team scope when one engineering team clearly owns several repositories.
• Use path scope for a sensitive subpath where the selected rule or chain evaluates changed files.

See Repository, team, and path scope.

Production and counterparts

Set the production changelog on the repository that emits the GitHub deployment event. Repository IDs — not free-form names — are also the safe boundary if you later request a named cross-repository pair.