sense: setup and tree design

Querying an existing tree is the sense skill. This one covers making a tree: installing, writing presets, and the design decisions a tree owner faces. Worked configurations for common tree shapes: EXAMPLES.md.

Setup

• npm install -g sensemaking, then sense init at the tree root writes sense.config.json: two presets (default, and large showing what a big tree tunes) and an embed block naming the model. The model fetches once per machine at the first vector search (progress on stderr); sense download prefetches it instead where that timing matters (CI, air-gapped setup). Config discovery walks up from cwd; --config <path> overrides.
• Backing store. The config's store key: sqlite (default, zero-dependency, Node's built-in SQLite), or the experimental duckdb and turso, whose engine package the first command that opens such a tree installs on its own (@duckdb/node-api, a one-time native download of about 110 MB; @tursodatabase/database, much smaller). The same commands and tables run on all three. Two things do not port, and each one decides a tree. FTS5 syntax: under duckdb and turso, search text and raw MATCH reject FTS5's prefix, boolean, NEAR, initial-token and column-filter operators with a named error, and sqlite's FTS5 SQL (MATCH, snippet(), bm25()) does not run, so saved queries written in that syntax are sqlite dialect; a tree whose saved queries or search vocabulary depend on FTS5 operators stays on sqlite. SQL functions: has/basename run on all three (turso rewrites them into portable SQL rather than registering them); segment runs on sqlite and duckdb only, so a tree whose queries call segment stays off turso. sense watch runs on all three; duckdb and turso lock their cache file per connection, so a concurrent command waits out the watcher's current cycle instead of failing. Each store keeps its own cache file (.sense/cache.db, .sense/cache.duckdb, .sense/cache.turso.db); switching stores is a rebuild, not a migration. Speed is the other axis, and it does not follow from any of the above. sqlite is fastest at both building an index and querying one. duckdb and turso both cost noticeably more to build, turso the most on a large tree, since its engine costs more per write and more again to maintain each index; both then answer queries at close to sqlite's speed. Speed is not the only reason to choose, though: the cache is an ordinary database file, so a tree indexed under duckdb is readable by anything in DuckDB's ecosystem, and turso brings concurrent access, non-blocking I/O and encryption. Pick for what you intend to do with the file, then check the per-store figures. Per-store figures: BENCHMARKING.md in the sensemaking repo.
• Globs resolve relative to the config file, never the cwd.
• sense status and sense map show each preset's coverage (files matched, embedded count), so what a config actually indexes is always visible in output. A config edit that changes coverage rebuilds the cache and names the preset that caused it on stderr.

Presets

A preset is a named, self-contained bundle of settings. default (required) is what bare commands use; every other preset is addressed by name (sense search "..." --preset raw, or "preset": "raw" in a saved search). No inheritance: what a preset states is all it does.