Plan-2: enforce CODEOWNERS reviews on .github/ paths once second maintainer onboards

[millsmillsymills]

Context

Pre-merge review of #17 (signed-tag verification) surfaced that .github/allowed_signers and .github/workflows/release.yml are repo-tracked and editable by anyone with write access. The default-branch ruleset enforces required status checks only — no required reviewers, no CODEOWNERS enforcement — because `require_code_owner_review` would deadlock a solo-owner repo (documented in `modules/ruleset-default-branch/main.tf`).

Within the solo-owner threat model this is accepted: the owner could add a malicious signing key in a PR and self-merge, but they could equally push directly to main via break-glass. The control set is "trust the owner."

If/when a second maintainer onboards, this control gap widens — a single rogue/compromised contributor could add a key to `allowed_signers` in a PR and self-merge to grant release-signing authority.

Proposed change at that future point

• Flip `require_code_owner_review = true` on the default-branch ruleset (currently false for the solo-owner deadlock reason in modules/ruleset-default-branch/main.tf).
• Tighten CODEOWNERS so `.github/allowed_signers` and `.github/workflows/release.yml` (and other release-trust paths) require explicit owner review.
• Consider scoping a tag-protection ruleset rule that requires modifications to those paths route via a separate `security-paths` branch protection.

Trigger

Onboarding of a second maintainer to the org. Until then, this stays parked.

References

• feat(ci): enforce signed-tag-object verification on release #17 — signed-tag-object verification (introduced `.github/allowed_signers`).
• `modules/ruleset-default-branch/main.tf` — solo-owner deadlock note.
• `CODEOWNERS` — currently `* @millsmillsymills` (not enforced).

[millsmillsymills]

🤖 Automated multi-agent issue review

Recommendation: keep-open · Priority: P3 · Effort: small · Premise still valid: True

Review. A deliberately-parked future-work issue: when a second maintainer joins the org, flip require_code_owner_review = true and tighten CODEOWNERS so release-trust paths (.github/allowed_signers, .github/workflows/release.yml) require owner review. The premise is accurate and current — the code still has the solo-owner deadlock guard and the org still has exactly one member, so the trigger has not fired. It is well-specified but not yet actionable; acting now would deadlock every owner-authored PR including the apply pipeline, which is exactly the documented reason the controls are off.

Suggested next step. Keep open as a parked tracking issue gated on its explicit trigger (a second maintainer onboarding to the org). No action while the org is solo-owner — enabling require_code_owner_review now would deadlock owner-authored PRs and the merge-apply pipeline. Optionally label it blocked/parked to signal it is intentionally not ready-for-agent; the current ready-for-human label is fine. Revisit only when org membership grows beyond one.

Adversarial re-review (concurs). premise recheck: confirmed

The review is accurate. Premise reproduces exactly against the code: ruleset has require_code_owner_review=false / require_last_push_approval=false with a documented solo-owner deadlock guard (and required_approving_review_count=0), CODEOWNERS is a single unenforced line, both release-trust paths exist, and the org still has exactly one member so the trigger has not fired. Keep-open at P3/small is correct; the only quibble is the ready-for-human label mildly over-signals readiness for a deliberately parked issue.

Open points raised:

• Minor: the reviewer called the current ready-for-human label 'fine'. It is mildly contradictory for an issue that is explicitly parked pending an external trigger (second maintainer onboarding) and not currently implementable. A blocked/parked label (which the reviewer did suggest optionally) would be more accurate than leaving ready-for-human as the primary signal.
• Borderline on actionable: false: the third proposed bullet (a tag-protection/security-paths ruleset routing modifications to release-trust paths) is arguably partially scopable today without flipping require_code_owner_review. However it would be a no-op for security without a second distinct reviewer, and the issue frames the whole change as trigger-gated, so actionable: false remains defensible.

_{Posted by a review + adversarial-review agent sweep across all open issues. No code was changed; no PRs were opened.}