@imunitic/synapse 0.2.11 → 0.2.13

package/commands/synapse-vault-tidy.md

@@ -101,11 +101,11 @@ findings for the Step 6 proposal instead of a silent edit:
 
 - **Broken links** — every `vault-unresolved` row whose `source` is in scope. Before writing the
   finding, check the vault's own 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 (`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.
+  to guesswork — a `SYNAPSE_VAULT_STORE=git` vault has one, since every agent-driven edit commits
+  into it automatically. Resolve the vault's filesystem path the same way `synapse.conf` 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
     hit means a note by that exact title was created at some point (even if later renamed or
     deleted): report it as *"used to be a note — find what it's called now, or was deleted"*.

package/harness/claude/hooks.json

@@ -21,15 +21,6 @@
       }
     ],
     "PostToolUse": [
-      {
-        "matcher": "Write|Edit|Bash",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "synapse-hook db-sync"
-          }
-        ]
-      },
       {
         "matcher": "Write|Edit|MultiEdit",
         "hooks": [

package/harness/codex/hooks.json

@@ -21,15 +21,6 @@
       }
     ],
     "PostToolUse": [
-      {
-        "matcher": "apply_patch|Bash",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "synapse-hook db-sync"
-          }
-        ]
-      },
       {
         "matcher": "apply_patch",
         "hooks": [

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

@@ -101,11 +101,11 @@ findings for the Step 6 proposal instead of a silent edit:
 
 - **Broken links** — every `vault-unresolved` row whose `source` is in scope. Before writing the
   finding, check the vault's own local git history to say *why* it's broken instead of leaving that
-  to guesswork — the vault is usually a git repo (a db-sync hook 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 its own conf file 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.
+  to guesswork — a `SYNAPSE_VAULT_STORE=git` vault has one, since every agent-driven edit commits
+  into it automatically. Resolve the vault's filesystem path the same way its own conf file 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
     hit means a note by that exact title was created at some point (even if later renamed or
     deleted): report it as *"used to be a note — find what it's called now, or was deleted"*.

package/harness/opencode/plugin/synapse.js

@@ -18,18 +18,11 @@
 // `tool.execute.after`'s real tool names/args, live-verified against a real
 // edit: `write` (`args.filePath`, `args.content`) and `edit` (`args.filePath`,
 // `args.oldString`, `args.newString`) -- both share `filePath`, matching
-// Claude Code's `Write`/`Edit` sharing `tool_input.file_path`. `db_sync.zig`
-// itself is a blind `git add -A && commit` against the vault's own repo, so
-// this plugin only needs to decide *whether* to fire it, not translate a
-// payload -- fired on the same write/edit tools, and on `bash` (`args.command`,
-// confirmed against `packages/core/src/tool/bash.ts` in the real
-// `sst/opencode` source) when the command actually names `synapse
-// vault-write`/`vault-patch` -- the CLI door skills use to reach the vault
-// (see `sb — Vault store backend selection`). Unlike Claude Code's/Codex's
-// `hooks.json`, which can only match a tool *name* and so must widen their
-// own matcher to `Bash` and let `db_sync.zig` filter the command text itself,
-// this plugin has the real args in hand before ever spawning the hook, so it
-// filters right here instead -- no spawn at all for an unrelated `bash` call.
+// Claude Code's `Write`/`Edit` sharing `tool_input.file_path`. Fired on
+// write/edit tools for `staleness` -- the vault's own version control
+// (`SYNAPSE_VAULT_STORE=git`) commits from inside `synapse`'s own CLI
+// (`vault-write`/`vault-patch`) itself now, needing no `PostToolUse`-style
+// hook here or on any other harness.
 //
 // `stop-nudge`'s Claude Code trigger (`Stop`, once per turn) maps to
 // `session.idle` -- live-verified as firing exactly once, after every tool
@@ -108,15 +101,6 @@ async function alreadyInjected(client, sessionID) {
 
 const EDIT_TOOLS = new Set(["write", "edit"])
 
-// A `bash` call whose command names a `synapse vault-write`/`vault-patch`
-// invocation -- the substring check a real shell quoting/path prefix can't
-// evade in the cases that matter (`synapse vault-write ...`, `/path/to/synapse
-// vault-patch ...`), matching `db_sync.zig`'s own `shouldSkipBash` filter for
-// the harnesses that can't pre-filter on args the way this plugin can.
-function isVaultWriteCommand(command) {
-  return typeof command === "string" && (command.includes("vault-write") || command.includes("vault-patch"))
-}
-
 // sessionID -> nudge text from a `stop-nudge` call that had nowhere to land
 // yet -- delivered on that session's next `chat.message`.
 const pendingNudge = new Map()
@@ -156,9 +140,6 @@ export const Synapse = async ({ directory, client }) => {
           session_id: input.sessionID,
           tool_input: { file_path: filePath },
         })
-        runHook("db-sync", {});
-      } else if (input.tool === "bash" && isVaultWriteCommand(input.args?.command)) {
-        runHook("db-sync", {});
       }
     },
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@imunitic/synapse",
-  "version": "0.2.11",
+  "version": "0.2.13",
   "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.11",
-    "@imunitic/synapse-linux-x64": "0.2.11",
-    "@imunitic/synapse-linux-arm64": "0.2.11"
+    "@imunitic/synapse-darwin-arm64": "0.2.13",
+    "@imunitic/synapse-linux-x64": "0.2.13",
+    "@imunitic/synapse-linux-arm64": "0.2.13"
   },
   "license": "SEE LICENSE IN LICENSE"
 }

