@mrciphersmith/keryx 0.2.70 → 0.2.72

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

@@ -1,5 +1,6 @@
 ---
 name: review-architecture
+model_tier: deep
 description: |
   Use when: reviewing code for architectural violations — layer violations, dependency direction
   mistakes, module boundary coupling, SOLID principle breaches, NestJS module/provider structure,
@@ -7,7 +8,6 @@ description: |
   Triggered by: "review architecture", "check architecture", "architectural review",
   or dispatched by review-orchestrator with --architecture or --backend.
   NOT for: style/naming preferences, logic correctness bugs, or security vulnerabilities.
-version: "1.0.0"
 triggers:
   - "review architecture"
   - "check architecture"
@@ -19,8 +19,8 @@ metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
   category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode,claude"
 license: "MIT"
-compatibility: "cursor,codex,zed,opencode,claude"
 ---
 
 # Review Architecture
@@ -211,7 +211,7 @@ Focus on **SRP** and **DIP** — the two most commonly violated in practice.
 
 ## Orchestrated Review Contract
 
-When dispatched by `review-orchestrator`, follow the provided `reviewer-input.schema.json` payload. Return a `REVIEW_RESULT` object compatible with `skills/review-orchestrator/reviewer-finding.schema.json`, then a concise markdown summary. Keep findings evidence-based, include concrete `suggested_fix` for every blocker/major, and return `NEEDS_CONTEXT` instead of guessing when required context is missing.
+When dispatched by `review-orchestrator`, follow the provided `reviewer-input.schema.json` payload. Return a `REVIEW_RESULT` object compatible with `skills/review/review-orchestrator/reviewer-finding.schema.json`, then a concise markdown summary. Keep findings evidence-based, include concrete `suggested_fix` for every blocker/major, and return `NEEDS_CONTEXT` instead of guessing when required context is missing.
 
 ---
 
@@ -257,16 +257,43 @@ observation is theatre, not rigour.
   ```
 ```
 
-Severity guide for this reviewer:
+Severity comes from **Severity (canonical)** in `review-orchestrator/SKILL.md`.
+This reviewer keeps no table of its own; what follows is where its recurring
+conditions land under that rubric, not a second rubric.
 
-| Severity | When to use |
-|----------|------------|
-| `blocker` | Circular dependency causing runtime failure; NestJS module scope mismatch causing incorrect behavior; domain importing infrastructure breaking testability entirely |
-| `major` | Clear layer violation (API call in component, business logic in controller); broken DIP; cross-module boundary coupling that will cause maintainability failures |
-| `minor` | SRP smell with clear separation path; ISP violation; component using multiple raw observables instead of computed |
-| `info` | Architectural opinion without clear violation; pattern that could be improved but works correctly |
+| Condition | Severity | Why, under the canonical rubric |
+|---|---|---|
+| Circular dependency that fails at runtime (an import resolves to `undefined` on a path the change reaches) | `blocker` | Crash |
+| Module scope mismatch that produces wrong data across requests | `blocker` | Data corruption |
+| Layer violation — API/IO call in a component, business logic in a controller, domain importing infrastructure | `major` | A named trigger and a named outcome, but structural: not a crash, data loss, vulnerability, or missing acceptance criterion. Identical to `review-frontend`'s rule for the same condition |
+| Broken DIP; cross-module coupling with a named consequence | `major` | Same |
+| SRP smell with a clear separation path; ISP violation; a component reading several raw observables instead of a computed | `minor` | The code is correct; the cost is to whoever restructures it next |
+| Architectural opinion with no named violation | `info` | Shared laws 1 and 2 |
+
+A circular import that resolves cleanly is not a `blocker` — it is `minor`, and
+if the concern is purely readability it belongs to `review-style`.
+
+## Iron Laws
+
+### 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.
+
+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.
+
+### Architecture laws
 
-Iron laws:
 - Only flag actual violations found **in the diff**, not pre-existing issues untouched by the change.
 - Every finding MUST cite a specific `file:line` from the diff.
 - Architecture opinions without a clear, named violation (layer, SOLID principle, pattern misuse) are `info` only — never `blocker` or `major`.

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

