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 and refreshes after repositories are added to or removed from that 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. Import history can collect the supported recent window for newly selected repositories without repeating completed imports for every existing repository. Imported events feed Events and metrics; comparison availability still follows actual current- and prior-window coverage.

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.

The repository list shows the current owner, and the repository drawer is where an admin assigns, replaces, or clears that person. 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.

Rules that use repository context

The repository drawer shows both Applied here and Used as context:

• Applied here means a rule configuration is saved directly on this repository; the row can be enabled, disabled, or awaiting context configuration.
• Used as context means another source repository’s rule has or had an approved reference to this repository; current, stopped, and historical bindings can appear.

A direct configuration without repository context shows Configure rule, which opens the Rules drawer’s Scopes tab. Context-capable or bound rows show their selection and Review context and evidence, which opens Interpretation. People who can access the Space can inspect immutable receipts there; only a space admin can approve context or use Stop context. Stopping a binding does not delete the rule, stop repository monitoring, or change earlier receipts. See Custom rule interpretations.

Production

Set the production changelog on the repository that emits the GitHub deployment event.