Build notes

A systematic review is not a summarisation task. It is an argument that a specific set of papers was found by a stated method, judged against stated criteria, by named people — and that someone following the same steps would arrive at the same set. The value is entirely in the traceability. A screening decision nobody can account for is worth less than no decision at all, because it looks like one.

The practical version of the objection is simpler. A reviewer asks why paper 147 was excluded. The answer has to be a person, a reason from the agreed list, and a timestamp. "The model scored it below threshold" is not an answer that survives peer review, and neither is a person who says they checked the model's work on three hundred papers.

So the ranking in search suggests an order and nothing more, extraction fields are typed by people, and quote-typed questions cannot be typed into at all — only filled by selecting the passage in the paper. The database rejects an answer that is not linked to one. That constraint is annoying about twice a week and it is the reason the evidence table means something.

Every screener's interface reported that they had decided five papers that session, and every one of them was telling the truth about what it had done. They were overwriting each other. Two people opening the same paper both read its status as unscreened, both wrote a decision, and the second write replaced the first with no trace anywhere a human would look — including a supervisor's exclusion being reversed by a colleague's include.

No amount of single-user testing finds this. It needs concurrency and it needs the same queue, which is exactly what an exit trial with real people is for and exactly what a demo never reproduces.

The fix is that every decision now carries the status the screen was showing when the person decided, and the write locks the row and compares before it swaps. A decision made about a paper that has since moved is refused and returned, naming who moved it. The first version of that check used a plain read instead of a lock and caught fourteen of fifteen collisions — a number that looks like success and is not, because the fifteenth is a silently wrong review.

The other half of the fix is that no two people see the same queue order. Collisions are rarer now because the app stopped arranging them.

A test that asserts a query returns no rows passes just as happily when the rule works, when the rule was never applied, and when the query was wrong. Three very different situations, one green tick. Row-level security is especially good at this: a policy with a typo in its condition denies everything, which looks exactly like a policy that is working.

So every check that expects to find nothing is paired with a mutation: the same query with the rule switched off, which must fail. Drop the trigger, watch the suite go red, put it back. If it stays green without the rule, the test was measuring nothing.

This caught a real one in the encryption work. Removing a member from a project was supposed to rotate the project key to a new epoch, so that someone removed cannot read what is said afterwards. The rotation was implemented, reviewed and covered by a passing test. It was triggered by nothing — no code path called it. The test passed because it called the rotation itself. What replaced it is honest rather than automatic: removal marks the project as needing rotation, and an admin performs it in a browser, because the key exists nowhere else. The window between those two moments is real, and every page that mentions removal now says so.

The focus rule lived at the top of the stylesheet, outside any cascade layer. Unlayered CSS beats layered CSS regardless of specificity, and Tailwind's utilities are layered — so `focus-visible:outline-none`, which the form primitives and the nav links and most of the buttons all carried, had never applied. Not overridden: never applied. It compiled, it shipped, it did nothing.

This is a whole family of bug that only exists in a utility-first codebase, and it is genuinely hard to see, because the failure mode is that the correct-looking code has no effect. The same afternoon turned up a second one in the header: links marked `hidden sm:inline-flex` were visible on a phone, because Tailwind emits `.hidden` before `.inline-flex` and the base class list already contained `inline-flex`. Equal specificity, later rule wins, the link stays. The header wrapped to two rows, covered the top of the page, and six end-to-end tests failed somewhere else entirely.

Both fixes are one line. Finding them was not, and the reason is worth writing down: when an override silently does nothing, the instinct is to add a stronger override. That works, and it buries the actual cause one layer deeper for whoever looks next.