@@ -1,5 +1,6 @@
 ---
 name: review-backend
+model_tier: standard
 description: |
   Use when: reviewing NestJS backend changes — API design, service layer, DTO validation,
   database patterns, and TypeScript correctness. Covers "review backend", "backend review",
@@ -7,7 +8,6 @@ description: |
   NOT for: frontend patterns, MobX, React components, general security vulnerabilities
   (use review-security-code for XSS/injection/auth-bypass), or performance profiling
   (use review-performance).
-version: "1.0.0"
 triggers:
   - "review backend"
   - "backend review"
@@ -18,8 +18,9 @@ metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
   category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode,claude"
+  stack_requires: "nestjs,prisma"
 license: "MIT"
-compatibility: "cursor,codex,zed,opencode,claude"
 ---
 
 # Review — Backend (NestJS / API / DB)
@@ -175,28 +176,61 @@ Only review files changed in scope. Do not comment on legacy code outside the di
 - No `as any` or unsafe casts (`as unknown as T`) without a comment explaining why
 - `@ts-ignore` / `@ts-expect-error` without explanation comment — flag as `minor`
 
+  **This is the one severity for this condition, repo-wide.** It was previously
+  `minor` here and `major` in `review-strict`, which is deleted. `minor` is what
+  the canonical rubric returns: a suppressed compiler error names no trigger and
+  no observable wrong outcome — the code does exactly what it did before the
+  comment was added. What it costs is the next reader, who cannot tell what was
+  suppressed or whether it is still needed. That is the definition of `minor`.
+  It becomes `major` only when you can name the input the suppressed error was
+  hiding and the wrong value it produces — at which point the finding is about
+  that bug, not about the comment.
+
 ---
 
 ## Iron Laws
 
-| Condition | Severity |
-|-----------|----------|
-| Missing DTO validation on an endpoint accepting user input | **blocker** |
-| `REQUEST`-scoped provider injected into `Singleton` | **blocker** |
-| Leaking stack trace / raw ORM error to API response | **blocker** |
-| Unhandled promise rejection in controller method | **blocker** |
-| String interpolation in raw SQL query | **blocker** |
-| N+1 query (relation loaded in a loop) | **major** (minimum) |
-| Missing transaction on multi-step atomic mutation | **major** |
-| Business logic in controller | **major** |
-| Missing pagination on unbounded list endpoint | **major** |
-| `NOT NULL` column added without default to populated table (migration) | **blocker** |
+### 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.
+
+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.
+
+### Backend conditions
+
+Where this reviewer's recurring conditions land under the canonical rubric. Not a
+second rubric — each `blocker` names which of the four merge-blocking shapes it
+is, and a condition that cannot name one is not a `blocker`.
+
+| Condition | Severity | Shape |
+|---|---|---|
+| Missing DTO validation on an endpoint accepting user input | `blocker` | Exploitable vulnerability |
+| String interpolation in raw SQL query | `blocker` | Exploitable vulnerability |
+| Leaking stack trace / raw ORM error to API response | `blocker` | Exploitable vulnerability (information disclosure) |
+| `REQUEST`-scoped provider injected into a `Singleton` | `blocker` | Data corruption — one request's state is served to another |
+| Unhandled promise rejection in a controller method | `blocker` | Crash |
+| `NOT NULL` column added without a default to a populated table | `blocker` | Data loss — the migration fails or truncates |
+| N+1 query (relation loaded in a loop) | `major` (minimum) | Named trigger and outcome; degradation, not an outage. Same rating as `review-highload` |
+| Missing transaction on a multi-step atomic mutation | `major` — `blocker` where a partial write corrupts persisted state | The outcome decides |
+| Business logic in a controller | `major` | Layer violation. Same rating as `review-architecture` |
+| Missing pagination on an unbounded list endpoint | `major` — `blocker` where an attacker-reachable request exhausts memory | Degradation vs. crash/DoS |
 
 ---
 
 ## Orchestrated Review Contract
 
