Symptom
While searching, some rows show an extra grey line that reads like a second copy of the first-user-message line — but with unfamiliar content and a #N prefix:
git 43 msgs 33d ago
/effort max → 可 retry 了
⌕ #3 我想請你幫我 study 看有什麼不錯的辦法可以用我們公司 Fireflies 內部員工其 staging/productio…
Reported by the author while testing PR #137, having forgotten what the line was — and reading the leading glyph as • and then ρ.
It is not a bug — it is the matched-prompt snippet from PR #132
That line is the ⌕ #N …context… snippet: when a search hit lands in a middle prompt, which the row never displays, this line shows why the row matched. #3 is the prompt index (the 3rd thing you typed in that session). It is gated on an active search, which is why it only appears while searching.
Working exactly as designed. The defect is that it does not look like what it is.
The actual defect: it is visually indistinguishable from the first-message line
| Row line |
Colour |
Size |
| first user message |
#999 |
12px |
⌕ matched snippet |
#999 |
11px |
| last user message |
#c89030 |
12px |
| last assistant reply |
#9DC8E0 |
11px |
The snippet is the same grey as the first-message line, one pixel smaller. Every other line in the row has its own colour and its own leading marker (→, ◀), so the snippet is the only one that reads as a duplicate of a neighbour rather than as its own kind of information.
Two contributing problems:
- Colour collision —
#999 is already spoken for by the first-message line, so the eye files the snippet under "another first message".
- The
⌕ glyph is illegible at 11px — U+2315 renders as a small circle with a tail; it was read as • and as ρ in the same session. It carries the whole "this is a search hit" signal and cannot be read.
Suggested fix
Give the snippet line its own visual identity, in the same pass as the other row-readability work:
- a distinct colour that is not the first-message grey (it is a search affordance, so the amber of
SEARCH_HIGHLIGHT_STYLE is the natural family)
- a legible marker — a plain
🔍, or the word match, or ⌕ at a size where it resolves
- consider showing which field matched once the search covers title/branch too (
⌕ title: / ⌕ #3), since a snippet with no field label cannot say where the hit came from
Notes
🤖 On behalf of @grimmerk — generated with Claude Code
Symptom
While searching, some rows show an extra grey line that reads like a second copy of the first-user-message line — but with unfamiliar content and a
#Nprefix:Reported by the author while testing PR #137, having forgotten what the line was — and reading the leading glyph as
•and thenρ.It is not a bug — it is the matched-prompt snippet from PR #132
That line is the
⌕ #N …context…snippet: when a search hit lands in a middle prompt, which the row never displays, this line shows why the row matched.#3is the prompt index (the 3rd thing you typed in that session). It is gated on an active search, which is why it only appears while searching.Working exactly as designed. The defect is that it does not look like what it is.
The actual defect: it is visually indistinguishable from the first-message line
#999⌕matched snippet#999#c89030#9DC8E0The snippet is the same grey as the first-message line, one pixel smaller. Every other line in the row has its own colour and its own leading marker (
→,◀), so the snippet is the only one that reads as a duplicate of a neighbour rather than as its own kind of information.Two contributing problems:
#999is already spoken for by the first-message line, so the eye files the snippet under "another first message".⌕glyph is illegible at 11px — U+2315 renders as a small circle with a tail; it was read as•and asρin the same session. It carries the whole "this is a search hit" signal and cannot be read.Suggested fix
Give the snippet line its own visual identity, in the same pass as the other row-readability work:
SEARCH_HIGHLIGHT_STYLEis the natural family)🔍, or the wordmatch, or⌕at a size where it resolves⌕ title:/⌕ #3), since a snippet with no field label cannot say where the hit came fromNotes
docs/session-finding-plan.md§4.5), which is already reworking the same lines for the truncation and highlight-window problems.🤖 On behalf of @grimmerk — generated with Claude Code