@olegkoval/agent-skills 1.43.1 → 1.45.0

package/plugins/olko-github-pr/skills/lekker-review/references/revmux/lenses/lekker-consistency.md

@@ -0,0 +1,76 @@
+---
+description: cross-layer consistency: one business rule implemented twice must agree, row by row
+---
+## Lens: lekker-consistency
+
+Review the change for **cross-layer consistency**: one business rule enforced in
+more than one place, where the places disagree.
+
+This is the defect class that survives every other lens. Each implementation is
+correct read on its own, each has its own tests, and the bug only exists in the
+gap between them. Nobody reads them side by side, so nobody sees it.
+
+### Step 1: find the rules implemented more than once
+
+A rule is duplicated when the same decision (allow/block, show/hide, include/
+exclude, retry/fail) is made in two code paths that can both run for the same
+input. The usual shapes:
+
+- a client-side guard and the server-side validator behind it (a checkout UI
+  extension and the Shopify Function, a form check and the API handler);
+- a UI filter and the query that feeds it;
+- a webhook handler and the cron reconciler that backfills the same state;
+- a feature flag read in two clients that must agree on the same gate;
+- a permission checked in a route guard and again in the service.
+
+Search the worktree (`{{WORKDIR}}`), not only the diff. The second
+implementation is very often a file this change never touched; that is exactly
+how the two drift apart.
+
+### Step 2: print the two decision tables side by side
+
+For every duplicated rule, build the table before judging anything. One row per
+input class, one column per implementation, cell = the decision that
+implementation makes:
+
+| Input | Layer A (`file:line`) | Layer B (`file:line`) |
+|---|---|---|
+| value present, active | allow | allow |
+| value present, inactive | block | block |
+| **value missing / undefined / empty** | **block** | **allow** |
+| gate disabled | allow | allow |
+
+Rows that must always appear, because they are where layers actually diverge:
+
+- the missing / `undefined` / `null` / empty-string input;
+- the not-applicable actor (a D2C shopper where the rule is B2B, an
+  unauthenticated caller, a shop with no config);
+- the gate or feature flag being off;
+- the error path (one layer fails open, the other fails closed).
+
+Put the real table in the finding. A reader who cannot see both columns cannot
+check your claim, and the table is the whole evidence.
+
+### Step 3: judge the divergence
+
+Any row where the two columns differ is a finding. Severity:
+
+- **critical**: the strict layer is the one that can be bypassed, or the
+  divergence blocks a legitimate action (a user who should be able to check out
+  cannot) or admits one that should be blocked.
+- **major**: the layers disagree but the authoritative layer is still correct,
+  so the visible effect is a confusing or wrong message rather than a wrong
+  outcome.
+
+Name which layer is authoritative and say so explicitly: the server-side,
+unbypassable one is the specification, and the advisory client-side one must
+match it. **A client layer that is STRICTER than the server is still a bug**, and
+the easy one to wave through, because it looks like extra safety. It is not: it
+blocks work the system allows, and the person hitting it has no way around a
+rule the server would have permitted.
+
+Also compare both tables against the acceptance criteria in `{{CONTEXT}}`. When
+an AC governs the same decision and one layer disagrees with it, quote the AC
+verbatim in the finding. When the AC and a scoping decision in `{{CONTEXT}}`
+disagree with each other, report that as its own finding, quote both, and do not
+pick a side; that contradiction is the author's call to make.

package/plugins/olko-github-pr/skills/lekker-review/references/revmux/lenses/lekker-conventions.md

