docs: plan framework repository cleanup

TODO.md

@@ -0,0 +1,28 @@
+# Squared Framework TODO
+
+Only cross-package and repository-wide unfinished work belongs here. Keep
+package-specific work in the corresponding `packages/*/TODO.md` file.
+
+## Repository ownership
+
+- [ ] Move the maintained `examples/gui-showcase` application to
+  `squared-netizen/squared-examples`; reserve `squared-netizen/sandbox` for
+  disposable experiments.
+- [ ] Before removing the showcase from this repository, migrate its README and
+  Doxygen references and retain or extract the smallest self-contained GUI test
+  fixture required by framework CI.
+- [ ] Audit the framework tree after the move so application-owned examples and
+  generated artifacts do not remain in the authoritative package repository.
+
+## Source and package layout
+
+- [ ] Design a repository-wide flattening plan for the excessive
+  `packages/<package>/content/modules/<module>/...` authoring depth.
+- [ ] Separate the contributor-friendly source layout from the immutable `.sq`
+  archive layout; use package staging when necessary instead of making authors
+  edit deeply nested payload paths.
+- [ ] Preserve public include paths, package coordinates, exact dependency
+  semantics, and reproducible content digests during the migration.
+- [ ] Migrate one representative package as a measured pilot, update CMake,
+  package tooling, tests, and documentation, then apply the proven layout
+  consistently.

packages/squared-gui/TODO.md

@@ -4,6 +4,19 @@ Only unfinished work belongs here. Move completed work into `history.md`.
 
 ## Next
 
+- [ ] Decompose the monolithic `gui.hpp` and `gui.cpp` implementation into
+  cohesive component-focused headers and translation units, following
+  `list_view.cpp` as the extraction precedent.
+- [ ] Keep `squared/gui/gui.hpp` as a compatibility umbrella while introducing
+  focused public headers for core geometry and style contracts, widget
+  foundations, layouts, primitive controls, overlays and windows, and composite
+  controls.
+- [ ] Split implementation by ownership and behavior rather than creating one
+  file for every trivial class; avoid cyclic includes, duplicate widget
+  hierarchies, and backend or platform leakage.
+- [ ] Preserve behavior with component-level tests, run the mandatory Clang
+  workflow for each slice, and update CMake and programmer/developer
+  documentation as each extraction lands.
 - [ ] Continue rounding out the primitive widget set with popup overlays,
   select boxes, and menus.
 - [ ] Add a canvas widget using the existing `Widget`, input propagation,