Iliya Oblakov

Thanks. You're right that it's the weak spot, because the gate runs whatever tests are in the commit. It isn't in RULES.md. It's in the review prompt Codex gets: every test change has to fail on the old behaviour, nothing can be weakened without a stated reason, and the reviewer has to check the diff for any weakened or deleted test. So a loosened assertion with no reason comes back as CHANGES REQUIRED, but it's the reviewer's call rather than a hard check in the script. A script that flags removed asserts in the diff would be a good addition, and I'll look at it.

Thanks, that is a good tip, and an easy one for a small team to do. I didn't score service text on its own in this check, so I can't say whether those sites did better on the rest. It's a good question, and I'll add it as a separate check next time.

Thanks. Yes, that's why the verdict file is named after the commit hash, so an ACCEPT for an older commit can't cover code that came after it. On acceptance criteria: yes, that's where I took it next. Each change now starts with a short "Done means" list, and Codex has to mark every line as met, not met or not checkable, with the house rules checked the same way. I count a "not checkable" answer as a finding about the brief, because it means I wrote a requirement nobody can verify. I wrote that up as a follow-up on my blog, "How to make Codex review Claude Code's commits", if it's useful.