fix(construction): die Bauverweigerung nennt den Grund statt nur das Ergebnis (#135)

[cubetribe]

Warum

Aus der Proberunde des Inhabers vom 31.08.2026 auf Build 97e5459 kamen zwei Beschwerden:

„Ich habe einen zweiten Atlas gebaut. Der hat keine Funktion, der kann keine Gebäude bauen."

„Ich wollte bei den Vorkommen in der Mitte ein Hauptquartier bauen. Das ging nicht, obwohl ich genug Strom hatte und auch genug Geld."

Fixes #135

Bei der Prüfung erwiesen sie sich als dieselbe — und die Simulation hatte in beiden Fällen recht. ConstructionSystem.IsInsideBuildInfluence misst die Bauzone von den eigenen fertigen Gebäuden aus, nicht vom Pionier: wo der Atlas steht, ist für die Platzierung völlig egal. Und die Kartenmitte liegt 56 Zellen vom HQ entfernt, bei BuildInfluenceRadiusCells = 8. Dort kann nach D-104/D-108 nichts stehen, bevor eine Gebäudekette hingewachsen ist.

Das Verhalten bleibt unverändert. D-108 hat die Regel bewusst so gesetzt, und die Karte aus Sprint 21 ist auf sie hin gebaut.

Der eigentliche Defekt

ValidatePlacement warf vier verschiedene Regeln in einen einzigen Rückgabewert (RejectedInvalidTarget): außerhalb der Karte, außerhalb der Bauzone, zu dicht am Nachbarn, falscher Abstand zum Vorkommen.

Der Spieler bekam „geht nicht" und musste raten. Mit genug Geld und Strom ist „die Einheit ist kaputt" der vernünftigste verbleibende Schluss — und genau den hat der Inhaber gezogen. Das ist die Schuld der Meldung, nicht seine.

Wie es gelöst ist, ohne das eingefrorene Schema anzufassen

Simulation/CommandsV1/ ist D-ID-pflichtig, ein neuer CommandResultCode wäre also ein Schema-Vorgang gewesen. Stattdessen:

• Die schema-v1-Rückgabewerte bleiben exakt wie sie sind.
• Der feine Grund reist über ein schreibgeschütztes Enum außerhalb des Befehlsstroms (PlacementDenial), gelesen über GetPlacementDenial.
• Entscheidend: das ist derselbe Durchlauf wie die Prüfung, nur feiner abgebildet. Ergebnis und Begründung können dadurch nicht auseinanderlaufen — eine zweite, nachgebaute Prüfung wäre genau die Sorte Duplikat, die in einem halben Jahr etwas anderes sagt als der Validator.

Die Meldungen nennen die Regel, nicht das Ergebnis

Statt „ungültiges Ziel":

• „Außerhalb der Bauzone — sie reicht 8 Felder um jedes fertige Gebäude …"
• „Zu dicht an einem Gebäude oder einer Baustelle — mindestens ein freies Feld dazwischen."
• „Raffinerie braucht ein Vorkommen in 1 bis 3 Feldern Entfernung — näher am Aetherium platzieren."
• „Zu dicht an einem Aetherium-Vorkommen — 2 Felder Abstand nötig (nur die Raffinerie darf näher)."
• „Hier steht schon ein Gebäude oder eine Baustelle — freie Zelle wählen."
• „Das Gebäude würde über den Kartenrand ragen — weiter innen platzieren."
• „Unwegsames Gelände — Gebäude brauchen freien Boden." (für den Felsring aus 21.7)

Die Zahlen sind keine Literale im Text — sie werden aus den Konstanten gelesen. Ändert jemand den Radius, ändert sich die Meldung mit; sie kann nicht veralten.

Die offene Frage aus dem Issue, beantwortet

Zeichnet das Bauzonen-Overlay in der Kartenmitte überhaupt?

Ja. Das Quad ist so groß wie die Karte (size = ConstructionSystem.GridSize), es deckt die Mitte also ab. Es zeichnet dort nur nichts — weil dort nichts baubar ist.

Damit ist „nicht baubar" optisch nicht von „kein Overlay" zu unterscheiden, und das erklärt, warum der Inhaber die Information nicht hatte, obwohl sie angezeigt wurde. Ein Overlay, das Auskunft durch Abwesenheit gibt, ist genau dann stumm, wenn man es am nötigsten braucht. Das ist kein Fehler dieses PRs, aber ein Grund mehr, warum die Meldung tragen muss — und sie tut es jetzt.

Nachweis

• dotnet test tools/Nova.SimRunner.Tests -c Release: grün, vom Orchestrator gefahren; neue Testdatei ConstructionPlacementDenialTests.cs (422 Zeilen) deckt jeden der Gründe einzeln ab
• Verhalten unverändert: keine Regel, keine Konstante, keine Baseline bewegt
• Nicht belegt: wie die Meldungen im Spiel aussehen. Unity kompiliert die Präsentationsseite, aber ob der Text an der richtigen Stelle und lesbar erscheint, zeigt erst eine Proberunde

Herkunft

Erarbeitet von Kimi K3 als delegiertem Worker. Der Lauf blieb am Ende in einer Warteschleife hängen und hat seinen Bericht nicht mehr geschrieben — die Arbeit selbst war da vollständig. Diese Beschreibung ist deshalb vom Orchestrator aus dem Diff geschrieben, einschließlich der eigenständig nachgeprüften Overlay-Antwort.