fix(frontend): keep unsaved memory edits when a memory is added

[dovvnloading]

The problem

Edit a memory row, then add a new memory, and the edit reverts — silently, with nothing to undo it.

Memory 2: "Second"  ->  user types "Edited"  ->  adds "Third"  ->  Memory 2 is "Second" again

Root cause

The draft list is re-seeded from the server whenever the server's answer changes:

if (!changed) return;
lastServerMemos.current = memos;
setDraft(memos.map((value, id) => ({ id, value })));   // wholesale replace

That effect exists for a good reason — #241 added it so a row the server normalized away (trimmed to nothing, a case-insensitive duplicate) stops sitting on screen looking saved. The mistake is that it replaces rather than reconciles.

Adding a memory also changes the server's answer. So the add succeeds, memos changes, the effect fires, and every other row the user had edited and not yet saved is overwritten with the server's copy.

The comment above it claimed the opposite:

Re-seed whenever the server's answer actually changes, which leaves in-progress edits alone between saves.

That only held while nothing else changed the list — which an add always does.

The fix

Each row now remembers the server value it was seeded from, and a changed server list carries every surviving row's in-progress value across by matching on that origin:

const existing = byOrigin.get(value)?.shift();
return existing ? { ...existing, origin: value } : { id: nextId++, value, origin: value };

Matching on origin rather than current value is the whole point: an edited row no longer equals its server value, and that is precisely the row being preserved. shift() so duplicate server values claim distinct rows rather than aliasing onto one.

Both behaviours are pinned, including together

The risk with a fix like this is satisfying it by simply preferring the draft — which would put #241's bug straight back. So one of the new tests exercises both directions in the same update: a normalized-away row is dropped at the same moment an edit to a surviving row is kept.

Test	Before	After
unsaved edit survives an add	✗	✓
normalized-away row dropped and edit to surviving row kept	✗	✓
drops rows the server normalized away (existing, #241)	✓	✓

Both new tests fail against the unfixed component; the existing #241 test passes throughout.

Check	Result
npm test -- --run	270 passed, 31 files
npm run typecheck	clean
npm run lint	clean
python -m pytest -q	907 passed

Compatibility and rollback

One component's local state. No API contract, stored data, or migration. A list that has not changed still skips the effect entirely, exactly as before. Reverting the commit restores the previous behaviour exactly.

Limits

A row the user deleted locally but has not saved is still restored when the server list changes, since the server still has it. That is pre-existing and arguably correct — the deletion is not committed until "Save changes" — but it is the same class of question as the edit case, and worth revisiting if it bites.

Reconciliation matches on value, so if the server reorders two memories the rows follow the server's order rather than the screen's. With a set-like list whose order comes from the server, that is the intended outcome.

🤖 Generated with Claude Code