From e870b078bdf7b7e614ecdb12552c8c32d62cce44 Mon Sep 17 00:00:00 2001 From: Dennis Westermann Date: Tue, 18 Aug 2026 09:29:22 +0200 Subject: [PATCH] =?UTF-8?q?docs(decision):=20D-108=20berichtigen=20?= =?UTF-8?q?=E2=80=94=20die=20Ankerliste=20wird=20ge=C3=B6ffnet,=20nicht=20?= =?UTF-8?q?festgeschrieben?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Die Erstfassung von D-108 behauptete, ConstructionSystem lasse bereits jedes eigene Gebäude als Bauanker gelten, und wollte diesen Zustand nur aussprechen. Das war falsch: IsInsideBuildInfluence prüft seit D-104 auf HQ, Lager und Kraftwerk, und D-104 Punkt 2 sagt das wörtlich. Der Docstring von BuildInfluenceRadiusCells nennt die Rollenliste nicht — daraus entstand die falsche Prämisse. Gefunden hat den Widerspruch der ausführende Agent beim Umsetzen von Paket 21.1; er hat angehalten und nachgefragt, statt ihn selbst aufzulösen. Der Inhaber hat daraufhin in Kenntnis der tatsächlichen Lage neu entschieden: nicht die Bestandsregel festschreiben, sondern die Ankerliste öffnen. Folgen, die in den Dokumenten nachgezogen sind: - D-108 ist damit eine Verhaltensänderung, keine Festschreibung. RulesHash64, die Determinismus-Baselines und der gepinnte Ausgang der kanonischen KI-Partie bewegen sich. Eigener Regel-PR, zweiter Baseline-PR, Merge-Fenster mit dem Einheitenstrang. - Paket 21.1 neu gefasst: Messung erledigt (15 bei Abstand 2, 23 bei 1, 23 bei 0), beide Konstanten bleiben unverändert, Regeländerung und zweifacher Docstring-Nachzug ergänzt. - R-2, R-3, Versionsrelevanz und "Fertig wenn" im Sprint sowie Pakettabelle und Merge-Fenster-Hinweis im Auftrag nachgezogen. Co-Authored-By: Claude Opus 5 --- CHANGELOG.md | 30 ++++ docs/production/DecisionLog.md | 130 ++++++++++++------ .../hashkrieg/21_Sprint_Verknappungsfolgen.md | 102 +++++++++----- .../hashkrieg/AUFTRAG_Verknappungsfolgen.md | 31 +++-- 4 files changed, 206 insertions(+), 87 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 2aab35a..edbf161 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -18,6 +18,23 @@ die Versionierung folgt (in der aktuellen Doku-Phase) dem Dokumentationsstand de > erzeugt; MS-0 und MS-1 bleiben offen. ### Entschieden +- **D-108 berichtigt und neu gefasst: jedes eigene Gebäude wird Bauanker.** Die + Erstfassung vom 2026-08-17 behauptete, der Code lasse *jedes* Gebäude als Anker + gelten, und wollte diesen Zustand nur aussprechen. Das war falsch: + `ConstructionSystem.IsInsideBuildInfluence` prüft seit D-104 auf **HQ, Lager + und Kraftwerk**, und D-104 Punkt 2 sagt das wörtlich. Der Fehler entstand, weil + der Docstring von `BuildInfluenceRadiusCells` und Issue #92 von einem „eigenen + Bauanker" sprechen, ohne die Rollenliste zu nennen, und die Implementierung vor + der Beschlussfassung nicht gelesen wurde. Gefunden hat ihn der ausführende + Agent beim Umsetzen von Paket 21.1, der angehalten und nachgefragt hat statt + den Widerspruch aufzulösen. Der Inhaber hat daraufhin **in Kenntnis der + tatsächlichen Lage neu entschieden**: nicht die Bestandsregel festschreiben, + sondern die Ankerliste öffnen. Damit ist D-108 eine Verhaltensänderung — + `RulesHash64`, Determinismus-Baselines und der gepinnte Ausgang der kanonischen + KI-Partie bewegen sich, es braucht einen eigenen Regel-PR, einen zweiten + Baseline-PR und ein mit dem Einheitenstrang abgestimmtes Merge-Fenster. Bewusst + in Kauf genommen: eine Kette billiger Gebäude kann sich damit über die Karte + schieben — in C&C etabliert und im Zusammenspiel mit 21.6/21.7 gewollt - **D-108: Territorium wächst kriechend an jedem eigenen Bauanker.** Die Frage aus Testbericht T-01 (#92) — erweitert ein zweites HQ den Baubereich? — war im Code längst beantwortet und nie ausgesprochen: @@ -56,6 +73,19 @@ die Versionierung folgt (in der aktuellen Doku-Phase) dem Dokumentationsstand de spielerisch abgenommen und kein Meilenstein-Nachweis ### Hinzugefügt +- **Die Startzone ist gemessen statt geschätzt (Paket 21.1).** + `tools/Nova.SimRunner.Tests/BuildZoneCapacityTests.cs` beziffert in zwei Spuren, + wie viele Gebäude in die Bauzone des kanonischen HQ-Ankers passen: eine echte + Systemspur über `ValidatePlacement` und `PlaceCompletedBuilding`, und ein + Geometriemodell, das die Systemspur beim geltenden Wert zellgenau reproduzieren + muss, bevor seine Variantenzahlen zählen. Ergebnis: **15** Gebäude bei + `MinimumBuildingDistanceCells = 2`, **23** bei 1, und bei 0 ebenfalls 23 — weil + die Footprint-Belegung jede Konfiguration mit Abstand unter 1 ohnehin verbietet. + Der einzige wirksame Hebel wäre 2 → 1, und **beide Konstanten bleiben + unverändert**: die Zahl weist die im Testbericht gemeldete Enge nicht als + Abstandsproblem aus, und die 15 sind ohnehin nur eine untere Schranke für die + Anfangszone, weil jeder Anker die Grenze mitschiebt. Der Test pinnt alle drei + Konstanten und macht das Paket erneut auf, falls eine davon fällt - **Sprint 21 festgeplant und als Großauftrag erteilt.** Aus dem Vorschlag zu den Verknappungsfolgen wird nach den Inhaberentscheidungen D-108 und D-109 die Sprintdatei `docs/production/hashkrieg/21_Sprint_Verknappungsfolgen.md` mit diff --git a/docs/production/DecisionLog.md b/docs/production/DecisionLog.md index 95f08f7..6a31b3c 100644 --- a/docs/production/DecisionLog.md +++ b/docs/production/DecisionLog.md @@ -1,6 +1,6 @@ # Decision Log -**Version:** 1.40.0 | **Status:** aktiv (laufend) | **Verantwortungsbereich:** Game Director / Lead Technical Director / Project Owner | **Sprint:** 21 +**Version:** 1.41.0 | **Status:** aktiv (laufend) | **Verantwortungsbereich:** Game Director / Lead Technical Director / Project Owner | **Sprint:** 21 ## Zweck @@ -3429,53 +3429,100 @@ selbst. und Befehlsschemata bleiben unverändert. D-102 bleibt für Feldanzahl, Koordinaten, Reserven, Reihenfolge und Ernterate vollständig verbindlich. -### D-108 | verbindlich | Sprint 21 (Territorium wächst kriechend an jedem Bauanker) +### D-108 | verbindlich | Sprint 21 (Jedes eigene Gebäude wird Bauanker) -**Status:** Inhaberentscheidung vom 2026-08-17. +**Status:** Inhaberentscheidung vom 2026-08-17, **am 2026-08-18 in der Prämisse +berichtigt und in der Sache neu gefasst.** Die Erstfassung schrieb eine Regel +fest, die der Code nicht hat; die Berichtigung macht daraus eine bewusste +Regeländerung. Der Verlauf steht unten unter „Berichtigung". **Kontext:** Testbericht T-01 (#92) fragt, wie der Spieler sein Territorium erweitert — ob ein zweites HQ die Bauzone vergrößert, ob es später eigene -Erweiterungsgebäude gibt, ob Bauzonen sich überschneiden dürfen. Der Code -beantwortet die Frage bereits, ausgesprochen wurde sie nie: -`ConstructionSystem.BuildInfluenceRadiusCells = 8` misst die maximale -footprint-bewusste Chebyshev-Distanz **von einem eigenen Bauanker**, nicht vom -HQ. Damit erweitert jedes fertiggestellte Gebäude das erlaubte Feld um seinen -eigenen Radius; die Zone kriecht mit der Basis mit, statt sprunghaft an einem -zweiten HQ zu wachsen. Der Bericht meldet zugleich, der Platz sei „nach einigen -Kraftwerken relativ schnell ausgeschöpft" — wofür `MinimumBuildingDistanceCells = 2` -die wahrscheinlichere Ursache ist als der Radius, weil dieser Wert Zellen -*innerhalb* der Zone sperrt. +Erweiterungsgebäude gibt, ob Bauzonen sich überschneiden dürfen. Der Bericht +meldet zugleich, der Platz sei „nach einigen Kraftwerken relativ schnell +ausgeschöpft". + +**Was der Code heute tut** (`ConstructionSystem.IsInsideBuildInfluence`): + +```csharp +if (def.Role != UnitRole.HQ && def.Role != UnitRole.Storage && def.Role != UnitRole.Power) continue; +``` + +Anker sind ausschließlich **HQ, Lager und Kraftwerk**. Kaserne, Fahrzeugfabrik, +Raffinerie, Radar, Forschungslabor und Verteidigungsplattform erweitern die Zone +nicht. Das deckt sich wörtlich mit D-104 Punkt 2: „Ein Neubau braucht ein +eigenes, lebendes und fertiggestelltes HQ, Lager oder Kraftwerk in höchstens acht +Zellen Abstand." Die Zone kriecht also bereits mit — aber nur über +Infrastrukturbauten. + +**Die Messung** (Paket 21.1, `tools/Nova.SimRunner.Tests/BuildZoneCapacityTests.cs`) +beziffert die Startzone des HQ-Ankers allein: **15** Gebäude bei +`MinimumBuildingDistanceCells = 2`, **23** bei 1, und bei 0 ebenfalls 23, weil +die Footprint-Belegung jede Konfiguration mit Abstand unter 1 ohnehin verbietet. +Der einzige wirksame Hebel wäre 2 → 1. Die 15 sind dabei eine **untere Schranke +für die Anfangszone**, keine Kapazitätsgrenze: da Kraftwerke Anker sind, schiebt +jedes am Rand platzierte Kraftwerk die Grenze nach außen. **Alternativen:** -1. Die bestehende Regel festschreiben: jedes eigene Gebäude bleibt Bauanker. -2. Nur ausgewiesene Gebäude (HQ, Raffinerie, ein künftiger Expansionsposten) - werden Anker; alle übrigen erweitern die Zone nicht. -3. Die Regel beibehalten und den Radius über 8 anheben. - -**Entscheidung:** Alternative 1. **Jedes eigene Gebäude bleibt Bauanker**, das -Kriechen ist gewollt und ab sofort ausgesprochene Mechanik. Die gemeldete Enge -wird **nicht** über den Radius beantwortet, sondern zuerst gemessen: Sprint 21 -Paket 21.1 liefert als Test, wie viele Gebäude welcher Footprintgröße bei -`MinimumBuildingDistanceCells` 2 gegen 1 gegen 0 in die Startzone passen. Erst -gegen diese Zahl wird über den Wert entschieden. - -**Begründung:** Das kriechende Wachstum ist das klassische C&C-Verhalten und -koppelt Expansion genau so an die Wirtschaft, wie die Verknappung aus D-102 es -verlangt: Wer ein entferntes Feld erschließen will, muss sich baulich dorthin -arbeiten. Alternative 2 wäre eine echte Designerweiterung mit eigenem -Gebäudetyp und gehört nicht in einen Sprint, der Bestehendes lesbar macht. -Alternative 3 behebt möglicherweise das falsche Problem — der Radius ist nicht -belegt als Ursache, die Mindestdistanz ist es plausibel. - -**Konsequenzen:** Der Docstring an `BuildInfluenceRadiusCells` wird so -umgeschrieben, dass die Ankerregel nicht mehr nur ein Nebensatz ist. Das -Baubereichs-Overlay (#91, Paket 21.4) färbt die **tatsächlich baubaren Zellen** -für den gewählten Footprint ein, nicht einen Radius-Ring — ein Ring wäre -unehrlich, weil er die innerhalb gesperrten Zellen verschweigt. Fällt -`MinimumBuildingDistanceCells` später nach der Messung, ist das ein eigener PR -mit eigener D-ID und bewegt `RulesHash64`. Die Kartendichte (#93, Paket 21.6) -hängt an dieser Festlegung und läuft danach. +1. Die bestehende Ankerliste (HQ, Lager, Kraftwerk) festschreiben und die + Sichtbarkeit über das Overlay aus Paket 21.4 herstellen. +2. **Jedes eigene fertiggestellte Gebäude wird Bauanker.** +3. Die Ankerliste unverändert lassen und stattdessen `MinimumBuildingDistanceCells` + von 2 auf 1 senken. + +**Entscheidung:** Alternative 2. **Jedes eigene, lebende und fertiggestellte +Gebäude wird Bauanker** — die Rollenprüfung in `IsInsideBuildInfluence` entfällt. +`BuildInfluenceRadiusCells` bleibt bei 8, `MinimumBuildingDistanceCells` bleibt +bei **2**; der Wert wird ausdrücklich **nicht** angefasst, weil die Messung die +gemeldete Enge nicht als Abstandsproblem bestätigt. + +**Begründung:** Das ist das klassische C&C-Verhalten und die einfachste Antwort +auf die Frage des Berichts: Territorium wächst dort, wo gebaut wird, ohne einen +eigenen Erweiterungsgebäudetyp erfinden zu müssen. Es koppelt Expansion an die +Wirtschaft, wie es die Verknappung aus D-102 verlangt — wer ein entferntes Feld +erschließen will, arbeitet sich baulich dorthin. Alternative 1 wäre billiger, +lässt aber die Frage des Berichts unbeantwortet. Alternative 3 dreht an einem +Wert, den die Messung nicht als Ursache ausweist, und kostet denselben +Regelbruch. + +**Konsequenzen:** + +- Eingriff in `Simulation/Construction/ConstructionSystem.cs`. Maintainer-Strang, + aber **eine Verhaltensänderung**, kein Aussprechen: `RulesHash64` bewegt sich, + die Determinismus-Baselines werden rot, und der gepinnte Ausgang der + kanonischen KI-Partie (`CanonicalAiOutcomeTests`, Einheitenstrang) bewegt sich + mit. Eigener PR, Baseline in einem **zweiten** PR, und ein mit dem + Einheitenstrang abgestimmtes Merge-Fenster. +- Der Docstring an `BuildInfluenceRadiusCells` beschreibt heute „from an own + construction anchor", ohne die Rollenliste zu nennen. Genau diese Auslassung + hat die falsche Erstfassung dieser Entscheidung erzeugt. Er wird zweimal + nachgezogen: zuerst auf den Ist-Zustand mit der Rollenliste, dann mit dieser + Regeländerung auf die neue Fassung. +- **Bewusst in Kauf genommen:** ab jetzt kann sich ein Spieler mit einer Kette + billiger Gebäude über die Karte schieben, weil auch Kaserne und + Verteidigungsplattform ankern. Das ist in C&C etabliertes Verhalten und im + Zusammenspiel mit den Paketen 21.6 und 21.7 gewollt — es ist der Weg, auf dem + ein umkämpftes Feld überhaupt erschlossen wird. +- `BuildInfluenceRadiusCells` und `MinimumBuildingDistanceCells` bleiben + unverändert; die Kapazitätsmessung aus 21.1 pinnt beide Konstanten und macht + Paket 21.1 erneut auf, falls eine davon später fällt. +- D-104 Punkt 2 wird durch diese Entscheidung in der Ankerliste **ersetzt**; + seine übrigen Punkte (Footprint-Chebyshev, Feldabstände, Raffinerieintervall) + bleiben unberührt. + +**Berichtigung (2026-08-18):** Die Erstfassung dieser Entscheidung behauptete, +der Code lasse bereits *jedes* eigene Gebäude als Anker gelten, und wollte diesen +Zustand lediglich aussprechen. Das war falsch — die Rollenprüfung auf HQ, Lager +und Kraftwerk stand seit D-104 im Code. Der Fehler entstand daraus, dass der +Docstring von `BuildInfluenceRadiusCells` und Issue #92 von einem „eigenen +Bauanker" sprechen, ohne die Rollenliste zu nennen, und die Implementierung vor +der Beschlussfassung nicht gelesen wurde. Aufgefallen ist er dem ausführenden +Agenten beim Umsetzen von Paket 21.1, der angehalten und nachgefragt hat, statt +den Widerspruch aufzulösen — das ist der vorgesehene Weg und hat hier +funktioniert. Der Inhaber hat die Entscheidung daraufhin **in Kenntnis der +tatsächlichen Lage neu getroffen**: nicht die Bestandsregel festschreiben, +sondern die Ankerliste bewusst öffnen. ### D-109 | verbindlich | Sprint 21 (Die Kartenmitte wird ein Gebiet mit Chokepoints) @@ -3616,6 +3663,7 @@ Mitte sind ausdrücklich nicht Teil dieser Entscheidung. | Version | Datum | Änderung | Autor | |---|---|---|---| +| 1.41.0 | 2026-08-18 | **D-108 in der Prämisse berichtigt und in der Sache neu gefasst.** Die Erstfassung behauptete, der Code lasse bereits jedes Gebäude als Bauanker gelten, und wollte das nur aussprechen — tatsächlich prüft `IsInsideBuildInfluence` seit D-104 auf HQ, Lager und Kraftwerk. Der ausführende Agent hat den Widerspruch beim Umsetzen von Paket 21.1 gefunden und angehalten. Der Inhaber hat daraufhin in Kenntnis der Lage neu entschieden: die Ankerliste wird bewusst geöffnet, **jedes eigene fertiggestellte Gebäude wird Anker**. Damit ist D-108 eine Verhaltensänderung (`RulesHash64`, Baselines, kanonischer KI-Pin), keine Festschreibung. `MinimumBuildingDistanceCells` bleibt bei 2 — die Messung aus 21.1 (15/23/23) weist die gemeldete Enge nicht als Abstandsproblem aus | Dennis Westermann / Orchestrator | | 1.40.0 | 2026-08-17 | D-108 und D-109 aufgenommen (Sprint 21, aus Testbericht T-01): Territorium wächst **kriechend an jedem eigenen Bauanker** — die bestehende Regel wird festgeschrieben statt geändert, und die gemeldete Enge wird an `MinimumBuildingDistanceCells` gemessen, bevor ein Wert fällt. Die Kartenmitte wird ein Gebiet mit schmalen Zufahrten, mit der verbindlichen Auflage, dass Begehbarkeit und Optik aus **einer** Struktur stammen — heute streut `GlutrinneBlockoutView` begehbare Deko-Felsen, während niemand ausser `ConstructionSystem` in das `CostField` schreibt | Dennis Westermann / Orchestrator | | 1.39.0 | 2026-08-10 | D-107 aufgenommen: Die bestehende Glutrinne-Layoutachse spiegelt Punkte um 124 und 3×3-Footprint-Ursprünge abgeleitet um 122; der zweite HQ-Ursprung wird von `(120,120)` auf `(118,118)` korrigiert | Agent (unter Delegation) / Dennis Westermann | | 1.38.0 | 2026-08-10 | D-104 aufgenommen: footprintbasierte Chebyshev-Platzierung mit Einfluss-, Feld-, Gelände- und Gebäudeabständen, zustandslose kumulative Reparaturkosten von 30 Prozent, kanonisch dichte Reparaturreihenfolge und Rules-Revision V3 | Project Owner / Agent (unter Delegation) | diff --git a/docs/production/hashkrieg/21_Sprint_Verknappungsfolgen.md b/docs/production/hashkrieg/21_Sprint_Verknappungsfolgen.md index bb2f8ff..b458f8f 100644 --- a/docs/production/hashkrieg/21_Sprint_Verknappungsfolgen.md +++ b/docs/production/hashkrieg/21_Sprint_Verknappungsfolgen.md @@ -1,6 +1,6 @@ # Sprint 21: Die Folgen der Verknappung — endliche Felder werden lesbar und bespielbar -**Version:** 1.0.0 | **Status:** geplant | **Verantwortungsbereich:** Maintainer-Strang | **Sprint:** 21 | **Vorgänger:** [16_Sprint_Wirtschaft.md](16_Sprint_Wirtschaft.md) | **Parallel zu:** [13B](13B_Sprint_Einheitenverhalten.md) | **Regelwerk:** [13-15_Parallelbetrieb.md](13-15_Parallelbetrieb.md) | **UX-Gate:** human | **Leitsatz:** endliche Felder sind kein Wert, sondern ein Systemwechsel +**Version:** 1.1.0 | **Status:** in Arbeit (21.1 läuft) | **Verantwortungsbereich:** Maintainer-Strang | **Sprint:** 21 | **Vorgänger:** [16_Sprint_Wirtschaft.md](16_Sprint_Wirtschaft.md) | **Parallel zu:** [13B](13B_Sprint_Einheitenverhalten.md) | **Regelwerk:** [13-15_Parallelbetrieb.md](13-15_Parallelbetrieb.md) | **UX-Gate:** human | **Leitsatz:** endliche Felder sind kein Wert, sondern ein Systemwechsel ## Zweck @@ -131,35 +131,60 @@ Simulation/State/ Layout und Serialisierung Die Reihenfolge ist nach Abhängigkeit sortiert, nicht nach Aufwand. Jedes Paket ist ein eigener PR und für sich abnehmbar. -### 21.1 · Die Territoriumsregel wird ausgesprochen und gemessen (#92 → D-108) +### 21.1 · Jedes Gebäude wird Bauanker (#92 → D-108) — **Verhaltensänderung** -**Kein Overlay, keine Regeländerung — erst eine Festlegung und eine Zahl.** +> **Diese Beschreibung ist am 2026-08-18 neu gefasst worden.** Sie stand vorher +> auf einer falschen Prämisse: die Erstfassung von D-108 hielt das Kriechen über +> *jedes* Gebäude für den Ist-Zustand und wollte es nur aussprechen. Der Code +> prüft seit D-104 auf HQ, Lager und Kraftwerk. Der Inhaber hat daraufhin in +> Kenntnis der Lage neu entschieden — die Ankerliste wird **geöffnet**. Das +> Paket ist damit kein Dokumentationspaket mehr, sondern das einzige der ersten +> fünf, das Simulationsverhalten ändert. -Die Entscheidung ist getroffen (D-108): **jedes eigene Gebäude bleibt Bauanker**, -die Zone kriecht mit der Basis mit. Das ist klassisches C&C und koppelt Expansion -genau so an die Wirtschaft, wie die Verknappung es will. Was fehlt, ist, dass es -irgendwo steht. +**a) Die Messung — erledigt.** `tools/Nova.SimRunner.Tests/BuildZoneCapacityTests.cs` +beziffert die Startzone des HQ-Ankers in zwei Spuren: die echte Systemspur über +`ValidatePlacement` + `PlaceCompletedBuilding`, und ein Geometriemodell, das die +Systemspur beim heutigen Wert zellgenau reproduzieren muss, bevor seine +Variantenzahlen gelten. -Zu liefern: +| `MinimumBuildingDistanceCells` | Gebäude in der Startzone | +|---|---| +| **2** (Ist, D-104) | **15** | +| 1 | 23 (+53 %) | +| 0 | 23 — identisch zu 1, weil die Footprint-Belegung Abstand unter 1 ohnehin verbietet | + +Der einzige wirksame Hebel wäre 2 → 1. **Der Wert bleibt bei 2.** Die Messung +weist die gemeldete Enge nicht als Abstandsproblem aus, und die 15 sind ohnehin +nur eine untere Schranke für die *Anfangs*zone — Anker schieben die Grenze mit +jedem Bau nach außen. Der Test pinnt alle drei Konstanten und macht dieses Paket +erneut auf, falls eine davon später fällt. + +**b) Die Regeländerung.** In `ConstructionSystem.IsInsideBuildInfluence` entfällt +die Rollenprüfung: + +```csharp +// entfällt: +if (def.Role != UnitRole.HQ && def.Role != UnitRole.Storage && def.Role != UnitRole.Power) continue; +``` + +Jedes eigene, lebende und fertiggestellte Gebäude wird Anker. `BuildInfluenceRadiusCells` +bleibt 8, `MinimumBuildingDistanceCells` bleibt 2. + +**c) Der Docstring wird zweimal nachgezogen.** Er sagt heute „from an own +construction anchor" und nennt die Rollenliste nicht — genau diese Auslassung hat +die falsche Erstfassung von D-108 erzeugt. Erst auf den Ist-Zustand *mit* +Rollenliste (zusammen mit der Messung, damit der Fehler sofort aus dem Code +verschwindet), dann mit der Regeländerung auf die neue Fassung. -1. Den Docstring an `BuildInfluenceRadiusCells` so umschreiben, dass die Regel - *„ab jedem eigenen Bauanker"* nicht mehr nur ein Nebensatz ist, mit Verweis - auf D-108. -2. **Die Enge messen, bevor irgendetwas gedreht wird.** Der Bericht sagt, der - Platz sei „nach einigen Kraftwerken relativ schnell ausgeschöpft". Die - Vermutung aus #91 ist, dass nicht der Radius 8 die Ursache ist, sondern - `MinimumBuildingDistanceCells = 2`, das Zellen *innerhalb* der Zone sperrt. - Liefere eine Zahl, kein Gefühl: **wie viele Gebäude welcher Footprintgrößen - passen in die Startzone**, bei `MinimumBuildingDistanceCells` 2 gegen 1 - gegen 0? Als Test in `tools/Nova.SimRunner.Tests/`, damit die Zahl nicht - verfällt. -3. **Erst dann** entscheiden, ob der Wert fällt. Fällt er, ist das eine - Simulationsänderung mit eigenem PR und eigener Baseline-Bewegung — und der - Grund steht in der PR-Beschreibung mit alter und neuer Zahl. +> **Verhalten und Baseline nie im selben PR.** Teil b bewegt `RulesHash64`, die +> Determinismus-Baselines **und** den gepinnten Ausgang der kanonischen KI-Partie. +> Also: ein PR für die Regel, ein zweiter für die Baselines — und vorher ein mit +> dem Einheitenstrang abgestimmtes Merge-Fenster, weil `CanonicalAiOutcomeTests` +> arn gehört. -**Fertig wenn:** die Regel dokumentiert ist, die Kapazitätszahl als Test -existiert, und die Entscheidung über `MinimumBuildingDistanceCells` mit Zahl -begründet ist. +**Fertig wenn:** die Messung als Test liegt, der Docstring die geltende Regel +nennt, jedes Gebäude ankert, und die Baselines in einem eigenen PR nachgezogen +sind. ### 21.2 · Der Restbestand wird sichtbar (#86) — **kritisch** @@ -207,7 +232,8 @@ davor, und schreib die Rechnung in die PR-Beschreibung. ### 21.4 · Der Baubereich wird sichtbar (#91) -**Erst nach 21.1**, sonst zeigt das Overlay eine Regel, die sich danach ändert. +**Erst nach 21.1**, sonst zeigt das Overlay eine Regel, die sich danach ändert — +und seit der Neufassung von D-108 ändert sie sich wirklich. Beim Anklicken des HQ und im Platzierungsmodus wird der erlaubte Bereich angezeigt. **Nicht als Radius-Ring** — der wäre unehrlich, weil @@ -331,7 +357,7 @@ Drei von vier ergibt einen roten Test, der wie ein Determinismusfehler aussieht und keiner ist. Betrifft 21.3, 21.6 und 21.7. **R-2 · Verhalten und Baseline nie im selben PR.** Die wichtigste Regel des -Parallelbetriebs. 21.3, 21.6 und 21.7 ändern Simulationsverhalten und lassen +Parallelbetriebs. **21.1 Teil b**, 21.3, 21.6 und 21.7 ändern Simulationsverhalten und lassen `SnapshotGoldenBytesTests`, `CommandGoldenBytesTests`, `SimRandomGoldenTests` und `Determinism10000Tests` rot werden. Das ist ihr Zweck. Die Baseline wird in einem **eigenen** PR neu gesetzt, mit altem und neuem Wert im Text und der @@ -339,9 +365,9 @@ Begründung, warum die Änderung gewollt ist. Das Drehbuch `Determinism10000Scenario.cs` ist davon **nicht** betroffen und darf im selben PR nachgezogen werden. -**R-3 · 21.6 und 21.7 bewegen den gepinnten KI-Ausgang.** Eine andere Karte -heißt eine andere kanonische Partie. `CanonicalAiOutcomeTests` gehört dem -Einheitenstrang. **Vor** dem Merge von 21.6 mit arn abstimmen, in welchem +**R-3 · 21.1 Teil b, 21.6 und 21.7 bewegen den gepinnten KI-Ausgang.** Eine +andere Bauregel und eine andere Karte heißen eine andere kanonische Partie. `CanonicalAiOutcomeTests` gehört dem +Einheitenstrang. **Vor** dem Merge von 21.1 Teil b und 21.6 mit arn abstimmen, in welchem Merge-Fenster das läuft — „ein Fenster hat einen Strang". Zwei Stränge in einem Fenster machen einen roten Test nicht zuordenbar. @@ -355,6 +381,8 @@ verschwinden. Der getrackte Weg ist ausschließlich `tools/packaging/`. ## Fertig wenn +- [ ] Jedes eigene fertiggestellte Gebäude erweitert die Bauzone, und der + Docstring nennt die geltende Regel statt eines vagen „anchor" (21.1) - [ ] Ein Spieler liest den Restbestand jedes Vorkommens ab, ohne das Debug-HUD zu öffnen — als Zahl und am Kristallstand auf der Karte (21.2) - [ ] Der Baubereich ist vor dem Klick sichtbar, inklusive der gesperrten Zellen @@ -381,15 +409,19 @@ die neue Feldlage in den Eintrag, nicht nur „mehr Felder". ## Versionsrelevanz `minor`. Kein Vertrag bricht: kein neuer `CommandKind`, kein -`StateVersion`-Bump, keine Änderung an `SimDefinitions`. Die Kartenlage bewegt -Determinismus-Baselines, aber keine Schnittstelle. +`StateVersion`-Bump, keine Änderung an `SimDefinitions`. -> Falls 21.1 zu dem Ergebnis kommt, dass `MinimumBuildingDistanceCells` fällt, -> bewegt das `RulesHash64` — dann ist das ein eigener PR mit eigener D-ID, und -> die Versionsrelevanz dieses Pakets steigt auf die Regelrevision. +> **`RulesHash64` bewegt sich aber**, und zwar durch 21.1 Teil b (Ankerliste). +> Das ist eine Regelrevision und kein Schnittstellenbruch: alte und neue Builds +> können nicht miteinander spielen, aber nichts an der Schnittstelle ändert +> sich. Verteilte Testbuilds sind danach ungültig — siehe R-4. +> `MinimumBuildingDistanceCells` und `BuildInfluenceRadiusCells` bleiben +> unverändert; fällt später doch einer der beiden Werte, ist das ein eigener PR +> mit eigener D-ID. ## Änderungsverlauf | Version | Datum | Änderung | Autor | |---|---|---|---| +| 1.1.0 | 2026-08-18 | **Paket 21.1 neu gefasst.** Die Erstfassung hielt das Kriechen über jedes Gebäude für den Ist-Zustand; `IsInsideBuildInfluence` prüft seit D-104 auf HQ, Lager und Kraftwerk. Der ausführende Agent hat den Widerspruch gefunden und angehalten, der Inhaber hat D-108 in Kenntnis der Lage neu getroffen: die Ankerliste wird geöffnet. 21.1 ist damit eine Verhaltensänderung mit `RulesHash64`-Bewegung und eigenem Merge-Fenster; die Messung (15/23/23) ist erledigt und `MinimumBuildingDistanceCells` bleibt bei 2. R-2, R-3, Versionsrelevanz und „Fertig wenn" nachgezogen | Orchestrator | | 1.0.0 | 2026-08-17 | Erstfassung aus [20_Vorschlag_Verknappungsfolgen.md](20_Vorschlag_Verknappungsfolgen.md) nach den Inhaberentscheidungen D-108 und D-109. #85 als vom Einheitenstrang erledigt ausgetragen, #89/#90 als Vertragsflächen ausgeschlossen | Orchestrator | diff --git a/docs/production/hashkrieg/AUFTRAG_Verknappungsfolgen.md b/docs/production/hashkrieg/AUFTRAG_Verknappungsfolgen.md index 99db92d..21b8c62 100644 --- a/docs/production/hashkrieg/AUFTRAG_Verknappungsfolgen.md +++ b/docs/production/hashkrieg/AUFTRAG_Verknappungsfolgen.md @@ -1,6 +1,6 @@ # Großauftrag: Die Folgen der Verknappung -**Version:** 1.0.0 | **Status:** verbindlich | **Erteilt:** 2026-08-17 | **Auftraggeber:** Inhaber | **Ausführung:** Kimi (Maintainer-Seite) | **Umfang:** Blöcke 1–2, entspricht Sprint 21 und Sprint 18 | **Grundlage:** `main` @ `3e10c48` | **Leitsatz:** erst sichtbar machen, was die Simulation weiß, dann die Karte anfassen +**Version:** 1.1.0 | **Status:** verbindlich | **Erteilt:** 2026-08-17 | **Auftraggeber:** Inhaber | **Ausführung:** Kimi (Maintainer-Seite) | **Umfang:** Blöcke 1–2, entspricht Sprint 21 und Sprint 18 | **Grundlage:** `main` @ `3e10c48` | **Leitsatz:** erst sichtbar machen, was die Simulation weiß, dann die Karte anfassen ## Vorrangregel @@ -103,7 +103,7 @@ Abhängigkeit sortiert, nicht nach Aufwand: | | Paket | Issue | Hängt an | |---|---|---|---| -| 21.1 | Territoriumsregel aussprechen und Enge messen | #92 → D-108 | — | +| 21.1 | **Jedes Gebäude wird Bauanker** — Verhaltensänderung | #92 → D-108 | — | | 21.2 | **Restbestand sichtbar machen** (kritisch) | #86 | — | | 21.3 | Startmenge rechnen statt raten | #87 | 21.2 | | 21.4 | Baubereich sichtbar machen | #91 | 21.1 | @@ -118,13 +118,20 @@ Abhängigkeit sortiert, nicht nach Aufwand: dieser Sprint existiert. Was fällt, kommt mit Begründung in den [ScopeLedger](../ScopeLedger.md). -**Zwei Dinge, die du aus der Sprintdatei allein nicht siehst:** - -- **21.6 und 21.7 bewegen den gepinnten Ausgang der kanonischen KI-Partie.** Eine - andere Karte heißt eine andere Partie. `CanonicalAiOutcomeTests` gehört dem - Einheitenstrang. Beide Pakete brauchen ein eigenes Merge-Fenster, abgestimmt - mit @arn-c0de — „ein Fenster hat einen Strang". Sag Bescheid, bevor du 21.6 - aufmachst, statt danach. +**Drei Dinge, die du aus der Sprintdatei allein nicht siehst:** + +- **21.1 hat am 2026-08-18 die Richtung gewechselt.** Es war als reines + Dokumentationspaket geplant, weil D-108 in seiner Erstfassung eine Regel + festschreiben wollte, die der Code gar nicht hatte. Der Widerspruch wurde beim + Umsetzen gefunden und gemeldet — genau so, wie es die Vorrangregel oben + verlangt. Der Inhaber hat neu entschieden: die Ankerliste wird **geöffnet**, + jedes eigene fertiggestellte Gebäude wird Anker. Damit ist 21.1 das einzige der + ersten fünf Pakete, das Simulationsverhalten ändert. +- **21.1 Teil b, 21.6 und 21.7 bewegen den gepinnten Ausgang der kanonischen + KI-Partie.** Eine andere Bauregel und eine andere Karte heißen eine andere + Partie. `CanonicalAiOutcomeTests` gehört dem Einheitenstrang. Alle drei + brauchen ein eigenes Merge-Fenster, abgestimmt mit @arn-c0de — „ein Fenster hat + einen Strang". Sag Bescheid, **bevor** du aufmachst, statt danach. - **21.2 legt kein Feld in den Zustand.** Die Anzeige „6.420 / 9.000" braucht die Anfangsreserve. Sie kommt aus der kanonischen Kartenlage, **nicht** aus einem neuen Feld in `AetheriumField` — das wäre `Simulation/State/`-Layout und damit @@ -246,8 +253,9 @@ Entscheidung kurz im PR. „nur ein Feld" in `AetheriumField` - Die Tickreihenfolge in `MatchRunner` ändern oder ein neues System registrieren - Die Anzahl oder Lage der Aetheriumfelder ohne die Symmetrieprüfung aus D-107 -- `MinimumBuildingDistanceCells` oder `BuildInfluenceRadiusCells` ändern, bevor - die Messung aus 21.1 vorliegt +- `MinimumBuildingDistanceCells` oder `BuildInfluenceRadiusCells` ändern. Die + Messung aus 21.1 liegt vor (15/23/23) und der Inhaber hat entschieden: **beide + Werte bleiben.** Wer sie doch bewegen will, braucht eine eigene D-ID - Ein Paket streichen, das nicht auf der Abwurfliste steht - Irgendetwas in fremdem Terrain, auch wenn es „nur eine Zeile" wäre @@ -273,4 +281,5 @@ nötig wäre, und auf die Entscheidung warten. | Version | Datum | Änderung | Autor | |---|---|---|---| +| 1.1.0 | 2026-08-18 | Paket 21.1 nach der Neufassung von D-108 als Verhaltensänderung ausgewiesen: die Ankerliste in `IsInsideBuildInfluence` wird geöffnet, statt eine nicht existente Bestandsregel festzuschreiben. Merge-Fenster-Hinweis auf 21.1 Teil b erweitert, die Messung als erledigt und beide Konstanten als unverändert eingetragen | Orchestrator | | 1.0.0 | 2026-08-17 | Erstfassung: Sprint 21 und Sprint 18 gebündelt, gegen `main` @ `3e10c48` geprüft, Grenzen und stille Fallen benannt. Enthält die Berichtigung zur lokalen Testbarkeit gegenüber dem vorigen Auftrag | Orchestrator |