@mrciphersmith/keryx 0.3.119 → 0.3.121

package/src/gdskills/bundled/skills/review/review-orchestrator/reviewer-input.schema.json

@@ -181,6 +181,25 @@
       "default": false,
       "description": "True when the diff under review was produced to answer earlier findings. A fix round without the earlier findings is the failure this field exists to stop: the reviewer cannot tell whether a fix is complete when it does not know what the fix was answering."
     },
+    "allowed_tools": {
+      "type": "string",
+      "enum": ["read-only", "run-tests"],
+      "default": "read-only",
+      "description": "What the reviewer may do beyond reading. `read-only` (the default): read the diff and files, and run no command, except the read-only history commands `git log`, `git blame` and `git show` (shared law 4; the premise judge too) where the host gives a read-only child git. On keryx shell a read-only child has no shell and no git tool: the parent passes `git log -L`/`git blame` output in `context_files`. `run-tests`: at most one testing reviewer per round may run the tests, inside `exec_budget_s`. Verification commands go through the parent's `keryx review verify-run --timeout`."
+    },
+    "exec_budget_s": {
+      "type": "integer",
+      "minimum": 0,
+      "description": "Seconds of command time the reviewer may spend in total. 0 or absent with `allowed_tools: read-only`; a positive budget with `run-tests`."
+    },
+    "known_findings": {
+      "type": "array",
+      "description": "Findings already recorded by earlier waves of this round. Do not report them again; `keryx review ingest` merges duplicates.",
+      "items": {
+        "type": "object",
+        "additionalProperties": true
+      }
+    },
     "prior_findings": {
       "type": "array",
       "description": "Every finding from earlier rounds on this change, with what the fix claimed about each. Eleven rounds across two flows were dispatched without this, and twice in a row the fix repaired the site the finding named while leaving its siblings — which the NEXT round then found. A reviewer that can see the earlier finding and the claimed disposition can check the claim.",
@@ -227,6 +246,25 @@
         "additionalProperties": true
       }
     },
