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.

.scratch/rustkeep-1.0/map.md

@@ -13,6 +13,7 @@ dort als Konvention im Body. Zuordnung Ticket → Gitea-Issue:
 | 03 Mod-Ladepipeline | [#4](https://gitlab.hive-brain.de/MDietermann/rustkeep/issues/4) | 08 Event-System | [#9](https://gitlab.hive-brain.de/MDietermann/rustkeep/issues/9) |
 | 04 Fehlerstrategie | [#5](https://gitlab.hive-brain.de/MDietermann/rustkeep/issues/5) | 09 Save-Schema | [#10](https://gitlab.hive-brain.de/MDietermann/rustkeep/issues/10) |
 | 05 Research Script-Engine | [#6](https://gitlab.hive-brain.de/MDietermann/rustkeep/issues/6) | 10 Raum-Prefab-Format | [#11](https://gitlab.hive-brain.de/MDietermann/rustkeep/issues/11) |
+| 11 UI-Gerüst | [#12](https://gitlab.hive-brain.de/MDietermann/rustkeep/issues/12) | 12 Prototyp ratatui | [#13](https://gitlab.hive-brain.de/MDietermann/rustkeep/issues/13) |
 
 ## Destination
 
@@ -49,6 +50,8 @@ Feststehende Rahmenentscheidungen aus der Charter-Session:
 
 <!-- eine Zeile pro geschlossenem Ticket -->
 
+- [06 — Research: ratatui-App-Architektur](issues/06-research-ratatui-architektur.md) ([#7](https://gitlab.hive-brain.de/MDietermann/rustkeep/issues/7)) — Screen-Stack über zentralem `Game`-State statt Elm oder Component-Trait; `game/` bleibt ratatui-frei; Popups per `Clear` auf Sub-`Rect` statt Widget-Stack; blockierendes `event::read()` ohne Tick; Dungeon-Grid ist Eigenbau, es gibt kein Widget dafür; ratatui 0.30.2 mit MSRV 1.88; `KeyEventKind::Press`-Filter unter Windows Pflicht. Voller Bericht in [research/06](research/06-ratatui-architektur.md).
+
 ## Not yet specified
 
 - **Kampfmechanik im Detail** — Initiative, Aktionen pro Runde, Trefferformel, Krit, Flucht. Wartet auf das Effekt-Vokabular (01), weil Angriffe und Fähigkeiten Effekte sind.
@@ -56,7 +59,7 @@ Feststehende Rahmenentscheidungen aus der Charter-Session:
 - **XP-Kurve und Progression** — was Level-ups geben, wie Rasse/Klasse mitskalieren. Wartet auf 01.
 - **Boss-Design** — ob Bosse nur Gegner mit besseren Werten sind oder eigene Mechanik brauchen (Phasen, Skripte). Berührt Stufe (c) des Mod-Supports.
 - **NPC- und Handelsmodell** — Warenbestand, Preisbildung über `charisma`, Dialogdaten. Wartet auf das Event-System (08).
-- **Inventar-UX** — Slots, Gewicht oder Kapazität, Sortierung, Vergleichsansicht. Wartet auf die ratatui-Architektur (06).
+- **Inventar-UX** — Slots, Gewicht oder Kapazität, Sortierung, Vergleichsansicht. Wartet jetzt auf das Screen-Modell (11), nicht mehr auf 06.
 - **Mod-Verteilung** — wie Spieler an Mods kommen und ob es eine Versionsprüfung gibt. Wartet auf das Manifest-Format (03).
 
 ## Out of scope