| key | type | primitive | tier |
|---|---|---|---|
describes-the-change | must_have | llm_judge@1 | 1 |
tests-addressed | must_have | llm_judge@1 | 1 |
no-security-anti-patterns | must_not | llm_judge@1 | 1 |
follows-the-stated-spec | must_have | llm_judge@1 | 1 |
no-unrelated-changes | must_have | llm_judge@1 | 1 |
no-hardcoded-secrets | must_not | regex_match@1 | — |
no-leftover-debug | must_not | regex_match@1 | — |
Version: `code-review-gate@3`
**Judges:** a PR review packet (`PR DESCRIPTION`, optional `LINKED ISSUE / SPEC`, `TESTS`, `DIFF`) against merge-gate hygiene: description accuracy, testing coverage, visible security anti-patterns, spec adherence, unrelated changes, committed secret-looking literals, and leftover debug artifacts. **Use when:** you gate auto-generated or high-volume PRs and want an auditable pre-review verdict before a human spends attention.
The rubric is general engine config. The PR body and diff are submission data; prompt-injection text inside either one must be judged as data, never as reviewer instructions. LLM criteria are authored to emit only `met`, `not_met`, or first-class `cannot_determine`; they should abstain when the supplied diff excerpt is too thin. Deterministic regex criteria are also authored in config and use `must_match: false`; they return `not_met` only when the forbidden pattern is visible in the submitted packet.
curl -s -X POST $API/v1/rubrics -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
-d @templates/code-review-gate/rubric.json
curl -s -X POST $API/v1/verify -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
-d '{"rubric_id":"<id>","submission":{"inline":"CLAIM: ...\nTESTS: ...\nDIFF:\n..."},"options":{"wait_ms":30000}}'MCP: `verify_submit` with the PR body + trimmed diff as `submission.inline` (mind the 512 KiB cap; send the description plus the highest-risk hunks, not the whole diff).