fix(economy): Sammler halten bei vollem Lager an, und die HQ-Decke trägt das Startguthaben (#136, #131) - #141
Merged
Merged
Conversation
cubetribe
added a commit
that referenced
this pull request
Aug 31, 2026
…131 nicht mehr gibt (#143) ## Was Der Graybox-Beweis prüfte, dass der **Startüberhang verfällt** — den es seit [#131](#131) nicht mehr gibt. ```csharp Assert.That(creditsBaseline, Is.InRange(EconomySystem.HqBaseCapacityAE, 2999L), "D-106 deterministically decays the initial overhang …"); ``` Mit der auf 3.000 angehobenen Decke wird daraus `InRange(3000, 2999)` — ein ungültiger Bereich. Der Test starb an `ArgumentException: from must be less than to`. Die Zusicherung sagt jetzt das Gegenteil, und das ist der Punkt der Änderung: die Eröffnungsbilanz passt unter die Decke und darf **nicht** verfallen. ## Wie das durch die CI gekommen ist Genau so, wie [#110](#110) es beschreibt: **`tests.yml` fährt nur die headless-Kette.** PR [#141](#141) war dort mit 754/754 grün und ist gemergt worden — während dieser PlayMode-Test rot wurde, ohne dass irgendetwas es meldete. Aufgefallen ist es nur, weil ich vor dem Bauen von Hand `-runTests -testPlatform PlayMode` gefahren habe. Ohne diesen Schritt wäre der Fehler im Build gelandet, und der nächste Testbericht hätte ihn als Spielfehler zurückgemeldet. **Das ist kein Argument gegen den Merge, sondern der dritte Beleg für #110.** Der ausführende Worker hatte den Zusammenhang sogar vorhergesagt („der PlayMode-Graybox-Test, dessen Überhang-Prämisse mit E-2 entfällt") — die Vorhersage stand im Bericht, nur konnte sie nichts rot machen. ## Nachweis - Unity PlayMode: **15/15 grün** (vorher 14/15) - Unity EditMode: **663/663 grün** - `dotnet test tools/Nova.SimRunner.Tests`: 768/768 grün Beide Unity-Spuren vom Orchestrator lokal gefahren, Batchmode ohne `-quit`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Warum
Aus der Proberunde des Inhabers vom 31.08.2026 auf Build
97e5459:Fixes #136
Fixes #131
#136 — gebremst wird beim Aufnehmen, nicht beim Abliefern
Genau so war es implementiert, und die Einzahlungsdeckelung ist gewollt (D-024, „Überschuss verfällt"). Was die Regel nicht vorsah: dass der Sammler trotzdem weiterfährt. Seit die Vorkommen endlich sind (#80) ging dabei nicht nur die Fahrt verloren, sondern der Rohstoff selbst — das Feld hatte die Menge bereits abgegeben, unwiederbringlich, während der Spieler zusah und es für Fortschritt hielt.
Der Sammler hält jetzt beim Aufnehmen an, nicht erst beim Abliefern. Das ist die ehrlichere Stelle: was nie abgebaut wurde, ist nicht verloren. Er behält Auftrag und Ladung, und nimmt die Arbeit von selbst wieder auf, sobald Platz ist — durch ein neues Lager oder schlicht durch Ausgeben. Drei Tests pinnen den Halt, beide Wege der Wiederaufnahme und die Grenze „1 AE Platz heißt arbeiten"; ein Sammler, der nach dem Lagerbau nicht wieder anfängt, wäre schlimmer als das Problem.
Was ausdrücklich bleibt: dass der Überschuss verfällt. Das ist D-024. Geändert hat sich nur, ob überhaupt noch abgebaut wird.
#131 — die Decke trägt wieder, was das Spiel austeilt
HqBaseCapacityAEsteigt von 2.000 auf 3.000 AE.Die Herkunft ist die eigentliche Geschichte: die 3.000 AE Startguthaben kamen mit D-077 als bewusst gesetzter Eröffnungspuffer, die 2.000er-Decke erst viel später mit D-024 / Sprint 16.4. Beide Konstanten taten genau, was ihre Entscheidung sagte — nur hob die zweite die erste auf, und niemandem fiel es auf. Ein Drittel des Startguthabens verdampfte in den ersten fünfzehn Sekunden jeder Partie.
Bewusst in Kauf genommen: das Lagergebäude wird früh weniger wertvoll, weil man erst ab 3.000 eines braucht.
Der eigentliche Ertrag ist der Test, den es bis heute nicht gab. Kein Test sah Startguthaben und Decke zusammen — genau deshalb blieb der Widerspruch drei Wochen stehen. Er ist jetzt da.
Die nachgezogenen Pins — jeder einzeln begründet
SellStorage_…SellStorage_…VerfallCurrentRulesHash_MovesPastRevisionTwo…0x05CCA847…→0xD1B68383…HqBaseCapacityAEist eine gehashte Regelkonstante — die Bewegung ist der ZweckRulesRevisionOneAndTwo…(Rev 1 + 2)CanonicalAiMatch_DecidesOnThePinnedTick…0x10B83E94…→0x4A861D9F…StartField_…(4 Tests)Die Startfeld-Messung: Fixture repariert, Zahlen unverändert
Die vier 21.3-Tests schlugen mit „field not exhausted after 20000 ticks" fehl — das Feld wurde nie leer. Grund:
CapacityForliefert für einen Slot ohne fertiges HQ eine Decke von null, und die Fixture spawnte nur eine Raffinerie. Seit #136 heißt das „permanent voll", also rührte sich kein Sammler mehr.Die Fixture bekommt deshalb ein HQ und einen Verbraucher, der das Konto jeden Tick leert. Beides stellt her, was sie immer zu messen behauptete: wie lange das Feld bei reiner Ernterate trägt, mit der Lagerdecke bewusst aus der Frage heraus. Die gepinnten Tickzahlen sind unverändert (4527 / 2263 / 1509) — die Erntedynamik hat sich nie geändert, nur die Bedingung, unter der sie pausiert.
Die Revision-Pins überstreichen einen bekannten Defekt
RulesRevisionOneAndTwo_GoldenHashesRemainByteStablesichert zu, dass die historischen Regel-Revisionen eingefroren sind. Eine Änderung an einer heutigen Konstante hat sie bewegt — weilComputeRulesHash64für jede Revision die heutigen Konstanten hasht und nur die Feldzahl historisch ist. Das ist #138.Die Neusetzung macht den Test grün. Sie macht die Zusicherung nicht wieder wahr. Damit das der nächste Leser nicht übersieht, steht der Verweis auf #138 jetzt als Kommentar direkt an der Zusicherung — ein sauberer grüner Test an dieser Stelle wäre irreführend.
Der gepinnte KI-Ausgang gehört dem Einheitenstrang
CanonicalAiOutcomeTestsist Arns Datei. Die Wirtschaftsänderung bewegt die kanonische Partie, und das ist exakt Risiko R-3 aus Sprint 21, das hier eintritt. Der Pin ist nachgezogen, damit die Kette grün ist — das Merge-Fenster, das ihn bewegt hat, ist dieses hier. Wer den alten Wert sucht:0x10B83E94F86F2E55.Nachweis
dotnet test tools/Nova.SimRunner.Tests -c Release: 754/754 grün, vom Orchestrator gefahrenbaseline-guardgeschützten Golden-Byte-Dateien ist berührt — keinbaseline-reset-approvednötig. Alle Bewegungen sind Erwartungswerte, und der Wächter sagt in seinem eigenen Kommentar, dass eine Testanpassung für sich keine Verhaltensänderung istmainliegtHerkunft
Erarbeitet von Kimi K3 als delegiertem Worker; die acht roten Tests hat er gemeldet statt grün gemacht, mit alten und neuen Werten. Die Pins, die Fixture-Reparatur und der #138-Vermerk stammen vom Orchestrator.