MR Main RoadGuru release practice
Day-one operating model

A review environment should feel like booking a meeting room.

Ask a colleague—or your Codex or Claude—to grab a room for a PR. Bring related work from several designers together, review the combined experience, then rebase and verify it against the latest staging tip before it merges.

01review-1
Meeting room one

Fixed address. Fresh candidate.

Ready to lease
02review-2
Meeting room two

One PR. One clear owner.

Ready to lease
03review-3
Meeting room three

Idle is fine. Waiting is not.

Ready to lease

Architecture illustration—not live room status yet.

One rule

The room belongs to one deliberate candidate. Several designers can assemble related features there, but the room keeps one associated PR and must be rebased and verified against the latest staging tip before that PR merges.

The whole process

Local work stays fast. Shared review becomes obvious.

No development branch, no queue before review, and no environment that quietly becomes a graveyard.

01Local

Make the feature

Build and verify on your own machine. Open the PR when there is something worth experiencing together.

02Claim

Book a room

Ask your agent to claim any available room and associate its lease with the PR.

03Meet

Review together

Share one URL. Combine related features from multiple designers, test the full experience, pair on fixes, and update the candidate PR.

04Verify

Meet staging tip

Freeze the reviewed work, rebase its candidate onto the latest staging tip, and verify that exact result in the merge queue before merging.

05Reset + park

Leave it clean and quiet

Once merged, rebuild from current staging, prove the baseline, stop billable compute, and reopen the door as parked.

Before you claim

First decide what PR owns the room.

A room always follows one canonical candidate PR. Designers can share that PR from the outset or combine independently useful PRs later. The agent handles assembly and records every input.

Mode A · Shared from the start

One experience, one candidate early.

Use this when several designers are jointly shaping the same journey, contract or tightly coupled change. Open the candidate PR early and name one integration owner. Designers can keep short working branches; their agents merge those heads into the candidate rather than everyone rebasing and force-pushing the same branch.

Open a shared candidate PR for this work, add PRs #238 and #239 as inputs, and associate our review room with the shared PR.
Mode B · Combine when needed

Independent work, assembled later.

Use this when each feature can stand and merge alone. Keep separate PRs until their interaction needs review. Then ask the agent to create a short-lived bundle PR from current staging, merge the exact component heads into it, and claim the room for that bundle.

Combine PRs #238 and #239 into a review candidate from staging tip, open the bundle PR, claim a room for it, and record both PRs as inputs.
Switching modes

Re-associate; never quietly mutate.

Freeze the room, create or rebuild the canonical PR from current staging plus the selected component heads, and atomically move the lease to it. Increment the generation, clear acceptance, redeploy and review again. Component PRs remain traceable and are not queued separately while bundled.

Add PR #244 to the candidate in this room. Rebuild from current staging, re-associate the lease, clear acceptance, and tell us when the combined experience is ready.
Default: share a candidate from the start only when the work is genuinely one release unit. Otherwise preserve independent PRs and combine them when interaction testing becomes valuable. Removing an input uses the same rebuild-and-reassociate flow; nobody rewrites another designer's branch. When a bundle merges, its component PRs are automatically marked as included and closed—not merged a second time.
Talk normally

Ask Codex or Claude as if you were asking a teammate.

The MCP server turns these requests into atomic leases and environment workflows. The associated PR is the integration thread for related work from one or several designers—and the unit rebased and verified against staging tip before merge.

Claim any room
Claim the next available Main Road review room for PR #241. Associate the lease with that PR, deploy its current head, and tell me when the full environment is ready.
Combine related PRs
Create a combined review candidate for PRs #238 and #239 from the latest staging tip. Open one canonical bundle PR, record both component PRs, claim a Main Road room for it, and tell me when the combined experience is ready.
Invite a colleague
Give me the current status and review URL for the room associated with PR #241 so I can invite Lagnesh to review it with me.
Refresh the candidate
Update the Main Road room for PR #241 to the latest commit on the PR. Keep the same lease and tell me when the redeploy and smoke checks pass.
Accept and queue
Mark the combined candidate in the room for PR #241 as accepted. Rebase it onto the latest staging tip, verify that exact result through the staging merge queue, and keep the room leased until the merge completes.
Release without merging
Release the room associated with PR #241 without merging it. Reset the room to current staging, reseed its data, clear its R2 namespace, verify the baseline, park its compute, and only then mark it available.
Clean up after merge
Watch PR #241. When it is merged into staging, reset and reseed the room from the new staging tip, verify the baseline, release its lease, park its compute, and confirm that it is available again.
What the MCP remembers

The conversation can stay casual because the lease is precise.

The controller records room, owner, canonical PR, component PRs, branch, candidate SHA, lease ID and expiry. Codex and Claude use the same command service as the future authenticated room console, so there is one source of truth. This public site remains the operating guide.

