Skip to content

Name both speakers so memories don't quote raw ids - #6

Merged
dani1005 merged 1 commit into
mainfrom
fix/speaker-name
Oct 15, 2026
Merged

dani1005 merged 1 commit into
mainfrom
fix/speaker-name

Conversation

@dani1005

Copy link
Copy Markdown
Member

Problem

Extraction labels each speaker by sender_name and falls back to sender_id (everalgo boundary/chat.py: speaker = m.sender_name or m.sender_id). We never send a name, so:

  • locally, memories read "default-user said ...";
  • on the HTTP server (OAuth), they quote the user's Supabase account id, e.g. "speaker 57a628c0-0460-... stated a test codeword". That id then flows into recall results and the synthesized profile.

Both EverOS Cloud (MessageItem.sender_name) and self-hosted (memorize.py) accept sender_name.

Change

add_memory and record_trajectory send sender_name = "User" / "Assistant" on user and assistant messages (tool messages unchanged). sender_id is untouched, so ownership and isolation are unaffected.

Tests

New test_add_memory_names_both_speakers; the trajectory test now asserts the names. 92 passed.

🤖 Generated with Claude Code

Extraction labels each speaker by sender_name and falls back to sender_id,
so stored memories read "default-user said ..." locally and, on the HTTP
server, quote the user's opaque account id. Send "User" / "Assistant".

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@dani1005
dani1005 merged commit 3e982cc into main Oct 15, 2026
2 checks passed
@dani1005
dani1005 deleted the fix/speaker-name branch October 15, 2026 21:49
@dani1005 dani1005 mentioned this pull request Oct 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant