fix(memory): make each row scannable and each button say what it deletes - #49
Merged
Conversation
Three problems visible the moment the panel is opened with real entries. Every row led with a 43-character generated key — `memory_de3f612e-dd95-4b1a-8ca4-5268007fa4d9` — set at the same weight as the timestamp, directly under the content. For someone scanning what the agent remembers it is the least useful thing on the row and takes the most room; the key only matters when addressing the entry from the API or the CLI. That got worse once the gateway started generating keys for entries stored without one. Every delete button was labelled "Forget this memory", so three rows produced three identical accessible names. Nothing distinguished them for a screen reader or for anyone navigating by keyboard. And the count read "Memory entries· 3" — a missing space. - generated keys collapse to a "copy key" control; a key the agent chose, like `user_lang`, is a name and still reads as one - the timestamp leads, since that is what people actually scan by - delete buttons name the memory they remove - clipboard failure outside a secure context shows the key instead of failing silently, so it can still be selected by hand Verified against the running console with a browser, not by reading the JSX.
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
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.
Found by opening the console in a browser against a live gateway with real entries — not by reading the component.
Problems
The generated key dominated every row.
43 characters of UUID, set at the same weight as the timestamp, directly under the content. For someone scanning what the agent remembers it is the least useful thing on the row and takes the most room — the key only matters when addressing the entry from the API or the CLI. This got worse once the gateway began generating keys for entries stored without one; before that, keys came from the agent and were short names like
user_lang.Every delete button had the same accessible name. Three entries produced three buttons all reading
Forget this memory. Nothing distinguished them for a screen reader or for anyone tabbing through.The count read
Memory entries· 3— a missing space.Change
copy keycontrol. A key the agent chose —user_lang— is a name, and still reads as one.Forget "Staging credentials rotate weekly on Mondays".Verification
Driven in a real browser against a running gateway. Accessibility tree after the change:
One thing worth recording: the first attempt at verifying this looked at a stale build. The old dev server still held port 3120, so the new instance failed with
EADDRINUSEwhile the old one kept serving — and a screenshot at that moment would have shown the unchanged panel and been reported as verified. Killing by port rather than by remembered PID is what caught it.Risk and rollback
Low — presentation only.
git revertrestores the previous row layout and labels.