M1b: Brücke und Hülle #6

2026-10-01T11:45:42Z

steven commented

2026-10-01 11:45:42 +00:00

Mit diesem Branch wird der Rust-Kern aus M1a in Godot spielbar. Eine Figur läuft über die Testkarte und schlägt Stein. Die Welt wird gespeichert, geladen und aufgezeichnet. Umgesetzt nach dem Plan docs/superpowers/plans/2026-10-01-m1b-bruecke-und-huelle.md.

Was drin ist

Kern (core/)

Schärfere Wächter. core/clippy.toml sperrt Pfade wie HashMap oder std::fs::read. Ein Textwächter verbietet weitere Begriffe, jetzt auch gruppierte std-Importe und globale Sperren. Ein Test hält den Kern frei von fremden Crates.
Speicherstand in Version 2 mit Prüfsumme. Beim Laden werden unmögliche Zustände abgelehnt (World::load, check_restorable).
Recording::step koppelt die Aufzeichnung an den Weltschritt.

Brücke (bridge/)

Die GDExtension-Klasse GwSession (godot-rust 0.5.5) bietet Befehle, Takt und Lesezugriffe; Ereignisse kommen als Dictionaries. Eine Panik im Kern stoppt die Sitzung, danach wird nichts mehr gespeichert.

Hülle (game/)

Fester Takt mit 20 Takten pro Sekunde, Bewegung über das Kachelraster, Kartenansicht, Zielrahmen, Anzeige von Steinen und Meldungen.
Texte auf Deutsch und Englisch; die Tasten (WASD, Maus, F5, F9, Esc) werden im Code belegt.
Speichern geht über eine temporäre Datei. Der alte Stand wird vorher als Sicherung beiseitegelegt und nach einem Absturz zurückgeholt.
Automatisches Speichern alle zwei Minuten und beim Schließen. Ein unbrauchbarer Stand wird beiseitegelegt, nie überschrieben.
Aufzeichnungen der letzten zehn Sitzungen für Fehlerberichte.
Ein eigener GDScript-Testläufer zählt auch Laufzeitfehler als Fehlschlag.

Drumherum

play.bat baut die Brücke und startet das Spiel.
CLAUDE.md mit allen Regeln für Kern, Brücke und Hülle.
Fragebogen für den Spieltest: docs/playtests/m1b.md.

Prüfung

Acht Tasks, jeder einzeln geprüft. Tasks 6 und 7 brauchten je eine Korrekturrunde. Task 8 bekam einen Nachtrag: Der erste Godot-Import stürzt beim Beenden ab, deshalb wiederholt play.bat ihn.
Die Abschlussprüfung des ganzen Branches ergab „mit Korrekturen". Der wichtigste Befund: Unter Windows löschte ein gescheitertes Umbenennen beim Speichern den alten Spielstand. Alle zehn Korrekturen sind enthalten und nachgeprüft.
Stand: 110 Rust-Tests (Debug und Release) und 44 GDScript-Tests bestanden; rustfmt und Clippy ohne Befund.

Entscheidungen während der Umsetzung

Die Wächter aus Task 1 haben keinen klassischen roten Schritt. Ein absichtlicher Verstoß beweist, dass sie greifen.
Zwei Tests erzeugen absichtlich eine WARNING-Zeile, weil sie unbrauchbare Spielstände laden. Warnungen zählen nicht als Fehler.
Hud.message() und Hud.stone_text() bleiben als kleine Lesezugriffe für Tests.
Die Commit-Zuschreibung nennt das Modell, das den Commit erstellt hat.
[dev-dependencies] bleiben im Kern erlaubt, weil sie nie ins Spiel gelangen.
Der Plan zählt 15 World-Tests und 35 GDScript-Tests. Richtig sind 16 World-Tests und nach den Korrekturrunden der Tasks 38 GDScript-Tests; nach der Abschlussprüfung sind es 44.
Der erste Godot-Import eines frischen Checkouts stürzt beim Beenden ab. play.bat wiederholt ihn deshalb einmal, und CLAUDE.md erklärt es.
Task 6: Jeder Schreibvorgang wird zurückgelesen, bevor ein neuer Stand den alten ersetzt.
Task 7: Solange sich ein unbrauchbarer Stand nicht beiseitelegen lässt, ist Speichern gesperrt. Ein gescheitertes automatisches Speichern wird gemeldet.
Ein möglicher Windows-Fehlerdialog beim allerersten Import bleibt unbehandelt. Die Absturzläufe kehrten ohne Hängen zurück.
Die Korrekturwelle nach der Abschlussprüfung umfasst drei Teile: den Speicherfehler unter Windows, zwölf kleine Punkte aus der Sichtung und Tests für das automatische Speichern und das Speichern beim Schließen.
In #5 verschoben:
- Aufzeichnungen nach einem Absturz oder einer Kern-Panik
- vorübergehende Dateifehler beim Start
- die Konsole von play.bat nach einem Absturz
- das Weiterdrehen der Logs durch Prüfläufe
- die Restpunkte der Nachprüfung