package/skills/synapse-vault/SKILL.md

@@ -90,9 +90,10 @@ verification that cannot fail in the direction you are worried about is not a ve
 
 ## If you do destroy something
 
-`synapse-hook db-sync` auto-commits every vault edit, so the intact version is one
-`git show <sha>:<path>` away in the vault's own git history. That hook is a vault-wide undo for
-destructive tool calls, not merely a record of intentional edits.
+On a `SYNAPSE_VAULT_STORE=git` vault, every edit commits automatically, so the intact version is one
+`git show <sha>:<path>` away in the vault's own git history -- a vault-wide undo for destructive tool
+calls, not merely a record of intentional edits. The default `disk` backend keeps no history at all,
+so this safety net only exists once that backend is chosen.
 
 ## Tagging is part of writing a note, not a separate pass
 

package/synapse-claude.md

@@ -17,8 +17,11 @@ seeding the vault's foundational bootstrap file warrants a confirmation
 step the way an ordinary note-write doesn't.
 
 **This is a primary, load-bearing memory system, not an optional nicety.**
-Actively use it — don't wait to be asked. You MUST create or update a note
-whenever, during a session, any of the following happens. Before deciding
+Actively use it — don't wait to be asked, and don't wait for a hook to
+remind you either: the periodic nudge below is a backstop for a session
+that runs long and drifts, not the trigger that authorizes writing in the
+first place. You MUST create or update a note whenever, during a session,
+any of the following happens. Before deciding
 which folder, check `Index.md`'s folder list for the matching category —
 don't rely on categories already in memory from earlier in the session,
 since a vault owner's own `Index.md` is the only authority on what exists
@@ -98,8 +101,10 @@ The vault is reached through the `synapse` CLI — `synapse vault-read`/`vault-w
 `vault-search`/`vault-search-text`/`vault-doc-map`/`vault-patch`/`vault-backlinks`/`vault-links`/
 `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,
+Which concrete store the CLI talks to (`SYNAPSE_VAULT_STORE=disk`, the default; `obsidian`, opted
+into for a running Obsidian app's own live search relevance and graph data; or `git`, opted into for
+the vault to own its own version control -- commit on every write, push/pull in the background) 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