reviewer-harness 1.15.0 → 1.16.0

package/README.md

@@ -12,7 +12,7 @@ One sync to bind them all,
 and in your codebase, protect them.
 ```
 
-![version](https://img.shields.io/badge/version-1.14.0-blue)
+![version](https://img.shields.io/badge/version-1.16.0-blue)
 ![License](https://img.shields.io/badge/License-MIT-yellowgreen)
 ![node](https://img.shields.io/badge/node-%3E%3D18-brightgreen)
 ![dependencies](https://img.shields.io/badge/dependencies-0-brightgreen)
@@ -139,7 +139,7 @@ reviewer-harness status
 Expected output (version number varies):
 
 ```
-Harness : reviewer-harness v1.14.0
+Harness : reviewer-harness v1.16.0
 Target  : /path/to/your/project
 Runtimes:
   - opencode → .opencode/instructions.md
@@ -187,7 +187,7 @@ Expected output when everything is fine:
 
 `validate` checks for empty or duplicate rules and scans the config for leaked API keys and tokens — secrets must never be synced into instruction files (they would leak into Git).
 
-**Step 3 — Add the skills you want.** Pick from the 27 bundled skills (full list below):
+**Step 3 — Add the skills you want.** Pick from the 28 bundled skills (full list below):
 
 ```bash
 reviewer-harness skills add safe-editing
@@ -237,12 +237,12 @@ npx reviewer-harness skills add no-hallucination
 A skill is a playbook: a short, checkable set of rules for one job (safe editing, API security, UI taste, debugging, and so on), distilled from real, reputable sources — not generic advice. Every rule cites its source.
 
 ```bash
