chore(governance): code-owner capacity gap in digital-employee, doc, and design-system

[PeterGuy326]

What this records

digital-employee, doc, and design-system carry the same two-owner roster, byte-identical across all three (.github/CODEOWNERS, blob c20040f9301554967e929365632b2dcb846b6b08):

# Changes require review from the organization administrator or the designated
# independent reviewer, so code-owner review is satisfiable without admin bypass.
* @PeterGuy326 @Bindy-lbb

mem carries three: * @PeterGuy326 @Bindy-lbb @waterbro-8.

The obvious maintenance action is to bring the other three repositories to the same shape. That edit cannot be made as intended, and this issue exists to record why, so that nobody later "fixes" the roster by adding an owner GitHub will ignore.

Why the obvious edit does not work

Per GitHub's code-owner documentation, "the people you choose as code owners must have write permissions for the repository"; where a listed user lacks access, "a code owner will not be assigned."

So the roster can only be widened with people who already hold write. Read back on 2026-09-11 via GET /repos/{owner}/{repo}/collaborators?affiliation=all:

repository	@PeterGuy326	@Bindy-lbb	@waterbro-8	anyone else with push
mem	admin	write	write	@jnn111 write
digital-employee	admin	write	triage	—
doc	admin	write	read	—
design-system	admin	admin	read	—

@waterbro-8 is a valid third owner in mem and is not one in the other three. Listing them there would produce an entry GitHub does not act on — a governance record asserting review capacity the repository does not have. That is the same defect class as the tag-ruleset claim corrected in bytefolk/mem#204: a configuration statement that was already false when it was written.

@jnn111 holds write in mem and appears in none of the other three repositories at any level, so they are not an available candidate either without a grant.

Is the current state a violation?

No. mem/GOVERNANCE.md sets two as a floor:

At least two owners are required so that a non-author approval is always satisfiable. Two is a floor, not a target: one owner makes the review gate structurally unsatisfiable, and two leave an availability bottleneck.

All four repositories satisfy the floor, and GET /repos/{owner}/{repo}/codeowners/errors reports 0 errors for each of .github, mem, and digital-employee as the rosters stand today. What differs is the bottleneck the charter names but does not forbid.

Why the bottleneck is worth closing

It is not theoretical. Branch protection on all three repositories was read back as enforce_admins: true, required_approving_review_count: 1, require_code_owner_reviews: true, and bypass_pull_request_allowances: null.

digital-employee#263 is authored by @PeterGuy326, so the required independent code-owner approval can come only from @Bindy-lbb. With enforce_admins: true there is no admin path around it — correctly, and this issue does not ask for one. One unavailable reviewer therefore stops the queue, and every other open digital-employee pull request sequenced behind #263 waits with it.

Decision required

Widening the roster is a role change first and a documentation change second. The charter is explicit that adding an owner "grants review authority only; it grants no tag creation, no role change", so the grant is not implied by this issue and has not been made.

Options, in ascending order of blast radius:

1. Accept the two-owner floor in these three repositories and close this issue. Cheapest. Leaves the #263-shaped bottleneck in place.
2. Grant @waterbro-8 write in digital-employee (currently triage, and already the implementation owner on digital-employee#250), then add them to that repository's roster. The smallest change that relieves the queue which is actually blocked.
3. Option 2, extended to doc and design-system (currently read in both), bringing all four repositories to three owners and matching mem.

Whichever is chosen, the roster edit must land after the grant, and the CODEOWNERS comment must stay truthful about who can actually approve.

Acceptance criteria

• A decision among options 1–3 is recorded here by the organization administrator.
• If option 2 or 3: the grant is applied first, then re-read back via GET /repos/{owner}/{repo}/collaborators?affiliation=all and the observed role_name is pasted into this issue.
• Only then, one pull request per affected repository adding the newly-eligible owner to .github/CODEOWNERS. Each such pull request needs a non-author code-owner approval, which today means @Bindy-lbb.
• GET /repos/{owner}/{repo}/codeowners/errors reports 0 for every edited repository.
• If option 1: this issue closes with that decision recorded, and no roster edit is made.

Refs bytefolk/mem#204 · Refs bytefolk/digital-employee#263