list_review_slots() assemble_review_candidate(prs) claim_review_slot(pr, room?) change_candidate_inputs(lease, add?, remove?) update_review_candidate(lease) accept_review_candidate(lease) release_review_slot(lease)
Approver dossier

What is actually behind each door?

The short answer remains “a full review environment.” Expand the engineering decisions below for the isolation boundary, reset transaction, key custody and control-plane design.

IsolationHard state boundaries

Separate backend, database and R2. Shared telemetry and stateless capsules.

LifecycleFixed shell, parked compute

Reset and verify after merge, then idle the room without deleting its identity.

ControlUI and MCP are peers

One command API, one audit trail and one authoritative lease record.

KeysAgents hold no infra keys

Workflows and credential capsules retain narrowly scoped secrets.

01 Isolation modelWhat is dedicated, what is shared, and where room data can travel.

Recommended day-one boundary: each room has a fixed identity and dedicated mutable product state. Shared services are allowed only when they are stateless or deliberately partitioned by room and lease.

LayerIsolationReset behavior
FrontendDedicated Worker/static deployment and proposed hostname such as review-1.brainmo.com.Replace with the baseline or candidate asset bundle.
BackendDedicated DigitalOcean App ID, runtime and environment configuration per room.Deploy the pinned candidate or current staging SHA; scale compute to zero when parked where the platform supports it.
DatabaseDedicated database or provider branch per room. No shared review schema.Drop/recreate from the sanitized room seed, migrate and verify; suspend while parked where the provider supports it.
R2Dedicated bucket per room, selected by the R2 capsule from authenticated room identity. The application receives no raw storage credentials.Delete all objects and restore only baseline seed artifacts.
AuthenticationShared staging identity provider; distinct callback URLs and namespaced seeded users.Invalidate seeded sessions and recreate test identities.
PostHogIntentionally shared staging project, tagged with room, lease, PR, SHA and is_test.Append-only; nothing is deleted during room reset.
Credential capsulesShared, stateless R2/Mistral/Textract boundaries. They authorize capability but own no product workflow.No room state to reset; every request carries room and lease context.
Not isolated: PostHog, provider accounts and the controller itself. Never shared: product database rows, R2 artifacts, application runtime or candidate deployment.
02 Combined candidate and staging-tip verificationHow related work meets in one room and proves itself against current staging.
staging base SHA+PR head SHAsynthetic candidate SHAroom deployment
  • Related changes from several designers are deliberately assembled into one candidate PR. The room is a place to experience their interactions together, not merely a preview for one isolated branch.
  • The candidate PR is canonical for the lease. Its component PR numbers and exact head SHAs are recorded as inputs, so adding or removing work is an explicit, auditable generation change.
  • When work is tightly coupled, open the canonical PR early. When work is independently useful, preserve separate PRs and create a short-lived bundle only when interaction testing is needed.
  • Component PRs cannot queue independently while included in an active bundle. When the canonical bundle merges, automation marks them as included and closes them with a link to the merge.
  • The workflow checks out the candidate PR and creates a temporary merge with the selected staging baseline. It does not push that merge back to a designer's branch.
  • A conflict fails before deployment and leaves the existing room untouched. An agent can resolve the real conflict on the PR once.
  • The lease stores base_sha, head_sha and candidate_sha. Staging moving forward does not silently alter a room under active review.
  • “Update the room” explicitly builds a new candidate and increments its generation. Review acceptance is cleared whenever the candidate SHA changes.
  • Acceptance freezes the reviewed work, not an old base. Before merge, the candidate is always rebuilt against the latest staging tip and that exact merge result must pass the required integration checks.
  • If staging advances while verification is running, the merge queue regenerates the candidate against the new tip and verifies it again. Only a green candidate based on current staging may merge.
{
  "slot": "review-2",
  "lease_id": "lease_7f2…",
  "generation": 4,
  "owner": "lagnesh",
  "pull_request": 241,
  "component_prs": [238, 239],
  "base_sha": "staging@8b7…",
  "head_sha": "feature@73a…",
  "candidate_sha": "review@129…",
  "state": "ready"
}
03 Release, reset and parkThe idempotent transaction that makes a room safe and cheap to claim again.

Reset makes a room clean; parking makes it cheap. Neither operation deletes the room's DNS, Access application or provider identity. The workflow proves a known staging baseline before releasing the lease, then stops compute that need not run while nobody owns the room.

  1. 1
    Fence the lease

    Atomically move the matching lease generation to resetting. New claims are rejected.

  2. 2
    Resolve the baseline

    Fetch the current staging SHA after the merge event—not the staging SHA from when the room was claimed.

  3. 3
    Replace code

    Deploy staging frontend and backend artifacts to the room's fixed destinations.

  4. 4
    Destroy mutable state

    Recreate the dedicated database, wipe the dedicated R2 bucket and invalidate room-scoped sessions, caches and jobs.

  5. 5
    Rebuild known state

    Run migrations, apply the versioned sanitized seed and create namespaced test identities.

  6. 6
    Prove the baseline

    Run readiness plus one representative journey while the room is still running.

  7. 7
    Release and park

    Close the lease, stop workers and scheduled jobs, scale or suspend eligible compute, then publish available · parked.

