Transmettez les entrées utilisateur à l'état via les trois fonctions pures de l'architecture Elm : init, update et view. Modélisez l'application de compteur sous forme de struct, définissez Msg comme une énumération exhaustive, puis exécutez la boucle poll/read de crossterm en mode « raw ». Mappez chaque KeyEvent via une fonction de dispatch totale afin que la fonction update ne reçoive jamais de bruit, et quittez proprement en appuyant sur Esc, Ctrl-C ou q.

Créez des widgets qui remplissent une fonction concrète : des « sparklines » à partir de huit glyphes de blocs Unicode, des « BrailleGraphs » en résolution 4x, un « CpuGrid » qui s’adapte à une cellule par CORE, un « ProcessTable » qui défile et un « MemoryBar » qui se remplit. Chaque widget correspond à un appel paint(rect) ; ensemble, ils forment une interface utilisateur textuelle (TUI) permettant de surveiller le système en temps réel.

Passez des appels de peinture impératifs à des scènes déclaratives. Écrivez des fichiers .prs décrivant la mise en page, puis observez un compilateur à descente récursive de 200 lignes les synchroniser avec vos widgets. Verrouillez l'apparence à l'aide de tests de snapshot Probar : des CellBuffers convertis en chaînes de caractères, des valeurs de référence intégrées ou stockées dans des fichiers, identiques au niveau des octets d'une exécution à l'autre, le tout s'exécutant en CI sans terminal TTY.

Regroupez le tout : un dispositif « Snapshot » déterministe alimente une vue unique qui intègre CpuGrid, Sparkline, MemoryBar et ProcessTable au sein d'un tableau de bord ptop-mini, puis remplacez ce dispositif par un lecteur /proc pour exécuter cette même vue en temps réel.