Branches, PRs & merges

You can't commit straight to main, save_version and edit_file refuse it. Work goes on a feature branch and reaches main only via a merged pull request. This keeps production deployable and gives every change a review point.

1. Commit to a feature branch, just pick a branch name when calling save_version / edit_file and it's auto-created from main. (manage_branch (action: create) only when forking from a non-HEAD commit.)
2. deploy_app on the branch to get a live preview URL, backed by the branch's own throwaway sandbox so it can't touch production data.
3. manage_pull_request (action: open) with a clear title and description. One open PR per branch.
4. An app admin reviews and merges, via the dashboard or merge_pull_request. If the target hasn't moved the merge fast-forwards; if it advanced but the two branches touched different files, or the same file in non-overlapping places (e.g. opposite ends), Cloudrizz merges them automatically. Only when both sides changed the same lines of a file do you resolve a conflict (below).

If main moved on while your branch was open and you both edited the same file, Cloudrizz first tries a line-level merge: if your changes and main's are in different parts of the file, it merges them for you automatically, two branches editing opposite ends of one big file no longer collide. Only when both sides changed the same lines does merge_pull_request return a conflict (with merged: false) listing each clashing file with three versions: the common base, the current main, and your branch. Cloudrizz never auto-resolves overlapping edits with AI, you reconcile those. The loop:

1. Read the base / main / branch contents in the conflict and write the reconciled version back to your source branch with save_version / edit_file.
2. Call merge_pull_request again with resolvedAgainstTargetHead set to the targetHead from the conflict, that tells Cloudrizz you've reconciled against that exact state of main.
3. If main moved again in the meantime you simply get a fresh conflict (or a 409), nothing is merged or lost; re-resolve against the new targetHead.

• manage_pull_request (action: list/get/close), list open PRs, inspect one (with its canFastForward merge status), or close one without merging.
• merge_pull_request, the real merge. Disjoint changes, and non-overlapping edits to the same file, auto-merge; only for overlapping edits (the same lines on both sides) does it hand you each file's base/main/branch versions to reconcile. Cloudrizz never AI-generates a merged result.

Running several assistants against one app at once? manage_branch (action: list) is the shared status board so they don't step on each other. For every branch it returns how far it is ahead of and behind main, behind > 0 means main has moved on since that branch last synced, so pull it up to date with merge_from_main before you drift further. It also lists each branch's migration files and, across all branches, the next free migration number, so two branches don't both grab the same number and clash at merge time.

Each branch gets its own preview instance and its own playground sandbox (a separate database and storage), so parallel branches never share, or contend on, the same data. Merging a PR can tear the branch and its sandbox down for you, and manage_branch (action: delete) removes one on demand (its commits stay on main); abandoned branch previews are cleaned up automatically once the branch is merged or goes stale, and per-user main previews after a period of inactivity. Reset a sandbox anytime with reset_playground (pass a branch to target that branch's data).