The builder, pane by pane

Preview

While a first build runs, this is a draft: a static sketch of the page, labeled “Draft, building the real site”, with the build’s progress over it. It is drawn in a restricted frame, is never saved in the project, and is a picture of the intent, not a run of it. A follow-up keeps what the tab already shows instead.

Once there is code, the tab says Ready to run (or keeps the draft) and offers Run live preview, which installs the project and starts it in a private sandbox. Once it is up, the frame is the running app and the draft is gone: the two are never shown side by side.

A running preview takes each new version in place, and says Updating preview… while it does. When it cannot, it is restarted and the tab says why. See Running and sharing your project.

Code

The generated files, as files. While a build is being checked, the list is that build’s code, badged like the preview.

Export, Publish and Push to GitHub are not here. They are under Ship, in the top bar, and they act on the last finished checkpoint. The tab says so when the list shows something else.

Console

Generation lifecycle events: what the run is doing, when it started, when it finished, what it cost.

It is not the sandbox’s output. Sandbox execution is real, but its process output is not piped into this tab yet. If your project logs something at runtime, that log is in the sandbox, not here.

Problems

What vibld’s own checks found, including a build that failed its check or a run that failed.

It is not the sandbox’s errors. Install failures, build failures and type errors from a sandbox run are not reported here yet. A sandbox that fails to start says so only in the Preview tab.

History

The newest 100 checkpoints this project has accepted, newest first. A build’s checkpoint is named by its message while that message is still in the conversation; a restore, a copy, or a build whose message is gone gets a plain label instead. Restore makes an earlier one the project’s code again, after asking: the preview and the next build start from it. No checkpoint is deleted, so a restore can itself be undone, and the published site and connected repository stay as they were until you ship again. It is refused while a build runs.

Runs

Every run on this project: the model, the tokens, the cost and why it ended. It is read back from storage, so it survives a reload and includes runs this tab never watched.

Projects

Everything is saved as you go: the code, the whole conversation, the style, the model, your instructions and preferences. The Projects list opens, renames, duplicates, archives and deletes projects. Deleting is permanent and asks first. A Free account can have three active projects, and archived ones do not count; Build and Ship have no limit.

With the same project open in two tabs, the one left behind is told “This project changed in another tab” and stops saving until you press Reload.

Sharing a project

Share, in the top bar, turns on a link of the form app.vibld.com/s/<token>. Anyone with it sees the project’s name, its code and its live preview, read-only; starting the live preview needs them to be signed in. Somebody signed in can Remix it: a copy of the code and settings in a new project of their own, called “Remix of” the original, with the media its code uses copied into their library. Your conversation, your name and your email are not shared. Turning the link off stops it working for good, and turning it on again makes a new one.

This is not the same as a sandbox share link, which points at one running preview and never outlasts it.

Ship: publishing, and taking it back down

Publish puts the project’s last finished checkpoint on the web at its own address, <slug>.vibld-preview.dev, and anybody with the address can read it. Each project has its own site, and publishing one never replaces another’s. It takes two presses: the first names the site, the checkpoint and whether this replaces something already live, and the second is the act. On the Build and Ship plans a site can also be published on your own domain, as well as at its vibld-preview.dev address.

Running a sandbox, or finishing a build, never makes anything public. Nothing automated can publish either: no scheduled run, no webhook, and no text in a pull request or a commit message.

Take it down is the other half, on the same terms. The address stops working immediately and the files are deleted. The name stays yours: nobody else can claim it, and publishing again under it is what puts the site back. Deleting the project takes its site down too. Rolling back to a previous published checkpoint is not built yet.

Published sites are sent a few safe default headers (HTTPS only, no content-type sniffing, a strict referrer policy, and no camera, microphone, location or payment features), and nothing that restricts what a page loads, so embeds and third-party scripts keep working. Images and fonts that the build itself emits are not published yet; files from your media library are.

The header and the footer

The header carries what you look at while building: the brand, then Projects, the project’s name (click it to rename), the save status, Share and Ship, then the light and dark toggle, the settings menu and your account.

Everything that is configuration lives behind the gear: your plan and this period’s spend against your allowance, auto-reload and Start Build (both off until you turn them on), your referral link, the GitHub connection, deleting your account, and which provider and model served the last run. None of it claims anything before there has been a run.

Delete account asks you to type a phrase to confirm. From then on the account cannot be used: any subscription is canceled, the preview stopped, published sites taken down and the GitHub connection removed. Thirty days later its projects, media and usage records are deleted. Until then, signing in offers Keep my account.

The footer carries the limits above in one line, for anybody who never opens those tabs. The run count and token figures sit beside it, folded away until you ask for them.

Where this is going

The sandbox already produces the output and the errors; both gaps are about wiring them into these tabs. Until then, the tabs say so.