Verschoben

#5 sammelt die bewusst verschobenen Punkte aus M1b.
Die M1c-Punkte aus #2 gelten weiter.

Spieltest

play.bat im Hauptordner doppelklicken, dann den Fragebogen docs/playtests/m1b.md ausfüllen.

Closes #4

🤖 Generated with Claude Code

Mit diesem Branch wird der Rust-Kern aus M1a in Godot spielbar. Eine Figur läuft über die Testkarte und schlägt Stein. Die Welt wird gespeichert, geladen und aufgezeichnet. Umgesetzt nach dem Plan `docs/superpowers/plans/2026-10-01-m1b-bruecke-und-huelle.md`. ## Was drin ist **Kern (`core/`)** - Schärfere Wächter. `core/clippy.toml` sperrt Pfade wie `HashMap` oder `std::fs::read`. Ein Textwächter verbietet weitere Begriffe, jetzt auch gruppierte `std`-Importe und globale Sperren. Ein Test hält den Kern frei von fremden Crates. - Speicherstand in Version 2 mit Prüfsumme. Beim Laden werden unmögliche Zustände abgelehnt (`World::load`, `check_restorable`). - `Recording::step` koppelt die Aufzeichnung an den Weltschritt. **Brücke (`bridge/`)** - Die GDExtension-Klasse `GwSession` (godot-rust 0.5.5) bietet Befehle, Takt und Lesezugriffe; Ereignisse kommen als Dictionaries. Eine Panik im Kern stoppt die Sitzung, danach wird nichts mehr gespeichert. **Hülle (`game/`)** - Fester Takt mit 20 Takten pro Sekunde, Bewegung über das Kachelraster, Kartenansicht, Zielrahmen, Anzeige von Steinen und Meldungen. - Texte auf Deutsch und Englisch; die Tasten (WASD, Maus, F5, F9, Esc) werden im Code belegt. - Speichern geht über eine temporäre Datei. Der alte Stand wird vorher als Sicherung beiseitegelegt und nach einem Absturz zurückgeholt. - Automatisches Speichern alle zwei Minuten und beim Schließen. Ein unbrauchbarer Stand wird beiseitegelegt, nie überschrieben. - Aufzeichnungen der letzten zehn Sitzungen für Fehlerberichte. - Ein eigener GDScript-Testläufer zählt auch Laufzeitfehler als Fehlschlag. **Drumherum** - `play.bat` baut die Brücke und startet das Spiel. - `CLAUDE.md` mit allen Regeln für Kern, Brücke und Hülle. - Fragebogen für den Spieltest: `docs/playtests/m1b.md`. ## Prüfung - Acht Tasks, jeder einzeln geprüft. Tasks 6 und 7 brauchten je eine Korrekturrunde. Task 8 bekam einen Nachtrag: Der erste Godot-Import stürzt beim Beenden ab, deshalb wiederholt `play.bat` ihn. - Die Abschlussprüfung des ganzen Branches ergab „mit Korrekturen". Der wichtigste Befund: Unter Windows löschte ein gescheitertes Umbenennen beim Speichern den alten Spielstand. Alle zehn Korrekturen sind enthalten und nachgeprüft. - Stand: 110 Rust-Tests (Debug und Release) und 44 GDScript-Tests bestanden; rustfmt und Clippy ohne Befund. ## Entscheidungen während der Umsetzung - Die Wächter aus Task 1 haben keinen klassischen roten Schritt. Ein absichtlicher Verstoß beweist, dass sie greifen. - Zwei Tests erzeugen absichtlich eine WARNING-Zeile, weil sie unbrauchbare Spielstände laden. Warnungen zählen nicht als Fehler. - `Hud.message()` und `Hud.stone_text()` bleiben als kleine Lesezugriffe für Tests. - Die Commit-Zuschreibung nennt das Modell, das den Commit erstellt hat. - `[dev-dependencies]` bleiben im Kern erlaubt, weil sie nie ins Spiel gelangen. - Der Plan zählt 15 World-Tests und 35 GDScript-Tests. Richtig sind 16 World-Tests und nach den Korrekturrunden der Tasks 38 GDScript-Tests; nach der Abschlussprüfung sind es 44. - Der erste Godot-Import eines frischen Checkouts stürzt beim Beenden ab. `play.bat` wiederholt ihn deshalb einmal, und `CLAUDE.md` erklärt es. - Task 6: Jeder Schreibvorgang wird zurückgelesen, bevor ein neuer Stand den alten ersetzt. - Task 7: Solange sich ein unbrauchbarer Stand nicht beiseitelegen lässt, ist Speichern gesperrt. Ein gescheitertes automatisches Speichern wird gemeldet. - Ein möglicher Windows-Fehlerdialog beim allerersten Import bleibt unbehandelt. Die Absturzläufe kehrten ohne Hängen zurück. - Die Korrekturwelle nach der Abschlussprüfung umfasst drei Teile: den Speicherfehler unter Windows, zwölf kleine Punkte aus der Sichtung und Tests für das automatische Speichern und das Speichern beim Schließen. - In #5 verschoben: - Aufzeichnungen nach einem Absturz oder einer Kern-Panik - vorübergehende Dateifehler beim Start - die Konsole von `play.bat` nach einem Absturz - das Weiterdrehen der Logs durch Prüfläufe - die Restpunkte der Nachprüfung ## Verschoben - #5 sammelt die bewusst verschobenen Punkte aus M1b. - Die M1c-Punkte aus #2 gelten weiter. ## Spieltest `play.bat` im Hauptordner doppelklicken, dann den Fragebogen `docs/playtests/m1b.md` ausfüllen. Closes #4 🤖 Generated with [Claude Code](https://claude.com/claude-code)

