緑の表示ではなく検証根拠を渡す

一言でいうと

引き継ぎとは、成功したスクリーンショットではなく、どのコードと入力で何を検証し、何が残っているのかを伝えることです。

なぜ必要なのか

開発者は「問題なく動きます」と言い、顧客は「昨日のファイルをもう一度アップロードしても、ですか」と尋ねます。2人は、別々の成功を語っています。開発者は正常なリクエストを1回見ただけで、顧客は、次の担当者が繰り返し実行しても業務が壊れないかを尋ねています。よい受け入れ基準は、この違いをコードを書く前に表に出し、最後に同じ基準で再び確認させます。

どう動くのか

まず、計画モードと送信モードを分けます。デフォルトの実行は、HTTPリクエストをまったく送らず、元データのハッシュと、送信の候補・再配信・保留をJSONに残します。--sendを明示してはじめて、予約と参照を始めます。「実際に変更する動作」を、目に見える選択にするのです。計画ファイルが存在するからといって、送信まで完了したと解釈してはいけません。

送信報告書には、用意した各注文のstatus・attempts・reservation_idを記録します。attemptsは、POSTだけを数えます。元帳を参照するGETや、CSVの再配信の行数は足しません。保留の行がある場合や、結果を確認できなかった場合は、終了コード2を返します。このコードは、プログラムのクラッシュではなく、処理の結果に確認すべき項目が残っているという意味です。監視や次の自動化が、0以外のコードをすべて無差別に再実行すると、保留と障害がまた混ざります。

ラボの評価ツールは、あなたの成功の文言を信じる代わりに、別の倉庫APIを立ち上げ、実際のHTTPリクエスト数とSQLiteの元帳を見て、報告書を照合します。入力の注文番号・SKU・数量の一部も変えます。提供されたCSVの正解だけをハードコードすると、別の入力で露見します。採点用の資料や元帳を直接直すのではなく、公開されたCLIとHTTPの契約を実装する必要があります。

検査	確認したい質問
plan	送信なしで、入力全体を分類したか。
send	正常なサーバーで、候補だけを予約し、結果を参照したか。
chaos	保存前の503と、保存後の応答の消失を、どちらも処理したか。
repeat	同じ元帳でサーバーを再起動して再実行しても、重複がないか。
drift	既存の注文の内容が変わったとき、409を迂回しないか。
outage	持続する503で、4回のあとに止まり、未確認として残すか。

最後のステップでは、この6つの検査を実行した引き継ぎ文書を作ります。implementation_sha256は検証したsync.pyを、fixture_sha256は配布されたサンプルのCSVを指します。ハッシュ自体は、品質のスコアではありません。検証のあとにファイルが変わったかどうかを区別する目印です。コメントだけを変えても、ファイルのバイト列が変わるので、文書を作り直します。

verified_casesには実行した事例を、unresolvedには、不良の数量と衝突した注文の判断が残っていることを書きます。decisionはreview_onlyです。教育用の試験に通ったからといって、顧客の運用の承認の代わりにはならないからです。limitsには、合成した単一の倉庫の実験であることと、運用の承認に当たらないことを残します。最終的な採点も、文書の文字列だけを検査するのではなく、現在のコードで検査をもう一度実行します。

現場での姿

次の担当者には、失敗した注文番号だけでは足りないことがあります。どの入力の何行目か、すでに確定した予約があるか、どんな場合に再送を止めたのかを知る必要があります。だからといって、元データ全体や顧客のメールを、ログにコピーする必要はありません。この課題では、検証済みの注文ID・行番号・短い理由だけを使います。合成データでも、不要な個人情報を移さない習慣を練習します。

この評価ツールは、ラボのコンテナで実行される正確性の検査であり、同じ権限の悪意のあるプログラムを隔離する、別のセキュリティシステムではありません。6つの事例も、すべての障害を代表するわけではありません。検証を通過した範囲と、実際の運用に必要な追加の確認を、分けて書くことが、信頼できる引き継ぎです。

次の担当者の最初の行動まで考える

引き継ぎを受けた人が「とりあえず全部もう一度実行すればいいんだな」と理解したなら、文書が不足しています。保留の理由invalid_quantityは、元データの担当者に、許可された整数の数量を確認する仕事で、conflicting_orderは、どの内容が承認された注文なのかを、業務の担当者に尋ねる仕事です。この2つの判断は、エンジニアが、行の順序や、より小さい数量を見て、推測することはしません。修正されたファイルを受け取ったら、元データを上書きせず、別の入力で計画モードを実行して、候補と保留の変化を確認します。

すでに予約された注文の数量が変わっていたなら、さらに注意が必要です。今回のAPIは、予約の作成と参照だけを提供し、修正・キャンセルの手続きは提供しません。新しいキーで、変更した数量を押し込む代わりに、既存の予約と変更のリクエストを示して、顧客と変更の手続きを合意する必要があります。「検証に通ったこと」と「今回の変更を実行する権限があること」を分ける、小さな練習です。最終的な文書は、その判断を完了したと主張しないように、review_onlyを維持します。

未確認の状態への対応も違います。元データの数量を直すのではなく、同じ業務の識別子で、相手側の結果を確認し、既存のキーを保存する必要があります。個人のメールアドレスを新しいログに広げなくても、該当する注文と入力のハッシュで、文脈を伝えられます。このコースが終わったあとで、自分のプログラムを他の人に説明するなら、正常に成功させる実行の方法だけでなく、いつ止めて、何を尋ねるべきかまで、話してみてください。

次のラボですること

scope.jsonで要求を固定し、sync.pyを、計画→正常な送信→再試行の順で完成させます。再起動・内容の変更・持続する障害を確認したあと、handoff.jsonを作ります。想定所要時間は80分なので、デフォルトの60分のセッションが終わる前に、＋時間で延長してください。最大180分で、セッションが終わるとファイルは消えます。完成したコードは、終了の前に、個人の作業スペースに別に保管してください。