-When dispatched by `review-orchestrator`, follow the provided `reviewer-input.schema.json` payload. Return a `REVIEW_RESULT` object compatible with `skills/review-orchestrator/reviewer-finding.schema.json`, then a concise markdown summary. Keep findings evidence-based, include concrete `suggested_fix` for every blocker/major, and return `NEEDS_CONTEXT` instead of guessing when required context is missing.
+When dispatched by `review-orchestrator`, follow the provided `reviewer-input.schema.json` payload. Return a `REVIEW_RESULT` object compatible with `skills/review/review-orchestrator/reviewer-finding.schema.json`, then a concise markdown summary. Keep findings evidence-based, include concrete `suggested_fix` for every blocker/major, and return `NEEDS_CONTEXT` instead of guessing when required context is missing.
 
 ---
 

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

@@ -1,5 +1,6 @@
 ---
 name: review-clean-code
+model_tier: standard
 description: |
   Use when: reviewing code against Clean Code principles (Uncle Bob) and SOLID at the
   function/class level — meaningful names, small functions, single level of abstraction,
@@ -9,7 +10,6 @@ description: |
   "review --clean-code", or dispatched by review-orchestrator.
   NOT for: architectural layer violations (review-architecture), naming convention formatting
   (review-style), logic correctness bugs (review-logic), or security (review-security-code).
-version: "1.0.0"
 triggers:
   - "review clean code"
   - "check clean code"
@@ -21,8 +21,8 @@ metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
   category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode,claude"
 license: "MIT"
-compatibility: "cursor,codex,zed,opencode,claude"
 ---
 
 # Review: Clean Code + SOLID
@@ -84,9 +84,35 @@ worsens them.
 
 ## Iron Laws
 
+### 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.
+
+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.
+
+### Clean Code laws
+
 1. **Findings without a specific `file:line` from the diff are not valid findings.** Never cite general observations about the codebase.
-2. **Max severity for a naming issue is `major`.** Pure naming never rises to `blocker` — reserved for issues that break correctness.
-3. **DRY violations require at least 3 repetitions before becoming `major`.** Two occurrences can be accidental; three is a pattern.
+2. **A naming issue is `minor`.** It reaches `major` only when the name has
+   already produced an observable wrong outcome at a call site you can name — a
+   caller misusing the API because of what it is called. "A future reader might
+   misread it" is the maintenance cost that makes it `minor`, not a trigger.
+   Naming is never a `blocker`. (`review-style` carries the identical rule.)
+3. **DRY violations need at least 3 repetitions before they are worth reporting,
+   and they are `minor`.** Two occurrences can be accidental; three is a pattern.
+   Duplication is a cost to whoever edits it next, which is `minor` by the
+   canonical test — report it once, listing every site, per shared law 3.
 4. **SOLID opinions without a named principle and a concrete violation description are `info` only.** State the principle (e.g., SRP), the two responsibilities, and the impact.
 5. **Do not flag language idioms or framework conventions as Clean Code violations.** If it is the standard way to do something in TypeScript / NestJS / React, it is not a violation.
 
@@ -341,7 +367,7 @@ Flags:
 
 ## Orchestrated Review Contract
 
-When dispatched by `review-orchestrator`, follow the provided `reviewer-input.schema.json` payload. Return a `REVIEW_RESULT` object compatible with `skills/review-orchestrator/reviewer-finding.schema.json`, then a concise markdown summary. Keep findings evidence-based, include concrete `suggested_fix` for every blocker/major, and return `NEEDS_CONTEXT` instead of guessing when required context is missing.
+When dispatched by `review-orchestrator`, follow the provided `reviewer-input.schema.json` payload. Return a `REVIEW_RESULT` object compatible with `skills/review/review-orchestrator/reviewer-finding.schema.json`, then a concise markdown summary. Keep findings evidence-based, include concrete `suggested_fix` for every blocker/major, and return `NEEDS_CONTEXT` instead of guessing when required context is missing.
 
 ---
 
@@ -387,14 +413,25 @@ observation is theatre, not rigour.
   ```
 ```
 
