Context
PR #653 added chunk_progress SSE events to the indexing stream and surfaced them in the Index tab as file.md — 100/250 chunks. The Sources → Memory Dirs reindex flow consumes the same stream (sources-memory-dirs.js mdReindexOne, line 1093-1177), but PR #653 deliberately left it untouched because the per-button text already reads 5/12 and adding 5/12 — 100/250 would crowd or wrap the button.
This issue tracks the design-and-implement work for chunk-level visibility in that flow.
Why this needs design, not just code
The Memory Dirs button is a small, fixed-width control inside a row of vendor cards. Naive concatenation breaks the layout. Options that need a decision:
- Two-line button — file count on top, chunk count below. Costs vertical space across the entire dirs list.
- Tooltip / aria-label — hover/focus shows
5/12 files, 100/250 chunks. Keeps button text untouched but accessibility-only.
- Replace button text mid-flight — show only
100/250 chunks while a single file is in-flight, snap back to N/M once the file completes. Most informative but visually noisy.
- Inline progress bar under the button — full bar like the Index tab. Most consistent UX but the largest layout change.
Acceptance criteria
- During a Memory Dirs reindex, the user can see per-chunk progress for the file currently being embedded — no requirement on the exact form.
- Existing
5/12 file counter behavior preserved (or knowingly replaced).
- Layout does not wrap or shift adjacent dirs cards on any of: 1280px, 1024px, narrow mobile.
- Throttle (~100ms) and final-tick (
done == total) bypass match the Index tab's behavior — copy/paste from app.js:runIndexStream is fine.
- No new SSE event types needed; consume the existing
chunk_progress event from the stream.
Files likely touched
packages/memtomem/src/memtomem/web/static/sources-memory-dirs.js (mdReindexOne, line 1093-1177)
packages/memtomem/src/memtomem/web/static/style.css (if option 1 or 4)
packages/memtomem/src/memtomem/web/static/locales/en.json + ko.json (new label key)
References
Context
PR #653 added
chunk_progressSSE events to the indexing stream and surfaced them in the Index tab asfile.md — 100/250 chunks. The Sources → Memory Dirs reindex flow consumes the same stream (sources-memory-dirs.jsmdReindexOne, line 1093-1177), but PR #653 deliberately left it untouched because the per-button text already reads5/12and adding5/12 — 100/250would crowd or wrap the button.This issue tracks the design-and-implement work for chunk-level visibility in that flow.
Why this needs design, not just code
The Memory Dirs button is a small, fixed-width control inside a row of vendor cards. Naive concatenation breaks the layout. Options that need a decision:
5/12 files, 100/250 chunks. Keeps button text untouched but accessibility-only.100/250 chunkswhile a single file is in-flight, snap back toN/Monce the file completes. Most informative but visually noisy.Acceptance criteria
5/12file counter behavior preserved (or knowingly replaced).done == total) bypass match the Index tab's behavior — copy/paste fromapp.js:runIndexStreamis fine.chunk_progressevent from the stream.Files likely touched
packages/memtomem/src/memtomem/web/static/sources-memory-dirs.js(mdReindexOne, line 1093-1177)packages/memtomem/src/memtomem/web/static/style.css(if option 1 or 4)packages/memtomem/src/memtomem/web/static/locales/en.json+ko.json(new label key)References
feedback_layout_primitives_first.mdpattern — check existing.dir-button/.reindex-btnoverflow rules before adding new CSS.