If a git-side edit rewrote a page file WITHOUT its `gitmost_id` frontmatter (e.g.
a tool that regenerates the whole file), the push planner's M (modify) branch found
no pageId in the current meta and SKIPPED the file — then the next Docmost->git push
overwrote it with the DB content, silently reverting the edit (data loss, found via
web-test).
Mirror the D (delete) branch: recover the identity from the PRE-IMAGE meta (the
last-pushed version at the same path, which still carried the id) before skipping,
and apply the body edit as an update. The pushed-back re-serialize restores the
frontmatter next cycle, so the file self-heals. Only when the pre-image ALSO lacks
an id (a never-tracked page) is it genuinely skipped.
Verified on the stand: editing a synced page's file with the frontmatter removed now
applies the edit (was reverted). Unit test: a modified file with no current pageId
recovers it from the pre-image -> update. git-sync suite green (705).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
agent_qa
cec50c3ce4