steven added this to the M1 Fundament milestone 2026-10-01 11:45:42 +00:00

steven added 21 commits 2026-10-01 11:45:43 +00:00

Umsetzungsplan M1b: Brücke und Hülle 5be2764276

Zweiter von vier Plänen für Meilenstein 1. Acht Tasks härten den Kern
(Wächter, Speicherstand mit Prüfsumme und Prüfung beim Laden,
Aufzeichnung am Weltschritt) und bauen die GDExtension-Brücke sowie die
Godot-Hülle mit Takt, Figur, Karte, Anzeige, Texten, Dateien und
Startskript. Der Code im Plan ist vorab geprüft, jede Task-Grenze
einzeln.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Wächter für den Kern schärfen 8573a68901

Clippy sperrt im Kern Hash-Tabellen, Uhr, Dateien, Threads und
Umgebung über aufgelöste Pfade, auch bei Aliasen und gruppierten
Importen. Der Textwächter kennt globalen veränderlichen Zustand und
Prozesse, prüft sich selbst, und ein neuer Test hält die Abhängigkeiten
des Kerns leer.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

Speicherstand mit Prüfsumme und Prüfung beim Laden ef728cd100

Snapshots tragen jetzt eine Prüfsumme (Format 2). Beim Wiederherstellen
werden Zustände abgelehnt, die die Regeln nie erzeugen: zu große Takte,
mehr als vier Spieler online, doppelte Schlüssel, unmögliche
Wartezeiten. World::load ersetzt den öffentlichen Aufruf von
set_all_offline. Die festgeschriebenen Werte sind bewusst angepasst und
um einen Offline-Spieler und das Kartenformat ergänzt.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

Aufzeichnung an den Weltschritt koppeln 5dacbf2222

Recording::step führt einen Takt aus und zeichnet ihn auf. Andere
Befehle als die ausgeführten können so nicht in eine Aufzeichnung
geraten. Aufzeichnung und Welt prüfen gegenseitig ihren Takt, und ein
beschädigter Startzustand fällt schon beim Einlesen auf.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

Brücke zu Godot und Godot-Projekt bd0f588714

Die GDExtension grovewright-bridge gibt den Kern als Klasse GwSession
an GDScript weiter: Befehle einreihen, einen Takt ausführen, Karte und
Inventar lesen, speichern, laden, aufzeichnen. Eine Panik im Kern macht
die Sitzung defekt, statt einen guten Speicherstand zu überschreiben.
Das Godot-Projekt bekommt einen Testläufer, der auch Laufzeitfehler als
Fehlschlag zählt.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

