Skip to content

Roadmap

Recently shipped

  • v1.7.24 (2026-05-16) — embeddings.md BYOM callout + 5 devDep bumps
  • v1.7.23 (2026-05-16) — BYOM Ollama auto-pull gate + logger sweep + SIGTERM unit test
  • v1.7.22 (2026-05-15) — structured stderr (NDJSON) + Ollama preparing-state + dependabot security bumps + SIGTERM drain integration test
  • v1.7.21 (2026-04-27) — install.sh vault-picker fix + auto ollama pull + docs/test polish
  • v1.7.20 (2026-04-27) — Ollama prefix-lookup bug + 13 audit polish items

Planned / In progress

Note on version numbering. v1.7.0 shipped on 2026-04-24 as a different bundle than this page originally planned — it became the fault-tolerant-embeddings / expanded-presets / BYOM CLI / index_status / macOS installer release (see CHANGELOG). The block-ref editing / FTS5 frontmatter / topic-aware PageRank work below has therefore been renumbered to v1.8.0.

v1.7.25+ — open follow-ups (uncommitted, design TBD)

  • CLI --accept-byom-pull flag — v1.7.23 added the BYOM auto-pull gate with an env-var opt-in (OBSIDIAN_BRAIN_OLLAMA_BYOM_AUTO_PULL=1). A one-shot CLI flag for users running obsidian-brain index user/custom-fork interactively would be more ergonomic than the env var, but needs net-new prompt infrastructure (the CLI is flag-only today). Defer until there's user demand or until the broader Templater-style dynamic tool registration (v2.0) lands the prompt scaffolding.
  • better-sqlite3 12.10.0+ bump — held back from v1.7.24 because the bump removed Node.js v20 prebuilt binaries (WiseLibs/better-sqlite3#1468). Bundle with v1.8.0's Node-minimum bump from >=20.19.0 to >=22.0.0 (Node 20 hit EOL in April 2026).

Audit items explicitly accepted as-is

Listed so they're answered, not silently dropped — these are working as designed or not worth the change for the value:

  • D1 — nodes.content stored verbatim alongside chunks.content. ~40 MB doubling on a 10k-note vault. Joining-on-read is slower than the current denormalised layout; the disk overhead is acceptable.
  • D2 — two parallel vec0 indexes (note-level + chunk-level). Powers unique:notes vs unique:chunks search modes; both are real product features with different recall semantics. Collapsing to one would lose a feature.
  • O6 — boot-time probe of Ollama liveness. Already addressed via /api/show + /api/tags calls inside OllamaEmbedder.init(). The remaining "fail-loudly-at-boot-if-daemon-down" pattern is partial because the design intentionally lets handshake complete and surfaces the error per-tool-call (so MCP transport stays alive even when Ollama isn't).
  • S3 — discoveredMaxTokens vs advertisedMaxTokens divergence. Two-field design is intentional: advertised is from tokenizer_config.json, discovered is empirically tested with reserved special tokens. Documenting the difference is a v1.7.21 polish item under D3/D4.
  • S4 — no model_info(preset) MCP tool. The CLI's models check covers this. Adding an MCP variant would duplicate without a real client need.
  • V3 — companion-plugin error message truncated. The truncation is the harness's display logic, not the server's stderr. Server error string is fine; consumer should adapt.

v1.8.0 — block-ref editing + FTS5 frontmatter + topic-aware PageRank (~1-2 weeks)

Pairs with plugin v1.8.0.

  • edit_note(mode: 'patch_block', block_id: '^abc123'). Parse ^[a-zA-Z0-9-]+$ at line end into a new block_refs(id, node_id, start_line, end_line) table; boundary is text from ID back to previous blank line or previous block ID. Meaningful Obsidian-power-user gap (lstpsche ships it, we don't). Adds one tool — count becomes 19.
  • FTS5 frontmatter fielding. Tokenize frontmatter alongside title + body as a fielded index, moderate 2× boost. Complements v1.4.0's stemming + column-weighted BM25.
  • find_influential_notes_about(topic). The tool only obsidian-brain can ship because only it co-locates both signals: semantic neighborhood → induced subgraph → PageRank on the subgraph. Replaces the noisy full-vault PageRank for topic-aware "what are the hubs here". One new tool — count becomes 20.

Audit items needing more than a patch

These v1.7.18-audit items need schema migrations, new tools, or a multi-tool refactor — not appropriate for v1.7.x patch releases. Bundled here.

  • C2 / C3 — failed_chunks audit-table gap. Notes that produce zero chunks bypass the audit table entirely (the table only records embedding attempts that errored), so failedChunksTotal: 0 even when 108 notes are silently absent. Add a reasonCode column on failed_chunks (values: no-embeddable-content, tokenizer-rejected, embedder-error, produced-zero-chunks) so every "this note isn't indexed" case has a machine-readable cause. Ship alongside a new MCP tool list_missing_embeddings({limit?}) so clients don't have to read kg.db directly to find which notes are missing. Tool count: 19 → 20 (or 21 if v1.8.0's find_influential_notes_about also lands).
  • C11 — multilingual-quality silently dropped 6 chunks. Symptom of C2/C3: same fix surfaces them. The chunker proactively detects transformers.js#267 candidates pre-embed and discards them without recording. The new produced-zero-chunks reasonCode makes them visible.
  • C10 — vault-side ignore patterns. Honor .gitignore if present; introduce .obsidianbrainignore for vaults that aren't git repos. Useful for test/CI vaults, transient _test-runner/ paths, and node_modules-style noise that currently gets indexed and counted in notesTotal.
  • M1 — response-shape consistency pass. Currently mixed: some tools return {data: [...]}, some return raw arrays, some return flat objects, some return {data: {nodes, edges}}. Pick one envelope ({data, context?}) and migrate every tool. Likely breaking — clients using parsed?.data ?? parsed defensively will keep working, but anyone strict-parsing will break. Plan as opt-in via response version negotiation, or accept the break with a major bump (push to v2.0 if so). Folds in: G7 (rank_notes(metric: 'both') returns {influence, bridging} while singles return [...]), M2 (read_note brief vs full lacks discriminator field), M4 (index_status mixes liveness flags + counts in one envelope — split or accept).
  • M3 — typed error codes. Replace stringly-typed errors (/companion plugin unavailable/, /dimensions not known yet/, /expected.*confirm:true/) with {code: 'E_PLUGIN_UNAVAILABLE'|...} envelope. Lets clients handle failures structurally instead of regex-matching prose. Same breaking-vs-additive trade-off as M1. Folds in: G8 (find_path_between returns {paths: []} for both "no path within depth" AND "graph disconnected" — add a reason enum to disambiguate).

v1.9.0 — graph analytics credibility writeup (~1 week)

Pairs with plugin v1.9.0 (alignment, no plugin code changes).

  • Evaluation on a real vault. Publish top-10 PageRank results on the author's actual vault, manual hit-rate assessment, write up the methodology. Per the competitive-analysis critique: an honest 60% hit rate is more credible than silence.
  • Blog post + README "how well does this work" section.
  • No feature code — the work is the eval + writeup.

v2.0 — daemon mode + ecosystem reach

Revisit when user demand (resource cost, install friction) actually surfaces. None of the below is committed or dated.

  • Multi-client daemon mode. One long-running daemon + per-client stdio-proxy shims. Shared embedder + watcher + SQLite. Saves ~200 MB RAM per extra MCP client. Needs: daemon lifecycle (auto-start, health, restart), Unix socket transport (Windows: named pipe), graceful upgrade, per-client auth. Worth it only when running 3+ simultaneous MCP clients is common.
  • Community plugin registry submission. PR obsidian-brain-plugin to obsidianmd/obsidian-releases for one-click install from Obsidian's in-app Community Plugins browser (no BRAT required). Wait until the plugin's endpoint surface has stabilised (post-v1.6.0 at earliest); registry review is 1–2 weeks and re-submitting after every API change is friction.
  • Dynamic Templater-style tool registration. If the companion plugin is installed + Templater is enabled, scan the user's templates and register each as a typed MCP tool (parsing tp.user.askString("X") prompts into Zod schemas). Lets "Claude, make me a meeting note" become meeting_notes({title, attendees, date}) with validation. High ceiling, niche audience.
  • Optional git integration for write auditing. If the vault is a git repo, each agent-initiated edit becomes a commit with attribution (agent: claude, tool: edit_note, note: X). Auditable + recoverable. Opt-in config flag so non-git users are unaffected.

Explicitly NOT planned

Stances worth naming so expectations stay calibrated:

  • Cloud embeddings (OpenAI, Voyage, Cohere). Deliberate local-only stance — zero egress, works offline, nothing leaves the machine. The v1.4.0 Embedder interface is forkable if anyone wants a cloud variant, but it won't be a first-party config knob.
  • DQL execution without Obsidian running. Reimplementing Dataview's query engine + metadata cache outside Obsidian is months of work for no meaningful gain over the companion-plugin approach.
  • Full Bases feature parity — rendered card / calendar / map views. MCP returns data; rendering is the client's job.
  • DataviewJS / JS-block execution. Arbitrary JS eval against the vault is a security hole; skip permanently.
  • Plugin writes from the server (move Obsidian's cursor, open a file in the UI, inject text into the editor). The companion plugin is read-only by design. If we ever want this, it's a separately-scoped feature with its own threat model and opt-in.
  • Rewrite in Rust. Node + sqlite-vec + transformers.js covers the performance envelope. A Rust rewrite would cost months for no user-visible win.
  • Collapse to 5 hub-tools (aaronsb-style). Good pattern for single-surface operations; wrong for a tool set with distinct graph-analytics + writes + search semantics. We take the next_actions hint pattern (v1.5.0), not the tool-count philosophy.

Ideas

New ideas go here. To add one from the command line: npm run idea -- "your idea text".

  • 2026-04-23 · Cross-vault search across multiple VAULT_PATHs
  • 2026-04-23 · Auto-tag suggestions from embedding clusters
  • 2026-04-23 · Periodic "what have I been working on?" digest tool using recent edit timestamps

Versioning policy

Plugin and server ship aligned at major.minor — when server goes X.Y.0, plugin goes X.Y.0 the same day (even if the plugin has no code changes, as a "version alignment" release with a CHANGELOG note). Patch versions may drift. The capabilities[] array in discovery.json remains the actual compatibility handshake; version numbers are a signal to users that "plugin 1.4.x works with server 1.4.x". The plugin jumps 0.2.1 → 1.4.0 in v1.4.0 to establish the alignment baseline.