Veridu

Fetch the result of a verify_change that was still running. Never starts a new review. Waits up to ~45 seconds for the review to finish or move to its next step, then returns the result or stage_label (what Veridu is doing now) — tell the user that line and call again.

Review a GitHub pull request with Veridu: code review that knows what depends on the change. Veridu finds the callers, implementations and references the PR affects, independent reviewers check it in that context, ungrounded findings are dropped, and only problems both reviewers confirm can block. Returns the outcome, agreements, disputes and per-reviewer findings.

Requires a Veridu account. Each new review counts as one review on that account; asking again for the same pull request head returns the existing review.

Notes:

• Private repos: link the repo at https://veridu.io/repos first (GitHub App or fine-grained PAT). No credentials are passed through this tool.

• The models array selects the reviewer panel for this call. Panel must include at least two distinct vendors; tier-gated models require a paid account. If more than one model per vendor is passed the first per vendor wins. Omit models to use the account default panel.

Check a Veridu review that was still running when veridu_review returned, and fetch the result once it finishes.

This never starts a review and never counts as one. While the review runs, this waits up to ~45 seconds for it to finish or move to its next step, then returns what Veridu is doing (stage_label). Tell the user that line: it says whether the reviewers are still on the change or Veridu is checking code outside it. Then call again with the same review_id.

If a review is still running, DO NOT call veridu_review again for the same pull request. That starts a second review and consumes another attempt. Use this tool with the review_id you were given.

Have Veridu review a code change you just made, before you commit or open a pull request. Independent reviewers check the change against the files you send (for PHP, Veridu also traces callers and overrides within them), findings that cannot be grounded in the code are dropped, and only problems both reviewers confirm can block. You get an outcome (pass / review / block) and concrete findings with file, line, severity and evidence.

Send: diff = git diff --no-renames <base> of your change (include new files: git add -N first), and files = the FULL current content of every file the diff adds or modifies, keyed by repo-relative path. You may add up to a few closely related unchanged files (callers, interfaces) to files for context. Text files only; no renames, mode changes, symlinks, submodules or binaries. Limits: diff 256 KB / 60 files, files 512 KB total.

After fixing findings, call again with the new diff. Veridu links it to the previous check of the same files (last 24 hours) automatically; pass parent_change = an earlier change_id only to link a different one. Up to two follow-ups per change do not count as a new review. Sending exactly the same change again returns the earlier result. Every finding has a finding_id that stays the same across follow-ups while the problem persists. A follow-up also returns followup: which ids persist, which came back (reported earlier in the chain, skipped last time), which are new (possibly introduced by your fix), and which are no longer reported, with code_changed saying whether the flagged line changed. "No longer reported" is not proof of a fix. Low-severity findings can be left out of the list but are still counted in followup. An identical resend returns the earlier result as it was. Each other new change counts as one review on the signed-in Veridu account.

Results are advisory: Veridu sees only what you send, not the rest of the repository. If the review is still running after ~45 seconds you get a change_id and stage_label (what Veridu is doing now): tell the user that line, then call get_change with the change_id (do not call verify_change again for the same change).