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

New Issue

2026-09-30T20:36:17Z

steven commented

2026-09-30 20:36:17 +00:00

Die Abschlussprüfung von M1a (#1) hat den Kern für zusammenführbar erklärt. Diese Punkte wurden bewusst verschoben, weil sie erst mit den nächsten Plänen relevant werden. Jeder Plan übernimmt seine Punkte in seine Tasks.

Für M1b (Brücke und Hülle)

bridge/ wird Mitglied des bestehenden Workspace. Sonst fehlt der Brücke die Überlaufprüfung im Release-Build.
Speicherstände beim Laden prüfen: Takt nahe u64::MAX, mehr als vier Spieler online, doppelte Spielerschlüssel. Heute führt ein manipulierter Stand zu einer Panik statt zu einem Fehler.
World::set_all_offline durch einen Lade-Konstruktor ersetzen, damit die Hülle den Zustand nicht mitten in der Sitzung auf nur einem Rechner ändern kann.
Aufzeichnung an den Weltschritt koppeln (Recording::step), damit nie andere Befehle aufgezeichnet als ausgeführt werden.
Den Spielerschlüssel pro Installation dauerhaft speichern.
Jede Panik aus dem Kern gilt als fatal für die betroffene Welt.
Prüfsumme über Speicherdateien erwägen; beschädigte Dateien laden heute unbemerkt.
Wächter schärfen: Clippy disallowed-types/disallowed-methods (fängt auch gruppierte Importe wie use std::{fs, env}), einen Test auf leere Abhängigkeiten des Kerns und einen Selbsttest des Wächters.
CLAUDE.md: Die Versionsregel bei fehlschlagenden festgeschriebenen Werten gilt nur, wenn Speicherstände oder Aufzeichnungen betroffen sind; Satz zu core/src/ glätten; der Aufzeichnungszähler ist u32. In core/tests/golden.rs „Every other test" zu „Most other tests" korrigieren und bei Test 3 auf die anderen beiden Tests verweisen.
Ein zweites eingefrorenes Skript mit abgemeldetem Spieler und ein Pin für eine nicht quadratische Karte, damit auch diese Felder des Formats festgeschrieben sind.
Hülle: Bei den Startzahlen 83, 145 und 221 ist der Felsblock neben der Lichtung nicht zu Fuß erreichbar. Weicher Fels lässt sich aber mit der Steinspitzhacke graben.

Für M1c (Gleichschritt im Netz)

Befehle an die sendende Verbindung binden: Heute kann ein Befehl jeden Spieler nennen. Befehle pro Spieler und Takt begrenzen (über 65.535 Befehle in einem Takt bricht die Aufzeichnung ab).
Eine Regel-Identität (RULES_VERSION) im Handshake, abgeleitet vom festgeschriebenen End-Hash. Alte Aufzeichnungen melden sonst eine Divergenz, die wie ein echter Fehler aussieht.
Verdrängungsregel für bekannte Spieler: Nach 16 verschiedenen Schlüsseln kann heute niemand Neues mehr beitreten. In M1c (#9) bewusst nicht gebaut: Ein Host mit 16 bekannten Spielern lehnt neue mit Begründung ab („zu viele Spieler“).
Ausstehende Befehle zusammen mit dem Beitritts-Snapshot senden. In M1c (#9) läuft der Beitritt im nächsten Takt, dessen Nachricht alle eingereihten Befehle trägt.
Die Ablehnung überlanger Namen in Command::decode testen.
Die Zahl der Takte in fremden Aufzeichnungen begrenzen, bevor verify sie abspielt.

Für spätere Meilensteine

Upgrade-Pfad für Speicherstände vor dem ersten Formatwechsel (spätestens M2). Das Konzept verspricht in Abschnitt 9, dass kein Fortschritt verloren geht.
M2: Sobald ein Befehl eine Gegenstands-Id trägt, muss Command::decode die Id 0 ablehnen. Sonst stürzt ein einziger fehlerhafter Befehl alle Rechner ab.
M2: debug_assert! für die Kachel-Invariante in Map::set, sobald mehr Regeln Kacheln schreiben.
M3: Werkzeugstufe im Speicher-Round-Trip testen, sobald Spitzhacken verbessert werden können.
Vor der Planung von M4: Konzept Abschnitte 1 und 3.4 („jede Ruine ruft Rückkehrer") mit der bestätigten Reihenfolge abgleichen (nach Ruine 1 Schmiedin und Hirte, nach Ruine 2 die Gärtnerin, nach Ruine 3 niemand).

Dazu kommen kleinere Testlücken aus den Task-Prüfungen (Grenzfälle bei Kartengrößen, Inventar mit Anzahl 0, Dekodierpfade der Aufzeichnung). Sie werden erledigt, wenn die jeweilige Datei das nächste Mal angefasst wird.

Die Abschlussprüfung von M1a (#1) hat den Kern für zusammenführbar erklärt. Diese Punkte wurden bewusst verschoben, weil sie erst mit den nächsten Plänen relevant werden. Jeder Plan übernimmt seine Punkte in seine Tasks. ### Für M1b (Brücke und Hülle) - [x] `bridge/` wird Mitglied des bestehenden Workspace. Sonst fehlt der Brücke die Überlaufprüfung im Release-Build. - [x] Speicherstände beim Laden prüfen: Takt nahe `u64::MAX`, mehr als vier Spieler online, doppelte Spielerschlüssel. Heute führt ein manipulierter Stand zu einer Panik statt zu einem Fehler. - [x] `World::set_all_offline` durch einen Lade-Konstruktor ersetzen, damit die Hülle den Zustand nicht mitten in der Sitzung auf nur einem Rechner ändern kann. - [x] Aufzeichnung an den Weltschritt koppeln (`Recording::step`), damit nie andere Befehle aufgezeichnet als ausgeführt werden. - [x] Den Spielerschlüssel pro Installation dauerhaft speichern. - [x] Jede Panik aus dem Kern gilt als fatal für die betroffene Welt. - [x] Prüfsumme über Speicherdateien erwägen; beschädigte Dateien laden heute unbemerkt. - [x] Wächter schärfen: Clippy `disallowed-types`/`disallowed-methods` (fängt auch gruppierte Importe wie `use std::{fs, env}`), einen Test auf leere Abhängigkeiten des Kerns und einen Selbsttest des Wächters. - [x] CLAUDE.md: Die Versionsregel bei fehlschlagenden festgeschriebenen Werten gilt nur, wenn Speicherstände oder Aufzeichnungen betroffen sind; Satz zu `core/src/` glätten; der Aufzeichnungszähler ist `u32`. In `core/tests/golden.rs` „Every other test" zu „Most other tests" korrigieren und bei Test 3 auf die anderen beiden Tests verweisen. - [x] Ein zweites eingefrorenes Skript mit abgemeldetem Spieler und ein Pin für eine nicht quadratische Karte, damit auch diese Felder des Formats festgeschrieben sind. - [x] Hülle: Bei den Startzahlen 83, 145 und 221 ist der Felsblock neben der Lichtung nicht zu Fuß erreichbar. Weicher Fels lässt sich aber mit der Steinspitzhacke graben. ### Für M1c (Gleichschritt im Netz) - [x] Befehle an die sendende Verbindung binden: Heute kann ein Befehl jeden Spieler nennen. Befehle pro Spieler und Takt begrenzen (über 65.535 Befehle in einem Takt bricht die Aufzeichnung ab). - [x] Eine Regel-Identität (`RULES_VERSION`) im Handshake, abgeleitet vom festgeschriebenen End-Hash. Alte Aufzeichnungen melden sonst eine Divergenz, die wie ein echter Fehler aussieht. - [x] Verdrängungsregel für bekannte Spieler: Nach 16 verschiedenen Schlüsseln kann heute niemand Neues mehr beitreten. In M1c (#9) bewusst nicht gebaut: Ein Host mit 16 bekannten Spielern lehnt neue mit Begründung ab („zu viele Spieler“). - [x] Ausstehende Befehle zusammen mit dem Beitritts-Snapshot senden. In M1c (#9) läuft der Beitritt im nächsten Takt, dessen Nachricht alle eingereihten Befehle trägt. - [x] Die Ablehnung überlanger Namen in `Command::decode` testen. - [x] Die Zahl der Takte in fremden Aufzeichnungen begrenzen, bevor `verify` sie abspielt. ### Für spätere Meilensteine - [ ] Upgrade-Pfad für Speicherstände vor dem ersten Formatwechsel (spätestens M2). Das Konzept verspricht in Abschnitt 9, dass kein Fortschritt verloren geht. - [ ] M2: Sobald ein Befehl eine Gegenstands-Id trägt, muss `Command::decode` die Id 0 ablehnen. Sonst stürzt ein einziger fehlerhafter Befehl alle Rechner ab. - [ ] M2: `debug_assert!` für die Kachel-Invariante in `Map::set`, sobald mehr Regeln Kacheln schreiben. - [ ] M3: Werkzeugstufe im Speicher-Round-Trip testen, sobald Spitzhacken verbessert werden können. - [ ] Vor der Planung von M4: Konzept Abschnitte 1 und 3.4 („jede Ruine ruft Rückkehrer") mit der bestätigten Reihenfolge abgleichen (nach Ruine 1 Schmiedin und Hirte, nach Ruine 2 die Gärtnerin, nach Ruine 3 niemand). Dazu kommen kleinere Testlücken aus den Task-Prüfungen (Grenzfälle bei Kartengrößen, Inventar mit Anzahl 0, Dekodierpfade der Aufzeichnung). Sie werden erledigt, wenn die jeweilige Datei das nächste Mal angefasst wird.

steven added this to the M1 Fundament milestone 2026-09-30 20:36:17 +00:00

steven referenced this issue

2026-10-01 06:03:04 +00:00

M1a: deterministischer Rust-Kern #3

steven referenced this issue

2026-10-01 07:55:19 +00:00

M1b Brücke und Hülle #4

steven referenced this issue

2026-10-01 11:40:21 +00:00

Nacharbeiten aus M1b für die nächsten Pläne #5

steven referenced this issue

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

M1b: Brücke und Hülle #6

steven commented

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

Die M1b-Punkte sind mit #6 erledigt. Der Felsblock bei den Startzahlen 83, 145 und 221 war kein Fehler: Die Figur gräbt sich durch weichen Fels. Neue Nacharbeiten aus M1b stehen in #5. Die M1c-Punkte und die Punkte für spätere Meilensteine hier gelten weiter.