Adding NATS JetStream to a Jepsen-style harness took zero changes to the checker

`checker.Check` runs a Wing and Gong style search over the sequential orderings of a recorded history, memoized on the pair `(remaining-operations, sequential-state)`. The search budget is bounded, so a history it cannot resolve returns inconclusive instead of hanging forever ^[8]. Two details in that code are the ones I would copy. Numeric equality is exact, through `big.Rat`, applied recursively across JSON-shaped values. A client whose wire protocol round-trips numbers through JSON turns a Go `int` into a `float64`, and a naive comparison flags every one of those operations as a false violation ^[9]. The memoization key is only a bucket hash, so every cache hit is confirmed with full structural equality before it is used ^[10].

Faults go through Apply, Verify, Clear, across partition, kill, delay, drop and reorder ^[20]. A partition's `Verify` pings across the intended break and asserts that the ping fails, and nothing counts as coverage until it is confirmed against the real container ^[7]. That check passed unconditionally for a while, because the container images did not ship `iputils-ping`, so `ping` exited with "command not found", which in code is indistinguishable from a partition genuinely blocking traffic ^[15].

`containerIP` read only Docker's legacy default-bridge field, `.NetworkSettings.IPAddress`. That field is empty for any container on a user-defined network, and every deployment here uses one. The partition injector silently resolved an empty peer IP until the first live test ^[13]. `Clear()` for partition, kill and netem faults returned immediately on its first error and abandoned cleanup for every other node ^[14]. That stranded a live three-node etcd cluster in a partitioned, unrecoverable state for several days before diagnosis, and cleanup is now best-effort across every node regardless of earlier failures ^[14]. The fourth documented bug is in the ToyKV fixture. The server wrote the CAS outcome to `wireResult.OK` while the client read `wireResult.Value`, so every real client saw `nil` for every CAS regardless of outcome. The unit tests exercised the store directly and never went through the HTTP path ^[12].

Three of those four are in the fault-injection and Docker plumbing; one is in a target's client ^[18]. The post counts six bugs caught in the harness itself, and four of them are documented ^[17]. Its author wrote that "a correctness tool that has never caught anything isn't credible" ^[5].

The clean result is evidence about the schedules that were actually run. The write-up describes the outcome as "no violations found across N campaigns, fully reproducible", and it omits N, the workload size and the fault mix ^[19]. Reproducibility is cheap here because the campaign package derives both the fault schedule and the workload from one seed, then checks the recorded history ^[21]. For the etcd verdict to carry to another etcd deployment, that deployment's clients would have to use linearizable reads and transaction-based CAS the way this target does ^[16]. Its fault schedule would have to reach the same five fault types ^[20].