How reviews work

The shape of a review

When a pull request opens or updates, gittensory CI runs a review in two layers and reports the result in one place:

1. The gate — a deterministic pass that never asks an AI. It runs a fixed set of rules (duplicates, linked issues, merge-readiness, anti-slop, manifest policy) and each rule is off, advisory, or block.
2. The AI review — a dual-model read of the diff that writes review notes and, when you opt in, lets a high-confidence consensus become a blocker.

Everything those layers find is folded into a single gittensory review comment on the PR, plus an optional Gittensory Gate check run. The review algorithm is open-source; what changes between repos is the configuration you tune. See Review configuration for every option and default.

1. The gate: advisory vs. block

The gate is deterministic — same inputs, same verdict, no model in the loop. Its master switch is gateCheckMode (off / enabled). Once enabled, each dimension is independently set to one of three modes:

• off — the dimension is not evaluated at all.
• advisory — the finding is surfaced in the comment, but it never blocks the merge.
• block — the finding can become a hard Gittensory Gate blocker.

A block outcome is always confirmed-contributor-gated: the mode chooses which checks are active, never who can be blocked. A genuine newcomer can be softened from a block to an advisory when firstTimeContributorGrace is on.

The gate dimensions

These are the deterministic rules the gate runs, with their default modes:

• Duplicate-PR gate (duplicatePrGateMode, default block) — detects duplicate or superseding PRs.
• Linked-issue gate (linkedIssueGateMode, default advisory) — checks the PR references an issue, as strongly as linkedIssuePolicy asks.
• Quality / merge-readiness score gate (qualityGateMode, default advisory) — the PR-quality score; passes at or above qualityGateMinScore.
• Slop gate (slopGateMode, default off) — the deterministic anti-slop signal. advisory surfaces the slop score and warnings; block also hard-blocks at or above slopGateMinScore (engine default band 60).
• Merge-readiness gate (mergeReadinessGateMode, default off) — a composite readiness check.
• Manifest-policy gate (manifestPolicyGateMode, default off) — when block, the repo's declared policy (blocked paths, required linked issue, test expectations) becomes enforceable.

Which deterministic rules even apply is set by the policy pack (gatePack): gittensor (confirmed-contributor-gated, registry-aware) or oss-anti-slop (runs the rules against any author on any repo).

gate:
  enabled: true
  pack: gittensor
  duplicates: block
  linkedIssue: advisory
  readiness:
    mode: advisory
    minScore: 70
  slop:
    mode: block
    minScore: 60
  mergeReadiness: advisory
  manifestPolicy: block
  firstTimeContributorGrace: true

2. The dual-AI review and consensus

AI review is its own dimension (aiReviewMode, default off). It reads the diff and produces review notes — concrete findings tied to the change, not a vague verdict. Two modes:

• advisory — the AI write-up is posted as notes only. It never blocks.
• block — a dual-model high-confidence consensus defect is allowed to become a blocker (confirmed contributors only).

The blocking decision always runs on a pair of free models and only blocks when both models independently agree, with high confidence, on a real defect. Two agreeing models is the bar — there is no single-model block and no tie-breaker third model. That consensus requirement is what keeps a confident-but-wrong single model from blocking a good PR.

Bring your own model (advisory only)

With aiReviewByok: true and a configured provider key, the advisory write-up can use a maintainer's own frontier model (aiReviewProvider / aiReviewModel, e.g. claude-3-5-sonnet-latest). The consensus blocker always stays on the free model pair, so BYOK improves the prose without ever changing who can be blocked.

3. The unified review comment

The result is rendered as one in-place comment on the PR — updated in place on each push rather than stacked — when GITTENSORY_REVIEW_UNIFIED_COMMENT is on for the repo. It has three parts, top to bottom:

• The alert — a one-line headline verdict: whether the gate blocks, what the single most important blocker is, or that the PR is clear. This is the line a reader scans first.
• The signal table — a compact row-per-signal summary: each dimension that ran, its state (pass / advisory / block), and a short reason. This is the at-a-glance map of why the verdict came out the way it did.
• Collapsibles — expandable sections for the detail behind each signal: the AI review notes, the slop warnings, duplicate matches, manifest findings. Folded away by default so the comment stays short, opened when a reader wants the evidence.

Who sees the comment, and how much detail it carries, is a repo setting: commentMode chooses the audience (off / detected_contributors_only / all_prs), and publicSignalLevel (minimal / standard) controls how much of the signal detail is published. Private review context (maintainerNotes) is never published to a public surface.

4. The signals behind a verdict

Each row in the signal table comes from a named finding. The common ones you will see:

• secret_leak — the safety scan (GITTENSORY_REVIEW_SAFETY) found a leaked secret in the diff. The same scan also defangs untrusted PR text before the AI reviewer reads it.
• manifest_blocked_path — the PR touches a path listed in the repo's blockedPaths. Enforceable when manifestPolicy is block.
• manifest_missing_tests — code changed but the expected test paths (testExpectations) did not.
• Slop score + warnings — the deterministic anti-slop signal. With slopAiAdvisory: true, a free advisory-only ai_slop_advisory finding is added too — it never feeds the score or the gate.
• Duplicate match — the other PR this one duplicates or supersedes.
• AI review notes — the dual-model findings, and (in block mode) any consensus defect.

The check run can carry the same signals at adjustable depth: checkRunMode (off / enabled) publishes the Gittensory Gate check, and checkRunDetailLevel (minimal / standard / deep) sets how much the check summary spells out.

Putting it together

A pull request flows through the deterministic gate, then the dual-AI review, and the union of both is rendered as one alert + signal table + collapsibles comment. The gate decides can this merge with fixed rules you can read; the AI review adds judgment as advisory notes, escalating to a blocker only on two-model consensus; and the comment is the single, sanitized place a contributor reads the whole verdict. Tune every mode, threshold, and surface in Review configuration.