@imunitic/synapse 0.2.6 → 0.2.8

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -43,7 +43,7 @@ frontmatter (unlike task notes) -- a content match, scoped to `designs/`. Needs
43
43
  synapse vault-search --fields frontmatter.title <<'EOF'
44
44
  {"and": [
45
45
  {"glob": ["designs/*", {"var": "path"}]},
46
- {"regexp": ["## Status\\nDiscussing", {"var": "content"}]}
46
+ {"regexp": ["## Status\nDiscussing", {"var": "content"}]}
47
47
  ]}
48
48
  EOF
49
49
  ```
@@ -57,7 +57,7 @@ only the title:
57
57
  synapse vault-search --fields frontmatter.title <<'EOF'
58
58
  {"and": [
59
59
  {"glob": ["designs/*", {"var": "path"}]},
60
- {"regexp": ["## Status\\nReady", {"var": "content"}]},
60
+ {"regexp": ["## Status\nReady", {"var": "content"}]},
61
61
  {"!": [{"regexp": ["Compiled task:", {"var": "content"}]}]}
62
62
  ]}
63
63
  EOF
@@ -74,22 +74,24 @@ rather than reading the note again:
74
74
  synapse vault-search --fields frontmatter.title,content <<'EOF'
75
75
  {"and": [
76
76
  {"glob": ["designs/*", {"var": "path"}]},
77
- {"regexp": ["## Open Questions\\n- ", {"var": "content"}]}
77
+ {"regexp": ["## Open Questions\n- ", {"var": "content"}]}
78
78
  ]}
79
79
  EOF
80
80
  ```
81
81
 
82
- Do not chain further `and`/`regexp` conditions onto this query to sort matches by status -- compound
83
- `regexp` conditions against `content` have been observed to return results that are logically
84
- impossible (a query with strictly more AND-ed conditions returning *more* matches than one with
85
- fewer), so any query beyond a single `glob` + single `regexp` pair is unverified and not to be
86
- trusted here. Instead, take two things from each row's `content` column directly, no second call
87
- needed for either: the line following `## Status` (normally `Discussing`/`Ready`/`Reference`, but a
88
- note written before the three-word convention can carry free text instead, e.g. `Superseded by
89
- [[...]]` -- report that verbatim rather than forcing it into a bucket, surfacing an odd note beats
90
- losing it) and the target of a `> Compiled task: [[...]]` line, if present -- that's the compiled
91
- task, parsed straight out of the wikilink text rather than resolved through any vault-wide link
92
- index.
82
+ This spans every status, so take two things from each row's `content` column directly instead of
83
+ chaining further status-specific `regexp` branches onto the query: the line following `## Status`
84
+ (normally `Discussing`/`Ready`/`Reference`, but a note written before the three-word convention can
85
+ carry free text instead, e.g. `Superseded by [[...]]` -- report that verbatim rather than forcing it
86
+ into a bucket, surfacing an odd note beats losing it) and the target of a `> Compiled task: [[...]]`
87
+ line, if present -- that's the compiled task, parsed straight out of the wikilink text rather than
88
+ resolved through any vault-wide link index.
89
+
90
+ A `regexp` pattern containing a literal newline (`\n`) must be written with a single backslash, byte-
91
+ for-byte, in the JSON text piped to `vault-search` -- the heredocs above are unquoted-delimiter
92
+ (`<<'EOF'`), so nothing here re-escapes it; `\\n` would reach the JSON parser as a literal backslash
93
+ followed by `n`, never matching a real line break, and every one of this command's five queries would
94
+ silently stop finding anything under a multi-line pattern.
93
95
 
94
96
  **4. Open task notes with at least one unchecked item.** Task notes carry `status:` in frontmatter,
95
97
  unlike design notes -- filter there first, and request `content` to count `- [ ]` lines directly from
@@ -30,9 +30,11 @@ of scope — foundational files, not taxonomy notes.
30
30
 
31
31
  Requires the `synapse` CLI on `PATH`, resolving a vault with a working `LinkGraph`
32
32
  (`synapse vault-backlinks`/`vault-links`/`vault-unresolved`/`vault-orphans`/`vault-deadends` — see
33
- `sb — Obsidian CLI as ObsidianStore's transport`). If `SYNAPSE_VAULT_STORE` resolves to a backend
34
- with no `LinkGraph` yet, these commands exit 1 saying so; stop and report that rather than falling
35
- back to anything else.
33
+ `sb — Obsidian CLI as ObsidianStore's transport` and `sb DiskStore's own index, Obsidian becomes
34
+ optional`). Both real coding-vault backends have one now `obsidian` reaching the CLI when
35
+ reachable and falling back to `disk`'s own implementation otherwise, `disk` always local. If
36
+ `SYNAPSE_VAULT_STORE` ever resolves to a backend with no `LinkGraph` at all, these commands exit 1
37
+ saying so; stop and report that rather than falling back to anything else.
36
38
 
37
39
  This command reaches the vault store only through the `synapse` CLI's `vault-*` subcommands, the
