@olegkoval/agent-skills 1.43.0 → 1.44.0

package/adapters/claude/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.

package/adapters/claude/olko-github-pr/skills/lekker-review/references/revmux/phase4-comparison.md

@@ -0,0 +1,42 @@
+# Phase 4: revmux engine on real PRs
+
+One row per live `--engine revmux` run. Numbers come from revmux `stats` via
+`scripts/revmux-adapter.mjs`; USD is the `pricing.json` list-price placeholder
+(`verified: false`, output price applied to every token, synth+verify unpriced),
+and every run so far went through the Max subscription, so USD is a relative
+signal only. "Confirmed" means the main loop kept the finding after reading the
+worktree; "merged" means two revmux findings described one mechanism.
+
+| Date | PR | Depth | Wall | Tokens | USD est. | revmux findings | Kept | Re-severity | Hard-rule re-promotions | Merged | False positives |
+|---|---|---|---|---|---|---|---|---|---|---|---|
+| 2026-09-09 | evi-integrations #544 | medium (auto) | 15m40s | 12,604,506 | $169.53 | 4 | 3 (1 C / 2 I) + obs | 1 important → critical (lost role grants, watermark written before post-pass) | 0 | 0 | 0 |
+| 2026-09-09 | evi-integrations #537 | deep (auto, *.sql) | 11m08s | 11,245,064 | $141.61 | 4 | 3 (0 C / 2 I / 1 idiomatic) + obs | none | 0 | 1 (#1 reactivation + #4 guard removal → one Important) | 0 |
+
+## Notes per run
+
+### #544
+
+- revmux under-rated the watermark ordering bug as important; the main loop
+  raised it to Critical after tracing `executeSyncStrategy` writing the CUSTOMER
+  watermark before the role post-pass.
+- One finding referenced `getShopFlag`, which does not exist in this repo;
+  rewritten to an env toggle with Reflag as the policy target. Class: fix code
+  invented from another repo's helper. Worth a lens note.
+- Depth medium, so verify ran on Criticals only; revmux's own verify stage
+  covered all four.
+
+### #537
+
+- Two of four findings were the same mechanism seen from two lenses (bugs,
+  adversarial). Synthesis did not merge them; the main loop did.
+- All four confirmed against the worktree. The idiomatic one (comment
+  narrating deleted code) is exactly the teifi-conventions §2 class.
+- Reactivation and soft-delete files are outside the diff, so the main
+  finding could only be anchored on the sync-path signal it replaces.
+
+## Still open
+
+- Same PRs through the default `workflow` engine for a side-by-side (Oleg-driven).
+- Read-only enforcement: revmux default `--tools` includes Bash; prompt-enforced
+  only. `--tools=Read,Grep,Glob,WebFetch,WebSearch` override not yet applied.
+- Adapter: price synth + verify once revmux reports a per-model split.

package/adapters/claude/olko-github-pr/skills/lekker-review/references/revmux/profile.md

