Technical: File System Event Abstraction

Refactor the file watcher to use a semantic event layer (FileSystemEvent enum) instead of directly matching on the notify crate's low-level events. This enables unit testing of event handling logic without filesystem mocks, simplifies the 140-line pattern-matching block into clean semantic matches, decouples from the notify crate for easier upgrades or replacement, and creates a foundation for smarter features like addon-aware change detection, intelligent debouncing, and batch operation coalescing.

Arguments for Keeping the Abstraction

1. Decoupling from notify crate

• Currently the code is tightly coupled to notify::EventKind matching (lines 192-341)

• If notify changes its API or you switch to a different file watcher crate, you'd have to rewrite all the event handling logic

• With FileSystemEvent, you'd only change the translation layer once

2. Simpler event handling

• The current match statement is ~140 lines of gnarly pattern matching on notify::EventKind variants

• With the abstraction, event handlers would be cleaner:

  match event { FileSystemEvent::DirectoryCreated(path) => { /* handle */ } FileSystemEvent::FileRemoved(path) => { /* handle */ } // ... } 

3. Testability

• You can't easily unit test code that depends on notify::Event without mocking the filesystem

• With FileSystemEvent, you can create test events trivially and test your handling logic in isolation

4. Semantic clarity

• notify has Create(CreateKind::Any), Remove(RemoveKind::Folder), etc. - you're already translating these to semantic strings like "directory_created"

• The enum would formalize this translation and make the code's intent clearer

5. Future extensibility

• You might want custom events like AddonFolderChanged(Uuid, String) that carry more context than raw paths

• An abstraction layer gives you a place to add that semantic enrichment