todo: the code editor, and what is known about it before going deeper

Recorded so it survives a context reset rather than living in a chat message.
The useful part is not the request, it is the four things established today:
the screen has been unreachable for six months and so has no users, nothing
about it has been verified beyond the URL plumbing, an empty-file editing bug of
exactly the expected kind was already found next door, and whether 'Open in
editor' should still exist is genuinely undecided.

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

TODO.md

@@ -254,6 +254,35 @@ write**, orphaning a pty per reload; Running Shells has **404'd since 2026-07-31
 error boundaries** anywhere in the repo; and `dashboards.id` is a **global** primary key fed by
 `slugify(name)`, so two members naming a dashboard the same thing collide.
 
+## Code editor
+
+- [ ] **The owner wants to go deeper here — ideas pending (noted 2026-08-15).** Raised right after the file
+      browser gained its first links into `/code-editor`. Do this after the file-browser test pass.
+
+      What is worth knowing before starting, all established on 2026-08-15:
+
+      **It has been effectively invisible for six months.** The app landed 2026-02-21 (`9e9acd96`), the
+      screen 2026-02-17, and `1fa3a659` on 2026-07-25 is titled "**restore** the code editor screen" — so
+      it was dropped and brought back at least once. It IS in `CORE_DOCK_ITEMS` as "Editor", but
+      `DEFAULT_DOCK_PATHS` is `['/', '/files', '/terminal', '/dashboards', '/chat']` and the owner's own
+      `dock_configs` row does not list it either. Until today the only way in was typing the URL.
+
+      **So it has no users, and that is the risk.** A surface nobody reached for six months is where things
+      rot quietly. Nothing about the editor itself has been verified — whether saving works, how the file
+      tree behaves, what closing the last tab does, what an unsaved-changes navigation does. Only the
+      plumbing was checked: `?file=` is read (`EDITOR_FILE_PARAM`), `/code-editor` renders with `urlState`,
+      and `CodeEditor.tsx:60-76` fetches a path that arrives in the URL rather than only matching already
+      open tabs.
+
+      **One bug of exactly this kind was already found and fixed** in the FileViewer's editor on the same
+      day: the Edit toggle was gated on `content` rather than `content !== null`, so an empty file — the
+      one "New file" produces — could not be edited at all. Assume siblings.
+
+      **Open question, deliberately not decided:** `Open in editor` in the file browser's row menu still
+      navigates to `/code-editor`, which is the last action that leaves the browser. Editing now happens
+      in place via double-click → the viewer's pane. Either `/code-editor` earns its keep as a genuinely
+      different tool (tree, tabs, multi-file) or that menu item should go.
+
 ## Known bugs
 
 - [ ] **`bootstrap.ts` runs `npm install -g` for Pi on every boot.** `findPiPackageDir` checks stale