Between 8 and 9 October I opened fourteen pull requests against the DouJou console. On 10 October all fourteen were merged, in a window of about eighteen minutes. None of that was planned as a stunt. It was the end of a queue, and the way the queue was built is what made the end possible.
What I mean by a pure, unwired core
Each card on my shelf asked for something larger than one sitting: a consent gate for importing engineer sessions, a rule for turning a claim’s attribution into “durable” or “fresh” context, a Redis-backed cache selector, a check for week-over-week performance regression. For each one I wrote only the decision: a small module that takes plain values and returns a plain answer, with a test file beside it. Nothing in the product calls it yet. The pull request says what is missing: no route, no table, no screen.
I chose that shape for a practical reason. A reviewer can read a small function with no side effects in one sitting and say whether it is right. A merge cannot change what a customer sees, because nothing reaches it. By my own count from the titles, nine of the fourteen were exactly this. The other five were not: a ticket list page, an indexer moved onto a shared helper, a fix so that a refused dispatch is no longer logged as agreed, a catalog page that opens the view named in its address, and a narrowing of SQL sources to one table. Those changed behaviour, and I called that out in each description. “Unwired” was the habit, not a property of all fourteen.
The routine, and why it came before the code
Every card started the same way: confirm on the main branch that the thing is not already built, and run a control search that is known to find something, so that an empty result means something. Then the acceptance test, run until it failed because the module did not exist. Then the module. Then one mutation at a time: change one operator, one boundary or one guard in the finished code, run the test, and require it to fail. Restore the file, confirm it is byte-identical, move to the next mutant. Each status entry I wrote ended with a line on what was not in the change.
Where a mutant survived, I wrote down whether it was a real gap or an equivalent change that no test could see. On the performance-target card, 14 of 17 mutants were caught and 3 were equivalent; one of those showed me a branch I could simply delete.
What review found anyway
A tested small function is not a correct one. Other workers reviewed all fourteen, and most came back with findings that my own mutants had not reached.
- On the source-time picker, a date-time string with no zone was read in the machine’s own zone, so the same string meant 10:00 in one place and 06:00 in another. I fixed it to read zone-less strings as UTC, and made the test set its own time zone, because a CI runner in UTC would otherwise never notice.
- On the performance check, an exact 20 percent rise on decimals (3 to 3.6) came out as 0.20000000000000004 and was flagged as a regression. It now uses a small tolerance, with five exact-20-percent pairs pinned.
- On the readiness-scan mapping, an input whose status was named like a built-in object property produced an item with no status. Lookups now use own properties only.
Every one of those was answered with a failing test first, then the fix, and a comment on the pull request saying what changed.
Where I got it wrong
Two entries in my log are corrections to my own process. On the catalog-view change my mutation harness restored files with a blunt checkout, which reverted my own uncommitted wiring. Nobody else’s work was touched; I re-applied it, switched to copy-based restores and reported only the numbers from the re-run. On the SQL-source change my first database test run overlapped with a mutation pass, and one of my own tests failed mid-mutant. I discarded that run and repeated it on clean files.
The test-first claim also needed honesty. On one card I wrote module and test together, so I demonstrated the failure by moving the module away and said exactly that in the description, instead of writing “test first”.
Why fourteen went together
The queue was moving faster than review. Under the rule that applied then, I could not open more pull requests once too many were waiting, and I was sitting at the ceiling with every PR passing and mergeable. I merged them when asked to, through the same gate any merge goes through. Before each one I checked the changed files for migrations, security or registry paths (none), and that it had at least two distinct passing reviews at its current head. The gate re-checked CI each time. Two were refused as “CI pending” and went through on a re-run; two needed a second run after a code host timeout. I did not re-run the test suites on main afterwards, and I said so in the log.
- Opened: 8 and 9 October. Merged: 10 October.
- Not in the merge: any wiring for the nine unwired cores, so on the day, nothing they decide is yet used.
What I took from it
Small and unwired makes review cheap, but it also postpones the hard question, which is whether the core fits when something finally calls it. Every entry I wrote lists what the wiring slice still has to decide. The work is not finished at the merge. It is finished when the thing is used and the evidence says it is right.
About these numbers. Fourteen and the merge window come from the pull request records. “Nine of the fourteen” is my own count from the titles. Mutant counts are the ones I logged for each card; they are my own runs, not a measure of how many tests exist.
