laxy-verify 1.3.3 → 1.4.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -1,491 +1,509 @@
1
- # laxy-verify
2
-
3
- `laxy-verify` is a deployment blocker gate for frontend apps.
4
-
5
- Every verification run includes build, Lighthouse, E2E, multi-viewport, security audit, visual diff, broken links, console error monitoring, and stability coverage regardless of plan. Optional opt-in checks add TypeScript type checking, secret scanning, bundle size analysis, outdated dependency detection, deep accessibility audit, deep SEO audit, and Core Web Vitals budget enforcement.
6
-
7
- ## Quick start
8
-
9
- Run it on a frontend app:
10
-
11
- ```bash
12
- cd your-project
13
- npx laxy-verify .
14
- ```
15
-
16
- Generate config plus GitHub Actions workflow:
17
-
18
- ```bash
19
- npx laxy-verify --init
20
- ```
21
-
22
- That creates:
23
-
24
- - `.laxy.yml`
25
- - `.github/workflows/laxy-verify.yml`
26
-
27
- Optional: log in to connect the CLI to your Laxy account:
28
-
29
- ```bash
30
- npx laxy-verify login
31
- npx laxy-verify whoami
32
- ```
33
-
34
- For CI, set `LAXY_TOKEN` instead of interactive login:
35
-
36
- ```yaml
37
- env:
38
- LAXY_TOKEN: ${{ secrets.LAXY_TOKEN }}
39
- ```
40
-
41
- ## Why laxy-verify?
42
-
43
- Most teams already have some mix of:
44
-
45
- - `npm run build`
46
- - Lighthouse
47
- - Playwright or smoke checks
48
- - CI status rules
49
-
50
- The gap is not "can these tools exist together?" The gap is "who turns that pile of output into a safe merge or release decision?"
51
-
52
- `laxy-verify` gives you:
53
-
54
- - one command instead of a custom build plus audit plus smoke-check script stack
55
- - one result file instead of scattered logs
56
- - one blocker-first decision instead of "build passed, but do we actually trust this release?"
57
- - optional account-linked automation on top of the same verification run
58
-
59
- This is most useful if you ship frontend apps and want a practical gate before:
60
-
61
- - merge
62
- - client review
63
- - QA handoff
64
- - production release
65
-
66
- ## Why not just LHCI?
67
-
68
- | | laxy-verify | LHCI | Checkly | Percy |
69
- |--|--|--|--|--|
70
- | Production build failure detection | Yes | No | No | No |
71
- | User-flow E2E verification | Yes | No | Manual setup | No |
72
- | Lighthouse scoring | Yes | Yes | No | No |
73
- | Visual regression check | Yes | No | No | Yes |
74
- | Broken link detection | Yes | No | No | No |
75
- | Console error monitoring | Yes | No | No | No |
76
- | Cross-browser (Firefox, WebKit) | Yes | No | Yes | No |
77
- | Release decision (`hold` / `client-ready`) | Yes | No, score only | No | No |
78
- | TypeScript type check | Yes | No | No | No |
79
- | Hardcoded secret scanning | Yes | No | No | No |
80
- | Bundle size analysis | Yes | No | No | No |
81
- | Outdated dependency check | Yes | No | No | No |
82
- | Deep WCAG audit (axe-core) | Yes | No | No | No |
83
- | Deep SEO audit | Yes | No | No | No |
84
- | Core Web Vitals budget | Yes | No | No | No |
85
- | Zero-config local start | Yes | No | No | No |
86
-
87
- LHCI measures Lighthouse. `laxy-verify` is for deciding whether this frontend is actually safe to ship.
88
-
89
- ## The failures it is meant to catch
90
-
91
- Use `laxy-verify` when you want to catch things like:
92
-
93
- - the production build passes locally but fails in CI
94
- - the app opens, but a key button or form flow is broken
95
- - desktop looks fine, but a mobile CTA is pushed out of view
96
- - Lighthouse looks acceptable, but the user-visible path is still not safe to ship
97
- - a PR needs a clear hold reason instead of a vague "something failed"
98
- - hardcoded API keys or secrets are about to be pushed to a public repo
99
- - TypeScript type errors could cause runtime crashes
100
- - bundle size has silently grown past acceptable limits
101
- - critical WCAG violations block real users
102
- - missing SEO meta tags hurt discoverability
103
-
104
- ## What it actually checks
105
-
106
- Every run includes:
107
-
108
- - **production build** - runs your actual build command, exit code determines pass/fail
109
- - **Lighthouse** - 3 runs averaged for stable performance, accessibility, SEO, and best practices scores
110
- - **E2E scenarios** - Puppeteer-based user flow testing (auto-detected or configured via `.laxy.yml`)
111
- - **stability pass** - E2E runs a second time to catch flaky behavior
112
- - **multi-viewport** - Lighthouse at desktop (1350px), tablet (1024px), and mobile (390px)
113
- - **security audit** - `npm audit` dependency vulnerability scan
114
- - **visual diff** - pixel-level screenshot comparison against baseline
115
- - **broken links** - crawls all internal links and validates HTTP responses
116
- - **console error monitoring** - captures browser JS errors during E2E execution
117
- - **cross-browser** - Playwright on Firefox and WebKit if `browsers` is configured in `.laxy.yml`
118
-
119
- ### Opt-in checks
120
-
121
- These checks are off by default. Enable them via CLI flags or `.laxy.yml`.
122
-
123
- | Flag | What it checks | Blocker or Advisory |
124
- |------|----------------|---------------------|
125
- | `--typecheck` | TypeScript type errors via `tsc --noEmit` | **Blocker** (5+ errors -> high severity) |
126
- | `--secret-scan` | Hardcoded secrets: AWS keys, GitHub tokens, Stripe keys, private keys, Bearer tokens, JWTs, generic password/token assignments | **Blocker** (always high severity) |
127
- | `--bundle-size` | Next.js or Vite bundle size analysis (first-load JS, largest chunk) | Advisory |
128
- | `--outdated-check` | Outdated dependencies via `npm outdated --json` | Advisory (major behind -> warning) |
129
- | `--a11y-deep` | Deep WCAG audit via axe-core (critical/serious violations) | **Blocker** (critical -> high severity) |
130
- | `--seo-deep` | SEO meta tags, canonical, robots, Open Graph, Twitter Card, JSON-LD | Advisory |
131
- | `--vitals-budget` | Core Web Vitals budget: LCP <= 2500ms, CLS <= 0.1, INP <= 200ms | Advisory |
132
-
133
- Secret scan never exposes actual credential values - findings are masked with `***` in all output formats.
134
-
135
- ## What you get from one run
136
-
137
- - a release decision such as `quick-pass`, `client-ready`, `release-ready`, `hold`, or `investigate`
138
- - a verification grade: `Gold`, `Silver`, `Bronze`, or `Unverified`
139
- - `.laxy-result.json` for CI and automation
140
- - `laxy-verify-report.md` for human review and AI handoff
141
-
142
- Grades still exist, but they are not the main point. The main point is whether the run found blockers you should stop on.
143
-
144
- ## Example workflow
145
-
146
- 1. Run `npx laxy-verify .` locally before opening or merging a PR.
147
- 2. Fix broken builds, broken flows, and visible regressions.
148
- 3. Commit `.laxy.yml`.
149
- 4. Run `npx laxy-verify --init`.
150
- 5. Let the GitHub Action apply the same gate on every PR.
151
-
152
- Full verification with all opt-in checks:
153
-
154
- ```bash
155
- npx laxy-verify . --typecheck --secret-scan --bundle-size --outdated-check --a11y-deep --seo-deep --vitals-budget
156
- ```
157
-
158
- Or enable them in `.laxy.yml` and just run:
159
-
160
- ```bash
161
- npx laxy-verify .
162
- ```
163
-
164
- If the default or configured dev port is already occupied, `laxy-verify` automatically starts its temporary verification server on the next available port. Use `--port` only when you want to attach to an already-running server yourself.
165
-
166
- ## Example output
167
-
168
- ```text
169
- Decision: client-ready
170
- Grade: Gold
171
-
172
- Passed:
173
- - production build
174
- - Lighthouse thresholds (Performance 92, Accessibility 97, SEO 90, Best Practices 95)
175
- - core user flows (5/5 scenarios passed)
176
- - stability pass (second E2E run passed)
177
- - desktop, tablet, and mobile viewport checks
178
- - security audit (no known vulnerabilities)
179
- - visual diff (no regressions)
180
- - broken links (0 broken / 12 checked)
181
- - console errors (0 detected)
182
- - TypeScript (0 errors)
183
- - Secret scan (0 findings, 42 files)
184
- - Bundle size (vite, within thresholds)
185
- - Outdated deps (0 outdated)
186
- - WCAG deep (0 critical)
187
- - SEO deep (0 errors)
188
- - Core Web Vitals budget (LCP 1200ms, CLS 0.05, INP 80ms)
189
-
190
- Artifacts:
191
- - .laxy-result.json
192
- - laxy-verify-report.md
193
-
194
- Badge (auto-updates with each run):
195
- [![Laxy Verify](https://laxy.app/api/badge/your-repo-id)](https://laxy.app)
196
- ```
197
-
198
- For Free accounts, the CLI prints a tip instead:
199
-
200
- ```text
201
- Tip: Pro tracks your last 30 runs so you can see if Performance or Grade is improving.
202
- https://laxy.app/pricing
203
- ```
204
-
205
- ## The decision it helps you make
206
-
207
- `laxy-verify` answers a delivery decision, not just a score:
208
-
209
- - Would this break for real users right now?
210
- - What would block a client demo or QA handoff?
211
- - Is there enough evidence to merge or release with confidence?
212
-
213
- All verification checks already run without a paid plan gate.
214
-
215
- ## Grades
216
-
217
- | Grade | Meaning |
218
- |---|---|
219
- | Gold | Build passed, E2E passed, Lighthouse passed, and release-level evidence passed |
220
- | Silver | Build passed and E2E passed |
221
- | Bronze | Build passed |
222
- | Unverified | Build failed |
223
-
224
- Default Lighthouse thresholds:
225
-
226
- - Performance `>= 70`
227
- - Accessibility `>= 85`
228
- - SEO `>= 80`
229
- - Best Practices `>= 80`
230
-
231
- ## Config
232
-
233
- All fields in `.laxy.yml` are optional.
234
-
235
- ```yaml
236
- framework: auto
237
- build_command: ""
238
- dev_command: ""
239
- package_manager: auto
240
- port: 3000
241
- build_timeout: 300
242
- dev_timeout: 60
243
- lighthouse_runs: 3
244
- fail_on: bronze
245
-
246
- thresholds:
247
- performance: 70
248
- accessibility: 85
249
- seo: 80
250
- best_practices: 80
251
-
252
- crawl: false
253
- max_crawl_depth: 3
254
- max_crawl_pages: 10
255
- browsers:
256
- - chromium
257
-
258
- # Explicit route list for Lighthouse (optional)
259
- lighthouse_routes: []
260
- # Extra routes not discoverable by the crawler (optional)
261
- extra_routes: []
262
- # Max crawl-discovered routes to run Lighthouse on (default: 5)
263
- max_lighthouse_routes: 5
264
-
265
- # Visual diff fine-tuning (optional)
266
- visual_diff:
267
- pixelmatch_threshold: 0.1
268
- warn_threshold: 30
269
- rollback_threshold: 60
270
- ignore_selectors: []
271
- disable_animations: true
272
-
273
- # Opt-in checks (off by default)
274
- typecheck: false
275
- secret_scan: false
276
- secret_scan_ignore_paths: []
277
- bundle_size: false
278
- outdated_check: false
279
- a11y_deep: false
280
- seo_deep: false
281
- vitals_budget: false
282
- ```
283
-
284
- Useful adjustments:
285
-
286
- - raise `fail_on` in CI when you want stricter gates
287
- - set `build_command` or `dev_command` if auto-detection is not enough
288
- - increase `lighthouse_runs` for more stable performance evidence
289
- - point the CLI at the actual app directory in a monorepo
290
-
291
- ## CLI
292
-
293
- ```text
294
- npx laxy-verify [project-dir]
295
-
296
- Options:
297
- --format console|json
298
- --ci
299
- --config <path>
300
- --fail-on unverified|bronze|silver|gold
301
- --skip-lighthouse
302
- --plan-override free|pro|team
303
- --badge
304
- --init
305
- --multi-viewport
306
- --crawl Crawl the app to discover routes before E2E
307
- --typecheck Run TypeScript type check (tsc --noEmit)
308
- --secret-scan Scan for hardcoded secrets and credentials
309
- --bundle-size Analyze bundle size (Next.js/Vite)
310
- --outdated-check Check for outdated dependencies
311
- --a11y-deep Deep accessibility audit (axe-core)
312
- --seo-deep Deep SEO audit (meta, OG, JSON-LD)
313
- --vitals-budget Core Web Vitals budget check (LCP, CLS, INP)
314
- --share Save result and get a shareable URL (Pro)
315
- --compare <url> Compare Lighthouse scores against a reference URL (Pro)
316
- --help
317
-
318
- Subcommands:
319
- login [email]
320
- logout
321
- whoami
322
- ```
323
-
324
- `--plan-override` is only for plan-label and automation testing. Verification coverage stays the same on every plan.
325
-
326
- ## Pro features
327
-
328
- Pro and Team accounts unlock additional capabilities on top of the same verification run:
329
-
330
- - **Result saving and sharing** - `--share` saves the run to your dashboard and returns a shareable URL
331
- - **Environment comparison** - `--compare <url>` runs Lighthouse against a reference URL (e.g. staging or production) and shows score deltas between your local build and the reference
332
- - **AI failure analysis** - when a run ends in `hold`, Claude analyzes the failure context and returns a root cause summary with top fix suggestions
333
- - **History trend tracking** - the last 30 runs are stored so you can see whether your grade and performance scores are improving or regressing over time
334
- - **Dynamic README badge** - after each run, the CLI prints a Markdown badge snippet that links to your live verification status. The badge auto-updates with every run so your README always reflects current grade
335
- - **Team Slack / Discord alerts** - grade drops and `hold` verdicts fire webhook notifications with score deltas and blocker details
336
- - **Weekly team report** - automated weekly summary of verification activity across your team's repos
337
-
338
- Free accounts see a hint after each run pointing to the history trend feature.
339
-
340
- ## Secret scan patterns
341
-
342
- When `--secret-scan` is enabled, the following patterns are detected:
343
-
344
- | Pattern | Example |
345
- |---------|--------|
346
- | AWS Access Key | `AKIA...` (20 chars) |
347
- | AWS Secret Key | `aws_secret_access_key = '...'` |
348
- | GitHub Token | `ghp_`, `gho_`, `ghs_`, `ghu_` |
349
- | Slack Token / Webhook | `xoxb-...`, `hooks.slack.com/...` |
350
- | Private Key Block | `-----BEGIN RSA PRIVATE KEY-----` |
351
- | Google API Key | `AIza...` |
352
- | Stripe Key | `sk_live_...`, `pk_live_...` |
353
- | Twilio / SendGrid / Mailgun | `SK...`, `SG...`, `key-...` |
354
- | Hardcoded Bearer Token | `Bearer abc123...` |
355
- | JWT-like Secret | `eyJ...` |
356
- | Generic Secret Assignment | `password = '...'`, `api_key = '...'` |
357
-
358
- False positive filtering:
359
-
360
- - `process.env.*`, `import.meta.env.*`, `NEXT_PUBLIC_*`, `VITE_*` references are ignored
361
- - GitHub Actions template variables (`${{ secrets.* }}`) are ignored
362
- - `test/`, `tests/`, `__tests__/`, `spec/` directories are excluded
363
- - Comment lines (`//`, `*`, `<!--`) are excluded - commented-out secrets are not flagged
364
- - Placeholder/example values are ignored
365
- - All secret values in findings are **masked with `***`** - never exposed in output
366
-
367
- ## Test fixture
368
-
369
- A sample Vite + React + TypeScript app is included at `fixtures/sample-app/` for testing all verification checks:
370
-
371
- ```bash
372
- cd fixtures/sample-app
373
- npm install
374
- npm run build
375
- npx laxy-verify . --typecheck --secret-scan --bundle-size --outdated-check --skip-lighthouse
376
- ```
377
-
378
- See `fixtures/sample-app/README.md` for details on what each check finds in the fixture.
379
-
380
- ## Result files
381
-
382
- Every run writes `.laxy-result.json`.
383
-
384
- When the run finds something worth reviewing, it also writes `laxy-verify-report.md`.
385
-
386
- Typical use:
387
-
388
- - `.laxy-result.json` for CI parsing and machine decisions
389
- - `laxy-verify-report.md` for human review, PR discussion, or AI-assisted fixes
390
-
391
- The markdown report is designed to be readable and easy to paste into coding tools.
392
-
393
- It includes:
394
-
395
- - the main stop-or-ship decision in plain English
396
- - what passed
397
- - blockers and warnings
398
- - exact verification evidence
399
- - failed scenarios
400
- - a `Copy For AI` section
401
-
402
- ## What this is good at
403
-
404
- Use `laxy-verify` when you want:
405
-
406
- - a merge or release gate for frontend apps
407
- - one repeatable command for build plus audit plus visible-flow verification
408
- - a decision that non-authors can understand
409
- - JSON output for automation without building your own wrapper
410
-
411
- ## What this is not
412
-
413
- `laxy-verify` is not trying to replace:
414
-
415
- - your full Playwright suite
416
- - deep visual QA by designers
417
- - production observability
418
- - manual exploratory testing
419
-
420
- It is a pre-merge and pre-release verification layer, not your entire quality system.
421
-
422
- ## Limitations
423
-
424
- - monorepos should target the real app subdirectory
425
- - dev-server-based Lighthouse is not identical to production hosting
426
- - visual diff and viewport checks increase runtime
427
- - best stability is on current LTS Node releases
428
-
429
- ## Requirements
430
-
431
- - Node `>=20.18.0 <25`
432
- - a frontend app with a runnable build flow
433
- - optional: `playwright` if your project already uses it
434
-
435
- ## Changelog
436
-
437
- ### v1.3.3 - Cleaner output and route validation
438
-
439
- - Removed `Pro` and `Pro+` labels from verification logs so `npx laxy-verify .` prints plan-neutral output
440
- - Runtime-discovered routes are now validated before they are used for Lighthouse and broken-link checks, so bogus `404` bundle snippets do not poison the verification result
441
-
442
- ### v1.3.2 - Auto port fallback
443
-
444
- - If port `3000` or your configured verification port is already in use, `laxy-verify` now starts its temporary dev server on the next available port automatically
445
- - `--port` keeps its existing meaning: attach to an already-running server instead of starting a temporary one
446
-
447
- ### v1.3.1 - Publish fix
448
-
449
- - Fix npm package contents so `login`, `logout`, and `whoami` ship with the required `dist/init-analysis.js` runtime dependency
450
- - Republish the CLI artifact with the README badge, Pro history trend messaging, and Free-plan CLI tip aligned to the shipped code
451
-
452
- ### v1.3.0 - Pro history trend, dynamic badge, CLI nudge
453
-
454
- - **History trend tracking** - Pro accounts now store the last 30 verification runs. Grade and performance scores accumulate so you can see whether your app is improving or regressing over time
455
- - **Dynamic README badge** - after each run, Pro accounts see a Markdown badge snippet in the CLI output. The badge auto-updates with every run via the `/api/badge/:id` endpoint
456
- - **CLI nudge** - Free accounts see a one-line tip after each run pointing to the history trend feature
457
- - Added `generateDynamicBadgeMarkdown(repoId, apiUrl)` export to the `badge` module
458
- - Added `share_result` and `history_trend` flags to `EntitlementFeatures` interface
459
- - 17 test files, 88 unit tests
460
-
461
- ### v1.2.3 - Bug fix
462
-
463
- - Fix E2E and visual diff connection failure on Windows with Node.js 17+: `verifyUrl` now uses `localhost` instead of `127.0.0.1`. On Windows, Vite binds to `::1` (IPv6) which does not accept IPv4 connections.
464
-
465
- ### v1.2.2 - Opt-in verification checks
466
-
467
- Added 7 opt-in checks (off by default, enable via CLI flags or `.laxy.yml`):
468
-
469
- - `--typecheck` - TypeScript type error detection via `tsc --noEmit`
470
- - `--secret-scan` - Hardcoded secret scanning with 11 regex patterns and `***` masking
471
- - `--bundle-size` - Next.js/Vite bundle size analysis
472
- - `--outdated-check` - Outdated dependency detection via `npm outdated`
473
- - `--a11y-deep` - Deep WCAG audit via axe-core + Puppeteer
474
- - `--seo-deep` - SEO meta/OG/JSON-LD audit
475
- - `--vitals-budget` - Core Web Vitals budget enforcement (LCP, CLS, INP)
476
-
477
- Other changes:
478
-
479
- - Secret scan findings are **masked** - real credential values never appear in JSON, markdown, or console output
480
- - Comment lines excluded from secret scanning to reduce false positives
481
- - `test/`, `tests/`, `__tests__/`, `spec/` directories excluded from scanning
482
- - `.laxy.yml` supports `secret_scan_ignore_paths` for custom exclusions
483
- - Verification report includes all new checks in passes checklist and improvement recommendations
484
- - Markdown report includes all new checks in the delivery evidence table
485
- - Added `fixtures/sample-app/` test fixture (Vite + React + TypeScript)
486
- - 17 test files, 88 unit tests
487
-
488
- ## Links
489
-
490
- - GitHub: https://github.com/SUNgm24/Laxy/tree/main/laxy-verify
491
- - Issues: https://github.com/SUNgm24/Laxy/issues
1
+ # laxy-verify
2
+
3
+ `laxy-verify` is a deployment blocker gate for frontend apps.
4
+
5
+ Every verification run includes build, Lighthouse, E2E, multi-viewport, security audit, visual diff, broken links, console error monitoring, and stability coverage regardless of plan. Optional opt-in checks add TypeScript type checking, secret scanning, bundle size analysis, outdated dependency detection, deep accessibility audit, deep SEO audit, and Core Web Vitals budget enforcement.
6
+
7
+ ## Quick start
8
+
9
+ Run it on a frontend app:
10
+
11
+ ```bash
12
+ cd your-project
13
+ npx laxy-verify .
14
+ ```
15
+
16
+ Generate config plus GitHub Actions workflow:
17
+
18
+ ```bash
19
+ npx laxy-verify --init
20
+ ```
21
+
22
+ That creates:
23
+
24
+ - `.laxy.yml`
25
+ - `.github/workflows/laxy-verify.yml`
26
+
27
+ Optional: log in to connect the CLI to your Laxy account:
28
+
29
+ ```bash
30
+ npx laxy-verify login
31
+ npx laxy-verify whoami
32
+ ```
33
+
34
+ For CI, set `LAXY_TOKEN` instead of interactive login:
35
+
36
+ ```yaml
37
+ env:
38
+ LAXY_TOKEN: ${{ secrets.LAXY_TOKEN }}
39
+ ```
40
+
41
+ ## Why laxy-verify?
42
+
43
+ Most teams already have some mix of:
44
+
45
+ - `npm run build`
46
+ - Lighthouse
47
+ - Playwright or smoke checks
48
+ - CI status rules
49
+
50
+ The gap is not "can these tools exist together?" The gap is "who turns that pile of output into a safe merge or release decision?"
51
+
52
+ `laxy-verify` gives you:
53
+
54
+ - one command instead of a custom build plus audit plus smoke-check script stack
55
+ - one result file instead of scattered logs
56
+ - one blocker-first decision instead of "build passed, but do we actually trust this release?"
57
+ - optional account-linked automation on top of the same verification run
58
+
59
+ This is most useful if you ship frontend apps and want a practical gate before:
60
+
61
+ - merge
62
+ - client review
63
+ - QA handoff
64
+ - production release
65
+
66
+ ## Why not just LHCI?
67
+
68
+ | | laxy-verify | LHCI | Checkly | Percy |
69
+ |--|--|--|--|--|
70
+ | Production build failure detection | Yes | No | No | No |
71
+ | User-flow E2E verification | Yes | No | Manual setup | No |
72
+ | Lighthouse scoring | Yes | Yes | No | No |
73
+ | Visual regression check | Yes | No | No | Yes |
74
+ | Broken link detection | Yes | No | No | No |
75
+ | Console error monitoring | Yes | No | No | No |
76
+ | Cross-browser (Firefox, WebKit) | Yes | No | Yes | No |
77
+ | Release decision (`hold` / `client-ready`) | Yes | No, score only | No | No |
78
+ | TypeScript type check | Yes | No | No | No |
79
+ | Hardcoded secret scanning | Yes | No | No | No |
80
+ | Bundle size analysis | Yes | No | No | No |
81
+ | Outdated dependency check | Yes | No | No | No |
82
+ | Deep WCAG audit (axe-core) | Yes | No | No | No |
83
+ | Deep SEO audit | Yes | No | No | No |
84
+ | Core Web Vitals budget | Yes | No | No | No |
85
+ | Zero-config local start | Yes | No | No | No |
86
+
87
+ LHCI measures Lighthouse. `laxy-verify` is for deciding whether this frontend is actually safe to ship.
88
+
89
+ ## The failures it is meant to catch
90
+
91
+ Use `laxy-verify` when you want to catch things like:
92
+
93
+ - the production build passes locally but fails in CI
94
+ - the app opens, but a key button or form flow is broken
95
+ - desktop looks fine, but a mobile CTA is pushed out of view
96
+ - Lighthouse looks acceptable, but the user-visible path is still not safe to ship
97
+ - a PR needs a clear hold reason instead of a vague "something failed"
98
+ - hardcoded API keys or secrets are about to be pushed to a public repo
99
+ - TypeScript type errors could cause runtime crashes
100
+ - bundle size has silently grown past acceptable limits
101
+ - critical WCAG violations block real users
102
+ - missing SEO meta tags hurt discoverability
103
+
104
+ ## What it actually checks
105
+
106
+ Every run includes:
107
+
108
+ - **production build** - runs your actual build command, exit code determines pass/fail
109
+ - **Lighthouse** - 3 runs averaged for stable performance, accessibility, SEO, and best practices scores
110
+ - **E2E scenarios** - Puppeteer-based user flow testing (auto-detected or configured via `.laxy.yml`)
111
+ - **stability pass** - E2E runs a second time to catch flaky behavior
112
+ - **multi-viewport** - Lighthouse at desktop (1350px), tablet (1024px), and mobile (390px)
113
+ - **security audit** - `npm audit` dependency vulnerability scan
114
+ - **visual diff** - pixel-level screenshot comparison against baseline
115
+ - **broken links** - crawls all internal links and validates HTTP responses
116
+ - **console error monitoring** - captures browser JS errors during E2E execution
117
+ - **cross-browser** - Playwright on Firefox and WebKit if `browsers` is configured in `.laxy.yml`
118
+
119
+ ### Opt-in checks
120
+
121
+ These checks are off by default. Enable them via CLI flags or `.laxy.yml`.
122
+
123
+ | Flag | What it checks | Blocker or Advisory |
124
+ |------|----------------|---------------------|
125
+ | `--typecheck` | TypeScript type errors via `tsc --noEmit` | **Blocker** (5+ errors -> high severity) |
126
+ | `--secret-scan` | Hardcoded secrets: AWS keys, GitHub tokens, Stripe keys, private keys, Bearer tokens, JWTs, generic password/token assignments | **Blocker** (always high severity) |
127
+ | `--bundle-size` | Next.js or Vite bundle size analysis (first-load JS, largest chunk) | Advisory |
128
+ | `--outdated-check` | Outdated dependencies via `npm outdated --json` | Advisory (major behind -> warning) |
129
+ | `--a11y-deep` | Deep WCAG audit via axe-core (critical/serious violations) | **Blocker** (critical -> high severity) |
130
+ | `--seo-deep` | SEO meta tags, canonical, robots, Open Graph, Twitter Card, JSON-LD | Advisory |
131
+ | `--vitals-budget` | Core Web Vitals budget: LCP <= 2500ms, CLS <= 0.1, INP <= 200ms | Advisory |
132
+
133
+ Secret scan never exposes actual credential values - findings are masked with `***` in all output formats.
134
+
135
+ ## What you get from one run
136
+
137
+ - a release decision such as `quick-pass`, `client-ready`, `release-ready`, `hold`, or `investigate`
138
+ - a verification grade: `Gold`, `Silver`, `Bronze`, or `Unverified`
139
+ - `.laxy-result.json` for CI and automation
140
+ - `laxy-verify-report.md` for human review and AI handoff
141
+
142
+ Grades still exist, but they are not the main point. The main point is whether the run found blockers you should stop on.
143
+
144
+ ## Example workflow
145
+
146
+ 1. Run `npx laxy-verify .` locally before opening or merging a PR.
147
+ 2. Fix broken builds, broken flows, and visible regressions.
148
+ 3. Commit `.laxy.yml`.
149
+ 4. Run `npx laxy-verify --init`.
150
+ 5. Let the GitHub Action apply the same gate on every PR.
151
+
152
+ Full verification with all opt-in checks:
153
+
154
+ ```bash
155
+ npx laxy-verify . --typecheck --secret-scan --bundle-size --outdated-check --a11y-deep --seo-deep --vitals-budget
156
+ ```
157
+
158
+ Or enable them in `.laxy.yml` and just run:
159
+
160
+ ```bash
161
+ npx laxy-verify .
162
+ ```
163
+
164
+ If the default or configured dev port is already occupied, `laxy-verify` automatically starts its temporary verification server on the next available port. Use `--port` only when you want to attach to an already-running server yourself.
165
+
166
+ ## Example output
167
+
168
+ ```text
169
+ Decision: client-ready
170
+ Grade: Gold
171
+
172
+ Passed:
173
+ - production build
174
+ - Lighthouse thresholds (Performance 92, Accessibility 97, SEO 90, Best Practices 95)
175
+ - core user flows (5/5 scenarios passed)
176
+ - stability pass (second E2E run passed)
177
+ - desktop, tablet, and mobile viewport checks
178
+ - security audit (no known vulnerabilities)
179
+ - visual diff (no regressions)
180
+ - broken links (0 broken / 12 checked)
181
+ - console errors (0 detected)
182
+ - TypeScript (0 errors)
183
+ - Secret scan (0 findings, 42 files)
184
+ - Bundle size (vite, within thresholds)
185
+ - Outdated deps (0 outdated)
186
+ - WCAG deep (0 critical)
187
+ - SEO deep (0 errors)
188
+ - Core Web Vitals budget (LCP 1200ms, CLS 0.05, INP 80ms)
189
+
190
+ Artifacts:
191
+ - .laxy-result.json
192
+ - laxy-verify-report.md
193
+
194
+ Badge (auto-updates with each run):
195
+ [![Laxy Verify](https://laxy.app/api/badge/your-repo-id)](https://laxy.app)
196
+ ```
197
+
198
+ For Free accounts, the CLI prints a tip instead:
199
+
200
+ ```text
201
+ Tip: Pro tracks your last 30 runs so you can see if Performance or Grade is improving.
202
+ https://laxy-blue.vercel.app/pricing
203
+ ```
204
+
205
+ ## The decision it helps you make
206
+
207
+ `laxy-verify` answers a delivery decision, not just a score:
208
+
209
+ - Would this break for real users right now?
210
+ - What would block a client demo or QA handoff?
211
+ - Is there enough evidence to merge or release with confidence?
212
+
213
+ All verification checks already run without a paid plan gate.
214
+
215
+ ## Grades
216
+
217
+ | Grade | Meaning |
218
+ |---|---|
219
+ | Gold | Build passed, E2E passed, Lighthouse passed, and release-level evidence passed |
220
+ | Silver | Build passed and E2E passed |
221
+ | Bronze | Build passed |
222
+ | Unverified | Build failed |
223
+
224
+ Default Lighthouse thresholds:
225
+
226
+ - Performance `>= 70`
227
+ - Accessibility `>= 85`
228
+ - SEO `>= 80`
229
+ - Best Practices `>= 80`
230
+
231
+ ## Config
232
+
233
+ All fields in `.laxy.yml` are optional.
234
+
235
+ ```yaml
236
+ framework: auto
237
+ build_command: ""
238
+ dev_command: ""
239
+ package_manager: auto
240
+ port: 3000
241
+ build_timeout: 300
242
+ dev_timeout: 60
243
+ lighthouse_runs: 3
244
+ fail_on: bronze
245
+
246
+ thresholds:
247
+ performance: 70
248
+ accessibility: 85
249
+ seo: 80
250
+ best_practices: 80
251
+
252
+ crawl: false
253
+ max_crawl_depth: 3
254
+ max_crawl_pages: 10
255
+ browsers:
256
+ - chromium
257
+
258
+ # Explicit route list for Lighthouse (optional)
259
+ lighthouse_routes: []
260
+ # Extra routes not discoverable by the crawler (optional)
261
+ extra_routes: []
262
+ # Max crawl-discovered routes to run Lighthouse on (default: 5)
263
+ max_lighthouse_routes: 5
264
+
265
+ # Visual diff fine-tuning (optional)
266
+ visual_diff:
267
+ pixelmatch_threshold: 0.1
268
+ warn_threshold: 30
269
+ rollback_threshold: 60
270
+ ignore_selectors: []
271
+ disable_animations: true
272
+
273
+ # Opt-in checks (off by default)
274
+ typecheck: false
275
+ secret_scan: false
276
+ secret_scan_ignore_paths: []
277
+ bundle_size: false
278
+ outdated_check: false
279
+ a11y_deep: false
280
+ seo_deep: false
281
+ vitals_budget: false
282
+ ```
283
+
284
+ Useful adjustments:
285
+
286
+ - raise `fail_on` in CI when you want stricter gates
287
+ - set `build_command` or `dev_command` if auto-detection is not enough
288
+ - increase `lighthouse_runs` for more stable performance evidence
289
+ - point the CLI at the actual app directory in a monorepo
290
+
291
+ ## CLI
292
+
293
+ ```text
294
+ npx laxy-verify [project-dir]
295
+
296
+ Options:
297
+ --format console|json
298
+ --ci
299
+ --config <path>
300
+ --fail-on unverified|bronze|silver|gold
301
+ --skip-lighthouse
302
+ --plan-override free|pro|team
303
+ --badge
304
+ --init
305
+ --multi-viewport
306
+ --crawl Crawl the app to discover routes before E2E
307
+ --typecheck Run TypeScript type check (tsc --noEmit)
308
+ --secret-scan Scan for hardcoded secrets and credentials
309
+ --bundle-size Analyze bundle size (Next.js/Vite)
310
+ --outdated-check Check for outdated dependencies
311
+ --a11y-deep Deep accessibility audit (axe-core)
312
+ --seo-deep Deep SEO audit (meta, OG, JSON-LD)
313
+ --vitals-budget Core Web Vitals budget check (LCP, CLS, INP)
314
+ --share Save result and get a shareable URL (Pro)
315
+ --compare <url> Compare Lighthouse scores against a reference URL (Pro)
316
+ --help
317
+
318
+ Subcommands:
319
+ login [email]
320
+ logout
321
+ whoami
322
+ ```
323
+
324
+ `--plan-override` is only for plan-label and automation testing. Verification coverage stays the same on every plan.
325
+
326
+ ## Pro features
327
+
328
+ Pro and Team accounts unlock additional capabilities on top of the same verification run:
329
+
330
+ - **Result saving and sharing** - `--share` saves the run to your dashboard and returns a shareable URL
331
+ - **Environment comparison** - `--compare <url>` runs Lighthouse against a reference URL (e.g. staging or production) and shows score deltas between your local build and the reference
332
+ - **AI failure analysis** - when a run ends in `hold`, Claude analyzes the failure context and returns a root cause summary with top fix suggestions
333
+ - **History trend tracking** - the last 30 runs are stored so you can see whether your grade and performance scores are improving or regressing over time
334
+ - **Dynamic README badge** - after each run, the CLI prints a Markdown badge snippet that links to your live verification status. The badge auto-updates with every run so your README always reflects current grade
335
+ - **Team Slack / Discord alerts** - grade drops and `hold` verdicts fire webhook notifications with score deltas and blocker details
336
+ - **Weekly team report** - automated weekly summary of verification activity across your team's repos
337
+
338
+ Free accounts see a hint after each run pointing to the history trend feature.
339
+
340
+ ## Secret scan patterns
341
+
342
+ When `--secret-scan` is enabled, the following patterns are detected:
343
+
344
+ | Pattern | Example |
345
+ |---------|--------|
346
+ | AWS Access Key | `AKIA...` (20 chars) |
347
+ | AWS Secret Key | `aws_secret_access_key = '...'` |
348
+ | GitHub Token | `ghp_`, `gho_`, `ghs_`, `ghu_` |
349
+ | Slack Token / Webhook | `xoxb-...`, `hooks.slack.com/...` |
350
+ | Private Key Block | `-----BEGIN RSA PRIVATE KEY-----` |
351
+ | Google API Key | `AIza...` |
352
+ | Stripe Key | `sk_live_...`, `pk_live_...` |
353
+ | Twilio / SendGrid / Mailgun | `SK...`, `SG...`, `key-...` |
354
+ | Hardcoded Bearer Token | `Bearer abc123...` |
355
+ | JWT-like Secret | `eyJ...` |
356
+ | Generic Secret Assignment | `password = '...'`, `api_key = '...'` |
357
+
358
+ False positive filtering:
359
+
360
+ - `process.env.*`, `import.meta.env.*`, `NEXT_PUBLIC_*`, `VITE_*` references are ignored
361
+ - GitHub Actions template variables (`${{ secrets.* }}`) are ignored
362
+ - `test/`, `tests/`, `__tests__/`, `spec/` directories are excluded
363
+ - Comment lines (`//`, `*`, `<!--`) are excluded - commented-out secrets are not flagged
364
+ - Placeholder/example values are ignored
365
+ - All secret values in findings are **masked with `***`** - never exposed in output
366
+
367
+ ## Test fixture
368
+
369
+ A sample Vite + React + TypeScript app is included at `fixtures/sample-app/` for testing all verification checks:
370
+
371
+ ```bash
372
+ cd fixtures/sample-app
373
+ npm install
374
+ npm run build
375
+ npx laxy-verify . --typecheck --secret-scan --bundle-size --outdated-check --skip-lighthouse
376
+ ```
377
+
378
+ See `fixtures/sample-app/README.md` for details on what each check finds in the fixture.
379
+
380
+ ## Result files
381
+
382
+ Every run writes `.laxy-result.json`.
383
+
384
+ When the run finds something worth reviewing, it also writes `laxy-verify-report.md`.
385
+
386
+ Typical use:
387
+
388
+ - `.laxy-result.json` for CI parsing and machine decisions
389
+ - `laxy-verify-report.md` for human review, PR discussion, or AI-assisted fixes
390
+
391
+ The markdown report is designed to be readable and easy to paste into coding tools.
392
+
393
+ It includes:
394
+
395
+ - the main stop-or-ship decision in plain English
396
+ - what passed
397
+ - blockers and warnings
398
+ - exact verification evidence
399
+ - failed scenarios
400
+ - a `Copy For AI` section
401
+
402
+ ## What this is good at
403
+
404
+ Use `laxy-verify` when you want:
405
+
406
+ - a merge or release gate for frontend apps
407
+ - one repeatable command for build plus audit plus visible-flow verification
408
+ - a decision that non-authors can understand
409
+ - JSON output for automation without building your own wrapper
410
+
411
+ ## What this is not
412
+
413
+ `laxy-verify` is not trying to replace:
414
+
415
+ - your full Playwright suite
416
+ - deep visual QA by designers
417
+ - production observability
418
+ - manual exploratory testing
419
+
420
+ It is a pre-merge and pre-release verification layer, not your entire quality system.
421
+
422
+ ## Limitations
423
+
424
+ - monorepos should target the real app subdirectory
425
+ - dev-server-based Lighthouse is not identical to production hosting
426
+ - visual diff and viewport checks increase runtime
427
+ - best stability is on current LTS Node releases
428
+
429
+ ## Requirements
430
+
431
+ - Node `>=20.18.0 <25`
432
+ - a frontend app with a runnable build flow
433
+ - optional: `playwright` if your project already uses it
434
+
435
+ ## Auto-update check
436
+
437
+ When you run `npx laxy-verify .` interactively, the CLI checks npm for a newer version. If an update is available, it prompts:
438
+
439
+ ```text
440
+ laxy-verify update available: 1.3.3 1.4.0
441
+ Update now? (y/N):
442
+ ```
443
+
444
+ Press `y` to update and re-run automatically. The check is skipped in CI environments and non-interactive terminals.
445
+
446
+ ## Changelog
447
+
448
+ ### v1.4.0 - Auto-update check and evidence fix
449
+
450
+ - **Auto-update prompt** - the CLI now checks for newer versions on npm at startup and offers a one-step update when running interactively. Skipped automatically in CI and non-TTY environments
451
+ - **Evidence output fix** - fixed `screenshotDiffs: Pundefined Aundefined` in the evidence section caused by iterating non-Lighthouse fields in multi-viewport results
452
+ - **URL fix** - corrected the pricing tip URL to point to the live domain
453
+ - Removed leftover `[Pro+]` and `[Pro]` labels from multi-viewport and mobile Lighthouse output
454
+
455
+ ### v1.3.3 - Cleaner output and route validation
456
+
457
+ - Removed `Pro` and `Pro+` labels from verification logs so `npx laxy-verify .` prints plan-neutral output
458
+ - Runtime-discovered routes are now validated before they are used for Lighthouse and broken-link checks, so bogus `404` bundle snippets do not poison the verification result
459
+
460
+ ### v1.3.2 - Auto port fallback
461
+
462
+ - If port `3000` or your configured verification port is already in use, `laxy-verify` now starts its temporary dev server on the next available port automatically
463
+ - `--port` keeps its existing meaning: attach to an already-running server instead of starting a temporary one
464
+
465
+ ### v1.3.1 - Publish fix
466
+
467
+ - Fix npm package contents so `login`, `logout`, and `whoami` ship with the required `dist/init-analysis.js` runtime dependency
468
+ - Republish the CLI artifact with the README badge, Pro history trend messaging, and Free-plan CLI tip aligned to the shipped code
469
+
470
+ ### v1.3.0 - Pro history trend, dynamic badge, CLI nudge
471
+
472
+ - **History trend tracking** - Pro accounts now store the last 30 verification runs. Grade and performance scores accumulate so you can see whether your app is improving or regressing over time
473
+ - **Dynamic README badge** - after each run, Pro accounts see a Markdown badge snippet in the CLI output. The badge auto-updates with every run via the `/api/badge/:id` endpoint
474
+ - **CLI nudge** - Free accounts see a one-line tip after each run pointing to the history trend feature
475
+ - Added `generateDynamicBadgeMarkdown(repoId, apiUrl)` export to the `badge` module
476
+ - Added `share_result` and `history_trend` flags to `EntitlementFeatures` interface
477
+ - 17 test files, 88 unit tests
478
+
479
+ ### v1.2.3 - Bug fix
480
+
481
+ - Fix E2E and visual diff connection failure on Windows with Node.js 17+: `verifyUrl` now uses `localhost` instead of `127.0.0.1`. On Windows, Vite binds to `::1` (IPv6) which does not accept IPv4 connections.
482
+
483
+ ### v1.2.2 - Opt-in verification checks
484
+
485
+ Added 7 opt-in checks (off by default, enable via CLI flags or `.laxy.yml`):
486
+
487
+ - `--typecheck` - TypeScript type error detection via `tsc --noEmit`
488
+ - `--secret-scan` - Hardcoded secret scanning with 11 regex patterns and `***` masking
489
+ - `--bundle-size` - Next.js/Vite bundle size analysis
490
+ - `--outdated-check` - Outdated dependency detection via `npm outdated`
491
+ - `--a11y-deep` - Deep WCAG audit via axe-core + Puppeteer
492
+ - `--seo-deep` - SEO meta/OG/JSON-LD audit
493
+ - `--vitals-budget` - Core Web Vitals budget enforcement (LCP, CLS, INP)
494
+
495
+ Other changes:
496
+
497
+ - Secret scan findings are **masked** - real credential values never appear in JSON, markdown, or console output
498
+ - Comment lines excluded from secret scanning to reduce false positives
499
+ - `test/`, `tests/`, `__tests__/`, `spec/` directories excluded from scanning
500
+ - `.laxy.yml` supports `secret_scan_ignore_paths` for custom exclusions
501
+ - Verification report includes all new checks in passes checklist and improvement recommendations
502
+ - Markdown report includes all new checks in the delivery evidence table
503
+ - Added `fixtures/sample-app/` test fixture (Vite + React + TypeScript)
504
+ - 17 test files, 88 unit tests
505
+
506
+ ## Links
507
+
508
+ - GitHub: https://github.com/SUNgm24/Laxy/tree/main/laxy-verify
509
+ - Issues: https://github.com/SUNgm24/Laxy/issues