Vibe Studio Enterprise
Enterprise Engineering Review System
Enterprise Engineering Review System
Enterprise Engineering Review System
Enterprise Engineering Review System
Human in Loop
Human in Loop
Human in Loop
This guide walks through the three parts of the Enterprise workflow: approving a change, letting review agents check it first, and finding anything that shipped in Build history.
This guide walks through the three parts of the Enterprise workflow: approving a change, letting review agents check it first, and finding anything that shipped in Build history.
This guide walks through the three parts of the Enterprise workflow: approving a change, letting review agents check it first, and finding anything that shipped in Build history.
In this guide
In this guide
In this guide
In this guide
Three chapters. Read them in order the first time, then use this page to look things up.
Three chapters. Read them in order the first time, then use this page to look things up.
Three chapters. Read them in order the first time, then use this page to look things up.
Chapter 1
Approve or reject a change
Approve or reject a change
Approve or reject a change
See what Vibe Studio built, compare it with what is live, then approve it or send it back.
See what Vibe Studio built, compare it with what is live, then approve it or send it back.
5 steps
Chapter 2
Review agents
Review agents
Review agents
Put a check in front of every merge so nothing reaches your live app unreviewed.
Put a check in front of every merge so nothing reaches your live app unreviewed.
5 steps
Chapter 3
Build history
Build history
Every version you have ever shipped, in plain language, with a way back.
Every version you have ever shipped, in plain language, with a way back.
2 views
CHAPTER 1
Approve or reject a change
Approve or reject a change
Approve or reject a change
Approve or reject a change
Vibe Studio never edits your live app. Every build lands on its own branch and everything you review is a preview deployed to its own URL. Approving marks the change ready to go. On Enterprise the merge that puts it in front of your users belongs to an engineer, so nothing here can release by accident.
Vibe Studio never edits your live app. Every build lands on its own branch and everything you review is a preview deployed to its own URL. Approving marks the change ready to go. On Enterprise the merge that puts it in front of your users belongs to an engineer, so nothing here can release by accident.
Vibe Studio never edits your live app. Every build lands on its own branch and everything you review is a preview deployed to its own URL. Approving marks the change ready to go. On Enterprise the merge that puts it in front of your users belongs to an engineer, so nothing here can release by accident.
1
Vibe Studio tells you the new version is ready
Vibe Studio tells you the new version is ready
Vibe Studio tells you the new version is ready
Vibe Studio tells you the new version is ready
When a build finishes, a card lands at the bottom of the chat. It repeats what you asked for, says what changed, and shows a green Tested & safe chip once the Flutter build passed and the app booted cleanly in the simulator. That card is the plain-language face of a pull request: Vibe Studio committed the work to a branch and opened the PR.
When a build finishes, a card lands at the bottom of the chat. It repeats what you asked for, says what changed, and shows a green Tested & safe chip once the Flutter build passed and the app booted cleanly in the simulator. That card is the plain-language face of a pull request: Vibe Studio committed the work to a branch and opened the PR.
When a build finishes, a card lands at the bottom of the chat. It repeats what you asked for, says what changed, and shows a green Tested & safe chip once the Flutter build passed and the app booted cleanly in the simulator. That card is the plain-language face of a pull request: Vibe Studio committed the work to a branch and opened the PR.
The simulator keeps running the new version while you decide.
The simulator keeps running the new version while you decide.
UNDER THE HOOD
push → GitHub webhook · commit on Vibe Studio/feat-signin-brand · PR opened
2
Put the new version next to the live one
Put the new version next to the live one
Put the new version next to the live one
Put the new version next to the live one
Above the simulator, the preview tabs list every build that is live right now: the change Vibe Studio just made, and any branch or pull request your engineers have open. Main is your production app. Each other tab is a Firebase Hosting preview channel on its own stable URL, so what you click is the real build and not a mockup. Switch between them, or put any two side by side. Approve and reject only appear on changes Vibe Studio built for you. Engineer branches are view-only.
Above the simulator, the preview tabs list every build that is live right now: the change Vibe Studio just made, and any branch or pull request your engineers have open. Main is your production app. Each other tab is a Firebase Hosting preview channel on its own stable URL, so what you click is the real build and not a mockup. Switch between them, or put any two side by side. Approve and reject only appear on changes Vibe Studio built for you. Engineer branches are view-only.
Above the simulator, the preview tabs list every build that is live right now: the change Vibe Studio just made, and any branch or pull request your engineers have open. Main is your production app. Each other tab is a Firebase Hosting preview channel on its own stable URL, so what you click is the real build and not a mockup. Switch between them, or put any two side by side. Approve and reject only appear on changes Vibe Studio built for you. Engineer branches are view-only.
You can even compare two engineer pull requests against each other.
You can even compare two engineer pull requests against each other.
UNDER THE HOOD
preview = Firebase Hosting channel · stable URL · compare any two
3
Approve, or send it back
Approve, or send it back
Approve, or send it back
Approve, or send it back
Approve marks the change ready to go. Reject closes the pull request, deletes the branch and puts the app back exactly as it was. Neither button touches main, so nothing your users see moves at this point and there is no decision here you cannot walk back from.
Approve marks the change ready to go. Reject closes the pull request, deletes the branch and puts the app back exactly as it was. Neither button touches main, so nothing your users see moves at this point and there is no decision here you cannot walk back from.
Approve marks the change ready to go. Reject closes the pull request, deletes the branch and puts the app back exactly as it was. Neither button touches main, so nothing your users see moves at this point and there is no decision here you cannot walk back from.
Rejecting drops you back into the build loop, which is where most changes get better.
Rejecting drops you back into the build loop, which is where most changes get better.
UNDER THE HOOD
approve = squash-merge + promote channel · reject = close PR + delete branch
4
Look through the saved versions
Look through the saved versions
Look through the saved versions
See version history opens the full list. Every version is there with the time it was saved and a one line description of what changed. The green dot marks the one you are on. Each entry is a commit on the branch, and Restore checks an earlier one back out into your draft.
See version history opens the full list. Every version is there with the time it was saved and a one line description of what changed. The green dot marks the one you are on. Each entry is a commit on the branch, and Restore checks an earlier one back out into your draft.
Restore an earlier version, or send the one you are on for review.
Restore an earlier version, or send the one you are on for review.
UNDER THE HOOD
each saved version = a commit · Restore = checkout that commit
5
Send it for a final check
Send it for a final check
Send it for a final check
On an Enterprise app the button reads Send for final check, and it does what it says: nothing goes live yet. It marks the change approved, fires a Slack message to your engineering team, and drops the pull request into their admin-portal review queue. An engineer merges it to main, or returns it to you with a note on what to change. The merge is the only thing your users ever see.
On an Enterprise app the button reads Send for final check, and it does what it says: nothing goes live yet. It marks the change approved, fires a Slack message to your engineering team, and drops the pull request into their admin-portal review queue. An engineer merges it to main, or returns it to you with a note on what to change. The merge is the only thing your users ever see.
On an Enterprise app the button reads Send for final check, and it does what it says: nothing goes live yet. It marks the change approved, fires a Slack message to your engineering team, and drops the pull request into their admin-portal review queue. An engineer merges it to main, or returns it to you with a note on what to change. The merge is the only thing your users ever see.
Returned work comes back with the engineer note attached, ready to iterate and resubmit.
Returned work comes back with the engineer note attached, ready to iterate and resubmit.
UNDER THE HOOD
approve → Slack webhook → admin review queue → squash-merge to main
CHAPTER 2
CHAPTER 2
Review agents
Review agents
Review agents
Review agents are the automated gate. They run against the pull request every time a change is ready, and report pass, fail or pending. A required agent blocks the merge until it passes, an advisory one only leaves a note. They never merge anything themselves. Their job is to catch what a person should not have to.
Review agents are the automated gate. They run against the pull request every time a change is ready, and report pass, fail or pending. A required agent blocks the merge until it passes, an advisory one only leaves a note. They never merge anything themselves. Their job is to catch what a person should not have to.
Review agents are the automated gate. They run against the pull request every time a change is ready, and report pass, fail or pending. A required agent blocks the merge until it passes, an advisory one only leaves a note. They never merge anything themselves. Their job is to catch what a person should not have to.
1
See what changed before anything runs
See what changed before anything runs
See what changed before anything runs
Vibe Studio posts a short summary in the chat: which version the work landed on, which files it touched, and how many lines moved. The panel on the right is the pull request diff, green for added lines and red for removed. Nobody has to read that to make a decision, but it is there when someone wants it.
Vibe Studio posts a short summary in the chat: which version the work landed on, which files it touched, and how many lines moved. The panel on the right is the pull request diff, green for added lines and red for removed. Nobody has to read that to make a decision, but it is there when someone wants it.
Vibe Studio posts a short summary in the chat: which version the work landed on, which files it touched, and how many lines moved. The panel on the right is the pull request diff, green for added lines and red for removed. Nobody has to read that to make a decision, but it is there when someone wants it.
Press Review changes when you are ready.
Press Review changes when you are ready.
UNDER THE HOOD
diff = Dart / Flutter changed files on the PR
2
Let the review agent work
Let the review agent work
Let the review agent work
The agent runs on opencode and works through a checklist against the code as it stands on the branch, reporting as it goes: finished, running now, still queued. It takes a moment because it is reading the change, not just checking that the build compiled. Nothing merges while this runs.
The agent runs on opencode and works through a checklist against the code as it stands on the branch, reporting as it goes: finished, running now, still queued. It takes a moment because it is reading the change, not just checking that the build compiled. Nothing merges while this runs.
The agent runs on opencode and works through a checklist against the code as it stands on the branch, reporting as it goes: finished, running now, still queued. It takes a moment because it is reading the change, not just checking that the build compiled. Nothing merges while this runs.
The review is never automatic. It starts when someone asks for it.
The review is never automatic. It starts when someone asks for it.
UNDER THE HOOD
review agent (opencode) runs on the PR head commit
3
Read the finding in plain language
Read the finding in plain language
Read the finding in plain language
If the agent finds something, it explains what it is, how much it matters, and which file and line it came from. No jargon, no stack traces. Fix it with Vibe Studio pushes another commit to the same branch and re-runs the checks. Talk to a human engineer hands it to a person on your team.
If the agent finds something, it explains what it is, how much it matters, and which file and line it came from. No jargon, no stack traces. Fix it with Vibe Studio pushes another commit to the same branch and re-runs the checks. Talk to a human engineer hands it to a person on your team.
If the agent finds something, it explains what it is, how much it matters, and which file and line it came from. No jargon, no stack traces. Fix it with Vibe Studio pushes another commit to the same branch and re-runs the checks. Talk to a human engineer hands it to a person on your team.
The flagged line is marked in the diff, so you can see it in context.
The flagged line is marked in the diff, so you can see it in context.
UNDER THE HOOD
finding → file + line in the diff
4
Clear the checks
Clear the checks
Clear the checks
Once the fix is in and the review runs clean you get an all clear: no problems found, every check passed. Passing the required checks is what unlocks approval. An advisory failure will still let you through, it just travels with the change as a note.
Once the fix is in and the review runs clean you get an all clear: no problems found, every check passed. Passing the required checks is what unlocks approval. An advisory failure will still let you through, it just travels with the change as a note.
Once the fix is in and the review runs clean you get an all clear: no problems found, every check passed. Passing the required checks is what unlocks approval. An advisory failure will still let you through, it just travels with the change as a note.
Approve stays disabled until every required check is green.
Approve stays disabled until every required check is green.
UNDER THE HOOD
required checks must pass before merge is enabled
5
Approval hands it over, the merge makes it live
Approval hands it over, the merge makes it live
Approval hands it over, the merge makes it live
Approving clears the automated gate and moves the pull request into your engineers’ review queue, with a Slack notification attached. An engineer merges it to main or returns it with a note. When the merge lands, the preview you have been clicking through becomes the live app, and the chat confirms it with the branch name and where it went.
Approving clears the automated gate and moves the pull request into your engineers’ review queue, with a Slack notification attached. An engineer merges it to main or returns it with a note. When the merge lands, the preview you have been clicking through becomes the live app, and the chat confirms it with the branch name and where it went.
Approving clears the automated gate and moves the pull request into your engineers’ review queue, with a Slack notification attached. An engineer merges it to main or returns it with a note. When the merge lands, the preview you have been clicking through becomes the live app, and the chat confirms it with the branch name and where it went.
Merged or returned, it reaches you the moment it happens, no refresh, with a link into Build history.
Merged or returned, it reaches you the moment it happens, no refresh, with a link into Build history.
UNDER THE HOOD
PR squash-merged · channel promoted · Firestore push, no reload
CHAPTER 3
Build history
Build history
Build history
Approvals, rejections, fixes, engineer notes and releases all end up in the same place. Build history is the record: what happened, when, who it was waiting on, and a way back to any earlier version. Every entry is a commit, with the pull request it belonged to and the preview it was deployed to.
Approvals, rejections, fixes, engineer notes and releases all end up in the same place. Build history is the record: what happened, when, who it was waiting on, and a way back to any earlier version. Every entry is a commit, with the pull request it belonged to and the preview it was deployed to.
Approvals, rejections, fixes, engineer notes and releases all end up in the same place. Build history is the record: what happened, when, who it was waiting on, and a way back to any earlier version. Every entry is a commit, with the pull request it belonged to and the preview it was deployed to.
1
Open the history next to the chat
Open the history next to the chat
Open the history next to the chat
Build history sits at the top of the window beside Chat with AI. Opening it swaps the chat rail for a feed of everything that has happened to this app, newest first and grouped by day. The simulator stays where it is, so you can read the history and look at the app at the same time.
Build history sits at the top of the window beside Chat with AI. Opening it swaps the chat rail for a feed of everything that has happened to this app, newest first and grouped by day. The simulator stays where it is, so you can read the history and look at the app at the same time.
Build history sits at the top of the window beside Chat with AI. Opening it swaps the chat rail for a feed of everything that has happened to this app, newest first and grouped by day. The simulator stays where it is, so you can read the history and look at the app at the same time.
Orange is still building, amber needs your review, green is live on main, grey is saved to your draft.
UNDER THE HOOD
feed = commits, PRs, preview deploys, merges
2
Open a version to see the detail
Open a version to see the detail
Open a version to see the detail
A single entry opens into what actually changed, in the same plain language as the rest of the product, with the steps the build went through underneath. Try it yourself points at the simulator so you can check the change instead of taking the summary on trust. If an engineer returned the change, their note sits here too.
A single entry opens into what actually changed, in the same plain language as the rest of the product, with the steps the build went through underneath. Try it yourself points at the simulator so you can check the change instead of taking the summary on trust. If an engineer returned the change, their note sits here too.
A single entry opens into what actually changed, in the same plain language as the rest of the product, with the steps the build went through underneath. Try it yourself points at the simulator so you can check the change instead of taking the summary on trust. If an engineer returned the change, their note sits here too.
Keep it and Undo it sit at the bottom if the entry is still waiting on you.
Keep it and Undo it sit at the bottom if the entry is still waiting on you.
UNDER THE HOOD
entry = commit + preview channel URL + merge SHA
Who does what
Who does what
Three parties touch a change, and only one of them can put it on main.
Three parties touch a change, and only one of them can put it on main.
You, the client
You, the client
Prompt Vibe Studio, click through the preview, approve or reject. Approving marks a change ready and notifies your team. You have no write access to main, which is what makes approving safe.
cannot merge
Review agents
Run against the pull request whenever a change is sent for review and report pass, fail or pending. Required agents block approval until they pass. Advisory ones travel along as a note.
automated checks on the PR
Your engineers
Your engineers
Get the Slack notification, work the review queue in the admin portal, then merge to main or return the change with a note. They can also build any branch or PR into its own preview for you to see, straight from their dashboard.
the only role that can merge
Nothing reaches main without an engineer merge. Approving is how you say the change is right, not how it ships.
Nothing reaches main without an engineer merge. Approving is how you say the change is right, not how it ships.
The same thing, in two languages
The same thing, in two languages
The product speaks plainly on purpose. If you work with the repository, or you are sitting next to someone who does, here is the same vocabulary on both sides.
The product speaks plainly on purpose. If you work with the repository, or you are sitting next to someone who does, here is the same vocabulary on both sides.
What you see
What it is
New version
New version
A branch, cut from main and named for what it does, like Vibe Studio/feat-add-height-input.
A branch, cut from main and named for what it does, like Vibe Studio/feat-add-height-input.
A branch, cut from main and named for what it does, like Vibe Studio/feat-add-height-input.
Change
Change
A commit on that branch.
A commit on that branch.
A commit on that branch.
Sent for review
Sent for review
A pull request, open and waiting.
A pull request, open and waiting.
A pull request, open and waiting.
Preview
Preview
A deploy of the branch on its own stable URL, in a pending state.
A deploy of the branch on its own stable URL, in a pending state.
A deploy of the branch on its own stable URL, in a pending state.
Live
Live
main, the branch your users are served from.
main, the branch your users are served from.
main, the branch your users are served from.
Approved
Approved
Sent for a final check: the pull request marked ready and queued for an engineer.
Sent for a final check: the pull request marked ready and queued for an engineer.
Sent for a final check: the pull request marked ready and queued for an engineer.
Merged
Merged
The pull request squash-merged into main, so the preview becomes the live app.
The pull request squash-merged into main, so the preview becomes the live app.
The pull request squash-merged into main, so the preview becomes the live app.
Rejected
Rejected
The pull request closed and the branch deleted.
The pull request closed and the branch deleted.
The pull request closed and the branch deleted.
Returned to you
Returned to you
The pull request left open with an engineer note attached.
The pull request left open with an engineer note attached.
The pull request left open with an engineer note attached.
Roll back
Roll back
An earlier commit restored, and shipped the same way as any other change.
An earlier commit restored, and shipped the same way as any other change.
An earlier commit restored, and shipped the same way as any other change.
Approving from your phone
Approving from your phone
Approving from your phone
Approving from your phone
The same decisions are on mobile, in the same order. Reviews rarely wait for someone to get back to a desk, so the approve card, the compare view and the publish confirmation all work at phone width, in light and dark.
The same decisions are on mobile, in the same order. Reviews rarely wait for someone to get back to a desk, so the approve card, the compare view and the publish confirmation all work at phone width, in light and dark.
The same decisions are on mobile, in the same order. Reviews rarely wait for someone to get back to a desk, so the approve card, the compare view and the publish confirmation all work at phone width, in light and dark.
Approve or reject
Compare before you decide
Live for your users
Good to know
Good to know
Good to know
Nothing is ever lost
Nothing is ever lost
Rejected work stays in Build history with everything else. Nothing is deleted from the record, only the branch is, and the commits behind it are still reachable.
Rejected work stays in Build history with everything else. Nothing is deleted from the record, only the branch is, and the commits behind it are still reachable.
Required and advisory
Required and advisory
A required agent blocks approval until it passes. An advisory one travels along as a note. Neither of them merges anything, that part belongs to your engineers.
A required agent blocks approval until it passes. An advisory one travels along as a note. Neither of them merges anything, that part belongs to your engineers.
Your work stays off main
Your work stays off main
Approving saves to your branch and deploys a preview on its own URL. Your users keep seeing main until an engineer merges, which is why you can approve all morning and release once.
Approving saves to your branch and deploys a preview on its own URL. Your users keep seeing main until an engineer merges, which is why you can approve all morning and release once.
It updates on its own
It updates on its own
When an engineer merges or returns your change, Vibe Studio shows it right away without a reload. Build history keeps the record either way.
When an engineer merges or returns your change, Vibe Studio shows it right away without a reload. Build history keeps the record either way.
Questions that come up
Questions that come up
Questions that come up
Questions that come up
Why did approving not put my change live?
Why did approving not put my change live?
Why did approving not put my change live?
Because on Enterprise approving is a request, not a release. It marks the pull request ready, notifies your engineers in Slack, and puts it in their review queue. The merge to main is what your users see, and an engineer makes it.
Because on Enterprise approving is a request, not a release. It marks the pull request ready, notifies your engineers in Slack, and puts it in their review queue. The merge to main is what your users see, and an engineer makes it.
Because on Enterprise approving is a request, not a release. It marks the pull request ready, notifies your engineers in Slack, and puts it in their review queue. The merge to main is what your users see, and an engineer makes it.
What happens when an engineer returns a change?
What happens when an engineer returns a change?
What happens when an engineer returns a change?
It comes back to you with their note attached and the pull request still open. You iterate with Vibe Studio on the same branch and resubmit. Nothing is lost in the handover.
It comes back to you with their note attached and the pull request still open. You iterate with Vibe Studio on the same branch and resubmit. Nothing is lost in the handover.
What happens to a change I reject?
What happens to a change I reject?
What happens to a change I reject?
The pull request closes and the branch is deleted, so the app goes back to how it was. The attempt stays in Build history, so you can see what was tried and ask for it again.
The pull request closes and the branch is deleted, so the app goes back to how it was. The attempt stays in Build history, so you can see what was tried and ask for it again.
The pull request closes and the branch is deleted, so the app goes back to how it was. The attempt stays in Build history, so you can see what was tried and ask for it again.
Can I approve one change and hold another?
Can I approve one change and hold another?
Can I approve one change and hold another?
Yes. Each change lives on its own branch with its own preview, so they do not queue behind each other. Your engineers merge them in whatever order makes sense.
Yes. Each change lives on its own branch with its own preview, so they do not queue behind each other. Your engineers merge them in whatever order makes sense.
Yes. Each change lives on its own branch with its own preview, so they do not queue behind each other. Your engineers merge them in whatever order makes sense.
What do review agents actually check?
What do review agents actually check?
What do review agents actually check?
Whatever you set them up to check: security, accessibility, mobile layout, performance, brand rules. Each returns pass, fail or pending against the pull request, and you choose which of them are allowed to block approval.
Whatever you set them up to check: security, accessibility, mobile layout, performance, brand rules. Each returns pass, fail or pending against the pull request, and you choose which of them are allowed to block approval.
Whatever you set them up to check: security, accessibility, mobile layout, performance, brand rules. Each returns pass, fail or pending against the pull request, and you choose which of them are allowed to block approval.
Do I need to read the code to approve?
Do I need to read the code to approve?
Do I need to read the code to approve?
No. Every screen leads with a plain summary of what changed, and the preview is the real build, so clicking through it tells you more than the diff will. The diff is on the right for whoever wants it.
No. Every screen leads with a plain summary of what changed, and the preview is the real build, so clicking through it tells you more than the diff will. The diff is on the right for whoever wants it.
No. Every screen leads with a plain summary of what changed, and the preview is the real build, so clicking through it tells you more than the diff will. The diff is on the right for whoever wants it.
Who on my team can approve?
Who on my team can approve?
Who on my team can approve?
Anyone with review rights on the project. Whoever approved is recorded on the entry in Build history along with the time, and the merge is recorded against the engineer who made it.
Anyone with review rights on the project. Whoever approved is recorded on the entry in Build history along with the time, and the merge is recorded against the engineer who made it.
Anyone with review rights on the project. Whoever approved is recorded on the entry in Build history along with the time, and the merge is recorded against the engineer who made it.
Do I have to use the chat to make every change?
Do I have to use the chat to make every change?
Do I have to use the chat to make every change?
No. Your engineers develop outside the app builder, and when they push to a branch Vibe Studio rebuilds it and stages the same review card you would get from a chat build. You review it the same way.
No. Your engineers develop outside the app builder, and when they push to a branch Vibe Studio rebuilds it and stages the same review card you would get from a chat build. You review it the same way.
No. Your engineers develop outside the app builder, and when they push to a branch Vibe Studio rebuilds it and stages the same review card you would get from a chat build. You review it the same way.
Can I add a teammate who has no Vibe Studio account yet?
Can I add a teammate who has no Vibe Studio account yet?
Can I add a teammate who has no Vibe Studio account yet?
Yes. Grant access by their email and they get an invitation. Their access turns on the moment they sign up, so you do not have to come back and do it again.
Yes. Grant access by their email and they get an invitation. Their access turns on the moment they sign up, so you do not have to come back and do it again.
Yes. Grant access by their email and they get an invitation. Their access turns on the moment they sign up, so you do not have to come back and do it again.
