Daeseon Yoo
Back to project
·UX retro·2 min

I lost the thread of my own product — so I built the lens, not another store

Mid-session I couldn't remember what I'd been asking for — the exact pain DalkkakAI is supposed to kill. The memory was being captured all along (5,808 nodes); it just wasn't readable. The fix was a read-back lens over memory we already keep, reusing renderers we already had — not a new pipeline.

Halfway through a session I typed, more or less: "I can't even remember what I was asking you for — don't we have a feature that keeps storing this? We do, right? But it's not readable for a human, is it?"

That's the product's own pain, landing on the founder. DalkkakAI's whole premise is an operating memory that remembers your work. And it does — a quick graph_search showed 5,808 nodes for this one workspace. It had even already stored work items complaining about this exact gap ("the Today feed is dev-capture noise," "clicking a memory node is meaningless"). The memory wasn't missing. The reading was.

What already existed (and why none of it fit)

Every session already emits a <dk-summary> card at the end of each turn (a recap / plan / note / question). The viz/ folder already had a beautiful renderer for each kind. But nothing showed the sequence — "this session did A → then B → then C" — and nothing put the sessions side by side so you grasp the whole thing at a glance.

The build: a lens, not a store

The temptation is always to add a new capture pipeline. Wrong move. The data was already there; I just needed to read it back.

SessionFlow.tsx walks each open pane, reads its transcript (LLM-agnostic — Claude or Codex), and peels out every <dk-summary> block. (The stripper hides those from the terminal, but they survive in the transcript file.) Each session becomes a column; each summary becomes a card, in time order. One screen, every session's flow.

The only refactor: the card dispatcher lived privately inside SummaryModal. I lifted it into viz/summaryCard.tsx so the modal and the new flow view render through the same function. No duplicated card logic, no second source of truth.

Verified live: the panel renders, and in the terminal view it shows a column per session (3MNC, ZB5L) with provider and step count. The columns are empty here only because those dev panes never ran a real agent — with a live session, the cards fill in.

The lesson

When the user asks "don't we already have this?", the honest answer is almost always: the data, yes; the human-readable view, no. The reflex to build another store or another capture path is usually the expensive, duplicative mistake. The cheap, correct move is a new read-back lens over the memory you already keep — rendered with the components you already built.

Capture was never the hard part. Legibility was.