@imunitic/synapse 0.2.8 → 0.2.10

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,18 +87,18 @@ 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.
-8. **Prepend the resolved task ID to the title itself** — the final title
-   becomes `{task-id} — {original title}` (em dash). Use this same final
-   title for both the `title` frontmatter field and the `# ` heading, and
-   use the resolved task ID for `task_id`. Don't let the frontmatter task
-   ID and the visible title disagree.
+8. **The title itself is never prefixed with the task ID.** `task_id` lives in frontmatter only —
+   the same convention `note_id` already uses for bare and design notes, now consistent across all
+   three kinds. `title`, the `# ` heading, and the filename all stay exactly the given topic.
 
 `/synapse-design-note`/`/synapse-task-note` read the same conf file directly for the same reason —
 they don't duplicate this resolution logic, just this file.
@@ -120,7 +120,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 +129,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 +180,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-task-note.md

@@ -68,8 +68,8 @@ Follow `/synapse-note`'s task-mode procedure exactly (its "Creating the note" se
 duplicate that scaffolding here, just supply its inputs:
 
 - **Title:** a short, plain description of the compiled plan (e.g. "Rollup direct storage
-  implementation") — `/synapse-note --task` resolves the project prefix and `task_id` and prepends
-  them itself.
+  implementation") — stays exactly this, never prefixed with the resolved `task_id`; `/synapse-note
+  --task` resolves the project prefix and `task_id` itself and puts them in frontmatter only.
 - **Project:** derive from the source design note's `project:` frontmatter — that prefix is already
   resolved (the design note went through `/synapse-design-note`'s resolution when it was created,
   which reads/appends the resolved `synapse-projects.conf`, per `/synapse-note`'s tiered lookup),
@@ -133,7 +133,7 @@ Claude: [reads designs/{PROJECT} — Rollup direct storage.md, Status: Ready]
 
         Project already known: {PROJECT} → {prefix}-005.
 
-        Created: tasks/{PROJECT}/{prefix}-005 — Rollup direct storage implementation.md
+        Created: tasks/{PROJECT}/Rollup direct storage implementation.md (task_id: {prefix}-005)
         Linked back from designs/{PROJECT} — Rollup direct storage.md.
 
         Status transitions happen automatically via the synapse-task skill once you start work.

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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@imunitic/synapse",
-  "version": "0.2.8",
+  "version": "0.2.10",
   "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.8",
-    "@imunitic/synapse-linux-x64": "0.2.8",
-    "@imunitic/synapse-linux-arm64": "0.2.8"
+    "@imunitic/synapse-darwin-arm64": "0.2.10",
+    "@imunitic/synapse-linux-x64": "0.2.10",
+    "@imunitic/synapse-linux-arm64": "0.2.10"
   },
   "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.conf.template

@@ -1,14 +1,14 @@
 # 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
-# dependency on Obsidian being open at all -- search and the link graph
+# external dependency at all -- search and the link graph
 # (backlinks/links/unresolved/orphans/deadends/ambiguous) are computed by
-# DiskStore's own scan. Set to "obsidian" to prefer a running Obsidian
-# app's own live search relevance and graph data instead, falling back to
-# the same disk-backed behavior automatically whenever Obsidian isn't
-# reachable.
+# 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