todo: background job logs appeared inside an open file in the editor

Reported on the production host, as a member, with a `bun dev` job streaming: the
runner's output rendered into the buffer of a file open in the code editor. The
file on disk was intact and nothing was saved, so it is a display-layer mixing
rather than a write path.

Not reproduced and not diagnosed — logged with the two places the streams can
meet (`CodeSurface` is shared between the task panel and the editor; the editor
keys by path while panel stores key by panelId through useGlobal/usePanelMemory)
and a first move that distinguishes them: whether the buffer is polluted or only
the render is, which Cmd+S and a tab reopen answer immediately.

Recorded rather than guessed at further. An editor that can show content the file
does not contain is a correctness problem even when it never writes, because the
instinct on seeing it is to save.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

TODO.md

@@ -324,6 +324,33 @@ pane belonging to the folder you left; and the breadcrumb opted out of that last
 
 ## Known bugs
 
+- [ ] **Background job logs appeared INSIDE an open file in the code editor.** Reported 2026-08-16 by the
+      owner, on the production host, running as a member with a `bun dev` background job streaming. The
+      editor had a file open; the runner's log output was rendered into that file's buffer. **It was never
+      saved** — the file on disk was intact, and the editor was not marked dirty as far as the report goes.
+      So this is a DISPLAY-layer mixing, not a write path: the bytes reached a buffer that only exists in
+      the browser.
+
+      Not reproduced, not diagnosed, and deliberately not guessed at further than this. What is worth
+      recording is where the two streams could meet, because both were added in the same week and they are
+      the only two things writing text into a panel:
+
+      - `useTaskDetail` polls `GET /chat/tasks/:id` every 2s while a job runs and returns `{kind:'log', text}`.
+        `CodeSurface` renders it — and `CodeSurface` is shared with the editor's own surfaces.
+      - The editor keys open files by PATH (`useEditorState`), while the task panel keys by TASK ID, and
+        several panel-scoped stores in between are keyed by `panelId` through `useGlobal` /
+        `usePanelMemory`. A key collision between those namespaces would produce exactly this: one panel's
+        text arriving in another's buffer, with no server involvement and nothing persisted.
+
+      First moves, in order: reproduce with a job whose output is distinctive (`seq 1 100000`), then check
+      whether the editor's content state or only its RENDER is affected — `Cmd+S` at that moment answers it,
+      as does closing and reopening the tab. If the buffer really is clean and only the view is wrong, the
+      suspect is a shared component instance; if the buffer is polluted, it is a key collision.
+
+      Worth noting because it is the reason to look at all: an editor that can show content the file does
+      not contain is a correctness problem even when it never writes — the next person's instinct will be to
+      save the file to "fix" it.
+
 - [ ] **`bootstrap.ts` runs `npm install -g` for Pi on every boot.** `findPiPackageDir` checks stale
       paths and an outdated package name, so `installPi` always fires and floods the logs with
       `EEXIST` noise. Should detect `@earendil-works/pi-coding-agent` at the real npm prefix.