38
40
  same door every other skill uses — no MCP tool, no direct `ObsidianStore` call. `vault-links`/
@@ -45,7 +45,7 @@ frontmatter (unlike task notes) -- a content match, scoped to `designs/`. Needs
45
45
  synapse vault-search --fields frontmatter.title <<'EOF'
46
46
  {"and": [
47
47
  {"glob": ["designs/*", {"var": "path"}]},
48
- {"regexp": ["## Status\\nDiscussing", {"var": "content"}]}
48
+ {"regexp": ["## Status\nDiscussing", {"var": "content"}]}
49
49
  ]}
50
50
  EOF
51
51
  ```
@@ -59,7 +59,7 @@ title -- "`Ready` and missing that line" is a direct signal, not fuzzy title-mat
59
59
  synapse vault-search --fields frontmatter.title <<'EOF'
60
60
  {"and": [
61
61
  {"glob": ["designs/*", {"var": "path"}]},
62
- {"regexp": ["## Status\\nReady", {"var": "content"}]},
62
+ {"regexp": ["## Status\nReady", {"var": "content"}]},
63
63
  {"!": [{"regexp": ["Compiled task:", {"var": "content"}]}]}
64
64
  ]}
65
65
  EOF
@@ -75,21 +75,23 @@ the status directly out of the returned text rather than reading the note again:
75
75
  synapse vault-search --fields frontmatter.title,content <<'EOF'
76
76
  {"and": [
77
77
  {"glob": ["designs/*", {"var": "path"}]},
78
- {"regexp": ["## Open Questions\\n- ", {"var": "content"}]}
78
+ {"regexp": ["## Open Questions\n- ", {"var": "content"}]}
79
79
  ]}
80
80
  EOF
81
81
  ```
82
82
 
83
- Do not chain further `and`/`regexp` conditions onto this query to sort matches by status -- compound
84
- `regexp` conditions against `content` have been observed to return results that are logically
85
- impossible (a query with strictly more AND-ed conditions returning *more* matches than one with
86
- fewer), so any query beyond a single `glob` + single `regexp` pair is unverified and not to be
87
- trusted here. Instead, take the line following `## Status` directly out of each row's `content`
88
- column -- normally `Discussing`/`Ready`/`Reference`, but a design note written before that
89
- three-word convention was standardized can carry free text there instead (e.g. `Superseded by
90
- [[...]]`); report that verbatim rather than forcing it into a bucket, surfacing an odd note beats
91
- losing it, the same reasoning behind reporting a 0-unchecked task instead of hiding it (see Query 4
92
- below).
83
+ This spans every status, so take the line following `## Status` directly out of each row's `content`
84
+ column instead of chaining further status-specific `regexp` branches onto the query -- normally
85
+ `Discussing`/`Ready`/`Reference`, but a design note written before that three-word convention was
86
+ standardized can carry free text there instead (e.g. `Superseded by [[...]]`); report that verbatim
87
+ rather than forcing it into a bucket, surfacing an odd note beats losing it, the same reasoning behind
88
+ reporting a 0-unchecked task instead of hiding it (see Query 4 below).
89
+
90
+ A `regexp` pattern containing a literal newline (`\n`) must be written with a single backslash, byte-
91
+ for-byte, in the JSON text piped to `vault-search` -- the heredocs above are unquoted-delimiter
92
+ (`<<'EOF'`), so nothing here re-escapes it; `\\n` would reach the JSON parser as a literal backslash
93
+ followed by `n`, never matching a real line break, and every one of this skill's five queries would
94
+ silently stop finding anything under a multi-line pattern.
93
95
 
94
96
  **4. Open task notes with at least one unchecked item.** Task notes carry `status:` in frontmatter,
95
97
  unlike design notes -- filter there first, and request `content` to count `- [ ]` lines directly from
@@ -30,9 +30,11 @@ there is no argument to parse, every run produces the same one-pass sweep.
30
30
  ## Prerequisites
31
31
 
32
32
  Requires the `synapse` CLI on `PATH`, resolving a vault with a working link graph
33
- (`synapse vault-backlinks`/`vault-links`/`vault-unresolved`/`vault-orphans`/`vault-deadends`). If
34
- `SYNAPSE_VAULT_STORE` resolves to a backend with no link graph yet, these commands exit 1 saying so;
35
- stop and report that rather than falling back to anything else.
33
+ (`synapse vault-backlinks`/`vault-links`/`vault-unresolved`/`vault-orphans`/`vault-deadends`). Both
34
+ real coding-vault backends have one `disk` (the default) always local, `obsidian` reaching a
35
+ running app when reachable and falling back to `disk`'s own implementation otherwise. If
36
+ `SYNAPSE_VAULT_STORE` ever resolves to a backend with no link graph at all, these commands exit 1
37
+ saying so; stop and report that rather than falling back to anything else.
36
38
 
37
39
  This skill reaches the vault store only through the `synapse` CLI's `vault-*` subcommands, the same
