38 lines
1.7 KiB
Markdown
38 lines
1.7 KiB
Markdown
---
|
|
id: "0007"
|
|
date: 2026-06-03
|
|
status: Accepted
|
|
supersedes:
|
|
superseded-by:
|
|
affected-paths: []
|
|
affected-components: []
|
|
migration_confidence: medium
|
|
migration_source: "docs/memory-system/03-architecture-decisions.md### ADR-007 — Lazy freshness: write-hook + session-start reconcile, no daemon/cron"
|
|
---
|
|
|
|
# 0007 — Lazy freshness: write-hook + session-start reconcile, no daemon/cron
|
|
|
|
## Context
|
|
|
|
The cache must reflect new/edited/deleted/renamed notes without becoming a
|
|
resource hog or going stale on renames.
|
|
|
|
## Decision
|
|
|
|
**Option A (lazy).** A `PostToolUse` hook updates the index on **AI** writes
|
|
(single-file, prunes on delete). **Manual** edits are caught by a **session-start reconcile**
|
|
(`index update --since` + prune of vanished paths). **No daemon, no cron.**
|
|
- **Rationale**: The AI is the primary writer, so write-time hooks give event-driven freshness
|
|
with no polling. The user rarely edits the vault by hand, so a session-start reconcile is
|
|
enough; a continuous `inotify` daemon (the `listen` gem) would add an always-on process to
|
|
manage/sync for negligible benefit. Matches the user's "lazy sync is fine" stance.
|
|
|
|
## Consequences
|
|
|
|
Index freshness is handled lazily: a PostToolUse hook updates the index on AI writes, and a session-start reconcile catches manual edits and deletions, with no daemon or cron process running continuously. This avoids the overhead of an always-on inotify/listen process at the cost of freshness only being guaranteed at write-time or session-start rather than continuously.
|
|
|
|
## Alternatives rejected
|
|
|
|
`inotify`/`listen` daemon (live freshness, but always-on process
|
|
to manage — unnecessary). Cron reconcile ("seems silly" per user; session-start covers it).
|