@imunitic/synapse 0.1.1 → 0.2.0

package/bin/synapse-setup.cjs

@@ -69,7 +69,7 @@ function readObsidianPluginData() {
   const { resolveVaultDir } = require("../lib/obsidian-mcp-refresh.cjs");
   const vault = resolveVaultDir();
   if (!vault || !fs.existsSync(vault)) {
-    fail("no OBSIDIAN_VAULT_DIR resolvable (see synapse.conf) -- can't configure the obsidian MCP connection");
+    fail("no SYNAPSE_VAULT_DIR resolvable (see synapse.conf) -- can't configure the obsidian MCP connection");
   }
   const pluginDataPath = path.join(vault, ".obsidian", "plugins", "obsidian-local-rest-api", "data.json");
   if (!fs.existsSync(pluginDataPath)) {

package/commands/synapse-design-note.md

@@ -17,14 +17,14 @@ Not every design discussion ends with something to build. See `Status: Reference
 ```
 /synapse-design-note "topic"           # Start or resume a design discussion
 /synapse-design-note --continue        # Resume an incomplete design note
-/synapse-design-note --list            # List every Obsidian design note, regardless of status
+/synapse-design-note --list            # List every design note in the vault, regardless of status
 ```
 
 ## Prerequisites
 
-- Requires the `obsidian` MCP server (`mcp__obsidian__*` tools). If unreachable, say so and stop —
-  there is no local-file fallback for this command.
-- If `designs/` doesn't exist in the vault yet, `mcp__obsidian__vault_write` creates it implicitly on
+- Requires the `synapse` CLI on `PATH`. If it errors (no vault configured), say so and stop —
+  there is no other fallback for this command.
+- If `designs/` doesn't exist in the vault yet, `synapse vault-write` creates it implicitly on
   first write — but add a `designs/` entry to the vault's `Index.md` folder layout in the same
   action (per the Synapse Vault folder-layout rule: a new top-level folder must never fall behind the
   index).
@@ -34,7 +34,7 @@ Not every design discussion ends with something to build. See `Status: Reference
 Every design note is tagged with the project it belongs to — both in the title
 (`{PROJECT} — {Topic}`) and as `project: {prefix}` in frontmatter (the same short prefix
 `/synapse-note --task` uses for task IDs) — so a flat `designs/` folder still reads clearly, and
-both note kinds can be filtered together via `search_query`.
+both note kinds can be filtered together via `synapse vault-search`.
 
 Same resolution `/synapse-note` uses for a missing task ID (its "Resolving a missing task ID"),
 reading the same file:
@@ -59,15 +59,22 @@ unrelated contexts (e.g. personal vs. work) never end up in the same place.
 ## Handling Arguments
 
 **No arguments:**
-1. Check for incomplete design notes: search `designs/` (via `mcp__obsidian__vault_list` +
-   `vault_read`, or `search_query` scoped to the `designs/` path) for notes whose `## Status` line
-   reads `Discussing`.
+1. Check for incomplete design notes: `synapse vault-search --fields frontmatter.title` with the
+   query below on stdin — one call, no separate read needed:
+
+   ```
+   {"and": [
+     {"glob": ["designs/*", {"var": "path"}]},
+     {"regexp": ["## Status\\nDiscussing", {"var": "content"}]}
+   ]}
+   ```
 2. If found: show a short state summary — title and current section — and offer to resume.
 3. If none: ask "What are we designing?"
 
 **With a topic:**
-1. Search first — `mcp__obsidian__search_simple` for the topic text across `designs/` (per the
-   Synapse Vault rule: link/reuse over duplicate). Also check for an obvious title match.
+1. Search first — `synapse vault-search-text "{topic}"` for the topic text, then filter matches to
+   `designs/` paths (per the Synapse Vault rule: link/reuse over duplicate). Also check for an
+   obvious title match.
 2. If found with `Status: Discussing` → ask "Resume this design?" or "Start fresh?"
 3. If found with `Status: Ready` → ask "Already marked Ready. Reopen to revise, or start a new note?"
 4. If found with `Status: Reference` → ask "This concluded as Reference (no implementation intended).
@@ -82,8 +89,9 @@ unrelated contexts (e.g. personal vs. work) never end up in the same place.
 4. None → "No incomplete design note found. Start one with `/synapse-design-note \"topic\"`."
 
 **--list:**
-1. `mcp__obsidian__vault_list` on `designs/`, then `vault_read` each (or a `search_query` scoped to
-   that path) to pull title and `## Status`.
+1. `synapse vault-search --fields frontmatter.title,content` with `{"glob": ["designs/*", {"var":
+   "path"}]}` on stdin — every design note regardless of status, title and `## Status` line both in
+   the same row.
 2. None found → "No design notes yet. Start one with `/synapse-design-note \"topic\"`."
 3. Group into **Active** (`Discussing`, `Ready`) and **Closed** (`Reference`) — active first, title
    and status in backticks, not bold.

package/commands/synapse-init.md

@@ -23,7 +23,7 @@ No arguments — always operates on the repo containing the current working dire
 
 ## Prerequisites
 
-- Requires the `obsidian` MCP server (`mcp__obsidian__*` tools). If unreachable, say so and stop.
+- Requires the `synapse` CLI on `PATH`. If it errors (no vault configured), say so and stop.
 - Must be run from inside a git repository. Synapse assumes git throughout (source hashing uses
   `git hash-object`, file enumeration uses `git ls-files`) — if `git rev-parse --show-toplevel`
   fails, stop and say this only works inside a git repo.
@@ -65,8 +65,8 @@ Every step below needs the same three facts, resolved once up front:
 
 ## Already initialized?
 
-Check whether `synapse/{repo}@{branch}/Index.md` exists (`mcp__obsidian__vault_list` on
-`synapse/{repo}@{branch}/`, or a direct `vault_read` attempt).
+Check whether `synapse/{repo}@{branch}/Index.md` exists: `synapse vault-read
+"synapse/{repo}@{branch}/Index.md"` and see whether it succeeds or reports "no such note".
 
 - **Doesn't exist** → this is a first-time build. Go to "First-time build" below.
 - **Exists, `remote` frontmatter matches** the resolved remote/path → this namespace already
@@ -97,7 +97,7 @@ yours and cannot be scripted because what counts as signal differs per codebase.
   (hash, digest, `## Sources` mirror, PUT), `synapse push-nodes`, `synapse build-index`,
   `synapse build-project-index`.
 
-**The work directory** defaults to `~/.claude/synapse-work/{repo}@{branch}/`, created on demand, and
+**The work directory** defaults to `~/.cache/synapse/work/{repo}@{branch}/`, created on demand, and
 holds `manifest.tsv`, `all.txt`, `lists/`, the authored `b-NN.md` bodies and the coverage files. Override with `$SYNAPSE_WORK_DIR` if you need to. Two things never to do: point it
 at the repo (`synapse` runs from inside the repo, so its working files would land in the user's
 checkout) or at the vault (Obsidian would index a file list that runs to six figures of lines).

package/commands/synapse-note.md

@@ -26,7 +26,7 @@ If no match is found, **don't just leave it blank** — see "Resolving a missing
 
 ## List mode
 
-Use `mcp__obsidian__search_query` with the JsonLogic query `{"var": "frontmatter.task_id"}` — this returns every file that has a `task_id` set, along with that file's `task_id` value as `result`. For each match, also read the file's `status` and `title` (either via a second query `{"var": "frontmatter.status"}` / `{"var": "frontmatter.title"}`, or via `mcp__obsidian__vault_read` on the handful of matched files — whichever is fewer round-trips for the count involved).
+Run `synapse vault-search --fields frontmatter.task_id,frontmatter.status,frontmatter.title` with the JsonLogic query `{"var": "frontmatter.task_id"}` on stdin — one call returns every file that has a `task_id` set, each row already carrying `task_id`/`status`/`title` together, no second query or extra read needed.
 
 Categorize:
 - **Prefixed notes**: `task_id` matches `{prefix}-\d+`. Group by the distinct prefix found (whatever
@@ -43,8 +43,8 @@ Do not modify any files in list mode.
 
 Everything after `--search` (trimmed, quotes stripped) is the query.
 
-1. Run `mcp__obsidian__search_simple` with the query — this gives full-text relevance-ranked matches with context, the closest equivalent to a title/body search.
-2. If the query looks like it's targeting metadata specifically (a tag, a task ID, a status value) rather than free text, also run `mcp__obsidian__search_query` with an appropriate JsonLogic filter (e.g. `{"==": [{"var": "frontmatter.task_id"}, "proj-032"]}`).
+1. Run `synapse vault-search-text "{query}"` — this gives full-text relevance-ranked matches with context, the closest equivalent to a title/body search.
+2. If the query looks like it's targeting metadata specifically (a tag, a task ID, a status value) rather than free text, also run `synapse vault-search --fields frontmatter.title` with an appropriate JsonLogic filter on stdin (e.g. `{"==": [{"var": "frontmatter.task_id"}, "proj-032"]}`).
 3. Report matches as `{title} — {file path relative to vault root}`, deduped across both. If nothing matches, say so plainly — the caller (agent or user) needs a clear "no existing note" signal to proceed with `--task`-less creation.
 
 Do not modify any files in search mode.
@@ -54,8 +54,8 @@ Do not modify any files in search mode.
 Triggered when `--task` is given but the title doesn't match `{prefix}-\d+`.
 
 The known project/prefix pairs live in a plain local file named `synapse-projects.conf` (one
-`project-name=prefix` line each) — read/appended with the Read/Edit tools, not the `obsidian`
-MCP server, since it's outside the vault. It is deliberately **not** part of the portable
+`project-name=prefix` line each) — read/appended with the Read/Edit tools, not the `vault-*` subcommands,
+since it's outside the vault. It is deliberately **not** part of the portable
 Synapse package and never copied between machines, so contexts that shouldn't mix (e.g.
 personal vs. work projects) never end up in the same file. It's self-managed — this command appends
 newly resolved pairs to it — but also plain text, so the user can add, fix, or remove a line by hand
@@ -77,8 +77,8 @@ unchanged for anyone who has never touched an XDG config directory.
 2. Check the resolved `synapse-projects.conf` for a line whose project name matches (loosely —
    case/whitespace-insensitive). If found, use that prefix directly — no need to ask.
 3. If the file doesn't have it yet, fall back to deducing from the vault itself (useful the first
-   time this runs, or for a project whose notes predate this file): `search_simple` for the
-   project/repo name across existing notes, and/or `search_query` on
+   time this runs, or for a project whose notes predate this file): `synapse vault-search-text` for
+   the project/repo name across existing notes, and/or `synapse vault-search` on
    `{"var": "frontmatter.task_id"}` to see which prefixes exist, then check whether any of those
    prefixed notes reference this project. If exactly one prefix confidently matches, use it.
 4. If nothing confidently matches (new project, or an ambiguous/multiple match), ask the user
