Scene strip now renders in canonical F-key order regardless of persisted SortOrder. The strip loads Scenes ORDER BY SortOrder while each tab's F-key label is name-derived, so a session that persisted Chat before BRB (found on the creator's DB: SortOrder 2/3) showed tabs 'Chat F4' then 'BRB F3'. MainViewModel.LoadLayout now calls the new ReorderScenesToCanonical() - the five canonical scenes reorder to Starting, Live, BRB, Chat, Ending (F1-F5, stable among renamed non-canonical scenes), and the next auto-save re-stamps SortOrder so the heal persists. One integration test (SceneOrderTests) seeds the swapped-order DB and asserts loaded order, F1-F5 labels, and that a save persists the corrected ordering. 423 pass, 0 build warnings. (Unit: scene order)

bugs.md

@@ -1,5 +1,18 @@
 # Bugs
 
+## Scene strip / F-keys out of sequence (FIXED 2026-10-10)
+Report: "the ordering of the 5 screens and their corresponding F-key is out of sequence." The strip
+renders `Scenes ORDER BY SortOrder` but each tab's F-key label is name-derived, so the two can drift
+when a session persists a non-canonical order (on the creator's DB: Chat SortOrder 2, BRB 3 — tabs
+showed "Chat F4" then "BRB F3").
+
+Fix (same commit): `MainViewModel.LoadLayout` calls the new
+`ReorderScenesToCanonical()` after loading — the five canonical scenes render in F-key order
+(Starting, Live, BRB, Chat, Ending = F1-F5), renamed (non-canonical) scenes keep their loaded order
+after them; the next auto-save re-stamps SortOrder to the corrected index. One integration test
+(`SceneOrderTests`) seeds a Chat-before-BRB DB and asserts the loaded order + F1-F5 labels, then that
+a save persists the corrected SortOrder (fresh load keeps canonical order).
+
 ## Desktop "locked" after the app starts while a fullscreen game is running (FIXED 2026-10-10)
 Report: once the app is started, the desktop is "locked" — the mouse can no longer interact with it —
 which made streaming live gameplay impossible.