Architecture: punt all git concerns to DMC GitSync

[chubes4]

Statement

Markdown Database Integration should not implement git operations. All git concerns (remotes, pull, push, bind, auth, conflict resolution) belong in the separate Data Machine Code GitSync module, which shipped this layer on 2026-04-20.

This issue exists to formalize that boundary so future contributors don't reach for git primitives inside MDI.

Layering

┌─────────────────────────────────────────────────┐
│ DMC GitSync                                     │
│   bind / pull / push / submit / status / policy │  ← ALL git concerns
│   GitHub Contents + Git Data APIs               │
│   (no shell, no git binary, no .git/ directory) │
└─────────────────────────────────────────────────┘
                      ▲
                      │ points at wp-content/markdown/
                      │
┌─────────────────────────────────────────────────┐
│ Markdown Database Integration                   │
│   WP post ↔ .md file on disk                    │  ← filesystem stops here
│   frontmatter / loader / write engine / index   │
└─────────────────────────────────────────────────┘
                      ▲
                      │
┌─────────────────────────────────────────────────┐
│ WordPress (posts, meta, options)                │
└─────────────────────────────────────────────────┘

• MDI's job: WordPress post ↔ markdown file on disk. Full stop.
• GitSync's job: markdown file on disk ↔ upstream git repo.
• Integration: GitSync writes files; MDI notices (via file-watching, not git).

What stays in MDI

• File watching / filesystem reactivity — detecting new or changed .md files and rehydrating the post index. This is incremental-sync plumbing, not a git concern.
• Frontmatter round-trip, slug derivation, ID assignment (see Auto-assign IDs for new .md files without id: frontmatter #42).
• The markdown ↔ block conversion pipeline.

What moves out (or was never MDI's in the first place)

• git commit / git push / git pull / git status — DMC GitSync.
• Remote repo configuration and auth — DMC GitSync.
• Branch / worktree management — DMC GitSync.
• Conflict resolution semantics — DMC GitSync.
• PR creation for wiki-content syncs — DMC GitSync's submit ability.

Why this matters

MDI must work identically across environments:

• Self-hosted with DMC + GitSync installed
• Studio local dev (symlinked MDI checkouts, no DMC)
• WP.com / VIP (no drop-ins, no DMC)
• Minimal installs with only MDI

Coupling MDI to git primitives would produce two code paths — one for "git is available" and one for "git isn't" — which is exactly the class_exists() branching the ecosystem explicitly forbids inside feature flows. Users on managed hosts would get a subtly different MDI than self-hosters.

Keeping git in GitSync makes MDI portable, and makes GitSync swappable (the same markdown/ directory could be synced by any alternative implementation — Meilisearch-based sync, inotify-based local mirror, a Dropbox-style agent, etc.).

Action items

• Confirm current MDI roadmap does not list "git auto-commit" or similar. If it does, remove it.
• If any code inside MDI currently shells out to git, extract it. (Spot-check says no, but double-check.)
• Future "file watching" work (fs_events, inotify, polling) lands in MDI. Future "sync this dir with GitHub" work lands in DMC GitSync.

References

• DMC GitSync shipped: data-machine-code#38, PR #42, #43
• DMC GitSync is API-first (GitHub Contents + Git Data APIs) — works on WP.com Business, WP Engine, Pantheon, etc.