@@ -87,11 +87,10 @@ 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
-   `mcp__obsidian__search_query` with `{"var": "frontmatter.task_id"}`,
-   filter the returned `result` 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: 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.
 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.
@@ -181,7 +180,7 @@ or supplied directly by a caller like `/synapse-task-note`):
    ## Notes
 
    ```
-4. Write it with `mcp__obsidian__vault_write`. Task mode: path
+4. Write it with `synapse vault-write <path>` (content on stdin). Task mode: path
    `tasks/{project}/{filename}.md` (project resolved in "Resolving the
    project folder" above). Bare mode: path `{category}/{filename}.md`
    (category resolved above).

package/commands/synapse-rebuild-diff.md

@@ -85,7 +85,7 @@ this command when it does. What no longer happens is arriving here merely becaus
   because it is not this checkout's namespace to diff at all. Never conflate the two: a non-ancestor
   baseline on a branch-identity match still proceeds normally, per the "One mechanical fact about
   branches" section above.
-- The work directory (`$SYNAPSE_WORK_DIR`, default `~/.claude/synapse-work/{repo}@{branch}/`) ideally
+- The work directory (`$SYNAPSE_WORK_DIR`, default `~/.cache/synapse/work/{repo}@{branch}/`) ideally
   holds the `manifest.tsv` from the original build. Without it, new paths cannot be classified as
   auto-claimable, and clustering decisions have to be re-derived — say so rather than proceeding as if
   nothing were missing. `synapse/{repo}@{branch}/_manifest.tsv` is the fallback copy.

package/commands/synapse-rebuild-full.md

@@ -29,7 +29,7 @@ No arguments — always operates on the repo and branch containing the current w
 
 ## Prerequisites
 
-- Requires the `obsidian` MCP server (`mcp__obsidian__*` tools). If unreachable, say so and stop —
+- Requires the `synapse` CLI on `PATH`. If it errors (no vault configured), say so and stop —
   same requirement `/synapse-init` has.
 - Must be run from inside a git repository, on a named branch (not detached `HEAD`) — same
   requirement `/synapse-init` has, since `synapse_namespace` needs a branch to key on.

package/commands/synapse-status.md

@@ -6,12 +6,11 @@ description: Print a read-only report of what in Synapse Vault currently needs a
 
 A read-only sweep over Synapse Vault answering one question: what currently needs a human decision?
 Five categories, one pass, printed as plain chat text -- an org-agenda-style check-in, not a document
-to hand to someone else and not a live dashboard (a published Artifact has no route to the local
-Obsidian REST API, so nothing here is ever presented that way). Run it on demand, or from a
-scheduled `/loop`/cron invocation of this same command -- never wired into `SessionStart`: two of
-the five categories need a per-note body read, not just a frontmatter check, and unlike `Index.md`
-this report is a periodic human check-in, not something the agent needs injected every session to
-behave correctly.
+to hand to someone else and not a live dashboard (a published Artifact has no route to the vault, so
+nothing here is ever presented that way). Run it on demand, or from a scheduled `/loop`/cron
+invocation of this same command -- never wired into `SessionStart`: some of the five categories need
+a per-note content read, not just a frontmatter check, and unlike `Index.md` this report is a
+periodic human check-in, not something the agent needs injected every session to behave correctly.
 
 Scoped to `designs/`/`tasks/` only -- the two folders `/synapse-design-note`/`/synapse-note --task`
 structurally require, so every Synapse install has them in the same shape. The free-form taxonomy
@@ -27,87 +26,104 @@ periodic look on their own schedule -- this report doesn't cover it.
 
 ## Prerequisites
 
-Requires the `obsidian` MCP server (`mcp__obsidian__*` tools). If unreachable, say so and stop --
-there is no local-file fallback.
+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
+CLI errors (no vault configured), say so and stop -- there is no other fallback.
 
 ## Producing the report
 
-Run all five queries in parallel where the tool call shape allows it; none depends on another's
-result.
+Run each query below via `synapse vault-search --fields <fields>`, with the JsonLogic query on stdin.
+`--fields` asks for exactly the columns the query needs back -- no separate read per match required,
+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/`:
+frontmatter (unlike task notes) -- a content match, scoped to `designs/`. Needs only the title:
 
 ```
+synapse vault-search --fields frontmatter.title <<'EOF'
 {"and": [
   {"glob": ["designs/*", {"var": "path"}]},
   {"regexp": ["## Status\\nDiscussing", {"var": "content"}]}
 ]}
+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/`:
+"`Ready` and missing that line" is a direct signal, not fuzzy title-matching against `tasks/`. Needs
+only the title:
 
 ```
+synapse vault-search --fields frontmatter.title <<'EOF'
 {"and": [
   {"glob": ["designs/*", {"var": "path"}]},
   {"regexp": ["## Status\\nReady", {"var": "content"}]},
   {"!": [{"regexp": ["Compiled task:", {"var": "content"}]}]}
 ]}
+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 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:
+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:
 
 ```