@@ -0,0 +1,158 @@
+---
+description: deviations from Teifi's own codebase conventions — the "strong teammate" non-blocking lens
+---
+## Lens: lekker-conventions
+
+Review the change for deviations from Teifi's established codebase
+conventions and idioms. This is the "strong teammate" lens: the suggestions a
+senior Teifi engineer leaves — non-blocking, but they make the code match how
+the rest of the codebase is written. Look beyond the diff only for
+convention-specific precedent and reuse searches. Other lenses may inspect the
+runtime context they need for their own cross-file checks.
+
+Read `{{PROFILE}}` now, before forming any opinion — it carries the Teifi
+conventions text. Its §1 (naming matrix), §2 (comment policy), §5 (commit
+hygiene) and §6 (generated code) are yours — they are the house style, so a
+deviation needs NO codebase precedent beyond that file (the file IS the
+precedent; cite the section, e.g. "teifi-conventions §1 verbs").
+Everything else in this lens still requires a cited precedent from the code.
+
+Axes to cover:
+- Naming (teifi-conventions §1): every symbol the diff INTRODUCES against the
+  matrix — boolean without `is`/`has`, async I/O named `get`, a row lock or a
+  throw-on-miss or a cache read absent from the name (`…ForUpdate`,
+  `…OrThrow`, `…Cached`), a collidable component without its domain prefix, a
+  bare generic noun (`line`, `node`, `row`) where the domain has two variants in
+  scope. NEVER flag a boundary name (DB column, GraphQL/oRPC field, enum value,
+  route string, wire key) — renaming it breaks callers outside the diff.
+- Comments (teifi-conventions §2): one finding per over-commenting offender the
+  diff ADDED, with the deletion as the fix. Never a vague "too many comments",
+  never a pre-existing comment, never a lint/type pragma or a genuine
+  non-obvious "why".
+- Generated code (teifi-conventions §6): a changed `.sql` / `.graphql` /
+  `.json` schema / `prisma/schema.prisma` whose generated artifact is absent
+  from the diff (or the reverse) — major. Raise NO naming, comment, or
+  complexity finding inside a `generated/` directory. A hand-rolled `fetch` to
+  the Shopify Admin GraphQL endpoint instead of the genql client — major.
+- Commits (teifi-conventions §5): non-conventional or vague commit subjects, and
+  any Claude Code / assistant mention in the commit or PR text.
+- Type-system idioms:
+  * A hand-written interface/type that duplicates an existing Zod schema —
+    should be `z.infer<typeof zSchema>` so the schema stays the single source
+    of truth. (Grep for a matching z-schema in the same feature folder.)
+  * Raw `string` used for a Shopify GID or an entity id where a branded
+    `ID<'Customer'>` (or similar) type exists and is used elsewhere.
+  * A union typed as `as readonly string[]` / a hand-rolled `is...` guard where
+    a `z.enum([...])` + `z.infer` would give validation, narrowing, and the
+    options array in one declaration.
+  * An unnecessary `satisfies` / redundant type annotation the compiler already
+    infers.
+  * A GID validated/parsed inline where a shared helper exists (e.g.
+    `zNamespacedGid`). Grep the shared libs and the repo before asserting.
+- Reuse (search the worktree AND sibling Teifi repos before flagging):
+  * Inline fetch/client logic that should reuse — or be promoted into — a
+    shared client (e.g. a company-switcher client) that already exists or that
+    the codebase clearly wants.
+  * A util/helper that already exists elsewhere being re-implemented inline.
+  * A symbol defined locally that is (or should be) exported from a shared
+    module — "are we not exporting this somewhere?"
+- Consistency:
+  * Cache-key / composite-key separators that disagree with the repo's
+    prevailing choice (e.g. `:` vs `::`). Grep existing key-building code to
+    find the prevailing pattern, then flag the deviation.
+  * Ad-hoc error throwing where the repo has an idiom (e.g. `throw new
+    HttpError('...', 403)` instead of a bare string / generic Error).
+  * Naming/casing that breaks the convention used by sibling files.
+
+MANDATORY SWEEP — do this FIRST, before forming any opinion:
+
+The axes above are symptom-driven: they only fire once you already suspect a
+duplication. That is how a re-implemented helper slips through — nobody thinks to
+look. So run these enumerations mechanically, whether or not anything looks wrong.
+
+1. **Sibling sweep for every file the diff ADDS.** For each added file, list its
+   directory and read the exports of its neighbours. A helper that solves the same
+   problem is usually sitting in the same folder.
+
+   ```bash
+   REVIEW_CONFIG="{{CONTEXT}}/worktree.json"
+   WORKTREE="$(jq -er '.worktreePath | select(type == "string" and length > 0)' "$REVIEW_CONFIG")"
+   BASE_REV="$(jq -er '(.mergeBase // .baseRef) | select(type == "string" and length > 0)' "$REVIEW_CONFIG")"
+   REPO_ROOT="$(jq -er '.repoRoot | select(type == "string" and length > 0)' "$REVIEW_CONFIG")"
+   SIBLING_ROOT="$(dirname "$REPO_ROOT")"
+
+   git -C "$WORKTREE" diff --name-status "$BASE_REV"...HEAD | awk '$1=="A"{print $2}' |
+     while IFS= read -r added_file; do
+       added_dir="$WORKTREE/$(dirname "$added_file")"
+       ls -la "$added_dir"                         # what already lives beside it
+       grep -rn "^export " "$added_dir"/*.ts "$added_dir"/*.tsx 2>/dev/null |
+         grep -v -F -- "$added_file"
+     done
+   grep -rn "^export " "$SIBLING_ROOT" --include='*.ts' --include='*.tsx' \
+     --exclude-dir=node_modules 2>/dev/null
+   ```
+
+   A new `foo/bar-thing.ts` next to an existing `foo/thing.ts` is a finding waiting
+   to happen. Read the neighbour, do not just note its name.
+
+2. **New-symbol sweep.** For every function/const the diff exports, search the repo
+   for something that already does that job, by BEHAVIOUR not just by name. Names
+   rarely match; behaviour does.
+
+   ```bash
+   git -C "$WORKTREE" diff --unified=0 "$BASE_REV"...HEAD | \
+     grep '^+' | grep -E 'export (function|const) '             # collect new symbols
+   # then for each, search by what it does, e.g. a locale normaliser:
+   grep -rln "toLowerCase()\|normalize\|isoCode\|split('-')" "$WORKTREE" \
+     --include='*.ts' --include='*.tsx'
+   ```
+
+   Pick 2 or 3 behavioural keywords from the new function's body and grep those.
+   Reviewing the diff alone cannot catch this.
+
+3. **State what you swept.** In your output, name the directories you listed and the
+   behavioural greps you ran, even when they found nothing. A sweep that is not
+   reported did not happen, and the next reviewer cannot tell "no duplication exists"
+   from "nobody looked".
+
+HARD RULES:
+- Only raise a finding when the better pattern PROVABLY ALREADY EXISTS. Cite it:
+  the file:line where the helper/type/convention lives, or the sibling file that
+  does it the idiomatic way. If you cannot find a concrete precedent, DROP the
+  finding — "this would be nicer as X" on taste alone is not allowed.
+- Every finding must still trace to a `+` line in the diff (the deviation must
+  be code this change added/changed). The supporting precedent may live outside the
+  diff; the deviation may not.
+- These are suggestions, not blockers. Do not inflate severity. Report each as
+  `file:line — <deviation> (precedent: <file:line of the existing pattern>)`.
+- ONE EXCEPTION to non-blocking: if the re-implementation DIVERGES in behaviour
+  from the helper it duplicates, that is not a style nit, it is two spellings of
+  the same value that disagree, and it belongs on lekker-quality's severity
+  scale rather than this lens's. Diff the two implementations before deciding:
+  same inputs, same outputs? If a real input produces different results, say so
+  explicitly and give the input.
+
+To find precedents, you may run:
+
+```bash
+grep -rn "<symbol or pattern>" "$WORKTREE" --include='*.ts' --include='*.tsx'
+find "$SIBLING_ROOT" \( -name "*.ts" -o -name "*.tsx" \) ! -path "*/node_modules/*" \
+  | xargs grep -l "<symbol>" 2>/dev/null | head
+```
+
+Always include *.tsx. Extension and frontend code lives in .tsx, so a search that
+omits it silently reports "no precedent exists" for whole directories.
+
+A mined record of what other bots (Greptile / Gemini / CodeRabbit) have
+commented on in this repo may be present under `{{CONTEXT}}`. Use it as a prior,
+not as a checklist: a high count means "frequently raised here", not "correct" —
+never raise a finding because a bot once said it, only because it is true here.
+
+Rules:
+- Report file:line — description with a precedent citation. No positive
+  observations. No taste-only suggestions.
+- Quote the verbatim offending line(s) — never paraphrased, never reconstructed
+  from memory — and give a concrete drop-in fix, or when the fix is
+  architectural, a minimal skeleton plus one sentence on what else must change.
+- A finding you cannot quote and cannot fix is a finding you have not proven —
+  drop it instead.