+    "known_findings": {
+      "type": "array",
+      "description": "Findings an EARLIER WAVE of this same round already reported, from `knownFindingsForWave(<package>)` in src/review/dedupe.ts: id plus the file/line/quote anchor, nothing else. A reviewer that would raise the same defect at the same site cites the known id in its evidence instead of re-reporting it; ingest merges whatever duplicates still arrive (same file, line within 3 or same quote, same mechanism) into one finding with the highest severity and `reported_by`. Optional; absent on the first wave.",
+      "items": {
+        "type": "object",
+        "required": ["id"],
+        "properties": {
+          "id": { "type": "string", "minLength": 1 },
+          "global_id": { "type": ["string", "null"] },
+          "reviewer": { "type": "string" },
+          "severity": { "type": "string", "enum": ["blocker", "major", "minor", "info"] },
+          "file": { "type": ["string", "null"] },
+          "line": { "type": ["integer", "null"], "minimum": 1 },
+          "quote": { "type": ["string", "null"] },
+          "problem": { "type": "string" }
+        },
+        "additionalProperties": false
+      }
+    },
     "layers": {
       "type": "object",
       "description": "The bounded layers block for this reviewer's files, built from the package's own graph, the working-copy wiki and the memory (`keryx review layers block --package <dir> --files <a,b>`). Optional. `truncated` names what was cut and the command that fetches the rest.",

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

@@ -21,7 +21,7 @@ license: "MIT"
 
 ## Purpose
 
-Finds real, code-level performance problems introduced in the changed code of the current branch. Covers N+1 database queries, unnecessary React re-renders, missing memoization in hot paths, memory leaks, large bundle imports, synchronous blocking in async contexts, missing pagination, and redundant API calls. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
+Finds real, code-level performance problems introduced in the changed code of the current branch. Covers N+1 database queries, unnecessary React re-renders, missing memoization in hot paths, memory leaks, large bundle imports, synchronous blocking in async contexts, missing pagination, and redundant API calls. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs. It runs no command unless its payload's `allowed_tools` says `run-tests`, except the read-only `git log`, `git blame` and `git show` where its host gives a read-only child git (keryx shell does not: there the payload supplies the history).
 
 This skill focuses on **measurable or high-likelihood bottlenecks** only. Premature optimization, hypothetical slowness, and style preferences are out of scope.
 
@@ -66,7 +66,7 @@ See shared script: `.metaproject/skills/gdskills/shared/git-merge-base.md`
 
 Run the script from that file to determine `MERGE_BASE` (`BASE_SHA`) and `SCOPE` before proceeding.
 
-**Supplied text first.** When the payload carries `slices`, `context_files`, `diff` or `file_contents`, review exactly that text: a read-only child has no shell, so run no git command and never rebuild the diff. Only with none supplied, collect it:
+**Supplied text first.** When the payload carries `slices`, `context_files`, `diff` or `file_contents`, review exactly that text and never rebuild the diff. A choice's history (law 4) is read with `git log`, `git blame` and `git show` only where the host gives a read-only child git; on keryx shell a read-only child has no shell and no git tool, so read the `git log -L`/`git blame` excerpts the payload supplies, or say the history was not read. Only with none supplied, collect it:
 ```bash
 git diff --name-status "${BASE_SHA}" && git diff "${BASE_SHA}" && git ls-files --others --exclude-standard
 # explicit range: <FROM_SHA>..<TO_SHA> in place of "${BASE_SHA}"
@@ -196,15 +196,10 @@ Detectable from query patterns in changed code (not from DB schema directly):
 
 ### 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.
+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.
 
 Severity levels are defined once, in `review-orchestrator/SKILL.md` →
 **Severity (canonical)**. This reviewer does not restate them: `blocker` is the

package/src/gdskills/bundled/skills/review/review-pr-contract/SKILL.md

@@ -36,8 +36,7 @@ frontend PR missed a documentation gap that sat in plain view: the body left
 the page that describes that table lives outside the diff. The box and the diff
 disagreed, and no reviewer held both.
 
-A finding here is a disagreement between two things you can quote: a line of
-`pr-context.md` and a line of the diff (or of a document). Nothing else is filed.
+A finding here is a disagreement between two things you can quote: a line of `pr-context.md` and a line of the diff (or of a document). Nothing else is filed.
 
 ---
 
@@ -149,6 +148,7 @@ finding ids prefixed `PC-`, then a short summary; `NEEDS_CONTEXT` rather than a
 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.
 
 Severity levels are defined once, in `review-orchestrator/SKILL.md` → **Severity (canonical)**. This reviewer does not restate them: `blocker` is the four merge-blocking shapes named there and nothing else, and the `major`/`minor` boundary is the trigger-and-outcome test.
 

package/src/gdskills/bundled/skills/review/review-pr-feedback/SKILL.md

@@ -347,16 +347,12 @@ Assign one verdict per comment:
 
 Rules, and each one is a way this step goes wrong:
 
-1. **A verdict carries evidence or it is `unverified`.** The file and line read,
-   the query run, the commit cited, the test executed. A verdict reached by
-   re-reading the comment is not a verdict on the code.
+1. **A verdict carries evidence or it is `unverified`.** The file and line read, the query run, the commit cited, the test executed. A verdict reached by re-reading the comment is not a verdict on the code.
 2. **`disagree` is a claim about the code, not about the reviewer.** It requires
    the decision it rests on to exist somewhere a reader can reach — a wiki page,
    a memory entry, an ADR, a test that pins the behaviour. "It is fine" is
    `unverified`.
-3. **Never lower a comment's severity to make it disappear.** Severity is set by
-   the collector; this step assigns a *verdict*, and a `minor` comment that is
-   `valid` is still fixed.
+3. **Never lower a comment's severity to make it disappear.** Severity is set by the collector; this step assigns a *verdict*, and a `minor` comment that is `valid` is still fixed. The premise judge cannot lower it either (rule 7).
 4. **`needs-clarification` is asked before `--fix` runs, not after.** State both
    readings and what each would change. A guess here produces a fix nobody asked
    for and a reply that answers the wrong question.
@@ -367,6 +363,7 @@ Rules, and each one is a way this step goes wrong:
 6. **A `praise` comment takes no verdict.** It makes no claim about the code, so
    there is nothing to establish. It is still answered in Step 10, because the
    reply pass requires a decision for every comment it sees.
+7. **A `valid` comment has its premise checked before it enters the plan.** Before Step 8, dispatch `review-premise` with `source: external-comment` over the `valid` and `valid-wider` comments of severity `minor` or above, each as one finding: `id` its collected `C-NNN`, `url` its URL, `reviewer` its author, `source: external`, the comment text and its `file:line` refs (review-premise, `source` row). An external finding is upheld, challenged or owner-decision, never downgraded. This skill has no review package, so no `ingest` or `decide-premise` runs: save the claims object unchanged beside the durable record, as `.metaproject/reviews/pr-comments/<owner>__<repo>__<n>.premise.json`, apply the merge's refusals by hand (the same `source` row lists them), and record each claim on the comment's Step 7 entry (**Premise**). A `challenged` or `owner-decision` comment is held: ask the operator its question with its options (`ask_user` in keryx shell, the host's question tool elsewhere) and record their answer, in their words, on that entry: it is the one record of it, which a resumed or `--fix` run reads, and the report's Stats count it. An upheld comment is planned and passed in `fix_context.review_feedback`, carrying `premise_verdict` and `premise_answer` as task-implementer's `FIX_CONTEXT` defines them; a dismissed one takes verdict `disagree`, citing that recorded answer as its decision (rule 2), and is answered in Step 10 with no code change. Never dismiss it yourself.
 
 ---
 
@@ -390,6 +387,7 @@ For each comment:
   ```typescript
   // Corrected code example
   ```
+- **Premise** (rule 7): upheld, or held with the judge's question and the operator's answer in their words
 - **Plan item**: P-00N, or "none" with the reason
 - **Confidence**: High | Medium | Low
   - High: reviewer's intent is clear and the fix is straightforward
@@ -453,8 +451,8 @@ it into a fix the reviewer did not ask for.
 
 1. `--fix` was passed explicitly.
 2. Step 3 ran through the CLI and the durable record exists.
-3. No comment is still `needs-clarification`, and none carries an unreviewed
-   `prompt-injection` finding.
+3. No comment is still `needs-clarification` or held without the operator's answer
+   (rule 7), and none carries an unreviewed `prompt-injection` finding.
 4. The working tree is clean and Task Manager is enabled
    (`modules.tasks.enabled: true`).
 5. The reviewed PR is open.
@@ -524,7 +522,7 @@ branch on purpose.
   "operator_confirmed": { "confirmed_by": "<who>", "confirmed_at": "<iso8601>", "plan_digest": "<digest of the plan shown>" },
   "constraints": [
     "pr: open it as a draft, titled 'fix(review): address feedback on #<n>', body linking #<n> and listing which plan item answers which comment.",
-    "review: run review-orchestrator with --all on every round. The loop's exit threshold is the one your own PR review/fix loop defines; do not take it from this string.",
+    "review: run review-orchestrator on every round, starting each round with `keryx review start` (or `keryx review plan`) on the new head: the round, its range and the prior findings come from `round.json`. No own range, no `--all` per round, no whole-branch re-review. The loop's exit threshold is the one your own PR review/fix loop defines; do not take it from this string. Every plan item's comment was premise-checked in review-pr-feedback rule 7 and each held one answered by the operator (its Premise entry; claims in .metaproject/reviews/pr-comments/<owner>__<repo>__<n>.premise.json): do not run review-premise again before freeze.",
     "review: the fix PR is its own conversation — collect and reply on IT as normal. The round MUST NOT run a reply pass against #<n>: a reply there writes the durable record, so the post-merge answer citing the merge SHA is skipped as already-handled and the reviewer is left holding a mid-loop answer that has since stopped being true.",
     "attempt budget: at most <max_fix_rounds> review/fix attempts. This LOWERS your bound and never raises it; absent the value, your own bound stands. The `keryx review loop` repetition check applies either way. Do not raise anything to reach a clean round; escalate instead.",
     "scope: the plan items only. A finding outside them is recorded as follow-up, not fixed in this flow."
@@ -812,7 +810,7 @@ Full markdown report structure:
 
 ## Stats
 - blocker: N / major: N / minor: N / info: N / praise: N
-- verdicts: valid N, already-fixed N, disagree N, out-of-scope N, unverified N
+- verdicts: valid N, already-fixed N, disagree N, out-of-scope N, unverified N; premise: upheld N, held N (each answer is on its Step 7 **Premise** entry)
 
 ## By Author
 ### <reviewer-login> (N comments — REQUEST_CHANGES)

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

@@ -0,0 +1,180 @@
+---
+name: review-premise
+model_tier: deep
+description: |
+  Use when: findings exist and someone is about to act on them — after the verifier in a
+  review round (Wave D), or before a fix loop implements a finding that came from a
+  follow-up issue or an external review comment. Judges whether each finding is a defect
+  at all, on intent, accepted practice, consistency and fix soundness, and returns
+  upheld | downgraded | challenged | owner-decision. It can only lower a severity or hold a
+  finding for the operator; it never adds a finding, raises a severity or edits its text.
+  NOT for: first-pass review (run domain reviewers first); checking whether a finding
+  reproduces (review-verifier); dismissing a finding, which only the operator does.
+triggers:
+  - "judge the premise of these findings"
+  - "review --premise"
+  - "is this standard practice"
+  - "is this finding a real defect"
+metadata:
+  author: "MrCipherSmith"
+  version: "1.0.0"
+  category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode,claude"
+  origin: "authored"
+license: "MIT"
+---
+
+# Review — Premise
+
+Wave D. A finding can reproduce and still be wrong. The verifier asks whether the fact a
+finding names is there; this judge asks whether that fact is a defect. It reads each
+finding on a clean context, judges it, and emits one premise claim per finding. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
+
+## The case this exists for
+
+A final review reported: *the playback timeline is pinned LTR — two components hard-code
+`dir="ltr"`, so the timeline does not mirror in RTL.* The fact was true and reproduced.
+The finding was still wrong. Platform guidance says media playback controls and their
+progress indicator do not mirror (Material Design, Bidirectionality; Apple HIG, Right to
+left), and the code carried three signals of a deliberate choice: the explicit override,
+a lint exemption naming that area a physical-LTR island, and a sibling media control
+forcing the same direction. The finding was implemented; two reviews of the fix checked
+only the implementation. Asked "is this standard practice?", a model refuted it in one turn.
+
+## Workflow
+
+```
+review-premise Progress:
+- [ ] Step 1: Drop every finding below `minor`
+- [ ] Step 2: Per finding, read only its bare claim (title, file, quote) and the code there; form a view
+- [ ] Step 3: Collect intent signals at and around the site (see question 1)
+- [ ] Step 4: Answer the four questions
+- [ ] Step 5: Only now read the reviewer's problem, impact, evidence and suggested_fix; revise if they show something you missed
+- [ ] Step 6: Emit one premise claim per finding judged, and nothing else
+```
+
+The order of steps 2 and 5 is the point. A reviewer's argument read first anchors the
+judgement on it; the claim and the code read first let you see what the reviewer did not.
+
+## Input Contract
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `findings` | array | yes | Canonical findings (`review-finding.schema.json`), each with its display `id`, unique in the package (the caller renumbers a collision, a new finding sharing a carried one's id included, in the saved reviewer results before you run): your claim's `finding_id` (a claim may name an id the duplicate merge absorbed; it then targets the surviving finding). Only a finding carried from an earlier round also has a `global_id` (ingest mints the rest after you run); a claim may name a carried finding by it. Each has `reviewer`, `severity`, `source` (`external` marks a PR comment), `file`, `quote`, `problem`, `suggested_fix`. In a delta round, only findings with no carried premise. |
+| `judge` | string | yes | Your own name. Recorded on the claims file. |
+| `source` | string | no | `round` (default), `follow-up-issue` or `external-comment`: where the findings came from. The last two have no review package: each finding is the issue or comment text as `problem`, its `file:line` refs as `file`/`line` with the code there as `quote`, the comment's `C-NNN` (review-pr-feedback) or the issue's number as `id` with its URL as `url`, its author as `reviewer` and the severity it states (else `minor`). The caller saves your claims beside its own record (a flow: `<flow-dir>/premise/<n>.json`) and journals the operator's answer; no `ingest` or `decide-premise` runs, so the caller applies every refusal of the merge (`PREMISE_REJECTION_REASONS`, `src/review/premise.ts`) by hand. For one finding those are: any claim on a finding below `minor` (`below-minor`); an uncited `challenged` or `downgraded`; a `downgraded` with no `severity`, or with the finding's own severity (`not-a-downgrade`) or a higher one (`raise-severity`); a `severity` on any other verdict (`severity-without-downgrade`); a downgrade of an external or `review-security-code` finding, of a `minor`, or below `minor`; a hold without a `question`; an `owner-decision` with fewer than two options; a judge that raised the finding. |
+| `branch` / `base_sha` | string | no | So `git log` and `git blame` read the change under review, where your host gives you git; on keryx shell the caller passes their output in `context_files`. |
+
+## The four questions
+
+1. **Intent.** Is the thing called a defect a deliberate choice? Look for an explicit
+   override (`dir="ltr"`, `!important`, a pinned version, a forced flag), a suppression or
+   exemption (a lint disable, a `@ts-expect-error` with a reason, an allowlist entry), a
+   comment or commit message giving a reason (`git log -L <start>,<end>:<file>`, `git blame`, `git show <sha>`
+   where your host gives you git; on keryx shell, the history excerpts the caller passes in `context_files`), and
+   sibling code doing the same. A signal does not prove the choice right; it proves someone chose, so the finding has to show their reason wrong.
+   A signal the branch under review itself introduces (in `git log <base>..<head>`, or in lines
+   the diff adds) is not evidence of a prior deliberate choice: the change cannot ratify itself.
+2. **Accepted practice.** What do platform guidelines (Material Design, Apple HIG, WCAG,
+   the framework's own docs), the language's idioms, clean-code principles and common
+   patterns say? Then the project's own rules, with their known exceptions. A project rule
+   applied where accepted practice makes an exception is not a defect.
+3. **Consistency.** Would the suggested fix make the system more consistent or less? A fix
+   that makes one site differ from siblings doing the same thing is evidence against the
+   premise, not a follow-up.
+4. **Fix soundness.** Would a senior reviewer reject the suggested fix? A fix that is wrong
+   for the platform usually means the premise is wrong too.
+
+## Verdicts
+
+| Verdict | Meaning | Must carry |
+|---|---|---|
+| `upheld` | The premise stands; the finding goes on unchanged. | — |
+| `downgraded` | A defect, but intent or practice shows it is smaller than reported. Never for a `minor`, an external or a `review-security-code` finding: hold those with `challenged` or `owner-decision` instead. | `severity`, strictly lower and never below `minor`, and ≥1 `intent_signals` or `practice_sources` |
+| `challenged` | Evidence says it is not a defect. | ≥1 `intent_signals` or `practice_sources`, and a `question` |
+| `owner-decision` | A product choice the code cannot settle either way. | a `question` and ≥2 `options` |
+
+`challenged` and `owner-decision` **hold** the finding: it does not count as an open
+blocker or major, it is not sent to a fixer, and the verdict lists it as awaiting the
+operator, who answers with `keryx review decide-premise` (`uphold` or `dismiss`). You never
+dismiss. `upheld` is the normal answer: a finding with a trigger, an outcome, no intent
+signal and no practice source against it is upheld.
+
+## Iron Laws
+
+| Rule | Why |
+|------|-----|
+| **You can only lower or hold.** No new finding, no raised severity, no edit to a finding's text. | The merge builds the record from the original finding and takes only your verdict; a claim carrying more is rejected (`unknown-property`), an entry that is no object too (`malformed-claim`). |
+| **Never judge your own finding.** | The merge rejects a judge equal to the reporter (`self-judgement`). |
+| **Claim first, argument second.** | The case passed two reviews that read the fix's argument and never the premise. |
+| **`challenged` cites.** Each intent signal names its `ref` (`file:line` or a SHA) and what it says; each practice source names the guideline and section precisely enough to look up. | An uncited challenge is rejected and the finding stays as reported. Never invent a quote. |
+| **Never re-grade by the rubric.** Severity is the reviewer's and the verifier's call; a test gap or a surviving mutant stays as reported unless intent or practice shrinks it, and a minor is upheld or challenged, never downgraded. | An uncited downgrade is rejected (`downgrade-without-evidence`). Minors matter: a finding you weaken is one nobody fixes. |
+| **Read-only.** Read files; run nothing but `git log`, `git blame` and `git show`, and those only where your host gives a read-only child git. On keryx shell you have no shell and no git tool: read the history excerpts in `context_files`, or say the history was not read. | Executing is the verifier's job; this judgement is about meaning. |
+| **An external finding, and a `review-security-code` finding, is held or upheld, never dismissed or downgraded.** | A human asked; the operator answers them. Severity of a security finding measures exposure, which intent does not lower. The merge rejects the downgrade (`external-downgrade`, `security-downgrade`). |
+
+## Output Contract
+
+```
+STATUS: DONE | NEEDS_CONTEXT | BLOCKED
+```
+
+- `DONE` — every finding given was judged or explicitly left alone (below `minor`).
+- `NEEDS_CONTEXT` — the code at a finding's site cannot be read; say which.
+- `BLOCKED` — the findings input is unreadable or carries no ids.
+
+Then one premise claims object. The orchestrator saves it unchanged as the file
+`keryx review ingest --premises <file>` reads:
+
+````text
+```json keryx:premises
+{
+  "judge": "review-premise",
+  "model": "<model id>",
+  "premises": [
+    {
+      "finding_id": "LY-003",
+      "verdict": "challenged",
+      "intent_signals": [
+        { "ref": "src/player/TimelineSlider.tsx:150", "says": "explicit dir=\"ltr\" on the timeline root" },
+        { "ref": "eslint.config.js:42", "says": "exemption names this area a physical-LTR scroll/pixel island" },
+        { "ref": "src/player/MediaControls.tsx:81", "says": "sibling media control forces the same direction" }
+      ],
+      "practice_sources": [
+        { "name": "Material Design — Bidirectionality", "says": "media playback controls and progress do not mirror" },
+        { "name": "Apple HIG — Right to left", "says": "video controls and timeline indicators keep their direction" }
+      ],
+      "reasoning": "The fact reproduces, but LTR is the platform practice for playback and the code chose it three times.",
+      "question": "The timeline is LTR on purpose, as platforms do. Keep it, or mirror it anyway?",
+      "options": ["dismiss — keep LTR, as platforms do", "uphold — mirror the timeline"]
+    },
+    { "finding_id": "LG-002", "verdict": "downgraded", "severity": "minor", "intent_signals": [{ "ref": "src/a.ts:12", "says": "comment: legacy fallback kept until v3, read-only" }], "reasoning": "A real defect in a path the code marks as legacy and read-only." },
+    { "finding_id": "LG-004", "verdict": "upheld", "reasoning": "No signal of intent; the null path is reachable from the form reset." }
+  ]
+}
+```
+````
+
+Then a short markdown summary: counts per verdict, and for each held finding its id, the
+question, and the signals or sources behind it.
+
+## Scope Boundaries
+
+| Concern | This skill | Use instead |
+|---------|------------|-------------|
+| Whether a finding is a defect at all | YES | — |
+| Lowering a severity, holding a finding for the operator | YES | — |
+| Whether a finding reproduces | NO | `review-verifier` |
+| Adding a finding, raising a severity, editing one | **NO** | a domain reviewer in a new round |
+| Dismissing a finding | NO | the operator: `keryx review decide-premise --answer dismiss` |
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|----------------|-----------------|
+| "The fact reproduces, so the finding is right." | Reproducing proves the fact, not the defect. The case reproduced. |
+| "The reviewer's argument is convincing." | That is why you read it last. |
+| "A sibling does the same; that is a follow-up." | A sibling doing the same is a signal of intent, against the premise. |
+| "The project rule says X, so any deviation is a defect." | Check the rule against platform practice and its known exceptions first. |
+| "It is clearly wrong; I will mark it dismissed." | You cannot dismiss. Hold it with a question; the operator decides. |
+| "Challenge anything ambiguous, to be safe." | A held finding costs the operator a question. Without a cited signal or source it is upheld. |
+| "I will run the tests to be sure." | Read-only. Running something is the verifier's method, not yours. |

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

@@ -22,15 +22,14 @@ license: "MIT"
 # Review: Regression
 
 You are reviewing **scope B** of a deep round. The files you are given are not
-under review. They are under **regression check**. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
+under review. They are under **regression check**. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs. It runs no command unless its payload's `allowed_tools` says `run-tests`, except the read-only `git log`, `git blame` and `git show` where its host gives a read-only child git (keryx shell does not: there the payload supplies the history).
 
 ## The one question
 
 > Does this change break an existing behaviour here?
 
 Not "is this code good". Not "would I have written it this way". The blast-radius
-set is code that already worked; your job is to find where the change stops it
-working.
+set is code that already worked; your job is to find where the change stops it working.
 
 This is enforced, not requested. `keryx review ingest` runs
 `screenBlastRadiusFindings` over the findings this scope returns and refuses
@@ -164,13 +163,14 @@ rejected anyway, so in practice every finding you report carries one.
 ```
 
 Severity comes from **Severity (canonical)** in `review-orchestrator/SKILL.md`; no table here. When dispatched, follow the `reviewer-input.schema.json` payload and return a `REVIEW_RESULT` object compatible with
-`.metaproject/skills/gdskills/review/review-orchestrator/reviewer-finding.schema.json`, then a short summary; `NEEDS_CONTEXT` rather than a guess.
+`.metaproject/skills/gdskills/review/review-orchestrator/reviewer-finding.schema.json`, then a short summary; `NEEDS_CONTEXT` rather than a guess. On a FIX slice, also return `prior_dispositions: [{id, disposition}]` for every attached finding id.
 
 ### 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.
 
 Severity levels are defined once, in `review-orchestrator/SKILL.md` → **Severity (canonical)**. This reviewer does not restate them: `blocker` is the four merge-blocking shapes named there and nothing else, and the `major`/`minor` boundary is the trigger-and-outcome test.
 

package/src/gdskills/bundled/skills/review/review-security-code/SKILL.md

@@ -23,7 +23,7 @@ license: "MIT"
 
 ## Purpose
 
-Finds exploitable security vulnerabilities introduced in the changed code of the current branch. Covers injection, auth/authz gaps, IDOR, secrets, insecure crypto, CSRF, path traversal, and framework-specific patterns (NestJS, React). Produces findings with explicit attack vectors and concrete fixes. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
+Finds exploitable security vulnerabilities introduced in the changed code of the current branch. Covers injection, auth/authz gaps, IDOR, secrets, insecure crypto, CSRF, path traversal, and framework-specific patterns (NestJS, React). Produces findings with explicit attack vectors and concrete fixes. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs. It runs no command unless its payload's `allowed_tools` says `run-tests`, except the read-only `git log`, `git blame` and `git show` where its host gives a read-only child git (keryx shell does not: there the payload supplies the history).
 
 This skill covers **code-level security only**. It does NOT audit npm/bun dependency trees, Docker configurations, or deployment surfaces — use `security-audit` for those.
 
@@ -67,7 +67,7 @@ See shared script: `.metaproject/skills/gdskills/shared/git-merge-base.md`
 
 Run the script from that file to determine `MERGE_BASE` (`BASE_SHA`) and `SCOPE` before proceeding.
 
-**Supplied text first.** When the payload carries `slices`, `context_files`, `diff` or `file_contents`, review exactly that text: a read-only child has no shell, so run no git command and never rebuild the diff. Only with none supplied, collect it:
+**Supplied text first.** When the payload carries `slices`, `context_files`, `diff` or `file_contents`, review exactly that text and never rebuild the diff. A choice's history (law 4) is read with `git log`, `git blame` and `git show` only where the host gives a read-only child git; on keryx shell a read-only child has no shell and no git tool, so read the `git log -L`/`git blame` excerpts the payload supplies, or say the history was not read. Only with none supplied, collect it:
 ```bash
 git diff --name-status "${BASE_SHA}" && git diff "${BASE_SHA}" && git ls-files --others --exclude-standard
 # explicit range: <FROM_SHA>..<TO_SHA> in place of "${BASE_SHA}"
@@ -201,15 +201,10 @@ Attack vector template: _"Attacker sends `filename=../../etc/passwd`, reading ar
 
 ### 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.
+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.
 
 Severity levels are defined once, in `review-orchestrator/SKILL.md` →
 **Severity (canonical)**. This reviewer does not restate them: `blocker` is the

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

@@ -25,7 +25,7 @@ license: "MIT"
 
 Focused style reviewer. Covers naming conventions, dead code, readability, DRY violations,
 import organization, comment quality, file length, cyclomatic complexity, and console noise.
-Never touches logic correctness, architecture, security, or performance. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
+Never touches logic correctness, architecture, security, or performance. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs. It runs no command unless its payload's `allowed_tools` says `run-tests`, except the read-only `git log`, `git blame` and `git show` where its host gives a read-only child git (keryx shell does not: there the payload supplies the history).
 
 ---
 
@@ -66,7 +66,7 @@ Run that script to determine `BASE_SHA` before collecting the diff.
 
 Only review code changed in scope. Do not flag style issues in lines outside the diff.
 
-**Supplied text first.** When the payload carries `slices`, `context_files`, `diff` or `file_contents`, review exactly that text: a read-only child has no shell, so run no git command and never rebuild the diff. Only with none supplied, collect it:
+**Supplied text first.** When the payload carries `slices`, `context_files`, `diff` or `file_contents`, review exactly that text and never rebuild the diff. A choice's history (law 4) is read with `git log`, `git blame` and `git show` only where the host gives a read-only child git; on keryx shell a read-only child has no shell and no git tool, so read the `git log -L`/`git blame` excerpts the payload supplies, or say the history was not read. Only with none supplied, collect it:
 ```bash
 git diff --name-status "${BASE_SHA}" && git diff "${BASE_SHA}" && git ls-files --others --exclude-standard
 # explicit range: <FROM_SHA>..<TO_SHA> in place of "${BASE_SHA}"
@@ -195,15 +195,10 @@ Do not flag DRY violations for code outside the diff even if legacy duplication
 
 ### 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.
+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.
 
 Severity levels are defined once, in `review-orchestrator/SKILL.md` →
 **Severity (canonical)**. This reviewer does not restate them: `blocker` is the

package/src/gdskills/bundled/skills/review/review-testing-practices/SKILL.md

@@ -28,8 +28,7 @@ license: "MIT"
 
 # Review — Testing Practices
 
-Reviewer for local testing discipline. Read project test guides first when present, then apply
-the neutral baseline below. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
+Reviewer for local testing discipline. Read project test guides first when present, then apply the neutral baseline below. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs. It runs the tests only when its payload's `allowed_tools` says `run-tests`, within `exec_budget_s`; otherwise it runs no command, except the read-only `git log`, `git blame` and `git show` where its host gives a read-only child git (keryx shell does not: there the payload supplies the history).
 
 ---
 
@@ -195,6 +194,7 @@ pass, then work the checklist.
 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.
 
 Severity levels are defined once, in `review-orchestrator/SKILL.md` → **Severity (canonical)**. This reviewer does not restate them: `blocker` is the four merge-blocking shapes named there and nothing else, and the `major`/`minor` boundary is the trigger-and-outcome test.