+synapse vault-search --fields frontmatter.title,content <<'EOF'
 {"and": [
   {"glob": ["designs/*", {"var": "path"}]},
   {"regexp": ["## Open Questions\\n- ", {"var": "content"}]}
 ]}
+EOF
 ```
 
-`regexp` is boolean-only (no captured groups), so getting each match's actual status needs a second
-pass. Run the same query three more times, `and`-ed with `{"regexp": ["## Status\\nDiscussing", ...]}`
-/ `Ready` / `Reference` respectively, to sort the matches from the first query into the three known
-statuses without a body read. **A design note written before `## Status` was standardized on those
-exact three words can carry free text there instead** (e.g. `Superseded by [[...]]`) -- it matches
-the first query but none of the three status-scoped ones. Whatever's left over after removing the
-Discussing/Ready/Reference matches from the first query's full result set is exactly this case:
-report those under a fourth bucket, "Other", rather than silently dropping them -- surfacing an odd
-note beats losing it, the same reasoning behind reporting a 0-unchecked task instead of hiding it
-(see Query 4 below).
+Do not chain further `and`/`regexp` conditions onto this query to sort matches by status -- compound
+`regexp` conditions against `content` have been observed to return results that are logically
+impossible (a query with strictly more AND-ed conditions returning *more* matches than one with
+fewer), so any query beyond a single `glob` + single `regexp` pair is unverified and not to be
+trusted here. Instead, take two things from each row's `content` column directly, no second call
+needed for either: the line following `## Status` (normally `Discussing`/`Ready`/`Reference`, but a
+note written before the three-word convention can carry free text instead, e.g. `Superseded by
+[[...]]` -- report that verbatim rather than forcing it into a bucket, surfacing an odd note beats
+losing it) 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.
 
 **4. Open task notes with at least one unchecked item.** Task notes carry `status:` in frontmatter,
