Governance patterns: branch protection as agent gate, CODEOWNERS

The governance problem

Autonomous agents need constraints. But those constraints must be:

Enforceable — the agent can’t opt out
Configurable — operators can adjust without redeploying agents
Auditable — every approval and bypass is logged
Granular — “require human review for infra changes” != “require human review for everything”

The rig’s answer: use GitHub’s existing branch protection and CODEOWNERS system as the enforcement layer. Agents work within these constraints because they can’t merge without satisfying them — the GitHub API enforces it, not the agent’s self-discipline.

Branch protection rules

Every dashecorp/* production repo has a protected main branch with:

Required status checks:
  - ci (build + lint + test)
  - conductor-gate (Closes #N check)

Required reviews: 1
  - Dismiss stale reviews on new commits: true
  - Require review from CODEOWNERS: see CODEOWNERS section

Restrictions:
  - No direct push to main (agents included)
  - No force push
  - No branch deletion

The “1 required review” is satisfied by Review-E’s approval (she’s in the GitHub org as review-e-bot). For repos without CODEOWNERS, Review-E’s approval + CI green = auto-merge eligible.

The conductor gate

Rig-conductor registers a GitHub App that posts a required status check conductor-gate on every PR. The check passes only if:

PR body contains Closes #N or Closes owner/repo#N
No unresolved review threads
Issue is in ISSUE_ASSIGNED state (not closed, not stuck)

This prevents:

PRs that don’t close an issue (orphaned work)
PRs merged before Review-E resolves her comments
PRs for issues that were already closed by another agent

The conductor gate is separate from CI. It runs independently via webhook and can pass or fail without blocking the CI queue.

CODEOWNERS as the human veto layer

CODEOWNERS files give operators surgical control over which paths require human approval. The pattern:

# .github/CODEOWNERS in dashecorp/rig-gitops

# Anyone can review most content
* @review-e-bot

# Infrastructure changes require a human
/apps/**                  @<the-operator>
/clusters/**              @<the-operator>
/infrastructure/**        @<the-operator>

# Agent character files require human review
/apps/*/character.yaml    @<the-operator>

With this CODEOWNERS file:

A PR changing apps/dev-e/rig-agent-helmrelease.yaml requires the operator’s approval even if Review-E already approved it
A PR changing src/content/docs/research/new-doc.md only needs Review-E

This creates a two-tier governance model:

Path type	Required approver	Human involved?
Application code / docs	Review-E bot	No
Infrastructure / Helm configs	Human owner	Yes
Agent character files	Human owner	Yes
Security-sensitive files	Human owner	Yes

Why this works

No model changes required. When the operator wants to add a new sensitive path to human review, they edit .github/CODEOWNERS. They don’t retrain a model, don’t update agent prompts, don’t redeploy. The enforcement is in GitHub’s infrastructure, not in the agent’s reasoning.

Audit trail is automatic. Every PR approval, dismiss, and bypass is logged in GitHub’s audit log. The operator can answer “who approved the HelmRelease change on April 21?” from the GitHub UI.

Agents can’t bypass it. A Dev-E pod cannot merge a PR against a CODEOWNERS-protected path even if it somehow generated an approval token — GitHub’s merge API enforces CODEOWNERS before accepting the merge request.

Governance evolution

As the rig matures, governance tiers can evolve:

Phase	Trust model
Early	Every PR needs human approval
Current	Review-E approves code; human approves infra
Future	Review-E approves most things; human reviews only cost-threshold or security-classified changes

This evolution happens by changing CODEOWNERS and branch protection rules — not by changing the agents. The governance layer is intentionally decoupled from the agents so trust can be incrementally extended as the rig proves reliability.