Confirmation pass returned BLOCKED, and its lead finding is the one worth having.
The test forbidding the by-name lookup recorded URLs from INSIDE the
`endswith("/branch_protections")` branch, so the only URLs it could ever record were
ones that already satisfied the assertion. A by-name request was invisible to the very
test written to forbid it. Cold review proved it by reintroducing the lookup in the
hook: the suite stayed 33/33 green. That is the filter-on-the-asserted-property defect
this PR's sibling record exists to describe, committed inside the guard against it —
and the commit message had called the twin "pinned so it cannot come back".
The recorder now sees every branch-protection URL whatever its shape. Re-verified by
the same mutation: reintroducing a by-name call reddens exactly the two tests that
forbid it.
Also from that pass:
- an HTTP 404 on the LIST read reached the "the full rule list was read and none
matches" deny — a claim about a read that never happened. Gitea answers 404 for a
repo that is absent or invisible to the credential, so the classifier's own verdict
is now the sentinel `nomatch` and HTTP failures reach the ask;
- two comment blocks still described the deleted by-name endpoint as live, one of them
asserting the classifier "is never reached at all";
- the decision record still documented `branch_protections/{base}` and its 404
semantics as the mechanism, in the record this PR authored — now rewritten to the
list endpoint, with why reading the LIST is the load-bearing choice;
- seven assertions on a string the hook no longer emits, and three test
names/docstrings describing the removed 404 flow;
- an unused fixture helper, and 79 lines left over-indented by the removed nesting.
724 tests green.
refs #778
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
timothyandClaude Opus 5
7d81f85b38