Merge Model

A feature in RoboCo isn't one commit on one branch — it's a small tree of work that converges, as real pull requests, up a fixed chain to your repository's default branch. The rule at the top is simple and absolute: only you ever merge to master.

Branches, commits, and PRs are traceable

Every branch, commit, and pull request carries the task ID it belongs to, so your git history reads back to the work that produced it.

  • Branches follow {type}/{team}/{task-hierarchy}, where the hierarchy uses -- between levels (a / would collide with git's ref storage). Types are feature, bug, chore, docs, hotfix.

    text
    1feature/backend/ABC12345                    # a root task2feature/backend/ABC12345--DEF67890           # a subtask3feature/backend/ABC12345--DEF67890--GHI11111 # a sub-subtask (max depth)

  • Commits are auto-prefixed with the short task ID: [ABC12345] Add the auth endpoint.

  • Pull requests are titled the same way: [ABC12345] <title>.

A branch is created automatically the moment an agent claims a task, and a work session tracks its branch, base, commits, files changed, and pull request from claim to merge.

A re-claim inherits an advanced upstream base

A developer's or PM's clone is shared across tasks, so a task's branch can sit unattended for a while — long enough for its real parent branch to move on without it. When that task is re-claimed (a pool release, an unclaim, an escalation redirect), RoboCo merges the advanced upstream base into the pre-existing task branch before work resumes, so the dev isn't quietly working off a stale snapshot. A clean merge is silent (or a no-op if there was nothing new to inherit); a genuine conflict surfaces as a note on the task pointing the dev at sync_branch to resolve it by hand, rather than failing the re-claim outright.

Committed work can no longer be lost to a branch sync

The shared rebase primitive behind every one of these syncs — sync_branch, a re-claim's base inheritance, and the PM/CEO rebase action — used to reset a task's branch hard to its last-known origin state before rebasing, which silently discarded any commit an agent had made but not yet pushed. It now checks first: strictly-ahead local work is never reset, and a genuinely diverged branch reports both sides instead of picking one to throw away. A reviewer re-examining a task now also always sees the latest pushed commits, not a stale pre-sync snapshot from an earlier round — the read path that resolves a branch's tip for diffing and file reads prefers origin over a diverged local ref, the same way a fresh commit already showing up in a later QA round should behave.

Work converges up a chain

Each developer works in their own clone and opens a pull request from their branch. Those flow upward:

  1. Developers → cell. A cell's developers merge their work into the cell's branch.
  2. Cell → root. The cell PM runs submit_up to open the cell → root pull request. The Main PM keeps one integration (root) branch per repository.
  3. Root → master. The Main PM runs submit_root to open the final root → master pull request.

Each of those assembled pull requests passes through the in-path PR-review gate before its PM merges it.

Submit can happen without a PM turn

submit_up and submit_root aren't always a hand-run PM action. When every child of an assembled parent has reached a terminal state, the system runs the submit to the PR gate on the PM's behalf — the submit's real substance (freshness rebase, integrity check, opening the PR) is deterministic, so spending a whole PM turn just to press the button is wasteful. If the gate rejects the assembly (it's out of date, or fails an integrity check), it falls back to spawning the PM to handle it. The PM keeps every judgment turn — the merge itself, and any request-changes. This turn-cut is on by default (ROBOCO_PR_GATE_AUTO_SUBMIT_ENABLED) and leaves a task.auto_submitted entry in the audit trail.

Only the CEO merges to master

The final pull request — root → master — is the one place the company stops and hands the decision back to you. It lands in your CEO Approval Queue and waits.

  • The agent-facing merge path hard-refuses to target the default branch. A PM can merge a cell PR up to the root, but the merge to master is reserved for the CEO action, taken from awaiting_ceo_approval.
  • Force-push is CEO-only too.

From the queue you Approve & Merge (it ships to master), Request Changes (it loops back for another pass), or Cancel. This is the second of the only two moments the company needs you — the first being the green light that started the work.

Why a squash and one integration branch

Cell pull requests are squash-merged, so each cell's work lands as a single verified commit on the integration branch, co-authored by the agent that wrote it. The final pull request then carries one clean commit per cell — three streams of work folded into one reviewable history.

Pull requests you didn't open

Not every pull request comes from inside the company. When an external contributor or a fork opens one against your repository, the read-only PR Reviewer reads the diff against your standards and posts a single change-request on the PR — it never chats, merges, or decides. The PR then surfaces in the PR Review Queue on the Command Center, where you Supersede it (the company cuts its own branch from the contributor's commits, hardens it, opens its own PR, and links back to the original once that merges) or Dismiss it. Either way the call is yours, and the org never pushes to anyone else's fork. (This inbound-review flow is feature-flagged; see the optional-subsystems reference.)

Next

→ How agents are sandboxed — why a developer agent literally cannot perform the merge.

llms.txt