-unlike design notes -- filter there first:
+unlike design notes -- filter there first, and request `content` to count `- [ ]` lines directly from
+the row rather than reading each match again:
 
 ```
+synapse vault-search --fields frontmatter.title,content <<'EOF'
 {"in": [{"var": "frontmatter.status"}, ["TODO", "IN-PROGRESS"]]}
+EOF
 ```
 
-Then `mcp__obsidian__vault_read` each match and count `- [ ]` lines in the body. A match with zero
-unchecked lines (a checklist that's fully checked but hasn't been promoted to `REVIEW` yet) is still
-worth surfacing -- report it under this section with its count shown as 0, rather than silently
-dropping it, since that state itself is worth a human noticing.
+A match with zero unchecked lines (a checklist that's fully checked but hasn't been promoted to
+`REVIEW` yet) is still worth surfacing -- report it under this section with its count shown as 0,
+rather than silently dropping it, since that state itself is worth a human noticing.
 
-**5. Task notes stuck in `REVIEW`.** Frontmatter-only, no body read needed -- a fully-checked
-checklist waiting specifically on human sign-off, since `synapse-task` deliberately never promotes a
-note past `REVIEW` on its own:
+**5. Task notes stuck in `REVIEW`.** Frontmatter-only, no body needed -- a fully-checked checklist
+waiting specifically on human sign-off, since `synapse-task` deliberately never promotes a note past
+`REVIEW` on its own:
 
 ```
+synapse vault-search --fields frontmatter.title <<'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 (`Discussing`/`Ready`/`Reference`/the "Other" catch-all from Query 3 above), so put the
-status first, before the title, so it's the first thing scanned:
+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:
 
 ```
 ## Discussing