38
40
  door every other skill uses — no MCP tool, no direct `ObsidianStore` call. `vault-links`/
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@imunitic/synapse",
3
- "version": "0.2.6",
3
+ "version": "0.2.8",
4
4
  "description": "Memory for Claude Code, Codex CLI, and OpenCode: a durable Obsidian vault plus a per-repo code graph.",
5
5
  "repository": {
6
6
  "type": "git",
@@ -22,9 +22,9 @@
22
22
  "*.conf.template"
23
23
  ],
24
24
  "optionalDependencies": {
25
- "@imunitic/synapse-darwin-arm64": "0.2.6",
26
- "@imunitic/synapse-linux-x64": "0.2.6",
27
- "@imunitic/synapse-linux-arm64": "0.2.6"
25
+ "@imunitic/synapse-darwin-arm64": "0.2.8",
26
+ "@imunitic/synapse-linux-x64": "0.2.8",
27
+ "@imunitic/synapse-linux-arm64": "0.2.8"
28
28
  },
29
29
  "license": "SEE LICENSE IN LICENSE"
30
30
  }
package/synapse-claude.md CHANGED
@@ -96,17 +96,18 @@ a real yes/no answer, not a formality to wave past.
96
96
 
97
97
  The vault is reached through the `synapse` CLI — `synapse vault-read`/`vault-write`/`vault-list`/
98
98
  `vault-search`/`vault-search-text`/`vault-doc-map`/`vault-patch`/`vault-backlinks`/`vault-links`/
99
- `vault-unresolved`/`vault-orphans`/`vault-deadends` — for reads *and* for writes, never by resolving
100
- a vault path or calling an `mcp__obsidian__*` tool directly. Which concrete store the CLI talks to
101
- (today, an Obsidian vault reached through its own official CLI; also a plain-disk vault,
102
- `SYNAPSE_VAULT_STORE=disk`) is resolved once, inside the compiled binary, from
103
- `SYNAPSE_VAULT_STORE`/`SYNAPSE_VAULT_DIR` — never something a skill or an agent turn needs to know or
104
- branch on. Today that means Obsidian running headless at login, with no plugin, no cert, no MCP
105
- server needed: `read`/`write`/`list` are plain disk I/O against the vault folder, and
106
- `search`/the link graph go through Obsidian's own CLI over its local socket — off by default, so a
107
- `vault-search-text`/`vault-backlinks`/etc. failure is worth mentioning **Settings General
108
- Advanced Command line interface** for, alongside stopping on it (see the precondition-failure
109
- rule below).
99
+ `vault-unresolved`/`vault-orphans`/`vault-deadends`/`vault-ambiguous`/`vault-rename` — for reads
100
+ *and* for writes, never by resolving a vault path or calling an `mcp__obsidian__*` tool directly.
101
+ Which concrete store the CLI talks to (`SYNAPSE_VAULT_STORE=disk`, the default; or `obsidian`,
102
+ opted into for a running Obsidian app's own live search relevance and graph data) is resolved once,
103
+ inside the compiled binary, from `SYNAPSE_VAULT_STORE`/`SYNAPSE_VAULT_DIR` — never something a skill
104
+ or an agent turn needs to know or branch on. By default that means no Obsidian dependency
105
+ whatsoever: `read`/`write`/`list`/`search`/the link graph/rename are all plain disk I/O and direct
106
+ computation against the vault folder. Under the opted-in `obsidian` backend, `search`/the link
107
+ graph/rename go through Obsidian's own CLI over its local socket instead when Obsidian is running,
108
+ falling back to the same disk-backed behavior automatically and silently (a one-line stderr note,
109
+ nothing an agent turn needs to react to) whenever it isn't — no precondition to check or fail on
110
+ either way.
110
111
 
111
112
  **Every write to a note goes through `synapse vault-write` or `vault-patch`. Never the `Write`/`Edit`
112
113
  tools on the on-disk path, and never a raw `mcp__obsidian__*` tool call either** — not for a one-line
@@ -2,6 +2,15 @@
2
2
  # synapse.conf anywhere. Edit the path below for this machine.
3
3
  SYNAPSE_VAULT_DIR="$HOME/Obsidian/YourVault"
4
4
 
5
+ # Default "disk" if unset: reads/writes the vault folder directly, no
6
+ # dependency on Obsidian being open at all -- search and the link graph
7
+ # (backlinks/links/unresolved/orphans/deadends/ambiguous) are computed by
8
+ # DiskStore's own scan. Set to "obsidian" to prefer a running Obsidian
9
+ # app's own live search relevance and graph data instead, falling back to
10
+ # the same disk-backed behavior automatically whenever Obsidian isn't
11
+ # reachable.
12
+ #SYNAPSE_VAULT_STORE="obsidian"
13
+
5
14
  # Where Synapse clones/builds tree-sitter grammars (shared across every
6
15
  # project -- not per-repo). Safe to leave at the default.
7
16
  SYNAPSE_GRAMMARS_DIR="$HOME/.cache/synapse/grammars"