fix: re-read daily note before write in sync-progress

CHANGELOG.md

@@ -8,6 +8,9 @@ Please choose versions by [Semantic Versioning](http://semver.org/).
 * MINOR version when you add functionality in a backwards-compatible manner, and
 * PATCH version when you make backwards-compatible bug fixes.
 
+## Unreleased
+- fix: sync-progress re-reads the daily note immediately before writing and merges — prevents a sibling session's concurrent write from being silently clobbered (lost entries never reach git history)
+
 ## v0.114.6
 
 - fix: `work-on-task-assistant` daily-note tracking claim now requires `grep -n` evidence (`<file>:<line-no>: <matched line>`) instead of a prose quote. v0.114.5 added a "quote it verbatim" guard after the agent reported `Already tracked` for a task absent from the note; the same day, with that guard in place, it did it again — a fabricated quote satisfies "quote verbatim" perfectly, since a plausible nonexistent line reads identically to a real match. A line number is cheaply spot-checkable and does not survive fabrication the same way.

commands/sync-progress.md

@@ -69,6 +69,15 @@ File: `{daily_dir}/YYYY-MM-DD.md`. Add to the daily note's "What happened today"
 
 **Do not assume the heading level.** Templates differ across vaults — the Personal vault uses `# What happened today` (h1). Locate the section with `grep -nE '^#+ What happened today'` before concluding it is absent. A `^## ` grep returns nothing there, and reading that as "this vault's template has no such section" silently skips the entry — the daily note then reports the session as unrecorded and `session-close` Phase 7 has to catch it. Observed 2026-08-20. Same defect class `session-close.md` § Phase 7 already fixed on its own side.
 
+**Re-read the file immediately before writing — never write from a stale copy.** This command reads the daily note early (to locate the section) and may compose the entry over several turns. In that gap a sibling session can rewrite the same file, and writing over it from the earlier read silently destroys their entry — the clobbered text is lost for good, because obsidian-git autocommits whatever is on disk and the earlier write never enters history. Observed 2026-08-23 on the Personal vault: a `sync-progress` entry vanished this way, provable via `git log -S "<entry-text>"` showing a single commit (the later restore) instead of add+remove.
+
+**Mandatory write protocol for the daily note:**
+1. **Immediately before writing**, read the file again from disk (`Read` tool — not memory, not the earlier grep).
+2. **Merge, never overwrite** — splice the new entry into the *current* content. If the file grew or changed since your earlier read (a sibling session's entry landed), keep their content and add yours alongside.
+3. If the file is missing or the section vanished since your read, re-locate it and re-merge rather than recreating from scratch.
+
+The same guard applies to any other shared vault file this command writes (task/goal pages, PR sections).
+
 Entry shape:
 
 ```markdown