@@ -117,7 +133,7 @@ status first, before the title, so it's the first thing scanned:
 - {title}
 
 ## Open questions
-- **{status}** — {title}
+- **{status}** — {title} — {compiled task title, or "not compiled"}
 
 ## In progress (unchecked items)
 - {title} ({N} unchecked)
@@ -136,9 +152,8 @@ go dig for.
 
 ## Constraints
 
-- Read-only end to end. Never calls `vault_write`/`vault_patch`/`vault_move`/`vault_delete`/
-  `vault_copy` -- if a step here ever seems to need one, that step is out of scope, not a case to
-  special-case around.
+- Read-only end to end. Never calls `vault-write`/`vault-patch` -- if a step here ever seems to need
+  one, that step is out of scope, not a case to special-case around.
 - No Artifact/web-UI output. No `SessionStart` wiring. Not a new binary CLI subcommand -- every
-  category above is a plain mechanical query already reachable through `mcp__obsidian__*` tools.
+  category above is a plain mechanical query already reachable through `synapse vault-search`.
 - Scoped to `designs/`/`tasks/` only -- never `inbox/`/`research/`/`scratchpad/`.

package/commands/synapse-task-note.md

@@ -89,12 +89,19 @@ duplicate that scaffolding here, just supply its inputs:
 
 ## Linking back
 
