Leiten Sie Benutzereingaben über die drei reinen Funktionen der Elm-Architektur – `init`, `update` und `view` – an den Zustand weiter. Modellieren Sie die Zähler-App als Struktur, definieren Sie `Msg` als erschöpfende Aufzählung und führen Sie die `poll/read`-Schleife von Crossterm im Raw-Modus aus. Leiten Sie jedes KeyEvent über eine Total-Dispatch-Funktion weiter, damit „update“ niemals Störsignale erhält, und beenden Sie das Programm sauber bei Esc, Strg-C oder q.

Erstellen Sie Widgets, die echte Arbeit leisten – Sparklines aus acht Unicode-Block-Glyphen, BrailleGraphs mit 4-facher Auflösung, ein CpuGrid, das pro CORE eine Zelle umbricht, eine scrollbare ProcessTable und eine sich füllende MemoryBar. Jedes Widget entspricht einem „paint(rect)“-Aufruf; zusammen bilden sie eine Live-TUI zur Systemüberwachung.

Wechseln Sie von imperativen Malaufrufen zu deklarativen Szenen. Schreiben Sie .prs-Dateien, die das Layout beschreiben, und beobachten Sie dann, wie ein 200-zeiliger rekursiv-absteigender Compiler diese mit Ihren Widgets abgleicht. Sichern Sie das Erscheinungsbild mit Probar-Snapshot-Tests – als Zeichenketten umgewandelte CellBuffers, Inline- oder dateibasierte Goldens, die zwischen den Durchläufen byteweise identisch sind und alle in der CI ohne TTY ausgeführt werden.

Alles zusammenführen: Ein deterministisches Snapshot-Fixture liefert eine einzige reine Ansicht, die CpuGrid, Sparkline, MemoryBar und ProcessTable zu einem ptop-mini-Dashboard zusammenfasst; anschließend wird das Fixture gegen einen /proc-Reader ausgetauscht, um dieselbe Ansicht live auszuführen.