@mastra/memory 1.23.1 → 1.24.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mastra/memory",
-  "version": "1.23.1",
+  "version": "1.24.0",
   "description": "",
   "type": "module",
   "main": "./dist/index.js",
@@ -56,17 +56,17 @@
     "@vitest/coverage-v8": "4.1.10",
     "@vitest/ui": "4.1.10",
     "eslint": "^10.7.0",
-    "tsup": "^8.5.1",
+    "tsdown": "0.22.9",
     "tsx": "^4.23.1",
     "typescript": "^6.0.3",
     "typescript-eslint": "^8.57.0",
     "vitest": "4.1.10",
-    "@internal/ai-sdk-v5": "0.0.62",
-    "@internal/ai-sdk-v4": "0.0.62",
-    "@internal/ai-v6": "0.0.62",
-    "@internal/types-builder": "0.0.90",
-    "@mastra/core": "1.52.0",
-    "@internal/lint": "0.0.115"
+    "@internal/ai-sdk-v5": "0.0.65",
+    "@internal/lint": "0.0.118",
+    "@internal/types-builder": "0.0.93",
+    "@internal/ai-v6": "0.0.65",
+    "@internal/ai-sdk-v4": "0.0.65",
+    "@mastra/core": "1.54.0"
   },
   "peerDependencies": {
     "@mastra/core": ">=1.4.1-0 <2.0.0-0"
@@ -85,12 +85,13 @@
   },
   "scripts": {
     "check": "tsc --noEmit",
-    "build:lib": "tsup --silent --config tsup.config.ts",
+    "build:lib": "tsdown --silent --config tsdown.config.ts",
     "build:watch": "pnpm build:lib --watch",
     "test:integration": "cd integration-tests && pnpm run test",
     "test:unit": "pnpm vitest run ./src/*",
     "test": "pnpm test:integration && pnpm test:unit",
-    "lint": "eslint .",
+    "lint": "oxlint . && eslint .",
+    "lint:fix": "oxlint --fix . && eslint --fix .",
     "analyze:om-repro": "node ./scripts/analyze-om-repro.mjs",
     "sanitize:om-repro": "node ./scripts/sanitize-om-repro.mjs"
   }

package/dist/chunk-43FJOLKM.cjs