package/plugins/olko-github-pr/skills/lekker-review/references/revmux/lenses/lekker-implementation.md

@@ -0,0 +1,76 @@
+---
+description: correctness, scalability and integration issues — Teifi's GQL-1 hard rule included
+---
+## Lens: lekker-implementation
+
+Review the change for correctness, scalability, and integration issues.
+
+Axes to cover:
+- Business Logic / AC coverage: for each acceptance criterion available in
+  `{{CONTEXT}}` (a ticket's AC list, when present), mark met / partial / missing.
+  Scope creep is also worth flagging.
+  Decide each AC against the code that RUNS, not against the diff. Use the
+  worktree (`{{WORKDIR}}`) to follow the AC through its runtime path into files
+  the diff never touched, and specifically:
+  (a) Find what invokes the new code and on what trigger. New code that nothing
+      calls satisfies nothing, however correct its body is.
+  (b) For an AC with a timing, cadence or SLA component, name the trigger's real
+      frequency (the cron expression, the poll interval, the webhook) and compare
+      that number against the AC. A reaper on a daily cron cannot meet a two-hour
+      SLA.
+  (c) For an AC about a failure mode (crash, OOM, timeout, network loss), confirm
+      the handling is reachable under that failure. A killed process never reaches
+      a `finally` block, a shutdown hook, or the tail of a long-running function.
+  An AC can fail with every added line correct, because the defect is what the
+  diff left alone. That is a finding, not an absence of one.
+- Binding scoping decisions: when `{{CONTEXT}}` names a resolved flag from the
+  ticket's Dev Scoping Session, a diff that contradicts it is major (critical
+  when it changes external behaviour or data shape); quote the decision text.
+- Scalability: N+1 queries, missing pagination, unbounded in-memory
+  collections, missing rate-limit handling, cron jobs without overlap guard,
+  missing DB indexes for new query patterns.
+- Time/Space Complexity: O(n²) where linear exists, large payloads in memory,
+  sort/dedup on large arrays that could be done at DB level.
+- Integration Contracts: Shopify API misuse, BC API assumptions, webhook
+  idempotency, external API pagination not handled.
+- GraphQL pagination (GQL-1): for every GraphQL query in the diff that uses a
+  nodes connection (`nodes { ... }`):
+  (a) Check that `pageInfo { hasNextPage endCursor }` is present alongside nodes — if missing, critical.
+  (b) Check that all pages are fetched (a loop or recursion using endCursor) — a single-page fetch is a bug, critical.
+  (c) Check the page size: must be 250 (Shopify max). If any other size is used without a code comment explaining why, flag as major.
+  Title any critical finding under this axis `[GQL-1] ...`.
+- Feature-flag rollout (Reflag repos ONLY): first check the repo actually uses
+  Reflag — a `package.json` (any depth, excluding node_modules) depending on
+  `@reflag/node-sdk` or `@teifi-digital/reflag-client`. If it does not, SKIP this
+  axis entirely and raise nothing; a repo with no flag client cannot act on the
+  finding. Where it does apply, ask whether the change should ship behind a flag:
+  (a) a client should validate it before everyone sees it; (b) it changes data
+  shape or what gets written; (c) it touches orders, money, or fulfilment; (d) it
+  cannot be verified without real client data or volume. Do NOT raise it for pure
+  UI/copy with no data change, a bug fix that is strictly better and obviously
+  correct, internal/admin-only surfaces, or work fully covered by tests and
+  verifiable in staging. Tie-breaker: if you would not be comfortable fixing it
+  forward at 2am, it needs a flag. Name which of (a)-(d) applies.
+  Severity: major at most, usually minor — this is a rollout judgement call, not
+  a defect. NEVER title this with a bracketed hard-rule tag (that would force
+  critical and imply a policy violation). Never invent a concrete flag key as
+  though it exists: flag keys must be confirmed against Reflag, so say a flag is
+  needed without naming one.
+  Also raise as a structural concern (severity major) when a diff BOTH adds a
+  column/table AND changes what is read or written — the SOP requires splitting
+  that into expand / migrate / read-switch / contract PRs. Name the split.
+
+GQL-1's full rule text lives in `{{PROFILE}}` — read it there before applying it.
+
+Rules:
+- Every finding must trace to a `+` line in the diff, with one exception: an
+  unmet AC whose defect lives in code the diff did not touch. Anchor that one to
+  the unchanged file:line that had to change, and say in the description why the
+  unchanged line is the defect. That line may be an unchanged one — do not drop
+  an unmet AC for lack of a quotable added line.
+- Report file:line — description. No positive observations.
+- Quote the verbatim offending line(s) — never paraphrased, never reconstructed
+  from memory — and give a concrete drop-in fix, or when the fix is
+  architectural, a minimal skeleton plus one sentence on what else must change.
+- A finding you cannot quote and cannot fix is a finding you have not proven —
+  drop it instead.

