pastilhasandClaude Fable 5
6071ded175
TODO.md had reached 1050 lines and 72 open items across 28 sections, read mostly on a phone. It is now a directory: todo/<theme>/<item>.md, one card per file, with frontmatter carrying id, status, created date and order, and the prose body copied across verbatim. TODO.md becomes a generated index (bun run todo:index). Dates: where an item's prose stated one it is used; otherwise its old section's; otherwise 2026-08-20, floored at the day before the split rather than invented. date_source records which. Shaped for a two-way Kanban board, filed as todo/tooling — a card is a file, id is the identity, frontmatter is the machine's half and the body is the owner's. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2.1 KiB
id, title, theme, status, created, date_source, order
| id | title | theme | status | created | date_source | order |
|---|---|---|---|---|---|---|
| code-editor/the-owner-wants-to-go-deeper-here-ideas | The owner wants to go deeper here — ideas pending (noted 2026-08-15) | code-editor | open | 2026-08-15 | stated | 1 |
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.