The vault. Must allow writes (i.e. the server was started
with --enable-writes).
note_path, role, content are required. thread_title
is used only when creating a brand-new note from scratch.
The note's vault-relative path plus the 1-based line range of the appended message (for jumping the UI to it).
Append a message to a note's chat thread — note-tethered AI conversations persisted as markdown.
Creates the note (and the
## Chat: <title>parent heading) if absent. Messages are stored as third-level headings with role + ISO timestamp (### user · 2026-05-08T10:00Z). The format is human-readable, version- controllable via git, and feeds back into the vault's retrieval index — agents can search past threads by content like any other note.Appending always creates a fresh
### <role> · <timestamp>block, never mutates existing messages.CONCURRENCY CONTRACT (v3.10.0-rc.58, audit CONC-1): this is a read-modify-WRITE (read the note → append in memory →
writeNote(overwrite)), NOT an atomic O_APPEND likeVault.appendNote. Two appends to the SAMEnote_paththat overlap (e.g. a client firing two without awaiting, or concurrent serve-http requests) are a lost-update window: both read body B, and the second write (B + msg2) overwrites the first (B + msg1), dropping msg1. Callers MUST serialize appends to a given thread note (await each before the next). This is an accepted design characteristic — the heading-injection / new-note branches genuinely need a full write, so routing through atomic append is deferred.