Summary
The /memory dashboard renders each tag's count in two places: a text bar-chart block and the inline keyboard buttons immediately below. The text rows duplicate what the buttons already show, so the dashboard is roughly twice as tall as it needs to be without giving the user any data they couldn't read off the buttons.
Current behavior
Memories: 73 facts across 8 tags.
project 18 ▓▓▓▓▓▓▓▓
fact 16 ▓▓▓▓▓▓▓
preference 15 ▓▓▓▓▓▓▓
constraint 10 ▓▓▓▓
decision 9 ▓▓▓▓
location 3 ▓
confirmed_action 1 ▓
relationship 1 ▓
Tap a tag to browse. Confidence: median 0.86, min 0.52.
[project (18)] [fact (16)] [preference (15)] [constraint (10)] ...
[Search] [Stats]
The counts in the bar-chart rows (18, 16, 15, ...) are the same counts shown in the button labels ((18), (16), (15), ...).
Proposed change
Drop the per-tag text rows. Keep the summary line, the confidence footer, and the inline keyboard exactly as they are.
Memories: 73 facts across 8 tags.
Tap a tag to browse. Confidence: median 0.86, min 0.52.
[project (18)] [fact (16)] [preference (15)] [constraint (10)] ...
[Search] [Stats]
Tradeoff
We lose the visual bar chart, which gave at-a-glance relative magnitude. The button labels still carry the counts in parentheses so the relative magnitudes remain readable; only the bar visualization itself is gone. Telegram's inline buttons are short text only, so there is no equivalent surface for the bars - they exist purely because the buttons can't render them.
Cleanup
_bar, _BAR_CHAR, and _BAR_WIDTH in memory_command.py become unused once the rows are gone. Their tests in TestBar (test_zero_count_empty_bar, test_max_count_full_width, test_nonzero_min_one_block) become unnecessary. The test_renders_summary_and_tags test asserts the order of tag rows in the dashboard text - it needs to be reworked to assert the order of buttons instead.
Spec drift
Spec 310 §6.1 specified the bar-chart block as part of the dashboard mock-up. This issue intentionally diverges from that part of the spec based on operator feedback during real use. The other §6.1 elements (summary header, confidence footer, asymmetry between dashboard and stats around zero-count tags) are unchanged.
Related
Summary
The
/memorydashboard renders each tag's count in two places: a text bar-chart block and the inline keyboard buttons immediately below. The text rows duplicate what the buttons already show, so the dashboard is roughly twice as tall as it needs to be without giving the user any data they couldn't read off the buttons.Current behavior
The counts in the bar-chart rows (
18,16,15, ...) are the same counts shown in the button labels ((18),(16),(15), ...).Proposed change
Drop the per-tag text rows. Keep the summary line, the confidence footer, and the inline keyboard exactly as they are.
Tradeoff
We lose the visual bar chart, which gave at-a-glance relative magnitude. The button labels still carry the counts in parentheses so the relative magnitudes remain readable; only the bar visualization itself is gone. Telegram's inline buttons are short text only, so there is no equivalent surface for the bars - they exist purely because the buttons can't render them.
Cleanup
_bar,_BAR_CHAR, and_BAR_WIDTHinmemory_command.pybecome unused once the rows are gone. Their tests inTestBar(test_zero_count_empty_bar,test_max_count_full_width,test_nonzero_min_one_block) become unnecessary. Thetest_renders_summary_and_tagstest asserts the order of tag rows in the dashboard text - it needs to be reworked to assert the order of buttons instead.Spec drift
Spec 310 §6.1 specified the bar-chart block as part of the dashboard mock-up. This issue intentionally diverges from that part of the spec based on operator feedback during real use. The other §6.1 elements (summary header, confidence footer, asymmetry between dashboard and stats around zero-count tags) are unchanged.
Related