-reviewer-harness skills list            # see all 27 bundled skills (+ which are enabled)
+reviewer-harness skills list            # see all 28 bundled skills (+ which are enabled)
 reviewer-harness skills add <name>      # install into the project and enable it in the config
 reviewer-harness skills remove <name>   # disable it in the config and remove it
 ```
 
-All 27 bundled skills (v1.14.0):
+All 28 bundled skills:
 
 | Skill | What it does |
 |---|---|
@@ -255,7 +255,7 @@ All 27 bundled skills (v1.14.0):
 | `api-security` | 14 API security rules — apply to every backend endpoint you build or review. |
 | `ux-edge-states` | 10 UX states beyond the happy path — empty, loading, error, offline, success. |
 | `owasp-top10` | OWASP Top 10 web security risks — the industry standard check before shipping. |
-| `backend-performance` | 10 backend performance rules from nodebestpractices and system-design-primer. |
+| `backend-performance` | 19 backend performance rules from nodebestpractices, system-design-primer, the PostgreSQL concurrency docs, and the OWASP Business Logic cheat sheet. |
 | `devops-basics` | 12 DevOps rules from nodebestpractices — Docker, graceful shutdown, health checks, logging. |
 | `motion-design` | Animation principles from GSAP (GreenSock) — easing, sequencing, stagger, performance. |
 | `frontend-performance` | Frontend performance rules from the Front-End Checklist — animations, resource hints, budgets, lazy loading. |
@@ -264,7 +264,7 @@ All 27 bundled skills (v1.14.0):
 | `audit-team` | Run an 8-agent parallel audit — 5 skill specialists plus 3 area agents — report-only, no edits. |
 | `ub-mode` | Uncle Bob mode — Clean Code discipline from Robert C. Martin: TDD first, CRAP < 10. |
 | `design-taste-frontend` | Anti-slop design taste from Leonxlnx/taste-skill — layout, palettes, type, heroes, copy ban lists. |
-| `ui-ux-pro-max` | Full UI/UX audit from nextlevelbuilder/ui-ux-pro-max-skill — 224 checkable guidelines across 10 categories. |
+| `ui-ux-pro-max` | Full UI/UX audit from nextlevelbuilder/ui-ux-pro-max-skill — 222 checkable guidelines across 10 categories. |
 | `vengeance-ui` | Modern animated React components from VengeanceUI — 79 copy-paste components across 9 families. |
 | `brainstorming` | Find out what you actually want — and why — before anything gets built. Design doc first, approval first. |
 | `writing-plans` | Turn an approved spec into a bite-sized TDD implementation plan. |
@@ -273,6 +273,7 @@ All 27 bundled skills (v1.14.0):
 | `instruction_registers` | Name the user's target and action registers before building, pushing, or planning, and ask one clarifying question when they are ambiguous. |
 | `verify_provider_claims` | Check a provider's live documentation or the user's verified setup before asserting its current availability, free tier, pricing, endpoints, or retired status. |
 | `verify_publish_install_surface` | Verify a published version on each surface the user can see (commit/tag, registry, installed file) before claiming it is installed or live. |
+| `playwright-cli` | Browser automation and real web-app testing for coding agents, from Microsoft's Playwright CLI — drive the app, turn the session into Playwright tests, attach screenshot evidence. |
 
 Enabled skills render below the rules in every instruction file — and sync also generates a **slash command** for each one (`.opencode/commands/<name>.md` and `.claude/commands/<name>.md`), so every enabled skill appears in the `/` menu of OpenCode and Claude, ready to invoke on a specific task: `/safe-editing`, `/no-hallucination`, and so on.
 
@@ -400,7 +401,7 @@ Requires Node.js 18+ (no dependencies). Run these inside your project — every
 
 | Command | What it does |
 |---|---|
-| `reviewer-harness skills list` | List all 27 bundled skills (+ which are enabled) |
+| `reviewer-harness skills list` | List all 28 bundled skills (+ which are enabled) |
 | `reviewer-harness skills add <name>` | Install a skill into the project and enable it in the config |
 | `reviewer-harness skills remove <name>` | Disable a skill and remove it |
 | `reviewer-harness agents list` | List the bundled sub-agents |

package/package.json

@@ -3,7 +3,7 @@
   "bin": {
     "reviewer-harness": "./bin/cli.js"
   },
-  "description": "Your own AI harness \u2014 one master config that syncs guardrail rules, skills, and a local memory to Claude, OpenCode, Gemini, Cline, Freebuff, Copilot CLI, and Antigravity. No API key, no dependencies.",
+  "description": "Your own AI harness \u2014 one master config that syncs guardrail rules, skills, and a local memory to Claude, OpenCode, Gemini, Cline, Freebuff, Copilot CLI, Antigravity, and Qoder. No API key, no dependencies.",
   "engines": {
     "node": ">=18"
   },
@@ -31,7 +31,7 @@
     "test": "node --test tests/*.test.js"
   },
   "type": "module",
-  "version": "1.15.0",
+  "version": "1.16.0",
   "files": [
     "bin",
     "lib",

package/skills/api-security.md

@@ -45,6 +45,7 @@ Apply these 14 rules to every endpoint. If a rule doesn't apply, say why.
 - [ ] Every query is parameterized (no string concatenation into SQL)
 
 ### Learn more (official sources)
+- Rules 1–12 originate from the "12 API Security Rules" reel by Code Crack — the reel is their origin; their detailed wording in this file is general practice. Rules 13–14 cite their OWASP sources inline.
 - OWASP API Security Top 10: https://owasp.org/API-Security/
 - OWASP Cheat Sheet Series (API Security): https://cheatsheetseries.owasp.org/
 - OWASP Web Security Testing Guide: https://github.com/OWASP/wstg

package/skills/audit-team.md

@@ -21,8 +21,8 @@ Spawn all eight at once. The first five are skill specialists (one skill each, d
 | 4 | **backend-performance** | backend-performance | Queries, N+1, missing indexes, re-renders, Edge Function cost |
 | 5 | **system-design** | system-design | Status transitions, trust boundaries, scale (pilot city → bigger) |
 | 6 | **backend** (area) | safe-editing, debug-first, owasp-top10, nodejs-quality, rea | Code correctness and quality: surgical edits, error handling, OWASP Top 10, Node quality rules, tracing unfamiliar flows |
-| 7 | **frontend** (area) | motion-design, frontend-performance | Real animations (not static visuals), render performance, visual quality |
-| 8 | **devops** (area) | — (pipeline proof; the CI guidance in devops-basics "Also apply") | The live shipping path: CI green on this exact commit, tests (pass count AND exit code AND the "Errors" line), build, lint, typecheck, migrations idempotent + re-runnable, deploy config, no secrets in the repo |
+| 7 | **frontend** (area) | motion-design, frontend-performance, playwright-cli | Real animations (not static visuals), render performance, visual quality, runtime behavior in a real browser |
+| 8 | **devops** (area) | devops-basics (the CI guidance in its "Also apply" section) | The live shipping path: CI green on this exact commit, tests (pass count AND exit code AND the "Errors" line), build, lint, typecheck, migrations idempotent + re-runnable, deploy config, no secrets in the repo |
 
 **Every agent also applies no-hallucination** — every finding cites a real file and line, and every claim about what runs or passes is backed by evidence the agent actually saw.
 
@@ -70,9 +70,9 @@ Spawn all eight at once. The first five are skill specialists (one skill each, d
 
 **6 — backend area agent brief:** "Audit the backend of <repo> at <commit> as a whole. Read these skills first and apply them genuinely, not as labels: safe-editing, debug-first, owasp-top10, nodejs-quality, rea. Check: code correctness and quality (surgical edits, readable at a glance, separated files, no spaghetti, no hardcoded values, nothing unnecessary); error handling (no swallowed errors, no silent failures); OWASP Top 10 coverage; Node quality rules; trace unfamiliar flows end-to-end before judging them. Report-only — do not edit anything. Every finding: severity (Blocker/Warning/Suggestion), file:line, evidence, and what breaks in real use."
 
-**7 — frontend area agent brief:** "Audit the frontend of <repo> at <commit> as a whole. Read these skills first and apply them genuinely, not as labels: motion-design, frontend-performance. Check: animations are real motion, not static visuals; render performance (no infinite fetch loops, no jank from layout-triggering animations — transform/opacity only); visual quality (no generic purple-blue gradients, no floating orbs, no identical glass cards); contrast (WCAG AA on text over gradients). Report-only — do not edit anything. Every finding: severity (Blocker/Warning/Suggestion), file:line, evidence, and what breaks in real use."
+**7 — frontend area agent brief:** "Audit the frontend of <repo> at <commit> as a whole. Read these skills first and apply them genuinely, not as labels: motion-design, frontend-performance, playwright-cli. Check: animations are real motion, not static visuals; render performance (no infinite fetch loops, no jank from layout-triggering animations — transform/opacity only); visual quality (no generic purple-blue gradients, no floating orbs, no identical glass cards); contrast (WCAG AA on text over gradients). When the target is a web app that can be run (dev server or deployed URL), also drive its key flows with playwright-cli — open, snapshot, walk the primary journeys — and report runtime failures (console errors, dead buttons, broken states) as findings with screenshot or snapshot evidence; if it cannot be run, say so and label the findings code-only. Report-only — do not edit anything. Every finding: severity (Blocker/Warning/Suggestion), file:line, evidence, and what breaks in real use."
 
-**8 — devops area agent brief:** "Audit the live shipping path of <repo> at <commit>. Check: CI is green on this exact commit (read the Actions/runs page, not the workflow file — a workflow file is not proof); tests really pass (pass count AND exit code AND the 'Errors' line); build, lint, and typecheck clean; migrations are idempotent and re-runnable (every CREATE has DROP IF EXISTS / IF NOT EXISTS / CREATE OR REPLACE); deploy config matches the live target; no secrets in the repo. Report-only — do not edit anything. Every finding: severity (Blocker/Warning/Suggestion), file:line or run URL, evidence, and what breaks in real use."
+**8 — devops area agent brief:** "Audit the live shipping path of <repo> at <commit>. Read this skill first and apply it genuinely, not as a label: devops-basics — in particular the CI guidance in its 'Also apply' section. Check: CI is green on this exact commit (read the Actions/runs page, not the workflow file — a workflow file is not proof); tests really pass (pass count AND exit code AND the 'Errors' line); build, lint, and typecheck clean; migrations are idempotent and re-runnable (every CREATE has DROP IF EXISTS / IF NOT EXISTS / CREATE OR REPLACE); deploy config matches the live target; no secrets in the repo. Report-only — do not edit anything. Every finding: severity (Blocker/Warning/Suggestion), file:line or run URL, evidence, and what breaks in real use."
 
 ### Quick check before reporting
 - [ ] Target commit verified against the remote (agents read the right code)

package/skills/backend-performance.md

@@ -1,6 +1,6 @@
 ---
 name: backend-performance
-description: 10 backend performance rules distilled from nodebestpractices (105k stars) and system-design-primer — event loop, caching, idempotency, backpressure, and the latency numbers that tell you what's actually slow.
+description: 19 backend performance rules distilled from nodebestpractices (105k stars), system-design-primer, the PostgreSQL concurrency docs, and the OWASP Business Logic cheat sheet — event loop, caching, idempotency, backpressure, race conditions, and the latency numbers that tell you what's actually slow.
 ---
 
 ## Skill: backend-performance
@@ -43,6 +43,34 @@ Every rule below is distilled from a reputable open-source repo (cited per rule)
 10. **Watch the four golden signals.** Error rate (users feel it immediately), latency (directly affects business), throughput (gives context to the other two), and saturation (90% CPU = no headroom). Node-specific: keep process RAM under ~1.4GB, track errors per minute and restarts.
 *Source: goldbergyoni/nodebestpractices — `sections/production/monitoring.md`*
 
+### Survive concurrent requests
+11. **Treat every check-then-act as a race.** Any operation that reads a value, decides, then writes — check balance then debit, check the coupon is unused then redeem it, check the slot is free then book it — lets two concurrent requests both read the old value, both pass the check, and both write. Loyalty points get drained, balances go negative, single-use coupons get redeemed many times. If two requests can race, assume they will; the check and the act must be one atomic operation. (Idempotency keys, rule 5, cover retries — this rule covers simultaneous first attempts.)
+*Source: OWASP Cheat Sheet Series — `Business_Logic_Security_Cheat_Sheet.md`, "Prevent Race Conditions on Sensitive Operations"*
+
+12. **Lock the row when you read-then-write it.** In PostgreSQL, `SELECT ... FOR UPDATE` inside a transaction locks the row until commit — other writers and lockers wait, then see the updated row. Use `FOR NO KEY UPDATE` when you don't change key columns (weaker, blocks less). A plain `SELECT` takes no such lock: under MVCC it reads a snapshot and stops nobody.
+*Source: PostgreSQL documentation — Chapter 13 "Concurrency Control", §13.3.2 "Row-Level Locks"*
+
+13. **Prefer a conditional update over read-modify-write.** `UPDATE ... SET stock = stock - 1 WHERE stock > 0` makes the predicate part of the write itself — there is no window between check and act. Check the affected-row count: 0 rows means the condition no longer held at write time, so return the conflict error instead of writing.
+*Source: OWASP Cheat Sheet Series — `Business_Logic_Security_Cheat_Sheet.md`, pattern reference (conditional decrement)*
+
+14. **Back "exactly once" with a unique constraint.** One claim per donation, one redemption per coupon, one bonus per user: put a UNIQUE constraint on the natural key (e.g. `(user_id, bonus_type)`) and let the database reject the loser of the race. Application-level checks alone always leave a window — the constraint is the last line of defense.
+*Source: OWASP Cheat Sheet Series — `Business_Logic_Security_Cheat_Sheet.md`, pattern reference (one-per-user bonus)*
+
+15. **Know your isolation level — the default is weaker than you think.** PostgreSQL defaults to Read Committed: every statement sees a fresh snapshot, so invariants that span rows or statements can break under concurrency even though each statement looks correct. Repeatable Read gives one stable snapshot per transaction; Serializable additionally detects dangerous read/write patterns and aborts one side. Choose per invariant, not by habit.
+*Source: PostgreSQL documentation — Chapter 13 "Concurrency Control", §13.2 "Transaction Isolation"*
+
+16. **Retry serialization failures and deadlocks — they are normal outcomes, not bugs.** Repeatable Read and Serializable transactions can abort with SQLSTATE 40001 ("could not serialize access…"), and PostgreSQL automatically detects deadlocks and aborts one transaction to let the others finish. Wrap the whole transaction in a bounded retry loop; never surface a 40001 or a deadlock abort to the user as a 500.
+*Source: PostgreSQL documentation — Chapter 13, §13.2.2–13.2.3 (SQLSTATE 40001) and §13.3.4 "Deadlocks"*
+
+17. **Lock rows in a consistent order to prevent deadlocks.** When every transaction that touches multiple rows or tables locks them in the same order, circular waits mostly disappear. PostgreSQL detects the deadlocks that remain and aborts one side — which is why rule 16's retry loop must exist wherever explicit locking is used.
+*Source: PostgreSQL documentation — Chapter 13, §13.3.4 "Deadlocks"*
+
+18. **Use advisory locks when the resource isn't a row.** `pg_advisory_xact_lock` gives an application-defined lock for resources MVCC doesn't model — a job name, an external system, a whole workflow — and releases it automatically at transaction end. Advisory locks are cooperative: every code path that touches the resource must take the same lock, or it protects nothing.
+*Source: PostgreSQL documentation — Chapter 13, §13.3.5 "Advisory Locks"*
+
+19. **Write a test that races.** If two requests can race, a sequential test suite will never see the bug. Fire the same request concurrently (parallel calls against the real database) and assert the end state: the balance never goes negative, the coupon is redeemed exactly once, exactly one claim wins. The test documents the invariant as much as it verifies it.
+*Source: OWASP Cheat Sheet Series — `Business_Logic_Security_Cheat_Sheet.md`, "Test Concurrency"*
+
 ### Also apply (general practice, beyond these repos)
 - **Kill N+1 queries** — never query inside a loop; fetch related data with JOIN or `IN (...)`.
 - **Index hot columns** — foreign keys, `WHERE` and `ORDER BY` columns; verify with `EXPLAIN`.
@@ -54,6 +82,8 @@ Every rule below is distilled from a reputable open-source repo (cited per rule)
 - [ ] No Lodash where a native method does the job
 - [ ] Repeated reads are cached with a TTL and an invalidation plan
 - [ ] Write endpoints are idempotent or carry idempotency keys
+- [ ] Check-then-act operations are atomic — row lock, conditional update, or unique constraint, never a bare read-then-write
+- [ ] Serialization failures (40001) and deadlocks are retried with a bounded loop, not surfaced as 500s
 - [ ] Retries use backoff; queues have caps with 503 on overflow
 - [ ] Connections come from a sized pool, released on every path
 - [ ] Slowest path measured against the latency scale — biggest number attacked first
@@ -64,3 +94,5 @@ Every rule below is distilled from a reputable open-source repo (cited per rule)
 - System design primer: https://github.com/donnemartin/system-design-primer
 - Don't block the event loop (Node.js docs): https://nodejs.org/en/docs/guides/dont-block-the-event-loop/
 - Latency numbers: https://github.com/donnemartin/system-design-primer#latency-numbers-every-programmer-should-know
+- PostgreSQL concurrency control (official docs, Ch. 13): https://www.postgresql.org/docs/current/mvcc.html
+- OWASP Business Logic Security Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Business_Logic_Security_Cheat_Sheet.html

package/skills/clone.md

@@ -15,3 +15,4 @@ When to use: the user asks to clone a website or design, and gives a URL or refe
 - Front-end only: a clone reproduces the look, never the backend — no login, database, or dynamic data.
 - If the target is the user's own site, their own assets may be reused.
 - Afterwards, validate: compare screenshots side by side, check responsive breakpoints, audit every recorded measurement against the rebuild (sizes, spacing, fonts, colors), and audit that no third-party image, text, or brand remains. Report what was cloned, what was replaced, and any measurement that could not be verified.
+- If no browser or screenshot tooling is available in this environment, degrade honestly: run every check that does not need a rendered comparison (the measurement audit against the fetched styles and markup, the breakpoint check, the replaced-content audit) and state plainly in the report that the visual side-by-side was skipped — never imply it was done, and never report a visual match you did not actually see.

package/skills/design-taste-frontend.md

@@ -6,6 +6,7 @@ description: Anti-slop design taste distilled from Leonxlnx/taste-skill (v2.5.1)
 ## Skill: design-taste-frontend
 
 Distilled from [Leonxlnx/taste-skill](https://github.com/Leonxlnx/taste-skill) (`tasteskill 2.5.1`, HEAD `f6b7657`) — SKILL.md + references/layout-v4.md, copy.md, copy-tells.md, system.md, motion.md, library/palettes.json, library/type.json. Every rule below cites its source file. Anything the source does not cover is labeled "general practice".
+The two library files are vendored verbatim in this repo at `skills/library/palettes.json` (64 palettes) and `skills/library/type.json` (39 pairings), so the `library/…` paths in rules 32–33 resolve from this file's directory. Upstream is MIT — the license is vendored at `skills/library/LICENSE` (Copyright (c) 2026 Leonxlnx).
 
 When to use: build, design, redesign, restyle, polish, or review a landing page, company site, product page, shop, cafe, hotel, studio, SaaS, AI, devtool, or game site — or when a page looks generic, templated, or "AI-made".
 
@@ -107,6 +108,8 @@ When to use: build, design, redesign, restyle, polish, or review a landing page,
 59. **Tap targets:** every link/control outside running text ≥44px tall; a FAIL when another target is under 8px away. Nothing past the screen at 320.
 
 ### Edsiel's rules (local — not from the source)
+- **No green by default (2026-11-07):** never default to green or jade accents — Edsiel finds them ugly. The accent comes from the client or product (rule 27); a dealt palette that lands green-dominant with no client basis is dealt again. (A client's own green brand colour is his call, not a default.)
+- **No grid or dot-pattern backgrounds (2026-11-07):** grounds are flat colour, photographs, or the dealt effects where rule 3 allows them — never a grid or dot texture behind content.
 - Frontend team = `design-taste-frontend` + `ui-ux-pro-max` (+ `ux-edge-states`, `ub-mode`).
 - Installed on Edsiel's PC via `npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"`; location `~/.claude/skills/design-taste-frontend` (needed manual copy from `~/.agents/skills/`).
 - Paired with ui-ux-pro-max for the anti-slop check in DevPilotAI UI audits (since 2026-10-31).

