@mrciphersmith/keryx 0.3.1 → 0.3.3

package/src/gdskills/bundled/skills/review/review-jev-risk/SKILL.md

@@ -0,0 +1,190 @@
+---
+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.
+
+---
+
+## 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 <ref> | --pr <n> | --scope <scope.json>)
+                      [--max-calls <n>] [--threshold <0..1>]
+                      [--repo <owner/repo>] [--model <jev-1.13|jev-latest>]
+                      [--fixtures <dir>] [--json]
+```
+
+`review-orchestrator` passes `--scope <scope.json>` — 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.
+
+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` |

package/src/gdskills/bundled/skills/review/review-jev-scenarios/SKILL.md

@@ -0,0 +1,187 @@
+---
+name: review-jev-scenarios
+model_tier: light
+description: |
+  Use when: an ADDITIONAL, machine-scored FUNCTIONAL review is wanted — which user
+  scenarios a PR likely changes — never replacing any other reviewer. Dispatched by
+  review-orchestrator in Wave B, via the CLI (`keryx review jev-scenarios`), when
+  `review.jev.scenarios: 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` "does this change alter this scenario's behaviour?" per
+  scenario whose linked code the diff touches; keryx writes every word of every finding.
+  NOT for: discovering scenarios nobody documented (it reads existing gdwiki
+  user-scenario pages, PRD requirement/scenario sections, and README/docs "how to"
+  sections — a scenario that exists only in someone's head is invisible to it), and not
+  a substitute for manually walking the checklist it produces.
+triggers:
+  - "jev scenarios"
+  - "functional review"
+  - "review --jev-scenarios"
+metadata:
+  author: "MrCipherSmith"
+  version: "1.0.0"
+  category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode,claude"
+  engine: "jev"
+  origin: "authored"
+license: "MIT"
+---
+
+# Review — Jev Scenarios (deterministic functional review)
+
+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-scenarios` and reads the `--json`
+output. Every finding is composed by keryx; Jev ("System One" on OpenRouter)
+supplies only one `noul` probability per scenario — never prose.
+
+---
+
+## What it does
+
+1. Gathers user scenarios deterministically from three sources: gdwiki pages
+   of type `user-scenario` (`.metaproject/wiki/user-scenarios/**`), PRD
+   requirement/scenario sections (`docs/requirements/**`, any heading
+   matching scenario/requirement/user story/use case), and README/docs "how
+   to" sections (`README.md`, `docs/docs/**`).
+2. Extracts each scenario's own links to code — markdown links and inline
+   code-span file references, the same convention `src/wiki/backlinks.ts`
+   already established for the wiki's own code edges.
+3. Computes, per scenario, which of its linked files the diff actually
+   touches (a fact) and whether a test in the diff covers a touched link (a
+   fact).
+4. For every scenario with at least one touched link, asks Jev **one
+   `noul`**: "does this change alter this scenario's behaviour?" — batched
+   under the vendor's 64k token budget, capped at `--max-calls` (default
+   150), with every drop reported.
+5. Emits a **manual-check list**: every scenario at/above threshold (default
+   0.5), ranked, each with its touched links as evidence — for a human to
+   walk before merge.
+6. Emits a `minor` finding for each likely-affected scenario with **no test
+   in the diff covering it** (a fact) — severity fixed at `minor`: this
+   flags attention over a functional scenario, it does not assert a defect.
+
+---
+
+## Input Contract
+
+Not dispatched with a prompt — invoked as a CLI command:
+
+```text
+keryx review jev-scenarios (--diff <ref> | --pr <n> | --scope <scope.json>)
+                           [--max-calls <n>] [--threshold <0..1>]
+                           [--repo <owner/repo>] [--model <jev-1.13|jev-latest>]
+                           [--fixtures <dir>] [--json]
+```
+
+`review-orchestrator` passes `--scope <scope.json>` — the same file every
+other reviewer's dispatch already reads — so this reviewer's "touched by this
+diff" facts agree with the round's own scope.
+
+---
+
+## Opt-in and privacy
+
+Refuses before any read or network call unless `.metaproject/tasks.config.json`
+declares:
+
+```json
+{ "review": { "jev": { "scenarios": true } } }
+```
+
+Every scenario's text sent to Jev is redacted first through
+`src/security/service.ts` — the same floor every other Jev-backed mode in
+this repository already applies. 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-scenarios"`, `summary`, `findings`,
+`stats` — under `--json`, plus one orchestrator-facing extra: `checklist`
+(the ranked manual-check list described 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`/flow 332's
+  `review-jev-risk`, 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 any domain reviewer's own read of
+  the diff.
+- The consolidated report's "Manual verification" section (or equivalent)
+  should surface `checklist` verbatim alongside any findings — a scenario
+  that scored below the finding threshold but above the checklist threshold
+  is still worth a human glance even though it produced no finding.
+
+---
+
+### 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.
+
+This reviewer satisfies all three by construction: severity is fixed at
+`minor` — never higher — and `evidence` always names the scenario's linked
+code and the exact files this diff touched (never an unreproducible claim);
+a scenario is only asked about when a real link of its own is in the diff,
+never a hypothetical connection; and each scenario is its own class with its
+own `dedupe_key`, so there is nothing to collapse across sites.
+
+---
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "Jev said 0.9, so this scenario is definitely broken" | A `noul` score is a probability that behaviour changed, not a verdict — it only ever produces a `minor` finding, and only when paired with the separate "no covering test" fact |
+| "This PRD scenario links to a huge, frequently-touched file, so the match is meaningless" | Down-weighted after a live check (`SCENARIO_LINK_FANOUT_THRESHOLD`): a link to a file referenced by more scenarios than that only still counts as touched when the scenario's own text names one of the diff's touched exported symbols — read the scenario's own text before assuming a surviving entry is still spurious |
+| "No entries in checklist means nothing changed functionally" | Discovery only covers three sources (gdwiki `user-scenario` pages, `docs/requirements/**`, README/docs "how to" sections); a scenario that exists only in someone's head, or in a doc outside those three locations, is invisible to this reviewer |
+| "checklist is empty so scenarioSources must be empty too" | `scenarioSources` lists every discovered scenario; `checklist` lists only those with a touched link at/above threshold — a project can have hundreds of scenarios discovered and zero touched by a given diff |
+
+---
+
+## Verification
+
+Before trusting a run's findings:
+
+1. Read `selection.notApplicable`/`selection.scenariosSkipped` in the
+   `--json` output — a scenario with no touched link was never asked, and a
+   capped run may have skipped some that were.
+2. Spot-check a `checklist` entry against the scenario's own source
+   (`id` names the file, and for a PRD/README section, the heading): does
+   the touched link actually sit inside the part of the diff that matters
+   for that scenario, or did a large, widely-linked file produce a spurious
+   match?
+3. Confirm every finding carries `reviewer: "review-jev-scenarios"` 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 |
+|---------|------------|-------------|
+| Which documented user scenarios a diff likely changes | YES | — |
+| Discovering an undocumented scenario | NO | a human, or write the scenario down first |
+| Judging whether a reported finding is real | NO | `review-verifier` |
+| A risk map of the diff's hunks | NO | `review-jev-risk` |

package/src/gdskills/bundled/skills/review/review-orchestrator/SKILL.detail.md

@@ -46,22 +46,46 @@ review: it is a fact about the review, not about the diff.
 
 ## CLI-engine reviewers — dispatched as a command, not a sub-agent
 
-`review-jev-rules` (flow 330) is an ADDITIONAL reviewer, never replacing any
-other, and its dispatch mechanism differs from every reviewer named in
+`review-jev-rules` (flow 330), `review-jev-risk` and `review-jev-scenarios`
+(both flow 332), `review-jev-docs` and `review-jev-comments` (flow 333), and
+`review-jev-contract` (flow 335) are ADDITIONAL reviewers, never replacing
+any other, and their dispatch mechanism differs from every reviewer named in
 SKILL.md's Routing Table: there is no platform-native agent to invoke,
-because it is a deterministic **keryx program**. Run it with `keryx review
-jev-rules --scope <scope.json> --json` — the SAME `scope.json` every other
-Wave A/B reviewer's dispatch already reads, so it checks exactly the same
-hunks. Read its `--json` output as a `REVIEW_RESULT` and merge its `findings`
-into the consolidated array exactly like a sub-agent reviewer's: same
-Sub-Agent Report Quality Gate, same dedup, same Wave C verification.
-
-Gate it BEFORE running the command, not after: skip it — recorded in `Skipped
-reviewers` with the reason, never silently absent — when `review.jev.rules`
-is not `true` in `.metaproject/tasks.config.json`, or when no Jev/OpenRouter
-credential is resolvable. Either gate failing means `keryx review jev-rules`
-itself would refuse before any read or network call, so checking first saves
-a doomed dispatch.
+because each is a deterministic **keryx program**. Run them with `keryx
+review jev-rules --scope <scope.json> --json`, `keryx review jev-risk
+--scope <scope.json> --json`, and `keryx review jev-scenarios --scope
+<scope.json> --json` — the SAME `scope.json` every other Wave A/B reviewer's
+dispatch already reads, so each checks exactly the same hunks.
+`review-jev-docs` and `review-jev-comments` take a diff/PR target instead:
+`keryx review jev-docs (--diff <ref>|--pr <n>) --json` and `keryx review
+jev-comments --pr <n> --repo <owner/repo> --json`. `review-jev-contract`
+also takes a diff/PR target, plus an optional linked flow: `keryx review
+jev-contract (--diff <ref>|--pr <n>) [--flow <id>] --json` — a `--pr` target
+checks the description's own claims; `--flow <id>` additionally checks that
+flow's frozen acceptance criteria (reusing flow 328's `check-ac.ts`, see its
+own SKILL.md). Read each `--json` output as a `REVIEW_RESULT` and merge its
+`findings` into the consolidated array exactly like a sub-agent reviewer's:
+same Sub-Agent Report Quality Gate, same dedup, same Wave C verification.
+`review-jev-risk` additionally emits `ranked` and `routingHints`;
+`review-jev-scenarios` additionally emits `checklist`; `review-jev-contract`
+additionally emits `claims`, `budget`, and (when `--flow` was given)
+`acCheck` — see each reviewer's own SKILL.md for what to do with its extra.
+
+Gate each BEFORE running its command, not after: skip it — recorded in
+`Skipped reviewers` with the reason, never silently absent — when its own
+opt-in (`review.jev.rules` / `review.jev.risk` / `review.jev.scenarios` /
+`review.jev.docs` / `review.jev.comments` / `review.jev.contract`) is not
+`true` in `.metaproject/tasks.config.json`, or when no Jev/OpenRouter
+credential is resolvable. Either gate failing means the command itself would
+refuse before any read or network call, so checking first saves a doomed
+dispatch. The six opt-ins are independent: any subset may be on.
+`review-jev-comments` additionally needs a comment ledger to already exist
+(`keryx review comments collect` run first) — it refuses, before any read,
+when there is none. When `review.jev.contract` is on, dispatch
+`review-jev-contract` with `--pr` (never `--diff`, which has no description
+to check) and let its `findings` cover the description-vs-diff claim, in
+place of the by-eye Stage 1 judgement described in SKILL.md's "This gate owns
+the description-vs-diff comparison" — see that section's own note.
 
 `keryx review reviewers --json` marks a CLI-engine reviewer with
 `"engine": "jev"` on its `bundled` entry — the field's presence, not its
@@ -69,3 +93,52 @@ absence, is what distinguishes it from the default (an LLM sub-agent
 dispatch). A future engine-backed reviewer follows the same pattern: gate on
 its own opt-in and reachability, dispatch as a command, merge its `--json`
 output the same way.
+
+## `jev-triage` — advisory annotations, not a reviewer (Step 9b)
+
+`review-jev-triage` (flow 340) is a DIFFERENT shape from every CLI-engine
+reviewer above: it never produces a `findings` array of its own, and it is
+never merged into the consolidated array. It runs AFTER the Sub-Agent Report
+Quality Gate has already validated/merged/deduplicated the round's findings
+(Step 9) and BEFORE Wave C verification (Step 10) — Step 9b in the Workflow
+block — annotating the findings that already exist. It is advisory and
+annotate-only by construction: nothing it returns drops or demotes a finding,
+and no downstream step is permitted to treat its output as anything but a
+hint.
+
+Run it once per round, over the round's own consolidated findings:
+
+```bash
+keryx review jev-triage --report <this round's review package dir> --json
+```
+
+Gate it the same way as every other CLI-engine reviewer: skip it — recorded
+in `Skipped reviewers` with the reason — when `review.jev.triage` is not
+`true` in `.metaproject/tasks.config.json`, or when no Jev/OpenRouter
+credential is resolvable. Either gate failing means the command itself would
+refuse before any read or network call.
+
+Its `--json` output is `{status, reviewer: "review-jev-triage", summary,
+annotations, budget, tokens}` — never a `REVIEW_RESULT` merged into the
+findings array. `annotations` carries three tracks, each read and used
+differently in the report:
+
+| Track | Shape | What to do with it |
+|---|---|---|
+| `severity_check` | `{id, p, flagged}` per blocker/major finding — `flagged` means `p < 0.4` | Show `flagged` findings as a soft note next to their existing severity ("Jev's own trigger+outcome check scored this low"). Never change the finding's `severity` field from this alone. |
+| `merge_candidates` | `{id, a, b, reason, p}` per candidate pair | A high `p` is a suggestion to a human that `a` and `b` may be the same defect — surface it in the report as a note on both findings. Never merge, drop, or renumber either finding from this alone. |
+| `verify_order` | `{id, p}`, sorted lowest-`p`-first | Feed this order into Wave C's own dispatch — verify the lowest-plausibility findings first — never as a reason to skip verifying any of them. |
+
+`status` is `DONE_WITH_CONCERNS` — never `DONE` — when any `severity_check` is
+`flagged` OR any `merge_candidates` pair scores `p >= 0.5`
+(`LIKELY_DUPLICATE_THRESHOLD`, `src/commands/review-jev-triage.ts`). Live-check
+calibration found same-file pairs that were NOT duplicates scoring around
+0.6, so a merge candidate above the threshold is a prompt to look, never a
+merge — the status flip is a nudge to read the pair, not a verdict that the
+findings are duplicates.
+
+Show its annotations in the report as their own subsection, next to (not
+inside) the findings they annotate — same separation the finding schema
+itself draws between a reviewer's claim (`severity`, `problem`, …) and what
+became of it (`disposition`), which a reviewer never states and this pass
+does not either.

package/src/gdskills/bundled/skills/review/review-orchestrator/SKILL.md

@@ -42,6 +42,7 @@ Review Orchestrator Progress:
 - [ ] Step 7: Stage 1 gate - spec compliance check (if issue/task provided)
 - [ ] Step 8: Dispatch selected reviewers in PARALLEL with reviewer-input schema
 - [ ] Step 9: Collect reviewer-finding schema results and handle NEEDS_CONTEXT
+- [ ] Step 9b: `jev-triage` — advisory, annotate-only severity/duplicate/verify-order annotations over the consolidated findings (opt-in `review.jev.triage`)
 - [ ] Step 10: Wave C — dispatch `review-verifier` over the consolidated findings
 - [ ] Step 11: Sort by severity, deduplicate, emit unified report
 - [ ] Step 12: Emit the machine-readable `keryx:findings` block alongside the report
@@ -1168,7 +1169,7 @@ that already holds intent and diff side by side is this one.
 
 Run it on every round, not only the first. The drift the finding catches is
 created BY the rounds: the code moves to answer findings, the body does not, and
-whoever reads the merge commit a year later reads the body.
+whoever reads the merge commit a year later reads the body. When `review.jev.contract` is on, dispatch `review-jev-contract --pr` and read its `findings` as this comparison's scored result instead of judging it by eye; the by-eye judgement is the fallback when that opt-in is off — `SKILL.detail.md` § "CLI-engine reviewers".
 
 ---
 
@@ -1177,7 +1178,7 @@ whoever reads the merge commit a year later reads the body.
 Dispatch selected reviewers in parallel when independent. Use waves when token budget is tight or when one reviewer needs another result:
 
 1. Wave A - core correctness/risk reviewers: logic, architecture, security/highload when selected.
-2. Wave B - domain reviewers: frontend/backend/testing/convention reviewers filtered to relevant files. `review-jev-rules` (flow 330) also runs here, CLI-engine not sub-agent — `SKILL.detail.md` § "CLI-engine reviewers".
+2. Wave B - domain reviewers: frontend/backend/testing/convention reviewers filtered to relevant files. `review-jev-rules` (flow 330), `review-jev-risk`/`review-jev-scenarios` (flow 332), `review-jev-docs`/`review-jev-comments` (flow 333), `review-jev-contract` (flow 335) also run here, CLI-engine not sub-agent, `"engine": "jev"` in `keryx review reviewers --json`, gated on their own opt-in and a resolvable Jev/OpenRouter credential — `SKILL.detail.md` § "CLI-engine reviewers".
 3. Wave C - **verification**: `review-verifier` over the consolidated findings, when blockers/majors
    exist, `--verify` is set, or the PR is high-risk. See below.
 
@@ -1691,8 +1692,7 @@ CONTEXT_PATH: .metaproject/jobs/<job-name>/ai/context.md
 If provided and the file exists, read the context document **before** running scope detection.
 Use it to understand:
 - Intentionally chosen libraries and patterns (do not flag as issues)
-- Architectural decisions already agreed upon
-- Acceptance criteria to drive the Stage 1 spec compliance gate
+- Architectural decisions already agreed upon, and acceptance criteria driving the Stage 1 spec compliance gate
 
 If absent, proceed normally — context is optional and non-blocking.
 

package/src/gdskills/bundled/stacks/c-cpp/agent-refs.json

@@ -0,0 +1,4 @@
+{
+  "agents": [],
+  "note": "honest gate (DeepSeek deepseek-chat runner+judge, strictness high, trials 10, flow 337) ran and failed for all four skills -- trigger accuracy, not behavior content (every behavior scenario scored 0.9 or 1.0). No generated pair ships; pack stays stability: experimental. See governance/eval.json for the recorded reports and W1-stack-catalog.md's Wave 4 batch 5 implementation notes for the diagnosis."
+}