-After creation, patch the design note: add `> Compiled task: [[{task note title}]]` near the top
-(via `mcp__obsidian__vault_patch`) — a small annotation line, same idea as any other cross-reference
-you'd drop near a note's title. This is a one-time link; the design note's `Status` itself does not
-change and does not need to track the task's progress — Obsidian's own backlinks panel already
-surfaces the live task note from the design note, and the task's `status:` frontmatter is the
-authoritative progress signal from here on.
+After creation, patch the design note: add `> Compiled task: [[{task note title}]]` near the top —
+right after the `# {title}` heading, before `## Status`:
+
+```
+printf '> Compiled task: [[%s]]\n\n' "{task note title}" | \
+  synapse vault-patch "{design note path}" --heading "{design note title}" --prepend
+```
+
+A small annotation line, same idea as any other cross-reference you'd drop near a note's title. This
+is a one-time link; the design note's `Status` itself does not change and does not need to track the
+task's progress — Obsidian's own backlinks panel (or a plain `synapse vault-search-text` for the task
+note's title, on a disk-backed vault) already surfaces the live task note from the design note, and
+the task's `status:` frontmatter is the authoritative progress signal from here on.
 
 ## Confirm
 

package/commands/synapse-vault-tidy.md

@@ -89,7 +89,7 @@ instead of a silent edit:
   local git history to say *why* it's broken instead of leaving that to guesswork — the vault is
   usually a git repo (`db-sync` auto-commits every agent-driven edit into it, opt-in per vault, same
   precondition as that hook). Resolve the vault's filesystem path the same way `synapse.conf`
-  already does (`OBSIDIAN_VAULT_DIR`), skip this sub-step entirely if `{vault}/.git` doesn't exist,
+  already does (`SYNAPSE_VAULT_DIR`), skip this sub-step entirely if `{vault}/.git` doesn't exist,
   and never let a missing/unreachable git repo block the rest of the finding — worst case it's
   reported with no history context, same as today.
   - `git -C {vault} log --all --diff-filter=A --name-only --pretty=format: -- "**/{target}.md"` — a

package/harness/claude/hooks.json

@@ -22,7 +22,7 @@
     ],
     "PostToolUse": [
       {
-        "matcher": "Write|Edit|mcp__obsidian__vault_(write|patch|append|delete|move)",
+        "matcher": "Write|Edit|Bash|mcp__obsidian__vault_(write|patch|append|delete|move)",
         "hooks": [
           {
             "type": "command",

package/harness/codex/hooks.json

@@ -22,7 +22,7 @@
     ],
     "PostToolUse": [
       {
-        "matcher": "apply_patch|mcp__obsidian__vault_(write|patch|append|delete|move)",
+        "matcher": "apply_patch|Bash|mcp__obsidian__vault_(write|patch|append|delete|move)",
         "hooks": [
           {
             "type": "command",

package/harness/codex/skills/synapse-design-note/SKILL.md

@@ -29,9 +29,9 @@ There is no flag syntax here — read intent from how the user asks:
 
 ## Prerequisites
 
-- Requires the `obsidian` MCP server (`mcp__obsidian__*` tools). If unreachable, say so and stop —
-  there is no local-file fallback for this skill.
-- If `designs/` doesn't exist in the vault yet, `mcp__obsidian__vault_write` creates it implicitly on
+- Requires the `synapse` CLI on `PATH`. If it errors (no vault configured), say so and stop —
+  there is no other fallback for this skill.
+- If `designs/` doesn't exist in the vault yet, `synapse vault-write` creates it implicitly on
   first write — but add a `designs/` entry to the vault's index note's folder layout in the same
   action (per the Synapse Vault folder-layout rule: a new top-level folder must never fall behind the
   index).
@@ -41,7 +41,7 @@ There is no flag syntax here — read intent from how the user asks:
 Every design note is tagged with the project it belongs to — both in the title
 (`{PROJECT} — {Topic}`) and as `project: {prefix}` in frontmatter (the same short prefix the
 synapse-note skill's task mode uses for task IDs) — so a flat `designs/` folder still reads clearly,
-and both note kinds can be filtered together via `search_query`.
+and both note kinds can be filtered together via `synapse vault-search`.
 
 Same resolution the synapse-note skill uses for a missing task ID (its "Resolving a missing task
 ID"), reading the same file:
@@ -66,15 +66,22 @@ unrelated contexts (e.g. personal vs. work) never end up in the same place.
 ## Handling intent
 
 **No specific signal:**
-1. Check for incomplete design notes: search `designs/` (via `mcp__obsidian__vault_list` +
-   `vault_read`, or `search_query` scoped to the `designs/` path) for notes whose `## Status` line
-   reads `Discussing`.
+1. Check for incomplete design notes: `synapse vault-search --fields frontmatter.title` with the
+   query below on stdin — one call, no separate read needed:
+
+   ```
+   {"and": [
+     {"glob": ["designs/*", {"var": "path"}]},
+     {"regexp": ["## Status\\nDiscussing", {"var": "content"}]}
+   ]}
+   ```
 2. If found: show a short state summary — title and current section — and offer to resume.
 3. If none: ask "What are we designing?"
 
 **With a topic:**
-1. Search first — `mcp__obsidian__search_simple` for the topic text across `designs/` (per the
-   Synapse Vault rule: link/reuse over duplicate). Also check for an obvious title match.
+1. Search first — `synapse vault-search-text "{topic}"` for the topic text, then filter matches to
+   `designs/` paths (per the Synapse Vault rule: link/reuse over duplicate). Also check for an
+   obvious title match.
 2. If found with `Status: Discussing` → ask "Resume this design?" or "Start fresh?"
 3. If found with `Status: Ready` → ask "Already marked Ready. Reopen to revise, or start a new note?"
 4. If found with `Status: Reference` → ask "This concluded as Reference (no implementation intended).
@@ -89,8 +96,9 @@ unrelated contexts (e.g. personal vs. work) never end up in the same place.
 4. None → "No incomplete design note found. Tell me what you'd like to design and I'll start one."
 
 **Listing design notes:**
-1. `mcp__obsidian__vault_list` on `designs/`, then `vault_read` each (or a `search_query` scoped to
-   that path) to pull title and `## Status`.
+1. `synapse vault-search --fields frontmatter.title,content` with `{"glob": ["designs/*", {"var":
+   "path"}]}` on stdin — every design note regardless of status, title and `## Status` line both in
+   the same row.
 2. None found → "No design notes yet. Tell me what you'd like to design and I'll start one."
 3. Group into **Active** (`Discussing`, `Ready`) and **Closed** (`Reference`) — active first, title
    and status in backticks, not bold.

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

@@ -23,7 +23,7 @@ directory.
 
 ## Prerequisites
 
-- Requires the `obsidian` MCP server (`mcp__obsidian__*` tools). If unreachable, say so and stop.
+- Requires the `synapse` CLI on `PATH`. If it errors (no vault configured), say so and stop.
 - Must be run from inside a git repository. Synapse assumes git throughout (source hashing uses
   `git hash-object`, file enumeration uses `git ls-files`) — if `git rev-parse --show-toplevel`
   fails, stop and say this only works inside a git repo.
@@ -65,8 +65,8 @@ Every step below needs the same three facts, resolved once up front:
 
 ## Already initialized?
 
-Check whether `synapse/{repo}@{branch}/Index.md` exists (`mcp__obsidian__vault_list` on
-`synapse/{repo}@{branch}/`, or a direct `vault_read` attempt).
+Check whether `synapse/{repo}@{branch}/Index.md` exists: `synapse vault-read
+"synapse/{repo}@{branch}/Index.md"` and see whether it succeeds or reports "no such note".
 
 - **Doesn't exist** → this is a first-time build. Go to "First-time build" below.
 - **Exists, `remote` frontmatter matches** the resolved remote/path → this namespace already
@@ -97,7 +97,7 @@ yours and cannot be scripted because what counts as signal differs per codebase.
   (hash, digest, `## Sources` mirror, PUT), `synapse push-nodes`, `synapse build-index`,
   `synapse build-project-index`.
 
-**The work directory** defaults to `~/.claude/synapse-work/{repo}@{branch}/`, created on demand, and
+**The work directory** defaults to `~/.cache/synapse/work/{repo}@{branch}/`, created on demand, and
 holds `manifest.tsv`, `all.txt`, `lists/`, the authored `b-NN.md` bodies and the coverage files. Override with `$SYNAPSE_WORK_DIR` if you need to. Two things never to do: point it
 at the repo (`synapse` runs from inside the repo, so its working files would land in the user's
 checkout) or at the vault (Obsidian would index a file list that runs to six figures of lines).

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

@@ -44,7 +44,7 @@ proceeding.
 
 ## List mode
 
-Use `mcp__obsidian__search_query` with the JsonLogic query `{"var": "frontmatter.task_id"}` — this returns every file that has a `task_id` set, along with that file's `task_id` value as `result`. For each match, also read the file's `status` and `title` (either via a second query `{"var": "frontmatter.status"}` / `{"var": "frontmatter.title"}`, or via `mcp__obsidian__vault_read` on the handful of matched files — whichever is fewer round-trips for the count involved).
+Run `synapse vault-search --fields frontmatter.task_id,frontmatter.status,frontmatter.title` with the JsonLogic query `{"var": "frontmatter.task_id"}` on stdin — one call returns every file that has a `task_id` set, each row already carrying `task_id`/`status`/`title` together, no second query or extra read needed.
 
 Categorize:
 - **Prefixed notes**: `task_id` matches `{prefix}-\d+`. Group by the distinct prefix found (whatever
@@ -61,8 +61,8 @@ Do not modify any files in list mode.
 
 The user's search text is the query — whatever they named after asking to search, quotes stripped.
 
-1. Run `mcp__obsidian__search_simple` with the query — this gives full-text relevance-ranked matches with context, the closest equivalent to a title/body search.
-2. If the query looks like it's targeting metadata specifically (a tag, a task ID, a status value) rather than free text, also run `mcp__obsidian__search_query` with an appropriate JsonLogic filter (e.g. `{"==": [{"var": "frontmatter.task_id"}, "proj-032"]}`).
+1. Run `synapse vault-search-text "{query}"` — this gives full-text relevance-ranked matches with context, the closest equivalent to a title/body search.
+2. If the query looks like it's targeting metadata specifically (a tag, a task ID, a status value) rather than free text, also run `synapse vault-search --fields frontmatter.title` with an appropriate JsonLogic filter on stdin (e.g. `{"==": [{"var": "frontmatter.task_id"}, "proj-032"]}`).
 3. Report matches as `{title} — {file path relative to vault root}`, deduped across both. If nothing matches, say so plainly — the caller (agent or user) needs a clear "no existing note" signal to proceed with task-mode-less creation.
 
 Do not modify any files in search mode.
@@ -72,8 +72,8 @@ Do not modify any files in search mode.
 Triggered when task mode is requested but the title doesn't match `{prefix}-\d+`.
 
 The known project/prefix pairs live in a plain local file named `synapse-projects.conf` (one
-`project-name=prefix` line each) — read/appended as a plain text file, not the `obsidian`
-MCP server, since it's outside the vault. It is deliberately **not** part of the portable
+`project-name=prefix` line each) — read/appended as a plain text file, not the `vault-*` subcommands,
+since it's outside the vault. It is deliberately **not** part of the portable
 Synapse package and never copied between machines, so contexts that shouldn't mix (e.g.
 personal vs. work projects) never end up in the same file. It's self-managed — this skill appends
 newly resolved pairs to it — but also plain text, so the user can add, fix, or remove a line by hand
@@ -95,8 +95,8 @@ unchanged for anyone who has never touched an XDG config directory.
 2. Check the resolved `synapse-projects.conf` for a line whose project name matches (loosely —
    case/whitespace-insensitive). If found, use that prefix directly — no need to ask.
 3. If the file doesn't have it yet, fall back to deducing from the vault itself (useful the first
-   time this runs, or for a project whose notes predate this file): `search_simple` for the
-   project/repo name across existing notes, and/or `search_query` on
+   time this runs, or for a project whose notes predate this file): `synapse vault-search-text` for
+   the project/repo name across existing notes, and/or `synapse vault-search` on
    `{"var": "frontmatter.task_id"}` to see which prefixes exist, then check whether any of those
    prefixed notes reference this project. If exactly one prefix confidently matches, use it.
 4. If nothing confidently matches (new project, or an ambiguous/multiple match), ask the user
@@ -105,9 +105,9 @@ 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
-   `mcp__obsidian__search_query` with `{"var": "frontmatter.task_id"}`,
-   filter the returned `result` values client-side for ones matching
+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.
 7. Format the new task ID **zero-padded to 3 digits** (`{prefix}-001`, `{prefix}-030`,
@@ -197,7 +197,7 @@ or supplied directly by a caller like the synapse-task-note skill):
    ## Notes
 
    ```
-4. Write it with `mcp__obsidian__vault_write`. Task mode: path
+4. Write it with `synapse vault-write <path>` (content on stdin). Task mode: path
    `tasks/{project}/{filename}.md` (project resolved in "Resolving the
    project folder" above). Bare mode: path `{category}/{filename}.md`
    (category resolved above).

package/harness/codex/skills/synapse-rebuild-diff/SKILL.md

@@ -85,7 +85,7 @@ this skill when it does. What no longer happens is arriving here merely because
   because it is not this checkout's namespace to diff at all. Never conflate the two: a non-ancestor
   baseline on a branch-identity match still proceeds normally, per the "One mechanical fact about
   branches" section above.
-- The work directory (`$SYNAPSE_WORK_DIR`, default `~/.claude/synapse-work/{repo}@{branch}/`) ideally
+- The work directory (`$SYNAPSE_WORK_DIR`, default `~/.cache/synapse/work/{repo}@{branch}/`) ideally
   holds the `manifest.tsv` from the original build. Without it, new paths cannot be classified as
   auto-claimable, and clustering decisions have to be re-derived — say so rather than proceeding as if
   nothing were missing. `synapse/{repo}@{branch}/_manifest.tsv` is the fallback copy.