Review source files as they stand

Run the staged Jev review over source files you supply and return a structured report, never prose. It asks whether an issue exists in the code as it stands, not whether a change introduced one. The tool reads nothing from disk: it judges exactly the text you pass, so you and the tool are always looking at the same code.

WHEN TO USE: to audit files you did not just change, or to find where to start reading unfamiliar code. To review work in progress or a branch, collect the diff and use review_changes, which sends far less text.

WHAT TO PASS: "files" holds the source files to review, each with its full content. Choose them yourself: the files at the center of the flow you care about, not a whole repository, because every file passes through your context and then goes to the TypeSafe API. Leave out generated code, vendored code, and anything that must not leave the machine. "test_files" holds related test files in the same shape. They are not reviewed; they are the evidence used when judging whether behavior lacks a test, so omitting them makes every test-gap screen fire.

COST: one screening request per 160 lines of each file, three files at a time, then up to five profiling requests and about four requests for each of at most eight followed signals.

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.