package/plugins/olko-github-pr/skills/lekker-review/references/revmux/lenses/lekker-quality.md

@@ -0,0 +1,87 @@
+---
+description: quality, security and data-integrity issues — Teifi's TS-1/TS-2 hard rules included
+---
+## Lens: lekker-quality
+
+Review the change for quality, security, and data-integrity issues.
+
+Axes to cover:
+- Data Integrity: missing transactions on multi-step writes, optimistic
+  concurrency without locking, partial-failure with no rollback, silent data
+  loss in batch loops.
+- Security: SQL/command injection, auth bypass, missing permission checks,
+  IDOR, secrets in logs, webhook signature not verified.
+  When the diff touches a controller, a route, or an auth decorator, do NOT hand-roll the
+  decorator grep. Use the `route-auth-map` skill, which already does exactly this and prints
+  method/path/controller/guards plus an explicit unguarded-endpoint section. If the Skill tool
+  is unavailable to you, read `~/.claude/skills/route-auth-map/SKILL.md` and follow its steps.
+  Compare the map before and after the diff: a route that gains a handler but no guard, or
+  loses `@Authenticated`/`@Permission`, is critical.
+- Error Handling: unhandled promise rejections, empty catch blocks, missing
+  retries on transient failures, no dead-letter for failed jobs.
+- Catch-block exit paths: when the diff adds or edits a branch inside a `catch`,
+  enumerate EVERY way control leaves that block - each early return, each
+  rethrow, and the fall-through - and say what the client sees on each. A new
+  branch that changes what gets logged or reported, while leaving a rethrow or
+  fall-through reachable for the same condition, is a finding: the error is now
+  silent AND still escapes. Do not accept "it reports correctly" as covering the
+  block; the report and the control flow are separate claims.
+- Schema/Migration: NOT NULL without default, rename without two-step,
+  pgtyped queries invalidated, Prisma client out of sync.
+- Naming/Typos: wrong casing convention, mixed conventions in same scope,
+  misspelled identifiers (these are bugs-in-waiting).
+- Derived-value consistency: when the diff introduces a transform of some input
+  (normalise, trim, lowercase, parse, clamp, default), grep EVERY other use of
+  that raw input in the same scope and check they all go through the transform.
+  Half-applied transforms are a classic near-miss: the value is normalised at the
+  call site but the raw one is still used in a React dependency array, a cache
+  key, a log line, an equality check, or a second call site. Two spellings of the
+  "same" value then disagree. Enumerate the uses; do not eyeball the hunk.
+
+  ```bash
+  grep -n "<rawIdentifier>" <file>     # every use, then confirm each is intended
+  ```
+
+- Env vars: dead vars, renamed without migration, wrong fallback operator
+  (?? vs ||), type mismatch, leaked in logs.
+- TypeScript type safety (TS-1): flag every type cast (`as X`, `<X>expr`)
+  and every use of `any`. Test files: only flag blatantly omitted types
+  (e.g. `any[]` on a clearly-typed list). All others: critical. Quote the
+  cast, explain the correct type, show the fix. Ask if they're Harry Potter.
+  Title the finding `[TS-1] ...`.
+- No JavaScript files (TS-2): if the diff adds any `.js` file to a non-Liquid
+  theme repo, flag as critical — must be `.ts`. Title the finding `[TS-2] ...`.
+- Dependency changes. Skip this axis entirely unless the diff touches
+  `package.json`, a lockfile, or a vendored dependency. Where it applies:
+  (a) A version bump is a behaviour change nobody in this PR wrote. If neither
+      the PR body nor a commit message cites the changelog or migration notes,
+      that is major: semver is a promise the maintainer may not have kept,
+      and a "patch" can carry a behavioural change.
+  (b) A bulk bump of several unrelated packages in one PR is major. When
+      it breaks the build you have lost which package did it. The fix is to
+      split it per package, or per genuinely related group.
+  (c) A `package.json` dependency change with no matching lockfile change in the
+      same diff, or a lockfile change with no `package.json` change and no
+      explanation, is critical: the lockfile is what actually ships.
+  (d) A new direct dependency that duplicates something already in the stack is
+      major. Name the existing thing that already solves it.
+  Raise NO naming, comment, complexity, or TS-1 finding inside a lockfile or a
+  `node_modules` path.
+
+TS-1 and TS-2 are Teifi hard rules: their text is defined in full in `{{PROFILE}}`
+(read it there before applying either). A finding for one of them MUST have its
+title start with the bracketed tag, e.g. `[TS-1] ...` or `[TS-2] ...`, so the
+caller can recognize it as a policy violation rather than an ordinary finding.
+
+CI status, Sentry signals, and existing reviews may be present in `{{CONTEXT}}` —
+read what is there before forming an opinion, and skip anything that is absent
+rather than treating its absence as a finding.
+
+Rules:
+- Every finding must trace to a `+` line in the diff.
+- Report file:line — description. No positive observations.
+- Quote the verbatim offending line(s) from the diff — never paraphrased, never
+  reconstructed from memory — and give a concrete drop-in fix, or when the fix
+  is architectural, a minimal skeleton plus one sentence on what else must change.
+- A finding you cannot quote and cannot fix is a finding you have not proven —
+  drop it instead of reporting it as a minor observation with no evidence.

