drift: unmanaged repo-level rulesets default-branch-baseline on MCP repos

[millsmillsymills]

Context

Surfaced during rule-insights snapshot for issue #41 (commented on PR #16). Each of the four MCP repos has a repo-level ruleset that is not declared anywhere in this tofu state:

Repo	Ruleset ID	Name	source_type	enforcement
`unifi-mcp`	16150589	`default-branch-baseline`	Repository	active
`unraid-mcp`	16150590	`default-branch-baseline`	Repository	active
`gandi-mcp`	16150591	`default-branch-baseline`	Repository	active
`protonmail-mcp`	16150592	`default-branch-baseline`	Repository	active

The ruleset enforces `required_status_checks` requiring 6 checks, plus `pull_request`, `required_linear_history`, `non_fast_forward`, `deletion` rules. It is producing failures on direct pushes to `main` (see the per-repo table in PR #16 comment): unifi-mcp 5 fails, unraid-mcp 8 fails, gandi-mcp 1 fail.

These are pre-existing — likely created via `gh ruleset` CLI or the GitHub UI before the org came under tofu management, or by tooling outside this repo.

Why this needs a decision

The org-wide evaluate→active flip (PR #16) will layer the org-wide `default-branch-protection` ruleset (ID 16259943) on top of these existing repo-level rulesets. After the flip, two rulesets will evaluate every push to a default branch on these repos:

• Repo-level `default-branch-baseline` (currently active, producing fails because no PR-driven workflows feed the required-status-checks contexts).
• Org-level `default-branch-protection` (becomes active post-flip).

Without resolving the drift, the rule-insights signal on these repos will continue to be dominated by failures from a ruleset we don't control via tofu. That makes future audits of the org-wide ruleset's behavior harder.

Decision needed

Pick one:

1. Import into tofu — extend `modules/repo-baseline` to declare a `github_repository_ruleset` resource that matches the existing shape (or a deliberately-revised shape). Then `import` block in `repos_existing.tf` to bring the four IDs into state. The 6-context required-checks list would need to be defined; current contexts unknown without inspecting one of the repos.
2. Delete — `gh ruleset delete --repo millsymills-com/` per repo, then let the org-wide ruleset be the only enforcement layer. Simpler; reduces surface; but removes whatever protection the MCP repos currently have.
3. Accept and document — leave the repo-level rulesets in place, document them in `repos_existing.tf` as known unmanaged config, and accept the perpetual rule-insights noise. Cheapest in tofu work; worst for audit clarity.

Out of scope

• The management repo's `management-repo-checks` ruleset is intentionally repo-level and declared in `repos_meta.tf`. This issue is only about the four MCP repos.

References

• PR feat(tofu): flip org rulesets from evaluate to active #16 comment with the empirical numbers: feat(tofu): flip org rulesets from evaluate to active #16 (comment)
• Issue ops: capture rule-insights snapshot in PR #16 before flipping rulesets active #41 — the snapshot work that surfaced this.
• ADR-style decision belongs in `docs/adr/` if option 1 or 2 is chosen.

[millsmillsymills]

Full ruleset inspection (2026-05-15)

Captured the exact shape of all four `default-branch-baseline` rulesets after the admin:org-scoped token refresh. All four are identical except for the ID and timestamps; this is consolidated below.

Shape (verified identical across unifi-mcp / unraid-mcp / gandi-mcp / protonmail-mcp)

```json
{
"name": "default-branch-baseline",
"target": "branch",
"enforcement": "active",
"conditions": { "ref_name": { "include": ["~DEFAULT_BRANCH"], "exclude": [] } },
"rules": [
{ "type": "deletion" },
{ "type": "non_fast_forward" },
{ "type": "required_linear_history" },
{ "type": "pull_request", "parameters": {
"required_approving_review_count": 0,
"dismiss_stale_reviews_on_push": false,
"required_reviewers": [],
"require_code_owner_review": false,
"require_last_push_approval": false,
"required_review_thread_resolution": true,
"allowed_merge_methods": ["merge","squash","rebase"]
}},
{ "type": "required_status_checks", "parameters": {
"strict_required_status_checks_policy": true,
"do_not_enforce_on_create": false,
"required_status_checks": [
{ "context": "Lint & Format" },
{ "context": "Type Check" },
{ "context": "Bandit Security Scan" },
{ "context": "Test (Python 3.13)" },
{ "context": "Dependency Review" },
{ "context": "CI Pass" }
]
}}
],
"source_type": "Repository",
"created_at": "2026-05-08T12:00:19.070-07:00"
}
```

Created 2026-05-08, three days before the org came under tofu management (2026-05-11). Likely created via UI or `gh ruleset` CLI when the MCP repos were first set up.

Interaction with the org-wide ruleset on flip

This was the load-bearing concern. After PR #16 flips ruleset 16259943 to active, both layers will evaluate every default-branch push on these repos. Comparing rules:

Rule	Org (16259943, post-flip)	Repo (default-branch-baseline)	Effect
`deletion`	block	block	redundant, harmless
`non_fast_forward`	block	block	redundant, harmless
`required_linear_history`	enforce	enforce	redundant, harmless
`pull_request` (gate)	enforce	enforce	both active, strictest wins (both have approving_count=0, both have stale-dismiss + review-thread-resolution; org sets `dismiss_stale_reviews_on_push=true`, repo sets it to `false` — org's stricter setting wins)
`creation`/`update`	allow	not in rule list	unchanged
`required_signatures`	enforce	not in rule list	org adds this; new behavior for MCP repos after flip
`required_status_checks` (6 MCP CI contexts)	not in rule list	enforce	unchanged — still required

No conflicting rules. The flip is technically safe regardless of which path is chosen for this drift. The flip does add `required_signatures` enforcement to the MCP repos — that is the intended behavior of the org-wide ruleset and matches the security baseline goal.

Recommendation

Option 1 — import into tofu. The rulesets are legitimate, working CI gates that match what the org's MCP repos need. Removing them (option 2) would drop the 6-context required-checks layer that catches CI failures pre-merge; that protection is wanted. Documenting unmanaged config (option 3) accepts permanent drift on production protection rules.

Concrete implementation steps for option 1, if chosen:

1. Extend `modules/repo-baseline` with a new optional submodule or inline resource for an opt-in default-branch ruleset, parameterized on the required-status-checks contexts list.
2. Add the 6-context list as a per-repo argument in `repos_existing.tf` for each of the four MCP repos. (Or treat the 6-context list as the MCP-baseline default and let other repos opt out.)
3. Add four `import` blocks for IDs 16150589-16150592 in `repos_existing.tf`.
4. Verify `tofu plan` shows `0 to add, 0 to change, 0 to destroy` on the four imported resources (any non-zero means the module shape doesn't exactly match the imported state and needs to be aligned).
5. Land as a single PR; the `required_signatures` addition from the org-wide flip should land separately (i.e., either before or after this import, not bundled).

Tracking this issue stays open with that recommendation; the actual implementation requires either explicit user direction or a separate plan-and-execute pass.

Why this is NOT a blocker for PR #16

The org-wide flip's behavior is independent of these repo-level rulesets — they are complementary, not conflicting. The flip can proceed on/after 2026-05-18 with this issue still open; the only cost of leaving it open is that rule-insights signal on these four repos continues to be dominated by failures from a ruleset we don't manage via tofu. That is an audit-clarity cost, not a correctness cost.

PR #16 description should be updated to note that this drift exists and is being tracked here, so a future reviewer of #16 has the context.

[millsmillsymills]

This was generated by AI during triage.

Pre-PR-#16-flip disposition (2026-05-19)

Maintainer decision today: accept-and-track; leave OPEN.

Rationale (per the 2026-05-16 comment's rule-comparison + impact analysis): the four MCP-repo default-branch-baseline rulesets are complementary, not conflicting with the org-wide default-branch-protection ruleset (16259943) that PR #16 flips to active. No rule conflicts; stricter wins on overlapping pull_request parameters; org adds required_signatures enforcement (intended new behavior).

Status: explicitly not blocking PR #16. Future work to import the four IDs into tofu state (option 1 in the original issue) remains the recommended path but is deferred — no fixed date. Reopen with implementation work when scheduled.

[millsmillsymills]

🤖 Automated multi-agent issue review

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

Review. Valid, well-specified drift tracker: four repo-level default-branch-baseline rulesets exist and are active on the MCP repos but are not declared in tofu — confirmed live and absent from the repo-baseline module. The blocking concern (interaction with PR #16's org-wide flip) was analyzed in-thread, found non-conflicting, and PR #16 has since merged, so this is now pure drift cleanup rather than a flip blocker. The maintainer already made an explicit accept-and-track / leave-OPEN decision on 2026-05-19, deferring the import-into-tofu work (option 1) with no fixed date. It is correctly a deferred enhancement, not a bug.

Suggested next step. Keep open as the deferred-work tracker; the maintainer's 2026-05-19 disposition (accept-and-track, defer option 1) still holds and is recorded on the issue. When scheduled, implement option 1: add an optional default-branch-ruleset resource to modules/repo-baseline parameterized on the 6 required-status-check contexts (Lint & Format, Type Check, Bandit Security Scan, Test (Python 3.13), Dependency Review, CI Pass — captured in the 2026-05-15 comment), add import blocks for IDs 16150589-16150592 in repos_existing.tf, and confirm tofu plan shows 0 add/change/destroy on the imports. Record the choice in docs/adr/ per the issue's own note. No action needed now beyond ensuring the ready-for-human label still reflects that this awaits scheduling/direction, not agent execution.

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

The review holds up: the premise reproduces exactly against live state and code (four active repo-level default-branch-baseline rulesets 16150589-92, source_type Repository, absent from tofu — module declares only repository + vulnerability_alerts, no ruleset resource, no import blocks). Keep-open as a deferred decision tracker is correct; P3/medium are well-calibrated since the org-wide layer now provides protection and the only cost is audit-clarity noise. No defensible objection overturns the recommendation.

Open points raised:

• Minor: the ready-for-human label could be questioned now that option 1 is fully specified (6 contexts verified live, IDs known, module shape known) — execution is largely agent-doable. But it survives scrutiny because the issue's core 'Decision needed' is an architecture/policy choice (import vs delete vs document) that the user's own standards say must be human-gated, so the label is defensible.
• The reviewer's suggested_action references putting import blocks in repos_existing.tf; I confirmed that file currently has zero import blocks for these IDs, which is consistent — but note the vulnerability_alerts import-block precedent mentioned in the module comment lives elsewhere, so the implementer should not assume repos_existing.tf is the only place imports are wired.

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