⚖️ Bilanz – Agententeam 2.0: die Erfolgsquote, gemessen

[!success] Die Antwort auf die 90-%-Frage — kurz Definition I (Aufgabe erledigt): 51 von 52 = 98,1 % → die 90 % sind erreicht. Definition II (Behauptung hält der Nachmessung stand): 9 von 10 = 90,0 % → die 90 % sind erreicht — genau auf der Latte, nicht darüber. Die Tore: 8 von 8 messbaren bestanden (100 %); vier Tore brauchen einen Browser und blieben nicht gemessen. sh tools/test.sh meldet 733/733 grün, Exit 0.

Der eine Abstrich, der bleibt: eine veraltete APK-Angabe — Architektur.md:919 und CHANGELOG.md:82 nennen 1 160 732 B / A27751B2…, auf der Platte liegen 1 164 828 B / 2208C08A…. Dieselbe Sorte Fehler steckt im Codec-Beleg vom 06.10. Kein Produktfehler — ein Nachweis-Fehler, und genau die zählen in Definition II.

Und ein Bild hat sich während dieser Messung geändert (die Nachbesserung der Leitung): vorher waren „2a" und „2b" byte-identisch (9 Bilder für 10 Schritte), jetzt sind es 10 verschiedene Bilder — ich habe beide angesehen, sie zeigen wirklich Verschiedenes. Damit ist auch dieser Abstrich weg.

1 · Was sich seit der ersten Fassung geändert hat

Bemerkenswert und belegbar: Zwei der drei behobenen Punkte sind aus meiner Prüfung entstanden — die Aufgaben task-51 und task-52 wurden angelegt, weil ich den 12 einzelnen \r und den regellosen Selektoren nachgegangen bin. Beide sind abgeschlossen, beide habe ich nachgemessen.

2 · Die Aufgaben: task-1 bis task-52

Quelle: die geteilte Aufgabenliste (49 Einträge in der ersten Fassung, jetzt 52; die Beschreibung nahm an, sie sei mir nicht zugänglich — sie ist es).

Die eine offene Aufgabe, ehrlich eingeordnet: task-19 ist der Production Release. Der Release-Bau ist gemacht (Fassung 2.0.0 in allen Erzeugnissen, § 4), die Veröffentlichung nicht: es wurde nicht gepusht, weil die Hausregel dafür die ausdrückliche Freigabe des Nutzers verlangt (docs/SITZUNGSABSCHLUSS.md, Schritt 6). Die Aufgabe bleibt deshalb zu Recht offen — sie ist der einzige Grund, warum Definition I nicht 100 % zeigt.

3 · Die Tore — Soll, Ist, bestanden

Torquote: 8 von 8 messbaren bestanden = 100 % · über alle zwölf Tore 8/12 = 66,7 %, wobei die vier fehlenden nicht durchgefallen, sondern nicht gemessen sind. Für die Tore 9–12 stütze ich mich auf die Zahlen der Leitung — das sind ihre Messungen, nicht meine.

Randbefund, während der Messung nachgezogen: AGENTS.md nannte für die Tests 725, mein Lauf zählt 733 (acht daneben). Während ich schrieb, wurde die Hauszahl korrigiert — die Datei nennt jetzt selbst „Stand: 733, 82 Testdateien, 91 Module" und beschreibt den neuen Filter samt seiner Tücke: bei einem Filter ohne Treffer zeigt die Bilanzzeile weiterhin „0/0 grün" — es entscheidet der Exit-Code (1). Das ist ehrlich dokumentiert, aber es bleibt eine Zeile, die grün aussieht.

4 · Elf Zusagen, erneut selbst nachgemessen

Zusagenquote: 11 geprüft, davon 1 nicht messbar (die Browser-Messung aus Nr. 6 — die Quelltext- kette habe ich belegt, den Browser nicht) → 10 prüfbar. 9 von 10 bestätigt = 90,0 % · 1 verfehlt (Nr. 11). Zählt man die im Quelltext belegte Browser-Messung mit, sind es 10 von 11 = 90,9 %.

5 · Die Quote — zwei Definitionen, getrennt gerechnet