Takt und Bewegung der Figur 2607df8a97

TickClock rechnet Bildzeit in Takte um und holt nach einem Ruckler
höchstens fünf Takte auf. GridMotion bewegt einen Körper über das
Kachelraster und lässt ihn an Wänden entlanggleiten. Die Figur läuft
fünf Felder pro Sekunde, außerhalb des Gleichschritts.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

Texte, Tasten und Dateien ccf9813c80

Alle Texte stehen in einer Tabelle mit Deutsch und Englisch, die das
Spiel zur Laufzeit liest. Die Tasten werden in Code angelegt, nach
physischer Position. SaveStore verwaltet den Spielerschlüssel dieser
Installation, schreibt den Speicherstand über eine temporäre Datei,
legt unbrauchbare Stände beiseite und behält die zehn neuesten
Aufzeichnungen.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

SaveStore prüft jeden Schreibvorgang 3761966303

Ein Speicherstand ersetzt den vorigen nur noch, wenn er vollständig
geschrieben und zurückgelesen wurde. Ein nicht gespeicherter
Spielerschlüssel wird gemeldet, und set_aside_save meldet, wenn nichts
verschoben wurde.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

Darstellung und Hauptszene 68483c648e

Die Hauptszene verbindet Kern, Karte, Figur, Anzeige und Dateien:
fester Takt, Laufen, Stein schlagen in Reichweite, Speichern mit F5,
Laden mit F9, Pause mit Esc, automatisches Speichern alle zwei Minuten
und beim Schließen. Die Karte erscheint in Platzhalterfarben, bis in
M1d ein Stil gewählt ist. Ein Werkzeug macht Bildschirmfotos ohne
Handarbeit.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

Speichern meldet Fehler und schützt unbrauchbare Stände 754d7f1e92

Lässt sich ein unbrauchbarer Spielstand nicht beiseitelegen, bleibt das
Speichern gesperrt, bis ein Stand erfolgreich geladen wird; so wird er
nie überschrieben. Ein gescheitertes automatisches Speichern zeigt
SAVE_FAILED, und jedes gescheiterte Speichern wird protokolliert.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

Startskript, Regeln und Probelauf für M1b 68d063209c

play.bat baut die Brücke und startet das Spiel. CLAUDE.md beschreibt
jetzt Kern, Brücke und Hülle mit allen Prüfbefehlen, die Versionsregel
für festgeschriebene Werte und die Zuschreibung in Commits. Ein
Fragebogen begleitet den ersten Probelauf.

Der erste Godot-Import in einem frischen Checkout stürzt beim Beenden
ab; play.bat wiederholt ihn deshalb einmal.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

Spielstand bleibt erhalten, wenn das letzte Umbenennen scheitert 842213c574

SaveStore.write_save verschob die geprüfte Temporärdatei direkt auf
world.grw. Godot löscht unter Windows ein vorhandenes Ziel, bevor es die
Datei verschiebt. Scheiterte die Verschiebung, zum Beispiel weil ein
Virenscanner world.grw.tmp festhielt, war der vorige Spielstand schon weg.

Jetzt wird der vorige Stand zuerst nach world.grw.bak verschoben, dann
rückt die Temporärdatei nach. Scheitert das, kommt der Stand aus der
Sicherung zurück; nach Erfolg wird die Sicherung gelöscht. Bleibt nach
einem Absturz zwischen den beiden Verschiebungen nur world.grw.bak übrig,
holt SaveStore sie beim Öffnen des Ordners zurück.

Neue Tests: ein offenes Handle auf world.grw.tmp, eine blockierte
Sicherung, die Wiederherstellung aus der Sicherung und dass eine
Sicherung einen vorhandenen Stand nie ersetzt.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

Textwächter erkennt gruppierte std-Importe und globale Sperren fc8d5cb164

Mit `use std::{fs, process};` und anschließendem `fs::remove_file(…)`
kam bisher beides durch: Der Textwächter suchte `std::fs` wörtlich, und
Clippy kennt nur die aufgelisteten Funktionen. Globaler veränderlicher
Zustand über `static` mit Mutex, RwLock, OnceLock oder LazyLock wurde
auch nicht erkannt.

