@imunitic/synapse 0.2.7 → 0.2.9

package/commands/synapse-design-note.md

@@ -51,6 +51,12 @@ reading the same file:
 4. If nothing confidently matches, ask the user for a short project tag — plain free-text, not a
    multiple-choice list, never hinting at any other project's tag as an example — then append the
    resolved pair to the conf file.
+5. Once the prefix is known, mint the note's `note_id` the same shared-counter way `/synapse-note`'s
+   "Resolving a missing task ID" step 6 does: `task_id` and `note_id` share one counter per prefix, so
+   check both fields (`synapse vault-search --fields frontmatter.task_id,frontmatter.note_id`, filter
+   both for `{prefix}-\d+`, take the highest number found across both, add 1; start at 1 if none exist
+   yet). This is frontmatter only — unlike a task note, a design note's title and filename stay
+   exactly `{PROJECT} — {Topic}`, with no id prepended.
 
 Never hardcode a specific project/prefix pair in this command's own instructions — the conf file is
 machine-local and deliberately outside the portable Synapse package, so projects from
@@ -174,6 +180,7 @@ so the `## Status` line is the only lifecycle marker that matters. It simply sta
 title: "{PROJECT} — {Topic}"
 project: {prefix}
 created: "{now}"
+note_id: {id}
 ---
 
 # {PROJECT} — {Topic}
@@ -205,7 +212,7 @@ edit history here worth tracking separately.
 ## Filename
 
 `designs/{PROJECT} — {Topic}.md` — sanitize filesystem-illegal characters (`/ : * ? " < > |`). No
-slug, no numbering — Obsidian filenames are the title itself.
+slug, no numbering — vault filenames are the title itself.
 
 ---
 

package/commands/synapse-note.md

@@ -87,10 +87,12 @@ unchanged for anyone who has never touched an XDG config directory.
 5. Whenever step 3 or step 4 resolves a pair not already in the conf file (including a fresh
    `project-name=prefix` line matching what was just deduced or asked), append it — so the next task
    for this project resolves from step 2 without a search or a question.
-6. Once the prefix is known, find the next number: run `synapse vault-search --fields
-   frontmatter.task_id` with `{"var": "frontmatter.task_id"}` on stdin, filter the returned values
-   client-side for ones matching `{prefix}-\d+`, take the highest number found, add 1. If none exist
-   yet for that prefix, start at 1.
+6. Once the prefix is known, find the next number. `task_id` and `note_id` (the id every note gets —
+   see "Assigning a note_id" below) share one counter per prefix, so this has to check both fields,
+   not just `task_id` alone: run `synapse vault-search --fields frontmatter.task_id,frontmatter.note_id`
+   with `{"or": [{"!=": [{"var": "frontmatter.task_id"}, null]}, {"!=": [{"var": "frontmatter.note_id"}, null]}]}`
+   on stdin, filter both returned columns client-side for values matching `{prefix}-\d+`, take the
+   highest number found across both, add 1. If none exist yet for that prefix, start at 1.
 7. Format the new task ID **zero-padded to 3 digits** (`{prefix}-001`, `{prefix}-030`,
    `{prefix}-037`, ...), matching the org-roam-era convention — widening
    naturally past 3 digits if a prefix ever needs it.
@@ -120,7 +122,7 @@ offered.
 
 Resolve this to a `category` matching the folder name exactly as
 `Index.md` currently spells it, before moving on to the creation steps
-below. No project-slug question is needed here — Obsidian filenames are
+below. No project-slug question is needed here — vault filenames are
 the title itself, not a slug-prefixed timestamp, so there's no separate
 namespacing concern to resolve. The note always lands flat at
 `{category}/{filename}.md` — never inferred into a subfolder such as a
