@mrciphersmith/keryx 0.3.6 → 0.3.7

package/dist/core.js

@@ -8599,15 +8599,15 @@ var CEILINGS_BY_KEY, SKILL_LENGTH_CEILINGS;
 var init_skill_length_ceilings = __esm(() => {
   CEILINGS_BY_KEY = {
     "core/reviewer-skill-creator": 280,
-    "orchestration/code-verifier": 346,
+    "orchestration/code-verifier": 339,
     "orchestration/context-collector": 671,
     "orchestration/feature-analyzer": 447,
     "orchestration/feature-dev": 177,
     "orchestration/flow-orchestrator": 696,
     "orchestration/issue-analyzer": 373,
     "orchestration/job-documenter": 414,
-    "orchestration/job-orchestrator": 2246,
-    "orchestration/task-implementer": 670,
+    "orchestration/job-orchestrator": 2243,
+    "orchestration/task-implementer": 668,
     "planning/autodoc-analyst": 180,
     "planning/autodoc-architect": 179,
     "planning/autodoc-assembler": 145,
@@ -11183,6 +11183,11 @@ var init_rules_export = __esm(() => {
   init_registry();
 });
 
+// src/integrations/jev-edit-guard-surface.ts
+var init_jev_edit_guard_surface = __esm(() => {
+  init_settings_json();
+});
+
 // src/integrations/service.ts
 var init_service = __esm(() => {
   init_registry();
@@ -11191,6 +11196,7 @@ var init_service = __esm(() => {
   init_codecs();
   init_surfaces();
   init_rules_export();
+  init_jev_edit_guard_surface();
   init_surfaces_w5b();
   init_surfaces_learning();
   init_markdown_block();
@@ -23371,6 +23377,7 @@ var exports_service3 = {};
 __export(exports_service3, {
   AC_CHECK_TOKEN_BUDGET: () => AC_CHECK_TOKEN_BUDGET,
   CONFIRMATION_CAVEAT: () => CONFIRMATION_CAVEAT,
+  REVIEW_GATE_CONFIG_PATH: () => REVIEW_GATE_CONFIG_PATH,
   acCheckCacheKey: () => acCheckCacheKey,
   acCheckCachePath: () => acCheckCachePath,
   acCriterionKnown: () => acCriterionKnown,
@@ -37245,6 +37252,18 @@ var HELP_GROUPS = [
     group: "Managed work",
     summary: "Opt-in routing classifier: each request runs on its routing category's model \u2014 /route [on|off]."
   },
+  {
+    kind: "slash",
+    name: "/editguard",
+    group: "Managed work",
+    summary: "Jev EDIT GUARD status, threshold and recent flags for the Claude Code PostToolUse hook, with a toggle."
+  },
+  {
+    kind: "slash",
+    name: "/jevprofile",
+    group: "Managed work",
+    summary: "Every review.jev.* setting next to its measured verdict; toggle one or apply the recommended profile."
+  },
   { kind: "slash", name: "/plan", group: "Managed work", summary: "Toggle read-only mode \u2014 /plan [on|off]." },
   {
     kind: "slash",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mrciphersmith/keryx",
-  "version": "0.3.6",
+  "version": "0.3.7",
   "description": "Version-controlled project context for AI coding agents: code graph, architecture wiki, project memory, relevant tests, quality signals, and task flows.",
   "private": false,
   "publishConfig": {

package/src/gdskills/bundled/skills/orchestration/code-verifier/SKILL.md

@@ -151,6 +151,17 @@ Capture:
 - Exit code
 - List of circular chains (if any)
 
+**2.4 GitHub CI results (only when the dispatch names a PR or run id):**
+```bash
+gh pr checks <pr> --json name,state,link   # or use the run id already given
+```
+For each failed check, when `review.jev.ci_triage` is on, run `keryx review
+ci-triage --run <id> --json` before filing it as a finding — `real-regression`
+files CRITICAL as usual; `flaky`/`deterministic` files INFO, "likely flaky —
+rerun before treating as a defect"; `infra` files INFO, "infra failure, not a
+code defect." Every red check still appears; only severity and note change.
+Setting off → file CRITICAL as before, no Jev call.
+
 ---
 
 ### Phase 3: ANALYZE
@@ -259,26 +270,13 @@ STATUS: BLOCKED       — could not run checks (missing tooling, wrong directory
 
 ## Integration with job-orchestrator
 
-The orchestrator dispatches `code-verifier` at two points:
-
-**After task-implementer wave (pre-review gate):**
-```
-code-verifier:
-  codebase_path: <worktree_path>
-  scope: changed
-  base_branch: <base_branch from JOB_STATE>
-→ If gate: FAIL → dispatch fix tasks → re-run code-verifier
-→ If gate: PASS → proceed to review
-```
+The orchestrator dispatches `code-verifier` at two points, always with
+`codebase_path: <worktree_path>` and `scope: changed`:
 
-**After fix iterations (post-fix gate):**
-```
-code-verifier:
-  codebase_path: <worktree_path>
-  scope: changed
-→ If gate still FAIL after 3 iterations → report as BLOCKED, skip to report
-→ If gate: PASS → proceed to report
-```
+| Dispatch point | Extra input | On FAIL | On PASS |
+|---|---|---|---|
+| After task-implementer wave (pre-review gate) | `base_branch` from JOB_STATE | dispatch fix tasks, re-run | proceed to review |
+| After fix iterations (post-fix gate) | — | after 3 iterations: report BLOCKED, skip to report | proceed to report |
 
 **The orchestrator's internal "checks" step (2.8) is replaced by `code-verifier` dispatch.**
 
@@ -287,14 +285,9 @@ code-verifier:
 ## Standalone Usage
 
 ```bash
-# Run on current directory, changed files only
-/code-verifier
-
-# Run on specific project
+/code-verifier                        # current directory, changed files only
 /code-verifier --path /path/to/project
-
-# Full project scan (not just changed files)
-/code-verifier --scope full
+/code-verifier --scope full            # full project scan
 ```
 
 ---

package/src/gdskills/bundled/skills/orchestration/flow-orchestrator/SKILL.md

@@ -26,13 +26,9 @@ license: "MIT"
 Flow Orchestrator is the Task Manager-aware implementation orchestrator. Plan bridge: publish the tasks with `plan_set` under the ids `T1`…`Tn`, mirror each `keryx flow task done` with `plan_update`, and publish Phase 4's completion choice as `proposed` — see the `session-plan-bridge` rule.
 It wraps the existing gdskills pipeline with `keryx flow` state.
 
-Use this skill instead of `job-orchestrator` when the user wants a managed
-story/issue lifecycle with frozen acceptance criteria, task state, an explicit
-completion choice, Code Health, and a durable flow package in
-`.metaproject/flows/`.
+Use this skill instead of `job-orchestrator` when the user wants a managed story/issue lifecycle with frozen acceptance criteria, task state, an explicit completion choice, Code Health, and a durable flow package in `.metaproject/flows/`.
 
-Do not modify `job-orchestrator` or `task-implementer` behavior. They remain
-usable without Task Manager. This skill coordinates them through flow state.
+Do not modify `job-orchestrator` or `task-implementer` behavior. They remain usable without Task Manager. This skill coordinates them through flow state.
 
 ## Hard Preconditions
 
@@ -311,6 +307,8 @@ Recommended worker routing:
 | `review` | `review-orchestrator` |
 | `docs` | `job-documenter`, `prd-creator`, or documentation-specific project skill |
 
+**Before the first `task-implementer` dispatch of the run:** when `review.jev.edit_guard` is on (`.metaproject/tasks.config.json`), confirm the guard is active — `keryx review jev-edit-guard status`, else `keryx review jev-edit-guard install` — and say why in one line.
+
 ### Worker communication is schema-governed
 
 Workers do not inherit session state; every dispatch is constructed explicitly
@@ -546,6 +544,8 @@ the bound plus an escalation — never an unbounded loop.
 2. If findings or required check failures remain, create or update a flow fix
    task, dispatch `task-implementer`, push the fix, and run review again.
 
+   **A required check failure is not automatically a fix task.** When `review.jev.ci_triage` is on, run `keryx review ci-triage --run <id> --json` on each failed run first: `top: flaky` (or a `deterministic` override) → rerun once (`gh run rerun --failed <id>`), record it in `journal.md`, and treat a second failure as `real-regression` regardless; `top: real-regression` → investigate and fix as usual; `top: infra` → report it in the completion notes and leave the code alone. The verdict is advisory only — never the sole reason to skip a fix task.
+
    **The threshold is `minor`.** The loop exits when the round reports zero
    findings at `blocker`, `major` or `minor`; `info` does not hold it. State the
    remaining `info` findings in the completion report rather than fixing them

package/src/gdskills/bundled/skills/orchestration/job-orchestrator/SKILL.md

@@ -799,6 +799,8 @@ Task({
 })
 ```
 
+**Before this wave's first task-implementer dispatch:** when `review.jev.edit_guard` is on (`.metaproject/tasks.config.json`), confirm the guard is active — `keryx review jev-edit-guard status`, else `keryx review jev-edit-guard install` — and say why in one line.
+
 #### task-implementer dispatch (Step B)
 
 ```
@@ -2024,6 +2026,7 @@ Each step failure is classified into one of three classes with different recover
 | All reviewers fail | `recoverable` | Record the round as failed with a reason, add a warning to the report, continue to VERIFY (2.8) |
 | Fix loop exceeds max_review_iterations | `recoverable` | Disposition every surviving finding, log which ended the loop, continue to VERIFY (2.8) |
 | Final checks fail | `recoverable` | Include in report, still propose PR (user decides) |
+| A GitHub CI check on the PR fails | `recoverable` | When `review.jev.ci_triage` is on, run `keryx review ci-triage --run <id> --json` before reporting it as a defect: `flaky`/`deterministic` → rerun once and note it in the report, a second failure counts as `real-regression`; `real-regression` → treat as a real failure; `infra` → report it, don't touch code. Verdict is advisory only. |
 | gh CLI not available | `recoverable` | Print PR data, user creates manually. `keryx review comments` needs it too — say so rather than reporting `0 outstanding`. |
 
 ### Retry Protocol (for `retryable` errors)
@@ -2041,13 +2044,7 @@ attempt 1: keryx job step <job-name> <step-id> --status in-progress
 **Critical:** on retry, re-send the **same prompt** — hold it for the duration of the
 step and re-send it verbatim. Never re-derive it; re-derivation causes drift.
 
-The prompt itself is **not** persisted: `keryx job` writes no `step.prompt` and no
-prompt size, so do not instruct a resuming session to read one. What *is* persisted is
-that the attempt happened — `metrics.steps[].retries`, incremented every time the step
-re-enters `in_progress`, and the `--reason` line in `journal.md`. A resumed session
-therefore knows how many attempts a step has had, which is the fact the retry budget
-needs, and reconstructs the prompt from the plan and the analysis exactly as the first
-attempt did.
+The prompt itself is **not** persisted: `keryx job` writes no `step.prompt` and no prompt size, so do not instruct a resuming session to read one. What *is* persisted is that the attempt happened — `metrics.steps[].retries`, incremented every time the step re-enters `in_progress`, and the `--reason` line in `journal.md`. A resumed session therefore knows how many attempts a step has had, which is the fact the retry budget needs, and reconstructs the prompt from the plan and the analysis exactly as the first attempt did.
 
 ---
 

package/src/gdskills/bundled/skills/orchestration/task-implementer/SKILL.md

@@ -546,10 +546,8 @@ second copy of a schema is how that happens.
 7. **DO** use `runInAction()` after every `await` in MobX actions.
 8. **DO** use conventional commit format when auto-commit is enabled. Reference only a supplied real issue number; omit the issue reference when absent.
 9. **DO** verify your work before reporting.
-10. **DO** make `STATUS: <TOKEN>` the first line of your final message, and put no
-    JSON in the response body. The full JSON result is the file Phase 6.1 writes
-    and records. `parseChildResult` throws on any first line that is not a
-    canonical STATUS token.
+10. **DO** make `STATUS: <TOKEN>` the first line of your final message, and put no JSON in the response body. The full JSON result is the file Phase 6.1 writes and records. `parseChildResult` throws on any first line that is not a canonical STATUS token.
+11. **DO** check a `Rule check flagged: <clause id> at <file>:<line> — fix it if it is a real violation.` line against the named clause as soon as it arrives — fix the flagged line if it's real, otherwise continue; never argue with or silently ignore it, and record a false flag as `edit-guard false flag: <clause id> — <why>` in `notes` (Phase 6.1) so `review.jev.edit_guard_threshold` can be tuned.
 
 ---
 

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

@@ -94,6 +94,29 @@ 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.
 
+### Measured verdicts (flow 344 — a live benchmark on a large production React/MobX frontend)
+
+Gating them on is still a project's own choice; these are RESULTS, not a change to the gates above.
+
+| Reviewer | Verdict | Measured |
+|---|---|---|
+| `review-jev-risk` | **Off by default** — measured weaker than a strong model | Top-3 recall 21% vs. "largest diff first" 30%; Sonnet 5 alone: 44%. |
+| `review-jev-contract` | **Off by default** — measured weaker than a strong model | Caught 12.5% of false PR-description claims vs. Sonnet 5's 67.5%. |
+| `review-jev-rules` | **Not useful on top of a strong reviewer** | Dispatched as an EXTRA reviewer beside an already-strong reviewer: +0 findings. |
+| `review-jev-scenarios` | Experimental — not measured | — |
+| `review-jev-docs` | Experimental — not measured | — |
+| `review-jev-comments` | Experimental — not measured | — |
+
+By contrast, `keryx review ci-triage` (Step 0b, not a reviewer) and `keryx
+review jev-select` (Step 5c, not a reviewer either) both have a measured case
+FOR them: CI triage cut developer minutes per failure from 30 to 15.4 under an
+explicit cost model (38% vs. 25% flaky/regression/infra accuracy against
+Sonnet 5 reading the same log, p=0.035); reviewer *selection* is the
+unmeasured lever this benchmark named as most promising, which is why
+`jev-select` ships recall-first and fails open rather than waiting for a
+measurement that has not run yet. Full numbers, methodology and the cost
+model: `docs/docs/jev-in-review.md`.
+
 ## `jev-triage` — advisory annotations, not a reviewer (Step 9b)
 
 `review-jev-triage` (flow 340) is a DIFFERENT shape from every CLI-engine

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

@@ -32,12 +32,14 @@ unified report sorted by severity. It does not perform any review logic itself.
 ```
 Review Orchestrator Progress:
 - [ ] Step 0: On a PR target, collect external comments — `keryx review comments collect`
+- [ ] Step 0b: On a PR target whose checks are red, triage each failed run with `keryx review ci-triage --run <id>` (opt-in `review.jev.ci_triage`) — see "CI Triage on Red Checks"
 - [ ] Step 1: Build Review Context Pack — PR metadata AND the PR's own description, scope, rules, context_doc summary, accepted memory, and the cross-repo contracts the diff consumes
 - [ ] Step 2: Detect review mode (diff mode vs. path mode)
 - [ ] Step 3: Build the bounded scope with `keryx review scope` — never by hand
 - [ ] Step 3b: On a deep round, compute scope B with `keryx review blast-radius` — never by browsing — and KEEP the `--json` file; `review ingest --blast-radius <file>` is refused without it
 - [ ] Step 4: Parse flags / auto-detect domain from scope
 - [ ] Step 5: Ask user to confirm optional convention reviewers (legacy/profile reviewers are flag-only, never prompted)
+- [ ] Step 5c: When `review.jev.select` is on, run `keryx review jev-select` over the finalized candidate set and drop its `skip` decisions from Wave A/B — see "Reviewer selection with Jev"
 - [ ] Step 6: Plan sub-agent dispatch and token budgets, and compute each dispatch's model with `keryx review tier` — never by hand
 - [ ] Step 7: Stage 1 gate - spec compliance check (if issue/task provided)
 - [ ] Step 8: Dispatch selected reviewers in PARALLEL with reviewer-input schema
@@ -411,6 +413,14 @@ The rule is about the other pull request:
 
 ---
 
+## CI Triage on Red Checks (Step 0b)
+
+Run once per round, on a PR target whose checks are red, before Step 1: for each failed check run, `keryx review ci-triage --run <id>` (flow 306/307) — an existing keryx command, not something this skill re-implements. Gate it exactly the way the command gates itself: skip it — recorded in the report, never silently absent — when `review.jev.ci_triage` is not `true` in `.metaproject/tasks.config.json`, or no Jev/OpenRouter credential is resolvable; either means the command refuses before any read or network call.
+
+Read each run's verdict (`flaky` | `regression` | `infra`) into the report: `flaky` suggests a rerun rather than a finding; `regression` means investigate before trusting this round's other findings, since a broken build can hide or mimic a real defect; `infra` is noted and the round continues. Advisory only — a verdict never gates dispatch and is never itself a finding.
+
+---
+
 ## Everything written to GitHub is brief
 
 One rule, applied to every outward surface: **PR bodies, PR comments, review
@@ -663,6 +673,8 @@ A **fix round** is any review of work produced to answer earlier findings. Set
 `is_fix_round: true` on every reviewer input, and populate `prior_findings` with
 the earlier findings and the disposition the fix claimed for each.
 
+**The Jev edit guard is a FIX-phase tool, not a review-round tool.** `keryx review jev-edit-guard` (a separate feature) is the recommended Jev step during the FIX phase itself — run by the author's agent as it applies fixes, before this round re-reviews them. This skill never runs it; it is not part of review-orchestrator's own dispatch.
+
 **Nothing refuses a dispatch that omits them.** `reviewer-input.schema.json`
 states the rule and no production TypeScript loads that schema; reviewer
 dispatch is an action the host agent takes, not a `keryx` invocation, so there
@@ -891,8 +903,6 @@ nothing moved. The final round recomputes whatever the file set did — otherwis
 fix introduced in round 3 gets no regression check at all, and the round that
 certifies the flow is the one that checked the least.
 
----
-
 ### Path Mode
 
 When a path or target is named, collect the candidate files:
@@ -918,8 +928,6 @@ and therefore no context window; the drop list is recorded exactly the same way.
 
 **Reviewer behavior in path mode:** reviewers check the entire file content — not just added lines. All findings apply to the current state of the code, not only to changes.
 
----
-
 ### Auto-detection of Reviewers (both modes)
 
 When no flag is provided, infer reviewers from the collected file list:
@@ -1069,6 +1077,10 @@ If the user does not answer and the review is part of an automated `job-orchestr
 use the job setting `convention_reviewers` (default: `"ask"`; if still unresolved, include all
 detected reviewers and record that choice in the review scope).
 
+### Reviewer selection with Jev (`jev-select`) — advisory, before dispatch (Step 5c)
+
+When `review.jev.select` is on, before Wave A/B dispatch: run `keryx review jev-select (--diff <ref>|--pr <n>) --json` over the finalized candidate set (bundled + project reviewers, after every filter above) and drop every reviewer whose `decision` is `skip` from Wave A/B — **never** the Wave A core safety set (`review-logic`, `review-architecture`, `review-security-code`, `review-highload` when selected), which `jev-select` itself never marks `skip`. Record every decision in the report's scope section as `skipped by Jev selection (advisory)`, naming the probability and reason — this lever is UNMEASURED (unlike every CLI-engine reviewer below), so its skips must stay visible enough for a later round to check whether the skipped reviewer's domain surfaced a real finding anyway. It fails open — keeps every candidate — on its own opt-in being off, a missing credential, or any error; never treat a `jev-select` failure as a reason to skip a reviewer.
+
 ---
 
 ## Legacy/Profile Reviewer Auto-Detection
@@ -1137,8 +1149,6 @@ Multiple flags may be combined: `review --backend --security` dispatches `review
 This table applies once this skill is running; reaching it is a separate question. The router strips `--`, so `review --style` is the same phrase as `review-style`'s own `style review` trigger and goes straight there — the same destination this table names, and likewise for `--architecture`, `--security` and `--performance`. Only `--all`, `--project-conventions` and `--legacy-profiles` name this orchestrator, which is why they are its triggers.
 `--frontend` and `--backend` are the exception: this table fans each out to three reviewers, but a bare `review --frontend` reaches `review-frontend` alone, because `review frontend` and `frontend review` are one phrase to the router and that phrase is the specialist's — two skills may not share a trigger token set (`src/gdskills/catalog-single-source.test.ts`). Ask by name, or use `review --all`, when you want the three-reviewer fan-out; `docs/skills/rejected-skill-changes.md` records the alternatives that were measured and rejected.
 
----
-
 ## Stage 1 Gate — Spec Compliance
 
 **Run this FIRST, before dispatching quality reviewers, whenever the change has a
@@ -1178,7 +1188,7 @@ whoever reads the merge commit a year later reads the body. When `review.jev.con
 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), `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".
+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 — measured verdicts per reviewer (keep off by default, experimental, etc.) in `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.
 
@@ -1333,8 +1343,6 @@ Each reviewer must return a `REVIEW_RESULT` object matching `.metaproject/skills
 | Shared flow/graph abstraction contracts | NO | `review-flow-graph` |
 | Legacy/profile review profiles | NO | `code-ai-review`, `code-learned-review`, `code-style-review`, `code-mobx-store-review` |
 
----
-
 ## Sub-Agent Report Quality Gate
 
 Before consolidation, validate every reviewer result:
@@ -1346,8 +1354,6 @@ Before consolidation, validate every reviewer result:
 - `NEEDS_CONTEXT` triggers one targeted context refill. If still unresolved, keep it as an explicit open question, not as a blocker.
 - If a reviewer exceeds `max_findings`, keep blockers/majors first and summarize lower severity findings.
 
----
-
 ## Severity (canonical)
 
 **This is the only severity rubric in the review domain.** Reviewers do not carry
@@ -1445,8 +1451,6 @@ inventing a fifth level to express it would put us back where we started.
 `review-security-code` carries a fourth — every security finding states its attack
 vector — which does not generalise and stays there.
 
----
-
 ## Finding Format
 
 ### Class scope — required for `blocker` and `major`
@@ -1530,8 +1534,6 @@ All findings from all sub-reviewers must be normalized to this format before con
 
 Severity ordering for sort: `blocker` > `major` > `minor` > `info`.
 
----
-
 ### Model Metadata Rules
 
 `adaptive` is a model-assignment outcome recorded when `keryx review tier` printed `inherit: true` and the host picked the model for the tier, not a model name. Never render it as `model: adaptive` or as the PR comment `Model` value.
@@ -1544,8 +1546,6 @@ When writing review report metadata or a PR comment:
 5. If the dispatch's `model` block carried `inherit: true`, write `Model assignment: adaptive` and the model the host actually dispatched on for that tier (or `unknown`).
 6. If the actual model is unknown, write `unknown`; do not substitute `adaptive` or `inherit`.
 
----
-
 ## Output Contract
 
 ```