Fixed address. Fresh candidate.
Ready to leaseA 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.
One PR. One clear owner.
Ready to leaseIdle is fine. Waiting is not.
Ready to leaseArchitecture illustration—not live room status yet.
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.
Local work stays fast. Shared review becomes obvious.
No development branch, no queue before review, and no environment that quietly becomes a graveyard.
Make the feature
Build and verify on your own machine. Open the PR when there is something worth experiencing together.
Book a room
Ask your agent to claim any available room and associate its lease with the PR.
Review together
Share one URL. Combine related features from multiple designers, test the full experience, pair on fixes, and update the candidate PR.
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.
Leave it clean and quiet
Once merged, rebuild from current staging, prove the baseline, stop billable compute, and reopen the door as parked.
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.
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.
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.
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.
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 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.
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.
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.
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.
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 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.
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.
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)
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.
Separate backend, database and R2. Shared telemetry and stateless capsules.
Reset and verify after merge, then idle the room without deleting its identity.
One command API, one audit trail and one authoritative lease record.
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.
review-1.brainmo.com.Replace with the baseline or candidate asset bundle.is_test.Append-only; nothing is deleted during room reset.02 Combined candidate and staging-tip verificationHow related work meets in one room and proves itself against current staging.
- 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_shaandcandidate_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.
- 1Fence the lease
Atomically move the matching lease generation to
resetting. New claims are rejected. - 2Resolve the baseline
Fetch the current staging SHA after the merge event—not the staging SHA from when the room was claimed.
- 3Replace code
Deploy staging frontend and backend artifacts to the room's fixed destinations.
- 4Destroy mutable state
Recreate the dedicated database, wipe the dedicated R2 bucket and invalidate room-scoped sessions, caches and jobs.
- 5Rebuild known state
Run migrations, apply the versioned sanitized seed and create namespaced test identities.
- 6Prove the baseline
Run readiness plus one representative journey while the room is still running.
- 7Release and park
Close the lease, stop workers and scheduled jobs, scale or suspend eligible compute, then publish
available · parked.
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.
Can claim, release and approve according to role. Sees no infrastructure or provider secret.
Calls the same commands on the user's behalf. No shared team bearer token and no deployment credentials.
Reads PR state, writes deployment status and dispatches approved workflows. It cannot log into room databases or providers.
Deployment/reset workflows receive only the DigitalOcean, Cloudflare, database and R2 authority needed for that room.
Mistral, R2 and temporary Textract secrets stay at the provider boundary behind narrow operations.
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.
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.
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 = trueandbase.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.
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.
ready.parked, warm and their estimated idle cost honestly rather than promising zero cost it cannot deliver.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.
- 1Observe the merge
Confirm the associated PR merged into staging.
- 2Lock the door
Move the room to resetting so it cannot be claimed twice.
- 3Rebuild from staging
Deploy the new tip; recreate database and R2 state from the room seed.
- 4Prove the baseline
Run readiness and a representative journey before reopening.
- 5Release and park
Close the lease, stop background work and scale eligible compute to zero. The room remains claimable.