timothy
33e9abdd20
Review verdict / Set review-verdict status (pull_request) Successful in 4s
review-verdict/h10 Review-verdict: MERGEABLE @ 33e9abd
PR Gates / CI image pin matches docker/ci (pull_request) Successful in 12s
PR Gates / Docs update reminder (pull_request) Successful in 18s
PR Gates / decisions lifecycle (pull_request) Successful in 24s
Build ErsatzTV Image / Build & test (.NET) (pull_request) Successful in 8m46s
Build ErsatzTV Image / Formatting (changed .cs conform to .editorconfig) (pull_request) Successful in 19s
Build ErsatzTV Image / API docs in sync (OpenAPI + endpoint index) (pull_request) Successful in 5m21s
Build ErsatzTV Image / EF migration integrity (SQLite + MySql) (pull_request) Successful in 17m13s
Build ErsatzTV Image / Functional E2E (curl + UI contracts) (pull_request) Successful in 17m54s
Build ErsatzTV Image / Build & push image (amd64) (pull_request) Has been skipped
Round-3 review finding, and a correction to what the previous commit claimed. That commit said the regex matched the cap "as a whole token" and called the result "exact". The whole-token part was true and did fix the 100-within-1000 substring hole. "Exact" was not: `capped at 100(?!\d)` asks only whether a correct claim is PRESENT, which is not the same as asking whether an incorrect one is ABSENT. A description reading "not capped at 1000 for this endpoint; capped at 100 …" satisfied it while publishing a wrong number to every consumer. Enumerate every `capped at <n>` in the description instead and require the set to be exactly one number, the right one. Mutation-verified on the constructed case: /logs naming both 1000 and 100 now reddens the test, where it passed under the previous form. This is the third round on this one assertion, and each round found the previous fix's blind spot rather than a fresh mistake — the failure mode was consistently "the new check tests presence of the right thing, not absence of the wrong thing." Note on verification: the reviewer could not run the suite (its sandbox could not create a temp dir, and a direct VSTest invocation could not bind its IPC socket), so it explicitly flagged the 1905/0 result as unverified rather than trusting it. That figure comes from my own run in this worktree, re-run after this change, and CI is the independent confirmation. Refs #633 Decisions-Edit: yes