Work sample
Where an agent can work alone, and what has to hold before its change merges.
I answered it on a public .NET platform with orders and multi warehouse stock: an autonomy policy that executes, boundary rules measured against the real assemblies, and one order and stock case taken end to end.
An agent broke an order and stock invariant. The harness refused the merge.
The platform reserves stock across warehouses and, when they cannot cover an order, books the shortfall anyway. Its own comment says so, and nothing in the codebase writes down the rule that decides whether that is right.
- 01
The invariant, written down first
No warehouse commits more units than it holds. Stated as a property of the final state rather than an assertion about one code path, so a change arriving by another route still has to satisfy it.
- 02
A plausible change that satisfied the request and broke it
The request: ship from the warehouse that holds the most units. This version was written deliberately, to be wrong, because a control nobody has handed something bad is a control nobody has checked. It compiles, it does what was asked, and no boundary rule has anything to say about it.
FAILED CommittedStockNeverExceedsHeldStock Expected record.ReservedQuantity to be less than or equal to 8 because warehouse 1 cannot commit units it does not hold, but found 9.
Only a test that knew what stock means could refuse it, and the pull request was not merely red: branch protection held it at BLOCKED.
- 03
The correction, one line apart
Serves the biggest warehouse first, as asked, and still takes from each site only what is free in it. One line of difference, and no test was touched to make it pass.
What this does not claim
A public codebase is not a production ERP. It shares the shape, not the stakes, and not the decisions somebody made years ago and never wrote down. I know nothing about yours.
Multi store is not multi tenancy. Stores here can share a catalogue and customer accounts. Real tenant isolation is its own class of work, with its own negative tests.
SQLite is not SQL Server. The suites run on SQLite, so this is about application logic. Locking and isolation are not exercised, and the race between two checkouts is not reproduced.
Four tickets is not a measurement. The diagnosis says which classes of work were exercised, which were proposed, and which were not evaluated.
The same exercise on a real platform
An independent review of a representative scope: a few areas, the conventions as they stand, the existing pipeline, and the AI assisted changes that already went in. What comes back is a written opinion with the measurements behind it. One possible conclusion is that the setup you have is already enough.