9-repo direct-to-main: how /consolidate keeps the network in sync

The Master OS runs across 9 git repositories: the main Dev orchestration repo, 7 brand repos (Sandbox, UMANO, VioletStudios, Suite52, Blockwise Intelligence, MaxProduct, Personal), and the wiki repo. Every one of them pushes direct-to-main.

No pull requests. No main branches protected behind review requirements. No long-lived feature branches accumulating drift.

Most engineers hear this and reach for the obvious objection: “What about code review?” The answer is that the review mechanism is the pre-merge gate — a Python hook that runs before every merge to main and blocks it if ruff is failing, pytest is red, or system_doctor reports below A 19/19. That’s the quality gate. It’s stricter than most PR review processes and it doesn’t require a second human to be available.

Why PRs are the wrong model for a single-operator multi-agent system

PRs exist to coordinate between multiple engineers working on the same codebase simultaneously. They create a review point where a second engineer can catch mistakes the first engineer missed, and they serialize the “is this ready to merge?” decision through a human approval.

In a multi-agent system with one operator, the “second engineer” role is the verifier subagent. The “is this ready to merge?” decision is the pre-merge gate. Both happen automatically, on every ticket, before any merge occurs. Adding a PR step would create operator friction without adding safety — you’d be reviewing verifier output that already ran, plus pre-merge gate output that already passed.

The operator’s time is better spent on spec quality and prioritization. Not on approving merges that the gate has already approved.

What long-lived branches actually cost

The hidden cost of long-lived branches is rebase debt. A ticket executor that works on a branch for more than a few minutes while other executors are merging to main will find its branch diverged from origin/main when it tries to push. This triggers a rebase, which may produce conflicts, which require resolution, which may require operator input.

Direct-to-main with fast executors keeps this window small. The executor runs, verifies, and merges in one session — typically under 15 minutes. The divergence window is 15 minutes, not days. Conflicts are rare; when they do occur, they’re simple.

The 9 remote branches that do exist at any moment are claude/T-* branches — one per running ticket executor, alive for the duration of the executor’s run. They’re deleted by the executor as its last step. No accumulation.

/consolidate: the session-close sweep

At the end of each session, /consolidate runs across all 9 repos:

1. It walks all repos in dependency order (brand repos → Dev → wiki).
2. For each repo, it FF-merges any claude/* branches that the pre-merge gate blocked at push time but that are otherwise clean.
3. It auto-commits chore: changes that don’t need a dedicated ticket (log rotations, session state updates, auto-generated JSON).
4. It pushes everything to origin/main for all 9 repos.
5. It deletes stale worktrees and branch refs.

The practical effect: even if the session produced merges that got stuck at the push gate (usually because the gate runs from outside the worktree and blocks the push), /consolidate sweeps them at session close. No stuck state persists across sessions.

What this is actually optimizing for

The whole design optimizes for operator throughput and system correctness over process compliance. A PR process would slow the operator. A permissive merge would degrade correctness. Direct-to-main with a hard pre-merge gate gives you both: fast merges that pass the quality bar structurally, not by operator vigilance.

The tradeoff: this pattern works for a single-operator system. It would need adjustment for a multi-operator team where “who approved this?” matters for accountability. That’s a future problem.

---

The full repo protocol is at wiki/_global/repo-protocol.md in the Master OS. The consolidate skill is at Dev/.claude/skills/consolidate/SKILL.md.