How a build works

LoopCodeLab turns your idea into a plan of stories. Agents can build those stories in parallel. A master agent reviews each piece, merges accepted work, and runs a final check before delivery.

1 Idea · 2 Plan · 3 Build in parallel · 4 Review · 5 Integrate and verify · 6 Deliver

The path to delivery

1. You describe the result you want.
2. The planner turns it into stories.
3. Workers build the stories.
4. The master agent reviews and integrates the accepted work.
5. A final pass checks that the pieces fit together.
6. LoopCodeLab delivers the live preview and repository, plus any app or media artifacts for the selected output.

Stage	What you can do	What LoopCodeLab does
Plan	Clarify the idea and edit stories	Chooses an output and defines acceptance criteria
Build	Watch progress or swap a stuck worker	Runs independent stories, often in parallel
Review	Follow decisions in the activity feed	Checks each result before accepting it
Delivery	Open, install, or download artifacts	Integrates the work and runs a final verification

Stories are editable units of work

A story is one defined piece of the build. It has a title, a brief, and acceptance criteria. You can edit or remove stories during review, before the build starts.

Use a planning reference

Before starting, you can generate a mockup in chat or attach an item from the shared Assets library. A generated mockup comes from the configured image-generation provider; it is a planning reference for the agents, not an image scraped from another website.

LoopCodeLab resolves an attached item from your workspace library, copies the canonical file into the build, and links it to every planned story. This gives the planner, workers, and story dialogs one consistent reference, including when an Auto build is planned as a web app. The original remains available in the shared Assets library for reuse.

Follow and control a live build

When the current chat is linked to a build, desktop shows Live preview and Live Build in the left sidebar. In the collapsed icon rail they appear as Preview and Build. Live Build opens the story controls beside the conversation and includes a Full build link; the chat remains the activity log.

While work is active, the conversation shows a temporary assistant-style status bubble such as “Claude is building S-02 · Checkout” or “Master is finalizing the build.” It follows the existing live build updates, names the current worker or reviewer and story, and disappears automatically when that state ends. It is a live status indicator, not a saved chat message.

Each story card shows its Worker and the build-wide Master reviewer. An unresolved story offers Edit, Schedule, and Skip, even if it is building, in review, failed, or blocked. A scheduled story also offers Start now. A failed story has a direct Retry action that queues a fresh attempt and re-evaluates stories blocked by the failure. It starts when a worker slot is available; if the build is paused, choose Resume first. Skipped and reverted stories are read-only.

Click a merged story card, or its Regenerate action, to open the existing regeneration dialog. The dialog includes that story’s assets and lets you adjust the title, instructions, acceptance criteria, connected Worker, and connected Master before rebuilding on the current app. The same dialog handles Edit and Schedule. Its schedule offers Preserve current, Start now, In 30 minutes, In 2 hours, In 1 day, and a custom exact date and time in your local time zone. Scheduling active work stops that attempt, discards its unmerged changes, and queues the story for the chosen time. Skip asks for confirmation because it stops the attempt, removes its schedule, and lets dependent stories continue.

For a web app, the same story dialog includes a compact Story assets strip below the story controls. It shows the number of linked assets in a one-column list; when there are more than three, use View all and Collapse. Assets already merged into that story can be opened or downloaded while the build is active. Regenerate for supported images and Replace for editable files unlock when the build settles as Done, Failed, or Push failed. This lets you repair a merged asset even when another story or the final build check failed. They remain locked while work is queued, building, in review, finalizing, or being delivered.

One asset can support several stories, so it can appear in more than one story popup. Use the finished build’s main Assets tab for the complete build gallery, story-link management, and version history. Files with no story link remain there as Unassigned. The separate Assets entry in the account/sidebar area remains the reusable workspace-wide gallery.

Live Build, Live preview, and Edit share the same right-side workspace, so opening one closes the others. Use Collapse chat to give the active pane the full width and Show chat to restore the conversation. Live Build and Live preview can also collapse into slim side docks that reopen when clicked. These desktop controls are hidden on mobile.

When something goes wrong

The build system watches for stalled work and can nudge or retry it. It can identify a bad provider key as an account problem and route the story to another agent when possible.

If the build needs attention:

1. Read the attention block to see whether the issue is code, credentials, or delivery.
2. Fix an account problem in Settings and test the connection.
3. If workspace sessions are stuck, use Repair workspace & retry. Repair preserves project files and waits for active agent work to drain.
4. Use Doctor for other failed builds, or once after repairing a legacy build that remains marked Failed.

See Troubleshooting for the workspace status meanings and recovery order.