weekly maintenance: acquire dream.lock to mutually-exclude nightly#30
Merged
Conversation
stevepridemore
added a commit
that referenced
this pull request
May 10, 2026
Both the nightly dream and the new weekly maintenance task modify the graph. They should never run concurrently — concurrent graph_prune + graph_relate against the same nodes is a real correctness hazard. Adds Step 0 (acquire lock) and Step 12 (release lock) to the weekly maintenance prompt. Uses the same lock file as the nightly dream (~/graph-memory/processed/dream.lock) so the two routines mutually exclude with shared semantics: - Same path, same JSON shape, same 2-hour stale threshold - source field distinguishes "scheduled-nightly" vs "scheduled-weekly" - Either side seeing a fresh lock from the other aborts immediately - Both sides MUST release on every exit path including aborts Practical risk this closes: a long-running dream colliding with weekly's prune-execute step, or a manual "Run now" of the weekly task during an active dream. Likelihood is low for a single-user setup but the fix is small and the failure mode (corrupted graph from concurrent destructive ops) is severe. Updated rules section to call out lock acquisition + release as mandatory invariants alongside the existing backup and prune-sanity- check invariants. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #29. The new weekly maintenance task and the nightly dream both modify the graph but don't currently coordinate — they could in principle run concurrently, with race conditions between dream's `graph_relate` and weekly's `graph_prune execute` against the same nodes.
This PR makes the two routines mutually exclusive via the existing `~/graph-memory/processed/dream.lock` file (same one nightly already uses).
What changed
`prompts/weekly-maintenance.md`:
The live SKILL.md was regenerated via `scripts/sync-dream-skill.py --task weekly-graph-maintenance`. Next scheduled run (Sunday 6 AM) picks up the new content automatically — no re-registration needed.
Why now
The first manual run of the weekly task happened tonight without the lock. That was safe because no nightly was running at the time. But future scheduled overlap is possible (long-running dream colliding with the 6 AM weekly trigger, or another manual "Run now" during an active dream). The fix is small and closes a real correctness hazard.
Test plan
🤖 Generated with Claude Code