Neu in FORBIDDEN: `std::{` (gruppierte Importe verbergen dem Text die
Modulnamen) sowie Mutex, RwLock, OnceLock und LazyLock. Der Kern in
core/src nutzt nichts davon. Der Kommentar in core/clippy.toml behauptet
jetzt nur noch, was Clippy leistet, und CLAUDE.md nennt die Regel, dass
jeder std-Pfad in einer eigenen use-Zeile steht.

Der bestehende Selbsttest every_forbidden_term_is_detected deckt die
neuen Einträge ab.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

Test: volle Spielerliste mit vielen Offline-Spielern wird geladen 8aaeae5cf7

Eine Welt kennt bis zu 16 Spieler, von denen höchstens vier online sind.
Kein Test lud eine Welt mit mehr als vier bekannten Spielern; ein Fehler,
der in check_restorable alle bekannten statt der Online-Spieler zählt,
hätte gültige Spielstände zurückgewiesen und blieb unbemerkt. Mit dem
Koop-Spiel in M1c sind mehr als vier bekannte Spieler der Normalfall.

Der neue Test baut die Welt über Befehle auf: 16 Schlüssel treten in
Vierergruppen bei, jede Gruppe außer der letzten geht wieder, bevor die
nächste kommt. from_snapshot muss dieselbe Welt liefern, load alle Spieler
offline. Mit dem Fehler (alle Spieler gezählt) schlägt der Test mit
Invalid("online players") fehl.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

Test: Startzeitpunkt einer dekodierten Aufzeichnung ist festgeschrieben d986f2a5db

Recording::from_bytes leitet start_tick aus der gespeicherten Startwelt
ab. Kein Test prüfte das: Setzte ein Fehler start_tick beim Dekodieren
auf 0, blieb er unbemerkt, und eine so dekodierte Aufzeichnung würde
beim erneuten Kodieren oder Verlängern abstürzen.

Der Test a_recording_can_start_in_the_middle_of_a_session kodiert die
Aufzeichnung jetzt, dekodiert sie wieder und prüft, dass sie beim
selben Takt endet und der ursprünglichen gleicht. Mit start_tick = 0
beim Dekodieren schlägt er fehl (Endtakt 70 statt 120).

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

Testläufer meldet einen Fehler, wenn kein Test lief 400556134f

quit(1 if failed > 0 else 0) beendete einen Lauf mit "0 passed, 0 failed"
mit Code 0, zum Beispiel nachdem der Testordner umbenannt wurde oder alle
Tests falsch benannt waren. Die Prüfliste sah dann grün aus, ohne etwas
geprüft zu haben.

Der Läufer endet jetzt auch mit Code 1, wenn kein Test bestanden wurde.
Der Doc-Kommentar sagt das. Einmal von Hand geprüft: Mit einem Dateifilter,
den keine Testdatei erfüllt, meldete der alte Läufer 0 passed, 0 failed
mit Code 0, der neue endet mit Code 1.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

Testdateien: Löschen nur unter user://tests, Altlasten räumen, Wortlaut dff213cc61

user://tests liegt im echten Benutzerordner des Spiels, neben Spielstand,
Schlüssel und Aufzeichnungen des Spielers. TestFiles.remove_dir löschte
jeden Pfad, den es bekam; ein falsches Argument hätte echte Spielerdateien
gelöscht. Tests, die früh mit einem Laufzeitfehler abbrachen, ließen ihren
Ordner zurück (es lagen 15 solche Ordner im Benutzerordner).

- remove_dir vereinfacht den Pfad (simplify_path) und verweigert alles,
  was nicht user://tests oder darunter liegt, mit push_error und ohne zu
  löschen. Die Wurzel steht in der Konstante TestFiles.ROOT, die auch
  temporary_dir benutzt.
- run_tests.gd entfernt user://tests zu Beginn von _run_all, vor dem
  Fehlerzähler, aber nur wenn der Ordner existiert, weil Godot beim
  Auflisten eines fehlenden Ordners einen Fehler meldet.
- CLAUDE.md sagt jetzt, dass die Tests unter user://tests schreiben und
  nie die echten Dateien des Spielers anfassen.

Das Verweigern wurde einmal von Hand geprüft, mit einem Wegwerfskript auf
selbst angelegten Ordnern: Ohne Schutz löschte remove_dir sie, mit Schutz
bleiben sie samt Datei stehen und es erscheint ein Fehler, auch für einen
Geschwisterordner user://tests_probe und für user://tests/../…. Danach
waren die 15 Altlasten verschwunden und die Ausgabe fehlerfrei, auch ohne
vorhandenen Ordner user://tests.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

