--- name: review-jev-risk model_tier: light description: | Use when: an ADDITIONAL, machine-scored RISK MAP is wanted over every changed hunk — never replacing any other reviewer. Dispatched by review-orchestrator in Wave B, via the CLI (`keryx review jev-risk`), when `review.jev.risk: true` in .metaproject/tasks.config.json and a Jev/OpenRouter credential is resolvable. It is not an LLM sub-agent: there is nothing to dispatch through a platform-native agent mechanism, and no prose is generated by a model — Jev only answers one `noul` probability per (hunk, risk dimension) pair; keryx writes every word of every finding. NOT for: judgement calls a risk dimension does not state (style, architecture beyond risk-flagging — those stay with the reviewers that already cover them), and not a substitute for a human reviewer reading the ranked map it produces. triggers: - "jev risk" - "risk map" - "review --jev-risk" metadata: author: "MrCipherSmith" version: "1.0.0" category: "review" compatible_harnesses: "cursor,codex,zed,opencode,claude" engine: "jev" origin: "authored" license: "MIT" --- # Review — Jev Risk (deterministic risk map of the diff) An ADDITIONAL orchestrator reviewer, flow 332. It is a **keryx program**, not an LLM sub-agent: `review-orchestrator` never dispatches a platform-native agent for it, it runs `keryx review jev-risk` and reads the `--json` output. Every finding is composed by keryx; Jev ("System One" on OpenRouter) supplies only five `noul` probabilities per hunk — one per risk dimension — never prose. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs. --- ## What it does 1. Takes every changed hunk from `keryx review scope`/`buildReviewScope` (mechanical bulk already dropped). 2. Computes deterministic facts FIRST, per hunk: a path class (auth/ permissions, crypto, migrations, schema, public API, config, concurrency primitives, IO), the exported symbols it touches, its changed-line count, and whether a test file elsewhere in the diff touches the same module. 3. Asks Jev **one `noul` per risk dimension** per hunk — security-sensitive, data/migration, public-API/contract change, concurrency, error-handling — batched under the vendor's 64k token budget, capped at `--max-calls` (default 150, counted as hunk x dimension pairs), with every drop reported. 4. Ranks hunks by combined risk (the MAX across its five dimensions — one high-risk dimension is enough to draw attention) so a human reviewer knows where to look first. 5. Emits a finding ONLY for a hunk above threshold (default 0.7) AND with no test touched nearby in the same diff (a fact) — severity capped at `info`/`minor`, never higher: this flags attention, it does not assert a defect. 6. Additionally emits a **routing hint**: hunks above threshold with a security or concurrency dimension are listed with a suggested reviewer (`review-security-code`/`review-highload`) for the orchestrator to consider dispatching — see "Orchestrator integration" below. --- ## Input Contract Not dispatched with a prompt — invoked as a CLI command: ```text keryx review jev-risk (--diff | --pr | --scope ) [--max-calls ] [--threshold <0..1>] [--repo ] [--model ] [--fixtures ] [--json] ``` `review-orchestrator` passes `--scope ` — the same `keryx review scope --json` file every other reviewer's dispatch already reads — so this reviewer checks exactly the same hunks as everyone else in the round. --- ## Opt-in and privacy Refuses before any read or network call unless `.metaproject/tasks.config.json` declares: ```json { "review": { "jev": { "risk": true } } } ``` Every hunk sent to Jev is redacted first through `src/security/service.ts` — the same floor `review conform`/`review ci-triage`/`review jev-rules` already apply. No cache or output file stores a credential. --- ## Output Contract Emits a `REVIEW_RESULT`-shaped object matching `.metaproject/skills/gdskills/review/review-orchestrator/reviewer-finding.schema.json` — `status`, `reviewer: "review-jev-risk"`, `summary`, `findings`, `stats` — under `--json`, plus two orchestrator-facing extras: `ranked` (every scored hunk, highest risk first) and `routingHints` (see above). Its findings merge into the consolidated array exactly like any other reviewer's: same Quality Gate, same dedup, same Wave C verification. --- ## Orchestrator integration - `keryx review reviewers --json` lists it under `bundled` with `"engine": "jev"`. - `review-orchestrator` dispatches it in **Wave B**, alongside the domain/ convention reviewers and flow 330's `review-jev-rules`, when the opt-in is on and a Jev/OpenRouter credential resolves. When either is false it is **skipped with the stated reason**, recorded in `Skipped reviewers` — never silently absent. - It is **ADDITIONAL**: it never replaces `review-security-code`, `review-highload`, or any other pass. - **Routing hint**: read `routingHints` from its `--json` output. Each entry names a hunk location, the dimension that crossed threshold (`security`/`concurrency`) and a `suggestedReviewer` (`review-security-code`/`review-highload`). When that reviewer was not already selected for the round, dispatch it too — the hint is advisory, not a hard requirement, and the orchestrator's own path-based selection always takes precedence when it already covers the same hunk. --- ### Shared laws (every reviewer) 1. **A claim of runtime harm with no reproducible path is `info`.** If you cannot name the input, call, or condition that reaches the code, you have an observation, not a finding. Report it as `info` and say what would settle it. 2. **Never flag the theoretical.** The path you describe must exist in the code under review. Do not report a safe API because it could be misused, or a pattern because it is often wrong elsewhere. 3. **One finding per class, not one per occurrence.** When the same shape appears at several sites, report it once and list every site. Ten findings that are one finding hide the other nine problems. 4. **A deliberate choice is not a defect until its reason is read and shown wrong.** An explicit override, suppression or exemption, a comment or commit giving a reason, or a sibling doing the same is a decision: read its reason (the comment, `git log -L` or `git blame`, the sibling) before you report it, and report it only when you can show that reason wrong. A project rule is checked against accepted platform practice and its known exceptions before a deviation from it is reported. This reviewer satisfies all three by construction: `evidence` always names the hunk location, quotes the changed line, and states every dimension's probability (never an unreproducible claim); a finding is synthesized only against the hunk actually scored, never a hypothetical pattern; and each hunk is a distinct site with its own probabilities, so there is no repeated class across sites for this reviewer to collapse — the routing hint follows the same discipline, naming the exact hunk and dimension that crossed threshold rather than a general warning. --- ## Red Flags | Rationalization | Why it is wrong | |---|---| | "Jev said 0.9, so this hunk is definitely dangerous" | A `noul` score is a probability across one dimension, not a verdict — severity stays capped at `info`/`minor` precisely because Jev alone is not authoritative | | "No nearby test means nobody tested this at all" | `hasNearbyTest` requires the nearby test's OWN diff text to mention a touched symbol or import the hunk's module (`testHunkEvidence`), tightened after a live-check false negative — still a regex heuristic, not proof of coverage through an indirection it cannot see | | "This hunk touches a .md file, so 'no nearby test' is a meaningful finding" | Docs (`.md`/`.txt`) hunks are excluded before scoring (`isNonCodeHunk`) after a live check where prose scored `public-api` — this cannot happen; `selection.hunksNotCode` reports the count | | "No findings means the diff is low risk" | `--max-calls` bounds how many hunks are scored; a capped run reports `selection.hunksSkipped` for exactly this reason — read the selection stats before treating silence as clean | --- ## Verification Before trusting a run's findings: 1. Read `selection.hunksSkipped` in the `--json` output — a capped run covered fewer than "every retained hunk" and the report should say so. 2. Spot-check a handful of `ranked` entries against the actual hunk: does the file/line range and the top dimension make sense for what actually changed there? Docs (`.md`/`.txt`) hunks never reach `ranked` at all — `selection.hunksNotCode` should account for every one of them in the diff. 3. Confirm every finding carries `reviewer: "review-jev-risk"` and a `dedupe_key` — both are required for the orchestrator's Quality Gate and Wave C verification to route it correctly. --- ## Scope Boundaries | Concern | This skill | Use instead | |---------|------------|-------------| | A ranked risk map of the diff's hunks | YES | — | | An actual security/concurrency finding | NO (routing hint only) | `review-security-code` / `review-highload` | | Judging whether a reported finding is real | NO | `review-verifier` | | Which user scenarios changed | NO | `review-jev-scenarios` |