If anything fails: the room becomes quarantined, retains workflow logs and cannot be leased. Reset can safely rerun using slot + generation as its idempotency key. Parking is attempted only after verification, and a failure to park is visible as available · warm rather than concealed.
04 Keys, identity and approvalWho can ask, who can act, and where privileged credentials live.
HumanCloudflare Access identity

Can claim, release and approve according to role. Sees no infrastructure or provider secret.

Codex / ClaudePer-user remote MCP authorization

Calls the same commands on the user's behalf. No shared team bearer token and no deployment credentials.

ControllerGitHub App installation credential

Reads PR state, writes deployment status and dispatches approved workflows. It cannot log into room databases or providers.

GitHub environmentRoom-scoped infrastructure secrets

Deployment/reset workflows receive only the DigitalOcean, Cloudflare, database and R2 authority needed for that room.

Credential capsuleProvider secret store

Mistral, R2 and temporary Textract secrets stay at the provider boundary behind narrow operations.

Room applicationRuntime-only service tokens

Can use product capabilities. It cannot provision infrastructure, reset another room or retrieve provider keys.

Codex supports remote Streamable HTTP MCP servers with bearer-token or OAuth authentication; OAuth is the preferred user-attributable route. Official OpenAI MCP documentation ↗

05 Standalone UI and MCPTwo front doors, one command service and one audit history.
Human pathAccess-protected room consoleAvailability · evidence · approval · recovery
Agent pathRemote MCP endpointNatural-language claim · update · accept · release
One source of truthLease command service + durable storeAtomic transitions · audit events · PR webhook correlation
Privileged executorGitHub Actions environmentsWake · deploy · reset · seed · smoke · park · report
The standalone UI is required.

Daily use may happen through MCP, but approvers need a dependable place to see ownership, exact SHAs, reset history, smoke evidence, expiry, failures and the complete audit trail. It also provides recovery when an agent is unavailable.

The MCP is not a second controller.

It exposes the same typed commands and permissions. Tool results return the room URL, lease ID, candidate identity and workflow evidence so the assistant can explain what actually happened.

06 Merge automation and race protectionHow PR events clean the right room without stale callbacks causing damage.
  • The controller accepts a GitHub webhook only when the PR number, repository and recorded lease match.
  • Automatic cleanup requires merged = true and base.ref = staging. Closing, merging elsewhere or deleting a branch does not masquerade as a staging release.
  • The merge queue records the staging-tip SHA used for its final candidate. If the tip changes first, the candidate is regenerated and all required verification reruns before merge.
  • Every command and workflow callback carries lease_id + generation. A delayed callback from generation three cannot update generation four.
  • Webhook delivery IDs and workflow idempotency keys are recorded, making retries safe.
  • Force release is an approver-only command with an explicit reason; it always runs reset before the room can be claimed again.
available · parkedwakingprovisioningreadyacceptedqueuedresettingparkingavailable · parkedAny failed deploy/reset → quarantined
07 Parking and cost boundaryWhat survives at idle, what stops, and what happens on the next claim.

Available means claimable, not necessarily running. A parked room keeps its stable address and authority boundaries while avoiding idle application compute.

KeepStop or suspendWake on claim
Fixed identityBackend instances, workers, cron, queue consumers and polling.Start the dedicated runtime before candidate deployment.
DNS + AccessThe dedicated database branch where provider-native suspension is available.Resume or recreate the database, migrate and apply the sanitized seed.
R2 bucket + seed artifactsRoom-specific background activity; shared PostHog and stateless capsules remain request-driven.Deploy the candidate, run readiness and report the URL only when the room is ready.
Platform constraint: use provider-native scale-to-zero or suspension when it is available. Ordinary DigitalOcean App Platform scaling may retain a minimum instance, so the console must report parked, warm and their estimated idle cost honestly rather than promising zero cost it cannot deliver.
The exit is automatic

Merged means the room cleans itself—and goes quiet.

A merge into any other branch does nothing. A merge into staging resets the exact room associated with that PR, verifies the new baseline, releases its lease and parks its compute.

  1. 1
    Observe the merge

    Confirm the associated PR merged into staging.

  2. 2
    Lock the door

    Move the room to resetting so it cannot be claimed twice.

  3. 3
    Rebuild from staging

    Deploy the new tip; recreate database and R2 state from the room seed.

  4. 4
    Prove the baseline

    Run readiness and a representative journey before reopening.

  5. 5
    Release and park

    Close the lease, stop background work and scale eligible compute to zero. The room remains claimable.

Architecture companion

The road gets simpler when Sutra gets smaller.

Read the Sutra scale-down