Vault query and index
Status: open/planned · Kind: subsystem · Audience: system
Summary
Section titled “Summary”- An incremental vault index (frontmatter, links, structure) plus a query model of composable filters, formulas, and named views in the ergonomic shape of Obsidian Bases — without claiming compatibility with that proprietary format.
- One index serves every consumer; apps stop re-walking and re-parsing the vault per feature.
.basefiles are a supported input where practical; the query engine is our own.
Statement
Section titled “Statement”Search, graph, stats, agenda, and digest features each independently walked and parsed
the vault until fsindex amortized it for the determined suite; the closest thing to a
query language is vault-graph’s TS selector DSL. This capability promotes both ideas
into the core: an incremental index maintained over the CST/vault kernel, and a query
plane — boolean filter composition over frontmatter and file properties, computed
formulas, summaries, named views — that products and agents share. Obsidian Bases
supplies the ergonomic reference; the engine, grammar, and index are independent.
What it provides
Section titled “What it provides”- Incremental index: frontmatter values, link graph, structural facts (sections, anchors, tags), watched and invalidated on file change.
- Query API: filters (boolean composition, property predicates,
hasTag/hasLink/inFolder-class helpers), formulas, sorting, named views. - Best-effort
.basefile reading mapped onto the native query model. - Query surface exposed through the WASM boundary (C-X2PB-wasm-ts-surface) and as CLI verbs.
Underlying implementation
Section titled “Underlying implementation”New build (M-N2HG-query-and-index-plane). Inputs: platform-core fsindex.rs
(incremental cache), vault-graph selector DSL (TS migration source),
determined-notes::event (recurrence/agenda queries as the hardest existing consumer),
Obsidian Bases syntax as ergonomic prior art.