[codex] Add modular overview workspace layout

TODO.md

@@ -296,6 +296,19 @@ and [docs/plan/04-desktop-ui.md](docs/plan/04-desktop-ui.md).
 - [x] Overview screen now uses `@shadcnblocks/dashboard5` as the first
   dashboard screen, keeping Export -> Reports, Add connection modal, and
   Show all transactions wiring
+- [x] Add the first configurable page workspace foundation to Overview:
+  draggable/resizable page widgets, snap-grid constraints, collision handling,
+  z-order focus, reset-to-default, a widget palette with real and placeholder
+  modules, and local per-book/page persistence
+- [ ] Prove configurable workspaces with one concrete workflow before expanding
+  beyond Overview. Candidate proof points: transaction cleanup workspace with
+  table/detail/filter/review-queue modules, or tax review workspace with
+  blockers, journal freshness, E 1kv preview, and export status. Keep the
+  long-term UX bar explicit: workflow presets, small page-specific widget
+  catalogs, reset/restore safety, no controls outside edit mode, no tiny or
+  overlapping widgets, keyboard/tile controls, and consistent behavior across
+  pages. If the only gain is movable dashboard cards, do not expand the
+  pattern.
 - [x] Transactions screen now uses `@shadcnblocks/dashboard2` as the
   transaction dashboard, with ordered period controls, enlarged search copy,
   and privacy visibility toggle in the header

docs/plan/04-desktop-ui.md

@@ -75,6 +75,54 @@ malicious page could appear there.
   browser, Claude in Chrome, Claude Preview MCP, and any future
   AI-driven browser tool. See section 2.7 below for the concrete setup.
 
+### Main pages can become configurable workspaces
+
+The desktop shell should keep excellent defaults while letting serious users
+shape each main page into the workstation they need. The first implementation
+scope is per-page and additive: Overview exposes its current dashboard sections
+as page-level widgets with snap-grid movement, edge/corner resizing,
+collision handling, z-order focus, reset-to-default, and a widget palette that
+can also show planned modules. Layouts are local UI preferences keyed by the
+current book identity plus page id, so a tax-review book can have a different
+Overview layout than a wallet-monitoring book without changing accounting data
+or daemon contracts.
+
+Do not make card internals draggable. The configurable boundary is the
+page-level module frame; reports, tables, charts, and review controls inside a
+module should remain normal application UI. New configurable pages should reuse
+the shared `PageWorkspace` layer instead of creating one-off dashboard canvases.
+
+Configurable workspaces are only worth keeping if they increase task
+throughput. Normal mode must stay quiet and static: no grid, handles, palette,
+or motion outside an explicit edit-layout mode. Snapping should be shown as a
+preview outline while dragging or resizing, then committed on release, so data
+cards do not jump under the pointer.
+
+The long-term UX bar is workflow composition, not movable cards for their own
+sake:
+
+- Ship opinionated presets for real jobs such as tax review, transaction
+  cleanup, reporting/export readiness, source-of-funds review, and wallet
+  monitoring.
+- Keep each page's widget catalog small and page-specific. Add modules only
+  when they expose real state or actions for that workflow.
+- Provide reset-to-default, restore preset, and eventually duplicate/save as
+  preset affordances so experimentation is reversible.
+- Keep strong constraints: no overlapping modules, no unusably small widgets,
+  no empty decorative dashboards, and no layout controls outside edit mode.
+- Add precise non-pointer controls before expanding the pattern broadly:
+  keyboard nudging, size presets, and simple tile commands such as half-width,
+  full-width, and move-to-top.
+- Preserve cross-page consistency. If Transactions, Reports, or Source Funds
+  become configurable, they should use the same edit mode, persistence model,
+  reset behavior, and accessibility rules.
+
+Do not expand configurable workspaces to another main page until one concrete
+workflow proves the added control is useful. A good next proof is a transaction
+cleanup workstation with table, detail, filters, and review queue modules, or a
+tax review workstation with blockers, journal freshness, E 1kv preview, and
+export status.
+
 ### Animations honor motion preference and the display's refresh rate
 
 The Tauri webview (WKWebView on macOS, WebView2 on Windows, webkit2gtk on

docs/reference/desktop.md

@@ -52,6 +52,26 @@ prerelease and development troubleshooting: request logs include argument keys,
 not argument values, while terminal daemon errors keep their structured
 message, hint, and redacted details when the daemon exposes them.
 
+Overview is the first configurable page workspace. Normal mode stays static:
+there is no background grid, drag handle, resize control, remove button, or
+widget palette until the user enters Edit layout. In edit mode, page-level
+modules can be moved, resized from edges or the lower-right corner, focused
+above other modules, removed, re-added from the widget palette, and reset to the
+default layout. Drag and resize interactions show a snapped outline preview
+while the underlying module stays visually stable, then commit the layout on
+release. The layout is a local UI preference keyed by current book identity and
+page id; it is not persisted in the accounting database and does not change
+daemon data. The widget palette contains the existing Overview modules plus
+planned placeholders so later report, source-of-funds, and wallet-monitoring
+modules can reuse the same surface.
+
+Configurable workspaces should remain a workflow feature, not a dashboard toy.
+Future expansion needs opinionated presets for concrete jobs, a small
+page-specific widget catalog, reversible reset/restore behavior, strong minimum
+size and collision constraints, precise keyboard/tile controls, and the same
+edit-mode rules across pages. If a page cannot name the workflow it improves,
+it should keep a fixed layout.
+
 Settings -> AI providers displays each provider's API-key presence plus storage
 location/state. Saving provider metadata does not include the raw key in the
 create/update request; when the API-key field is filled, the form sends the