@imunitic/synapse 0.0.1-test.0

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

@@ -0,0 +1,133 @@
+---
+name: synapse-task-note
+description: Compile a Ready design note into a single tracked, checklist-based task note in Synapse Vault — delegates the actual note creation to the synapse-note skill's task mode under the hood. Use whenever the user wants to turn a settled design discussion into actionable, tracked work ("let's compile a task note", "let's turn this into a task", "make this a task now") — not for starting or continuing the design discussion itself (that's the synapse-design-note skill).
+---
+
+# Synapse Task Note: Compile a Design into a Tracked Checklist
+
+Compiles a `Ready` design note (from the synapse-design-note skill) into a single tracked task, using
+the vault's existing task-tracking machinery instead of a bespoke format: creation goes through the
+synapse-note skill's task mode, and status transitions from then on belong entirely to the
+synapse-task skill. This skill's only job is the compile step — turning a design into an ordered
+checklist — not tracking progress itself.
+
+One design compiles into **one** task note, one `task_id`, and the checklist items *are* the
+steps — matching how every other task in the vault already works (see the synapse-task skill's
+"Task file structure").
+
+## When this runs
+
+Invoked whenever the user wants to compile a settled design into a tracked task ("let's compile a
+task note", "let's turn this into a task", "make this a task now") — the design the user means is
+whatever they're currently discussing or naming, not a positional argument to parse.
+
+Once created, the task note's own progress (checked items, `status:` frontmatter) is what the
+synapse-note skill's list mode and the synapse-task skill already track. Use those instead of
+reinventing a parallel view — this skill has no separate list/continue mode of its own.
+
+## Prerequisites
+
+- Requires a matching Obsidian design note (`designs/`) with `Status: Ready`.
+- No matching note → "No Ready design note found for '{topic}'. Start or continue that design note
+  first." Never generate a checklist from scratch.
+- Matching note but `Status: Discussing` → "Design note for '{topic}' is still in Discussing. Finish
+  it first."
+- Matching note but `Status: Reference` → "Design note for '{topic}' concluded as Reference —
+  nothing to compile. Reopen the design discussion and mark it Ready if that's changed."
+- A task note already exists for this design (check the design note's `> Compiled task:` annotation,
+  or `search_query` for a `tasks/` note linking to it) → show its current state (title, `status:`,
+  checked/total) and ask: view it, or recompile (only on explicit confirmation — recompiling rewrites
+  the checklist, so any progress on items that no longer exist is lost).
+
+  **A recompile updates the existing note in place. It never creates a second one and never bumps
+  the `task_id`.** One design has exactly one task note for its whole life; a design that gets
+  revised mid-implementation is the normal case, not a new task. Preserve `task_id`, `created`,
+  `status`, the filename, and any `## Notes` content the human added; replace the checklist and the
+  pre-implementation notes. Carry forward `- [x]` marks for items that survive the recompile
+  unchanged — work already done doesn't become undone because the plan around it grew.
+
+  Record *why* in the note itself, in one line at the top of the body: what the old plan got wrong
+  and what changed. A recompiled task with no explanation reads like a plan that was always this
+  shape, which hides the fact that implementation found a gap.
+
+## Compiling the checklist
+
+1. Read the design note in full.
+2. Break the approach into an ordered list of small, sequential, independently-completable steps.
+3. For each step, write it the way the synapse-task skill's own checklist convention expects: a short
+   `- [ ] {Do}` line; for substantive steps (type definitions, API surfaces, interface signatures)
+   add a one-line nested description plus a fenced code block showing the exact interface, per that
+   skill's "Inline code examples in checklist items". Don't invent separate Files/Tests/AC fields —
+   fold what matters into the item's own description instead (e.g. "...; test: X returns Y").
+4. Note explicit exclusions — things a reasonable implementer might also attempt that are out of
+   scope — for the `## Notes` section below, not a separate heading.
+
+## Creating the note
+
+Follow the synapse-note skill's task-mode procedure exactly (its "Creating the note" section) —
+don't duplicate that scaffolding here, just supply its inputs:
+
+- **Title:** a short, plain description of the compiled plan (e.g. "Rollup direct storage
+  implementation") — the synapse-note skill's task mode resolves the project prefix and `task_id`
+  and prepends them itself.
+- **Project:** derive from the source design note's `project:` frontmatter — that prefix is already
+  resolved (the design note went through the synapse-design-note skill's resolution when it was
+  created, which reads/appends the resolved `synapse-projects.conf`, per the synapse-note skill's
+  tiered lookup), so supply it directly instead of re-deriving or re-asking. This is the *prefix*
+  (`ecs`, `sb`, ...), not the `tasks/{project}/` folder name — the synapse-note skill's task mode's
+  own "Resolving the project folder" step turns it into the folder name. Never hardcode a specific
+  project/prefix pair in this skill's own instructions — the conf file is machine-local and
+  deliberately outside the portable Synapse package, so projects from unrelated contexts (e.g.
+  personal vs. work) must never end up in the same place.
+- **Body:** the checklist from "Compiling the checklist" above, under the single top-level heading —
+  exactly the structure the synapse-task skill's "Task file structure" requires (no `## Step`
+  sub-headings).
+- **`## Notes` (pre-implementation):** populate per the synapse-task skill's own convention —
+  - Design reference: `[[{design note title}]]`
+  - Key constraints the implementor must not miss
+  - Deliberate exclusions (from step 4 above) and why
+
+## 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.
+
+## Confirm
+
+Report the created path and title, and remind the user that `status:` transitions (TODO →
+IN-PROGRESS → REVIEW) happen automatically via the synapse-task skill once work starts — this
+skill doesn't set or watch that field itself.
+
+## Integration
+
+- Reads the synapse-design-note skill's `Ready` output only — never invents a design.
+- Delegates note creation to the synapse-note skill's task mode and status tracking to the
+  synapse-task skill — this skill owns only the design → checklist compile step.
+
+---
+
+## Example
+
+```
+User: let's compile a task note for "rollup direct storage"
+
+Codex: [reads designs/{PROJECT} — Rollup direct storage.md, Status: Ready]
+       [no existing linked task note]
+
+       Compiled checklist:
+       - [ ] Add ReplacingMergeTree target table for the daily rollup
+       - [ ] Point the rollup MV at the new table instead of AggregatingMergeTree
+       - [ ] Migrate existing daily/monthly rollups (drop+recreate, sort-key change)
+       - [ ] Update the 5 retrofitted dashboards' rollup queries to drop argMaxMerge
+
+       Project already known: {PROJECT} → {prefix}-005.
+
+       Created: tasks/{PROJECT}/{prefix}-005 — Rollup direct storage implementation.md
+       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-vault-tidy/SKILL.md

@@ -0,0 +1,187 @@
+---
+name: synapse-vault-tidy
+description: Run one on-demand vault-tidy pass over Synapse Vault -- surface recategorization candidates (notes that no longer fit their folder, clusters that deserve a new top-level category, categories that have gone stale) into a single inbox/ proposal, silently fill in the one class of missing-frontmatter default that has an unambiguous fix, and fold the rest of note health (broken links, orphaned notes, duplicate titles) into that same proposal since none of them has a safe mechanical repair either. Use whenever the user wants the vault's own organization checked or tidied ("tidy the vault", "check vault health", "any notes drifted out of their folder", "find orphaned/duplicate notes"). Never invoked automatically -- no session-start wiring, no autonomous scheduling; run it only when asked, or on a recurring cadence the user sets up themselves. Scoped to everything except designs/, tasks/, and synapse/ (the code graph's own generated namespace), which stay entirely the synapse-status skill's (the first two) or the synapse-init skill's (the third) territory.
+---
+
+# Synapse Vault Tidy: Recategorization Proposals and Note-Health Fixes
+
+A single on-demand pass over Synapse Vault's free-form taxonomy (`inbox/`/`research/`/`scratchpad/`/
+whatever a given install's index note currently lists) that a person would otherwise have to notice
+and fix by hand: a note's folder fit drifting since it was filed, several notes sharing enough in
+common to deserve a category of their own, a category that stopped earning its keep, a link that
+broke when its target moved, a note nothing points to or from, two notes that are really the same
+thing under slightly different titles. Nothing here runs unprompted — it exists because nothing else
+in the vault periodically re-checks any of this, not because it's meant to run behind the user's
+back.
+
+Never touches `designs/`, `tasks/`, or `synapse/` — the first two are the design-note and
+task-note-creation skills' own interface for directing project work (any gap found there is the
+synapse-status skill's territory, not this skill's); `synapse/` is the code graph's own generated
+namespace, a different note kind entirely, owned and kept fresh by the synapse-init skill and the
+synapse-node/synapse-node-format skills. The vault's index note and any vault-root `README.md` are
+also out of scope — foundational files, not taxonomy notes.
+
+## When this runs
+
+Invoked whenever the user wants the vault's own organization checked or tidied ("tidy the vault",
+"check vault health", "any notes drifted out of their folder", "find orphaned/duplicate notes") --
+there is no argument to parse, every run produces the same one-pass sweep.
+
+## Prerequisites
+
+Requires the `obsidian` MCP server (`mcp__obsidian__*` tools). If unreachable, say so and stop —
+there is no local-file fallback.
+
+No compiled code anywhere in this skill. `adapters/obsidian/store.zig`'s `ObsidianStore` does now
+implement `read`/`list`/`search`, but for `synapse frontmatter get`/`set`'s narrow one-field-at-a-time
+use — a full-vault tidy sweep, reading every note's whole body to judge category, tags and broken
+links, is a different shape of work entirely, and stays on these same MCP tools rather than the
+compiled binary, the same way the synapse-status and synapse-rebuild-diff skills' vault-side checks
+already work. The one exception is Step 3's broken-link history check, a plain `git log` call (via
+the shell, not a compiled tool) against the vault's own local repo when one exists — best-effort,
+never a hard requirement.
+
+## Step 1: Inventory sweep
+
+Enumerate every note in scope and read each one exactly once — every later step reuses this same
+sweep rather than re-reading anything.
+
+```
+{"and": [
+  {"!": [{"glob": ["designs/*", {"var": "path"}]}]},
+  {"!": [{"glob": ["tasks/*", {"var": "path"}]}]},
+  {"!": [{"glob": ["synapse/*", {"var": "path"}]}]},
+  {"!=": [{"var": "path"}, "Index.md"]},
+  {"!=": [{"var": "path"}, "README.md"]}
+]}
+```
+
+`mcp__obsidian__search_query` with that filter, then `mcp__obsidian__vault_read` each match. Keep
+the full result (`path`, `frontmatter`, `tags`, `links`, `backlinks`, `unresolvedLinks`, `stat`,
+`content`) per note — Steps 2–4 below only ever reason over the structured fields, never `content`
+itself; the judgment layer in Step 5 is the first point anything actually reads note *bodies*, and
+only for the subset flagged by then. `content` is fetched for free in this same call regardless, so
+there's no separate "light" read to bother with.
+
+## Step 2: Frontmatter defaults (fixed directly)
+
+The only note-health fix applied silently, because it's the only one with exactly one correct
+answer per note. Design and task notes are out of scope entirely; the plain/free-form schema is
+just two fields (`title`, `created` — see the synapse-note skill's bare-mode format), both
+derivable without guessing:
+
+- Missing `title` → the filename with its `.md` extension stripped.
+- Missing `created` → `stat.ctime`, formatted `YYYY-MM-DD HH:MM` to match every other note's
+  convention.
+
+Apply via read-modify-write on the whole file (`vault_read` → edit the one frontmatter line in the
+returned content → `vault_write` the whole file back) — never `vault_patch` with
+`targetType: frontmatter`, which re-serializes the entire YAML block and silently reformats
+unrelated fields, the same hazard the vault and task-status skills already document.
+
+## Step 3: Note-health findings (reported, not fixed)
+
+From the same inventory, no additional vault reads (the broken-link history check below reads the
+vault's local git log, not more notes). Each of these three has no safe mechanical repair —
+fixing any of them means guessing at intent — so they become findings for the Step 6 proposal
+instead of a silent edit:
+
+- **Broken links** — `unresolvedLinks` non-empty. 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 (`OBSIDIAN_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"*.
+  - No hit → `git -C {vault} log --all -p -S"[[{target}]]" -- .` and look at the earliest match's
+    diff: if the line first appears inside a `new file mode` addition (the note was created with the
+    link already broken), report it as *"born broken — never pointed at a real note; probably meant
+    as plain text or an external reference, not a vault link"* rather than implying anything was
+    lost.
+  - Neither check resolves anything more specific → report the target plainly, same as before.
+- **Orphaned notes** — `links` empty *and* `backlinks` empty.
+- **Duplicate/near-duplicate titles** — group notes by title normalized (lowercased, trimmed,
+  internal whitespace collapsed); any group with 2+ members is a finding. This is a mechanical
+  string-normalization match, not fuzzy similarity — genuinely fuzzy "these might be the same
+  note" calls belong to the judgment layer in Step 5, not here.
+
+## Step 4: Recategorization signal layer
+
+Mechanical, from the same inventory, still no note-body reasoning:
+
+- **Weak folder fit** — a note (not already an orphan from Step 3) that shares no tag with any
+  other note in its own folder, and where fewer than half of its combined `links`+`backlinks` point
+  to notes within that same folder.
+- **Uncovered clusters** — a tag or keyword held by 3+ notes spanning 2+ different folders, where no
+  existing top-level folder name (from the index note's current list) already matches it.
+- **Stale categories** — a scope-eligible top-level folder whose newest note's `stat.mtime` is more
+  than 90 days old (no new note gained in that window) is flagged as a merge-back candidate, the
+  same way a newly proposed split is flagged — one signal, checked at a different point in a
+  category's life.
+
+## Step 5: Recategorization judgment layer
+
+For each Step 4 candidate — a weak-fit note, a cluster, or a stale folder — read its full content
+(and, for a cluster, every member's content) and decide with real judgment, not the mechanical
+signal alone:
+
+- Weak-fit note: does it genuinely belong in a different existing category, or was the signal a
+  false positive (a note that's fine where it is, just thin on tags/links)?
+- Cluster: given what these notes actually say, is this a real emerging category, or just a
+  coincidental shared keyword?
+- Stale folder: has it truly stopped being useful, or is low volume expected and fine (a narrow but
+  still-active category)?
+
+Never moves a note or creates a folder here — every conclusion becomes one line in the Step 6
+proposal, for the vault owner to act on.
+
+## Step 6: Compose the proposal
+
+One note, `inbox/Vault tidy — {YYYY-MM-DD}.md` (fetch machine local time, never infer it), written
+via `vault_write` (creates `inbox/` automatically if it doesn't exist yet; if `inbox/` isn't already
+in the index note's folder list, add it there in the same pass, matching the folder-layout rule every
+other skill that can create a top-level folder already follows). Two sections:
+
+```
+## Recategorization
+- {note or cluster}: {proposed move/new category/merge}, because {reasoning}
+
+## Note health
+- Broken link in {note}: → {target text that doesn't resolve} ({history classification, if the
+  vault's local git repo yielded one — "used to be a note", "born broken", or omitted entirely if
+  neither check resolved anything})
+- Orphaned: {note}
+- Possible duplicate: {note A} / {note B}
+```
+
+Omit either section if Steps 3–5 found nothing for it. If both are empty, don't write a proposal at
+all — say so directly instead of creating an empty note.
+
+This skill never edits the index note itself beyond the `inbox/` bootstrap case above — creating or
+renaming a category is the vault owner's call, made by hand using the vault's own already-shipped
+folder-taxonomy-customization mechanism, not something this skill does on its own.
+
+## Step 7: Report
+
+Print a short summary directly in the response, not left only in tool-call output:
+
+- Count of frontmatter defaults silently filled, with filenames.
+- Count of recategorization candidates and note-health findings written to the proposal, with a
+  link to `inbox/Vault tidy — {date}.md`.
+- If nothing was found anywhere: "Vault's in good shape — nothing to fix or propose."
+
+## Constraints
+
+- Never touches — moves, edits, or reorganizes — anything inside `designs/`, `tasks/`, or
+  `synapse/`. The index note and a vault-root `README.md` are also out of scope.
+- Recategorization never auto-moves a note or auto-creates a folder — proposal only, to `inbox/`.
+- Only the frontmatter-default class of note-health fix (Step 2) is applied directly and silently.
+  Broken links, orphaned notes, and duplicate titles are proposal findings, never auto-repaired.
+- Invoked on demand only — no session-start wiring, no autonomous scheduling. Run it only when
+  asked, or on a recurring cadence the user sets up themselves.
+- No compiled code — every step above is a plain `mcp__obsidian__*` call, or (Step 3's broken-link
+  history check only) a plain `git log` via the shell against the vault's own local repo; this skill
+  itself never calls into `ObsidianStore`.

package/harness/opencode/plugin/synapse.js

@@ -0,0 +1,164 @@
+// Synapse for OpenCode: shells out to the same `synapse-hook` binary Claude
+// Code's hooks.json already calls, translating OpenCode's plugin callbacks
+// into the same stdin JSON payload / stdout `hookSpecificOutput` shape the
+// binary already reads and writes. No engine change -- see
+// `src/apps/hook/main.zig`'s own doc comment for that contract.
+//
+// Session lifecycle isn't a named `Hooks` key in OpenCode's plugin API --
+// confirmed against the real `@opencode-ai/plugin`/`@opencode-ai/sdk` type
+// packages, not assumed from prose docs. `session.created` is delivered
+// only through the generic catch-all `event` hook as an `Event` union
+// member (`event.type === "session.created"`), so this plugin instead
+// piggybacks the equivalent one-per-session injection on `chat.message`,
+// gated on whether this session has already received it -- checked against
+// real session history (`client.session.messages`), not just in-memory
+// state, since each `opencode run` CLI invocation is its own short-lived
+// process and an in-memory Set alone re-injects on every `--continue` call.
+//
+// `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 reads no payload at all (a blind `git add -A && commit` against the
+// vault's own repo), so it only needs a trigger, not a translated payload --
+// fired on the same write/edit tools, plus the two vault-mutating MCP tools
+// (`obsidian_vault_write`/`obsidian_vault_patch`, the same OpenCode
+// tool-naming transform `mcp__obsidian__vault_write`/`vault_patch` go
+// through elsewhere in this plugin's own skill/command prose).
+//
+// `stop-nudge`'s Claude Code trigger (`Stop`, once per turn) maps to
+// `session.idle` -- live-verified as firing exactly once, after every tool
+// call and the final response for a turn. Its own `additionalContext` (the
+// periodic "worth capturing" nudge) has nowhere to land at that moment --
+// `session.idle` is a pure notification, no message `output` to push a part
+// onto the way `chat.message` has -- so it's queued and delivered as a
+// synthetic part on the *next* `chat.message` instead of dropped.
+//
+// `synapse-hook`'s own binary path isn't resolved here the usual way --
+// OpenCode plugins get no `${CLAUDE_PLUGIN_ROOT}`-equivalent "where am I
+// installed" value, unlike Claude Code/Codex. Resolves via `SYNAPSE_HOOK_BIN`
+// if set (an override, not a requirement), else the fixed shared install
+// location every harness's setup fetches into (`~/.cache/synapse/bin/
+// synapse-hook`, `XDG_CACHE_HOME`-aware) -- a real, predictable path now that
+// the binary is shared and unsuffixed across harnesses, not a bare name that
+// needed PATH resolution.
+
+import { spawnSync } from "child_process"
+import { homedir } from "os"
+import { join } from "path"
+
+function defaultHookBin() {
+  const cacheHome = process.env.XDG_CACHE_HOME || join(homedir(), ".cache")
+  return join(cacheHome, "synapse", "bin", "synapse-hook")
+}
+
+const HOOK_BIN = process.env.SYNAPSE_HOOK_BIN || defaultHookBin()
+const SESSION_START_MARKER = "[SYNAPSE-SESSION-START]"
+
+function runHook(subcommand, payload) {
+  const res = spawnSync(HOOK_BIN, [subcommand], {
+    input: JSON.stringify(payload),
+    encoding: "utf8",
+  })
+  if (res.status !== 0 || !res.stdout) return null
+  try {
+    const parsed = JSON.parse(res.stdout)
+    return parsed?.hookSpecificOutput?.additionalContext ?? null
+  } catch {
+    return null
+  }
+}
+
+function partID() {
+  return "prt_" + Math.random().toString(36).slice(2) + Date.now().toString(36)
+}
+
+function textPart(sessionID, output, text) {
+  return {
+    id: partID(),
+    sessionID,
+    messageID: output.message.id,
+    type: "text",
+    text,
+    synthetic: true,
+  }
+}
+
+const injected = new Set()
+
+// In-memory `injected` is a fast path only, good within one long-lived
+// process (the interactive TUI). Each `opencode run` invocation is its own
+// process, so `--continue`/`--session` against an existing session starts
+// with an empty Set -- checking real session history is what makes this
+// correct across separate CLI invocations, not just within one, confirmed
+// live: without this check, a second `opencode run --continue` call
+// re-injected the full vault index every time.
+async function alreadyInjected(client, sessionID) {
+  if (injected.has(sessionID)) return true
+  try {
+    const res = await client.session.messages({ path: { id: sessionID } })
+    const history = res?.data ?? []
+    const found = history.some((m) => m.parts.some((p) => p.type === "text" && p.text.startsWith(SESSION_START_MARKER)))
+    if (found) injected.add(sessionID)
+    return found
+  } catch {
+    return false
+  }
+}
+
+const EDIT_TOOLS = new Set(["write", "edit"])
+const VAULT_WRITE_TOOLS = new Set(["obsidian_vault_write", "obsidian_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()
+
+export const Synapse = async ({ directory, client }) => {
+  return {
+    "chat.message": async (input, output) => {
+      const sessionID = input.sessionID
+      const newParts = []
+
+      if (!(await alreadyInjected(client, sessionID))) {
+        injected.add(sessionID)
+        const ctx = runHook("session-start", { cwd: directory })
+        if (ctx) newParts.push(textPart(sessionID, output, `${SESSION_START_MARKER}\n${ctx}`))
+      }
+
+      const queuedNudge = pendingNudge.get(sessionID)
+      if (queuedNudge) {
+        pendingNudge.delete(sessionID)
+        newParts.push(textPart(sessionID, output, `[SYNAPSE-STOP-NUDGE]\n${queuedNudge}`))
+      }
+
+      const promptText = (output.parts || [])
+        .filter((p) => p.type === "text")
+        .map((p) => p.text)
+        .join("\n")
+      const nudge = runHook("prompt-context", { cwd: directory, prompt: promptText || "x" })
+      if (nudge) newParts.push(textPart(sessionID, output, `[SYNAPSE-PROMPT-CONTEXT]\n${nudge}`))
+
+      if (newParts.length) output.parts.push(...newParts)
+    },
+
+    "tool.execute.after": async (input) => {
+      const filePath = input.args?.filePath
+      if (EDIT_TOOLS.has(input.tool) && filePath) {
+        runHook("staleness", {
+          session_id: input.sessionID,
+          tool_input: { file_path: filePath },
+        })
+        runHook("db-sync", {});
+      } else if (VAULT_WRITE_TOOLS.has(input.tool)) {
+        runHook("db-sync", {});
+      }
+    },
+
+    event: async ({ event }) => {
+      if (event.type !== "session.idle") return
+      const sessionID = event.properties.sessionID
+      const text = runHook("stop-nudge", { session_id: sessionID })
+      if (text) pendingNudge.set(sessionID, text)
+    },
+  }
+}