diff --git a/CHANGELOG.md b/CHANGELOG.md index 8befe32..4068b99 100644 --- a/CHANGELOG.md +++ b/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 (`:: `) 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. diff --git a/commands/sync-progress.md b/commands/sync-progress.md index b5c40fa..c8bfb27 100644 --- a/commands/sync-progress.md +++ b/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 ""` 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