Warestack does not invent a seventh org chart. Configuration can use Space, Team, Repositories, or Path where the selected rule or chain supports that boundary.
| Decision | Repositories | Team |
|---|---|---|
| Rules | Activated on named in-scope repositories | Inherited by the Team’s repositories |
| Live card / Review SLA | One chain per repository, one Slack channel | One chain for the Team’s repositories |
| Cross-repo context | Source repository + named referenced repositories | Not supported; configure each source repository directly |
| Weekly digest | Space rollup of those repositories | Team rollup, then Space rollup |
| Production changelog | On the deploy-producing repository | Same event, Team or Repositories scope |
We will not turn on rules for a Team “because it is easier” if you asked to keep Repositories isolated. A saved Repositories configuration for the same catalog rule suppresses the inherited Team configuration.
Prefer 1–2 production repositories at first even if many repositories were busy. Extra repositories are a later request, not a bigger day-one blast radius.
See Teams and owners for when to propose Team rules and chains versus isolated Repositories.
Path
Path applies a changed-file boundary inside selected repositories — for example .github/workflows/**, infra/**, or a schema directory. Use it only with events and conditions that evaluate changed paths. A path does not replace repository authorization.
Space
Space is for a genuinely space-owned object such as a saved report schedule. Person-owned personal_digest is also associated with the Space but remains private to its member.
Propose this when
| Observation | Scope |
|---|---|
| One GitHub/Warestack team owns many production repositories | Team for the rule pack and live card; individual owner still required per repository |
| Two repositories must stay isolated | Repositories |
| A source PR must agree with contracts or policies elsewhere | A rule description with literal referenced repositories, followed by space-admin review and approval of the exact context binding |
Do not
- Turn on rules for a Team “because it is easier” if you asked to keep Repositories isolated.
- Propose a team as the Review SLA DM target.
Cross-repository rule context
The control GitHub never sees: a source pull request that conflicts with the approved schema, migration policy, API contract, or client expectations stored in another repository.
Status: available through a space-admin-approved custom-rule context binding with Repositories scope. Team is not supported; configure each source repository directly. State the requirement in the rule description with literal repository names. Warestack resolves those names inside the connected Space, then a space admin reviews and approves the exact repositories and selections. Each referenced repository independently selects paths or directories and exactly one revision source: a branch, immutable revision, or pull request. Different repositories may use different sources; a change diff is derived only for a pull-request source.
Typical families:
- Schema contract — evaluate a source PR against an approved schema revision and its compatibility or versioning requirements.
- Database migrations — evaluate persistence changes against the approved migration policy and migration repository revision.
- Frontend / backend compatibility — compare a source PR with approved API contracts, shared scenarios, or client expectations at named revisions.
Missing, ambiguous, unauthorized, or cross-space targets are rejected, not guessed. Incomplete context is unavailable evidence, never a pass. Changes to approved referenced context durably reevaluate affected open pull requests, with immutable receipts for the source pull-request and referenced-context revisions.
Pull-request stacks remain inside one repository. Cross-repository context is evidence for an ordinary rule; it is not a multi-repository stack or a blanket read across the space. See Custom rule interpretations.