Review a diff

Run the staged Jev review over a diff you supply and return a structured report, never prose. The tool reads nothing from disk and runs no git: it judges exactly the patches you pass, so you and the tool are always looking at the same change.

WHEN TO USE: before committing, before opening or merging a pull request, or when asked to review a branch, once you have collected the diff. For a single judgment about one patch, use judge. To check a finding you wrote yourself, use verify_claim.

WHAT TO PASS: "files" holds one entry per changed source file, each with its own unified diff. Decide the scope yourself first (which base, whether uncommitted and untracked work is included) and leave out generated files, lock files, and anything that must not leave the machine: every patch is sent to the TypeSafe API. "test_files" holds the changed test files in the same shape. They are not reviewed; they are the evidence used when judging whether changed behavior lacks a test, so omitting them makes every test-gap screen fire.

COST: one request per file for screening (more for a patch over about 40,000 characters, which is split by hunk), then up to five profiling requests and about four requests for each of at most eight followed signals. Three files take a few seconds; a hundred take minutes.

HOW TO READ THE RESULT:

• "findings" is sorted by descending "severity" (0 to config.severity_max). Each one names a "file", a "line" (the first line of the evidence region, not the exact defect line), a "dimension" (correctness, security, reliability, compatibility, testGap), and a "mechanism". As a reference point, the jev-review workflow this pipeline comes from requests changes at severity 2 or above and comments below that. What to do with a finding is your decision.

• A finding is a lead, not a verdict. Open the file at the cited line and confirm it yourself before you repeat it. Pass the confirmed claim and the code to verify_claim if you want a second check.

• Each finding rests on three judgments: where the evidence is, which mechanism it shows, and how severe it is. "certainty" (high/medium/low) applies the thresholds to the least confident of the three, and "weakest_judgment" names it. A weak "location" often means the line is wrong even when the concern is real. "needs_escalation" lists the findings with low certainty: do not treat those as settled.

• "unresolved_signals" lists every screening signal at or above config.screen_threshold that produced no finding. "no_evidence_located" means it was followed, but no region was selected with enough confidence or the mechanism check found no concrete issue. "not_followed" means it fell past the config.max_follow_ups cap and was never examined. "request_failed" means the follow-up request itself failed. None of them means the file is fine: a screen fired and nothing confirmed or refuted it, so those files still need your own read, strongest probability first.

• "screening" holds, per file, the probability of every dimension that is not a clear no (at or above the lower bound of the noul band). A probability near 0.5 means the screen could not tell, not that the file is half broken. "quiet_files" counts the files where every dimension was a clear no; they are left out to keep the report small.

• "profiles" covers the config.max_profiles files with the strongest signals: a category and a "review_priority" from 0 (routine) to 3 (specialist review), with a "certainty" from the less confident of the two.

• "failed_requests" lists every request that still failed after retries, with its "file" and "stage". A file that failed at the "screen" stage was not judged at all: it is missing from "screening", is not counted in "quiet_files" or "workflow.screened_files", and needs either a second call with just that file or your own read. A "profile" failure only costs that file its profile. When every file fails to screen, the tool returns an error instead of a report.

• "owner" is set only for findings at severity 1.5 or above.

• An empty "findings" array does not mean the code is free of defects. Check "unresolved_signals" first. Jev reads only the text it is sent and does not compile, run tests, or follow calls into other files.