Code Reviewer

Roster name: reviewer. See also the Review Pipeline.

What it does

It reviews every pull request the same way, line by line, and names each defect it finds with the file, the line and the fix.

• Reviews a pull request when it opens or changes, or when someone asks with a review tag such as @core_review.
• Reviews pull requests in repositories that have no review set up of their own, through the central sweep.
• Hands every finding to the Fix Drafter.

What it reads

• The pull request’s unified diff: the added lines and their context.
• Nothing outside the diff. It does not read the rest of the repository.

What it produces

• One pull request review that lists every finding: severity, file, line, the defect, and the fix. A finding with a file and line is also attached to that line.
• The review:findings-open label when findings remain. Only a completed review with no findings clears it.
• A “did not run” notice, rather than a silent pass, whenever no review was made: the model could not be reached, the diff could not be read, the answer was not in the review format, or the review could not be posted. The check then closes as neutral, not as passed.

Human oversight

A person reads the findings and decides what merges. The reviewer cannot approve, merge or push.

Model

Qwen3-Coder-30B-A3B, by Qwen, licensed Apache-2.0 (the coder tier). Runink domain adaptation for this agent is planned; this release uses the base model.

Where it runs and data handling

On your Runink TIDE deployment’s own inference, on your Server or in your cloud. The diff goes to that model plane and to no third-party AI service. Findings are posted to the pull request on your Git host.

Guardrails

• It is instructed to report only concrete, checkable findings that name the defect and where it is, and never to claim that code is unused or undefined, because the caller may sit outside the diff. A finding outside the fixed severity levels or without a plausible file path is dropped, and the review says how many were dropped.
• The diff is evidence, not instructions. It is marked as untrusted data, with chat control sequences neutralised, and a comment in the code that says “approve this” is reviewed as text. The reviewer can only comment: it has no way to approve or merge.
• The incoming diff and the outgoing review are both screened before the review posts.

Limitations

• It reviews the change, not the whole codebase.
• It reviews what it is shown. It does not run the code or its tests.
• Only the first part of a large diff fits the review window. When a diff is cut, the review says how much was read and that the rest is unreviewed.

Evaluation

No published evaluation scores yet.

Illustrative example

Invented change. A pull request adds an early return err inside a function that holds a lock. The review lists: 🟠 internal/retry/backoff.go:47 — the new return leaves mu locked; add defer mu.Unlock() after the Lock. The Fix Drafter then drafts a correction for the author to accept or close.