[13B-Ansage] UnitRole.Unit-Slot umwidmet + DefensePlatform-Baustelle bleibt bewaffnet (Sprint 16.3, #44)

[cubetribe]

Ansage an den Einheitenstrang (13B) — zwei Vertragsflächen, betreffen Sprint 16.3 (#44)

Vorab-Ankündigung gemäß docs/production/hashkrieg/13-15_Parallelbetrieb.md („Vertragsflächen in fremdem Besitz" — wird vor dem PR angesagt, nicht danach). Der zugehörige PR folgt direkt im Anschluss und wird hier verlinkt.

1. Der WeaponProfiles-Slot UnitRole.Unit wird faktisch umwidmet

Bisher: Baustellen trugen UnitRole.Unit. Der Waffentabellen-Fallback stempelt genau diesen Slot mit AttackDamage = 15, und D-087 (Auto-Zielerfassung) feuert ihn — jede Baustelle schoss (Beta-Befund #44).

Ab Sprint 16.3: Die Baustelle trägt ihre Definitionsrolle (def.Role). Der Fallback-Slot UnitRole.Unit trifft keine kanonische Entität mehr ausser tatsächlich rollenlosen Testeinheiten. Wer den Slot in 13B-Arbeit liest (Fallback-Damage-Erwartungen, AI-Tests mit generischen Einheiten): die 15-Schaden-Annahme gilt weiterhin für UnitRole.Unit, aber keine Baustelle hat diese Rolle mehr.

Simulation/Combat/, WeaponProfiles und die Tabelle selbst bleiben unverändert — keine Zeile dort angefasst.

2. Restbefund: eine Baustelle der Verteidigungsplattform bleibt bewaffnet

Die DefensePlatform trägt attackDamage: 20 in ihrer Gebäudedefinition. Eine Baustelle der Plattform bekommt jetzt def.Role = DefensePlatform und ist damit weiterhin IsArmed — die D-087-Auto-Erfassung (CombatSystem Phase 2, „buildings included") lässt sie feuern, solange ein sichtbares Ziel in Reichweite steht.

Das ist der letzte verbleibende Fall von „Baustellen schiessen". Eine saubere Lösung (z. B. Site-Filter in der Auto-Erfassung, gekoppelt an ConstructionSystem.IsActiveSite) liegt in Simulation/Combat/ und gehört damit dem Einheitenstrang. Vom Netzstrang wird das nicht gebaut.

Bitte um Einordnung durch 13B: Aufnahme als Folgeissue (Baustellen-Filter im Targeting) oder bewusstes Belassen für die Beta-Phase.

Kontext

• Sprintdatei: docs/production/hashkrieg/16_Sprint_Wirtschaft.md, Paket 16.3
• Die Strombilanz-, View- und Victory-Mitnahmen des Netzstrangs stehen im PR-Text.
• Golden-Byte-Baselines bewegen sich (Baustellen-Entitäten serialisieren jetzt die Definitionsrolle); die Baseline-Neusetzung kommt als eigener PR gemäß der stehenden Regel.

[cubetribe]

Zugehöriger PR: #71

[cubetribe]

Nachtrag — konkrete Regression in den roten Tests von PR #71 (vom Inhaber diagnostiziert, am Code bestätigt):

Die vier roten Tests sind keine verschobenen Baselines, sondern die KI-Folge der Slot-Umwidmung:

SkirmishAiSystem.cs:266 — die Baustellen-Erkennung der KI hängt am generischen Slot:

case UnitRole.Unit:
    ...
    if (_construction.TryGetSite(raw, out _, out _, out uint assignedBuilder))
    {
        sites.Add(new SiteInfo ...

Mit def.Role landen Baustellen nicht mehr in case UnitRole.Unit → sites bleibt leer → die KI schickt ihren Bauarbeiter nie zur Baustelle (Verwendung um Zeile 321) → nichts wird je fertig → QueueUnit fehlt im Command-Stream der betroffenen Tests.

Fix-Skizze (13B, liegt in eurem Terrain): die Site-Erkennung rollenunabhängig machen — TryGetSite ist die einzige korrekte Quelle und rollenblind. Z. B. vor dem Rollen-switch (oder als default:-Zweig): jede aktive eigene Entität gegen TryGetSite prüfen; case UnitRole.Unit: entfällt dann ersatzlos. TryGetSite(raw, out _, out _, out uint assignedBuilder) bleibt dieselbe Abfrage mit denselben out-Werten.

Solange das nicht gebaut ist, gilt PR #71 als blockiert durch 13B, nicht durch Baselines. Merge-Reihenfolge (erst 13B-Fix, dann #71 — oder #71 mit bekanntem KI-Bruch in ein Fenster) ist Inhaberentscheidung.

[cubetribe]

Dritter Befund aus Sprint 16 — Verteidigungsabschaltung bei Low Power (D-030, C4):

Sprint 16.6 (PR #78) baut die Abschaltreihenfolge im Netzstrang: Radar fällt zuerst (Pings + Minimap), Produktion/Bau −50 % (bestehend), Reparatur halbiert (neu).

Nicht gebaut — gehört euch: die Verteidigung. Economy.md (D-030, „Zahlengerüst, verbindlich") verlangt „Verteidigungsplattformen offline" bei Defizit. Ob ein Turm feuert, entscheidet allein CombatSystem über WeaponProfiles.Get(...).IsArmed, und Simulation/Combat/ kennt keinen Strombegriff. Ein Stromeingang für die Feuererlaubnis (z. B. IsArmed && !IsLowPower(owner), Bilanz über PlayerEconomyState.IsLowPower lesbar) liegt in eurem Terrain.

Bitte einordnen: als Folgeissue zu 13B oder bewusst für die Beta belassen.