@memnexus-ai/typescript-sdk 1.59.17 → 1.59.19

package/dist/index.d.cts

@@ -10573,6 +10573,13 @@ declare class MemoriesService extends BaseService {
      * Retrieve the current HEAD version of a named memory by its user-assigned name.
   Supports the same detail levels as GET /api/memories/{id}.
   
+  404 semantics: a 404 does NOT always mean the name was never created. It
+  is also returned when the name's current head was superseded, contradicted,
+  or duplicated and left with no successor version carrying the name (an
+  integrity condition — an orphaned head). Only current (or legacy
+  unstamped) heads are served; a superseded head is never returned as stale
+  content. Callers must not assume 404 == never-existed.
+  
      * @param name - Memory name (kebab-case, 2-64 chars)
      * @param detail - Detail level: minimal (raw memory), standard (default, + topics/entities/facts/relationships), full (+ conversation context and relationship previews)
      */
@@ -10618,9 +10625,12 @@ declare class MemoriesService extends BaseService {
      * Atomically append a block to a named memory
      * Atomically appends a text block to a named memory, eliminating the
   read-modify-write clobber that concurrent full-content updates cause on
-  shared named memories. The server reads the current head, concatenates
-  `existing + separator + block`, and writes a new version under the
-  NameLock with an internal compare-and-swap + bounded retry — so
+  shared named memories. Each append runs inside a single transaction that
+  holds the per-name NameLock end to end: it acquires the lock, reads the
+  current head UNDER the lock, concatenates `existing + separator + block`,
+  and writes the new version — all before releasing the lock. Concurrent
+  appends therefore QUEUE on the lock and serialize (the same mechanism the
+  full-content PUT path uses); there is no compare-and-swap retry loop, so
   simultaneous appends all survive and the client needs no retry logic.
   Content is decrypted, assembled, size-checked, and re-encrypted
   server-side; plaintext is never returned to other callers.

package/dist/index.d.ts

@@ -10573,6 +10573,13 @@ declare class MemoriesService extends BaseService {
      * Retrieve the current HEAD version of a named memory by its user-assigned name.
   Supports the same detail levels as GET /api/memories/{id}.
   
+  404 semantics: a 404 does NOT always mean the name was never created. It
+  is also returned when the name's current head was superseded, contradicted,
+  or duplicated and left with no successor version carrying the name (an
+  integrity condition — an orphaned head). Only current (or legacy
+  unstamped) heads are served; a superseded head is never returned as stale
+  content. Callers must not assume 404 == never-existed.
+  
      * @param name - Memory name (kebab-case, 2-64 chars)
      * @param detail - Detail level: minimal (raw memory), standard (default, + topics/entities/facts/relationships), full (+ conversation context and relationship previews)
      */
@@ -10618,9 +10625,12 @@ declare class MemoriesService extends BaseService {
      * Atomically append a block to a named memory
      * Atomically appends a text block to a named memory, eliminating the
   read-modify-write clobber that concurrent full-content updates cause on
-  shared named memories. The server reads the current head, concatenates
-  `existing + separator + block`, and writes a new version under the
-  NameLock with an internal compare-and-swap + bounded retry — so
+  shared named memories. Each append runs inside a single transaction that
+  holds the per-name NameLock end to end: it acquires the lock, reads the
+  current head UNDER the lock, concatenates `existing + separator + block`,
+  and writes the new version — all before releasing the lock. Concurrent
+  appends therefore QUEUE on the lock and serialize (the same mechanism the
+  full-content PUT path uses); there is no compare-and-swap retry loop, so
   simultaneous appends all survive and the client needs no retry logic.
   Content is decrypted, assembled, size-checked, and re-encrypted
   server-side; plaintext is never returned to other callers.

package/dist/index.js

@@ -3266,6 +3266,13 @@ var MemoriesService = class extends BaseService {
      * Retrieve the current HEAD version of a named memory by its user-assigned name.
   Supports the same detail levels as GET /api/memories/{id}.
   
+  404 semantics: a 404 does NOT always mean the name was never created. It
+  is also returned when the name's current head was superseded, contradicted,
+  or duplicated and left with no successor version carrying the name (an
+  integrity condition — an orphaned head). Only current (or legacy
+  unstamped) heads are served; a superseded head is never returned as stale
+  content. Callers must not assume 404 == never-existed.
+  
      * @param name - Memory name (kebab-case, 2-64 chars)
      * @param detail - Detail level: minimal (raw memory), standard (default, + topics/entities/facts/relationships), full (+ conversation context and relationship previews)
      */
@@ -3349,9 +3356,12 @@ var MemoriesService = class extends BaseService {
      * Atomically append a block to a named memory
      * Atomically appends a text block to a named memory, eliminating the
   read-modify-write clobber that concurrent full-content updates cause on
-  shared named memories. The server reads the current head, concatenates
-  `existing + separator + block`, and writes a new version under the
-  NameLock with an internal compare-and-swap + bounded retry — so
+  shared named memories. Each append runs inside a single transaction that
+  holds the per-name NameLock end to end: it acquires the lock, reads the
+  current head UNDER the lock, concatenates `existing + separator + block`,
+  and writes the new version — all before releasing the lock. Concurrent
+  appends therefore QUEUE on the lock and serialize (the same mechanism the
+  full-content PUT path uses); there is no compare-and-swap retry loop, so
   simultaneous appends all survive and the client needs no retry logic.
   Content is decrypted, assembled, size-checked, and re-encrypted
   server-side; plaintext is never returned to other callers.