When Workspaces cannot confirm an outcome, check the original operation before trying another write.
Check what actually completed
Cloud publication, local-file application and editor Open/reload are separate outcomes. An accepted request, disappearing spinner or empty Changes list is not proof of all three.
- Keep the original project and operation selected.
- Read the result and its named recovery action.
- Use Reconcile original operation, Continue or Try opening again only for the matching unfinished step.
- Inspect the actual open project, branch and files before continuing design work.
Reading a receipt does not execute the action again. An unavailable, missing, denied or malformed receipt leaves the earlier outcome uncertain; it does not prove that nothing happened.
Project added, but not open
Keep the confirmed cloud addition. Retry Open for that same project rather than add a duplicate. Your original source is separate from the cloud copy.
If publication itself is unknown, Continue adding checks the original addition. Closing its window is not cancellation. Do not repeatedly press Continue without reviewing whether the outcome changed. See Add a saved project.
Local work preserved after failure
- Local commit preserved: Push failed or did not publish; the local commit remains available.
- Park preserved: unpublished work was stashed, but the target switch did not complete.
- Needs resolution: conflict review or verified application is unfinished.
Keep the retained work. Use the matching original operation's controls rather than manually removing journals, stashes or recovery directories. After proven settlement, authorize a new reviewed action if still needed. Unknown outcomes must not be retried under a new request.
Restore or branch status needs attention
Check the branch actually open and the selected stash. A successful park is not proof of target opening; a file apply is not proof the editor reloaded. Do not force-save a stale editor over newer disk files.
If the stash is missing from the GUI or restoration repeatedly fails, preserve its recovery data and contact support with the build, action, project/branch names and safe displayed error. Do not send credentials, signed URLs or confidential design files without an agreed support path.
Cancel an original merge attempt
On builds offering Cancel merge attempt:
- Select the original uncertain merge.
- Read and confirm that attempt's cancellation.
- Check its result or reconcile the same original operation.
Confirmed pre-publication cancellation blocks that attempt from merging later. If the merge already completed, Trace reports its original successful outcome. Cancellation does not close the PR, undo the completed merge or choose conflict winners. A lost cancellation reply is still unknown.
Account, permission or connection changes
Recovery belongs to the original account, project and backend. Reauthentication or reconnection does not automatically replay a write. Later permission denial does not establish that an earlier authorized operation had no effect.
Do not switch servers to retry the same uncertain request. An API version alone does not enable recovery handlers or supply missing backend deployment. If recovery is unavailable, preserve local work and seek support rather than use shell Git or arbitrary API calls as a substitute.
For saved-file native CLI receipt/reconciliation support, see
Workspaces integration. Headless file
verification is not evidence that the GUI editor opened or reloaded.
Native workspaces reconcile observes supported project-metadata receipts,
not every unknown engine command. For an unknown Commit, Push, Pull, Switch or
Restore outcome, retain the original UUID and use its matching conflict/recovery
controls; do not treat a reconciliation refusal as permission to repeat it.