@olegkoval/agent-skills 1.44.0 → 1.45.1

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

@@ -1,18 +1,18 @@
 ---
-description: whether tests actually catch bugs — mutation-slip analysis, mock smell, Teifi test conventions
+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.
+coverage numbers - it is about whether the tests actually catch bugs.
 
-Step 1 — Inventory the tests. Read the diff at `{{SCOPE}}`. List every test
+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 2 - For each changed test file, read the full file from `{{WORKDIR}}`.
 
-Step 3 — Evaluate each of these axes:
+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
@@ -60,7 +60,7 @@ e) Test isolation and reliability
      (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
+     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)
@@ -75,12 +75,12 @@ f) Test-to-code ratio signal
    ```
    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" —
+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
+   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.
 
@@ -96,7 +96,7 @@ g) Mock smell — test the behavior, not the way it's built
        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
+       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`,
@@ -110,7 +110,7 @@ g) Mock smell — test the behavior, not the way it's built
      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
+       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
@@ -135,7 +135,7 @@ 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
+   `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
@@ -145,17 +145,17 @@ h) Teifi test conventions
    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.
+   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>`
+`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.
+"**Mutation-slip risk:**" heading - not as line items.
 
 Rules:
 - Every per-line finding must trace to test code in the diff, OR to business
@@ -163,10 +163,10 @@ Rules:
 - 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
+- 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.
+  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.
+  above) is a finding you have not proven - drop it instead.

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

@@ -37,6 +37,4 @@ worktree; "merged" means two revmux findings described one mechanism.
 ## 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/plugins/olko-github-pr/skills/lekker-review/references/revmux/profile.md

@@ -12,29 +12,29 @@ and lekker-deep review profiles. It concatenates the two files lekker-review its
 
 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)
+### 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.
+- 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
+### 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
+### 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.
+- 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-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.
+- 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)
 
@@ -49,7 +49,7 @@ belongs in *this* repo and not a sibling repo.
 | `*-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.
+**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`).
 
@@ -64,12 +64,12 @@ Include: spec quote with correct path, which repo to target, and the risk (wrong
 | 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 |
+| 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.
+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)
+### 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,
@@ -90,12 +90,30 @@ 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 —
+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).
 
+### CONS-1 — One rule, two implementations, must agree
+
+When a change enforces the same business rule in two places that can both run
+for the same input — a client-side guard and the server-side validator behind
+it, a UI filter and its query, a webhook handler and the cron that backfills the
+same state — the two must make the same decision for every input class.
+
+Build both decision tables and compare them row by row, including the
+missing/undefined input, the not-applicable actor, the flag-off case and the
+error path. The server-side, unbypassable layer is authoritative; the advisory
+layer must match it. A client layer that is STRICTER than the server is a bug,
+not extra safety: it blocks work the system allows.
+
+Severity: critical when the divergence blocks a legitimate action or admits one
+that should be blocked; major when the authoritative layer is still right and
+only the message is wrong. Detail and the reporting format live in the
+`lekker-consistency` lens.
+
 ### Stack context to inform the review:
 
 - **Backend:** TypeScript, Node.js, Express, Prisma, pgtyped, PostgreSQL
@@ -103,20 +121,20 @@ be split into expand / migrate / read-switch / contract PRs (`important`, name t
 - **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) —
+- **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.**
+**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
+  presence before assuming a split - do not assume the `*-integrations` pattern always
   means backend-only.
 
 **Step 1g action**: Before flagging a placement mismatch, run:
@@ -136,7 +154,7 @@ that alone is not precedent for new GIC extensions. Flag when the repo has no
 # 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
+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.
@@ -150,7 +168,7 @@ 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
+diff, expensive later - but a rename is still a cost, so leave conforming
 names alone.
 
 ### Values
@@ -166,7 +184,7 @@ names alone.
 | count | `Count` suffix | `lineCount` |
 | casing | camelCase values · PascalCase types/components · `CONSTANT_CASE` constants | |
 
-### Verbs — one per job, chosen by cost + purity
+### 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 ·
@@ -177,14 +195,14 @@ 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
+### 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
+without saying so in its name is a finding - that surprise is exactly what the
 next caller will miss.
 
 ### React & types
@@ -201,7 +219,7 @@ next caller will miss.
 `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**
+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
@@ -210,7 +228,7 @@ 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
+column" finding is a false positive - say the boundary name is bad and leave
 it to a human if it matters.
 
 ---
@@ -220,25 +238,25 @@ it to a human if it matters.
 **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
+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
+- **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
+- 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
+- **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
+- **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
+- **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
@@ -251,7 +269,7 @@ gotcha, is noise. Code is type-checked; prose is not.
 
 ---
 
-## 3. Hygiene & debug artifacts — severity is fixed, do not soften
+## 3. Hygiene & debug artifacts - severity is fixed, do not soften
 
 Scan `+` lines only (added by this diff; pre-existing occurrences are out of
 scope).
@@ -260,7 +278,7 @@ scope).
 |---|---|
 | `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 |
+| `.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 |
@@ -268,7 +286,7 @@ scope).
 | 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.
