fix(construction): sites carry the definition role, not Unit (#44, Sprint 16.3)

[cubetribe]

Was

Sprint 16.3 / Issue #44 stellt Baustellen auf ihre Definitionsrolle um. Eine
unfertige Baustelle trägt damit z. B. bereits Refinery, HQ oder
DefensePlatform; fertig ist sie weiterhin erst, wenn das Baustellenregister
keinen aktiven Site-Eintrag mehr enthält.

Die Rollenänderung ist an allen betroffenen Lesern geschlossen:

• ConstructionSystem bindet den Site-Lookup in die Wirtschaft und normalisiert
  beim Abschluss weiterhin die Rolle (kompatibel zu älteren Mid-Build-Snapshots).
• EconomySystem zählt Sites weder in der Strombilanz noch als
  Raffinerie-Abladepunkt.
• CombatSystem erhält ConstructionSystem als Pflichtabhängigkeit und schließt
  aktive Sites als Angreifer und Ziel aus. Auch eine unfertige
  Verteidigungsplattform feuert nicht.
• SkirmishAiSystem wertet Sites vor Gebäuderollen aus und ignoriert sie bei
  Zielwahl und Bedrohungsanalyse; das kanonische 10.000-Tick-Szenario wählt nur
  fertige Produzenten.
• Siegprüfung, View-/Prefab-Auflösung, Baustellenmarker, Builder-Warnung,
  Produzentenwahl, Rally- und Reparaturvorprüfung nutzen das Site-/Placement-
  Register statt einer Rollenannahme.

D-105-Integrationshinweis

Die beim Main-Merge sichtbar gewordenen AI-/Combat-/UI-Folgen sind eine
gebundene Integrationsreparatur nach D-105: minimaler Diff, im Sprintvertrag
Version 1.1.0 dokumentiert, unabhängiger Read-only-Review durchgeführt. Die
dauerhafte Stranghoheit ändert sich dadurch nicht.

Nachweis

• dotnet test tools/Nova.SimRunner.Tests/Nova.SimRunner.Tests.csproj -c Release
  — 663/663 grün
• Unity 6000.5.4f1, vollständige EditMode-Suite — 547/547 grün
• python3 .github/scripts/check_docs.py — 181 Markdown-Dateien und 5
  Quality-JSONs grün
• git diff --check — grün
• keine geschützte Determinismus-Baseline geändert; AiBehaviorId bleibt r6

Manuelle Spielsicht

Nicht gespielt / nach D-105 ausdrücklich zurückgestellt. Grund: Der Kollege
steht für die Runde derzeit nicht zur Verfügung. Ersatznachweis sind die
vollständigen .NET- und Unity-Suiten einschließlich gespiegelter Bau-, Kampf-,
Wirtschafts- und Siegtests. Restrisiko: Baustellenoptik, Marker/Builder-Warnung
und das sichtbare Ausbleiben des Schusses wurden nicht in einer laufenden Runde
beobachtet. Dieser PR ist damit integrierbar, aber nicht spielerisch
abgenommen und kein Meilenstein-Nachweis.

Changelog

Ein Eintrag unter [Unreleased]: „#44: Baustellen schiessen nicht mehr“.

[cubetribe]

Maintainer-Befund zu den vier roten Tests. Es sind zwei verschiedene Ursachen, und keine davon ist eine verschobene Baseline.

Das ist wichtig, weil #70 die Baselines als Erklärung nennt („Golden-Byte-Baselines bewegen sich … die Baseline-Neusetzung kommt als eigener PR"). Würden diese vier Tests über eine Baseline-Neusetzung grün gemacht, friert das eine echte Regression ein — genau das, was die Regel „Verhalten und Baseline nie im selben Zug" verhindern soll.

---

Ursache A — der eigene neue Test ist falsch (behebbar im Netzstrang)

Site_CarriesDefinitionRole_ButDrawsAndProvidesNoPower_UntilCompletion scheitert bereits an der Platzierung, nicht an der Strombilanz:

f.SpawnBuilder(0, 19, 20);                                              // nur ein Bauarbeiter
f.Step(1);                                                              // kein HQ, kein Kraftwerk
Assert.That(f.Construction.TryPlaceBuilding(0, 4, 20, 20), Is.True);    // ← Expected True, But was False

Definition 4 ist die Raffinerie mit powerRequired: 20. ConstructionSystem.ValidatePlacement lehnt ab:

if (def.PowerRequired > 0 && eco.PowerProvided - eco.PowerRequired < def.PowerRequired)

0 - 0 = 0 < 20 → abgelehnt. Der Nachbartest PowerSite_ProvidesNothing_UntilCompletion läuft durch, weil Definition 5 (Kraftwerk) powerRequired: 0 trägt.

Behebung: ein HQ in die Fixture (das liefert 30), dann greift die Energieprüfung nicht mehr. Die Implementierung ist an dieser Stelle in Ordnung — der Test prüft nur etwas, das er sich selbst unmöglich gemacht hat.

---

Ursache B — eine Regression in der KI (nicht im Netzstrang behebbar)

Die anderen drei Fehler (ShortRun_CommandStream_CarriesBothSlotsAndTheOpeningLoop, AiBehaviorId_TracksWhatTheAiActuallyDoes, SkirmishAi_AimsARetreatingUnitAtItsPursuer) haben eine gemeinsame Wurzel.

SkirmishAiSystem erkennt Baustellen an der Rolle:

if (SimDefinitions.IsBuildingRole(u.Role)) {          // Zeile 228
    case UnitRole.Refinery when refineryRaw == 0: ...
    case UnitRole.Barracks  when barracksRaw == 0: ...
    case UnitRole.Power:     powerCompleted = true;
    continue;                                          // ← und hier ist Schluss
}
switch (u.Role) {
    case UnitRole.Unit:                                // Zeile 266
        if (_construction.TryGetSite(raw, ...))        // ← SO fand die KI ihre Baustellen
            sites.Add(...);                            //    Zeile 271

Vor 16.3 trug eine Baustelle UnitRole.Unit und landete in Zeile 266. Seit 16.3 trägt sie ihre Definitionsrolle und wird oben abgefangen. Drei Folgen:

1. sites bleibt leer. Die Schleife ab Zeile 319, die den zugewiesenen Bauarbeiter in Chebyshev-Reichweite der Baustelle schickt, läuft nie. Ohne Bauarbeiter in Reichweite pausiert die Baustelle — es wird nie etwas fertig.
2. Die Bauleiter zählt falsch. Eine Raffinerie im Bau setzt refineryRaw, eine Kaserne im Bau barracksRaw. Die KI hält die Leiter für abgearbeitet.
3. powerCompleted = true durch ein Kraftwerk im Bau.

Daher fehlt QueueUnit im Eröffnungsloop: Es entsteht nie eine fertige Kaserne, aus der produziert werden könnte. Erwartet wird {PlaceBuilding, QueueUnit, Harvest}, gemessen {Move, PlaceBuilding, Harvest} — das passt genau zu diesem Bild.

Die Behebung ist klein, liegt aber in fremdem Terrain. Im Zensus muss zuerst das Baustellen-Register gefragt werden, dann die Rolle. _construction ist in SkirmishAiSystem bereits injiziert (Zeile 135/166), und dieser PR macht ConstructionSystem.IsActiveSite öffentlich — der Baustein ist also da. Aber Assets/_Project/Scripts/AI/SkirmishAiSystem.cs gehört exklusiv dem Einheitenstrang. Vom Netzstrang wird das nicht gebaut.

---

Was daraus folgt

Dieser PR kann erst gemergt werden, wenn der KI-Zensus nachgezogen ist. Das ist ein dritter Punkt für die Ansage in #70 — und der einzige, der 16.3 blockiert, während der DefensePlatform-Restbefund dort auch später behandelt werden kann.

Reihenfolge: Zensus in 13B nachziehen → dann #71 → dann, falls dann noch nötig, die Baseline-Neusetzung als eigener PR. Nicht umgekehrt.

[cubetribe]

Korrektur zur Baseline-Erwartung im PR-Text: Die vier roten Tests sind keine Golden-Byte-Verschiebungen, sondern eine KI-Regression aus der Rollenänderung (Diagnose vom Inhaber, am Code bestätigt):

SkirmishAiSystem.cs:266 erkennt Baustellen über case UnitRole.Unit: → mit def.Role bleibt sites leer, die KI schickt den Bauarbeiter nie zur Baustelle, nichts wird fertig, QueueUnit fehlt im Stream. Die Stelle gehört dem Einheitenstrang — Befund und Fix-Skizze liegen in Issue #70 (Kommentar vom 2026-08-09).

Damit steht dieser PR: Sim- und View-Teile wie beschrieben, KI-Regression bekannt und bei 13B eingeordnet. Baseline-Neusetzung bleibt zusätzlich nötig (Baustellen serialisieren die Definitionsrolle), aber sie ist nicht die Ursache der roten Tests.