Verification methodology
Every feature ships with production-verified, deterministic QA across Windows and macOS. The testing standards are reusable: adopt them in your own projects.
How it works
A single command triggers a five-step pipeline. No manual intervention required.
$ npm run test:e2e
> playwright test --project=chromium --project=webkit-desktop
Running 8 tests using 1 worker
✓ [chromium] site product runtime > lets users pick an IDE …
✓ [chromium] site product runtime > shows bundle explorer …
✓ [chromium] site product runtime > updates workflow state …
✓ [chromium] site product runtime > renders enterprise …
✓ [webkit-desktop] site product runtime > lets users pick …
✓ [webkit-desktop] site product runtime > shows bundle …
✓ [webkit-desktop] site product runtime > updates workflow …
✓ [webkit-desktop] site product runtime > renders enterprise …
8 passed (32.4s)Build in production mode
The launcher compiles a full production build into an isolated directory. No dev-server shortcuts, no hot-reload artifacts. The same output your users see.
Isolated .next-playwright directory prevents file-lock contention with local development on Windows and macOS.
Start the production server
A real HTTP server starts on a dedicated port. Playwright connects to it the same way a browser would in production.
Cross-platform: uses direct Node.js binary invocation instead of npm scripts for shell reliability.
Wait for readiness
Tests wait for React hydration before acting. The first interaction on each component retries until its handlers are live, so Playwright never drives server-rendered HTML that hasn't hydrated yet.
Prevents false failures from Playwright clicking server-rendered HTML before React hydration completes.
Verify rendered state
After every interaction, assertions check the derived UI: text content, attributes, visibility, not just whether the control accepted input.
A select option change isn't verified until the downstream card, text, or panel reflects the new state.
Produce evidence
Every run produces structured pass/fail output. Failures include screenshots. Retries include full execution traces. Results feed compliance and procurement workflows.
HTML reports, trace files, and video recordings are available for auditor review.
What this means for enterprise
Procurement
QA evidence is structured and auditor-ready. Pass/fail reports, failure screenshots, and trace files map directly to security questionnaire responses.
Compliance
Verification results feed into the governance audit trail. Evidence dashboards connect test outcomes to control requirements.
Cross-platform confidence
Chromium covers Windows Chrome/Edge. WebKit covers macOS Safari. Single-worker execution on Windows avoids file-lock contention. Parallel-safe on macOS.
Reusable standards
The same config templates, launcher scripts, and verification patterns apply to every project using the enterprise-skills hub. Scale QA governance across your org.
Browser matrix
| Browser | Coverage | Classification | Default run |
|---|---|---|---|
| Chrome / Edge (Chromium) | Windows + macOS desktop | Mandatory | Yes |
| Safari (WebKit) | macOS desktop | Mandatory | Yes |
| Mobile Chrome | Android phone viewport | Opt-in | No |
| Mobile Safari | iPhone viewport | Opt-in | No |
FAQ
Why desktop-only by default?
Enterprise B2B users work on Windows PCs and Macs. Chromium + WebKit desktop covers the vast majority of the real user base. Mobile phone-sized viewports are opt-in regression insurance, not a release gate. This is the standard for desktop-first B2B tools.
Can I add mobile coverage?
Yes. Mobile Chrome and mobile Safari projects are defined in the config and available via a dedicated command. Run them before major releases or marketing page updates.
How do I adopt this in my own project?
The testing standards, config templates, launcher script, and stateful-UI test patterns are all published as reusable templates in the enterprise-skills hub. Run the bootstrap-testing skill to scaffold everything automatically.
What about visual regression?
Playwright screenshot comparison is available as an optional tier. It's useful for design systems but not part of the default methodology: the product's value is in governance and workflows, not pixel-perfect rendering.
Who holds the signing key, and does the record depend on you?
The countersignature key is held server-side, and its public half is published, so every decision verifies offline, without this site. The ledger is append-only and per-tenant, and when a human overrides a decision, the override itself becomes a recorded entry with identity, reason, and scope.
Ready to ship with production-verified QA?
All the numbers
Every number the product can count, each captioned with the database table it comes from. An errored counter is dropped instead of showing as zero.
- 880
- release decisions
- 54
- FAIL verdicts from the gate
- 9
- repositories with recorded decisions
- 2,925
- skill runs
- 415
- countersigned ledger entries
- 0
- evidence bundles accepted
- 6
- deployment events
- 0
- human overrides
release_decisions
release_decisions
release_decisions
skill_usage_events
es_evidence_transparency_log
es_evidence_bundles
release_deployments
release_overrides
Some of these numbers are small: human overrides are rare because most gate decisions stand, and deployment events only accrue from repositories running the full truth loop. Findings totals come from the CLI's own count at sync time; the server stores them as reported.