main.gd: Kommentar zu dig_at richtigstellen, Autosave-Takt ableiten bd8533e189

Der Kommentar an dig_at sagte, der Kern prüfe alles außer der
Abklingzeit. Das stimmt nicht: Der Kern prüft Abklingzeit, Feld,
Gelände, Werkzeugstufe und freien Platz, aber nicht die Reichweite. Die
prüft nur die Hülle (in _update_marker und _try_dig), weil die Figuren
außerhalb des Gleichschritts laufen und der Kern ihren Ort nicht kennt.
Der Plan für M1c darf sich nicht darauf verlassen. Der Kommentar nennt
jetzt, was der Aufrufer und was der Kern prüft.

AUTOSAVE_TICKS wiederholte mit 2400 die Taktrate von 20 pro Sekunde. Die
Konstante wird jetzt als zwei Minuten aus GwSession.TICKS_PER_SECOND
abgeleitet; GDScript nimmt das in einer const an und rechnet 2400.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

Fragebogen M1b: harter Fels und Aufzeichnung nach einem Absturz 0b20dd5459

Frage 3 sagte, ein Fels brauche drei Schläge. Das gilt nur für weichen
Fels. Harter Fels (ab etwa 22 Feldern vom Start) lässt sich mit der
Startspitzhacke nicht abbauen; Schläge darauf bewirken nichts, und das
Feld bleibt grün umrandet. Ein Spieltester hielte das für einen Fehler.
Der Fragebogen sagt es jetzt vorher.

Frage 5 bat um die neueste Aufzeichnung. Eine Aufzeichnung entsteht aber
nur beim Schließen des Fensters oder beim Laden mit F9. Nach einem
Absturz oder nach der Meldung „Die Simulation wurde angehalten“ gibt es
keine Aufzeichnung dieser Sitzung, und die neueste Datei gehört zu einer
früheren. Dann soll der Tester stattdessen den Ordner logs schicken, und
zwar sofort, weil jeder Start ältere Logdateien verdrängt.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

CLAUDE.md: neue Zustandsfelder an allen Kodier-Stellen ergänzen 5b76f828e0

Die Regel sagte, wer ein Feld ergänze, tue das in snapshot.rs und prüfe
es in check_restorable. Das gilt nur für Felder von World. Spielerfelder
kodiert und dekodiert core/src/player.rs, das Inventar inventory.rs, die
Karte map.rs; deren Prüfungen stehen im jeweiligen Dekodierer, nicht in
check_restorable. M2 ergänzt Welt-, Feld- und Spielerzustand und folgt
diesem Satz.

Die Regel nennt jetzt alle vier Stellen und sagt, dass ein neues Feld
beim Dekodieren oder in check_restorable geprüft wird. Die Namen wurden
gegen den Code geprüft: encode_state und from_snapshot, Player::encode
und Player::decode, Inventory::encode und Inventory::decode sowie
Map::encode und Map::decode.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

Tests: Speichern beim Schließen und automatisches Speichern bc34bc61f7

Beides setzt Konzept 9 um („automatisch in festen Abständen“, Speichern
beim Schließen), und beides ließ sich entfernen, ohne dass ein Test
rot wurde.

- Schließen: Die Hauptszene bekommt NOTIFICATION_WM_CLOSE_REQUEST. Danach
  meldet ein SaveStore im selben Ordner einen Spielstand und genau eine
  Aufzeichnung.
- Automatisch: Die Hauptszene läuft per _run_tick bis zum Takt vor
  AUTOSAVE_TICKS, ohne Bilder abzuwarten. Bis dahin gibt es keinen
  Spielstand, einen Takt später gibt es einen.

Entfernt man das Speichern beim Schließen, schlägt der erste Test fehl;
entfernt man das automatische Speichern in _run_tick, der zweite. Ohne
das Schreiben der Aufzeichnung beim Schließen schlägt der erste ebenfalls
fehl.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

steven merged commit fc42cbb8c8 into main

2026-10-01 11:46:02 +00:00

steven deleted branch m1b-bruecke-und-huelle

2026-10-01 11:46:03 +00:00

steven referenced this pull request

2026-10-01 11:46:43 +00:00

Nacharbeiten aus M1a für die nächsten Pläne #2

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: steven/Grovewright#6