Hand over evidence, not a green status light

In one line

A handoff is not a screenshot of success but conveying what you verified with which code and input, and what is left.

Why this was needed

The developer says "It works well", and the customer asks "Even if we upload yesterday's file again?" The two are talking about different successes. The developer saw one normal request, and the customer is asking whether the business survives when the next owner runs it repeatedly. Good acceptance criteria reveal this difference before any code is written and have you check again at the end against the same criteria.

How it works

First, separate the plan mode from the send mode. The default run sends no HTTP request at all and leaves the source's hash and the send candidates, redeliveries, and holds as JSON. Only when you explicitly give --send does it start the reservations and lookups. It makes the "action that actually changes things" a visible choice. You must not interpret the existence of a plan file as the sending also being completed.

In the send report, you record the status, attempts, and reservation_id of each prepared order. attempts counts only POSTs. It does not add the ledger lookup GETs or the number of redelivered rows in the CSV. If there are held rows or you could not confirm a result, it returns exit code 2. This code does not mean the program crashed but that review items remain in the processing result. If monitoring or the next automation blindly reruns on every nonzero code, holds and failures get mixed up again.

The lab evaluator does not trust your success message; it starts a separate warehouse API and compares the report against the actual number of HTTP requests and the SQLite ledger. It also changes some of the input's order numbers, SKUs, and quantities. If you hardcode only the answer for the provided CSV, it shows on other inputs. You do not modify the grading material or the ledger directly; you implement the public CLI and HTTP contract.

Check	The question it confirms
plan	Did it classify the whole input without sending?
send	On a normal server, did it reserve only the candidates and look up the results?
chaos	Did it handle both a 503 before saving and a response lost after saving?
repeat	Even if you restart the server with the same ledger and rerun, are there no duplicates?
drift	When the contents of an existing order changed, does it avoid bypassing the 409?
outage	On a persistent 503, does it stop after four attempts and leave it unconfirmed?

In the last step, you make the handoff document by running these six checks. implementation_sha256 points to the sync.py you verified, and fixture_sha256 points to the distributed sample CSV. The hash itself is not a quality score. It is a marker that tells whether the file changed after verification. Even if you change only a comment, the bytes of the file change, so you regenerate the document.

In verified_cases you write the cases you ran, and in unresolved you write that the judgments for the invalid quantity and the conflicting order remain. decision is review_only. This is because passing a teaching test cannot replace the customer's production approval. In limits you leave the fact that it is a synthetic single-warehouse experiment and that it does not amount to a production approval. The final grading also does not check only the strings in the document but reruns the checks with the current code.

What it looks like in the field

For the next owner, the failed order number alone may not be enough. They need to know which row of which input, whether a reservation has already been committed, and in which case you stopped resending. That said, you do not need to copy the whole source and the customer emails into the log. In this assignment, you use only the validated order ID, the row number, and a short reason. Even with synthetic data, you practice the habit of not carrying over unnecessary personal information.

This evaluator is a correctness check that runs in the lab container and is not a separate security system that isolates a malicious program with the same privileges. The six cases also do not represent every failure. Writing separately the range that passed verification and the additional review needed for real production is what makes a trustworthy handoff.

Thinking about the next owner's first action

If the person receiving the handoff understands "So we can just rerun everything", the document is insufficient. The hold reason invalid_quantity is a matter of asking the original owner for the allowed integer quantity, and conflicting_order is a matter of asking the business owner which content is the approved order. An engineer does not guess these two judgments from the row order or the smaller quantity. When you receive a corrected file, you do not overwrite the original; you run plan mode on it as a separate input and check the change in candidates and holds.

If the quantity of an already reserved order has changed, you need even more care. This API provides only reservation creation and lookup, and does not provide an amendment or cancellation procedure. Instead of pushing the changed quantity in with a new key, you present the existing reservation and the change request and agree on a change procedure with the customer. It is a small exercise in separating "verification passed" from "we have the authority to run this change". The final document keeps review_only so that it does not claim that judgment has been completed.

The response to an unconfirmed state is different too. You do not fix the source quantity; you confirm the other side's result with the same business identifier and preserve the existing key. You can convey the context with the order and the input hash without spreading a personal email address into new logs. When you explain your own program to someone else after this course, tell them not only how to run the normal success but also when to stop and what to ask.

What you will do in the next lab

You fix the requirements with scope.json and finish sync.py in the order plan, normal send, retry. After checking restart, content change, and persistent failure, you make handoff.json. The expected time is 80 minutes, so extend with +time before the default 60-minute session ends. The maximum is 180 minutes, and the files disappear when the session ends. Keep the finished code separately in your personal workspace before it ends.