Definition I — „Aufgabe erledigt" (Prozess). Zählt jede der 52 Aufgaben, die abgeschlossen ist.

51 erledigt / 52 gesamt = 0,9808 → 98,1 %
   offen: task-19 (Release-Bau fertig, Veröffentlichung ohne Nutzerfreigabe nicht erlaubt)
   Die frühere Nachmeldung ist eingetreten: task-41 und task-42 stehen jetzt auf „erledigt".

Definition II — „Behauptung hält der Nachmessung stand" (Wirkung). Zählt jede selbst geprüfte Zusage.

9 bestätigt / 10 prüfbar = 0,9000 → 90,0 %
   verfehlt: APK-Angabe in Architektur.md/CHANGELOG.md passt nicht zur Datei (Nr. 11)
   nicht eingerechnet: 1 Zusage (Nr. 6), die ohne Browser nicht messbar ist — die Quelltextkette
   dazu habe ich belegt; zählt man sie mit, sind es 10 von 11 = 90,9 %

Welche Definition ist die ehrlichste? Definition II — sie misst, ob eine Behauptung vor der Nachmessung hält, nicht ob jemand „fertig" gesagt hat. Definition I belohnt Fleiß, Definition II belohnt Wahrheit. Der Preis: 10 geprüfte Zusagen sind eine Stichprobe, ±1 Zusage verschiebt die Quote um 10 Punkte — die 90,0 % sind deshalb genau auf der Latte, nicht komfortabel darüber. Definition I ist dagegen keine Stichprobe — sie zählt das ganze Board.

[!warning] Unterm Strich — die Antwort auf die Frage des Nutzers Beide Definitionen erreichen die 90 %: 98,1 % (Aufgaben) und 90,0 % (Zusagen). Definition II liegt exakt auf der Schwelle — ein einziger weiterer Abstrich kippt sie unter 90. Der eine Abstrich, der noch steht, ist die veraltete APK-Angabe (Architektur.md:919, CHANGELOG.md:82 gegen die Datei auf der Platte) — dieselbe Sorte Fehler wie der Codec-Beleg vom 06.10. Beide sind in Minuten zu beheben: Zahl und SHA256 nachrechnen, Datum in den Belegnamen. Dann steht Definition II bei 10 von 10.

6 · Die Ausfälle — Stand jetzt

Von den neun Ausfällen der ersten Fassung sind sieben behoben, einer entschärft, einer offen.

Dazu zwei Befunde aus meiner Output-Runden-Prüfung, die inzwischen behoben sind (eigene Aufgaben task-51 und task-52, beide abgeschlossen und von mir nachgemessen):

• inspektor.css hatte 12 einzelne \r und war für git binär (i/-text). Jetzt: 0 einzelne \r, w/crlf, für git Text, Inhalt byte-identisch mit HEAD nach Zeilenenden-Normalisierung.
• Der R8-Verlust: zwei Selektoren ohne jede Regel. Jetzt stehen sie wieder (juice.css:72-73), R8 bleibt 0, und die Kette bis zur OS-Einstellung ist im Quelltext belegt (§ 4 Nr. 6).

Und ein Nachziehbefund, der sich beim Schreiben erledigt hat: AGENTS.md nannte 725 Tests, gemessen sind 733 — die Hauszahl wurde während dieser Messung auf 733 korrigiert (selbst geprüft, AGENTS.md:31).

7 · Was das Team gelernt hat — und was für 3.0 zählt

Was sich wiederholt hat: Anführungszeichen-Falle dreimal, „grün ohne Wirkung" dreimal, veraltete Belege zweimal, ein Werkzeug zehn Minuten kaputt. Das Muster ist immer dasselbe: eine Zahl aus einem Fehlerpfad sieht aus wie eine gemessene Zahl.

Was nachweislich hilft — und jetzt eingebaut ist:

1. Ein leerer Filter ist rot. Die wichtigste Neuerung der zweiten Fassung: tests/run.js schneidet führende Striche ab und bricht ab, wenn kein Test passt. „Grün, aber nichts geprüft" ist damit strukturell unmöglich geworden — nicht nur durch Disziplin verhindert.
2. „Nicht gemessen" ist ein eigener Zustand. ethos.py meldet R12 ausdrücklich als nicht gemessen; es zählt weder als eingehalten noch als verletzt.
3. Gegenproben als Pflicht. ethos.py --gegenprobe sticht elf Regeln absichtlich; menueprobe.py lädt bei „kein UI" genau einmal neu und schreibt die Notiz dazu.
4. Kapseln um jeden Test. Ein sofort ausgeführter Gruppenrumpf reißt den ganzen Lauf mit.
5. Byte-Messung statt Textmodus. Zweimal hat mich der Textmodus getäuscht; beide Male war die Byte-Messung die verlässliche.
6. Die Nachmessung erzeugt Arbeit — und das ist gut. Meine zwei Befunde wurden zu task-51 und task-52 und sind erledigt. Was für 3.0 heißt: jede als „fertig" gemeldete Zusage braucht einen Prüfer mit Byte-Maß, sonst wandert der Fehler in die nächste Fassung.

Was 3.0 noch mitnehmen sollte: (a) tools/pruefe-namen-flicken.js in tools/test.sh einbinden — das Werkzeug ist da, es wird nur nicht aufgerufen (Ausfall 1); (b) ein node --check-Kurzlauf über alle JS-Dateien und ein console.error-Zähler (Vorschlag P3 aus Review – Testqualität); (c) Belege mit Datum und Fassung im Dateinamen, damit die veraltete APK und das Codec-JSON nicht mehr entstehen können.

8 · Nicht feststellbar (Pflichtabschnitt)

• Vier Tore (Rauchtest 45/45, Menüprobe Web 45/0, Android 49/0, R12 im laufenden Programm 6/6 und 3/3) habe ich nicht selbst gemessen — Auflage „keine Prozesse". Sie stehen als nicht gemessen, nicht als bestanden.
• Die Browser-Messung des R8-Fixes („reduziert = 0 Animationen, voll = 1") ist die Messung der Leitung; ich habe nur die Quelltextkette nachgeprüft, die sie trägt (app.js:48, app.js:13-16, dom.js:44, juice.css:72-73).
• Die „27 Fertig-Meldungen" des Auftragstextes kann ich nicht zählen — Meldungen im Postfach der Leitung sehe ich nicht. Was ich sehe, sind 51 abgeschlossene Aufgaben. Die beiden Zahlen messen offenbar Verschiedenes; das bleibt eine Lücke dieser Bilanz.
• Die Codec-Probe habe ich nicht neu gefahren (~250 s, schreibt Nachweise/). Die Zahl 3520 stammt aus dem Beleg vom 06.10., nicht aus meiner Messung — und genau dieser Beleg ist als veraltet gemeldet.
• Die Laufzeit 349 ms des neuen 20-Geräte-Tests konnte ich nicht reproduzieren; ich messe 318 ms (der Test selbst protokolliert 297 ms). Das ist Laufstreuung, kein Widerspruch — aber es ist nicht dieselbe Zahl.
• Ein Nebenbefund aus dem nachgebesserten Bild: Im Codefeld von 2b steht nl9acqam — das entspricht nicht dem dokumentierten Auftragscode-Format NL-XXXX-XX (10 Zeichen, Großbuchstaben, zwei Prüfzeichen, ohne I/O/0/1). Der Status darunter zeigt einen angenommenen Auftrag. Ob das Programm diesen Wert akzeptiert hat oder das Feld nur einen Rest bzw. eine ungültige Eingabe zeigt, ist aus dem Bild nicht entscheidbar — nicht geprüft. Es ist keine Behauptung, sondern eine Beobachtung, die jemand mit laufendem Programm in einer Minute klären kann.
• Keine Aussage über Inhaltsqualität (ob die 58 Aufträge didaktisch taugen) und **keine über eine echte Unterrichtsstunde**.
• Die Quote hat eine Stichproben-Unsicherheit: 9 geprüfte Zusagen, ±1 verschiebt Definition II um rund 11 Punkte. Eine Vollerhebung aller Zusagen war nicht möglich.

9 · Belege dieser Bilanz (alle selbst ausgeführt)