files-app becomes url-state: the file browser is where the work happened, but where selection lives and who clears a query string are framework questions. The panel framework's version of the same question moves in beside them, extracted from the deep-read item, which keeps it as one of its three questions. Item ids changed with the theme. Done now deliberately — no board reads them yet, and this is the last cheap moment to move one. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1.4 KiB
id, title, theme, status, created, date_source, order
| id | title | theme | status | created | date_source | order |
|---|---|---|---|---|---|---|
| workspaces-panels/a-deep-read-of-the-whole-framework-to | A deep read of the whole framework, to understand it and then improve it | workspaces-panels | open | 2026-08-20 | assumed | 1 |
A deep read of the whole framework, to understand it and then improve it. Low priority and
explicitly not pain-driven — it works, and it works well. But it was built fast and then added to,
repeatedly, and nobody has since sat down and read the whole thing at once.
Three questions to answer rather than assume: can the query strings come out of the flow; is there
a better shape for panel-to-panel communication than the current channel/URL split; and what does
the layout tree cost that a simpler one would not.
The first of those now has its own item, url-state/can-the-query-strings-come-out-of-the-flow,
filed with the file browser's work on the same question — that is where it has been thought about
hardest. It stays part of this read; it is not a separate effort.
Fold the existing panel items into this — the silent key/appType mismatch, the destructive
layout migration on a renamed key, and docs/workspace-panel-todo.md. They are symptoms of the
same unexamined design, and fixing them one at a time is how it stays unexamined.
Also a teaching exercise: the owner wants to understand it end to end, which is a reason to do it
properly rather than quickly.