Recall EvalOps memory in chat context

[haasonsaas]

Summary

• Recall relevant EvalOps Memory records for the latest user chat message when memory sync is enabled.
• Respect the same per-category toggles for chat, meeting summaries, and journal memories.
• Inject a bounded, deduplicated <evalops_memory> block into the chat system prompt so Kestrel can continue context across machines without mutating local SQLite threads.
• Treat recall failures as non-fatal and continue the local chat flow.

Closes #15.

Validation

• npm run build
• git diff --check

Validation caveat

• Full npm test is still blocked in this clone by the existing local audio duration issue noted on Add durable EvalOps memory sync queue #50/Add EvalOps memory export and wipe controls #51 (audio-data-size.test.mjs reports 0.0s duration despite captured mic buffers and a 158 KB file).

[cursor]

PR Summary

Medium Risk
Modifies chat prompt construction to call EvalOps Memory recall at runtime, which could affect model behavior and adds dependency on external recall responses (though failures are handled as non-fatal).

Overview
Chat prompts now optionally include a bounded <evalops_memory> context block built from EvalOps Memory recall results for the latest non-empty user message.

Adds buildEvalOpsMemoryRecallBlock() to recall top matching chat_thread, meeting_summary, and journal memories (respecting the existing sync toggles), deduplicate/sort by similarity, and truncate snippets before injecting into the system prompt; recall errors/offline responses are ignored so local chat continues.

^{Reviewed by Cursor Bugbot for commit 3ce291e. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is ON, but it could not run because the branch was deleted or merged before autofix could start.}

^{Reviewed by Cursor Bugbot for commit 3ce291e. Configure here.}

[cursor]

Sequential memory recall calls add unnecessary chat latency

Medium Severity

The for loop in buildEvalOpsMemoryRecallBlock makes up to three independent recallEvalOpsMemory HTTP requests sequentially, one per enabled category. Since buildConversation is awaited before runExecutionLoop starts streaming, this serialization directly delays the first token the user sees. Using Promise.allSettled would reduce total latency from the sum of all call durations to the duration of the slowest single call, and would also preserve partial results when one category fails instead of discarding all memories.

Additional Locations (1)

• src/main/ai/presenter-agent.ts#L181-L185

 

^{Reviewed by Cursor Bugbot for commit 3ce291e. Configure here.}