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

.scratch/rustkeep-1.0/issues/06-research-ratatui-architektur.md

@@ -1,7 +1,7 @@
 # 06 — Research: ratatui-App-Architektur
 
 Type: research
-Status: open
+Status: resolved
 Blocked by: —
 
 ## Question
@@ -22,3 +22,33 @@ Fakten sammeln. Zu klären:
 - Stand der Versionen: aktuelle ratatui- und crossterm-Version, bekannte Fallstricke unter Windows.
 
 Ergebnis: empfohlenes App-Muster mit Skizze der Modulstruktur, plus Quellenliste.
+
+## Answer
+
+Vollständiger Bericht: [`research/06-ratatui-architektur.md`](../research/06-ratatui-architektur.md)
+(942 Zeilen, gegen Live-Quellen geprüft am 2026-08-11). Kern:
+
+- **App-Muster: Screen-Stack (`Vec<Screen>`) über zentralem `Game`-State.** ratatui empfiehlt offiziell
+  nichts — es dokumentiert Elm, Component und Flux neutral und hat zu Multi-Screen gar keine Seite.
+  Maintainer joshka rät im Forum zum Enum; ratatuis Flaggschiff-Beispiel `demo2` macht Enum plus
+  `impl Widget for &App`; das rundenbasierte chess-tui fährt `current_page` plus `current_popup`.
+  Elm scheitert an ratatuis eigenem `StatefulWidget`; das Component-Template schleppt tokio, clap und
+  tracing mit.
+- **Modulstruktur:** `game/` (kennt ratatui nicht — mechanisch prüfbar), `data/`,
+  `ui/{screen,input,theme,widgets/,screens/}`, genau ein Eintrittspunkt `Game::apply(Action)`.
+- **Popups: kein Widget-Stack.** `Clear` auf ein zentriertes Sub-`Rect` nach dem Screen. Negativbefund:
+  kein produktives Projekt nutzt `Vec<Box<dyn Component>>` für Popups, auch gitui nicht.
+- **Event-Loop: blockierendes `event::read()`, kein Tick, kein tokio.** Das async-Rezept auf ratatui.rs
+  ist für ein rundenbasiertes Spiel Overkill.
+- **Dungeon-Grid: Eigenbau.** Es gibt kein Grid- oder Tilemap-Widget, weder mitgeliefert noch als
+  Drittanbieter-Crate. `impl Widget` mit direktem Buffer-Zugriff. `Canvas` ist eine Vektorfläche und
+  taugt nur für Minimap und Sichtlinien.
+- **Panic: `ratatui::run(...)` genügt** — die Init-Funktionen installieren den Hook selbst, die drei
+  Rezeptseiten dazu sind veraltet. `Drop` von `Terminal` stellt *nicht* wieder her.
+- **Versionen: ratatui 0.30.2** (2026-06-19, MSRV 1.88, in Teilcrates aufgespalten), **crossterm 0.29.0**.
+  crossterm nicht separat in `Cargo.toml` ziehen.
+- **Windows:** Der `KeyEventKind::Press`-Filter ist Pflicht, sonst doppelte Züge. Kitty-Protokoll und
+  `Event::Paste` gehen dort gar nicht, conhost verschiebt Spalten bei doppelbreiten Zeichen.
+
+Sieben Punkte sind im Bericht ausdrücklich als nicht verifiziert markiert. Sechs Anschlussfragen bleiben
+offen und sind zu Ticket 11 und 12 graduiert.

.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.

.scratch/rustkeep-1.0/issues/12-prototyp-ratatui-durchstich.md

@@ -0,0 +1,23 @@
+# 12 — Prototyp: ratatui-Durchstich
+
+Type: prototype
+Status: open
+Blocked by: 11
+
+## Question
+
+Trägt das Screen-Modell aus 11, bevor sieben Bildschirme darauf gebaut werden?
+
+Der Umbau von `print_box` auf ratatui berührt jedes bestehende Modul (`items.rs`, `player.rs`,
+`armor.rs`, `weapon.rs` und deren `print_values`). Vorher ein billiger Durchstich:
+
+- Hauptmenü und Dungeon-Grid, mehr nicht. Ein Popup darüber, um das Stacking zu prüfen.
+- Das Grid als eigenes Widget mit direktem Buffer-Zugriff — die Stelle, an der es kein fertiges
+  Widget gibt und die Empfehlung sich beweisen muss.
+- Bewegung über `KeyEventKind`-gefilterte Eingabe, damit der Windows-Fallstrick real getestet ist
+  statt nur belegt.
+- Prüfen, ob `game/` beim Bauen ratatui-frei bleibt oder ob es sofort leckt.
+
+Bewusst nicht im Prototyp: Kampf, Inventar, Shop, Speichern, Mods.
+
+Ergebnis: lauffähiger Durchstich plus Urteil, ob das Modell trägt oder Ticket 11 nachgebessert wird.