package/plugins/olko-github-pr/skills/lekker-review/references/revmux/lenses/lekker-simplification.md

@@ -0,0 +1,63 @@
+---
+description: over-engineering and DRY violations, plus Teifi's debug-artifact hygiene table
+---
+## Lens: lekker-simplification
+
+Review the change for over-engineering and DRY violations.
+
+Look for:
+- Copy-paste logic: identical blocks that differ only in a constant — flag
+  for extraction.
+- Parallel implementations: two functions doing the same thing — one should
+  call the other.
+- Unnecessary abstraction inversion: private helper called exactly once, adds
+  no reuse — should be inlined.
+- Over-engineered control flow: nested ternaries / promise chains that could
+  be plain if/else or async/await.
+- Config spread: same magic constant defined in multiple files.
+- Debug artifacts and hygiene: apply the fixed severity table in §3 of
+  `{{PROFILE}}` (the Teifi conventions section) — `debugger` and
+  `.only`/`fit`/`fdescribe` are critical, an added `console.log`/`console.debug`
+  in production code and a hardcoded URL are major, an unreferenced
+  TODO/FIXME and a >3-line commented-out block are minor. Those severities
+  are fixed: do not soften them, and only flag occurrences the diff ADDED.
+- Wrapper that adds nothing, factory for single implementation, layer-cake
+  anti-pattern (handler → service → repo with no logic in any layer).
+- Feature flags always on/off, fallback that can never trigger, dual
+  implementations where old has no callers.
+- Relocated complexity: a refactor that moves code without reducing the number
+  of concepts a reader must hold to follow it. Count them before and after. If
+  the count is unchanged, the restructuring did not simplify anything, and the
+  finding is that a cheaper move was available (deleting a branch, a mode, or a
+  layer outright, rather than re-centralising the same logic). Major when
+  the change is sold as a cleanup or refactor, minor otherwise.
+- Feature logic in a shared module: feature-specific behaviour added to a
+  general-purpose util, a shared client, or a base class. The branch belongs in
+  the package that owns the concept. Name the owning layer in the fix.
+- Dead code this diff orphans: when the diff replaces or reroutes something,
+  grep the worktree for remaining callers of what it superseded (the old helper,
+  the old component, a now-unreferenced constant, a flag that can no longer be
+  false). Enumerate what is now unreachable. NEVER propose a silent deletion:
+  the fix lists the orphans and asks the author to confirm removal.
+  Minor, or major when the dead path is still reachable from production code.
+
+Only flag where duplication or complexity creates a real maintenance risk or
+bug surface — not aesthetic preference.
+
+When you flag a structural problem, name the move, not just the smell: replace a
+chain of conditionals with a typed model or an explicit dispatcher, collapse
+duplicate branches into one flow, separate orchestration from business logic,
+move feature logic into the package that owns it, reuse the canonical helper
+instead of a near-duplicate, delete a pass-through wrapper. Prefer the remedy
+that removes moving pieces over one that spreads the same complexity around. A
+finding that says "this is complex" without naming the restructuring is not
+actionable: name the move or drop the finding.
+
+Rules:
+- Every finding must trace to a `+` line in the diff.
+- Report file:line — description. No positive observations.
+- Quote the verbatim offending line(s) — never paraphrased, never reconstructed
+  from memory — and give a concrete drop-in fix, or when the fix is
+  architectural, a minimal skeleton plus one sentence on what else must change.
+- A finding you cannot quote and cannot fix is a finding you have not proven —
+  drop it instead.