@@ -0,0 +1,347 @@
+# Teifi project profile
+
+This is the Teifi project profile, handed to revmux as `{{PROFILE}}` for the lekker-medium
+and lekker-deep review profiles. It concatenates the two files lekker-review itself reads as
+`teifi-rules.md` (hard rules, always critical) and `teifi-conventions.md` (soft house style).
+
+---
+
+# Teifi rules, taxonomy, and stack context
+
+## Teifi Hard Rules (apply during review AND development)
+
+These rules are non-negotiable. Violations are always **Critical** findings regardless of depth or other filters. Apply them when developing a feature or bugfix, not only during review.
+
+### TS-1 — Type safety (TypeScript only)
+
+- No type casting (`as X`, `<X>expr`) — ask them if they are Harry Potter for casting spells.
+- No `any` — except in test files where types are genuinely hard to express; even there, blatantly omitted types (e.g. `any[]` on a known shaped list) must be flagged.
+- Every finding: quote the cast/`any`, explain the correct type, show the fix.
+
+### TS-2 — No JavaScript files
+
+- No `.js` files may be added to any Teifi integrations repo.
+- Exception: Liquid themes (Online Store 2.0 Shopify themes) may contain `.js`.
+- If the PR adds a `.js` file to a non-theme repo, flag it as Critical: must be converted to `.ts`.
+
+### GQL-1 — GraphQL NodesConnection pagination
+
+- Every query that uses a nodes connection (`nodes { ... }`) **must** include `pageInfo { hasNextPage endCursor }` alongside the nodes.
+- All remaining pages **must** be fetched — a single-page fetch with no loop/recursion is a bug.
+- The page size **must** be `250` (Shopify max). If any other value is used, a code comment explaining why is required; if no comment exists, flag it.
+
+### PR-1 — PR title must be prefixed with Linear ticket(s)
+
+- PR title must start with `[GIC-123]` (or the relevant project prefix) in square brackets.
+- Go through the commit history: if merged PRs or commits reference Linear tickets in square brackets (`[GIC-123]`), all of them must appear comma-separated in the current PR title (e.g. `[GIC-123,GIC-124]`).
+- This is a **blocking** finding: display a prominent `⛔ CANNOT MERGE` warning and recommend the correct title prefix. Confidence score is not affected — this is a process rule, not a code quality signal.
+
+### 1g. Repo placement check (Teifi multi-repo projects only)
+
+For any PR in a `Teifi-Digital/` repo, verify that the code being changed
+belongs in *this* repo and not a sibling repo.
+
+**Teifi repo taxonomy:**
+
+| Repo pattern | Purpose |
+|---|---|
+| `*-live` (e.g. `gic-live`, `evi-live`) | Shopify app: customer account extensions, app blocks, storefront extensions, Polaris admin UI |
+| `*-integrations` (e.g. `evi-integrations`; see the GIC exception below) | Backend ERP sync: cron jobs, orchestrator, BC/Sage/Jitterbit/ROI API clients |
+| `teifi-digital` / shared libs | Cross-project utilities, shared types |
+
+**Note:** `gic-integrations` has an `extensions/` folder containing legacy/reference extensions (e.g. `link-account-customer`), but **new customer account extensions for GIC should target `gic-live`** per project specs. Always check the Linear/Notion ticket for explicit repo path — don't infer from existing repo contents alone.
+
+**Action:** If the diff adds a new Shopify extension and the PR targets `*-integrations`, check the Linear/Notion spec for the explicit target directory. If the spec names `*-live`, flag it as a **Critical** placement error (`## 🏠 Wrong Repo`).
+
+Include: spec quote with correct path, which repo to target, and the risk (wrong Shopify Partner app, extension not published to correct store).
+
+## Notes for Teifi / evi-integrations
+
+### Standing coding rules (apply during development and review)
+
+| Rule | What | When to flag |
+|---|---|---|
+| TS-1 | No type casts (`as X`), no `any` | Critical; test files lenient on genuine unknowns only |
+| TS-2 | No `.js` files in integrations repos | Critical; Liquid themes exempt |
+| GQL-1 | nodes connections need `pageInfo`, all pages fetched, size=250 | Critical if pageInfo/pagination missing; Important if size≠250 without comment |
+| PR-1 | PR title must start with `[TICKET-NNN]`; include all commit-referenced tickets | Blocking — ⛔ CANNOT MERGE warning |
+| FLAG-1 | Reflag repos only: risky change should ship behind a feature flag | Non-blocking; `important` at most, usually `observation`. Never a `rule:` tag |
+
+These apply equally when you are writing a feature or bugfix — not only in review.
+
+### FLAG-1 — Ship behind a feature flag (Reflag repos only)
+
+Applies ONLY where a `package.json` (any depth, excluding `node_modules`) depends on
+`@reflag/node-sdk` or `@teifi-digital/reflag-client`. Elsewhere there is no flag client,
+so the finding is unactionable and must not be raised.
+
+Flag it when any of these hold:
+- a client should validate it before everyone sees it
+- it changes data shape or what gets written
+- it touches orders, money, or fulfilment
+- it cannot be verified without real client data or volume
+
+Just ship it when: pure UI/copy with no data change; a bug fix that is strictly better
+and obviously correct; an internal/admin-only surface; fully covered by tests and
+verifiable in staging.
+
+Tie-breaker: would you be comfortable being the one to fix this forward at 2am?
+Yes → ship it. No → flag it.
+
+Deliberately NOT blocking, unlike TS-1/GQL-1/PR-1: whether something needs a flag is a
+rollout judgement, not a correctness violation, and a blocking comment on every
+borderline diff trains people to ignore the signal. Never invent a concrete flag key —
+keys must be confirmed against Reflag, so say a flag is needed without naming one.
+
+Related: a diff that BOTH adds a column/table AND changes what is read or written must
+be split into expand / migrate / read-switch / contract PRs (`important`, name the split).
+
+### Stack context to inform the review:
+
+- **Backend:** TypeScript, Node.js, Express, Prisma, pgtyped, PostgreSQL
+- **Frontend:** React, Shopify Polaris, Vite
+- **Shopify:** REST Admin + GraphQL Admin, Webhooks, Shopify Functions, genql
+- **External APIs:** Business Central (OAuth2, rate-limited), Salesforce GraphQL, ROI
+- **Infra:** Docker Compose locally; environment-var–driven cron syncs via `orchestrator.ts`
+- **Type gen pipeline:** pgtyped (SQL→TS), genql (GraphQL→TS), json2ts (schemas→TS) —
+  check that generated files are regenerated when their sources change
+- **MCPs available:** Linear, Slack, Notion, Shopify Dev docs, Harvest, Sentry
+
+### Repo taxonomy (for Step 1g placement check)
+
+**Per-project repo structure varies — always verify before flagging.**
+
+- For **EVI project**: `evi-integrations` = backend ERP sync only; `evi-live` = Shopify app (extensions, Polaris UI).
+- For **GIC project**: `gic-integrations` owns the ERP backend sync and retains
+  legacy/reference Shopify extensions. New GIC customer account extensions belong
+  in `gic-live`; do not treat the legacy `extensions/` folder as placement precedent.
+- For other projects (`rsl-*`, `elmt-*`, etc.): check the repo's `extensions/` folder
+  presence before assuming a split — do not assume the `*-integrations` pattern always
+  means backend-only.
+
+**Step 1g action**: Before flagging a placement mismatch, run:
+
+```bash
+gh api "repos/<REPO_SLUG>/git/trees/HEAD" 2>/dev/null | python3 -c "
+import sys,json; t=json.load(sys.stdin).get('tree',[]); print([f['path'] for f in t if f['path']=='extensions'])
+"
+```
+
+If `extensions/` exists in the target repo, placement may be intentional, but
+that alone is not precedent for new GIC extensions. Flag when the repo has no
+`extensions/` folder, or when a GIC spec targets the new extension to `gic-live`.
+
+---
+
+# Teifi soft conventions (styling, naming, comments, tests, hygiene)
+
+Companion to `teifi-rules.md`. Those are the four HARD rules (TS-1, TS-2,
+GQL-1, PR-1) — always Critical. This file is the house style the Teifi
+plugin skills enforce during development (`teifi-dev:code-review`,
+`rename-pass`, `comment-stripper`, `unit-test-best-practices`). A review that
+misses them lets the same nits come back from the human reviewer.
+
+Severity ceiling: everything here is **idiomatic** unless a row says otherwise.
+Cite a precedent from the codebase where the row asks for one, and never
+inflate a style deviation into Critical.
+
+---
+
+## 1. Naming matrix (source: `teifi-dev` rename-pass agent)
+
+Flag a name the diff INTRODUCES that breaks a row. Renaming is cheap in the
+diff, expensive later — but a rename is still a cost, so leave conforming
+names alone.
+
+### Values
+
+| Kind | Convention | Example |
+|---|---|---|
+| boolean | `is` prefix, no negatives (`has`/`can`/`should` for possession/permission/policy) | `isFrozen` |
+| array | plural noun (value plural, type stays singular) | `variantIds` |
+| keyed lookup | `…ById` suffix | `toneByStatus` |
+| id | `Id` / `Ids` suffix | `shipmentId` |
+| timestamp | `At` suffix | `scheduledAt` |
+| duration | unit suffix | `timeoutMs` |
+| count | `Count` suffix | `lineCount` |
+| casing | camelCase values · PascalCase types/components · `CONSTANT_CASE` constants | |
+
+### Verbs — one per job, chosen by cost + purity
+
+`get` cheap/sync · `fetch` async I/O · `create` new persisted entity ·
+`build` assembles in memory (pure) · `derive` pure value from existing state ·
+`parse` raw → typed · `format` value → display string · `update` change a
+persisted entity · `validate` returns validity · `assert` throws · `ensure`
+idempotently makes state hold.
+
+A `getX` that does network I/O is a finding (`fetchX`). A `createX` that
+mutates an existing row is a finding (`updateX`).
+
+### Effect affixes — put the surprise in the name
+
+`…OrThrow` · `…OrDefault` · `upsert` · `…ForUpdate` (row lock) ·
+`…SkipLocked` · `try…` (returns result, doesn't throw) · `with…`
+(acquire→run→release) · `…Sync` · `…Cached` · `unsafe…`.
+
+A function that takes a row lock, throws on miss, or returns a cached value
+without saying so in its name is a finding — that surprise is exactly what the
+next caller will miss.
+
+### React & types
+
+- React: `use` hook · `handle` (impl) / `on` (prop) · `Props` type · `with` HOC
+  · components PascalCase and **domain-prefixed when collidable**
+  (`AdjustmentStatusBadge`, not `StatusBadge`).
+- Types: `Input` / `Output` · `Result` (ok/err) · `Schema` (Zod) ·
+  `Brand<string,'X'>` for ids · PascalCase noun, no `I-` prefix, never
+  pluralize a type.
+
+### Bare generic nouns
+
+`line`, `item`, `node`, `record`, `entry`, `group`, `row`, `value`, `key` are
+findings when the surrounding domain has two or more qualified variants in
+scope (arrival line vs receipt line; source node vs target node). Qualify with
+the domain role — variables, params, fields, type aliases, **type params**
+(`TLine` → `TReceiptLine`), and the functions built on the noun.
+
+### NEVER flag a rename at a boundary
+
+DB table/column names (and any `Row`/`Dto` mirroring them), GraphQL / oRPC /
+OpenAPI contract fields, enum string values, route strings, wire/JSON keys.
+Something outside the diff reads them. The app-layer alias may be renamed
+(`createdAt @map("created_at")`); the boundary name may not. A "rename this
+column" finding is a false positive — say the boundary name is bad and leave
+it to a human if it matters.
+
+---
+
+## 2. Comment policy (source: `teifi-dev` comment-stripper + code-review Cat. 5)
+
+**Default: a comment should not exist.** It earns its place only by saying
+something the code *cannot*, and then in as few words as possible. Flag each
+offending comment the diff ADDED as its own `idiomatic` finding with the
+deletion as the `fix` — never a vague "too many comments". Pre-existing
+comments are out of scope.
+
+Flag a comment that:
+
+- restates the next line (`// increment counter` over `counter += 1`);
+- narrates a step or captions a block ("first we fetch, then we map…");
+- **narrates a whole function or type** — JSDoc restating a well-named
+  signature, its params, or its return shape. A doc comment earns its place
+  only for a non-obvious *contract*;
+- explains obvious syntax or a well-known API;
+- repeats a rationale stated elsewhere in the diff (keep ONE canonical place);
+- is changelog/AI noise — ticket IDs (`EVI-123`), person names, multi-paragraph
+  "why we chose X" essays. A single `@see EVI-123` JSDoc tag is fine;
+- **references what the reader cannot see** — a removed line or a prior
+  approach ("no longer using the old Y"). Source shows what the code *is*;
+- **documents invisible coupling** — "ordered this way because some other code
+  does X". The fix is clearer structure, not a comment enshrining it;
+- **says what a name or type could say** — then the code should carry it (this
+  is a naming finding per §1, not a comment to keep).
+
+KEEP (do not flag): an external-system quirk, an ordering/concurrency
+constraint, a bug workaround, a footgun, a "looks wrong but is correct
+because…" causal chain, a directive, a license header, and every lint/type
+pragma (`eslint-disable`, `@ts-expect-error`, `prettier-ignore`).
+
+Heuristic: a comment about as long as the code it sits on, naming no real
+gotcha, is noise. Code is type-checked; prose is not.
+
+---
+
+## 3. Hygiene & debug artifacts — severity is fixed, do not soften
+
+Scan `+` lines only (added by this diff; pre-existing occurrences are out of
+scope).
+
+| Artifact | Severity |
+|---|---|
+| `console.log(` / `console.debug(` added to non-CLI production code | important |
+| `debugger;` | critical |
+| `.only` on a test (`it.only`, `describe.only`, `fit(`, `fdescribe(`) — silently skips the rest of the suite | critical |
+| new `TODO:` / `FIXME:` / `HACK:` / `XXX:` with no ticket reference | idiomatic |
+| commented-out code block > 3 lines | idiomatic |
+| hardcoded URL / endpoint that belongs in an env var | important |
+| hardcoded magic number that should be a named constant | idiomatic |
+| unreachable code after `return`/`throw` | important |
+
+`console.error`/`console.warn` on a real error path is not a finding unless the
+repo has a logger idiom — then cite it.
+
+---
+
+## 4. Test conventions (source: `teifi-dev:unit-test-best-practices`)
+
+These are on top of the mutation/mock analysis the test-quality agent already
+does. Each is an `idiomatic` finding with the corrected code as the `fix`.
+
+- **Placement:** tests live in `__tests__/` **next to** the source file.
+  `.test.ts` for pure logic, `.test.tsx` when JSX is needed. A test parked in a
+  top-level `test/` dir or beside the source without `__tests__/` is a finding.
+- **Names read as English sentences:** `'returns false when name is null'`, not
+  `'should return false'`.
+- **`describe` nesting max 2 levels;** flat `it()` blocks are fine for small
+  functions. Grouping that adds no clarity is a finding.
+- **`afterEach(cleanup)`** in every RTL test file.
+- **`new QueryClient({ defaultOptions: { queries: { retry: false } } })`** in
+  every hook/component test wrapper. Missing `retry: false` silently hangs the
+  test on a failing query — flag it as `important`, not idiomatic.
+- **Query priority:** `getByRole` → `getByLabelText` → `getByText` →
+  `getByTestId` (last resort only). A `getByTestId` where a role query works is
+  a finding.
+- **Mock paths are RELATIVE, never the `@lib/common` alias.** The alias
+  resolves only from `web/`; inside `common/` it is silently ignored and the
+  mock has no effect — the test then passes against the real module. Flag any
+  `vi.mock('@lib/common/…')` inside `common/` as `important`.
+- **Mock at the module boundary,** not `vi.spyOn(mod, '_internal')`.
+- **Zod schemas:** test via `safeParse` and assert `result.success`, not
+  try/catch around `parse`.
+- **Matrix tests:** when behaviour depends on 3+ independent boolean/enum
+  inputs, drive `it.each` from a typed matrix, tag each row with the AC it
+  verifies, and include the exhaustiveness assertion
+  (`expect(matrix).toHaveLength(N * M * K)`). A hand-picked subset of a
+  combinatorial space is a coverage-gap finding.
+- **Comment the non-obvious scenario:** a test capturing a past bug explains
+  *why* (this is a sanctioned comment — never flag it under §2).
+
+---
+
+## 5. Commit & PR hygiene
+
+Beyond PR-1 (hard rule). All `idiomatic` — a squash fixes them and they never
+block.
+
+- Conventional commits: `<type>(<scope>): <description>` with type in
+  `feat|fix|refactor|test|docs|chore|style|perf|build|ci`; description
+  lowercase, imperative, no trailing period.
+- Vague subjects (`fix`, `update`, `wip`, `changes`, `stuff`) — flag, recommend
+  a rewrite.
+- Many WIP commits — recommend a squash before merge, in one line, once.
+- Never mention Claude Code / the assistant in commit or PR text; a
+  `Co-Authored-By: Claude` trailer or "Generated with Claude Code" footer in
+  the commit log is a finding.
+
+---
+
+## 6. Generated code — check the source, not the artifact
+
+The Teifi type-gen pipeline means several files must move together. When a
+source changes and its generated artifact does not (or vice-versa), that is an
+`important` finding:
+
+| Source changed | Artifact that must be regenerated |
+|---|---|
+| `services/db/queries/*.sql` | `services/db/queries/generated/` (pgtyped) |
+| `services/gql/queries/*.graphql` | `services/gql/queries/generated/queries.ts` (genql) |
+| `schemas/*.json` | `schemas/generated/` (json2ts) |
+| `prisma/schema.prisma` | a migration in `prisma/migrations/` + Prisma client |
+
+Never review the *content* of a generated file as if it were hand-written — no
+naming, comment, or complexity findings inside `generated/`. Review the source.
+
+Related hard convention (project CLAUDE.md): Shopify Admin API calls go through
+the genql client (`gql.<file>.<query>.run(graphql, vars)`) — a hand-rolled
+`fetch` to `/admin/api/…/graphql.json` is an `important` finding even for a
+one-off probe.

package/adapters/claude/olko-github-pr/skills/lekker-review/references/revmux/profiles/lekker-deep.md

@@ -0,0 +1,82 @@
+---
+description: Teifi deep review — lekker-medium plus revmux's own bugs+impl second opinion, claude-only
+model: claude/sonnet:medium
+agents:
+  - {name: quality+impl,      lenses: [lekker-quality, lekker-implementation],       color: cyan}
+  - {name: simpl+conventions, lenses: [lekker-simplification, lekker-conventions],   color: magenta}
+  - {name: tests,             lenses: [lekker-test-quality, tests],                  color: green}
+  - {name: adversarial,       lenses: [adversarial], model: claude/sonnet:high,      color: yellow}
+  - {name: bugs+impl,         lenses: [bugs, impl],                                  color: blue}
+stages: {synthesis: claude/opus:medium, verify: claude/sonnet:high}
+---
+You are one reviewer on a panel. Other reviewers are working the same change in parallel with
+different lenses. You never see their findings and must not guess at them — report what your own
+lenses find.
+
+This review is **read-only**. You may read files and run read-only commands such as `git diff`,
+`git log` and `rg`. Do not modify, delete, move, stage or commit anything, and do not write a file
+through a shell redirect. Report what you find; changing it is the caller's job, never yours.
+Do not run tests, builds or the linter - all of that was done before the review and passed.
+
+## Where the context lives
+
+Every item below is a **path**, not the text it names. Read the file or directory before you start.
+
+- `{{SCOPE}}` — what is under review and the command that produces the diff. Read this first and run
+  that command yourself.
+- `{{GOAL}}` — what the change is trying to achieve.
+- `{{PROFILE}}` — Teifi's own rules and conventions. Where they disagree with your general taste,
+  they win. This is also where the hard-rule text (TS-1, TS-2, GQL-1, PR-1) and the Teifi
+  conventions (naming matrix, comment policy, hygiene severities, test conventions) live in full.
+- `{{CONTEXT}}` — a directory of supporting material: ticket text, design notes, spec excerpts, CI
+  status, Sentry signals, existing review comments.
+- `{{WORKDIR}}` — run every command from here.
+
+Any of these may read `none provided`. That is not an error and not something to work around: the
+caller supplied nothing for it, so calibrate severity generically to that extent rather than
+inventing the missing context.
+
+## Severity bar
+
+No nitpicking. Critical and major findings are reserved for things that could cause bugs, outages,
+data loss, security incidents, or real performance problems at scale.
+
+- **critical** — a bug, an outage, data loss, a security hole, or a real performance problem at scale.
+- **major** — wrong behavior, or a broken contract a caller executes against.
+- **minor** — a real, contained defect.
+
+Style preference and taste alone are never a finding. Anything you cannot place on that bar is not
+a finding — leave it out.
+
+## Hard-rule findings are policy, not a runtime question
+
+Findings titled `[TS-1]`, `[TS-2]`, `[GQL-1]`, or `[PR-1]` are Teifi's own policy violations,
+defined in full in `{{PROFILE}}`. Confirm one when the quoted code shows the pattern the rule
+names — a cast, an `any`, a `.js` file outside a theme repo, a missing `pageInfo`/pagination, a PR
+title missing its ticket prefix. Never rate a hard-rule finding by its runtime impact and never mark
+it immaterial for lack of one: the rule itself is the standard, and violating it is always critical,
+independent of whether it happens to fail at runtime today.
+
+## Reporting
+
+Apply every lens you carry, in full, and tag each finding with the lens that raised it.
+
+- Point at a specific file and line. A finding with no location cannot be verified.
+- State the failure concretely: the input or state, and what goes wrong because of it.
+- Report the confidence you actually have, not the confidence that keeps the finding alive.
+- Say when a problem is pre-existing rather than introduced by the change under review.
+- Do not report one problem twice under two lenses. Report it once and name both lenses on it.
+
+## What not to report
+
+Silence beats a finding the reader has to disprove. Do not report:
+
+- a defect on a line this change did not touch, unless the change is what makes it reachable
+- anything a linter, compiler or type checker catches. All of them ran before the review and passed
+- a lint or vet rule the code silences deliberately, with the directive visible
+- a missing test, missing doc or general-quality observation the project's own rules do not ask for
+- a nitpick a senior engineer reading this diff would not raise
+- a behaviour change that is plainly the point of the change
+
+Pre-existing problems are the one exception: report them, and say so, so the reader can weigh them
+separately from what the change introduced.