Warestack does not invent a seventh org chart. Configuration can be repository, team, path, or space scoped where the selected rule or chain supports that boundary.
| Decision | Repository-focused | Team-focused |
|---|---|---|
| Rules | Activated on named in-scope repos | Inherited by the team’s repositories |
| Live card / Review SLA | One chain per repo, one Slack channel | One chain for the team’s repos |
| Cross-repo change | Source repo + named counterpart repos | Same explicit pairs; never every repo by inference |
| Weekly digest | Space-wide rollup of those repos | Team rollup, then space rollup |
| Production changelog | On the deploy-producing repo | Same event, team or repo scope |
We will not turn on team-wide rules “because it is easier” if you asked for repository isolation. A saved repository configuration for the same catalog rule suppresses the team-scoped version.
Prefer 1–2 production repos at first even if many repos were busy. Extra repos are a later request, not a bigger day-one blast radius.
See Teams and owners for when to propose team-scoped rules and chains versus repository isolation.
Path scope
Path scope 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 scope
Space scope is for a genuinely space-owned object such as a saved report schedule. Person-owned personal_digest is also space-associated but remains private to its member.
Propose this when
| Observation | Scope |
|---|---|
| One GitHub/Warestack team owns many production repos | Team for the rule pack and live card; individual owner still required per repo |
| Two repos must stay isolated | repository |
| API + frontend or schema + migrations moved together | Named counterpart repository IDs (unknown if not loadable) — draft only |
Do not
- Turn on team-wide rules “because it is easier” if you asked for repository isolation.
- Propose a team as the Review SLA DM target.
Cross-repository guards
The control GitHub never sees: a schema change in one repo, a migration in another, a frontend contract change with no matching backend PR.
Status: not generally available. Warestack does not currently expose a self-serve cross-repository guard. Any supported setup is explicit named pairs in one space, repository IDs rather than free-form names, bounded counterpart evidence, and unknown rather than a silent pass when evidence cannot be loaded.
Typical families:
- Schema contract — schema path change → counterpart PR/commit plus compatibility or versioning evidence.
- Database migrations — persistence/schema change → migration PR plus agreed deployment order.
- Frontend / backend compatibility — API-breaking change → counterpart PR or explicit compatibility declaration and checks on named SHAs.
Missing or cross-space targets are rejected, not guessed. Updates on either side must be able to re-evaluate and clear the source finding before treating this as an operating control.
Pull-request stacks are available today but remain inside one repository. They are not cross-repository guards.