package/skills/fix-team.md

@@ -1,6 +1,6 @@
 ---
 name: fix-team
-description: Run an 11-agent fix — 8 domain fixers (same skills as audit-team) plus ub-mode, superpowers, and a verification agent — over an audit report's findings, each applying the relevant skills, fix-only, no new features. The fix plan is written first and approved by the user; the verification agent runs last. Merged verification with the coordinator; the user picks what to fix.
+description: Run an 11-agent fix — 8 domain fixers (audit-team's eight areas; the backend fixer also applies ub-mode, and the frontend fixer also applies design-taste-frontend, ui-ux-pro-max, and vengeance-ui) plus ub-mode, superpowers, and a verification agent — over an audit report's findings, each applying the relevant skills, fix-only, no new features. The fix plan is written first and approved by the user; the verification agent runs last. Merged verification with the coordinator; the user picks what to fix.
 ---
 
 ## Skill: Fix Team (fix-team)
@@ -22,10 +22,10 @@ The superpowers agent runs FIRST (it writes the fix plan). The nine fixers run i
 | 5 | **system-design** | system-design | Status transitions, trust boundaries, races, idempotency |
 | 6 | **backend** (area) | safe-editing, debug-first, owasp-top10, nodejs-quality, rea, ub-mode | Code correctness and quality across the whole backend |
 | 7 | **frontend** (area) | motion-design, frontend-performance, design-taste-frontend, ui-ux-pro-max, vengeance-ui | Real animations, render performance, visual quality, anti-slop |
-| 8 | **devops** (area) | — (pipeline proof; the CI guidance in devops-basics "Also apply") | The live shipping path: tests, build, lint, typecheck, migrations, deploy config |
+| 8 | **devops** (area) | devops-basics (the CI guidance in its "Also apply" section) | The live shipping path: tests, build, lint, typecheck, migrations, deploy config |
 | 9 | **ub-mode** | ub-mode | Clean Code organization across the whole fix: TDD first, smallest edit, CRAP < 10, duplication ≥ 0.8 out, small ordered commits + log |
 | 10 | **superpowers** | writing-plans, brainstorming | The fix plan first (file map, rollback anchor, bite-sized TDD tasks, each ending in a commit) + the hard gate (no fix until the user approves the plan) |
-| 11 | **verification** | verify_before_done, instruction_registers, verify_provider_claims, verify_publish_install_surface | The fixer at the last: re-checks every fix (defined AND called, remote evidence, publish/install surfaces) and fixes what verification catches |
+| 11 | **verification** | verify_before_done, instruction_registers, verify_provider_claims, verify_publish_install_surface, playwright-cli | The fixer at the last: re-checks every fix (defined AND called, remote evidence, publish/install surfaces) and fixes what verification catches. For fixes touching a runnable web UI, it also drives the real app with playwright-cli — a UI fix is not verified by reading code alone |
 
 **Every agent also applies safe-editing, debug-first, no-hallucination, instruction_registers** — surgical edits only; root-cause first; every fix cites the finding's file:line + evidence; the target and action registers are named before building, and exactly one clarifying question is asked when they are ambiguous.
 
@@ -53,8 +53,8 @@ The superpowers agent runs FIRST (it writes the fix plan). The nine fixers run i
 6. **Every fix needs evidence.** The finding's file:line + the test/build output that proves the fix. A fix without a passing test (or a stated reason an honest test is impractical) is not a fix — it is a claim. A definition with no call site is an untested change, not a fix. A pass on mocked data proves the code logic only, never the live behavior.
    *Source: no-hallucination + verify_before_done (defined AND called, re-run every affected suite, mock passes are logic-only).*
 
-7. **Verification runs last and fixes what it catches.** The verification agent re-checks every fix against the finding, names the target and action registers before touching anything, checks provider claims and publish/install surfaces where the fix touches them, and fixes whatever the verification catches — then re-verifies its own fix. A fix that does not survive verification is not reported as done. Never present a guess as done — label untested work as untested and name what remains.
-   *Source: verify_before_done (remote evidence, never present a guess as done), verify_provider_claims (check the live source first), verify_publish_install_surface (check each surface in order; never say live from a push alone), instruction_registers (name the registers; ask once when unsure).*
+7. **Verification runs last and fixes what it catches.** The verification agent re-checks every fix against the finding, names the target and action registers before touching anything, checks provider claims and publish/install surfaces where the fix touches them, and fixes whatever the verification catches — then re-verifies its own fix. A fix that does not survive verification is not reported as done. Never present a guess as done — label untested work as untested and name what remains. Where a fix touches a web UI and the app can be run (dev server or deployed URL), verification must exercise the changed flow in a real browser via playwright-cli and attach the evidence (screenshot, snapshot, or a generated Playwright spec that passes) — code-reading alone does not verify a UI fix; if the app cannot be run, say so and label the UI fix unverified-at-runtime.
+   *Source: verify_before_done (remote evidence, never present a guess as done), verify_provider_claims (check the live source first), verify_publish_install_surface (check each surface in order; never say live from a push alone), instruction_registers (name the registers; ask once when unsure); playwright-cli runtime evidence — adoption test 2026-11-12 (TodoMVC: CLI session → generated spec → `npx playwright test` 1 passed).*
 
 8. **The coordinator merges, dedupes, and verifies centrally — then stops.** One merged report: counts by severity, fixes grouped by agent, regressions called out first. The coordinator re-runs the gates itself (tests, build, lint, typecheck, PGlite/Deno where they apply) — a pass count is not proof, check the exit code and the "Errors" line too. Then it prepares the push manifest (NUL-delimited, trailing NUL, count verified). It never pushes — the push is a separate decision by the user.
    *Source: Pantry fix rounds — central re-verification caught the capitalised-tag mismatch in round 6; push approvals are one-time per file.*
@@ -81,13 +81,13 @@ The superpowers agent runs FIRST (it writes the fix plan). The nine fixers run i
 
 **7 — frontend area fixer brief:** "Fix the frontend findings in <audit report> on <repo> at <commit> as a whole. Read these skills first and apply them genuinely, not as labels: motion-design, frontend-performance, design-taste-frontend, ui-ux-pro-max, vengeance-ui. Fix: animations are real motion, not static visuals; render performance; visual quality (no generic purple-blue gradients, no floating orbs, no identical glass cards); contrast (WCAG AA on text over gradients). Fix-only — fix what the audit found, nothing more. TDD first: failing test, smallest fix, tests pass. Every fix: finding file:line, what you changed, and the test/build output proving it."
 
-**8 — devops area fixer brief:** "Fix the shipping-path findings in <audit report> on <repo> at <commit>. Fix: CI green on this exact commit, tests really passing (pass count AND exit code AND the 'Errors' line), build, lint, and typecheck clean, migrations idempotent and re-runnable, deploy config matching the live target, no secrets in the repo. Fix-only — fix what the audit found, nothing more. Every fix: finding file:line or run URL, what you changed, and the command output proving it."
+**8 — devops area fixer brief:** "Fix the shipping-path findings in <audit report> on <repo> at <commit>. Read this skill first and apply it genuinely, not as a label: devops-basics — in particular the CI guidance in its 'Also apply' section. Fix: CI green on this exact commit, tests really passing (pass count AND exit code AND the 'Errors' line), build, lint, and typecheck clean, migrations idempotent and re-runnable, deploy config matching the live target, no secrets in the repo. Fix-only — fix what the audit found, nothing more. Every fix: finding file:line or run URL, what you changed, and the command output proving it."
 
 **9 — ub-mode fixer brief:** "Make the fixes in <fix run> on <repo> at <commit> clean and organized. Read this skill first and apply it genuinely, not as a label: ub-mode. Enforce across the whole fix: TDD first (failing test before the change); smallest edit that solves the problem (one decision lives in one place); sequence the work into verifiable units (finish one small unit and check it, then start the next); fix root causes, not symptoms; every function under CRAP 10; duplication ≥ 0.8 eliminated; small ordered commits, each saying why, what changed, and how it was proved; a log of every action and the reason. Where the crapper/dryer/mutator tools are not installed, apply the same thresholds by manual review and say so. Fix-only — organize what the audit found, nothing more. Every fix: finding file:line, what you changed, and the test/build output proving it."
 
 **10 — superpowers fixer brief:** "Write the fix plan for <audit report> on <repo> at <commit>, and hold the gate. Read these skills first and apply them genuinely, not as labels: writing-plans, brainstorming. Map the files first (which files are created or modified, what each is responsible for); write the plan with the header (Goal, Architecture, Tech Stack, Spec, Rollback anchor: last-known-good SHA), Global Constraints, and Review Focus; bite-sized TDD tasks, each ending in a testable deliverable and a commit, steps in checkbox syntax. Nothing is fixed until the user approves this plan — the hard gate. If the spec covers multiple independent subsystems, split them into separate plans. Self-review the plan against the audit report (spec coverage, step scan, type consistency, Review Focus, proportion) and fix it inline."
 
-**11 — verification fixer brief:** "Verify the fixes in <fix run> on <repo> at <commit>, and fix what verification catches. Read these skills first and apply them genuinely, not as labels: verify_before_done, instruction_registers, verify_provider_claims, verify_publish_install_surface. Re-check every fix: is the changed code defined AND called (or imported and used)? Re-run every affected suite after every change — do not reuse a passing result from before the change. Treat a mock pass as logic-only evidence. Get remote evidence (a pushed SHA exists on origin) before calling anything pushed. Name the target register (the agent's own workspace vs the reviewer-harness repo) and the action register (plan vs build) before touching anything; ask exactly one clarifying question when they are ambiguous. Where a fix touches a provider claim, check the live source first and quote it; where it touches a published version, check each surface in order (commit/tag, registry, installed file) and name the version on each. Fix what verification catches, then re-verify your own fix. Never present a guess as done — label untested work as untested and name what remains. Every result: fix file:line, what you checked, the evidence, and what you fixed if anything."
+**11 — verification fixer brief:** "Verify the fixes in <fix run> on <repo> at <commit>, and fix what verification catches. Read these skills first and apply them genuinely, not as labels: verify_before_done, instruction_registers, verify_provider_claims, verify_publish_install_surface, playwright-cli. Re-check every fix: is the changed code defined AND called (or imported and used)? Re-run every affected suite after every change — do not reuse a passing result from before the change. Treat a mock pass as logic-only evidence. Get remote evidence (a pushed SHA exists on origin) before calling anything pushed. Name the target register (the agent's own workspace vs the reviewer-harness repo) and the action register (plan vs build) before touching anything; ask exactly one clarifying question when they are ambiguous. Where a fix touches a provider claim, check the live source first and quote it; where it touches a published version, check each surface in order (commit/tag, registry, installed file) and name the version on each. Where a fix touches a web UI and the app can be run (dev server or deployed URL), drive the changed flow with playwright-cli: snapshot, perform the flow, screenshot the result, and where practical leave a passing Playwright spec as the evidence; if the app cannot be run, state that and label the UI fix unverified-at-runtime. Fix what verification catches, then re-verify your own fix. Never present a guess as done — label untested work as untested and name what remains. Every result: fix file:line, what you checked, the evidence, and what you fixed if anything."
 
 ### Quick check before reporting
 - [ ] Target commit + audit report verified (agents fixed the right code, from real findings)

package/skills/library/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Leonxlnx
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.