@@ -129,6 +131,25 @@ triage/priority one a vault owner might maintain by hand (e.g.
 sorting a note into one of those, if a category has one, is never an
 agent's call to make.
 
+## Assigning a note_id (bare mode only)
+
+Task mode already gets its id via "Resolving a missing task ID" above. Bare mode needs one too —
+every note gets a `note_id`, not just tasks — but unlike task mode, this step never blocks with a
+question: a quick bare note shouldn't require an interrupt just to get an id.
+
+1. Try steps 1-3 of "Resolving a missing task ID" above (repo context, the resolved
+   `synapse-projects.conf`, then deducing from the vault itself) to resolve a project prefix. Skip
+   step 4 entirely — if none of the first three resolve one, fall through to step 2 below instead of
+   asking.
+2. If a prefix resolved: mint the next number the same shared-counter way as that section's step 6
+   (checking both `task_id` and `note_id` across the vault for that prefix). If no prefix resolved:
+   mint `note-NNN` instead — its own flat, project-less counter, found the same way (`synapse
+   vault-search --fields frontmatter.note_id`, filter for `note-\d+`, take the highest, add 1; start
+   at 1 if none exist yet).
+3. Carry the resolved `{id}` into "Creating the note" below as `note_id`. Unlike task mode, the title
+   itself is untouched — no id prefix on the visible title or the `title` frontmatter field for a bare
+   note.
+
 ## Resolving the project folder (task mode only)
 
 Task notes are grouped one level deeper by project, `tasks/{project}/{filename}.md` — see
@@ -161,6 +182,7 @@ or supplied directly by a caller like `/synapse-task-note`):
    ---
    title: "{title}"
    created: "{now}"
+   note_id: {id}
    ---
 
    ```

package/commands/synapse-status.md

@@ -27,7 +27,7 @@ periodic look on their own schedule -- this report doesn't cover it.
 ## Prerequisites
 
 Requires the `synapse` CLI on `PATH`. Backend-agnostic -- every query below goes through `synapse
-vault-search`, so it works the same whether the vault is Obsidian-backed or plain-disk-backed. If the
+vault-search`, so it works the same regardless of which `Store` backend is configured. If the
 CLI errors (no vault configured), say so and stop -- there is no other fallback.
 
 ## Producing the report
@@ -37,10 +37,11 @@ Run each query below via `synapse vault-search --fields <fields>`, with the Json
 since a matched row already carries them.
 
 **1. Design notes still `Discussing`.** Design notes carry status in-body under `## Status`, not in
-frontmatter (unlike task notes) -- a content match, scoped to `designs/`. Needs only the title:
+frontmatter (unlike task notes) -- a content match, scoped to `designs/`. Needs the title and the
+note's own `note_id` (every design note gets one, minted by `/synapse-design-note` itself):
 
 ```
-synapse vault-search --fields frontmatter.title <<'EOF'
+synapse vault-search --fields frontmatter.title,frontmatter.note_id <<'EOF'
 {"and": [
   {"glob": ["designs/*", {"var": "path"}]},
   {"regexp": ["## Status\nDiscussing", {"var": "content"}]}
@@ -51,10 +52,10 @@ EOF
 **2. `Ready` design notes with no compiled task yet.** `/synapse-task-note`'s own "Linking back"
 step patches a compiled design note with a `> Compiled task: [[...]]` line right after its title --
 "`Ready` and missing that line" is a direct signal, not fuzzy title-matching against `tasks/`. Needs
-only the title:
+the title and `note_id`:
 
 ```
