This roadmap describes the intended direction of the project. It is ordered by dependency and risk rather than by promised release dates.
- Keep registered Google Docs/Markdown and Google Sheets/CSV pairings synchronized through the background service.
- Apply routine paragraph, list, link, table, status, and standalone-image changes while preserving unchanged document ranges.
- Download remote inline images into portable sibling asset directories and push local standalone images through short-lived private R2 staging.
- Create and pair Google Docs from Markdown and Google Sheets from one or more CSV files through Finder Quick Actions.
The image implementation, storage convention, safety rules, live-validation results, and remaining work are documented in the image synchronization design.
- Keep Google Docs and Markdown pairings convergent under routine local and remote edits.
- Make synchronization wake-safe and replace routine full-pairing polling with incremental Drive change discovery so normal work scales with actual changes.
- Keep daily reconciliation sequential while current scans remain comfortably below one minute; if registry growth or observed local-sync delays cross that threshold, introduce cooperative batches that yield to ordinary work and then measured four-way concurrency if needed.
- Add actionable image-sync logs and health checks without exposing secrets or signed staging URLs.
- Exercise retry, timeout, crash-recovery, partial-upload, and R2-cleanup paths.
- Continue live validation with screenshot-heavy documents containing both text paragraphs and supported standalone-image paragraphs.
- Continue live validation of incremental paragraph, list, link, table, and status updates.
The completed lifecycle, change-discovery, and reconciliation work is documented in the scalable, wake-safe synchronization design. Its future reconciliation scaling trigger records when and how to add cooperative batching and measured concurrency without prematurely complicating the current state coordinator.
- Begin with local-only daily aggregation and an exact
gdms telemetry preview; do not submit data during the prototype phase. - Keep telemetry disabled by default, require explicit interactive consent, and never collect document content, identifiers, paths, account details, raw errors, or precise activity timestamps.
- Use coarse configuration and activity fields to measure opted-in active installations, setup completion, feature adoption, versions, synchronization reliability, safety stops, and categorized failures.
- Separate the telemetry receiver from synchronization and image staging, enforce strict schemas and short raw-record retention, and ensure receiver failure cannot affect GDMS behavior.
- Ship network submission only with public schema and privacy documentation, complete enable/disable/reset/delete controls, focused security review, a version increase, and a matching changelog entry.
The product questions, consent contract, proposed payload, prohibited data, receiver requirements, delivery phases, and acceptance criteria are documented in the privacy-preserving telemetry design.
- Replaced the privileged discovery root and separate Raycast location storage with one GDMS-owned registry of explicitly selected sync locations.
- Made configured locations authoritative, kept the manifest index as rebuildable derived state, and limited scanning to location addition, explicit pairing discovery, and missing-index recovery.
- Preserved
workspaces.jsonrollback compatibility and the deprecated--workspaceCLI alias during migration. - Gave project trees and document archives the same CLI, Raycast, daemon, browsing, and recovery capabilities without recursive routine polling.
The justification, storage model, migration requirements, implementation phases, risks, and acceptance criteria are documented in the unified sync-location registry design.
- Add explicit unpairing and a command that lists every registered pairing.
- Improve conflict visibility with durable deduplicated logs, delayed email escalation, and emailed recovery notices while retaining the current later-modification-wins policy for text-only documents.
- Create recoverable conflict copies and user-visible notifications when both sides change incompatibly.
- Refine the current document-level image conflict stop into per-image baselines if routine use shows that the coarse check is too restrictive.
- Introduce
io.github.rsheyd.google-docs-markdown-syncidentifiers with dual-read Keychain compatibility and non-destructive credential copying. - Make the service installer replace legacy launchd jobs without allowing old and new daemons to run together, while retaining rollback-safe credentials.
- Remove legacy identifiers only after a documented compatibility window and an explicit cleanup path.
The phases, rollback guarantees, affected identifiers, and validation plan are documented in the namespace migration plan.
- Package GDMS as a signed and notarized macOS app that does not require Node.js, a source checkout, or manual background-service installation.
- Add guided Google authorization, sync-location selection backed by the existing shared registry, and first-document pairing without introducing another configuration store.
- Provide a simple interface for viewing pairings, sync health, conflicts, and recovery actions.
- Reduce or eliminate the infrastructure users must configure for image synchronization.
- Evaluate an optional managed service for shared infrastructure while keeping Markdown files local and making the privacy, security, and operating-cost tradeoffs explicit.
- Add explicit orphaned-asset review and cleanup tooling.
- Evaluate support for floating images, cropping, rotation, drawings, and linked charts after inline image synchronization is reliable.
- Support safe mutations of mixed text-and-image paragraphs and image-bearing full document rebuilds.
- Evaluate an explicit managed-folder pairing that continuously synchronizes all Markdown and CSV files beneath one deliberately enrolled local root with one bounded Google Drive subtree.
- Require each managed folder to live inside a registered sync location, index its portable manifest through the existing derived manifest index, and keep managed-folder identity independent of the machine-local location ID.
- Preview initial enrollment before creating Drive folders, Docs, Sheets, or tabs, and keep the folder rule and child pairings visible in a portable manifest inside the managed root.
- Mirror local subfolders in Drive, preserve stable object identity through moves and renames, and retain GDMS's move-detection and deletion-grace-period safeguards.
- Extend recoverable deletion to CSV tabs before allowing missing CSV files to remove remote data. Sheet tabs lack ordinary Drive trash semantics and need a dedicated recovery design.
- Treat automatic adoption of remote-created Docs and tabs as a later phase; begin with explicit enrollment and local-authoritative folder structure.
- Establish operation journaling, conflict recovery, notifications, API-load limits, and non-destructive bulk unpairing before unattended discovery.
- Use scoped watchers and incremental managed-root inventory so folder automation does not reintroduce recursive polling of entire sync locations.
The proposed product contract, safety model, CSV mapping alternatives, phased delivery, and unresolved decisions are documented in the managed folder synchronization design.
A separate hosted product could synchronize one explicitly selected Google Drive folder tree with one folder in a public or private GitHub repository. Unlike local GDMS, it would use Google and GitHub webhooks, durable cloud workers, service-side encrypted credentials and baselines, and guarded Git commits to provide two-way Docs/Markdown and Sheets/CSV synchronization without requiring a local clone. Automatic deletion would remain deferred until a recoverable policy is designed.
The product boundary, managed-cloud architecture, two-way reconciliation model, security requirements, delivery phases, and open decisions are documented in the hosted Google Drive–GitHub synchronization design.
A second hosted offshoot could synchronize Google Docs and Sheets with ordinary Markdown and CSV sidecars stored beside them in the same bounded Drive folder tree. It would use the same cloud worker and conflict model without GitHub, trading version-control workflows for a simpler single-provider folder, identity, permission, and notification boundary. The proposal is documented in the hosted Google Drive sidecar synchronization design.
- General-purpose Google Drive mirroring.
- Permanent public hosting of document images.
- Pixel-perfect round-tripping of every Google Docs visual object.
- Synchronizing unpaired documents or arbitrary files outside a registered sync location or explicitly configured folder auto-sync scope.