feat(ui): die Auswahl wird benutzbar — Typzeile, Doppelklick, Pioniersprung (#50)

[cubetribe]

Warum

Aus dem Betatest vom 09.08.2026, und die Folge ist kein Komfortproblem:

„Viele Einheiten standen auf einem Haufen. Ich konnte nicht eindeutig erkennen, was markiert war, und fand den Pionier nicht wieder."

„Weil ich den Pionier in der Gruppe nicht wiederfand, konnte ich nicht bauen."

Der Bauablauf bricht daran ab. Paket 21.5 hat die Aufstellung geliefert — die Befehlskarte schlüsselt die Auswahl nach Typ auf. Sie war nur nicht benutzbar: man sah, was markiert ist, konnte es aber nicht anfassen.

Fixes #50

Was jetzt geht

1. Die Typzeile filtert die Auswahl. Ein Klick auf „2× Lynx — 180/240 HP" reduziert die Auswahl auf genau diese Einheiten. SelectionManager.RetainRole behält dabei die Reihenfolge der Auswahl bei — der Anführer der reduzierten Auswahl ist damit dieselbe Einheit, nach der die Zeile ohnehin sortiert war. Tote Handles werden gegen den lebenden Store verworfen, dieselbe Höflichkeit wie beim Abruf einer Kontrollgruppe.

2. Doppelklick wählt alle sichtbaren Einheiten derselben Rolle. Zweiter Klick auf dieselbe Einheit innerhalb von 0,35 s. „Sichtbar" heißt im Kamerabild, nicht auf der ganzen Karte — kartenweit wäre ein anderer Befehl und würde überraschen. Shift bleibt additiv, wie bei der bestehenden Klickauswahl.

3. I springt zum nächsten unbeschäftigten Pionier und zentriert die Kamera auf ihn. Ohne das Zentrieren findet man ihn genauso wenig wie vorher. Wiederholtes Drücken tourt in aufsteigender Entitäts-Reihenfolge — der Reihenfolge des Entity-Stores selbst, also stabil und reproduzierbar — und läuft einmal um.

Was „unbeschäftigt" heißt — am Code abgelesen, nicht geraten

IdleBuilderQuery prüft fünf Marker, und die Liste ist nicht erfunden: sie ist die Räumliste des Stop-Befehls, also die Aufzählung der Simulation selbst.

• IsMoving — ein Bewegungsauftrag
• AttackTarget — ein Angriffsauftrag
• HarvestFieldId und IsReturningCargo — die beiden Wirtschaftsaufträge. Ein Pionier hält die nie legitim; die Abfrage prüft sie trotzdem, denn ein Zustand, den es nicht geben sollte, muss als beschäftigt lesen und nie als freie Arbeitskraft
• baustellenseitig: der AssignedBuilderRaw einer Baustelle — wer einer Baustelle zugewiesen ist, baut oder ist auf dem Weg dorthin

Der gemeldete blinde Fleck

Ein sechster Marker ist aus dieser Schicht nicht sichtbar, und das steht so im Code statt genähert zu werden: ein laufender Reparaturauftrag lebt in der privaten Reparaturtabelle des ConstructionSystem. Die einzige öffentliche Fläche ist schreibseitig, und der Reparatur-Tick verändert die Gesundheit des Ziels, nie den UnitState des Pioniers.

Ein Pionier, der gerade repariert, liest hier also als unbeschäftigt. Das ist eine bewusste, dokumentierte Falschantwort in genau einem gelegentlichen Zustand — kein Rateergebnis. Sie zu schließen bräuchte einen einzeiligen öffentlichen Leser in Simulation/**, und das ist außerhalb dessen, was #50 ist: Auswahl und Darstellung. Die Abfrage ist so geschnitten, dass der spätere Reparatur-Leser als eine weitere Klausel hineinpasst.

Kein Simulationseingriff

Alle Daten liegen im EntityManager. Kein neuer CommandKind, kein Snapshot-Feld, keine Regeländerung, RulesHash64 bewegt sich nicht. Der Kameraschwenk ist Präsentation und fließt in keinen Snapshot.

Nachweis

• dotnet test tools/Nova.SimRunner.Tests -c Release: 730/730, vorher wie nachher unverändert — genau das erwartete Ergebnis, denn diese Kette kompiliert Gameplay/ und Presentation/ gar nicht mit. Sie belegt hier nur, dass nichts in die Simulation durchgeschlagen ist
• 13 neue EditMode-Tests. Die Logik liegt bewusst in reinen, Unity-freien Funktionen (IdleBuilderQuery, SelectionManager.RetainRole / ReplaceSelection / AddRange) — dasselbe Muster, das Paket 21.5 mit CommandCardPresenter etabliert hat: was in OnGUI hängt, kann niemand testen; was daneben liegt, schon. Abgedeckt sind die Idle-Definition, die Baustellen-Zuweisung, das Touren mit Umlauf, der Einzelfall, der Leerfall, und die drei neuen SelectionManager-Wege
• Nicht belegt: Unity stand keinem Worker zur Verfügung. Die EditMode-Tests sind geschrieben, nicht gelaufen; die OnGUI-Verdrahtung (Trefferflächen der Zeilen, EstimateHeight, IsPointerOverHud) ist gelesen, nicht geklickt. Das ist der Teil, den ein Mensch nachfahren muss — und zwar an genau den zwei Stellen, an denen es im Bestand schon einmal schiefging: eine Zeile, die sichtbar aber nicht klickbar ist, und ein Klick, der hinter dem Panel in die Welt durchschlägt

Herkunft

Gebaut von Kimi K3 als delegiertem Worker. Der Lauf ist nach 164 Turns an der Kimi-Stundenquote gescheitert — nach der Implementierung, den Tests und dem Nachweislauf, aber vor dem Bericht. Diese Beschreibung ist deshalb vom Orchestrator aus dem Diff geschrieben, nicht aus einem Workerbericht; die Arbeit selbst ist vollständig.