package/plugins/olko-github-pr/skills/lekker-review/references/revmux/lenses/lekker-test-quality.md

@@ -0,0 +1,172 @@
+---
+description: whether tests actually catch bugs — mutation-slip analysis, mock smell, Teifi test conventions
+---
+## Lens: lekker-test-quality
+
+Review the change with a strict focus on test quality. This is NOT about
+coverage numbers — it is about whether the tests actually catch bugs.
+
+Step 1 — Inventory the tests. Read the diff at `{{SCOPE}}`. List every test
+file/spec added or modified. If no test files are in the diff, note that and
+continue to axis (f) below.
+
+Step 2 — For each changed test file, read the full file from `{{WORKDIR}}`.
+
+Step 3 — Evaluate each of these axes:
+
+a) Meaningful assertions vs. smoke tests
+   - Does the test verify a specific outcome, or just that no exception was
+     thrown / a function returned truthy?
+   - Are assertions on the correct thing? (e.g. checking the return value vs
+     a side-effect that is the actual goal of the operation)
+   - Are there tautological assertions that are always true regardless of the
+     implementation? (e.g. `expect(true).toBe(true)`,
+     `expect(x).toBeDefined()` when x is always defined by construction)
+
+b) Condition coverage
+   - Is the happy path tested?
+   - Are failure / error paths tested? (invalid input, external API error,
+     empty collection, null/undefined, 0 or negative numbers, pagination edge
+     cases, missing env vars)
+   - For every new if/else or switch in the changed business logic, is each
+     branch exercised by at least one test case?
+
+c) Regression tests
+   - If the change fixes a bug (the ticket mentions a bug, or the diff
+     contains "fix" language), is there a regression test that would have
+     caught the original bug? Flag if absent.
+   - If the change adds a new feature, are the known edge cases of that feature
+     tested?
+
+d) Mutation-slip analysis (mental mutation testing)
+   For the most critical assertions in the test suite, ask: would a simple
+   mutation in the production code slip through undetected?
+
+   Consider these mutation classes:
+   - Off-by-one: `> N` changed to `>= N`
+   - Operator flip: `&&` to `||`, `===` to `!==`
+   - Missing null/undefined guard: remove a `?? default`
+   - Wrong variable: using `a` where `b` was intended
+   - Return-value swap: returning the wrong field from an object
+   - Early-return removed: a guard clause deleted
+
+   For each mutation class relevant to the changed business logic, determine
+   whether at least one test assertion would catch it. Summarize as a short
+   paragraph: "Mutations that would slip through: ..." or "No obvious
+   mutation-slip gaps found."
+
+e) Test isolation and reliability
+   - Do tests share mutable state across cases without resetting between runs
+     (a beforeEach that does not clean up)?
+   - Are there tests that depend on execution order or global singletons?
+   - Could a test make a real network/DB call in CI (flaky)? The fix is a
+     simple injected fake at the boundary, not blanket module mocking — see
+     axis (g).
+   - Are async tests properly awaited? (floating promises, missing `await` on
+     `expect().resolves`, unhandled rejections)
+
+f) Test-to-code ratio signal
+   If the diff adds > 50 lines of new business logic with zero new or modified
+   test files, flag it explicitly. Then check whether existing test files
+   already cover the new code paths:
+   ```bash
+   find <workdir> -name "*.test.ts" -o -name "*.spec.ts" | \
+     xargs grep -l "<key changed symbol>" 2>/dev/null | head -5
+   ```
+   Report whether existing coverage closes the gap or not.
+
+g) Mock smell — test the behavior, not the way it's built
+   (House standard: Notion "To mock or not to mock" —
+   https://app.notion.com/p/teifi/To-mock-or-not-to-mock-36ff8ed0f7db80f09495d174e3b86cd6)
+   Flag tests coupled to *how* the code is built rather than *what* it does for
+   the user. For each smell, do NOT just criticize: give the concrete no-mock
+   refactor. The default fix is almost always the same shape — pull the logic
+   into a pure function (functional core) and test that directly, leaving a thin
+   shell covered by a few real integration tests.
+
+   - Mocking IO just to reach logic: a GraphQL/fetch/DB client mocked only so a
+     test can read a computed value back. It couples to the query shape AND the
+     markup while barely testing the logic, and silently rots as the real
+     dependency drifts from the mock. This applies just as much on the backend
+     as in a component: mocking a service client (e.g. `vi.mocked(epicorClient)`
+     returning a canned async generator/array) just to reach a reassembly loop
+     or a multi-stream join is the same smell as mocking `fetch` in a component.
+     → Extract the computation into a pure function over plain data and test
+       that with literals (no mocks, no render, no mocked client). Cover
+       fetch-and-wire once with a real integration test. For streaming/paging
+       code specifically: a shared `collect()`/reassembly helper should be a
+       pure function of `AsyncGenerator<T[]> → Promise<T[]>` (or similar) fed a
+       plain fake generator in its own test — never a mocked client — and any
+       call-site logic that combines multiple streams (parallel joins, chunked
+       batching) should be its own pure function tested the same way.
+   - Spying on calls / asserting call shape: `toHaveBeenCalledWith`,
+     `toHaveBeenCalledTimes`, a `vi.fn()` used as a probe. Asserts *how* a
+     function was called, freezing batching/page-size/call-count in place even
+     when the output is identical.
+     → Assert the output, never the call log. If a boundary is genuinely
+       needed, inject a simple fake (a plain function returning canned data),
+       not a spy.
+   - Mocking a component to read its props back (re-emitting props as `data-*`
+     attributes, then asserting on them): the assertions are about the mock, and
+     break on a component swap or prop rename that changes nothing a user sees.
+     → Pull the logic (pagination, display state) into a pure function over
+       plain values — e.g. `paginate(items, page, pageSize)` — and assert the
+       value it returns.
+   - Mocking a query hook (`useQuery` / a `use-X` hook) to hand a component
+     canned data: re-tests React Query's own plumbing and couples to the hook's
+     return shape.
+     → Keep the `queryFn` as IO (integration-tested); move the transform into a
+       pure function wired through React Query's `select` option, and unit-test
+       that pure function with plain data.
+   - Asserting implementation details: that a component is memoized, that a
+     specific child renders, that work happens through a fixed sequence of
+     calls.
+     → Delete the assertion; assert the user-visible behavior instead.
+
+   When a mock IS the right call, do NOT flag it: a real IO boundary that must
+   be exercised where a fake is impractical, non-determinism that must be pinned
+   (time, randomness, injected network failure), or a dependency that genuinely
+   cannot run in the test environment. The tell for a good mock: the behavior
+   under test only exists because the boundary did something (e.g. a retry
+   banner that appears only when the fetch rejects). Even then, prefer an
+   injected simple fake over a module-level spy, and assert what the user sees.
+
+h) Teifi test conventions
+   Read `{{PROFILE}}` and apply its §4 (test conventions) to every test file in
+   the diff: `__tests__/` placement beside the source, `.test.ts` vs
+   `.test.tsx`, English-sentence test names, `describe` nesting <= 2,
+   `afterEach(cleanup)`, `retry: false` on the test QueryClient (major — its
+   absence hangs the suite on a failing query), the getByRole → getByLabelText
+   → getByText → getByTestId priority, module-boundary mocking, `safeParse` for
+   Zod schemas, and the typed `it.each` matrix with AC tags plus the
+   exhaustiveness assertion whenever behaviour depends on 3+ independent inputs.
+   A `vi.mock('@lib/common/…')` inside `common/` is major, not style: the
+   alias resolves only from `web/`, so the mock silently does nothing and the
+   test passes against the real module. Quote the line, give the relative path
+   as the fix.
+   A comment explaining WHY a test exists (a captured past bug, a subtle
+   contract) is sanctioned — never flag it as over-commenting.
+
+Report each per-line issue as:
+`test-file:line — <concise description of the gap or weakness>`
+
+For every mock-smell finding from axis (g), append the no-mock fix on the next
+line as `→ Fix: <pure-function / simple-fake refactor in one line>`. A
+criticism without a fix is incomplete.
+
+Report the mutation-slip analysis as a single paragraph under a
+"**Mutation-slip risk:**" heading — not as line items.
+
+Rules:
+- Every per-line finding must trace to test code in the diff, OR to business
+  logic added in the diff that has no test coverage at all.
+- Report problems only. No praise for tests that meet the bar.
+- If no test files are changed AND no existing tests cover the new code paths,
+  report: "No test coverage for new code paths."
+- Quote the verbatim offending line(s) — never paraphrased, never reconstructed
+  from memory. When the finding IS the absence of a test, there is no test line
+  to quote: quote the untested production line(s) from the diff instead, and
+  give the test that should exist as the fix. Never drop a "no coverage"
+  finding just because nothing bad is written down — absence is the finding.
+- A finding you cannot quote and cannot fix (outside the no-coverage case
+  above) is a finding you have not proven — drop it instead.