@anuma/sdk 4.0.0 → 4.0.2

package/dist/server/{chunk-WZE6ZVKE.mjs → chunk-WADHFDMA.mjs}

@@ -16942,6 +16942,30 @@ async function updateVaultMemoryOp(ctx, id, opts) {
     return null;
   }
 }
+async function clearMemoryTopicsOverrideOp(ctx, memoryId, options) {
+  let record;
+  try {
+    record = await ctx.vaultMemoryCollection.find(memoryId);
+  } catch {
+    return false;
+  }
+  if (record.isDeleted || !isOwnedByCtxUser(ctx, record)) return false;
+  const originalUpdatedAt = record.updatedAt.getTime();
+  let cleared = false;
+  await ctx.database.write(async () => {
+    if (options?.unlessTopicsRecorded && parseTopics(record.topics) !== null) return;
+    cleared = true;
+    await record.update((r) => {
+      r._setRaw("topics_user_managed", false);
+      r._setRaw("topics_extracted_version", null);
+      if (record.topicsExtractedAt === null) {
+        r._setRaw("topics_extracted_at", originalUpdatedAt);
+      }
+      r._setRaw("updated_at", originalUpdatedAt);
+    });
+  });
+  return cleared;
+}
 async function setMemoryVisibilityOp(ctx, id, opts) {
   let record;
   try {
@@ -17103,11 +17127,13 @@ async function getMemoriesNeedingTopicExtractionOp(ctx, options) {
     entityCtx,
     rows.map((r) => r.id)
   );
+  const cap = options?.limit !== void 0 && options.limit > 0 ? options.limit : void 0;
   const pendingRaw = [];
   const stampedPendingRaw = [];
   const linkedUnstampedAll = [];
   const topicsToRelinkAll = [];
   const topicsBackfillAll = [];
+  const emptyCurationToClear = [];
   for (const raw of rows) {
     const id = raw.id;
     const topics = parseTopics(raw.topics);
@@ -17117,8 +17143,12 @@ async function getMemoriesNeedingTopicExtractionOp(ctx, options) {
       continue;
     }
     if (raw.topics_user_managed) {
-      if (topics === null && linked !== void 0) topicsBackfillAll.push(id);
-      continue;
+      if (topics !== null || linked !== void 0) {
+        if (topics === null) topicsBackfillAll.push(id);
+        continue;
+      }
+      if (cap !== void 0 && emptyCurationToClear.length >= cap) continue;
+      emptyCurationToClear.push(id);
     }
     const stamp = raw.topics_extracted_at ?? null;
     let isPending = false;
@@ -17134,11 +17164,21 @@ async function getMemoriesNeedingTopicExtractionOp(ctx, options) {
       pendingRaw.push(raw);
       isPending = true;
     }
+    if (!isPending && linked === void 0 && topics === null) {
+      pendingRaw.push(raw);
+      isPending = true;
+    }
     if (!isPending && topics === null && linked !== void 0) {
       topicsBackfillAll.push(id);
     }
   }
-  const cap = options?.limit !== void 0 && options.limit > 0 ? options.limit : void 0;
+  for (const id of emptyCurationToClear) {
+    try {
+      await clearMemoryTopicsOverrideOp(ctx, id, { unlessTopicsRecorded: true });
+    } catch (err) {
+      getLogger().warn("[memory/topics] repair clear failed", err);
+    }
+  }
   const orderedPendingRaw = [...stampedPendingRaw, ...pendingRaw];
   const limitedPendingRaw = cap !== void 0 ? orderedPendingRaw.slice(0, cap) : orderedPendingRaw;
   const pending = await mapInBatches(
@@ -20310,7 +20350,7 @@ function createMemoryVaultSearchTool(vaultCtx, embeddingOptions, cache, searchOp
             legacy.map((r) => ({ id: r.uniqueId, content: r.content, score: r.similarity }))
           );
         }
-        const { recall: recall2 } = await import("./recall-YZWIV6IH.mjs");
+        const { recall: recall2 } = await import("./recall-QTVT7HCZ.mjs");
         let recallDegraded = [];
         const result = await recall2(
           query,

package/dist/server/{consolidate-4VEAS3YN.mjs → consolidate-GRMEDWKK.mjs}

@@ -18,19 +18,21 @@ A "memory" is a self-contained natural-language fact about the user. Multiple me
 Decide one of four actions:
 
 - "create": the new memory describes a distinct fact not covered by any existing memory. Write it as new.
-- "update": the new memory describes the SAME FACET as exactly one existing memory and is COMPATIBLE with it \u2014 it adds detail, fixes an incomplete value, or rephrases the same still-true fact. Return targetId of that existing memory + the consolidated content (richest version of the two).
-- "supersede": the new memory REPLACES a standing fact whose value has CHANGED and is now INCOMPATIBLE with an existing memory \u2014 the old fact was true before but is false now (a state change). Return "targetIds": an array of the ids of EVERY existing candidate that describes the SAME standing attribute now being changed \u2014 retire ALL stale duplicates of the old value, not just one (the candidate list may contain several paraphrases of the same old fact) + content = the NEW fact. The old memories are kept as history, not overwritten or deleted; do not re-state them.
-- "noop": the new memory is already fully captured by an existing memory \u2014 same facet, no new information. Skip the write.
+- "update": the new memory describes the SAME FACET of the SAME SUBJECT as exactly one existing memory, is COMPATIBLE with it, and ADDS INFORMATION \u2014 it adds detail or fills in an incomplete value. Return targetId of that existing memory + the consolidated content (richest version of the two). A pure rewording that adds nothing is NOT an update; it is "noop".
+- "supersede": the new memory REPLACES a standing fact whose value has CHANGED and is now INCOMPATIBLE with an existing memory ABOUT THE SAME SUBJECT \u2014 the old fact was true before but is false now (a state change). Before choosing this, name the subject of the new memory and the subject of each candidate out loud to yourself; if they are different people, the old fact is still TRUE and superseding it would delete a correct memory \u2014 choose "create" instead. Return "targetIds": an array of the ids of EVERY existing candidate that describes the SAME standing attribute now being changed \u2014 retire ALL stale duplicates of the old value, not just one (the candidate list may contain several paraphrases of the same old fact) + content = the NEW fact. The old memories are kept as history, not overwritten or deleted; do not re-state them.
+- "noop": the new memory is already fully captured by an existing memory \u2014 same facet of the same subject, no new information. This INCLUDES a restatement in different words ("has two kids" / "has two children"): if the existing memory already tells you everything the new one does, the answer is noop no matter how differently it is worded. Skip the write.
 
 RULES (carry these strictly):
 
 1. ONE OBSERVATION PER DISTINCT FACET. If the new memory is about "user's aunt's twins" and an existing memory is also about "user's aunt's twins", they are the same facet \u2192 update, never create.
+1a. SAME SUBJECT REQUIRED \u2014 check this FIRST, before you look at the facet. The subject is WHO the fact is about: the user, or a specific person or thing in their life (a relative, their manager, their dog Biscuit). "update", "supersede" and "noop" all require the new memory and the existing one to be about the SAME subject. Two memories can share a facet and still have different subjects, and then they are simply two different facts: "User's daughter is allergic to peanuts" and "User is allergic to peanuts" are both about a peanut allergy, but one is about the DAUGHTER and one is about the USER \u2192 create, keep both. This holds for EVERY attribute, not just the one in this example \u2014 where someone lives, who they work for, what they own, how old they are. A possessive like "user's X" makes X the subject, not the user; strip it and ask "whose fact is this?" before comparing anything. Never retire the user's own value because a fact about somebody else resembles it \u2014 the user's fact is still true, and retiring it destroys it.
 2. MATCH BY FACET, NOT TOPIC. Two memories both mentioning "Zara" is not enough to merge \u2014 only merge if they describe the same property (e.g. both about "user's pending Zara boot exchange"). Two memories about Zara on different topics (e.g. "user shops at Zara" + "user returned a sweater to Zara last week") are separate facets.
 3. NO COMPUTATION. Do not sum counts, decrement quantities, or derive new facts from existing ones. If the new memory says "user spent $200 today" and an existing memory says "user spent $150 yesterday", these are TWO SEPARATE EVENTS \u2014 create.
 4. EVENTS vs STANDING STATE.
    - Distinct EVENTS (episodic \u2014 something that happened on a date) are separate memories, even if the same activity: "user went to gym Monday" vs "user went to gym Friday" \u2192 create; keep both.
-   - A STANDING ATTRIBUTE (an ongoing state: where the user lives/works, relationship status, current role) has ONE current value. When the new memory changes that value ("Lives in Portland" \u2192 "Lives in San Francisco"; "Works at Google" \u2192 "Works at Riverbend"; "Engaged" \u2192 "Broke up"), the old value is no longer true \u2192 supersede (retire the old, record the new). Do NOT create (that leaves a stale contradiction) and do NOT update (that erases the history that the old value was once true).
-5. When in doubt between create and update, choose create \u2014 EXCEPT when the new memory directly contradicts the current value of a standing attribute in an existing memory; then choose supersede. Over-merging loses information; a live contradiction is worse than either.
+   - A STANDING ATTRIBUTE (an ongoing state: where someone lives/works, relationship status, current role) has ONE current value PER SUBJECT. When the new memory changes that value FOR THE SAME SUBJECT ("Lives in Portland" \u2192 "Lives in San Francisco"; "Works at Google" \u2192 "Works at Riverbend"; "Engaged" \u2192 "Broke up"), the old value is no longer true \u2192 supersede (retire the old, record the new). Do NOT create (that leaves a stale contradiction) and do NOT update (that erases the history that the old value was once true). A different subject holding the same attribute is not a value change at all \u2192 create.
+5. When in doubt between create and update, choose create \u2014 EXCEPT when the new memory directly contradicts the current value of a standing attribute in an existing memory ABOUT THE SAME SUBJECT; then choose supersede. Two facts about different subjects never contradict each other, however similarly they read. Over-merging loses information; a live contradiction is worse than either.
+6. When in doubt between update and noop, ask whether the existing memory ALONE already answers everything the new one would. If it does, choose noop \u2014 a write that changes only the wording costs a re-embed and makes an old fact look newly observed.
 
 OUTPUT \u2014 strict JSON, no prose:
 {

package/dist/server/index.cjs

@@ -17747,6 +17747,30 @@ async function updateVaultMemoryOp(ctx, id, opts) {
     return null;
   }
 }
+async function clearMemoryTopicsOverrideOp(ctx, memoryId, options) {
+  let record;
+  try {
+    record = await ctx.vaultMemoryCollection.find(memoryId);
+  } catch {
+    return false;
+  }
+  if (record.isDeleted || !isOwnedByCtxUser(ctx, record)) return false;
+  const originalUpdatedAt = record.updatedAt.getTime();
+  let cleared = false;
+  await ctx.database.write(async () => {
+    if (options?.unlessTopicsRecorded && parseTopics(record.topics) !== null) return;
+    cleared = true;
+    await record.update((r) => {
+      r._setRaw("topics_user_managed", false);
+      r._setRaw("topics_extracted_version", null);
+      if (record.topicsExtractedAt === null) {
+        r._setRaw("topics_extracted_at", originalUpdatedAt);
+      }
+      r._setRaw("updated_at", originalUpdatedAt);
+    });
+  });
+  return cleared;
+}
 async function setMemoryVisibilityOp(ctx, id, opts) {
   let record;
   try {
@@ -17907,11 +17931,13 @@ async function getMemoriesNeedingTopicExtractionOp(ctx, options) {
     entityCtx,
     rows.map((r) => r.id)
   );
+  const cap = options?.limit !== void 0 && options.limit > 0 ? options.limit : void 0;
   const pendingRaw = [];
   const stampedPendingRaw = [];
   const linkedUnstampedAll = [];
   const topicsToRelinkAll = [];
   const topicsBackfillAll = [];
+  const emptyCurationToClear = [];
   for (const raw of rows) {
     const id = raw.id;
     const topics = parseTopics(raw.topics);
@@ -17921,8 +17947,12 @@ async function getMemoriesNeedingTopicExtractionOp(ctx, options) {
       continue;
     }
     if (raw.topics_user_managed) {
-      if (topics === null && linked !== void 0) topicsBackfillAll.push(id);
-      continue;
+      if (topics !== null || linked !== void 0) {
+        if (topics === null) topicsBackfillAll.push(id);
+        continue;
+      }
+      if (cap !== void 0 && emptyCurationToClear.length >= cap) continue;
+      emptyCurationToClear.push(id);
     }
     const stamp = raw.topics_extracted_at ?? null;
     let isPending = false;
@@ -17938,11 +17968,21 @@ async function getMemoriesNeedingTopicExtractionOp(ctx, options) {
       pendingRaw.push(raw);
       isPending = true;
     }
+    if (!isPending && linked === void 0 && topics === null) {
+      pendingRaw.push(raw);
+      isPending = true;
+    }
     if (!isPending && topics === null && linked !== void 0) {
       topicsBackfillAll.push(id);
     }
   }
-  const cap = options?.limit !== void 0 && options.limit > 0 ? options.limit : void 0;
+  for (const id of emptyCurationToClear) {
+    try {
+      await clearMemoryTopicsOverrideOp(ctx, id, { unlessTopicsRecorded: true });
+    } catch (err) {
+      getLogger().warn("[memory/topics] repair clear failed", err);
+    }
+  }
   const orderedPendingRaw = [...stampedPendingRaw, ...pendingRaw];
   const limitedPendingRaw = cap !== void 0 ? orderedPendingRaw.slice(0, cap) : orderedPendingRaw;
   const pending = await mapInBatches(
@@ -23361,19 +23401,21 @@ A "memory" is a self-contained natural-language fact about the user. Multiple me
 Decide one of four actions:
 
 - "create": the new memory describes a distinct fact not covered by any existing memory. Write it as new.
-- "update": the new memory describes the SAME FACET as exactly one existing memory and is COMPATIBLE with it \u2014 it adds detail, fixes an incomplete value, or rephrases the same still-true fact. Return targetId of that existing memory + the consolidated content (richest version of the two).
-- "supersede": the new memory REPLACES a standing fact whose value has CHANGED and is now INCOMPATIBLE with an existing memory \u2014 the old fact was true before but is false now (a state change). Return "targetIds": an array of the ids of EVERY existing candidate that describes the SAME standing attribute now being changed \u2014 retire ALL stale duplicates of the old value, not just one (the candidate list may contain several paraphrases of the same old fact) + content = the NEW fact. The old memories are kept as history, not overwritten or deleted; do not re-state them.
-- "noop": the new memory is already fully captured by an existing memory \u2014 same facet, no new information. Skip the write.
+- "update": the new memory describes the SAME FACET of the SAME SUBJECT as exactly one existing memory, is COMPATIBLE with it, and ADDS INFORMATION \u2014 it adds detail or fills in an incomplete value. Return targetId of that existing memory + the consolidated content (richest version of the two). A pure rewording that adds nothing is NOT an update; it is "noop".
+- "supersede": the new memory REPLACES a standing fact whose value has CHANGED and is now INCOMPATIBLE with an existing memory ABOUT THE SAME SUBJECT \u2014 the old fact was true before but is false now (a state change). Before choosing this, name the subject of the new memory and the subject of each candidate out loud to yourself; if they are different people, the old fact is still TRUE and superseding it would delete a correct memory \u2014 choose "create" instead. Return "targetIds": an array of the ids of EVERY existing candidate that describes the SAME standing attribute now being changed \u2014 retire ALL stale duplicates of the old value, not just one (the candidate list may contain several paraphrases of the same old fact) + content = the NEW fact. The old memories are kept as history, not overwritten or deleted; do not re-state them.
+- "noop": the new memory is already fully captured by an existing memory \u2014 same facet of the same subject, no new information. This INCLUDES a restatement in different words ("has two kids" / "has two children"): if the existing memory already tells you everything the new one does, the answer is noop no matter how differently it is worded. Skip the write.
 
 RULES (carry these strictly):
 
 1. ONE OBSERVATION PER DISTINCT FACET. If the new memory is about "user's aunt's twins" and an existing memory is also about "user's aunt's twins", they are the same facet \u2192 update, never create.
+1a. SAME SUBJECT REQUIRED \u2014 check this FIRST, before you look at the facet. The subject is WHO the fact is about: the user, or a specific person or thing in their life (a relative, their manager, their dog Biscuit). "update", "supersede" and "noop" all require the new memory and the existing one to be about the SAME subject. Two memories can share a facet and still have different subjects, and then they are simply two different facts: "User's daughter is allergic to peanuts" and "User is allergic to peanuts" are both about a peanut allergy, but one is about the DAUGHTER and one is about the USER \u2192 create, keep both. This holds for EVERY attribute, not just the one in this example \u2014 where someone lives, who they work for, what they own, how old they are. A possessive like "user's X" makes X the subject, not the user; strip it and ask "whose fact is this?" before comparing anything. Never retire the user's own value because a fact about somebody else resembles it \u2014 the user's fact is still true, and retiring it destroys it.
 2. MATCH BY FACET, NOT TOPIC. Two memories both mentioning "Zara" is not enough to merge \u2014 only merge if they describe the same property (e.g. both about "user's pending Zara boot exchange"). Two memories about Zara on different topics (e.g. "user shops at Zara" + "user returned a sweater to Zara last week") are separate facets.
 3. NO COMPUTATION. Do not sum counts, decrement quantities, or derive new facts from existing ones. If the new memory says "user spent $200 today" and an existing memory says "user spent $150 yesterday", these are TWO SEPARATE EVENTS \u2014 create.
 4. EVENTS vs STANDING STATE.
    - Distinct EVENTS (episodic \u2014 something that happened on a date) are separate memories, even if the same activity: "user went to gym Monday" vs "user went to gym Friday" \u2192 create; keep both.
-   - A STANDING ATTRIBUTE (an ongoing state: where the user lives/works, relationship status, current role) has ONE current value. When the new memory changes that value ("Lives in Portland" \u2192 "Lives in San Francisco"; "Works at Google" \u2192 "Works at Riverbend"; "Engaged" \u2192 "Broke up"), the old value is no longer true \u2192 supersede (retire the old, record the new). Do NOT create (that leaves a stale contradiction) and do NOT update (that erases the history that the old value was once true).
-5. When in doubt between create and update, choose create \u2014 EXCEPT when the new memory directly contradicts the current value of a standing attribute in an existing memory; then choose supersede. Over-merging loses information; a live contradiction is worse than either.
+   - A STANDING ATTRIBUTE (an ongoing state: where someone lives/works, relationship status, current role) has ONE current value PER SUBJECT. When the new memory changes that value FOR THE SAME SUBJECT ("Lives in Portland" \u2192 "Lives in San Francisco"; "Works at Google" \u2192 "Works at Riverbend"; "Engaged" \u2192 "Broke up"), the old value is no longer true \u2192 supersede (retire the old, record the new). Do NOT create (that leaves a stale contradiction) and do NOT update (that erases the history that the old value was once true). A different subject holding the same attribute is not a value change at all \u2192 create.
+5. When in doubt between create and update, choose create \u2014 EXCEPT when the new memory directly contradicts the current value of a standing attribute in an existing memory ABOUT THE SAME SUBJECT; then choose supersede. Two facts about different subjects never contradict each other, however similarly they read. Over-merging loses information; a live contradiction is worse than either.
+6. When in doubt between update and noop, ask whether the existing memory ALONE already answers everything the new one would. If it does, choose noop \u2014 a write that changes only the wording costs a re-embed and makes an old fact look newly observed.
 
 OUTPUT \u2014 strict JSON, no prose:
 {

package/dist/server/index.d.mts

@@ -6025,6 +6025,12 @@ declare function getUnfiledVaultMemoriesOp(ctx: VaultMemoryOperationsContext): P
  * older version (including pre-v37 rows, read as version 0) is then re-extracted
  * by the next sweep, so topic-quality improvements propagate across the existing
  * vault. The worker's `limit` drains that re-extraction across sweeps.
+ *
+ * Bumping this is a WHOLE-VAULT re-extraction: the gate is unconditional across
+ * every stamped row, and `stampTopicsExtractedAtOp` stamps this version on every
+ * healthy row, so a bump sends each user's entire extracted vault back to the
+ * LLM. Never reach for it to repair a subset — see the pre-v42-restore repair in
+ * {@link getMemoriesNeedingTopicExtractionOp}, which targets the damaged rows.
  */
 declare const TOPICS_EXTRACTION_VERSION = 3;
 /**
@@ -6037,9 +6043,10 @@ interface MemoriesNeedingTopicExtraction {
      * Memories to run LLM topic extraction on (decrypted): never-extracted rows
      * with no entity links, plus stamped rows edited since their last pass
      * (`updated_at` > `topics_extracted_at`) or extracted under an older
-     * `topics_extracted_version` than {@link TOPICS_EXTRACTION_VERSION}. Edited /
-     * stale-version rows come first (they get priority under `limit`), each group
-     * newest-created first.
+     * `topics_extracted_version` than {@link TOPICS_EXTRACTION_VERSION}, plus the
+     * pre-v42-restore repair: a stamped row left with neither links nor a `topics`
+     * record, which no no-LLM bucket can reach. Edited / stale-version rows come
+     * first (they get priority under `limit`), each group newest-created first.
      */
     pending: StoredVaultMemory[];
     /**
@@ -6091,6 +6098,11 @@ interface MemoriesNeedingTopicExtraction {
  * between the record and the index and never re-derive them. That's why the
  * ownership filter lives in the partition below rather than in the query: a
  * restored curated memory is exactly the row whose index must be rebuilt.
+ *
+ * NOT purely a read: a curated row with no `topics` record AND no usable link is
+ * a contradiction only a pre-v42 restore produces, and this is the one place
+ * that can see all three facts at once, so it clears the flag there (capped by
+ * `limit`) before returning. See the branch for why that's safe.
  */
 declare function getMemoriesNeedingTopicExtractionOp(ctx: VaultMemoryOperationsContext, options?: {
     limit?: number;

package/dist/server/index.d.ts

@@ -6025,6 +6025,12 @@ declare function getUnfiledVaultMemoriesOp(ctx: VaultMemoryOperationsContext): P
  * older version (including pre-v37 rows, read as version 0) is then re-extracted
  * by the next sweep, so topic-quality improvements propagate across the existing
  * vault. The worker's `limit` drains that re-extraction across sweeps.
+ *
+ * Bumping this is a WHOLE-VAULT re-extraction: the gate is unconditional across
+ * every stamped row, and `stampTopicsExtractedAtOp` stamps this version on every
+ * healthy row, so a bump sends each user's entire extracted vault back to the
+ * LLM. Never reach for it to repair a subset — see the pre-v42-restore repair in
+ * {@link getMemoriesNeedingTopicExtractionOp}, which targets the damaged rows.
  */
 declare const TOPICS_EXTRACTION_VERSION = 3;
 /**
@@ -6037,9 +6043,10 @@ interface MemoriesNeedingTopicExtraction {
      * Memories to run LLM topic extraction on (decrypted): never-extracted rows
      * with no entity links, plus stamped rows edited since their last pass
      * (`updated_at` > `topics_extracted_at`) or extracted under an older
-     * `topics_extracted_version` than {@link TOPICS_EXTRACTION_VERSION}. Edited /
-     * stale-version rows come first (they get priority under `limit`), each group
-     * newest-created first.
+     * `topics_extracted_version` than {@link TOPICS_EXTRACTION_VERSION}, plus the
+     * pre-v42-restore repair: a stamped row left with neither links nor a `topics`
+     * record, which no no-LLM bucket can reach. Edited / stale-version rows come
+     * first (they get priority under `limit`), each group newest-created first.
      */
     pending: StoredVaultMemory[];
     /**
@@ -6091,6 +6098,11 @@ interface MemoriesNeedingTopicExtraction {
  * between the record and the index and never re-derive them. That's why the
  * ownership filter lives in the partition below rather than in the query: a
  * restored curated memory is exactly the row whose index must be rebuilt.
+ *
+ * NOT purely a read: a curated row with no `topics` record AND no usable link is
+ * a contradiction only a pre-v42 restore produces, and this is the one place
+ * that can see all three facts at once, so it clears the flag there (capped by
+ * `limit`) before returning. See the branch for why that's safe.
  */
 declare function getMemoriesNeedingTopicExtractionOp(ctx: VaultMemoryOperationsContext, options?: {
     limit?: number;

package/dist/server/index.mjs

@@ -133,7 +133,7 @@ import {
   updateVaultMemoryOp,
   upsertMessageOp,
   vaultMemoryToStored
-} from "./chunk-WZE6ZVKE.mjs";
+} from "./chunk-WADHFDMA.mjs";
 import {
   createStreamingDeAnonymizer,
   notifyConsolidationFallback,
@@ -5445,7 +5445,7 @@ async function tryConsolidate(trimmed, ctx, options, prepared) {
     content: m.content,
     similarity: m.similarity
   }));
-  const { consolidateMemory: doConsolidate } = await import("./consolidate-4VEAS3YN.mjs");
+  const { consolidateMemory: doConsolidate } = await import("./consolidate-GRMEDWKK.mjs");
   const decision = await doConsolidate(trimmed, candidates, consolidateOptions);
   if (decision.action === "create") return null;
   if (decision.action === "supersede" && decision.content) {

package/dist/server/{recall-YZWIV6IH.mjs → recall-QTVT7HCZ.mjs}

@@ -1,6 +1,6 @@
 import {
   recall
-} from "./chunk-WZE6ZVKE.mjs";
+} from "./chunk-WADHFDMA.mjs";
 import "./chunk-OBDRKQQI.mjs";
 import "./chunk-3RPGXXPZ.mjs";
 export {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@anuma/sdk",
-  "version": "4.0.0",
+  "version": "4.0.2",
   "description": "",
   "main": "./dist/index.cjs",
   "module": "./dist/index.mjs",
@@ -159,7 +159,7 @@
   "homepage": "https://github.com/anuma-ai/sdk#readme",
   "packageManager": "pnpm@10.23.0",
   "dependencies": {
-    "@anuma/portal": "1.0.0-next.20260727223242",
+    "@anuma/portal": "1.0.0-next.20260728181242",
     "@babel/parser": "^7.29.2",
     "@babel/types": "^7.29.0",
     "ai": "6.0.202",