Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/paramveer-cyber/Deployaar/llms.txt

Use this file to discover all available pages before exploring further.

AI PR review runs automatically every time the coding agent opens or synchronizes a pull request on a Deployaar-managed branch. The review is grounded entirely in the original PRD — the reviewer is explicitly instructed never to invent requirements that are not written in the spec. This keeps the review fair, predictable, and focused on what was actually agreed upon rather than on theoretical best practices.
The review system applies a consistency principle: if a piece of code was present and not flagged in a previous review pass, it will not be flagged in a subsequent pass unless it was directly modified in the new diff. Only what changed is reviewed. This prevents review noise from accumulating across repeated agent runs on the same feature.

​
Review Depths

Each project’s linked repository has a configured reviewDepth. The depth controls how many hops of imported-file context the reviewer fetches before forming its verdict. The valid values are defined in the reviewDepthEnum (packages/database/models/enums.ts) and the ReviewDepth type (packages/services/github/review-context.ts).
DepthContext hopsScope
shallow0Diff only. Catches obvious correctness and security issues. Fastest turnaround.
depth_11Diff plus files directly imported by the changed files.
depth_22Diff plus two hops of import context. Balances thoroughness with speed.
depth_33Full three-hop cross-file analysis. Checks for side effects outside the immediate diff. Slowest but most thorough.
Use depth_3 for complex, cross-cutting features that touch shared utilities, authentication middleware, database schemas, or any code with broad downstream consumers. For isolated UI changes or self-contained API additions, depth_1 or depth_2 is usually sufficient.

​
Issue Severity

Every issue the reviewer raises is assigned one of four severity levels. Severity directly determines whether an issue is blocking — only critical and major block merging.
SeverityDescriptionBlocking?
criticalThe implementation is broken or introduces a concretely exploitable security hole. Reserved for clear, demonstrable problems only.✅ Always
majorA significant functional gap against an explicit, clearly stated PRD requirement. Must be something the PRD unambiguously requires that is absent or wrong.✅ Always
minorA small quality gap that does not prevent the feature from working as specified.❌ Never
suggestionAnything that would be nice but is not required by the PRD.❌ Never
The isBlocking flag is derived mechanically at review time: 
function deriveIsBlocking(severity: "critical" | "major" | "minor" | "suggestion"): boolean {
  return severity === "critical" || severity === "major";
}

​
Issue Categories

Each issue is also assigned a category that describes the nature of the problem. Categories are informational and do not affect the verdict.
CategoryWhen Used
correctnessLogic errors that produce demonstrably incorrect behaviour
securityConcrete, exploitable vulnerabilities introduced by this PR
performanceMeasurable performance regressions directly caused by the change
styleCode style issues — never blocking, at most a suggestion
acceptance_criteriaA stated acceptance criterion from the PRD is not satisfied
edge_caseAn edge case explicitly listed in the PRD’s edge cases section is not handled
otherCross-cutting issues that don’t fit the above categories

​
Review Verdicts

After all issues are evaluated, the review receives one of two verdicts:
VerdictConditionEffect on Feature Request
passedZero blocking issues (zero critical or major issues)Feature request status → in_review
needs_workOne or more blocking issuesFeature request status → fix_needed
const blockingIssueCount = issuesToInsert.filter((i) => i.isBlocking).length;
const verdict = blockingIssueCount > 0 ? "needs_work" : "passed";
const nextFeatureRequestStatus = blockingIssueCount > 0 ? "fix_needed" : "in_review";
When the verdict is needs_work, the feature request is surfaced in the dashboard’s “needs action” feed. A new agent run can be triggered to address the blocking issues, which will produce a new PR update and re-trigger the review workflow.

​
Review Delta

When two or more completed reviews exist for the same feature request, Deployaar computes a delta between the two most recent completed attempts. The delta reveals whether the code is improving between agent runs. 
type ReviewDelta = {
  previousAttemptNumber: number;
  currentAttemptNumber: number;
  previousBlockingCount: number;
  currentBlockingCount: number;
  resolved: number;    // blocking issues that went away
  remaining: number;   // blocking issues still present
  isImproving: boolean; // true if currentBlockingCount < previousBlockingCount
};
The delta is surfaced in the review UI. If isImproving is false across multiple attempts, it may indicate that the feature request’s PRD needs to be edited or the task breakdown needs revision before triggering another agent run.

​
Resolving Issues

Individual review issues can be manually marked as resolved by any team member via the review UI. Resolving an issue stamps it with resolvedByUserId and resolvedAt.
Marking an issue resolved is a human annotation — it does not re-run the AI or recalculate the blockingIssueCount or verdict fields on the review record. A resolved issue is still counted in blockingIssueCount. The only way to obtain a passed verdict is for the AI reviewer to run a fresh pass and find zero blocking issues on its own.
To obtain a new passed verdict:
  1. Trigger a new agent run to address the blocking issues.
  2. The agent pushes updated commits, synchronizing the PR.
  3. The pull_request webhook fires with action synchronize.
  4. The onPullRequestReceived Inngest function runs a fresh review.
  5. If the new review finds zero blocking issues, the verdict becomes passed.

​
Review Model

PR review uses resolveLanguageModelForUser to select the AI model, which respects the AI provider configured in user settings. The pull-request-review service also defines a resolveReviewModel helper that returns Anthropic claude-sonnet-4-6 directly, but the active code path calls resolveLanguageModelForUser. Ensure ANTHROPIC_API_KEY is set if you configure Anthropic as your AI provider — the review will fail to produce a verdict if the configured provider’s API key is missing.

Build docs developers (and LLMs) love

Get started for freeTalk to us