Root cause of the R.12.22 mkdir going unnoticed was never pinned down --
kernel-level inotifywait on the exact same directory caught the same
mkdir instantly, ruling out mount/fs issues, but watchdog's own internal
bookkeeping missed it with zero log line. Rather than keep chasing a
specific inotify failure mode, make the daemon resilient regardless of
cause: a reconcile() sweep walks the whole /data and /vault tree every
3 minutes (plus once at startup) and calls the same idempotent
handle_data_created/handle_vault_created used for live events. Both are
check-target-state-first by construction, so this is a no-op on an
already-synced tree and only acts on genuine misses.
Does not attempt rename reconstruction -- a missed rename looks
identical to a delete+create after the fact, which is genuinely
ambiguous. Live on_moved handling remains the only rename path;
reconcile's job is strictly to guarantee creates are never lost.
Two fixes:
1. Untitled folder junk + phantom-rename bug (Ryan reported 2026-09-22):
Obsidian's 'New folder' action does mkdir Untitled immediately, then
creates the real-named folder afterward -- either as a genuine OS
rename() or as a second separate mkdir + move-in, depending on
Obsidian's internal path (confirmed both happen). Previously we
mirrored 'Untitled' to /data like any other folder, so:
- the two-separate-creates case left a permanent 'Untitled' orphan
in /data (its delete event was silently dropped -- handle_vault_deleted
only tracks ID-shaped names) and fired two separate 'new folder'
ntfy pings instead of the one rename ping the user expected.
- the real-rename case (once Untitled stopped being mirrored) then
had no data_src to rename, so the folder never reached /data at all.
Fix: UNTITLED_RE skips mirroring 'Untitled'/'Untitled N' outright in
handle_vault_created. handle_vault_moved falls back to a create-mirror
at the destination when there's no data_src to rename, covering the
genuine-rename-from-Untitled case cleanly.
2. Stub /vault notes for /data-first folders (Ryan: 'I don't want needs
review and a fix-me message, it just needs to create the empty folder
note and give it the automatic alias'): handle_data_created now writes
just , matching the
existing convention across the vault (e.g. R.32.22 Alcohol.md). Dropped
the needs-review banner and the #fix-me inbox flagging entirely, along
with the now-dead _find_nearest_inbox_note/INBOX_ID_RE.
Verified both Untitled scenarios live: real OS rename from Untitled now
mirrors as a single create at the destination name; two-separate-creates
(Untitled then real name, Untitled later deleted) leaves no orphan in
/data and produces exactly one ntfy for the real folder.
Fixes silent rename-event loss on large folder trees. Previously
on_created/on_moved/on_deleted handlers ran synchronously inside
watchdog's own callback thread (git commits, network calls, sleeps),
starving the inotify reader under bursty activity. When the reader
falls behind, watchdog can't pair moved_from+moved_to within its
matching window and drops the rename entirely instead of firing a
degraded delete+create -- so large renames vanished with no log line
and no ntfy at all.
Fix: watchdog handlers now just enqueue (kind, path) tuples onto a
queue.Queue and return immediately; a single dedicated worker thread
drains the queue and does all the slow work. Reader thread never
blocks regardless of downstream latency.
Also adds file-level journal frontmatter automation: new dated entries
under R.16.11 (YYYY-MM-DD.md) get auto-injected
if missing (matches existing corpus format exactly -- full month name,
no zero-padded day). Idempotent: files that already have a title are
left untouched; files with other frontmatter get title prepended.
Verified: reran the exact 300-subfolder rename repro that silently
failed before the fix -- now completes as a single clean MIRRORED
rename with no orphaned /data state.
Forward (/vault->/data) mirroring was gated to only AREA/CATEGORY/ID-shaped
names, so arbitrary sub-structure Ryan creates inside an ID (e.g. dated trip
folders under F.21.21) never propagated to /data. Removed the name-shape
gate; the existing parent-must-exist check is sufficient safety, plus an
explicit '0 System area' exclusion since that tree has no /data root at all.
- vault move now accepts any JD code kind (area/cat/ID) on both old and
new, not just ID->ID. Enables e.g. 'vault move F.50.09 F.59' to promote
an ID to a standalone category.
- Refuses if the source has nested JD-coded children (would orphan their
codes -- that's a bulk renumber, a different and riskier operation).
- Also commits vault_sync_daemon.py (inotify bidirectional /vault<->/data
sync service, with ntfy notifications on rename/archive/stub/error).
Hermes
Hermes