-Severity guide for this reviewer:
-
-| Severity | When to use |
-|----------|------------|
-| `blocker` | Swallowed exception (silent failure); constructor performing I/O that prevents testing; LSP violation breaking substitutability at runtime |
-| `major` | Function >40 lines; ≥4 parameters without options object; boolean flag arg; class with two distinct responsibilities; `new ConcreteService()` bypassing DI |
-| `minor` | Poor naming; redundant comment; magic number; 20–40 line function; minor OCP/ISP smell; log+rethrow |
-| `info` | Stylistic opinion; potential future issue with no current concrete violation |
+Severity comes from **Severity (canonical)** in `review-orchestrator/SKILL.md`.
+This reviewer keeps no table of its own; what follows is where its recurring
+conditions land under that rubric, not a second rubric.
+
+| Condition | Severity | Why, under the canonical rubric |
+|---|---|---|
+| Swallowed exception hiding a failed operation | `major` — `blocker` only if the caller then persists or returns wrong data | Same wording as `review-logic`, deliberately. Silent failure is wrong behaviour; corruption is a different shape |
+| LSP violation that produces a wrong result or a crash at a named call site | `major`, or `blocker` on the crash/corruption outcome | The outcome decides, not the principle's name |
+| Constructor performing I/O | `major` | Named trigger (constructing it) and named outcome (the I/O runs); untestable is not one of the four shapes |
+| Function > 40 lines; ≥ 4 parameters without an options object; boolean flag argument; class with two distinct responsibilities; `new ConcreteService()` bypassing DI | `minor` | The code is correct. The cost is to whoever reads or edits it next — that is exactly `minor` |
+| Poor naming; redundant comment; magic number; 20–40 line function; OCP/ISP smell; log-and-rethrow | `minor` | Same |
+| Stylistic opinion; a future issue with no current violation | `info` | Neither trigger nor a named maintenance cost |
+
+**Clean Code findings are `minor` by default.** A long function with a named
+responsibility split is a maintenance cost, not observable wrong behaviour, and
+`major` is reserved for findings that name a trigger and an outcome. This
+reviewer previously called a 41-line function `major` and thereby forced
+`REQUEST_CHANGES` on it; that is the exact mis-ranking the canonical rubric
+exists to stop.
 
 ---
 

package/src/gdskills/bundled/skills/review/review-core-boundaries/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: review-core-boundaries
+model_tier: deep
 description: |
   Use when reviewing shared core/infrastructure module changes for dependency
   direction, feature-boundary leakage, abstraction stability, composition,
@@ -45,9 +46,30 @@ If a more specific module reviewer also applies, run both.
 
 ---
 
+## Iron Laws
+
+### 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.
+
+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.
+
+---
+
 ## Orchestrated Review Contract
 
-When dispatched by `review-orchestrator`, follow the provided `reviewer-input.schema.json` payload. Return a `REVIEW_RESULT` object compatible with `skills/review-orchestrator/reviewer-finding.schema.json`, then a concise markdown summary. Keep findings evidence-based, include concrete `suggested_fix` for every blocker/major, and return `NEEDS_CONTEXT` instead of guessing when required context is missing.
+When dispatched by `review-orchestrator`, follow the provided `reviewer-input.schema.json` payload. Return a `REVIEW_RESULT` object compatible with `skills/review/review-orchestrator/reviewer-finding.schema.json`, then a concise markdown summary. Keep findings evidence-based, include concrete `suggested_fix` for every blocker/major, and return `NEEDS_CONTEXT` instead of guessing when required context is missing.
 
 ---
 
