feat(memory): add dedicated memory management panel in settings#288
Merged
Conversation
Kun's runtime already had a complete memory store (FileMemoryStore + HTTP routes /v1/memory + agent-loop injection + 3 tools), but the GUI only exposed a read-only, truncated-to-8 view buried inside the Agents section. This adds a first-class Memory section to Settings with full CRUD: create, edit content/tags/confidence, disable, delete, plus diagnostics (active count, tombstone count, enabled state, last injected IDs) and a scope filter (all/user/workspace/project). - Frontend only; no runtime/kun changes. - Added createMemory + getMemoryDiagnostics to the AgentProvider interface and KunRuntimeProvider (POST route already existed). - New SettingsSidebar entry (BrainCircuit icon). - 30 i18n keys added to en/zh settings.json. - The existing read-only memory block in Agents section is left intact for backward compatibility.
whitelonng
force-pushed
the
feat/memory-gui
branch
from
123014f to
f8ec462
Compare
Two UX fixes from manual testing: 1. When create/update fails (e.g. memory capability disabled in runtime), the editor no longer closes and discards the user's draft. The handler now returns boolean success; the editor only closes on success. 2. When memory is disabled (memoryDiagnostics.enabled === false), an amber warning banner appears above the record list explaining that memory must be enabled in runtime config before records can be created. Previously the user could click 'New', fill in content, hit Save, and see nothing happen with no feedback.
Previously memory could only be enabled by manually editing the Kun config file — there was no GUI control. The Memory settings page showed 'Status: Off' but offered no way to turn it on, so users couldn't create or use memory records without finding the hidden runtime config. This adds: - memoryEnabled boolean to KunRuntimeSettingsV1 (default: false) - resolveKunMemoryEnabled + mergeKunRuntimeSettings support - kun-process writes capabilities.memory.enabled from the GUI setting - A Toggle at the top of the Memory settings section - i18n keys (en/zh)
The settings:set IPC payload is validated with a strict zod schema that rejects unknown keys. Adding memoryEnabled to KunRuntimeSettingsV1 without also adding it to kunRuntimePatchSchema caused every settings save to fail with 'Invalid payload for setting' — even on first load, because the auto-apply feature saves immediately on any field change.
…rieval
The memory retrieve path gated every record behind keyword-overlap scoring.
This caused three independent failures:
1. Semantic identity queries ("who am I?", "你知道我是谁吗") never matched
user memories because the query shares zero keyword/n-gram overlap with
the stored content (e.g. "whitelonng"). The LLM only saw the memory when
the user explicitly typed a keyword like "用户记忆". User-scope memories
are now injected unconditionally — they are small, high-value identity
facts that semantic prompts must surface. Workspace/project memories keep
the scored retrieval path.
2. scoreMemory split the query on [^a-z0-9_]+, which treats every CJK
character as a separator and produced an empty token set for Chinese
queries — workspace/project memories in Chinese were never retrieved.
Replaced with language-agnostic n-gram fingerprinting (trigrams for
ASCII words, bigrams for CJK runs), no tokenizer dependency.
3. inScope required an exact workspace match for workspace-scope records,
but the GUI creates memories without a workspace field, so they were
silently filtered out. A missing workspace now matches any request.
Also document the memory tools in the system prompt so the LLM proactively
persists durable facts via memory_create/update/delete instead of waiting
for an explicit instruction.
Adds regression tests for CJK retrieval, workspace-less workspace memories,
and semantic-query user-memory injection.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a first-class Memory management panel to Settings, giving users full CRUD over the assistant's long-term memory records.
Screenshots
Settings entry — the Memory item sits in the Settings sidebar:
Management panel — overview stats + full record list with CRUD:
Create memory — editor with content, scope, tags, confidence:
Scope dropdown — user / workspace / project:
Memory in action — user memories injected into the chat + LLM proactively calling
memory_create:Background
Kun's runtime already had a complete memory subsystem —
FileMemoryStore, HTTP routes (GET/POST/PATCH/DELETE /v1/memory+/v1/memory/diagnostics), automatic injection into the agent loop, andmemory_create/update/deletetools. But the GUI only exposed a read-only, truncated-to-8 view buried inside the Agents settings section. Users had no way to create, edit, or audit memories from the UI.What's new
A dedicated Memory entry in the Settings sidebar (BrainCircuit icon) with:
/v1/memory/diagnosticsChanges
Frontend (GUI panel):
kun-runtime.ts,types.tscreateMemory+getMemoryDiagnosticstoAgentProviderinterface andKunRuntimeProvider(POST route already existed in runtime)settings-section-memory.tsx(new)settings-sections.tsx,SettingsView.tsx,SettingsSidebar.tsx,use-settings-gui-update.tsmemorycategorySettingsView.tsxcreateMemoryRecord,updateMemoryRecord,refreshMemoryDiagnosticslocales/{en,zh}/settings.jsonRuntime (memory retrieval fixes):
kun/src/memory/memory-store.ts[^a-z0-9_]+, treating every Chinese char as a separator); workspace-scope memories with noworkspacefield now retrievablekun/src/prompt/kun-system-prompt.tsmemory_create/update/deletetools so the LLM proactively persists durable factskun/tests/memory-store.test.tsMemory retrieval bug — root cause
The retrieve path gated every record behind keyword-overlap scoring. This broke memory injection in three ways:
whitelonngshares zero keyword/n-gram overlap →score=0→ filtered out → not injected. The LLM only saw it when the user typed an explicit keyword like "用户记忆". User memories are now injected unconditionally — they are small, high-value identity facts.scoreMemorysplit the query on[^a-z0-9_]+, which treats every Chinese character as a separator and produced an empty token set for Chinese queries.inScoperequired an exactworkspacematch, but the GUI creates memories without one.Backward compatibility
The existing read-only memory block in the Agents settings section is left intact — it still shows the first 8 records with disable/delete buttons. The new Memory section is additive. Workspace/project memories keep the scored retrieval path.
Verification
npm run typecheckpassesnpm run lint— 0 errors (9 pre-existing warnings unchanged)npx vitest run src/renderer/src/components— 257/257 passednpx vitest run tests/memory-store.test.ts— 8/8 passed (kun runtime)npx tsc --noEmit(kun) — cleantests/loop.test.ts— 3 pre-existing failures confirmed unchanged viagit stash(unrelated to this change)memory_create(see screenshots)Notes