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.

02: Charakterbogen und Charakterbau sind Registry-Schleifen, keine gemauerten Layouts — Begründung in Ticket 02.
04: Der Startbildschirm trägt eine Zeile mit Warnungsanzahl und Logdateiname („12 Ladewarnungen — logs/load-20260812-112305.log"). Eine Zeile, kein Screen — der Inhalt gehört in einen Texteditor, nicht in ein TUI mit Scrolling und Navigation.