+repo has a logger idiom - then cite it.
 
 ---
 
@@ -287,13 +305,13 @@ does. Each is an `idiomatic` finding with the corrected code as the `fix`.
 - **`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.
+  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
+  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
@@ -304,28 +322,28 @@ does. Each is an `idiomatic` finding with the corrected code as the `fix`.
   (`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).
+  *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
+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
+- Vague subjects (`fix`, `update`, `wip`, `changes`, `stuff`) - flag, recommend
   a rewrite.
-- Many WIP commits — recommend a squash before merge, in one line, once.
+- 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
+## 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
@@ -338,10 +356,10 @@ source changes and its generated artifact does not (or vice-versa), that is an
 | `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
+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
+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/plugins/olko-github-pr/skills/lekker-review/references/revmux/profiles/lekker-deep.md

@@ -1,16 +1,17 @@
 ---
-description: Teifi deep review — lekker-medium plus revmux's own bugs+impl second opinion, claude-only
+description: Teifi deep review: lekker-medium (incl. cross-layer consistency) 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: consistency,       lenses: [lekker-consistency],                         color: white}
   - {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
+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`,
@@ -22,15 +23,15 @@ Do not run tests, builds or the linter - all of that was done before the review
 
 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
+- `{{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,
+- `{{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
+- `{{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.
+- `{{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
@@ -41,18 +42,18 @@ inventing the missing context.
 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.
+- **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.
+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
+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.

package/plugins/olko-github-pr/skills/lekker-review/references/revmux/profiles/lekker-medium.md

@@ -1,15 +1,16 @@
 ---
-description: Teifi medium-depth review — four claude agents, adversarial second pass, claude-only
+description: Teifi medium-depth review: five claude agents incl. cross-layer consistency, adversarial second pass, 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: consistency,       lenses: [lekker-consistency],                         color: white}
   - {name: adversarial,       lenses: [adversarial], model: claude/sonnet:high,      color: yellow}
 stages: {synthesis: claude/sonnet:medium, verify: claude/sonnet:medium}
 ---
 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
+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`,
@@ -21,15 +22,15 @@ Do not run tests, builds or the linter - all of that was done before the review
 
 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
+- `{{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,
+- `{{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
+- `{{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.
+- `{{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
@@ -40,18 +41,18 @@ inventing the missing context.
 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.
+- **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.
+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
+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.

package/plugins/olko-github-pr/skills/lekker-review/scripts/fixtures/house-rules.md

@@ -1,11 +1,11 @@
 # Fixture house rules
 
-### TS-1 — Type safety
+### TS-1 - Type safety
 
-### TS-2 — No JavaScript files
+### TS-2 - No JavaScript files
 
-### GQL-1 — Complete pagination
+### GQL-1 - Complete pagination
 
-### PR-1 — Ticket-prefixed titles
+### PR-1 - Ticket-prefixed titles
 
-### SEC-7 — Never log session tokens
+### SEC-7 - Never log session tokens

package/plugins/olko-github-pr/skills/lekker-review/scripts/fixtures/revmux-report.json

@@ -11,7 +11,7 @@
       "body": "Two concurrent writers can both pass the guard and insert a fulfillment row.",
       "fix": "Take a row lock on the order before the check-then-insert.",
       "sources": ["quality+impl"],
-      "lenses": ["lekker-quality"],
+      "lenses": ["lekker-quality", "lekker-implementation"],
       "verdict": "confirmed"
     },
     {

package/plugins/olko-github-pr/skills/lekker-review/scripts/revmux-engine.sh

@@ -143,6 +143,7 @@ REVMUX_OUT="$OUT"
 set +e
 revmux --task "$TASK" --run "$RUN" --profile "$PROFILE_NAME" \
     --workdir "$WORKDIR" --tasks-dir "$TASKS_DIR" --config-dir "$CONFIG_DIR" \
+    --tools=Read,Grep,Glob,WebFetch,WebSearch \
     --no-tui > "$REVMUX_OUT"
 CODE=$?
 set -e

package/plugins/olko-obsidian/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-obsidian",
   "description": "Keep an Obsidian vault in sync with work: PR sync, task rollover, morning routine.",
-  "version": "1.44.0",
+  "version": "1.45.1",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-product/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-product",
   "description": "Take a product idea to a shippable build: MVP passes, full-stack scaffolds, launch plans.",
-  "version": "1.44.0",
+  "version": "1.45.1",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-reflection/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-reflection",
   "description": "Look back and improve: self-critique, retrospectives, performance review, rapid learning.",
-  "version": "1.44.0",
+  "version": "1.45.1",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-release/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-release",
   "description": "Ship a release: semantic-release setup, changelogs, store listing copy, release-day routine.",
-  "version": "1.44.0",
+  "version": "1.45.1",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-skill-meta/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-skill-meta",
   "description": "Author and maintain agent skills and the AI toolchain itself.",
-  "version": "1.44.0",
+  "version": "1.45.1",
   "author": {
     "name": "Oleg Koval"
   },