🔬 Review – 2.0-Fundament (task-14, unabhängige Gegenprüfung)

⬆️ Netzwerk-Labor · Vertrag: Fahrplan – 1.3 und 2.0 · SITZUNGSABSCHLUSS

Auftrag. Nicht „sind die Tests grün?", sondern: Stimmt, was die anderen behaupten? Jeder Bericht eines Teammates ist eine BEHAUPTUNG. Verfahren: jede Zahl mit eigenem Befehl nachzählen, jede Ursache mit eigenem Experiment belegen, jede Datei per Byte-Vergleich prüfen — und ausdrücklich sagen, was nicht geprüft wurde. Geändert wird nichts: dieses Dokument ist mein einziges Schreibrecht.

Kernaussage in einem Satz. Die Nullmessung des Leads ist exakt bestätigt (471/479 grün, 8 rot, 55 Testdateien, 84 Module, 0 übersprungen) · die 8 roten UI: Übergabe › … waren ein Fehler der Attrappe, nicht des Produktivcodes (gemessen; inzwischen behoben, 8/8 in Isolation) · kein Zeilenenden-Bruch in dieser Sitzung (sieben Verdachtsfälle per Index-Arithmetik als vorbestehend entlastet) · die vorgeschriebene Wächterprüfung tools/pruefe-namen-flicken.js verschwieg im Trockenlauf genau die Datei, die nicht lädt (:86 — behoben, mit Verweis auf dieses Review) · eine Zusicherung außerhalb eines pruefe-Rumpfs gibt es in keiner der 66 Testdateien (24 statische Treffer, jeder von Hand gelesen: alles Helfer-Funktionen) · eine öffentliche Funktion ohne Aufrufer: Spiel.ergebnisKurz — und ein Zwischenstand mit 8 neuen roten Zeilen, von denen drei inhaltlich waren.

Was ich gemessen habe, in Zahlen (jede mit Befehl, siehe unten): 92 Minis mit 91 Denkhilfen, davon 91 von 91 wirklich ausgeliefert (kein stiller Wächter-Tausch) · Hilfe-Vorschläge 44 statt 29, Ebene 2: 15 statt 0, 0 Fertigkeiten ohne Vorschlag statt 10 · Trainingskarten 0 gesperrt statt 3, alle drei Ende-zu-Ende wirksam · Hilfe-Vorrat 6/4/2/0 je Bildungsstand, Stufe am Ticket · Klassenraum +0 €/+0 Ruf statt +33/+1 (Kontrolle pruefung liefert exakt die +33/+1) · Determinismus: derselbe Code ⇒ derselbe def.id, und der Flow-Regler lebt im Postfach-Weg weiter · Fehlerdex 39 Fehlerarten, 7 Grundcodes ohne Injektor, keine fehlenden Pflichtfelder.

Stand der Messung: 09.10.2026, 15:13–15:40 · Arbeitsbaum nur gelesen · kein git add, kein Commit, kein Prozess beendet · HEAD unverändert fe6d7c1. Dies ist der Zwischenstand. Phase 2 (voller Lauf nach Ende der Bauphase, Zahlen aller Teammates) folgt unten in § 10 — die Nummern dort bleiben offen, bis sie gemessen sind. „Nicht geprüft" steht als „nicht geprüft" da.

1 · Verfahren

Warum node -e und kein Skript im Projekt: mein Schreibrecht umfasst nur diese Datei. Ein Prüfskript im Projektordner wäre eine Änderung am Produkt.

2 · Die Nullmessung des Leads — nachgezählt, nicht zitiert

Behauptung (Lead, überall im Task-Board): „471/479 grün, 8 rot — die 8 roten heißen alle UI: Übergabe › …; 55 Testdateien, 84 Module."

Meine Messung (voller Lauf, kein Filter, 15:15–15:19):

471/479 grün, 8 ROT  (55 Testdateien, 84 Module)
davon 0 übersprungen

Alle acht ✗-Zeilen beginnen mit UI: Übergabe ›.

Restzweifel. Mein Lauf traf den Stand vor src/spiel/ergebnis.js (angelegt 15:15:34) — deshalb 84 und nicht 85/87 Module. Er ist damit genau die Nullmessung des Leads, aber kein Stand nach der Bauphase. Die Testdateizahl 55 war zum Messzeitpunkt ebenfalls die des Leads.

