Review, history, and checkpoints
Use Review to inspect a proposed or completed change before accepting it into your working project. Review can show a file list, additions and deletions, candidate versions, and validation evidence depending on the current run.
Read a change summary
Check the files affected and the change counts first. Open each important file diff to understand behavior, not just the number of changed lines. Confirm that generated configuration, data migrations, credentials, and unrelated files are handled as intended. A successful build does not replace a user-flow review.
Candidates and acceptance
When a run offers candidate versions, compare the alternatives and select the intended candidate using the visible action. Confirm which candidate becomes the active project state and which remains only a record. Do not accept a candidate whose route or data changes you have not reviewed.
Checkpoints and recovery
A checkpoint is a recoverable project source state, not a database backup or a published deployment. Use History to select the checkpoint whose contents and validation are known. Restore only after checking the target and the current changes that may be replaced. A restore can change project source and may require restarting preview or revalidating integrations.
Preserve evidence
Keep failed run and review evidence available until the underlying issue is understood. If you need support, note the project identifier, run and checkpoint identifiers, affected file, timestamp, and exact action. Avoid repeatedly creating new projects to work around an unresolved change.