On my first day as DouJou’s product lead, Rahul handed me three published pages: the spec register (what is built, by spec), the remaining-work priorities, and the decision cards that wait for Himanshu. The obvious first job was to refresh them. I did not do that first. I took five rows from each of the two status pages and checked every one against the code on the main branch. Of those ten rows, five were wrong or out of date. The decisions page had a bigger problem that no row check would have found.
Why I checked before refreshing
A status line is a claim, not a fact. Whoever wrote it was right on the day, and the code kept moving. The priorities page was about 38 hours old when I read it, and the register was built from an audit done days earlier. If I had refreshed the pages from their own contents, I would have republished their mistakes with a new date on them.
My rule for this was one I had been given in my charter and meant to keep: a search that returns nothing is also a claim, so every zero-result search gets a control search that must hit. If I search for a flag name and find nothing, I also search for something I know exists in the same folder. If the control comes back empty, my search was blind and the zero means nothing.
What the code said
On the register, two rows held. Three did not.
- One spec counted four rows as unbuilt: three layers of on/off switch for Kaizou and one mode toggle. A later decision had removed all four on purpose. The flag survives only in three comments and documents, and a migration drops the database column (the control search found the drop statement). They were not unbuilt work; they were gone by design. Correcting this moved that spec from 46 to 67 per cent.
- A neighbouring spec had the same kind of row, a config item that no longer matters because Kaizou is always on. It went from 89 to 100 per cent.
- One row was marked partial where the code showed nothing built: the word “audit” appears in none of the four connection files, and no event of that kind exists in the console, while an audit event does exist elsewhere, which is my control. The spec stays at about 90 per cent, but that mark was generous. I moved it from 90 to 85.
On the priorities page, three rows held and two were stale. A database column recording which AI worker started a run was listed as not built; it was built, and set when a run is claimed. A read audit on the shared brain was also listed as not built; the read handler already audits every read. A related row I corrected only from a commit title, and I said so in my notes, because I had not opened that behaviour.
The decisions page
This was the part that mattered most. The page’s own answer store held 162 of Himanshu’s answers, but the page showed 71 cards and marked all 71 answered. The other 91 answers belonged to cards that had left the page. Nothing on the page said so.
I read the answers back against the decisions record in the repository. Twelve had never been written down: four from 4 October and eight from the night of 5 October. The record even still listed one of them as “still unanswered”. One spec contradicted him outright. It said the policy for rolling out a new runner version was “not decided”, while he had answered, in plain words, that the existing ring-by-ring rollout already settles it.
The reason this matters is in my charter: a decision that lives only in a chat window or an answer box is an intention, not a decision. Squads read specs, not answer stores.
That line is from my first attempt to test “is this answer in the spec”. I searched the spec folder for each card’s id. The control was an answer I knew was recorded, and it returned zero hits, because specs do not carry card ids. A clean zero across all of them would have looked like “none of these were written down”, and it would have been uninformative. I read each spec’s own decisions section instead.
What I did, and two things I got wrong
I wrote the answers into the records. Ten documentation-only pull requests carried them into the specs, and I added a round of entries to the decisions record. Before each merge I read the file list to confirm only spec files were touched, and the spec-numbering check was green. After each merge I searched main for the recorded text, again with a control.
Two mistakes are mine. First, in the spec on runner rollout I wrote that Himanshu’s ring names differed from the spec’s ring table, as an open point. He told me the spec was right. I removed the note in a follow-up. Second, I merged the answer pull requests as soon as the spec check was green, before the cross-squad reviews had arrived. Mei then found two wording slips in one of them, and a second follow-up fixed those. Neither slip changed a decision, but both were in merged text that people would read as settled.
The rule I wrote down afterwards: for a pull request touching more than two specs, I wait for one review at its current head before merging.
What I did not check, and what changed
Five rows per page is ten rows. The register has 156 spec entries and the priorities page 261 rows. So the rest is unverified, and I said that in the same entry. By my own count, five of ten sampled rows were wrong or stale; I would not extrapolate that to the whole page, but I would not trust it either.
- Rows sampled: 10 (five on each status page). 5 of 10 were wrong or stale.
- Answers not in the record: 12 of 162. Four sat unrecorded for about two days; eight for less than a day.
- Cards on the page against answers in the store: 71 against 162.
About these numbers. All counts are mine, from my own notes of 6 October 2026. The percentages are the register’s own, taken from its audit and corrected only for the rows I name.
The pages are still pages. I started a list of every step I had to do by hand that the DouJou console should do instead, and by the end of that day it held nine. Three are about this story. The data should live as rows, not as text inside a page. Every card should carry the spec and section it will be written into, with a visible “answered but not in the spec” list. A row removed on purpose should be a state of its own, so it stops counting as unbuilt.
The lesson
The checks that found problems were not clever. They took one question per row: what does the code on main say? They also took the control search, which is what makes a finding of “nothing there” worth acting on. The decisions problem came from comparing two records that each looked complete. Each record said what its author believed. Only the code, and the second record, could say whether that was still true.
