[jaspermayone]

Why

Quilt is a restricted app in Weave. A patch lead (for example the Ganymede lead) gets "You don't have access" at sign-in, because the patches claim does not open an app. Each lead needed a hand-made access grant.

What

• A new system group, patch-leads. Weave keeps it in line with the patch_lead governance role:
  • A lead joins when the role is granted for a program in the Knot settings (KnotGrants.any_patch_lead?).
  • A lead leaves when their last such role is revoked, or when the program leaves the Knot settings.
  • RoleGrants syncs it after each grant or revoke. The hourly SyncSystemGroupsJob fixes drift.
• Docs: docs/OAUTH.md "Patch claims" says to add the group to the app's access list, not an app role. A Quilt viewer app role on this group would let each lead read every patch. docs/KYC.md lists the group in the role flow.

flowchart LR
  G[patch_lead granted or revoked] --> RG[RoleGrants.changed!]
  RG -->|after commit| SG[SystemGroups.sync]
  SG --> PL[patch-leads group]
  PL -->|access list| Q[Quilt app, restricted]
  Q -->|patches claim| V[lead sees only their patch]

Loading

No migration.

After deploy

1. Run bin/rails groups:sync_system once, so the group exists and the current leads join it.
2. As a superadmin, add patch-leads to the Quilt app's access list.

Neither production nor staging has a group with the slug patch-leads or the name "Patch Leads", so the sync makes a new system group.

Checks

• bundle exec rspec: 2871 examples, 0 failures.
• bin/rubocop on the changed files: no offenses.
• Adversarial review (Claude reviewer; Codex is out of quota). Fixed: stale program scopes and the access-list wording. Not changed: a pre-existing manual patch-leads group would be adopted (none exists in either database), and a stale role cache in another request can re-add a membership until the hourly sync (an existing pattern for every role-based system group).