@@ -88,6 +110,16 @@ observation is theatre, not rigour.
 - **Fix**: move to domain module, invert dependency, or extract a truly shared abstraction
 ```
 
-Severity guidance: importing feature code into core or adding feature-specific public API is
-usually `major`; broad shared API breakage can be `blocker`.
+Severity comes from **Severity (canonical)** in `review-orchestrator/SKILL.md`.
+This reviewer keeps no rubric of its own; what follows is where its recurring
+conditions land under that rubric.
+
+| Condition | Severity | Why, under the canonical rubric |
+|---|---|---|
+| A core API change that breaks a named consumer at runtime | `blocker` | Crash at a named call site |
+| Importing feature code into core; adding feature-specific public API to core; inverted dependency | `major` | Named trigger (the import) and named outcome (the cycle or the leak), but structural — not one of the four shapes |
+| A generic helper whose names or types lean on one feature's language | `minor` | Works today; the cost is to the next module that needs it |
+| A blast-radius concern with no named consumer | `info` | Shared law 1 |
+
+"Broad blast radius" is not by itself a `blocker`. Name the consumer that breaks.
 

package/src/gdskills/bundled/skills/review/review-flow-graph/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: review-flow-graph
+model_tier: standard
 description: |
   Use when reviewing generic ReactFlow or graph-surface abstraction changes:
   public graph surface, store subclassing, layout lifecycle, internal helper
@@ -71,9 +72,30 @@ baseline.
 
 ---
 
+## Iron Laws
+
+### 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.
+
+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.
+
+---
+
 ## Orchestrated Review Contract
 
-When dispatched by `review-orchestrator`, follow the provided `reviewer-input.schema.json` payload. Return a `REVIEW_RESULT` object compatible with `skills/review-orchestrator/reviewer-finding.schema.json`, then a concise markdown summary. Keep findings evidence-based, include concrete `suggested_fix` for every blocker/major, and return `NEEDS_CONTEXT` instead of guessing when required context is missing.
+When dispatched by `review-orchestrator`, follow the provided `reviewer-input.schema.json` payload. Return a `REVIEW_RESULT` object compatible with `skills/review/review-orchestrator/reviewer-finding.schema.json`, then a concise markdown summary. Keep findings evidence-based, include concrete `suggested_fix` for every blocker/major, and return `NEEDS_CONTEXT` instead of guessing when required context is missing.
 
 ---
 
@@ -114,6 +136,15 @@ observation is theatre, not rigour.
 - **Fix**: concrete change aligned with the shared graph surface
 ```
 
-Severity guidance: breaking the public surface or bypassing base selection/layout lifecycle is
-usually `major`; performance regressions on large graphs can be `major` or `blocker`.
+Severity comes from **Severity (canonical)** in `review-orchestrator/SKILL.md`.
+This reviewer keeps no rubric of its own; what follows is where its recurring
+conditions land under that rubric.
+
+| Condition | Severity | Why, under the canonical rubric |
+|---|---|---|
+| A graph operation that hangs or exhausts memory at a stated node/edge count | `blocker` | Crash |
+| Breaking the public graph surface; bypassing base selection or layout lifecycle | `major` | Named trigger and outcome; a broken contract is not one of the four shapes |
+| A performance regression on large graphs, with the size that makes it a cost | `major` | Degradation, not an outage — see `review-performance` for the same boundary |
+| Internal helper reaching across a boundary with no observable consequence | `minor` | Correct today; the cost is to the next editor |
+| Surface concern with no named caller | `info` | Shared law 1 |
 

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

@@ -1,5 +1,6 @@
 ---
 name: review-frontend
+model_tier: standard
 description: "Use when a frontend review is requested, checking React component patterns, MobX state management (observer, actions, computed, reactions, lifecycle), View-Store boundaries, and TypeScript safety in changed frontend code. NOT for backend patterns, security vulnerabilities, performance bottlenecks, or cross-layer architecture."
 triggers:
   - "review frontend"
@@ -13,8 +14,9 @@ metadata:
   author: "MrCipherSmith"
   version: "1.1.0"
   category: "review"
+  compatible_harnesses: "cursor,codex,zed,opencode,claude"
+  stack_requires: "react,mobx"
 license: "MIT"
-compatibility: "cursor,codex,zed,opencode,claude"
 ---
 
 # Review: Frontend (React + MobX + TypeScript)