-synapse vault-search --fields frontmatter.title <<'EOF'
+synapse vault-search --fields frontmatter.title,frontmatter.note_id <<'EOF'
 {"and": [
   {"glob": ["designs/*", {"var": "path"}]},
   {"regexp": ["## Status\nReady", {"var": "content"}]},
@@ -67,11 +68,11 @@ EOF
 at least one bullet -- a heading with nothing under it (fully pruned, per the Ready-gate convention
 `/synapse-design-note` now follows) doesn't count as open. Since this section spans every status,
 each line in the composed report also shows *which* status the note is currently in, and whether it
-has a compiled task note -- request `content` too, and pull both directly out of the returned text
-rather than reading the note again:
+has a compiled task note -- request `content` and `note_id` too, and pull the status/compiled-task
+target directly out of the returned text rather than reading the note again:
 
 ```
-synapse vault-search --fields frontmatter.title,content <<'EOF'
+synapse vault-search --fields frontmatter.title,frontmatter.note_id,content <<'EOF'
 {"and": [
   {"glob": ["designs/*", {"var": "path"}]},
   {"regexp": ["## Open Questions\n- ", {"var": "content"}]}
@@ -95,10 +96,11 @@ silently stop finding anything under a multi-line pattern.
 
 **4. Open task notes with at least one unchecked item.** Task notes carry `status:` in frontmatter,
 unlike design notes -- filter there first, and request `content` to count `- [ ]` lines directly from
-the row rather than reading each match again:
+the row rather than reading each match again. `task_id` is already frontmatter on every task note, no
+extra minting step needed:
 
 ```
-synapse vault-search --fields frontmatter.title,content <<'EOF'
+synapse vault-search --fields frontmatter.title,frontmatter.task_id,content <<'EOF'
 {"in": [{"var": "frontmatter.status"}, ["TODO", "IN-PROGRESS"]]}
 EOF
 ```
@@ -112,36 +114,40 @@ waiting specifically on human sign-off, since `synapse-task` deliberately never
 `REVIEW` on its own:
 
 ```
-synapse vault-search --fields frontmatter.title <<'EOF'
+synapse vault-search --fields frontmatter.title,frontmatter.task_id <<'EOF'
 {"==": [{"var": "frontmatter.status"}, "REVIEW"]}
 EOF
 ```
 
 ## Composing the report
 
-One section per category, in the order above. Each line names the note (title, or filename if no
-`title` frontmatter) plus the one identifying detail that category needs. The Open Questions section
-is the one place a note's status and compiled-task link also belong on the line -- every other
-section's heading already implies status (the "Discussing" section only ever holds `Discussing`
-notes) and compiled-task-ness (the "Ready, not yet compiled" section only ever holds notes without
-one), but Open Questions spans every status and both compiled and uncompiled notes, so put the status
-first, before the title, so it's the first thing scanned:
+One section per category, in the order above. Each line leads with the note's own id in brackets
+(`note_id` for a design note, `task_id` for a task note) — the whole point of every note now carrying
+one is that a human can act on a line directly ("open sb-068") without the title as an intermediate
+step — followed by the title, plus whatever other identifying detail that category needs. A note
+somehow missing its id (pre-dates the field, or the backfill hasn't reached it yet) drops the bracket
+entirely rather than printing an empty one, the same graceful-degradation the title-less case already
+gets. The Open Questions section is the one place a note's status and compiled-task link also belong
+on the line -- every other section's heading already implies status (the "Discussing" section only
+ever holds `Discussing` notes) and compiled-task-ness (the "Ready, not yet compiled" section only ever
+holds notes without one), but Open Questions spans every status and both compiled and uncompiled
+notes, so put the status first, before the id, so it's the first thing scanned:
 
 ```
 ## Discussing
-- {title}
+- [{note_id}] {title}
 
 ## Ready, not yet compiled
-- {title}
+- [{note_id}] {title}
 
 ## Open questions
-- **{status}** — {title} — {compiled task title, or "not compiled"}
+- **{status}** — [{note_id}] {title} — {compiled task title, or "not compiled"}
 
 ## In progress (unchecked items)
-- {title} ({N} unchecked)
+- [{task_id}] {title} ({N} unchecked)
 
 ## Awaiting review
-- {title}
+- [{task_id}] {title}
 ```
 
 Omit a section entirely when it has zero matches -- matching `/synapse-note --list`'s own convention

package/commands/synapse-vault-tidy.md

@@ -30,9 +30,11 @@ of scope — foundational files, not taxonomy notes.
 
 Requires the `synapse` CLI on `PATH`, resolving a vault with a working `LinkGraph`
 (`synapse vault-backlinks`/`vault-links`/`vault-unresolved`/`vault-orphans`/`vault-deadends` — see
-`sb — Obsidian CLI as ObsidianStore's transport`). If `SYNAPSE_VAULT_STORE` resolves to a backend
-with no `LinkGraph` yet, these commands exit 1 saying so; stop and report that rather than falling
-back to anything else.
+`sb — Obsidian CLI as ObsidianStore's transport` and `sb — DiskStore's own index, Obsidian becomes
+optional`). Both real coding-vault backends have one now — `obsidian` reaching the CLI when
+reachable and falling back to `disk`'s own implementation otherwise, `disk` always local. If
+`SYNAPSE_VAULT_STORE` ever resolves to a backend with no `LinkGraph` at all, these commands exit 1
+saying so; stop and report that rather than falling back to anything else.
 
 This command reaches the vault store only through the `synapse` CLI's `vault-*` subcommands, the
 same door every other skill uses — no MCP tool, no direct `ObsidianStore` call. `vault-links`/

package/harness/codex/skills/synapse-status/SKILL.md

@@ -29,7 +29,7 @@ produces the same five-category sweep.
 ## Prerequisites
 
 Requires the `synapse` CLI on `PATH`. Backend-agnostic -- every query below goes through `synapse
-vault-search`, so it works the same whether the vault is Obsidian-backed or plain-disk-backed. If the
+vault-search`, so it works the same regardless of which `Store` backend is configured. If the
 CLI errors (no vault configured), say so and stop -- there is no other fallback.
 
 ## Producing the report
@@ -39,10 +39,11 @@ Run each query below via `synapse vault-search --fields <fields>`, with the Json
 since a matched row already carries them.
 
 **1. Design notes still `Discussing`.** Design notes carry status in-body under `## Status`, not in
-frontmatter (unlike task notes) -- a content match, scoped to `designs/`. Needs only the title:
+frontmatter (unlike task notes) -- a content match, scoped to `designs/`. Needs the title and the
+note's own `note_id` (every design note gets one, minted at creation time):
 
 ```
-synapse vault-search --fields frontmatter.title <<'EOF'
+synapse vault-search --fields frontmatter.title,frontmatter.note_id <<'EOF'
 {"and": [
   {"glob": ["designs/*", {"var": "path"}]},
   {"regexp": ["## Status\nDiscussing", {"var": "content"}]}
@@ -53,10 +54,10 @@ EOF
 **2. `Ready` design notes with no compiled task yet.** The design-compilation skill's own "Linking
 back" step patches a compiled design note with a `> Compiled task: [[...]]` line right after its
 title -- "`Ready` and missing that line" is a direct signal, not fuzzy title-matching against
-`tasks/`. Needs only the title:
+`tasks/`. Needs the title and `note_id`:
 
 ```
-synapse vault-search --fields frontmatter.title <<'EOF'
+synapse vault-search --fields frontmatter.title,frontmatter.note_id <<'EOF'
 {"and": [
   {"glob": ["designs/*", {"var": "path"}]},
   {"regexp": ["## Status\nReady", {"var": "content"}]},
@@ -68,11 +69,12 @@ EOF
 **3. Design notes (any status) with a non-empty `## Open Questions`.** Match the heading followed by
 at least one bullet -- a heading with nothing under it (fully pruned, per the design-note skill's own
 Ready-gate convention) doesn't count as open. Since this section spans every status, each line in the
-composed report also shows *which* status the note is currently in -- request `content` too, and pull
-the status directly out of the returned text rather than reading the note again:
+composed report also shows *which* status the note is currently in, and whether it has a compiled task
+note -- request `content` and `note_id` too, and pull both directly out of the returned text rather
+than reading the note again:
 
 ```
-synapse vault-search --fields frontmatter.title,content <<'EOF'
+synapse vault-search --fields frontmatter.title,frontmatter.note_id,content <<'EOF'
 {"and": [
   {"glob": ["designs/*", {"var": "path"}]},
   {"regexp": ["## Open Questions\n- ", {"var": "content"}]}
@@ -80,12 +82,14 @@ synapse vault-search --fields frontmatter.title,content <<'EOF'
 EOF
 ```
 
-This spans every status, so take the line following `## Status` directly out of each row's `content`
-column instead of chaining further status-specific `regexp` branches onto the query -- normally
-`Discussing`/`Ready`/`Reference`, but a design note written before that three-word convention was
-standardized can carry free text there instead (e.g. `Superseded by [[...]]`); report that verbatim
-rather than forcing it into a bucket, surfacing an odd note beats losing it, the same reasoning behind
-reporting a 0-unchecked task instead of hiding it (see Query 4 below).
+This spans every status, so take two things from each row's `content` column directly instead of
+chaining further status-specific `regexp` branches onto the query: the line following `## Status`
+(normally `Discussing`/`Ready`/`Reference`, but a design note written before that three-word convention
+was standardized can carry free text there instead, e.g. `Superseded by [[...]]` -- report that
+verbatim rather than forcing it into a bucket, surfacing an odd note beats losing it, the same
+reasoning behind reporting a 0-unchecked task instead of hiding it, see Query 4 below) and the target
+of a `> Compiled task: [[...]]` line, if present -- that's the compiled task, parsed straight out of
+the wikilink text rather than resolved through any vault-wide link index.
 
 A `regexp` pattern containing a literal newline (`\n`) must be written with a single backslash, byte-
 for-byte, in the JSON text piped to `vault-search` -- the heredocs above are unquoted-delimiter
@@ -95,10 +99,11 @@ silently stop finding anything under a multi-line pattern.
 
 **4. Open task notes with at least one unchecked item.** Task notes carry `status:` in frontmatter,
 unlike design notes -- filter there first, and request `content` to count `- [ ]` lines directly from
-the row rather than reading each match again:
+the row rather than reading each match again. `task_id` is already frontmatter on every task note, no
+extra minting step needed:
 
 ```
-synapse vault-search --fields frontmatter.title,content <<'EOF'
+synapse vault-search --fields frontmatter.title,frontmatter.task_id,content <<'EOF'
 {"in": [{"var": "frontmatter.status"}, ["TODO", "IN-PROGRESS"]]}
 EOF
 ```
@@ -112,34 +117,39 @@ waiting specifically on human sign-off, since the task-status skill deliberately
 note past `REVIEW` on its own:
 
 ```
-synapse vault-search --fields frontmatter.title <<'EOF'
+synapse vault-search --fields frontmatter.title,frontmatter.task_id <<'EOF'
 {"==": [{"var": "frontmatter.status"}, "REVIEW"]}
 EOF
 ```
 
 ## Composing the report
 
-One section per category, in the order above. Each line names the note (title, or filename if no
-`title` frontmatter) plus the one identifying detail that category needs. The Open Questions section
-is the one place a note's status also belongs on the line -- every other section's heading already
-implies it (the "Discussing" section only ever holds `Discussing` notes), but Open Questions spans
-every status, so put the status first, before the title, so it's the first thing scanned:
+One section per category, in the order above. Each line leads with the note's own id in brackets
+(`note_id` for a design note, `task_id` for a task note) — the whole point of every note now carrying
+one is that a human can act on a line directly ("open sb-068") without the title as an intermediate
+step — followed by the title. A note somehow missing its id (pre-dates the field) drops the bracket
+entirely rather than printing an empty one, the same graceful-degradation the title-less case already
+gets. The Open Questions section is the one place a note's status and compiled-task link also belong
+on the line -- every other section's heading already implies status (the "Discussing" section only
+ever holds `Discussing` notes) and compiled-task-ness (the "Ready, not yet compiled" section only ever
+holds notes without one), but Open Questions spans every status and both compiled and uncompiled
+notes, so put the status first, before the id, so it's the first thing scanned:
 
 ```
 ## Discussing
-- {title}
+- [{note_id}] {title}
 
 ## Ready, not yet compiled
-- {title}
+- [{note_id}] {title}
 
 ## Open questions
-- **{status}** — {title}
+- **{status}** — [{note_id}] {title} — {compiled task title, or "not compiled"}
 
 ## In progress (unchecked items)
-- {title} ({N} unchecked)
+- [{task_id}] {title} ({N} unchecked)
 
 ## Awaiting review
-- {title}
+- [{task_id}] {title}
 ```
 
 Omit a section entirely when it has zero matches -- matching the note-listing skill's own convention

package/harness/codex/skills/synapse-vault-tidy/SKILL.md

@@ -30,9 +30,11 @@ there is no argument to parse, every run produces the same one-pass sweep.
 ## Prerequisites
 
 Requires the `synapse` CLI on `PATH`, resolving a vault with a working link graph
-(`synapse vault-backlinks`/`vault-links`/`vault-unresolved`/`vault-orphans`/`vault-deadends`). If
-`SYNAPSE_VAULT_STORE` resolves to a backend with no link graph yet, these commands exit 1 saying so;
-stop and report that rather than falling back to anything else.
+(`synapse vault-backlinks`/`vault-links`/`vault-unresolved`/`vault-orphans`/`vault-deadends`). Both
+real coding-vault backends have one — `disk` (the default) always local, `obsidian` reaching a
+running app when reachable and falling back to `disk`'s own implementation otherwise. If
+`SYNAPSE_VAULT_STORE` ever resolves to a backend with no link graph at all, these commands exit 1
+saying so; stop and report that rather than falling back to anything else.
 
 This skill reaches the vault store only through the `synapse` CLI's `vault-*` subcommands, the same
 door every other skill uses — no MCP tool, no direct `ObsidianStore` call. `vault-links`/

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@imunitic/synapse",
-  "version": "0.2.7",
+  "version": "0.2.9",
   "description": "Memory for Claude Code, Codex CLI, and OpenCode: a durable Obsidian vault plus a per-repo code graph.",
   "repository": {
     "type": "git",
@@ -22,9 +22,9 @@
     "*.conf.template"
   ],
   "optionalDependencies": {
-    "@imunitic/synapse-darwin-arm64": "0.2.7",
-    "@imunitic/synapse-linux-x64": "0.2.7",
-    "@imunitic/synapse-linux-arm64": "0.2.7"
+    "@imunitic/synapse-darwin-arm64": "0.2.9",
+    "@imunitic/synapse-linux-x64": "0.2.9",
+    "@imunitic/synapse-linux-arm64": "0.2.9"
   },
   "license": "SEE LICENSE IN LICENSE"
 }

package/skills/synapse-task/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: synapse-task
-description: Update Obsidian task notes' status frontmatter and Notes sections, enforcing status transitions so active work is IN-PROGRESS and completed checklists move only to REVIEW (not DONE).
+description: Update vault task notes' status frontmatter and Notes sections, enforcing status transitions so active work is IN-PROGRESS and completed checklists move only to REVIEW (not DONE).
 ---
 
 # Synapse Task Status Skill

package/synapse-claude.md

@@ -96,17 +96,18 @@ a real yes/no answer, not a formality to wave past.
 
 The vault is reached through the `synapse` CLI — `synapse vault-read`/`vault-write`/`vault-list`/
 `vault-search`/`vault-search-text`/`vault-doc-map`/`vault-patch`/`vault-backlinks`/`vault-links`/
-`vault-unresolved`/`vault-orphans`/`vault-deadends` — for reads *and* for writes, never by resolving
-a vault path or calling an `mcp__obsidian__*` tool directly. Which concrete store the CLI talks to
-(today, an Obsidian vault reached through its own official CLI; also a plain-disk vault,
-`SYNAPSE_VAULT_STORE=disk`) is resolved once, inside the compiled binary, from
-`SYNAPSE_VAULT_STORE`/`SYNAPSE_VAULT_DIR` — never something a skill or an agent turn needs to know or
-branch on. Today that means Obsidian running headless at login, with no plugin, no cert, no MCP
-server needed: `read`/`write`/`list` are plain disk I/O against the vault folder, and
-`search`/the link graph go through Obsidian's own CLI over its local socket — off by default, so a
-`vault-search-text`/`vault-backlinks`/etc. failure is worth mentioning **Settings → General →
-Advanced → Command line interface** for, alongside stopping on it (see the precondition-failure
-rule below).
+`vault-unresolved`/`vault-orphans`/`vault-deadends`/`vault-ambiguous`/`vault-rename` — for reads
+*and* for writes, never by resolving a vault path or calling an `mcp__obsidian__*` tool directly.
+Which concrete store the CLI talks to (`SYNAPSE_VAULT_STORE=disk`, the default; or `obsidian`,
+opted into for a running Obsidian app's own live search relevance and graph data) is resolved once,
+inside the compiled binary, from `SYNAPSE_VAULT_STORE`/`SYNAPSE_VAULT_DIR` — never something a skill
+or an agent turn needs to know or branch on. By default that means no Obsidian dependency
+whatsoever: `read`/`write`/`list`/`search`/the link graph/rename are all plain disk I/O and direct
+computation against the vault folder. Under the opted-in `obsidian` backend, `search`/the link
+graph/rename go through Obsidian's own CLI over its local socket instead when Obsidian is running,
+falling back to the same disk-backed behavior automatically and silently (a one-line stderr note,
+nothing an agent turn needs to react to) whenever it isn't — no precondition to check or fail on
+either way.
 
 **Every write to a note goes through `synapse vault-write` or `vault-patch`. Never the `Write`/`Edit`
 tools on the on-disk path, and never a raw `mcp__obsidian__*` tool call either** — not for a one-line

package/synapse.conf.template

@@ -1,6 +1,15 @@
 # synapse-setup configure copies this file in automatically when it finds no
 # synapse.conf anywhere. Edit the path below for this machine.
-SYNAPSE_VAULT_DIR="$HOME/Obsidian/YourVault"
+SYNAPSE_VAULT_DIR="$HOME/Vault/YourVault"
+
+# Default "disk" if unset: reads/writes the vault folder directly, no
+# external dependency at all -- search and the link graph
+# (backlinks/links/unresolved/orphans/deadends/ambiguous) are computed by
+# DiskStore's own scan. Set to the name of an extended store instead to
+# prefer a running external app's own live search relevance and graph data,
+# falling back to the same disk-backed behavior automatically whenever that
+# app isn't reachable -- see docs/synapse/synapse-extended-store.md.
+#SYNAPSE_VAULT_STORE="obsidian"
 
 # Where Synapse clones/builds tree-sitter grammars (shared across every
 # project -- not per-repo). Safe to leave at the default.