WorldScript Studio gives merge-blocking power to four of its fifteen automated reviewers

Blocking power in this registry depends on how a tool fails. According to a dev.to write-up of the project, the four providers that can stop a merge are CodeQL, OSV, GitGuardian and Socket, all deterministic security gates ^[3]. The other eleven can comment and nothing more ^[6]. The post argues that an LLM should never hold a merge wall because its error mode is "confident nonsense" ^[7]. I think that is the right cut for a project with this many reviewers. A deterministic scanner that misfires does it the same way on every run, so the false positive can be reproduced and suppressed. Here the semantic reviewers' misfires show up as comments, because blockingAuthority is false for every one of them ^[4].

The registry is a JSON file, config/reviewer-registry.json, with a schema version and an authority pointer. The excerpts come from commit 99024a4b, dated 2026-09-28, in release v1.28.8 ^[2][20]. The CodeRabbit entry sets role to semantic-ai-review, repoConfig to .coderabbit.yaml, configurationOwner to repository and statusSource to live ^[8]. For the pattern to work in another repo, each vendor has to read its settings from a file in that repo. The post treats that file as a narrow implementation of repo policy. When a vendor dashboard disagrees with it, the repo wins ^[10].

The harder problem is that the reviewer-policy check runs on untrusted input. "A PR that can modify the checker has already won," the post says ^[11]. The ordinary workflow already runs base-ref copies of the checkers. The step that calls them, though, still sits in files a PR could edit, and the second layer exists so that no later PR can delete or neutralize that step ^[16]. The same write-up calls any pull_request_target workflow that checks out PR code to run checks "a supply-chain incident waiting for a headline" ^[21].

The guard runs on that trigger anyway, and every step handles PR code as data ^[13]. It checks out the trusted base with SHA-pinned actions and `persist-credentials: false`. It fetches the PR head only as a git ref, then verifies that the fetched SHA matches the event SHA ^[14]. That match check means the guard judges only the commit the event named. It then fails if the protected policy files differ between base and head, and it pins the expected hash of the admission-policy checker itself ^[15]. The post does not describe how a legitimate change to those protected files, or to the pinned checker, gets merged past a guard built to fail on exactly that diff.

The same distrust applies to deciding when review is over. Without a definition, the post says, the answer is "when someone gets tired" ^[18]. The CodeAnt loop has five steps: fetch threads, validate each finding, fix or justify, reply citing the commit, then resolve ^[17]. The docs also record which bot posts inline threads and which posts status checks, and they tell agents to inspect the actual output on each PR instead of assuming it ^[19].