@@ -57,11 +59,42 @@ This skill consolidates what was previously split between `code-style-review` (f
 
 ## Iron Laws
 
-1. **Every observable mutation outside an action or `runInAction` is at minimum a `major` finding.** No exception for "small stores" or "simple assignments".
-2. **Missing `observer()` on a component that reads MobX observables is always a `blocker`.** The component will not react to state changes — this is a silent, runtime correctness bug.
-3. **An API call in a component is always a `blocker`.** API/IO belongs in private store methods, not in JSX, hooks, or event handlers within the component file.
-4. **`public` keyword on any class member is always an error.** The ESLint rule `@typescript-eslint/explicit-member-accessibility` with `"no-public"` forbids it.
-5. **Inter-store callbacks (`onChangeX`, `handleX`, `syncX`) without `private` are always a `major`.** Ask: "Is this called from JSX?" If no — it must be `private`.
+### 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.
+
+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.
+
+### Frontend / MobX laws
+
+These say what is **always reported**. What severity each carries is the
+conditions table under Finding Format, and it is the canonical rubric applied —
+not a second opinion.
+
+1. **Every observable mutation outside an action or `runInAction` is reported.**
+   No exception for "small stores" or "simple assignments".
+2. **Missing `observer()` on a component that reads MobX observables is
+   reported.** The component will not react to state changes — a silent runtime
+   correctness bug, and silence is exactly why nobody else will find it.
+3. **An API call in a component is reported.** API/IO belongs in private store
+   methods, not in JSX, hooks, or event handlers within the component file.
+4. **`public` on a class member is reported.** The ESLint rule
+   `@typescript-eslint/explicit-member-accessibility` with `"no-public"` forbids
+   it — so the machine already catches it, which is why it is `minor` here rather
+   than a merge gate.
+5. **Inter-store callbacks (`onChangeX`, `handleX`, `syncX`) without `private` are
+   reported.** Ask: "Is this called from JSX?" If no — it must be `private`.
 
 ---
 
@@ -114,7 +147,7 @@ Extract and note:
 - Any patterns explicitly declared as project standard — follow them, do NOT flag as violations
 - Any patterns explicitly declared as anti-patterns — flag them even if not in this skill's generic checklist
 
-**Resolution rule:** When a project CLAUDE.md pattern conflicts with this skill's generic checklist, the CLAUDE.md pattern wins — unless it violates an Iron Law.
+**Resolution rule:** When a project CLAUDE.md pattern conflicts with this skill's generic checklist, the CLAUDE.md pattern wins — unless it violates an Iron Law. It never overrides the canonical severity rubric: a project convention decides what is reported, not how merge-blocking it is.
 
 If no CLAUDE.md is found, proceed normally. CLAUDE.md is optional and non-blocking.
 
@@ -132,7 +165,7 @@ If no CLAUDE.md is found, proceed normally. CLAUDE.md is optional and non-blocki
 - [ ] Conditional reading of observables is still observable access — `if (store.isLoaded)` triggers tracking; wrapper is required regardless of conditionality
 
 Flags:
-- Component reads `store.*` or `useLocalObservable` result but is not wrapped in `observer` — **blocker**
+- Component reads `store.*` or `useLocalObservable` result but is not wrapped in `observer` — **major** (stale UI; not one of the four merge-blocking shapes)
 - `observer` applied inside another HOC wrapper instead of outside — **major**
 
 #### A2. MVVM Boundary (Business Logic in Store, Not Component)
@@ -143,7 +176,7 @@ Flags:
 - [ ] Computed/derived values MUST be `@computed` getters in the store, not inline derivations in the component body
 
 Flags:
-- `fetch()` / `axios` / `httpClient` call directly in component (hook or handler) — **blocker**
+- `fetch()` / `axios` / `httpClient` call directly in component (hook or handler) — **major** (layer violation; `review-architecture` rates the same condition `major`)
 - Business logic (conditionals, transformations, validation) inside a component event handler instead of a store method — **major**
 - Derived value computed inline in component that could be a `@computed` getter — **minor**
 
@@ -157,7 +190,7 @@ Flags:
 
 Flags:
 - `useEffect` calls `store.init()` or `store.loadX()` — **major**
-- `useEffect` contains `fetch()` or IO — **blocker** (API in component)
+- `useEffect` contains `fetch()` or IO — **major** (API in component)
 - `useEffect` contains business logic / state derivation — **major**
 - `useEffect` creates a subscription/timer/listener with no cleanup return — **major** (memory leak)
 
@@ -196,8 +229,8 @@ Flags:
 - [ ] `@observable.ref` is preferred for large external objects or objects that manage their own reactivity
 
 Flags:
-- `makeObservable(this)` missing from constructor — **blocker**
-- Observable state missing `@observable` decorator — **blocker**
+- `makeObservable(this)` missing from constructor — **major** (nothing is reactive; stale UI, not corrupted state)
+- Observable state missing `@observable` decorator — **major**
 - Derived value in plain method instead of `@computed` — **minor**
 
 #### B2. Member Ordering
@@ -229,7 +262,7 @@ Correct accessibility:
 Decision rule for inter-store callbacks: ask "Is this called from JSX or a React event handler?" If NO — it is `private`.
 
 Flags:
-- `public` keyword on any member — **blocker** (ESLint error)
+- `public` keyword on any member — **minor** (ESLint `no-public` already fails CI; a reviewer restating a lint rule is not a merge gate)
 - `onChangeX`, `onFireX`, `handleX`, `syncX` without `private` — **major**
 - Missing `private` on internal state or helper methods — **major**
 - Missing `private readonly` on injected dependencies — **minor**
@@ -243,7 +276,7 @@ Flags:
 Flags:
 - `IObservableArray` field reassigned instead of using `.replace()` — **major**
 - `ObservableMap` field reassigned instead of `.replace()` or `.merge()` — **major**
-- Observable mutation outside `runInAction` in async context — **blocker** (Iron Law 1)
+- Observable mutation outside `runInAction` in async context — **major**, or **blocker** where the interleaving can corrupt persisted state (frontend law 1)
 
 #### B5. Reactions and Disposers
 
@@ -276,7 +309,7 @@ Flags:
 - Public UI method missing `@action.bound` — **major**
 - Public helper method marked `@action.bound` but does not mutate state — **minor**
 - Public async action doing API/IO directly instead of delegating to private — **major**
-- State mutation after `await` outside `runInAction` — **blocker** (Iron Law 1)
+- State mutation after `await` outside `runInAction` — **major**, or **blocker** where the interleaving can corrupt persisted state (frontend law 1)
 - Missing `try/catch/finally` on private async method owning loading flags — **major**
 - `catch (err: any)` instead of `catch (err: unknown)` — **minor**
 
@@ -303,7 +336,7 @@ Flags:
 When two stores synchronize state in both directions, at least one direction MUST have an equality guard (`if (newValue !== currentValue)`) before writing to the other store. Without this, changes bounce indefinitely.
 
 Flags:
-- Bidirectional store sync without equality guard — **blocker**
+- Bidirectional store sync without equality guard — **blocker** (unbounded update loop: the render hangs)
 - Store A writes to Store B in a callback from Store B without `!==` check — **blocker**
 - Truthy guard (`if (value)`) on optional/nullable field instead of equality check in sync logic — **major**
 
@@ -315,7 +348,7 @@ Flags:
 
 Flags:
 - API call inside a public `@action.bound` method body — **major**
-- API call in a component (hook, handler, useEffect) — **blocker** (Iron Law 3)
+- API call in a component (hook, handler, useEffect) — **major** (frontend law 3)
 
 #### B10. Lifecycle Initialization and Disposal
 
@@ -540,14 +573,22 @@ STATUS: DONE_WITH_CONCERNS
 [List checklist sections with no findings, confirming they were checked]
 ```
 
-### Severity definitions
+### Where frontend conditions land
 
-| Severity | Meaning |
-|----------|---------|
-| `blocker` | Silent correctness bug or Iron Law violation; component will not behave correctly or store will corrupt state |
-| `major` | Pattern violation that will cause bugs under realistic usage or future changes |
-| `minor` | Convention deviation or defensive gap; does not cause immediate bugs but reduces maintainability |
-| `info` | Observation worth noting; no concrete bug in current code |
+Severity comes from **Severity (canonical)** in `review-orchestrator/SKILL.md`.
+This reviewer keeps no table of its own; what follows is where its recurring
+conditions land under that rubric, not a second rubric.
+
+| Condition | Severity | Why, under the canonical rubric |
+|---|---|---|
+| A store mutation that corrupts or loses persisted state | `blocker` | Data corruption |
+| A render path that throws on an input the change admits | `blocker` | Crash |
+| Missing `observer()` on a component that reads observables | `major` | Named trigger (the observable changes) and named outcome (the UI does not update). Stale UI is not a crash, data loss, vulnerability, or missing acceptance criterion |
+| Observable mutation outside an action or `runInAction` | `major` — `blocker` only where the interleaving can corrupt persisted state | Same wording as `review-logic` and `review-highload` for a race: the outcome decides |
+| API/IO call in a component | `major` | Layer violation. Identical to `review-architecture`'s rule for the same condition, which previously called it `major` while this file called it `blocker` |
+| `useState` for store-managed state; `useMemo` for a derived store value; a store constructed in the component body | `major` | Named trigger (a re-render) and named outcome (state lost or recreated) |
+| `public` on a class member; `useCallback` around a store method; a store created with `useMemo` instead of `useLocalObservable`; an unprivate inter-store callback | `minor` | The code behaves correctly. A lint rule that fails CI is caught by the machine, not by a reviewer, and the cost is to the next editor |
+| Observation with no concrete bug | `info` | Shared laws 1 and 2 |
 
 ---
 
@@ -557,11 +598,11 @@ Stop and re-read these rules if you are thinking:
 
 | Rationalization | Why it's wrong |
 |---|---|
-| "The store is small, no need for full observer wrapping" | Missing observer() is a blocker regardless of store size — Iron Law 2 |
-| "The mutation happens in a non-async method, so runInAction isn't needed" | Mutations outside action/runInAction are always at least major — Iron Law 1 |
-| "I'll mark the API call in component as minor to avoid friction" | API in component is always a blocker — Iron Law 3 |
-| "The `public` keyword is just a style issue, I'll call it minor" | It's an ESLint error that will fail CI — it is a blocker |
-| "This inter-store callback works fine as public" | Iron Law 5: if it's not called from JSX, it must be private |
+| "The store is small, no need for full observer wrapping" | Missing `observer()` is reported regardless of store size — frontend law 2. It is `major`, not `blocker`: stale UI is not one of the four shapes |
+| "The mutation happens in a non-async method, so runInAction isn't needed" | Mutations outside action/runInAction are always at least `major` — frontend law 1 |
+| "I'll mark the API call in component as minor to avoid friction" | API in a component is `major`, never `minor` — frontend law 3, and the same severity `review-architecture` gives it |
+| "The `public` keyword is just a style issue, I'll call it minor" | It is `minor` — but still reported. The linter fails CI on it, which is why a reviewer does not need to block merge on it too |
+| "This inter-store callback works fine as public" | Frontend law 5: if it is not called from JSX, it must be `private` |
 | "No spec compliance check needed for this skill" | Correct — this skill covers Stage 2 (code quality) only; spec compliance is handled by the orchestrator or review-logic |
 | "I can suggest adding useCallback everywhere for safety" | With MobX+observer, useCallback is rarely needed and adds noise; only flag when concretely justified |
 | "The bidirectional sync looks fine, no equality guard needed" | Bidirectional sync without equality guard is a blocker — infinite loop risk |
@@ -589,7 +630,7 @@ If the file does not exist or is not provided, proceed normally — context is o
 
 ## Orchestrated Review Contract
 
-When dispatched by `review-orchestrator`, follow the provided `reviewer-input.schema.json` payload. Return a `REVIEW_RESULT` object compatible with `skills/review-orchestrator/reviewer-finding.schema.json`, then a concise markdown summary. Keep findings evidence-based, include concrete `suggested_fix` for every blocker/major, and return `NEEDS_CONTEXT` instead of guessing when required context is missing.
+When dispatched by `review-orchestrator`, follow the provided `reviewer-input.schema.json` payload. Return a `REVIEW_RESULT` object compatible with `skills/review/review-orchestrator/reviewer-finding.schema.json`, then a concise markdown summary. Keep findings evidence-based, include concrete `suggested_fix` for every blocker/major, and return `NEEDS_CONTEXT` instead of guessing when required context is missing.
 
 ---