@ssheleg/sheleg-dev 0.13.4 → 0.14.0

package/CHANGELOG.md

@@ -1,3 +1,19 @@
+## v0.14.0 — frontend performance is tested in WebKit (Safari) first
+
+- `frontend-performance/SKILL.md` gains *Test browser — WebKit (Safari) first*:
+  Safari through `safaridriver`, Playwright `webkit` (`--browser webkit`,
+  `npx playwright install webkit`), Safari Web Inspector's Timelines, and
+  `open -a Safari <url>` on macOS rather than the system default browser.
+- Lighthouse, PageSpeed Insights, CrUX, CDP traces and the chrome-devtools MCP stay
+  as the stated Chromium exception (Chromium by definition): Chrome Dev, a
+  temporary profile, every started process closed. A page checked only in Chromium
+  is reported as exactly that; a Lighthouse score is not a cross-browser verdict.
+- The Measure and Validate steps run the WebKit pass too; *Degradation* names the
+  WebKit channels; the contrast check in `references/accessibility-perf.md` starts
+  in Safari Web Inspector.
+- New regression `test/audit_regressions/safari-first.py` with drop mutations. Text
+  integrity only; no hook or script behaviour changed.
+
 ## v0.13.4 — FW03 credential boundaries
 
 - Supply a copyable, locally tested Stripe mode assertion before client construction.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ssheleg/sheleg-dev",
-  "version": "0.13.4",
+  "version": "0.14.0",
   "description": "Seven integration skills for the layer a product reaches once it has users: Stripe subscription billing and cancellation retention, crypto payments, ad and conversion tracking under Consent Mode v2, Google sign-in and the wider Google auth surface, error tracking, and Core Web Vitals. This package is the installer CLI.",
   "bin": {
     "sheleg-dev": "bin/sheleg-dev.js"

package/plugins/sheleg-dev/.claude-plugin/plugin.json

@@ -3,7 +3,7 @@
   "name": "sheleg-dev",
   "displayName": "Sheleg Dev",
   "description": "The integration layer a product needs once it has users: Stripe subscription billing reconciled into your own database, crypto payments that survive over-payment and duplicate webhooks, ad and conversion tracking under Consent Mode v2, Google sign-in with the account-linking guards, the wider Google auth surface, and Core Web Vitals work that moves the score, and Sentry error tracking wired so it does not forward your own credentials to a third party and so a stack trace names the commit that caused it.",
-  "version": "0.13.4",
+  "version": "0.14.0",
   "author": {
     "name": "ssheleg",
     "url": "https://x.com/sshlg93"

package/plugins/sheleg-dev/skills/frontend-performance/SKILL.md

@@ -20,11 +20,33 @@ Optimize frontend applications for maximum Lighthouse scores and real-user perfo
 
 ## Audit Workflow
 
-1. **Measure** -- Run PageSpeed Insights or Lighthouse. Record scores and failing audits.
+1. **Measure** -- Run PageSpeed Insights or Lighthouse (Chromium) and load the same scenario in WebKit first (see *Test browser* below). Record scores, failing audits and the engine of each number.
 2. **Diagnose** -- Map each failing audit to a specific code-level cause (see checklist below).
 3. **Prioritize** -- Fix by impact: P0 blocks rendering, P1 hurts metrics, P2 is informational.
 4. **Implement** -- Apply fixes per the reference guides.
-5. **Validate** -- `next build` (or framework equivalent) + re-run Lighthouse. Verify no regressions.
+5. **Validate** -- `next build` (or framework equivalent) + re-run Lighthouse and the WebKit run. Verify no regressions in either engine.
+
+## Test browser — WebKit (Safari) first
+
+Load and profile the page in **WebKit first**: Safari through `safaridriver`
+(WebDriver; `sudo safaridriver --enable` once) for a real browser, Playwright's
+`webkit` (the `webkit` project, `--browser webkit`, installed with
+`npx playwright install webkit`) for scripted runs and traces, Safari Web
+Inspector's Timelines for debugging. On macOS open a page with
+`open -a Safari <url>`, not the system default browser, which may be another
+engine. An automation library (browser-use and the like) runs on its
+WebKit/Safari backend where it has one. WebKit has the narrowest support
+envelope of the big three — a regression that only iOS Safari users feel is
+invisible to every Chrome tool below.
+
+**Lighthouse, PageSpeed Insights, CrUX, a CDP trace and the chrome-devtools MCP
+are Chromium by definition** — they stay in this workflow as the **stated
+Chromium exception**: use them when the task needs Chrome itself, and say which
+and why. Prefer the Chrome Dev build for a Chrome run you start; give it a
+temporary profile (never the user's), record what you started, and close every
+process you started before you finish. A page checked only in Chromium is
+reported as "checked only in Chromium", never as "tested in a browser"; a
+Lighthouse score is a Chrome lab number, not a cross-browser verdict.
 
 ## Core Web Vitals, and the diagnostics beside them
 
@@ -198,7 +220,7 @@ how a typo survives review.
 - **Not Claude Code** (Cursor, Codex, the skills CLI, the API container): the pack's
   `PreToolUse` gate does not run — every rule here still applies, enforced by a person
   instead of a hook.
-- **No browser channel** (no Chrome DevTools MCP, no Playwright): a page is judged from
+- **No browser channel** (no `safaridriver`, no Playwright `webkit`, no Chrome DevTools MCP): a page is judged from
   the diff and the numbers are not measured on this machine. Record the weaker claim;
   a Lighthouse score nobody ran is not a score.
 - **No network**: PageSpeed Insights and field data are unavailable. Lab reasoning is

package/plugins/sheleg-dev/skills/frontend-performance/references/accessibility-perf.md

@@ -56,7 +56,7 @@ If you need visual hierarchy without reducing contrast below WCAG thresholds:
 
 ### Checking Contrast
 
-Use Chrome DevTools: inspect element -> color picker shows contrast ratio against computed background.
+Inspect in Safari Web Inspector first: the Computed styles give the text colour and, on the element or the ancestor that paints it, the background colour; and the formula below gives the ratio. Chrome DevTools' color picker shows the contrast ratio directly — a Chromium tool, so name it as the engine you checked in.
 
 Or calculate manually: `(L1 + 0.05) / (L2 + 0.05)` where L1 is the lighter relative luminance.