Branches, PRs & AI merges

Cloudrizz is versioned like real software. Changes are committed to feature branches, previewed in isolation, and merged into main through a pull request an org admin reviews. AI helps assess and resolve merges — but a human approves what ships.

Why main is protected

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.

The flow

  1. Commit to a feature branch — just pick a branch name when calling save_version / edit_file and it's auto-created from main. (create_branch only when forking from a non-HEAD commit.)
  2. deploy_app on the branch to get a live preview URL, backed by a throwaway database so it can't touch production data.
  3. open_pull_request with a clear title and description. One open PR per branch.
  4. An org owner/admin reviews and merges — via the dashboard or merge_pull_request. Merges are fast-forward only.

AI-assisted merges

  • describe_branch_intent — record what a branch is meant to do, so reviews and merges have context.
  • analyze_merge_risk — assess how risky merging this branch is.
  • generate_merge_candidate — have Cloudrizz produce a resolved merge for review.
  • list_pull_requests · get_pull_request · close_pull_request — manage the queue.

Previews & cleanup

Each branch (and each per-user preview) gets its own preview Worker and playground database. Merging a PR can tear the branch down for you; abandoned previews are also cleaned up automatically after a period of inactivity. Reset a branch's preview data anytime with reset_playground.

Roles matter: any member can propose changes, but merging to main requires owner/admin. See the tool reference for which tools mutate.