ClaudiaFang 06953e1b12 fix(sync): stop false-positive rename detection and 422 on rename push ... detectRename only checked whether a tracked old path's file was missing from the vault, with no content verification. Any orphaned syncMetadata entry (e.g. left behind by a local delete, which never cleared it) would cause the next unrelated push to be misclassified as a rename from that stale path, using create-only semantics that 422'd if the target path already existed remotely. - detectRename now confirms identity by checking that the remote content at the candidate old path still matches what's being pushed. - handleRename looks up the existing remote file at the new path and sends its sha, so pushing onto an existing remote path updates instead of failing with "file already exists". - Local deletes (single and batch) now clear syncMetadata for the deleted path so it can't become an orphaned rename source later. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>		2026-07-05 05:44:54 +00:00
..
logic	fix(sync): stop false-positive rename detection and 422 on rename push	2026-07-05 05:44:54 +00:00
services	fix(sync): clearer branch-not-found errors and connection test	2026-07-05 04:57:47 +00:00
ui	refactor(ui): unify Sync Status icons via Lucide setIcon	2026-06-26 06:22:53 +00:00
utils	refactor(test): eliminate duplicate code flagged by SonarCloud	2026-05-22 03:52:32 +00:00
setup.ts	refactor(ui): unify Sync Status icons via Lucide setIcon	2026-06-26 06:22:53 +00:00