Resolve an uncertain write and reject a faulty change

The C1 implementation prevents duplicate writes, but an uncertain operation can remain uncertain forever. The next feature gives the application a way to ask the receiving system what happened. We will also test whether the factory rejects a candidate that lies about success.

These are different questions: can the application recover, and can the acceptance machinery notice when it does not?

Add reconciliation

Open tasks/c2.md. When a request repeats an operation with a pending local record, the application may call remote.lookup(key). The lookup is scoped to the current account.

If the dependency returns an existing receipt with the matching payload, the application can store that receipt and return confirmed. If lookup fails, returns no receipt or reports a different payload, the result stays unknown. It must not repeat the write just to obtain a clearer answer.

Generate C2 from your accepted C1 candidate:

python3 build.py c2 runs/c1-build-01/candidate.py --model claude-sonnet-4-6 --budget-usd 2 --out runs/c2-build-01
python3 factory.py release runs/c2-build-01/candidate.py --contract c2 --out runs/c2-release-01

Run the second command only if generation produced a candidate. If your C1 attempt did not pass, stop that model-generated path. You can still study the worked solution honestly:

python3 factory.py release reference/c2.py --contract c2 --out runs/c2-reference-release-01

Look for reconcile_lost_reply, lookup_failure_stays_unknown and lookup_failure_no_repeat_write in the report. Together they distinguish recovery from optimistic guessing. C2 must also retain C1’s duplicate, conflict, concurrency and restart behavior.

Challenge the acceptance decision

The negative control deliberately changes the hand-authored C2 solution so uncertain operations return a fabricated confirmation. It should fail the very check that required uncertainty to remain visible.

python3 factory.py negative --out runs/negative-01

Here "passed": true means the checker rejected the faulty candidate in the expected way. Open the report and verify negative_control_rejected: true, released: false, and a failed lost_reply_unknown check. There must be no promotion.json in the negative-control directory.

Do not count this deliberately broken candidate as an ordinary unsuccessful build when calculating the success rate of model-generated changes. Keep it as a separate test of the instrument. If the checker accepts it, stop using that checker to make release decisions until you understand and repair the gap.

Decide what remains human

The workflow can produce a candidate, execute checks and follow a release rule. Someone still owns the meaning of the rule. Suppose an agent proposes replacing “unknown after a dropped response” with “assume success after three seconds.” That is a change to the acceptance criteria and the customer’s risk, not merely another implementation attempt.

You can ask an agent to propose better tests. Preserve the existing checks, show which cases the proposal changes and require the task owner to decide whether the new contract is acceptable. A builder should not make its own work pass by quietly weakening the test.

Check your understanding

Question: Lookup is unavailable, but the application’s local record shows that it attempted the write. Can it return a confirmation?

Answer: No. An attempt record does not establish the receiving system’s effect. Preserve unknown; recover when evidence becomes available or route the case to a human decision.

Transfer exercise: Change the example from contact updates to reserving an appointment. Specify the operation identity, the evidence of a completed reservation, a response-loss case and the cancellation policy. Do not reuse the contact-update test unchanged. Explain which invariants transfer and which belong to the new customer workflow.

Your evidence: Keep the baseline, C1, C2 and negative-control records, including failures and human interventions. This is a completed small exercise, not a general dark-factory benchmark or evidence of unattended production reliability.

For the surrounding explanations, return to dark software factories. To study the tools, memory and recovery inside an individual agent, open the always-on agent book.