3 · Die 8 roten UI: Übergabe › … — Ursache gemessen, und sie liegt im Test

Behauptung (task-11): „die 8 roten Fälle sind inhaltlich … die Attrappe ist unvollständig oder src/ui/uebergabe.js greift auf etwas zu, das sie nicht kennt."

3.1 Was der Lauf zeigt — und was er verschweigt

Der Lauf druckt als Fehler einen Code-Ausschnitt, keine Meldung:

✗ UI: Übergabe › Der Einstellungs-Abschnitt „Rechner übergeben" steht da, mit Knopf
    evalmachine.<anonymous>:3
    UI.app = {einstellungAbschnitt: (titel, fn) => { const c = h('div', …); fn(c); globalThis.__abschnitte.push([titel, c]); }, …};
                                                                                                                                 ^

Nebenbefund N1 (Testrahmen): tests/harness.js:41 kürzt den Fehler auf vier Stack-Zeilen (e.stack.split("\n").slice(0, 4)). Bei einem Fehler aus vm.runInContext sind diese vier Zeilen der Code-Ausschnitt — die Meldung selbst (TypeError: …) fällt weg. Genau deshalb stand im Board eine Meldung („Cannot set properties of undefined"), die der Lauf so gar nicht ausgibt. Wer künftig einen vm-Fehler sucht, findet die Ursache nur über ein eigenes Experiment; drei Zeilen im Harness (e.name + ": " + e.message voranstellen) würden das beheben.

3.2 Eigene Ursachenmessung (drei Proben, node -e)

Befund B1 (belegt): In tests/ui-uebergabe.test.js (Fassung 15:16, 220 Z.) verdrahtete Object.assign(bereich, {__reloads: 0}) nur __reloads. Die Attrappe schreibt aber nach globalThis.__abschnitte / __uebergaben / __toasts / __exporte, während der Test die äußeren Felder abschnitte, uebergaben, toasts, exporte liest. uebStand() warf beim ersten Start-Haken — vor jeder Zusicherung. Das ist ein Fehler der Attrappe, nicht des Produktivcodes.

3.3 Gegenversuch: Attrappe im Speicher repariert — es bleiben drei Fehler

Ich habe nur die Verdrahtung im Speicher nachgezogen (Datei unverändert) und erneut gemessen:

Befund B2: Die beiden „lädt neu"-Fälle scheiterten an P2 — location.reload zählte in den erzeugenden Realm. Befund B3: „Erst sichern" scheiterte, weil uebKapsel Spiel._trocken = true setzt, Spiel.speichern() bei src/spiel/zustand.js:170 sofort zurückkehrt und der Speicher deshalb kein labor hat; die Zusicherung inhalt.speicher.labor.euro === 42 ist in dieser Kapsel nicht einlösbar. Der Exportweg selbst ist dabei regelkonform: src/ui/uebergabe.js:28-31 ist Zeichen für Zeichen derselbe Weg wie src/ui/karriere.js:442-445 (store.sofort(), dann store.alles()).

Ergebnis: „Die 8 grün machen" war nicht mit einer Reparatur an einer Stelle getan. Das war der wertvollste Teil dieser Prüfung — und der Grund, warum ich die Attrappe nicht als „kleine Unvollständigkeit" durchgehen lasse.

3.4 Was der Eigentümer daraus gemacht hat (nachgemessen)

tests/ui-uebergabe.test.js wurde um 15:16:22 geändert. Die neue Fassung (235 Z., SHA256 F125293B629A3FD7…) verdrahtet alle vier Felder (:101), zählt neuladungen über eine Verschlussvariable statt über globalThis (:73, :92 — mit genau dieser Begründung im Kommentar) und legt store.set("labor", Spiel.st) vor die Export-Zusicherung (:211).

Meine Messung der neuen Fassung (Einzellauf im eigenen Bereich, 87 Module): 8/8 grün, 0 übersprungen.

Restzweifel. Das ist ein Einzellauf dieser einen Datei, kein voller Lauf; die Zahl im Gesamtlauf steht in Phase 2 (§ 10). Und: dass drei Fehler in einer Testdatei steckten, sagt nichts über src/ui/uebergabe.js selbst — dessen Wirkung im echten Browser habe ich nicht gemessen (§ 8).

4 · Prüfauftrag des Leads: Zusicherungen außerhalb eines pruefe-Rumpfs

Auftrag (Lead, 15:30). tests/klassenraum-hilfevorrat.test.js:66 hatte eine Zusicherung direkt im Gruppenrumpf; sie schlug durch bis vm.runInContext, tests/run.js:58 meldete LADEFEHLER und beendete den ganzen Lauf mit Exit 2. Gesucht: jede weitere solche Stelle.

4.1 Der gemeldete Ort ist inzwischen sauber

tests/klassenraum-hilfevorrat.test.js hat jetzt 131 Zeilen; jede Zusicherung steht in pruefe(…, kapsel(() => {…})). Der Kopfkommentar :20-22 warnt inzwischen selbst: „ein sofort ausgeführter Rumpf brächte den ganzen Lauf mit LADEFEHLER (exit 2) zum Stehen."

4.2 Statischer Scan über alle 65 Testdateien

Eigener Tokenizer (Zeichenketten, Vorlagen, Zeilen- und Blockkommentare werden zu Leerzeichen), dann Klammerstapel: eine Zusicherung gilt als „außerhalb", wenn beim Auftreffen von erwarte. kein offener pruefe(-Aufruf im Stapel liegt.

Geprueft: 65 Testdateien, 2352 erwarte.*-Aufrufe im Quelltext
AUSSERHALB eines pruefe-Rumpfs: 24

Jeden der 24 Treffer habe ich von Hand im Kontext gelesen. Alle 24 stehen in Helfer-Funktionen, die nur aus pruefe-Rümpfen gerufen werden — zum Beispiel:

Ergebnis (statisch): keine Zusicherung, die beim Ausführen eines Gruppenrumpfs ungeschützt läuft. Einschränkung, ehrlich: mein Scanner ist eine Heuristik — Regex-Literale mit Anführungszeichen können den Klammerstapel verschieben (genau das passiert bei spiel-einstieg-stufe.test.js). Deshalb die Handprüfung jedes Treffers; ein sauberes Ergebnis ist damit belegt, ein „Scanner findet nichts" allein wäre es nicht.

4.3 Dynamischer Scan — die belastbare Gegenprobe

Ich habe jede Testdatei einzeln in einen frischen Bereich geladen: dieselben 87 Module wie tests/run.js, dazu tests/harness.js und genau eine Testdatei — und testsAusfuehren() absichtlich nicht gerufen. Damit laufen alle Gruppenrümpfe (und nur die), also genau der Pfad, der den LADEFEHLER auslöst.

Geprueft: 65 Testdateien  |  Dateien mit LADEFEHLER beim Laden: 1
  LADEFEHLER  hilfe-ebene2.test.js

Befund B4 (hart, mit Zeitfenster): tests/hilfe-ebene2.test.js war beim Anlegen nicht ladbar:

tests/hilfe-ebene2.test.js:174
  for (const v of e1) erwarte.gleich(v.art, "pruefen", v.id + ": Ebene 1 („ansehen") muss prüfen");
SyntaxError: Unexpected identifier 'muss'          (node --check, Exit 1)

Das ASCII-" nach „ansehen schließt den String; muss ist dann ein Bezeichner. Gemessen im Fenster 15:20:16 (Anlage) bis 15:21:03 — in diesem Fenster hätte tests/run.js mit Exit 2 abgebrochen, also derselbe Totalausfall wie der gemeldete Fall, nur mit anderer Ursache. Der Eigentümer hat die Datei um 15:21:03 selbst behoben; node --check liefert jetzt Exit 0. Der Fehler steht hier, weil er gemessen ist — nicht als Vorwurf, sondern als Beleg für die Fehlerklasse.

Gesamturteil zum Prüfauftrag: In der aktuellen Fassung gibt es weder eine ungeschützte Zusicherung noch eine nicht ladbare Testdatei (65 von 65 laden, Stand 15:35).

4.4 Werkzeugbefund: die Wächterprüfung verschweigt den Fall, für den es sie gibt

Behauptung (AGENTS.md, Befehlstabelle): node tools/pruefe-namen-flicken.js „findet pruefe("…„…"…"), das den Lauf mit LADEFEHLER (Exit 2) anhält — trockener Lauf zuerst".

Messung im selben Befehlsblock, in dem node --check tests/hilfe-ebene2.test.js mit Exit 1 scheiterte:

würde flicken tests\hilfe-ebene2.test.js: 2 pruefe()-Name(n)
…
65 Datei(en) geprüft, 0 geschrieben, 0 laden nicht.
Exit: 0

Das Werkzeug meldet „0 laden nicht", während dieselbe Datei nicht ladbar ist.

Ursache (Zitat, tools/pruefe-namen-flicken.js:86):

if (setzen || !anzahl) {
  const fehler = ladbar(datei);
  if (fehler !== true) { kaputt.push(rel + " — " + fehler); … }
}

Im Trockenlauf (setzen === false) wird die Ladbarkeitsprüfung für jede Datei übersprungen, die geflickt werden müsste (anzahl > 0) — also für genau die verdächtigen. Der Trockenlauf ist aber der Lauf, den AGENTS.md vorschreibt.

Vorschlag (nicht von mir ausgeführt, weil fremde Datei): die Bedingung auf if (setzen || true) bzw. schlicht const fehler = ladbar(datei); verkürzen — die Prüfung kostet Millisekunden und ist der einzige Grund, warum es das Werkzeug gibt.

Restzweifel. Ich habe den Werkzeugbefund an einer Datei in einem Zeitfenster gemessen. Dass die Bedingung generell so wirkt, ist Quelltext-Zitat (:86), nicht Stichprobe über viele Dateien.

Nachtrag 15:26 — der Befund ist behoben. tools/pruefe-namen-flicken.js ist im Arbeitsbaum geändert; die Bedingung lautet jetzt unbedingt (Diff zitiert):

-    if (setzen || !anzahl) {
+    /* Die Ladbarkeit wird IMMER geprüft. … (gemessen am 09.10.2026 von der Gegenprüfung,
+       Beleg im Review – 2.0-Fundament.md) */
+    {
       const fehler = ladbar(datei);

Meine Nachmessung: node tools/pruefe-namen-flicken.js → „66 Datei(en) geprüft, 0 geschrieben, 0 laden nicht", Exit 0. Die Zahl der geprüften Dateien ist von 65 auf 66 gestiegen (neue Testdatei), die Prüfung läuft jetzt für jede Datei — Beleg im Quelltext (:92, aus der Bedingung herausgezogen). Restzweifel: dass die Korrektur auch eine kaputte Datei meldet, konnte ich nicht vorführen — dafür müsste ich eine nicht ladbare Testdatei anlegen, und Testdateien liegen außerhalb meines Schreibrechts. Belegt ist die geänderte Bedingung und der fehlerfreie Trockenlauf, nicht der scharfe Gegenfall.

5 · Zeilenenden — der Byte-Vergleich, und eine Entlastung

Regel (AGENTS.md / SITZUNGSABSCHLUSS Schritt 6). Ein Editor, der normalisiert, dreht die ganze Datei um; git diff --numstat und --ignore-cr-at-eol können dabei identisch aussehen. Verlässlich ist der Byte-Vergleich.

Erste Messung (Alarm): src/ui/spiel.js — Arbeitsbaum CRLF=876, LF=0, HEAD CRLF=0, LF=866. Und die Falle aus der Doku ist echt: git diff --numstat und --ignore-cr-at-eol zeigen beide 10 0, git diff --stat beide 10 insertions. Der Diff sieht also harmlos aus, obwohl der ganze Dateiinhalt umgestellt ist. Dazu passt git ls-files --eol:

i/lf  w/crlf  attr/text=auto eol=lf   src/ui/spiel.js

und Git warnt von selbst: „in the working copy of 'src/ui/spiel.js', CRLF will be replaced by LF the next time Git touches it".

Gegenmessung — und sie entlastet die Sitzung. Ein Zeilenendenwechsel in dieser Sitzung hätte bedeutet: die Datei war vorher LF. Die Index-Statistik sagt das Gegenteil:

Befund B5: Die CRLF von src/ui/spiel.js sind vorbestehend. Die 10 in dieser Sitzung angehängten Zeilen wurden in CRLF angehängt — also im Sinne der Datei, nicht gegen sie. Nach AGENTS.md ist das die richtige Behandlung (Zeilenenden bewahren), auch wenn sie der Deklaration in .gitattributes (* text=auto eol=lf) widerspricht.

Repo-weiter Zustand (gemessen): 51 von 423 verfolgten Dateien sind w/crlf, 372 w/lf, 0 w/mixed. In src/ allein: 38 CRLF, 105 LF. Es ist also kein Einzelfall dieser Sitzung, sondern gewachsener Bestand.

Restzweifel. Für untracked Dateien gibt es keinen HEAD-Vergleich; ich kann nur die jetzige Verteilung belegen (alles LF). Und für src/ui/spiel.js ist die Index-Statistik ein Indizienbeweis, kein Beweis aus einem zweiten Arbeitsbaum: sie zeigt den Zustand beim letzten Git-Zugriff, nicht lückenlos jeden Zeitpunkt davor. Kein anderes Argument in dieser Sitzung spricht dafür, dass jemand die Datei in dieser Sitzung umgestellt hat — der Inhalt ist um genau die 10 neuen Zeilen gewachsen.

6 · „Wirkung vor Grün" — was ich bisher messen konnte

Die Regel: ein Baustein zählt erst, wenn er im echten Weg vorkommt. Das belegte Gegenbeispiel des Projekts ist der DHCP-Pool-Modus, der jahrelang wirkungslos war, weil der Test nur den Prompt prüfte.

6.1 Eingebunden ist alles (Bau-Reihenfolge, nicht Wirkung)

bauen.py:60 (d.glob("*.js") je Schicht) und bauen.py:124 (d.glob("*.css") in src/stil) nehmen neue Dateien automatisch mit. python bauen.py --liste nennt spiel/uebergabe.js, spiel/ergebnis.js und ui/uebergabe.js. Aber: „steht im Bau" ist nicht „wird aufgerufen" — der DHCP-Fall war auch gebaut.

6.2 Übergabe: der echte Weg ist belegt, die Wirkung im Browser nicht

Nicht gemessen: dass der Knopf im echten Browser sichtbar ist und der Dialog dort öffnet. Dafür bräuchte es python bauen.py + tools/rauch.py (echter Edge) — beides gehört dem Lead und schreibt Erzeugnisse. Nicht geprüft.

6.3 Spiel.ergebnisText wirkt, Spiel.ergebnisKurz hat (noch) keinen Aufrufer

Befund B6 (Wirkung vor Grün): Spiel.ergebnisKurz ist eine öffentliche Funktion der zugesagten Schnittstelle, hat aber null Aufrufer im Programm. Nach der Projektregel gilt sie damit als nicht fertig. Ob das ein Fehler des Teammates ist, hängt an der Schnittstellenzusage des Leads (task-1 Punkt 2 nennt beide Funktionen) — die Entscheidung liegt beim Lead, nicht bei mir. Mein Befund ist die Zahl: 0 Aufrufer.

6.4 Klassenraum: der Schaden ist behoben — und der Fahrplan-Wert exakt reproduziert

Eigener Lauf im echten Fluss (Spiel.instanzErstellen → Spiel.oeffnen → Lösung → Spiel.abnahme → Spiel.abschliessen), Ticket salon-01, Niveau AP2, je Quelle ein frischer Stand:

Ergebnis: Die Zahl +33 € / +1 Ruf des Fahrplans ist auf dem ungefilterten Pfad exakt reproduziert (Kontrollzeile pruefung) — und der Klassenraum-Auftrag zahlt in der jetzigen Fassung nichts: Spiel.klassenraum existiert (typeof = object), die Umleitung greift. Den Vorher-Zustand konnte ich nicht messen — als ich messen konnte, war die Behebung schon eingebaut. Die Fahrplan-Zahl ist damit plausibel und konsistent, aber von mir nicht als Vorher-Messung wiederholt.

Nicht gemessen: die Teilbehauptungen „Wochenziel erfüllt" und „Kundenampel grün" — im frischen Stand ist st.woche === null und es gibt keinen Vertragskunden. Nicht geprüft.

6.5 Denkhilfen: 91 von 91 kommen wirklich beim Spieler an (Wirkung, nicht Prompt)

Das ist die schärfste Prüfung dieses Bausteins — denn src/spiel/mini.js:182-193 (miniOhneLoesung) ersetzt einen Text still durch den Fertigkeitssatz, wenn er die Lösung verrät oder eine Option wörtlich nennt. Ein grüner Daten-Test würde das nicht merken. Ich habe deshalb über die echte API gemessen: je Mini Spiel.mini.hilfe(id, {nurSehen:true}) aufrufen und den zurückgegebenen Text mit dem Eintrag vergleichen.

Ergebnis: Kein Text fällt durch den Wächter. Das ist die Aussage, die ein reiner Daten-Test nicht liefern kann. Restzweifel: gemessen auf einer Stufe (azubi) und mit nurSehen — ob die Oberfläche den Text danach auch anzeigt, ist damit nicht belegt (kein Browser, § 9).

6.6 Hilfe-Vorrat: der Vorrat folgt dem Bildungsstand, nicht dem stillen Standard

Eigener Lauf, je Bildungsstand ein frischer Klassenraum-Auftrag (salon-01, ohneFlow:true):

Ergebnis: 6/4/2/0 wie in der Zusage, und der Bildungsstand steht ausdrücklich am Ticket (inst.stufe) — der stille Rückfall auf EINST_STANDARD ist weg. Nicht gemessen: der Gegenfall „EINST_STANDARD auf meister, Mensch auf azubi" — den prüft die Testdatei des Eigentümers (tests/klassenraum-hilfevorrat.test.js:104-118, zitiert, nicht von mir nachgerechnet).

6.7 Die drei gesperrten Trainingskarten: alle drei wirken jetzt (Ende-zu-Ende gemessen)

Nicht „liste() sagt offen", sondern der ganze Weg: starten → Startzustand verletzt → Lösung → Abnahme → training.abnehmen. Je Karte ein frischer Stand.

Ergebnis: Der Fehler wirkt (Ziel verletzt vor der Lösung), die Lösung heilt (0 verletzt nach der Lösung), die Abnahme besteht, und das Training zahlt weiterhin 0 € / 0 Ruf. Die Kontrollzeile zeigt, dass mein Prüfstand überhaupt unterscheiden kann.

Wichtige Einschränkung: Die board-eigene Warnung zu lab.stp lautete, ein zweites Kabel erzeuge keinen Sturm und ticketBauen verwerfe einen Injektor, der nichts bricht. starten.ok = true und „Ziel verletzt" belegen, dass irgendein wirkender Fall gebaut wird — nicht, dass es ein Broadcast-Sturm ist (Grundcode STORM). Ob der STP-Injektor den behaupteten Mechanismus hat, prüfe ich am Bericht des Eigentümers nach (Phase 2). Bisher nicht geprüft: der Grundcode der erzeugten Fälle.

6.8 Determinismus: der Klassenraum ist fest — und der Flow-Regler lebt weiter

Gemessen mit Kontrolle (sonst wäre „alles gleich" auch als „mein Schalter tut nichts" deutbar):

Spiel.flow.stand("lab.vlan") gab in jedem Durchgang genau den gesetzten Wert zurück — der Schalter wirkt also, das Ergebnis ist nicht „Rauschen". Ursache im Quelltext, src/spiel/postfach.js:

const ohneRegler = o.quelle === "pruefung" || o.quelle === "raetsel" || o.quelle === "klassenraum";
const flow = Spiel.flow && !o.ohneFlow && !ohneRegler ? Spiel.flow.fuer(def) : null;

Ergebnis: Die Zusage „derselbe Code + derselbe Seed ⇒ derselbe Auftrag" ist für den Klassenraum belegt, und die naheliegende Abhilfe „Flow einfach abschalten" wurde nicht gewählt: im normalen Postfach-Weg adaptiert der Regler weiter (1 / 2 / 3 Ziele). Das ist der Unterschied zwischen „Test grün" und „Feature heil".

Nebenbefund N3 (zwei Listen, gemessen): src/spiel/flow.js:nachAbschluss nimmt nur pruefung und raetsel aus — nicht klassenraum. Ein Klassenraum-Auftrag schreibt also weiter in den Flow-Stand seines Geräts, obwohl er ihn nicht mehr liest. Ob das gewollt ist (der Flow ist die Lern-Geschichte des Geräts), entscheidet der Lead — ich melde nur, dass zwei Stellen zwei verschiedene Ausnahmelisten führen.

6.9 Was weiterhin ohne Aufrufer dasteht

7 · Die Vorher-Zahlen des Task-Boards — selbst ausgezählt

Alle Zahlen aus einem eigenen vm-Bereich (87 Module, Stand 15:35), nicht aus Berichten übernommen.

Nebenbefund N2 (Board-Text vs. Datei): task-1 sagt „tests/spiel-uebergabe.test.js (8 Fälle, grün)". Gemessen: 10 pruefe-Fälle, alle zehn im vollen Lauf grün. Eine Nebenangabe, kein Sachfehler — die Datei ist seither gewachsen.

8 · Verbote und Randbedingungen (gemessen)

9 · Was ich nicht geprüft habe (ehrlich)

• Die volle Prüfung der Bauphase — sie läuft noch. Alle Zahlen der Teammates (Zeilen, Testnamen, Vorher/Nachher) sind nicht von mir nachgezählt, solange ihre Tasks in_progress sind. § 10 folgt.
• Browser/Oberfläche: kein python bauen.py, kein tools/rauch.py, kein tools/menueprobe.py, kein python tools/seite.py --pruefen. Aussagen über die sichtbare Oberfläche (Knopf im Einstellungsdialog, Abschlussfenster mit Kopierknopf) beruhen auf Quelltext-Zitaten, nicht auf einem Bild.
• Wochenziel und Kundenampel beim Klassenraum-Auftrag (§ 6.4).
• Spiel.ergebnisKurz — kein Aufrufer gefunden; ob das gewollt ist, entscheidet der Lead.
• Der Vorher-Zustand des Klassenraum-Schadens — nicht mehr messbar, die Behebung war schon eingebaut.
• Der Lernmotor-Befund (fremd/lernmotor.js:39, s.v === 1 ohne Migration) — nicht nachgemessen; die Datei liegt außerhalb und darf nicht angefasst werden. Die Aussage „tests/run.js lädt die Spielhalle, nicht die Kopie" habe ich belegt: mein eigener Lader lädt ..\FISI-Spielhalle\src\lernmotor.js (Ausgabe der eigenen Probe), und beide Dateien liegen vor.
• Zeilen-/Zweigabdeckung im Sinne eines Abdeckungsinstruments: das Projekt hat keines.
• tools/klassenraum-probe/B-workflow.js — ob der await-Fehler praktisch relevant ist.
• Der Grundcode der drei geöffneten Trainingskarten (§ 6.7): ich habe „Ziel verletzt → Lösung heilt" gemessen, nicht ob der STP-Fall wirklich ein STORM ist.
• Die Berichte der Teammates selbst — zum Zeitpunkt dieses Zwischenstands lag mir noch keiner vor. Ich habe ihre Zahlen aus dem Board nachgemessen, nicht ihre Begründungen geprüft.

10 · Zwischen- und Endmessungen der Bauphase

(Dieser Abschnitt wächst mit. Jede Zeile nennt den Messzeitpunkt, weil der Baum während der Bauphase wandert — ein Zwischenstand ist kein Endstand.)

10.1 Voller Lauf 15:25 — 562/570 grün, 8 ROT (66 Testdateien, 90 Module, 0 übersprungen)

Kein LADEFEHLER. Die ursprünglichen acht UI: Übergabe › … sind verschwunden; dafür standen acht neue rote Zeilen im Lauf. Ich habe sie dem Umstand zugeschrieben, dass die Bauphase lief — und das war richtig, aber nicht bei allen:

Wert für die Abnahme: Punkt 8 ist der Fall, der sonst durchrutscht — eine Karte, die startet und „irgendwie" rot wird, aber dessen Lösung das Netz nicht heilt. Die Punkte 6–8 sind keine Bauartefakte und müssen vor dem Endlauf grün sein (oder ehrlich als Befund dastehen).

10.2 Die Datenzahlen nach der Bauphase (15:28, 90 Module)

10.3 Zeilenenden — kein Bruch in dieser Sitzung (15:27)

Der Byte-Vergleich zeigt für sieben geänderte Dateien „Arbeitsbaum CRLF, HEAD LF":

src/spiel/abnahme.js · src/spiel/dex.js · src/spiel/flow.js · src/spiel/postfach.js · src/ui/netzplan.js · src/ui/spiel.js · tests/spiel-bogen.test.js

Das sieht wie der verbotene Fall aus. Die Index-Arithmetik entlastet alle sieben — Index-Statistik-Größe = HEAD-Bytes + Zeilenzahl, also war die Datei beim letzten Git-Zugriff bereits CRLF:

Ergebnis: Keine Datei wurde in dieser Sitzung von LF auf CRLF gedreht. Alle neuen Dateien (24 untracked, darunter dieses Review) sind LF, 0 CRLF. Der CRLF-Bestand ist gewachsen (repo-weit 51 von 423 verfolgten Dateien) und widerspricht .gitattributes (* text=auto eol=lf) — aber er ist vorbestehend, nicht von dieser Sitzung gemacht.

10.4 Werkzeuge (15:30–15:31)

Zur ethos-Roten, ehrlich: sie fiel in dasselbe Zeitfenster, in dem src/stil/naechster.css entstand (15:29:34) — die einzige neue CSS-Datei. Um 15:31:10 war die Regel wieder grün, ohne dass ich etwas geändert hätte. Ich habe die +3 deshalb nicht einer bestimmten Zeile zuordnen können: mein eigener Nachbau des Zählers (messen() des Werkzeugs direkt aufgerufen, mit und ohne naechster.css) ergab in beiden Fällen 70. Ergebnis: Zwischenstand während des Schreibens, kein belegter Verstoß. Restzweifel: ein Zähler, der beim Schreiben einer Datei kurz ausschlägt, ist selbst eine Beobachtung wert — für die Abnahme zählt der Endlauf.

10.5 Zweiter Vollschnitt 15:31 — 591/593 grün, 2 ROT (69 Testdateien, 90 Module, 0 übersprungen)

Kein LADEFEHLER. Von den acht roten aus § 10.1 sind sechs verschwunden (Doku-Erzeugnis neu gebaut, Fehlerdex-Zahlen nachgezogen, stp-doppelkabel heilt jetzt auch in standorte). Es blieben zwei — beide gehören Bausteinen, die nach meinem Task-Board-Abzug entstanden sind:

✗ Fragen-Generator › Fragen-Generator: jede falsche Option ist ein typischer Denkfehler, keine Zufallszahl
✗ Spiel: naechster Schritt › Nur auf Bedarf: azubi nach Wartezeit, geselle nach Fehler, meister nie — gefragt bekommt sie jeder

Wert für die Abnahme: 591 von 593 grün heißt nicht fertig — die zwei roten Zeilen sind genau der Grund, warum die Abnahme am Ende zählt und nicht der Zwischenstand. Nicht geprüft: ob diese zwei im Endlauf noch rot sind (der Baum wanderte weiter, während ich maß).

10.6 Fremdbericht gegengeprüft: Fehlerdex-Nachzug (Peer-Meldung hilfevorrat, 15:35)

Der Peer meldete Zahlen zum Fehlerdex-Nachzug. Ich habe sie nicht zitiert, sondern mit eigener Probe nachgezählt (90 Module, eigener vm-Bereich):

Zu OFFEN: src/spiel/dex.js:77 fängt genau diesen Wert ausdrücklich ab („Etwas ist erreichbar, das gesperrt sein soll"). Die Ausnahme ist also gewollt — aber die Aussage „Differenz []" ist zu stark. Restzweifel: meine Zahl beruht auf Spiel.INJEKTOREN als Objekt (Object.values); die erste Probe lief in einen Typfehler, weil ich ein Feld falsch angenommen hatte. Diesen Fehlalarm nenne ich hier ausdrücklich, weil er die Regel des Hauses belegt: eine Probe, die das Falsche misst, sieht wie ein Befund aus.

10.7 Was für die Abnahme offen bleibt