Places where an assumption made during this build was proven wrong, or refined, by testing this build actually ran. Each entry is phrased as what was assumed and what was found. No entry here describes a mistake that was avoided by planning ahead of time; those are recorded as design decisions in FINDINGS.md instead. These are the ones testing genuinely corrected.
-
Generation-counter rationale. Assumed, when the arena's generation-counted handles were first built, to guard against a client-triggered ABA: a stale cancel reaching a reused arena slot and cancelling the wrong order. Found, by a fault-injection test that constructs a stale handle directly and by observing which assertion actually caught two unrelated planted bugs during fuzzer calibration: Cancel and Amend are order-id keyed and resolve through the live index on every call, so no sequence of ordinary client commands can ever present a stale handle. The counter guards an internal-corruption state that is unreachable through the public API, which is a stronger property than the one first assumed, not a weaker one.
-
The retirement window's membership set was assumed bounded by construction. The design called for a structure that never grows past its reservation, and the implementation seemed to satisfy that: a fixed initial capacity, and an eviction always performed before an insert once at capacity, so occupancy itself never exceeds the reservation. Found, by a test built specifically to assert zero allocations across ten million sustained commands: bounding occupancy is not the same guarantee as bounding the underlying table. The hash set used underneath still grew its own internal capacity after enough insert-and-evict churn, from a requested 16,384 up to 57,344, because its tombstone accounting forces a resize as removals accumulate regardless of how small live occupancy stays. Replaced with a hand-rolled fixed-capacity structure using backward-shift deletion, which has no tombstones to accumulate and so has no code path that could ever grow it.
-
The cost of cloning the book for a fill-or-kill dry run was assumed negligible, or more precisely was never assumed about at all: the clone was already known to need to be total for correctness (a partial clone had already been identified as a way to reintroduce a self-match bug), and nothing about that reasoning considered the clone's cost. Found, by a seeded fuzzing run whose throughput degraded as the run got longer rather than staying flat: the clone was carrying the book's entire command log along with it, a field with no bearing on matching semantics that the dry run's shadow copy never reads before discarding it, and the cost of cloning a growing log made every fill-or-kill order more expensive than the last. A clone kept for one throwaway use should not carry a run's entire history with it. Fixed by excluding the log from the clone specifically, keeping every other field total exactly as the original correctness reasoning required.
-
Whether a post-only order that would only cross its own account's resting order should be treated the same as any other cross was never settled explicitly, and an adversarial review of the two engines surfaced it as an apparent inconsistency: a post-only order whose only crossing counterparty is the same account's own resting order is rejected outright, while a resting Limit order crossed by an amend has its self-match cancelled and is allowed to proceed as a taker. Read side by side, this looks like the engine answering the same question two different ways. Investigating the actual semantics involved found it is not the same question. A resting Limit order is always allowed to become a taker; self-match prevention exists to stop it from trading against its own resting order specifically, not to stop it from trading at all, so cancelling the stale resting order and letting the amend proceed is the correct application of that policy. Post-only exists to guarantee something stronger and unconditional: that the order it is attached to never becomes a taker, full stop, for any reason, including a reason as narrow as "the only thing in the way happens to belong to the same account." Treating a self-only cross as not a real cross would quietly weaken that guarantee for a kind of order whose entire purpose is to make the guarantee absolute. The resolution: post-only's crossing check stays account-blind, rejecting on any cross regardless of whose order it would have crossed, and this is now pinned by a dedicated test in both engines rather than left to be re-discovered as a possible inconsistency by the next reader.
This project's working name described the state its engine must never enter: two resting orders on opposite sides of the book crossing each other, priced against a counterparty nobody agreed to trade with. It was renamed once the project's actual center of gravity became clear. The engine was never really the hard part. The hard part, and the actual subject of every finding in this report, was the machinery built to check the engine: a shadow reference implementation trusted only because it is simple enough to read at a glance, a generator trusted only because its model of the book's state is not a model at all but a live query against that same shadow, and a differential harness trusted only because it was deliberately calibrated against bugs it was shown to catch before its silence on a real run was allowed to mean anything. Every finding in this report turned out to be a bug, or a cost, in a shadow of the book's state rather than in the book itself. The new name fits what the project actually turned out to be about.