Problem

gog drive upload --replace can update one known Drive file ID, but safely backing up a local directory still requires every caller to implement recursive traversal, folder creation, duplicate-name detection, checksum comparison, and ID-stable updates.

Using a Google Drive for Desktop mount as the destination is not an equivalent solution: cloud-only File Provider placeholders do not behave like ordinary readable files and can break filesystem tools when they compare or replace evicted destination files.

Proposed scope

Add a one-way command:

gog drive sync push <local-directory> --parent <folder-id>

Semantics:

• recursively reproduce the local directory hierarchy under an existing Drive folder;
• create missing folders and binary files;
• skip unchanged files using Drive md5Checksum and size;
• update changed binary files by Drive file ID;
• retain remote-only files (no delete or mirror mode);
• reject local symlinks;
• fail before mutation when a remote sibling name is ambiguous or has the wrong type;
• support deterministic --dry-run, --json, and plain output;
• preserve existing shared-drive support through supportsAllDrives.

Non-goals

• bidirectional synchronization;
• pull;
• remote deletion;
• persistent sync state;
• Google-native file round-tripping;
• durable upload-session resumption across process restarts.

Prior art

This intentionally narrows the Drive sync portion of #116. That PR combined pull, push, delete, include/exclude rules, and persistent state; maintainers requested a separate design and live-proof path for those semantics.

Existing primitives remain useful:

• feat(drive): in-place file replace (preserve fileId/shared link) #232 / drive upload --replace established ID-preserving binary updates.
• feat(drive): add changes tracking for sync and automation (Changes API v3) #335 added Drive Changes API support.

This proposal does not duplicate either command; it adds bounded recursive reconciliation for local-directory backup workflows.