Twelve green modules, and one assembled product
Published
The swarm was built by twelve parallel owners, one per module, each with an exclusive file list and its own gate. Every lane finished green on its own terms. Then the assembled coordinator ran, and the first thing it did was demonstrate that a green module is not a wired module.
The coordinator that bypassed the policy
The first assembled coordinator ran on an internal queue scheduler and never consulted the policy engine. The residency rule, the hard filter that the whole product is justified by, was enforced by a module that the dispatch path did not call. The same coordinator paid out on the worker self-reported duration. Every module passed its own tests, and the product enforced almost nothing.
The fix was structural rather than another test: the default composition of the coordinator uses the real registry, policy, scheduler, ledger, chain and verification modules, and the test doubles that had been living in the source tree were deleted. Doubles belong in test files. The rule that came out of it is written into the contract: acceptance for any future lane is the running product, not its own suite.
An invented route, and a seam nobody used
One component wrote the path of an endpoint as a literal string instead of reading the route constant from the frozen interface. The literal was a different path from the one the seam named, so the dashboard called something nothing else served. The route constant now exists because of that defect, and the rule is blunt: a literal path in any component other than the interface file is a defect.
The second seam defect was found by the end-to-end script rather than by a unit test, and it could not have been found any other way. A job has to be encrypted to one device key before it is submitted, and the device list route deliberately returns no keys. That made outside submission impossible: only an in-process demo could submit, because it generated both sides of the exchange itself. The device identity route was added specifically so a real, separate contributor process could fetch one public key. The two-contributor acceptance test found it by being unable to cheat.
Things that only the assembled product exposed
- A placeholder backend label had leaked into a jurisdiction field in two components, so neither could register at all. The validator now requires a real two-letter country code.
- Payout was measured on the wall clock, and a fast job rounded to zero milliseconds and paid nothing. Payout is now measured with a monotonic sub-millisecond clock and carried inside the signed result.
- The credit display preferred a display-only value over the authoritative integer balance, so an operator panel showed the wrong number in the wrong unit.
- An acceptance assertion compared a short balance against a whole page of text and matched an unrelated identifier, reporting success twice while measuring nothing. It now asserts the exact formatted string, which a random identifier cannot fake.
The gate needed hardening too
One test file finished its assertions and then never exited its event loop, which made the whole suite hang. A per-test timeout does not bound a live loop, so the gate now bounds the suite subprocess on wall-clock time, kills the process group, and reports the hang as a failure. It also fails a run that ends early with too few tests collected, and strips test-runner environment variables from the child process so a nested runner cannot inherit a mode that hides the problem. A gate that can hang forever is not a gate.
The assertion that demanded the wrong thing
One test asserted that the browser worker page carried every route in the interface. That was true when it was written and stopped being a requirement the moment an operator-only route was added, so it went red against a correct product. The lesson recorded at the boundary is precise: an assertion must not demand more than the component owes, and the right set to assert is the routes that component actually uses. A test that is wrong about the product is worse than no test, because someone will edit the product to satisfy it.
What twelve green suites were never going to catch
None of these defects lived inside a module. They lived on the paths between modules: a scheduler that was not called, a route that was spelled differently, a key that could not be fetched, a unit that only mattered once two real processes met. If this wave has one transferable finding, it is that the integration boundary deserves a real, assembled, end-to-end check and that each owner needs to know which other modules its own actually has to satisfy. The full list of these decisions is written into the spec, because the alternative was a green suite and a product that enforced nothing.
Sources
Each link goes to the source the post cites. Where a source does not state a fact, the post shows it as unverified instead of filling it in.