Build lifecycle and revisions

Keep the revision attached to its context#

Continue in the existing project conversation to refine its current artifact. A follow-up request uses the project context; a new conversation is a different starting point. Identify the tested version and the narrow change required, especially when a public version and a newer preview coexist.

A request can require clarification, run, fail, be interrupted, or produce a ready preview. The availability of a Stop, retry, or resume action depends on that state. Do not treat an interrupted connection as proof that server-side work never completed.

Constrain the revision#

Base: the current preview in this conversation.
Observed: submitting an empty title creates an empty list item.
Expected: reject empty or whitespace-only titles before adding an item.
Preserve: stable IDs, status filtering, ordering, and the current layout.
Validate: empty input, whitespace, valid input, repeated submit, and keyboard submit.
Do not add persistence or change the data model. Report the changed files and validation results.

Inspect the resulting delta#

When the changed-files card is present, Review opens the relevant file and available differences. Check additions, removals, and unexpected changes outside the requested scope. Large differences may fall back to the full file rather than a line-by-line comparison.

The code panel displays saved source and supports copying; it is not an in-place source editor. For external development, export the artifact and inspect it in your own tools. Preview success, a source diff, and a passing production build answer different questions and should be checked separately.

Separate artifact rollback from data rollback#

Undo, when offered, returns to a previous artifact version after confirmation and requires the owner's project context. It can also affect the version at the published address. It does not provide a transaction rollback for database writes, sent emails, or actions already completed by external services.

Ordinary forward changes remain in preview until explicitly published. If the conversation is linked to GitHub, later completed versions can independently generate commits. Review both the deployed website and the repository state when coordinating a release.