A code drawer that knows why a file is the way it is

The honest starting point: an in-app code viewer next to the terminal grid is a convenience, not a moat. Cursor does it better as an editor. The only thing that makes a code surface inside Talkak worth building is the one thing a generic viewer structurally cannot do — connect the code to your own operating memory.

What shipped

Two layers, on feat/code-panel-extras:

The viewer grew up. Files are now editable inline with ⌘S save (confined to the granted repo root), the diff/file view got a toolbar (Quick Review · Save · open in Cursor · View), and the drawer takes over a set of shortcuts while it's open — ⌘⇧F Files, ⌘⇧C Changes, ⌘⇧V View, ⌘S Save — releasing them back to the app the moment you close it. Same override pattern as ⌘P. macOS-reserved chords (⌘F/⌘C/⌘V) were never on the table.
"📜 이 파일의 사연" — the file's backstory. Open a file and a thin strip above the editor shows the operating-memory nodes that mention it: the past decisions, the bug post-mortems, the commits that changed it, the open work items. git blame tells you who and when; this tells you why. Click a chip to expand the node body.

The part I'm proud of: zero new infrastructure

The backstory strip is a single new Tauri command, memory_file_history. It reuses a pure function that already existed — query_nodes — to match the file's path (then its basename) against the graph, scoped to the service and filtered through the same supersede-aware read path every other retrieval surface uses. No new index, no new store, no new model call. The operating memory was already there; the code drawer just learned to ask it.

The honest caveats

It only shines where memory has accumulated. Talkak's own repo has thousands of nodes; a brand-new repo shows an empty strip — and it should, gracefully, rather than inventing history.
Whether path↔node matching surfaces genuinely useful nodes consistently is unproven. That's a dogfooding question, not a claim.

Compile-verified (cargo check and tsc both clean) and launched in an isolated dev build; the runtime behavior is for me to confirm by using it.