Three things ntropy does not do, each the result of a design choice rather than an oversight. The decision records behind them are linked from each section.
macOS and Linux only
Materialized views
are real symlink trees, which is what makes them directories you can cd
into and browse with any tool. Windows needs Developer Mode or admin rights
to create symlinks, so ntropy targets Unix and leaves Windows out
(ADR 0020).
There is no Windows build, no symlink fallback, and no Windows testing.
Support is deferred, not ruled out. The open questions are the symlink
privilege, path and case-folding differences, and the missing SIGPIPE.
Personal scale
Your files are the database. ntropy keeps no index and no daemon. Every
list, search, and filter walks all-notes/ and parses frontmatter on
demand
(ADR 0002).
Query cost therefore grows with the vault on every run. That is fine for
hundreds to low thousands of notes, which is what ntropy is tuned for, and
not for hundred-thousand-note archives. In return everything stays plain,
greppable, committable files, and nothing can go stale or corrupt, because
there is nothing derived to invalidate. Since the filesystem stays
canonical, a cache can be added later without turning it into a database.
Views can drift on out-of-band edits
ntropy refreshes the view trees after its own mutations (create, edit,
retitle, delete). Change frontmatter or rename files behind its back, with
$EDITOR or a script, and the views will not catch up until the next
ntropy reconcile. That one command syncs the view trees, realigns
filenames whose slug drifted from the title, and rewrites links that
pointed at the old filenames, as described under
Commands. The notes themselves
are never stale, only the derived views.