Review what came back
The batch is done and the last version is waiting on you. Try it, record what is off, and either fix it inside the version or close it and run an acceptance pass.
In the appVersion · Reviews
The batch is done and the last version is waiting on you. Try it, record what is off, and either fix it inside the version or close it and run an acceptance pass.
The batch has run. Back on the workshop's Roadmap, the versions it built are done, and the last one sits awaiting review: the agent has finished and is waiting on you.
This is the step people skip, and it is the one that decides whether the next round is small or painful. Reviewing is not reading a diff. It is using the app and recording what is wrong where it is wrong.
Two things can happen from here, and you pick on purpose. Either you fix it inside the version that is still open, or you close the version and do a proper acceptance pass over the whole app.
Open the version that is waiting
The batch has finished its run. Progress sits at the top, the version waiting on you is promoted, and the completed ones are filed underneath.
Click the version awaiting review on the roadmap. You land inside it, at the Development step, with the agent's conversation on the left and the workspace on the right.
The preview in that workspace is the app as this version built it. Click through the screens the version was supposed to deliver, sign in with a test account, load the sample data, and behave like the person the app is for.
Record what is off, from the app itself
The floating M button in the preview is the point of the exercise.
Inside the version, at the Development step. Record the session, click on what is wrong, describe it, send. You never leave the app.
Start a session and the widget captures the page, the element you clicked, and the errors the browser saw, so the report carries its own context. A note saying the IBAN field accepts an invalid format with the screen attached is worth ten written from memory an hour later. See Use the Maleus widget in the preview.
Path one: fix it in the version that is open
Everything you just recorded is already attached to this version. The Reviews tab, top right of the version next to Preview, is where you read it back.
The review you just recorded, attached to the version (the V12 badge). On the right: the errors seen during the session, then your notes, page by page.
Pick a review, read the notes and the trace, then hand it over with Process with agent. The agent is still in the version, still has its context, and fixes it there. Nothing new is queued and nothing is rebuilt from scratch.
This is the right path while the version is open and the problems are contained: a wrong label, a broken validation, a layout that breaks below the fold.
Path two: close it, then run an acceptance pass
When the version is right, mark it Done. It moves to Ready to Deploy on the versions list.
Now test the whole app rather than one version's worth of it. App Preview in the project sidebar runs your app outside any version: the same preview browser, with no agent and no step attached. It is the honest way to look, because you are using the thing rather than watching it being built. See Open your app without a version.
Record what you find with the same widget. Those reviews land in App Reviews at the project level, unlinked to any version.
The project-level queue: everything recorded, whether or not it belongs to a version.
Read them, then decide, with the two buttons in the header:
Create workshop is the acceptance pass made into work: the session opens with those reviews as its input, you talk it through, and you come out with a fresh pipeline of versions. Maleus suggests it itself when the pile gets deep: that is a lot of reviews for one version, a workshop can split the fixes across several versions.
That is how round two starts, and it is the same step two you already did. See Triage app reviews.
Promote what is good
A version you are happy with moves on. From Versions, the ones under Ready to Deploy carry a Promote to action: pick a deployment target and its code is pushed to that branch. Then watch it from the Deployments page. See Deploy a version.
Review before you promote, not after. A review recorded against a preview costs one round of work; the same thing found in production costs a rollback and the conversation that comes with it.
That is the loop
Project, workshop, batch, review, and back to the workshop. You have been round it once.
From here the rest of the documentation goes deeper on each surface: what happens inside a version, the audit scores, and the settings that carry across versions.