Skip to content

Governance-Mode Worktree Consolidation (STANDING, 2026-07-10)

Rule

When the usage governor enters a restricted tier, active worktrees/sessions collapse into a small number of priority lanes. Lane caps by tier:

Governor tier Max active lanes
GREEN no cap (normal concurrency)
YELLOW 5
RED 3
BLACKOUT 1 (ops/triage only)

A "lane" is one live Claude session + its worktree. Everything else is absorbed: its work does not stop existing — it queues into a lane and gets done serially over time by the lane owner. Example: 9 worktrees under RED → prioritize into 3 lanes; each lane's owner drains the absorbed backlog over time.

Lane taxonomy (default 3 under RED)

  1. COMMS lane (gov:build) — fleet bus / worktree-mail / intermachine communication + Telegram monitoring surface. These are one system (fleet.v1 envelope); one session owns both.
  2. MULTI-MODEL lane (gov:orch) — multi-model tool deployment, harness parity, offload routing, BYOK/model-switcher work.
  3. OPS/GATE lane (gov:ops) — ship/merge/review gates, CI fixes, test hardening, board hygiene.

WW product work, when active under RED, replaces or shares the MULTI-MODEL lane by orchestrator decision — never exceeds the cap.

Absorption protocol (absorbed worktree)

  1. Commit WIP to its own wt/WT-xxxx/<ticket> branch (stage exact files; never git add -A in shared checkouts). Do NOT push unless already authorized.
  2. Write a compressed handoff brief (<2k tokens): ticket, state, next steps, gotchas, branch name. Deliver to lane owner via worktree-mail/bus message (kind: handoff) or session message.
  3. Update registry: worktree-identity update --id WT-xxxx --desc "ABSORBED -> WT-<lane-owner> · <ticket>" --gov bg.
  4. Session ends turn / archives. Worktree stays on disk (archive-not-delete); lane owner checks the branch out when its ticket comes up.

Lane owner duties

  • Maintain a serial queue of absorbed tickets; work one at a time.
  • Bulk implementation offloads to Codex/Gemini/Grok/local per downgrade ladder; Claude lane session = routing, review, hard decisions only (RED rules).
  • On governor return to GREEN, lanes may fan back out to per-ticket worktrees.

System integration requirements

  • Intermachine comms (fleet bus / worktree-mail): support a governance.consolidate broadcast message (fleet.v1 envelope, command tier) carrying {tier, laneCap, laneAssignments[]}. Remote PCs' listeners apply the same cap to their local sessions.
  • Telegram monitoring (fleet-telegram): under YELLOW+ report per-LANE (3 rows) not per-worktree (9 rows); alert when live session count exceeds the tier's lane cap; surface each lane's queue depth.
  • Multi-model orchestration: lane cap counts CLAUDE sessions only. Codex/Gemini/Grok/local harness workers are the offload targets and are not capped by this rule (they are capped by their own quotas), but each must be attached to a lane — no orphan harness work.

Rationale

Nine concurrent Claude sessions each pay context, hooks, memory injection, and polling overhead every turn. Three lanes doing the same tickets serially cut fixed per-session overhead ~3x and keep bulk tokens in cheap offload harnesses, at the cost of latency on lower-priority tickets — which is exactly the trade governance mode exists to make.