docs: ticket 06 (ratatui-research) aufloesen, tickets 11 und 12 graduieren

.scratch/rustkeep-1.0/issues/11-ui-geruest-screen-modell.md

@@ -0,0 +1,26 @@
+# 11 — UI-Gerüst und Screen-Modell
+
+Type: grilling
+Status: open
+Blocked by: —
+
+## Question
+
+Wie sieht das konkrete Screen-Modell aus, das auf der Empfehlung aus 06 aufsetzt?
+
+Ticket 06 hat die Fakten geliefert und Screen-Stack über zentralem `Game`-State empfohlen. Die
+Entscheidungen darüber stehen noch aus:
+
+- **Ein Stack oder zwei?** `Vec<Screen>` für Screens und Popups gemeinsam (sxtetris), oder getrennt als
+  `current_page` plus `Option<Popup>` (chess-tui)? Einer ist einfacher, zwei sind klarer bei
+  Popup-über-Popup.
+- **Wo lebt der Listen- und Tabellen-State?** `ListState` gehört nach ratatui-Logik in die UI. Wird er
+  beim `pop()` verworfen oder aufbewahrt — steht der Cursor beim Zurückkehren ins Inventar wieder oben?
+- **`KeyEventKind::Press` allein oder auch `Repeat`?** Rundenbasiert spricht für nur `Press`, aber ein
+  Grid, das man Feld für Feld antippt, fühlt sich zäh an. UX-Entscheidung, keine technische.
+- **Bleibt `game/` wirklich ratatui-frei?** Sobald Effekte Farben oder Symbole aus TOML mitbringen
+  (Ticket 01, 02), ist die Versuchung groß, `Color` nach `game/` zu ziehen. Alternative: eigene Farb- und
+  Symboltypen in `data/`, Übersetzung in `ui/theme.rs`.
+- **Welche Screens gibt es zum Start**, und welche Aktionen kennt `Game::apply(Action)`?
+
+Ergebnis: Screen-Enum, Stack-Modell, Action-Liste und die Regel, was `game/` nicht importieren darf.