Use the desktop Sync Changes workspace to inspect incoming differences, outgoing work, conflicts, and project history before pulling or pushing. History can also provide a safe copy of an old file or restore its content into the live project as a new outgoing edit.
Coverage: Desktop UI. Production MCP authoring tools do not currently expose the full sync/history review surface.
From the project top bar, open the cloud-shaped menu and choose Sync Changes. This desktop-only surface fetches current status and organizes the project into review views, including incoming work and history.
Use Refresh whenever collaborators or another machine may have changed remote state. Reading status and history should not itself merge or rewrite project content.
The left rail groups changes by folders, files, and—in supported design files—nested nodes or properties. File rows describe additions, deletions, modifications, and renames. Expanded node rows can show individual added, deleted, updated, or moved entities and before/after values.
Collapsed ancestors summarize descendants so a large project remains navigable. Open a file or node comparison to understand the actual change rather than accepting a file count.
The push action is disabled while incoming changes remain. Review the incoming set first:
refresh status;
inspect every changed file;
identify files changed on both sides;
resolve the intended current content;
pull/apply the incoming direction through the UI;
rerun Preview, diagnostics, and consumer builds affected by the merge;
review the resulting outgoing set;
push with a meaningful message.
Sync and push are project-level operations. They are not the same as Component undo or the top bar's Previous/Next file navigation.
The History view lists commits newest first. Select a commit to inspect its changed files. The Compare menu can compare the selected commit with its parent, the live project, or another loaded history entry.
History reads support two different recovery intentions:
Copy/Duplicate beside the live file: create a new file from that historical version, preserving the current live file.
Restore/Discard in place: write the chosen historical content into the live file as a normal new outgoing change. This does not rewrite project history.
For a deleted file, Restore Deleted File creates a copy from the historical version because no live file remains to replace.
Before an in-place restore:
preview the historical version or inspect its rows;
compare it with live state;
check current dependents and references;
choose Restore This Version or Discard My Changes only when that direction is clear;
review the resulting outgoing changes;
use file-content undo promptly if the restore was wrong and that stack is still undisturbed.
Copying a version beside the live file is safer when you want to inspect or manually merge old content.
MCP can inspect current project/file content, Preview behavior, diagnostics, and generated output, but it does not expose the complete incoming/history/compare model. Use an agent after you choose or materialize the relevant current file:
In the selected
Websiteproject, inspect the current<file reference>after the sync review. Compare its structure and generated output with<requirements or copied historical file>. Report mismatches and verification evidence without changing, pushing, or publishing anything.
Do not ask an agent to infer remote history from MCP activity marks; those are unrelated session-only editor feedback.
Pull/apply changes can replace current project content and reload the project.
Push writes the reviewed outgoing set to shared project history.
Restore/Discard writes live content as a new outgoing edit; it does not erase history.
Copy/Duplicate creates another project file and may require references to be wired manually.
Exact conflict resolution, recovery, and Undo behavior must be runtime-tested before this draft is approved.
Local/Git export history is a separate destination from Misaki project sync history.