@@ -1,108 +0,0 @@
-'use strict';
-
-var crypto = require('crypto');
-var diff = require('diff');
-
-// src/processors/working-memory-state/processor.ts
-var WORKING_MEMORY_STATE_ID = "working-memory";
-var WORKING_MEMORY_STATE_PROCESSOR_ID = "working-memory-state";
-var WorkingMemoryStateProcessor = class {
-  constructor(memory, memoryConfig) {
-    this.memory = memory;
-    this.memoryConfig = memoryConfig;
-  }
-  memory;
-  memoryConfig;
-  id = WORKING_MEMORY_STATE_PROCESSOR_ID;
-  stateId = WORKING_MEMORY_STATE_ID;
-  async computeStateSignal(args) {
-    const template = await this.memory.getWorkingMemoryTemplate({ memoryConfig: this.memoryConfig });
-    if (!template) return;
-    const data = await this.memory.getWorkingMemory({
-      threadId: args.threadId,
-      resourceId: args.resourceId,
-      memoryConfig: this.memoryConfig
-    });
-    const contents = data?.trim();
-    if (!contents) return;
-    const cacheKey = stableWorkingMemoryCacheKey({ format: template.format, data: contents });
-    const shouldMakeSnapshot = !args.contextWindow.hasSnapshot;
-    if (args.tracking?.currentCacheKey === cacheKey && !shouldMakeSnapshot) return;
-    const mergedConfig = this.memory.getMergedThreadConfig(this.memoryConfig);
-    const scope = mergedConfig.workingMemory?.scope ?? "resource";
-    const deltaCandidate = template.format === "markdown" && !shouldMakeSnapshot ? buildMarkdownDelta({
-      lastSnapshot: args.lastSnapshot,
-      deltasSinceSnapshot: args.deltasSinceSnapshot,
-      nextContents: contents
-    }) : void 0;
-    if (deltaCandidate) {
-      return {
-        id: WORKING_MEMORY_STATE_ID,
-        mode: "delta",
-        cacheKey,
-        tagName: "working-memory",
-        contents: deltaCandidate.contents,
-        delta: deltaCandidate.contents,
-        // Stash the full post-edit text on the signal so the next turn can
-        // diff against the most recently emitted state instead of the older
-        // snapshot. Invisible to the model.
-        value: contents,
-        attributes: {
-          format: template.format,
-          scope,
-          patch: "unified-diff"
-        }
-      };
-    }
-    return {
-      id: WORKING_MEMORY_STATE_ID,
-      mode: "snapshot",
-      cacheKey,
-      tagName: "working-memory",
-      contents,
-      // Mirror contents in value so the first delta after a snapshot has a
-      // typed prior-state to diff against without falling back to contents.
-      value: contents,
-      attributes: {
-        format: template.format,
-        scope
-      }
-    };
-  }
-};
-function stableWorkingMemoryCacheKey(input) {
-  const hash = crypto.createHash("sha256");
-  hash.update(input.format);
-  hash.update("\0");
-  hash.update(input.data ?? "");
-  return `sha256:${hash.digest("hex")}`;
-}
-function buildMarkdownDelta(args) {
-  const { lastSnapshot, deltasSinceSnapshot, nextContents } = args;
-  const latestDelta = deltasSinceSnapshot.at(-1);
-  const prior = pickStringValue(readSignalValue(latestDelta)) ?? pickStringValue(readSignalValue(lastSnapshot)) ?? (typeof lastSnapshot?.contents === "string" ? lastSnapshot.contents : void 0);
-  if (!prior) return;
-  const patch = renderHunksOnly(prior, nextContents);
-  return { contents: patch };
-}
-function pickStringValue(value) {
-  return typeof value === "string" ? value : void 0;
-}
-function readSignalValue(signal) {
-  return signal?.metadata?.value;
-}
-function renderHunksOnly(prior, next) {
-  const { hunks } = diff.structuredPatch("", "", prior, next, "", "", { context: 0 });
-  return hunks.map((hunk) => {
-    const header = `@@ -${hunk.oldStart},${hunk.oldLines} +${hunk.newStart},${hunk.newLines} @@`;
-    const lines = hunk.lines.filter((line) => !line.startsWith("\"));
-    return [header, ...lines].join("\n");
-  }).join("\n");
-}
-
-exports.WORKING_MEMORY_STATE_ID = WORKING_MEMORY_STATE_ID;
-exports.WORKING_MEMORY_STATE_PROCESSOR_ID = WORKING_MEMORY_STATE_PROCESSOR_ID;
-exports.WorkingMemoryStateProcessor = WorkingMemoryStateProcessor;
-exports.stableWorkingMemoryCacheKey = stableWorkingMemoryCacheKey;
-//# sourceMappingURL=chunk-43FJOLKM.cjs.map
-//# sourceMappingURL=chunk-43FJOLKM.cjs.map

package/dist/chunk-43FJOLKM.cjs.map

@@ -1 +0,0 @@
-{"version":3,"sources":["../src/processors/working-memory-state/processor.ts"],"names":["createHash","structuredPatch"],"mappings":";;;;;;AA2CO,IAAM,uBAAA,GAA0B;AAChC,IAAM,iCAAA,GAAoC;AAE1C,IAAM,8BAAN,MAAiG;AAAA,EAItG,WAAA,CACmB,QACA,YAAA,EACjB;AAFiB,IAAA,IAAA,CAAA,MAAA,GAAA,MAAA;AACA,IAAA,IAAA,CAAA,YAAA,GAAA,YAAA;AAAA,EAChB;AAAA,EAFgB,MAAA;AAAA,EACA,YAAA;AAAA,EALV,EAAA,GAAK,iCAAA;AAAA,EACL,OAAA,GAAU,uBAAA;AAAA,EAOnB,MAAM,mBAAmB,IAAA,EAAiE;AACxF,IAAA,MAAM,QAAA,GAAW,MAAM,IAAA,CAAK,MAAA,CAAO,yBAAyB,EAAE,YAAA,EAAc,IAAA,CAAK,YAAA,EAAc,CAAA;AAC/F,IAAA,IAAI,CAAC,QAAA,EAAU;AAEf,IAAA,MAAM,IAAA,GAAO,MAAM,IAAA,CAAK,MAAA,CAAO,gBAAA,CAAiB;AAAA,MAC9C,UAAU,IAAA,CAAK,QAAA;AAAA,MACf,YAAY,IAAA,CAAK,UAAA;AAAA,MACjB,cAAc,IAAA,CAAK;AAAA,KACpB,CAAA;AAID,IAAA,MAAM,QAAA,GAAW,MAAM,IAAA,EAAK;AAC5B,IAAA,IAAI,CAAC,QAAA,EAAU;AAEf,IAAA,MAAM,QAAA,GAAW,4BAA4B,EAAE,MAAA,EAAQ,SAAS,MAAA,EAAQ,IAAA,EAAM,UAAU,CAAA;AACxF,IAAA,MAAM,kBAAA,GAAqB,CAAC,IAAA,CAAK,aAAA,CAAc,WAAA;AAC/C,IAAA,IAAI,IAAA,CAAK,QAAA,EAAU,eAAA,KAAoB,QAAA,IAAY,CAAC,kBAAA,EAAoB;AAExE,IAAA,MAAM,YAAA,GAAe,IAAA,CAAK,MAAA,CAAO,qBAAA,CAAsB,KAAK,YAAY,CAAA;AACxE,IAAA,MAAM,KAAA,GAAQ,YAAA,CAAa,aAAA,EAAe,KAAA,IAAS,UAAA;AAEnD,IAAA,MAAM,iBACJ,QAAA,CAAS,MAAA,KAAW,UAAA,IAAc,CAAC,qBAC/B,kBAAA,CAAmB;AAAA,MACjB,cAAc,IAAA,CAAK,YAAA;AAAA,MACnB,qBAAqB,IAAA,CAAK,mBAAA;AAAA,MAC1B,YAAA,EAAc;AAAA,KACf,CAAA,GACD,MAAA;AAEN,IAAA,IAAI,cAAA,EAAgB;AAClB,MAAA,OAAO;AAAA,QACL,EAAA,EAAI,uBAAA;AAAA,QACJ,IAAA,EAAM,OAAA;AAAA,QACN,QAAA;AAAA,QACA,OAAA,EAAS,gBAAA;AAAA,QACT,UAAU,cAAA,CAAe,QAAA;AAAA,QACzB,OAAO,cAAA,CAAe,QAAA;AAAA;AAAA;AAAA;AAAA,QAItB,KAAA,EAAO,QAAA;AAAA,QACP,UAAA,EAAY;AAAA,UACV,QAAQ,QAAA,CAAS,MAAA;AAAA,UACjB,KAAA;AAAA,UACA,KAAA,EAAO;AAAA;AACT,OACF;AAAA,IACF;AAEA,IAAA,OAAO;AAAA,MACL,EAAA,EAAI,uBAAA;AAAA,MACJ,IAAA,EAAM,UAAA;AAAA,MACN,QAAA;AAAA,MACA,OAAA,EAAS,gBAAA;AAAA,MACT,QAAA;AAAA;AAAA;AAAA,MAGA,KAAA,EAAO,QAAA;AAAA,MACP,UAAA,EAAY;AAAA,QACV,QAAQ,QAAA,CAAS,MAAA;AAAA,QACjB;AAAA;AACF,KACF;AAAA,EACF;AACF;AAOO,SAAS,4BAA4B,KAAA,EAGjC;AACT,EAAA,MAAM,IAAA,GAAOA,kBAAW,QAAQ,CAAA;AAChC,EAAA,IAAA,CAAK,MAAA,CAAO,MAAM,MAAM,CAAA;AACxB,EAAA,IAAA,CAAK,OAAO,IAAI,CAAA;AAChB,EAAA,IAAA,CAAK,MAAA,CAAO,KAAA,CAAM,IAAA,IAAQ,EAAE,CAAA;AAC5B,EAAA,OAAO,CAAA,OAAA,EAAU,IAAA,CAAK,MAAA,CAAO,KAAK,CAAC,CAAA,CAAA;AACrC;AAeA,SAAS,mBAAmB,IAAA,EAIS;AACnC,EAAA,MAAM,EAAE,YAAA,EAAc,mBAAA,EAAqB,YAAA,EAAa,GAAI,IAAA;AAK5D,EAAA,MAAM,WAAA,GAAc,mBAAA,CAAoB,EAAA,CAAG,EAAE,CAAA;AAC7C,EAAA,MAAM,QACJ,eAAA,CAAgB,eAAA,CAAgB,WAAW,CAAC,KAC5C,eAAA,CAAgB,eAAA,CAAgB,YAAY,CAAC,MAC5C,OAAO,YAAA,EAAc,QAAA,KAAa,QAAA,GAAW,aAAa,QAAA,GAAW,MAAA,CAAA;AAExE,EAAA,IAAI,CAAC,KAAA,EAAO;AAEZ,EAAA,MAAM,KAAA,GAAQ,eAAA,CAAgB,KAAA,EAAO,YAAY,CAAA;AAEjD,EAAA,OAAO,EAAE,UAAU,KAAA,EAAM;AAC3B;AAEA,SAAS,gBAAgB,KAAA,EAAoC;AAC3D,EAAA,OAAO,OAAO,KAAA,KAAU,QAAA,GAAW,KAAA,GAAQ,MAAA;AAC7C;AAEA,SAAS,gBAAgB,MAAA,EAAyD;AAChF,EAAA,OAAQ,QAAQ,QAAA,EAA8C,KAAA;AAChE;AAWA,SAAS,eAAA,CAAgB,OAAe,IAAA,EAAsB;AAC5D,EAAA,MAAM,EAAE,KAAA,EAAM,GAAIC,oBAAA,CAAgB,EAAA,EAAI,EAAA,EAAI,KAAA,EAAO,IAAA,EAAM,EAAA,EAAI,EAAA,EAAI,EAAE,OAAA,EAAS,GAAG,CAAA;AAC7E,EAAA,OAAO,KAAA,CACJ,IAAI,CAAA,IAAA,KAAQ;AACX,IAAA,MAAM,MAAA,GAAS,CAAA,IAAA,EAAO,IAAA,CAAK,QAAQ,CAAA,CAAA,EAAI,IAAA,CAAK,QAAQ,CAAA,EAAA,EAAK,IAAA,CAAK,QAAQ,CAAA,CAAA,EAAI,IAAA,CAAK,QAAQ,CAAA,GAAA,CAAA;AACvF,IAAA,MAAM,KAAA,GAAQ,KAAK,KAAA,CAAM,MAAA,CAAO,UAAQ,CAAC,IAAA,CAAK,UAAA,CAAW,8BAA8B,CAAC,CAAA;AACxF,IAAA,OAAO,CAAC,MAAA,EAAQ,GAAG,KAAK,CAAA,CAAE,KAAK,IAAI,CAAA;AAAA,EACrC,CAAC,CAAA,CACA,IAAA,CAAK,IAAI,CAAA;AACd","file":"chunk-43FJOLKM.cjs","sourcesContent":["/**\n * WorkingMemoryStateProcessor\n *\n * Experimental: delivers working memory to the model as a state signal instead\n * of folding it into the system message. Storage and the `setWorkingMemory`\n * tool are unchanged — this processor only changes the delivery path.\n *\n * Pattern matches `BrowserContextProcessor` in `@mastra/core/browser`:\n * - `stateId` namespaces the state lane on the thread.\n * - `cacheKey` is derived from the rendered payload so dedup is automatic.\n * - `contextWindow.hasSnapshot` re-injection ensures the model still sees the\n *   current snapshot after older messages drop out of the window.\n *\n * Delta emission (markdown mode only): when a prior snapshot exists in the\n * context window, the processor emits a unified-diff delta against that\n * snapshot's contents. Schema mode and the snapshot fallback always emit a\n * full snapshot.\n *\n * @example\n * ```ts\n * new Memory({\n *   options: {\n *     workingMemory: {\n *       enabled: true,\n *       template: '...',\n *       useStateSignals: true, // auto-attaches this processor\n *     },\n *   },\n * });\n * ```\n */\n\nimport { createHash } from 'node:crypto';\n\nimport type { MastraMemory, MemoryConfigInternal, WorkingMemoryTemplate } from '@mastra/core/memory';\nimport type {\n  ComputeStateSignalArgs,\n  ComputeStateSignalResult,\n  Processor,\n  ProcessorActiveStateSignal,\n} from '@mastra/core/processors';\nimport { structuredPatch } from 'diff';\n\nexport const WORKING_MEMORY_STATE_ID = 'working-memory';\nexport const WORKING_MEMORY_STATE_PROCESSOR_ID = 'working-memory-state';\n\nexport class WorkingMemoryStateProcessor implements Processor<typeof WORKING_MEMORY_STATE_PROCESSOR_ID> {\n  readonly id = WORKING_MEMORY_STATE_PROCESSOR_ID;\n  readonly stateId = WORKING_MEMORY_STATE_ID;\n\n  constructor(\n    private readonly memory: MastraMemory,\n    private readonly memoryConfig?: MemoryConfigInternal,\n  ) {}\n\n  async computeStateSignal(args: ComputeStateSignalArgs): Promise<ComputeStateSignalResult> {\n    const template = await this.memory.getWorkingMemoryTemplate({ memoryConfig: this.memoryConfig });\n    if (!template) return;\n\n    const data = await this.memory.getWorkingMemory({\n      threadId: args.threadId,\n      resourceId: args.resourceId,\n      memoryConfig: this.memoryConfig,\n    });\n\n    // Nothing stored yet — no state to broadcast. The setWorkingMemory tool\n    // description tells the model the expected shape; the signal carries state.\n    const contents = data?.trim();\n    if (!contents) return;\n\n    const cacheKey = stableWorkingMemoryCacheKey({ format: template.format, data: contents });\n    const shouldMakeSnapshot = !args.contextWindow.hasSnapshot;\n    if (args.tracking?.currentCacheKey === cacheKey && !shouldMakeSnapshot) return;\n\n    const mergedConfig = this.memory.getMergedThreadConfig(this.memoryConfig);\n    const scope = mergedConfig.workingMemory?.scope ?? 'resource';\n\n    const deltaCandidate =\n      template.format === 'markdown' && !shouldMakeSnapshot\n        ? buildMarkdownDelta({\n            lastSnapshot: args.lastSnapshot,\n            deltasSinceSnapshot: args.deltasSinceSnapshot,\n            nextContents: contents,\n          })\n        : undefined;\n\n    if (deltaCandidate) {\n      return {\n        id: WORKING_MEMORY_STATE_ID,\n        mode: 'delta',\n        cacheKey,\n        tagName: 'working-memory',\n        contents: deltaCandidate.contents,\n        delta: deltaCandidate.contents,\n        // Stash the full post-edit text on the signal so the next turn can\n        // diff against the most recently emitted state instead of the older\n        // snapshot. Invisible to the model.\n        value: contents,\n        attributes: {\n          format: template.format,\n          scope,\n          patch: 'unified-diff',\n        },\n      };\n    }\n\n    return {\n      id: WORKING_MEMORY_STATE_ID,\n      mode: 'snapshot',\n      cacheKey,\n      tagName: 'working-memory',\n      contents,\n      // Mirror contents in value so the first delta after a snapshot has a\n      // typed prior-state to diff against without falling back to contents.\n      value: contents,\n      attributes: {\n        format: template.format,\n        scope,\n      },\n    };\n  }\n}\n\n/**\n * Stable cache key for the rendered working memory payload. Returns a SHA-256\n * digest so dedup metadata stays compact regardless of payload size (working\n * memory blobs can grow arbitrarily long).\n */\nexport function stableWorkingMemoryCacheKey(input: {\n  format: WorkingMemoryTemplate['format'];\n  data: string | null;\n}): string {\n  const hash = createHash('sha256');\n  hash.update(input.format);\n  hash.update('\\0');\n  hash.update(input.data ?? '');\n  return `sha256:${hash.digest('hex')}`;\n}\n\n/**\n * Build a unified-diff delta against the most recently emitted state. Prefers\n * the latest delta's `value` (the post-edit full text) when available, falling\n * back to the snapshot's `value` and finally the snapshot's `contents`. This\n * keeps deltas incremental (B→C) instead of cumulative against a stale\n * snapshot (A→C), which matters when many small edits land between snapshots.\n *\n * Returns undefined when:\n * - there's no prior state to diff against\n * - the prior state isn't a plain string (multimodal signal)\n *\n * In either case the caller falls back to emitting a full snapshot.\n */\nfunction buildMarkdownDelta(args: {\n  lastSnapshot?: ProcessorActiveStateSignal;\n  deltasSinceSnapshot: ProcessorActiveStateSignal[];\n  nextContents: string;\n}): { contents: string } | undefined {\n  const { lastSnapshot, deltasSinceSnapshot, nextContents } = args;\n\n  // `value` is stored on the persisted signal's metadata (see applyStateSignal\n  // in @mastra/core/agent/state-signals). Read from there to recover the\n  // post-edit full text from the most recently emitted state.\n  const latestDelta = deltasSinceSnapshot.at(-1);\n  const prior =\n    pickStringValue(readSignalValue(latestDelta)) ??\n    pickStringValue(readSignalValue(lastSnapshot)) ??\n    (typeof lastSnapshot?.contents === 'string' ? lastSnapshot.contents : undefined);\n  ('');\n  if (!prior) return;\n\n  const patch = renderHunksOnly(prior, nextContents);\n\n  return { contents: patch };\n}\n\nfunction pickStringValue(value: unknown): string | undefined {\n  return typeof value === 'string' ? value : undefined;\n}\n\nfunction readSignalValue(signal: ProcessorActiveStateSignal | undefined): unknown {\n  return (signal?.metadata as { value?: unknown } | undefined)?.value;\n}\n\n/**\n * Render a unified-diff-style patch body containing only `@@` hunks and their\n * lines — dropping the filename preamble (`Index:` / `===` / `---` / `+++`)\n * that `createPatch` emits and the `\` trailer.\n * The preamble exists for tooling like `patch -p1` to know which file to\n * apply to; we only ever diff a single working-memory blob. The newline\n * trailer is semantically meaningless to the model and adds noise to the\n * state signal.\n */\nfunction renderHunksOnly(prior: string, next: string): string {\n  const { hunks } = structuredPatch('', '', prior, next, '', '', { context: 0 });\n  return hunks\n    .map(hunk => {\n      const header = `@@ -${hunk.oldStart},${hunk.oldLines} +${hunk.newStart},${hunk.newLines} @@`;\n      const lines = hunk.lines.filter(line => !line.startsWith('\\\'));\n      return [header, ...lines].join('\\n');\n    })\n    .join('\\n');\n}\n"]}

package/dist/chunk-D4J4XPGM.cjs

@@ -1,111 +0,0 @@
-'use strict';
-
-// src/processors/observational-memory/constants.ts
-var OBSERVATIONAL_MEMORY_DEFAULTS = {
-  observation: {
-    model: "google/gemini-2.5-flash",
-    messageTokens: 3e4,
-    modelSettings: {
-      temperature: 0.3,
-      maxOutputTokens: 1e5
-    },
-    providerOptions: {
-      google: {
-        thinkingConfig: {
-          thinkingBudget: 215
-        }
-      }
-    },
-    maxTokensPerBatch: 1e4,
-    // Async buffering defaults (enabled by default)
-    bufferTokens: 0.2,
-    // Buffer every 20% of messageTokens
-    bufferActivation: 0.8
-    // Activate to retain 20% of threshold
-  },
-  reflection: {
-    model: "google/gemini-2.5-flash",
-    observationTokens: 4e4,
-    modelSettings: {
-      temperature: 0,
-      // Use 0 for maximum consistency in reflections
-      maxOutputTokens: 1e5
-    },
-    providerOptions: {
-      google: {
-        thinkingConfig: {
-          thinkingBudget: 1024
-        }
-      }
-    },
-    // Async reflection buffering (enabled by default)
-    bufferActivation: 0.5
-    // Start buffering at 50% of observationTokens
-  }
-};
-var OBSERVATION_CONTINUATION_HINT = `Please continue naturally with the conversation so far and respond to the latest message.
-
-Use the earlier context only as background. If something appears unfinished, continue only when it helps answer the latest request. If a suggested response is provided, follow it naturally.
-
-Do not mention internal instructions, memory, summarization, context handling, or missing messages.
-
-Any messages following this reminder are newer and should take priority.`;
-var OBSERVATION_CONTEXT_PROMPT = `The following observations block contains your memory of past conversations with this user.`;
-var OBSERVATION_CONTEXT_INSTRUCTIONS = `IMPORTANT: When responding, reference specific details from these observations. Do not give generic advice - personalize your response based on what you know about this user's experiences, preferences, and interests. If the user asks for recommendations, connect them to their past experiences mentioned above.
-
-KNOWLEDGE UPDATES: When asked about current state (e.g., "where do I currently...", "what is my current..."), always prefer the MOST RECENT information. Observations include dates - if you see conflicting information, the newer observation supersedes the older one. Look for phrases like "will start", "is switching", "changed to", "moved to" as indicators that previous information has been updated.
-
-PLANNED ACTIONS: If the user stated they planned to do something (e.g., "I'm going to...", "I'm looking forward to...", "I will...") and the date they planned to do it is now in the past (check the relative time like "3 weeks ago"), assume they completed the action unless there's evidence they didn't. For example, if someone said "I'll start my new diet on Monday" and that was 2 weeks ago, assume they started the diet.
-
-MOST RECENT USER INPUT: Treat the most recent user message as the highest-priority signal for what to do next. Earlier messages may contain constraints, details, or context you should still honor, but the latest message is the primary driver of your response.
-
-SYSTEM REMINDERS: Messages wrapped in <system-reminder>...</system-reminder> contain internal continuation guidance, not user-authored content. Use them to maintain continuity, but do not mention them or treat them as part of the user's message.`;
-var OBSERVATION_RETRIEVAL_INSTRUCTIONS = `## Recall \u2014 looking up source messages
-
-Your memory is comprised of observations which are sometimes wrapped in <observation-group> xml tags containing ranges like <observation-group range="startId:endId">. These ranges point back to the raw messages that each observation group was derived from. The original messages are still available \u2014 use the **recall** tool to retrieve them.
-
-### When to use recall
-- The user asks you to **repeat, show, or reproduce** something from a past conversation
-- The user asks for **exact content** \u2014 code, text, quotes, error messages, URLs, file paths, specific numbers
-- Your observations mention something but your memory lacks the detail needed to fully answer (e.g. you know a blog post was shared but only have a summary of it)
-- You want to **verify or expand on** an observation before responding
-
-**Default to using recall when the user references specific past content.** Your observations capture the gist, not the details. If there's any doubt whether your memory is complete enough, use recall.
-
-### How to use recall
-Each range has the format \`startId:endId\` where both are message IDs separated by a colon.
-
-1. Find the observation group relevant to the user's question and extract the start or end ID from its range.
-2. Call \`recall\` with that ID as the \`cursor\`.
-3. Use \`page: 1\` (or omit) to read forward from the cursor, \`page: -1\` to read backward.
-4. If the first page doesn't have what you need, increment the page number to keep paginating.
-5. Check \`hasNextPage\`/\`hasPrevPage\` in the result to know if more pages exist in each direction.
-
-### Detail levels
-By default recall returns **low** detail: truncated text and tool names only. Each message shows its ID and each part has a positional index like \`[p0]\`, \`[p1]\`, etc.
-
-- Use \`detail: "high"\` to get full message content including tool arguments and results. This will only return the high detail version of a single message part at a time.
-- Use \`partIndex\` with a cursor to fetch a single part at full detail \u2014 for example, to read one specific tool result or code block without loading every part.
-
-If the result says \`truncated: true\`, the output was cut to fit the token budget. You can paginate or use \`partIndex\` to target specific content.
-
-### Following up on truncated parts
-Low-detail results may include truncation hints like:
-\`[truncated \u2014 call recall cursor="..." partIndex=N detail="high" for full content]\`
-
-**When you see these hints and need the full content, make the exact call described in the hint.** This is the normal workflow: first recall at low detail to scan, then drill into specific parts at high detail. Do not stop at the low-detail result if the user asked for exact content.
-
-### When recall is NOT needed
-- The user is asking for a high-level summary and your observations already cover it
-- The question is about general preferences or facts that don't require source text
-- There is no relevant range in your observations for the topic
-
-Observation groups with range IDs and your recall tool allows you to think back and remember details you're fuzzy on.`;
-
-exports.OBSERVATIONAL_MEMORY_DEFAULTS = OBSERVATIONAL_MEMORY_DEFAULTS;
-exports.OBSERVATION_CONTEXT_INSTRUCTIONS = OBSERVATION_CONTEXT_INSTRUCTIONS;
-exports.OBSERVATION_CONTEXT_PROMPT = OBSERVATION_CONTEXT_PROMPT;
-exports.OBSERVATION_CONTINUATION_HINT = OBSERVATION_CONTINUATION_HINT;
-exports.OBSERVATION_RETRIEVAL_INSTRUCTIONS = OBSERVATION_RETRIEVAL_INSTRUCTIONS;
-//# sourceMappingURL=chunk-D4J4XPGM.cjs.map
-//# sourceMappingURL=chunk-D4J4XPGM.cjs.map

package/dist/chunk-D4J4XPGM.cjs.map

@@ -1 +0,0 @@
-{"version":3,"sources":["../src/processors/observational-memory/constants.ts"],"names":[],"mappings":";;;AAGO,IAAM,6BAAA,GAAgC;AAAA,EAC3C,WAAA,EAAa;AAAA,IACX,KAAA,EAAO,yBAAA;AAAA,IACP,aAAA,EAAe,GAAA;AAAA,IACf,aAAA,EAAe;AAAA,MACb,WAAA,EAAa,GAAA;AAAA,MACb,eAAA,EAAiB;AAAA,KACnB;AAAA,IACA,eAAA,EAAiB;AAAA,MACf,MAAA,EAAQ;AAAA,QACN,cAAA,EAAgB;AAAA,UACd,cAAA,EAAgB;AAAA;AAClB;AACF,KACF;AAAA,IACA,iBAAA,EAAmB,GAAA;AAAA;AAAA,IAEnB,YAAA,EAAc,GAAA;AAAA;AAAA,IACd,gBAAA,EAAkB;AAAA;AAAA,GACpB;AAAA,EACA,UAAA,EAAY;AAAA,IACV,KAAA,EAAO,yBAAA;AAAA,IACP,iBAAA,EAAmB,GAAA;AAAA,IACnB,aAAA,EAAe;AAAA,MACb,WAAA,EAAa,CAAA;AAAA;AAAA,MACb,eAAA,EAAiB;AAAA,KACnB;AAAA,IACA,eAAA,EAAiB;AAAA,MACf,MAAA,EAAQ;AAAA,QACN,cAAA,EAAgB;AAAA,UACd,cAAA,EAAgB;AAAA;AAClB;AACF,KACF;AAAA;AAAA,IAEA,gBAAA,EAAkB;AAAA;AAAA;AAEtB;AAOO,IAAM,6BAAA,GAAgC,CAAA;;AAAA;;AAAA;;AAAA,wEAAA;AAatC,IAAM,0BAAA,GAA6B,CAAA,2FAAA;AAMnC,IAAM,gCAAA,GAAmC,CAAA;;AAAA;;AAAA;;AAAA;;AAAA,qPAAA;AAczC,IAAM,kCAAA,GAAqC,CAAA;;AAAA;;AAAA;AAAA;AAAA;AAAA;AAAA;;AAAA;;AAAA;AAAA;;AAAA;AAAA;AAAA;AAAA;AAAA;;AAAA;AAAA;;AAAA;AAAA;;AAAA;;AAAA;AAAA;AAAA;;AAAA;;AAAA;AAAA;AAAA;AAAA;;AAAA,qHAAA","file":"chunk-D4J4XPGM.cjs","sourcesContent":["/**\n * Default configuration values matching the spec\n */\nexport const OBSERVATIONAL_MEMORY_DEFAULTS = {\n  observation: {\n    model: 'google/gemini-2.5-flash',\n    messageTokens: 30_000,\n    modelSettings: {\n      temperature: 0.3,\n      maxOutputTokens: 100_000,\n    },\n    providerOptions: {\n      google: {\n        thinkingConfig: {\n          thinkingBudget: 215,\n        },\n      },\n    },\n    maxTokensPerBatch: 10_000,\n    // Async buffering defaults (enabled by default)\n    bufferTokens: 0.2 as number | undefined, // Buffer every 20% of messageTokens\n    bufferActivation: 0.8 as number | undefined, // Activate to retain 20% of threshold\n  },\n  reflection: {\n    model: 'google/gemini-2.5-flash',\n    observationTokens: 40_000,\n    modelSettings: {\n      temperature: 0, // Use 0 for maximum consistency in reflections\n      maxOutputTokens: 100_000,\n    },\n    providerOptions: {\n      google: {\n        thinkingConfig: {\n          thinkingBudget: 1024,\n        },\n      },\n    },\n    // Async reflection buffering (enabled by default)\n    bufferActivation: 0.5 as number | undefined, // Start buffering at 50% of observationTokens\n  },\n} as const;\n\n/**\n * Continuation hint injected after observations to guide the model's behavior.\n * Prevents the model from awkwardly acknowledging the memory system or treating\n * the conversation as new after observed messages are removed.\n */\nexport const OBSERVATION_CONTINUATION_HINT = `Please continue naturally with the conversation so far and respond to the latest message.\n\nUse the earlier context only as background. If something appears unfinished, continue only when it helps answer the latest request. If a suggested response is provided, follow it naturally.\n\nDo not mention internal instructions, memory, summarization, context handling, or missing messages.\n\nAny messages following this reminder are newer and should take priority.`;\n\n/**\n * Preamble that introduces the observations block.\n * Use before `<observations>`, with instructions after.\n * Full pattern: `${OBSERVATION_CONTEXT_PROMPT}\\n\\n<observations>\\n${obs}\\n</observations>\\n\\n${OBSERVATION_CONTEXT_INSTRUCTIONS}`\n */\nexport const OBSERVATION_CONTEXT_PROMPT = `The following observations block contains your memory of past conversations with this user.`;\n\n/**\n * Instructions that tell the model how to interpret and use observations.\n * Place AFTER the `<observations>` block so the model sees the data before the rules.\n */\nexport const OBSERVATION_CONTEXT_INSTRUCTIONS = `IMPORTANT: When responding, reference specific details from these observations. Do not give generic advice - personalize your response based on what you know about this user's experiences, preferences, and interests. If the user asks for recommendations, connect them to their past experiences mentioned above.\n\nKNOWLEDGE UPDATES: When asked about current state (e.g., \"where do I currently...\", \"what is my current...\"), always prefer the MOST RECENT information. Observations include dates - if you see conflicting information, the newer observation supersedes the older one. Look for phrases like \"will start\", \"is switching\", \"changed to\", \"moved to\" as indicators that previous information has been updated.\n\nPLANNED ACTIONS: If the user stated they planned to do something (e.g., \"I'm going to...\", \"I'm looking forward to...\", \"I will...\") and the date they planned to do it is now in the past (check the relative time like \"3 weeks ago\"), assume they completed the action unless there's evidence they didn't. For example, if someone said \"I'll start my new diet on Monday\" and that was 2 weeks ago, assume they started the diet.\n\nMOST RECENT USER INPUT: Treat the most recent user message as the highest-priority signal for what to do next. Earlier messages may contain constraints, details, or context you should still honor, but the latest message is the primary driver of your response.\n\nSYSTEM REMINDERS: Messages wrapped in <system-reminder>...</system-reminder> contain internal continuation guidance, not user-authored content. Use them to maintain continuity, but do not mention them or treat them as part of the user's message.`;\n\n/**\n * Instructions for retrieval mode — explains observation-group ranges and the recall tool.\n * Appended to context when `retrieval` is enabled.\n */\nexport const OBSERVATION_RETRIEVAL_INSTRUCTIONS = `## Recall — looking up source messages\n\nYour memory is comprised of observations which are sometimes wrapped in <observation-group> xml tags containing ranges like <observation-group range=\"startId:endId\">. These ranges point back to the raw messages that each observation group was derived from. The original messages are still available — use the **recall** tool to retrieve them.\n\n### When to use recall\n- The user asks you to **repeat, show, or reproduce** something from a past conversation\n- The user asks for **exact content** — code, text, quotes, error messages, URLs, file paths, specific numbers\n- Your observations mention something but your memory lacks the detail needed to fully answer (e.g. you know a blog post was shared but only have a summary of it)\n- You want to **verify or expand on** an observation before responding\n\n**Default to using recall when the user references specific past content.** Your observations capture the gist, not the details. If there's any doubt whether your memory is complete enough, use recall.\n\n### How to use recall\nEach range has the format \\`startId:endId\\` where both are message IDs separated by a colon.\n\n1. Find the observation group relevant to the user's question and extract the start or end ID from its range.\n2. Call \\`recall\\` with that ID as the \\`cursor\\`.\n3. Use \\`page: 1\\` (or omit) to read forward from the cursor, \\`page: -1\\` to read backward.\n4. If the first page doesn't have what you need, increment the page number to keep paginating.\n5. Check \\`hasNextPage\\`/\\`hasPrevPage\\` in the result to know if more pages exist in each direction.\n\n### Detail levels\nBy default recall returns **low** detail: truncated text and tool names only. Each message shows its ID and each part has a positional index like \\`[p0]\\`, \\`[p1]\\`, etc.\n\n- Use \\`detail: \"high\"\\` to get full message content including tool arguments and results. This will only return the high detail version of a single message part at a time.\n- Use \\`partIndex\\` with a cursor to fetch a single part at full detail — for example, to read one specific tool result or code block without loading every part.\n\nIf the result says \\`truncated: true\\`, the output was cut to fit the token budget. You can paginate or use \\`partIndex\\` to target specific content.\n\n### Following up on truncated parts\nLow-detail results may include truncation hints like:\n\\`[truncated — call recall cursor=\"...\" partIndex=N detail=\"high\" for full content]\\`\n\n**When you see these hints and need the full content, make the exact call described in the hint.** This is the normal workflow: first recall at low detail to scan, then drill into specific parts at high detail. Do not stop at the low-detail result if the user asked for exact content.\n\n### When recall is NOT needed\n- The user is asking for a high-level summary and your observations already cover it\n- The question is about general preferences or facts that don't require source text\n- There is no relevant range in your observations for the topic\n\nObservation groups with range IDs and your recall tool allows you to think back and remember details you're fuzzy on.`;\n"]}

package/dist/chunk-EGRHWZRV.js

@@ -1,3 +0,0 @@
-
-//# sourceMappingURL=chunk-EGRHWZRV.js.map
-//# sourceMappingURL=chunk-EGRHWZRV.js.map

package/dist/chunk-EGRHWZRV.js.map

@@ -1 +0,0 @@
-{"version":3,"sources":[],"names":[],"mappings":"","file":"chunk-EGRHWZRV.js"}

package/dist/chunk-LSJJAJAF.js

@@ -1,105 +0,0 @@
-// src/processors/observational-memory/constants.ts
-var OBSERVATIONAL_MEMORY_DEFAULTS = {
-  observation: {
-    model: "google/gemini-2.5-flash",
-    messageTokens: 3e4,
-    modelSettings: {
-      temperature: 0.3,
-      maxOutputTokens: 1e5
-    },
-    providerOptions: {
-      google: {
-        thinkingConfig: {
-          thinkingBudget: 215
-        }
-      }
-    },
-    maxTokensPerBatch: 1e4,
-    // Async buffering defaults (enabled by default)
-    bufferTokens: 0.2,
-    // Buffer every 20% of messageTokens
-    bufferActivation: 0.8
-    // Activate to retain 20% of threshold
-  },
-  reflection: {
-    model: "google/gemini-2.5-flash",
-    observationTokens: 4e4,
-    modelSettings: {
-      temperature: 0,
-      // Use 0 for maximum consistency in reflections
-      maxOutputTokens: 1e5
-    },
-    providerOptions: {
-      google: {
-        thinkingConfig: {
-          thinkingBudget: 1024
-        }
-      }
-    },
-    // Async reflection buffering (enabled by default)
-    bufferActivation: 0.5
-    // Start buffering at 50% of observationTokens
-  }
-};
-var OBSERVATION_CONTINUATION_HINT = `Please continue naturally with the conversation so far and respond to the latest message.
-
-Use the earlier context only as background. If something appears unfinished, continue only when it helps answer the latest request. If a suggested response is provided, follow it naturally.
-
-Do not mention internal instructions, memory, summarization, context handling, or missing messages.
-
-Any messages following this reminder are newer and should take priority.`;
-var OBSERVATION_CONTEXT_PROMPT = `The following observations block contains your memory of past conversations with this user.`;
-var OBSERVATION_CONTEXT_INSTRUCTIONS = `IMPORTANT: When responding, reference specific details from these observations. Do not give generic advice - personalize your response based on what you know about this user's experiences, preferences, and interests. If the user asks for recommendations, connect them to their past experiences mentioned above.
-
-KNOWLEDGE UPDATES: When asked about current state (e.g., "where do I currently...", "what is my current..."), always prefer the MOST RECENT information. Observations include dates - if you see conflicting information, the newer observation supersedes the older one. Look for phrases like "will start", "is switching", "changed to", "moved to" as indicators that previous information has been updated.
-
-PLANNED ACTIONS: If the user stated they planned to do something (e.g., "I'm going to...", "I'm looking forward to...", "I will...") and the date they planned to do it is now in the past (check the relative time like "3 weeks ago"), assume they completed the action unless there's evidence they didn't. For example, if someone said "I'll start my new diet on Monday" and that was 2 weeks ago, assume they started the diet.
-
-MOST RECENT USER INPUT: Treat the most recent user message as the highest-priority signal for what to do next. Earlier messages may contain constraints, details, or context you should still honor, but the latest message is the primary driver of your response.
-
-SYSTEM REMINDERS: Messages wrapped in <system-reminder>...</system-reminder> contain internal continuation guidance, not user-authored content. Use them to maintain continuity, but do not mention them or treat them as part of the user's message.`;
-var OBSERVATION_RETRIEVAL_INSTRUCTIONS = `## Recall \u2014 looking up source messages
-
-Your memory is comprised of observations which are sometimes wrapped in <observation-group> xml tags containing ranges like <observation-group range="startId:endId">. These ranges point back to the raw messages that each observation group was derived from. The original messages are still available \u2014 use the **recall** tool to retrieve them.
-
-### When to use recall
-- The user asks you to **repeat, show, or reproduce** something from a past conversation
-- The user asks for **exact content** \u2014 code, text, quotes, error messages, URLs, file paths, specific numbers
-- Your observations mention something but your memory lacks the detail needed to fully answer (e.g. you know a blog post was shared but only have a summary of it)
-- You want to **verify or expand on** an observation before responding
-
-**Default to using recall when the user references specific past content.** Your observations capture the gist, not the details. If there's any doubt whether your memory is complete enough, use recall.
-
-### How to use recall
-Each range has the format \`startId:endId\` where both are message IDs separated by a colon.
-
-1. Find the observation group relevant to the user's question and extract the start or end ID from its range.
-2. Call \`recall\` with that ID as the \`cursor\`.
-3. Use \`page: 1\` (or omit) to read forward from the cursor, \`page: -1\` to read backward.
-4. If the first page doesn't have what you need, increment the page number to keep paginating.
-5. Check \`hasNextPage\`/\`hasPrevPage\` in the result to know if more pages exist in each direction.
-
-### Detail levels
-By default recall returns **low** detail: truncated text and tool names only. Each message shows its ID and each part has a positional index like \`[p0]\`, \`[p1]\`, etc.
-
-- Use \`detail: "high"\` to get full message content including tool arguments and results. This will only return the high detail version of a single message part at a time.
-- Use \`partIndex\` with a cursor to fetch a single part at full detail \u2014 for example, to read one specific tool result or code block without loading every part.
-
-If the result says \`truncated: true\`, the output was cut to fit the token budget. You can paginate or use \`partIndex\` to target specific content.
-
-### Following up on truncated parts
-Low-detail results may include truncation hints like:
-\`[truncated \u2014 call recall cursor="..." partIndex=N detail="high" for full content]\`
-
-**When you see these hints and need the full content, make the exact call described in the hint.** This is the normal workflow: first recall at low detail to scan, then drill into specific parts at high detail. Do not stop at the low-detail result if the user asked for exact content.
-
-### When recall is NOT needed
-- The user is asking for a high-level summary and your observations already cover it
-- The question is about general preferences or facts that don't require source text
-- There is no relevant range in your observations for the topic
-
-Observation groups with range IDs and your recall tool allows you to think back and remember details you're fuzzy on.`;
-
-export { OBSERVATIONAL_MEMORY_DEFAULTS, OBSERVATION_CONTEXT_INSTRUCTIONS, OBSERVATION_CONTEXT_PROMPT, OBSERVATION_CONTINUATION_HINT, OBSERVATION_RETRIEVAL_INSTRUCTIONS };
-//# sourceMappingURL=chunk-LSJJAJAF.js.map
-//# sourceMappingURL=chunk-LSJJAJAF.js.map

package/dist/chunk-LSJJAJAF.js.map

@@ -1 +0,0 @@
-{"version":3,"sources":["../src/processors/observational-memory/constants.ts"],"names":[],"mappings":";AAGO,IAAM,6BAAA,GAAgC;AAAA,EAC3C,WAAA,EAAa;AAAA,IACX,KAAA,EAAO,yBAAA;AAAA,IACP,aAAA,EAAe,GAAA;AAAA,IACf,aAAA,EAAe;AAAA,MACb,WAAA,EAAa,GAAA;AAAA,MACb,eAAA,EAAiB;AAAA,KACnB;AAAA,IACA,eAAA,EAAiB;AAAA,MACf,MAAA,EAAQ;AAAA,QACN,cAAA,EAAgB;AAAA,UACd,cAAA,EAAgB;AAAA;AAClB;AACF,KACF;AAAA,IACA,iBAAA,EAAmB,GAAA;AAAA;AAAA,IAEnB,YAAA,EAAc,GAAA;AAAA;AAAA,IACd,gBAAA,EAAkB;AAAA;AAAA,GACpB;AAAA,EACA,UAAA,EAAY;AAAA,IACV,KAAA,EAAO,yBAAA;AAAA,IACP,iBAAA,EAAmB,GAAA;AAAA,IACnB,aAAA,EAAe;AAAA,MACb,WAAA,EAAa,CAAA;AAAA;AAAA,MACb,eAAA,EAAiB;AAAA,KACnB;AAAA,IACA,eAAA,EAAiB;AAAA,MACf,MAAA,EAAQ;AAAA,QACN,cAAA,EAAgB;AAAA,UACd,cAAA,EAAgB;AAAA;AAClB;AACF,KACF;AAAA;AAAA,IAEA,gBAAA,EAAkB;AAAA;AAAA;AAEtB;AAOO,IAAM,6BAAA,GAAgC,CAAA;;AAAA;;AAAA;;AAAA,wEAAA;AAatC,IAAM,0BAAA,GAA6B,CAAA,2FAAA;AAMnC,IAAM,gCAAA,GAAmC,CAAA;;AAAA;;AAAA;;AAAA;;AAAA,qPAAA;AAczC,IAAM,kCAAA,GAAqC,CAAA;;AAAA;;AAAA;AAAA;AAAA;AAAA;AAAA;;AAAA;;AAAA;AAAA;;AAAA;AAAA;AAAA;AAAA;AAAA;;AAAA;AAAA;;AAAA;AAAA;;AAAA;;AAAA;AAAA;AAAA;;AAAA;;AAAA;AAAA;AAAA;AAAA;;AAAA,qHAAA","file":"chunk-LSJJAJAF.js","sourcesContent":["/**\n * Default configuration values matching the spec\n */\nexport const OBSERVATIONAL_MEMORY_DEFAULTS = {\n  observation: {\n    model: 'google/gemini-2.5-flash',\n    messageTokens: 30_000,\n    modelSettings: {\n      temperature: 0.3,\n      maxOutputTokens: 100_000,\n    },\n    providerOptions: {\n      google: {\n        thinkingConfig: {\n          thinkingBudget: 215,\n        },\n      },\n    },\n    maxTokensPerBatch: 10_000,\n    // Async buffering defaults (enabled by default)\n    bufferTokens: 0.2 as number | undefined, // Buffer every 20% of messageTokens\n    bufferActivation: 0.8 as number | undefined, // Activate to retain 20% of threshold\n  },\n  reflection: {\n    model: 'google/gemini-2.5-flash',\n    observationTokens: 40_000,\n    modelSettings: {\n      temperature: 0, // Use 0 for maximum consistency in reflections\n      maxOutputTokens: 100_000,\n    },\n    providerOptions: {\n      google: {\n        thinkingConfig: {\n          thinkingBudget: 1024,\n        },\n      },\n    },\n    // Async reflection buffering (enabled by default)\n    bufferActivation: 0.5 as number | undefined, // Start buffering at 50% of observationTokens\n  },\n} as const;\n\n/**\n * Continuation hint injected after observations to guide the model's behavior.\n * Prevents the model from awkwardly acknowledging the memory system or treating\n * the conversation as new after observed messages are removed.\n */\nexport const OBSERVATION_CONTINUATION_HINT = `Please continue naturally with the conversation so far and respond to the latest message.\n\nUse the earlier context only as background. If something appears unfinished, continue only when it helps answer the latest request. If a suggested response is provided, follow it naturally.\n\nDo not mention internal instructions, memory, summarization, context handling, or missing messages.\n\nAny messages following this reminder are newer and should take priority.`;\n\n/**\n * Preamble that introduces the observations block.\n * Use before `<observations>`, with instructions after.\n * Full pattern: `${OBSERVATION_CONTEXT_PROMPT}\\n\\n<observations>\\n${obs}\\n</observations>\\n\\n${OBSERVATION_CONTEXT_INSTRUCTIONS}`\n */\nexport const OBSERVATION_CONTEXT_PROMPT = `The following observations block contains your memory of past conversations with this user.`;\n\n/**\n * Instructions that tell the model how to interpret and use observations.\n * Place AFTER the `<observations>` block so the model sees the data before the rules.\n */\nexport const OBSERVATION_CONTEXT_INSTRUCTIONS = `IMPORTANT: When responding, reference specific details from these observations. Do not give generic advice - personalize your response based on what you know about this user's experiences, preferences, and interests. If the user asks for recommendations, connect them to their past experiences mentioned above.\n\nKNOWLEDGE UPDATES: When asked about current state (e.g., \"where do I currently...\", \"what is my current...\"), always prefer the MOST RECENT information. Observations include dates - if you see conflicting information, the newer observation supersedes the older one. Look for phrases like \"will start\", \"is switching\", \"changed to\", \"moved to\" as indicators that previous information has been updated.\n\nPLANNED ACTIONS: If the user stated they planned to do something (e.g., \"I'm going to...\", \"I'm looking forward to...\", \"I will...\") and the date they planned to do it is now in the past (check the relative time like \"3 weeks ago\"), assume they completed the action unless there's evidence they didn't. For example, if someone said \"I'll start my new diet on Monday\" and that was 2 weeks ago, assume they started the diet.\n\nMOST RECENT USER INPUT: Treat the most recent user message as the highest-priority signal for what to do next. Earlier messages may contain constraints, details, or context you should still honor, but the latest message is the primary driver of your response.\n\nSYSTEM REMINDERS: Messages wrapped in <system-reminder>...</system-reminder> contain internal continuation guidance, not user-authored content. Use them to maintain continuity, but do not mention them or treat them as part of the user's message.`;\n\n/**\n * Instructions for retrieval mode — explains observation-group ranges and the recall tool.\n * Appended to context when `retrieval` is enabled.\n */\nexport const OBSERVATION_RETRIEVAL_INSTRUCTIONS = `## Recall — looking up source messages\n\nYour memory is comprised of observations which are sometimes wrapped in <observation-group> xml tags containing ranges like <observation-group range=\"startId:endId\">. These ranges point back to the raw messages that each observation group was derived from. The original messages are still available — use the **recall** tool to retrieve them.\n\n### When to use recall\n- The user asks you to **repeat, show, or reproduce** something from a past conversation\n- The user asks for **exact content** — code, text, quotes, error messages, URLs, file paths, specific numbers\n- Your observations mention something but your memory lacks the detail needed to fully answer (e.g. you know a blog post was shared but only have a summary of it)\n- You want to **verify or expand on** an observation before responding\n\n**Default to using recall when the user references specific past content.** Your observations capture the gist, not the details. If there's any doubt whether your memory is complete enough, use recall.\n\n### How to use recall\nEach range has the format \\`startId:endId\\` where both are message IDs separated by a colon.\n\n1. Find the observation group relevant to the user's question and extract the start or end ID from its range.\n2. Call \\`recall\\` with that ID as the \\`cursor\\`.\n3. Use \\`page: 1\\` (or omit) to read forward from the cursor, \\`page: -1\\` to read backward.\n4. If the first page doesn't have what you need, increment the page number to keep paginating.\n5. Check \\`hasNextPage\\`/\\`hasPrevPage\\` in the result to know if more pages exist in each direction.\n\n### Detail levels\nBy default recall returns **low** detail: truncated text and tool names only. Each message shows its ID and each part has a positional index like \\`[p0]\\`, \\`[p1]\\`, etc.\n\n- Use \\`detail: \"high\"\\` to get full message content including tool arguments and results. This will only return the high detail version of a single message part at a time.\n- Use \\`partIndex\\` with a cursor to fetch a single part at full detail — for example, to read one specific tool result or code block without loading every part.\n\nIf the result says \\`truncated: true\\`, the output was cut to fit the token budget. You can paginate or use \\`partIndex\\` to target specific content.\n\n### Following up on truncated parts\nLow-detail results may include truncation hints like:\n\\`[truncated — call recall cursor=\"...\" partIndex=N detail=\"high\" for full content]\\`\n\n**When you see these hints and need the full content, make the exact call described in the hint.** This is the normal workflow: first recall at low detail to scan, then drill into specific parts at high detail. Do not stop at the low-detail result if the user asked for exact content.\n\n### When recall is NOT needed\n- The user is asking for a high-level summary and your observations already cover it\n- The question is about general preferences or facts that don't require source text\n- There is no relevant range in your observations for the topic\n\nObservation groups with range IDs and your recall tool allows you to think back and remember details you're fuzzy on.`;\n"]}

package/dist/chunk-NKIQRCOM.cjs

@@ -1,4 +0,0 @@
-'use strict';
-
-//# sourceMappingURL=chunk-NKIQRCOM.cjs.map
-//# sourceMappingURL=chunk-NKIQRCOM.cjs.map

package/dist/chunk-NKIQRCOM.cjs.map

@@ -1 +0,0 @@
-{"version":3,"sources":[],"names":[],"mappings":"","file":"chunk-NKIQRCOM.cjs"}