supercov 0.0.47 → 0.0.49

package/README.md

@@ -152,11 +152,14 @@ cargo binstall supercov && supercov -- cargo test  # crates.io
 | Rust | Available | `npx supercov -- cargo test` |
 | Python | Available | `npx supercov -- pytest` |
 | Ruby | Available | `npx supercov -- rspec` |
+| Go | Available | `npx supercov -- go test ./...` |
+| Java | Available | `npx supercov -- mvn test` |
+| Kotlin | Available | `npx supercov -- ./gradlew test` |
 | Zig | Coming soon | — |
 | PHP | Coming soon | — |
 | C | Coming soon | — |
 
-Supercov requires Node.js 22 or newer. Rust support currently uses Rust 1.95; cargo-nextest 0.9.138 and 0.9.140 are supported. Python support requires CPython 3.12 or newer and measures pytest and unittest runs. Ruby support requires Ruby 3.3 or newer (3.4 or newer for full measurement) and measures RSpec, Minitest, test-unit and Cucumber runs.
+Supercov requires Node.js 22 or newer. Rust support currently uses Rust 1.95; cargo-nextest 0.9.138 and 0.9.140 are supported. Python support requires CPython 3.12 or newer and measures pytest and unittest runs. Ruby support requires Ruby 3.3 or newer (3.4 or newer for full measurement) and measures RSpec, Minitest, test-unit and Cucumber runs. Go support requires Go 1.22 or newer and measures `go test`. Java and Kotlin support requires a JDK 17 or newer with Maven or Gradle, and measures every JUnit Platform engine -- JUnit 5, JUnit 4 through Vintage, Kotest and Spock -- as well as TestNG.
 
 ## Supported operating systems and architectures
 
@@ -168,7 +171,7 @@ The CLI is a single native binary. `npx supercov` selects the build for the mach
 | Linux | arm64, x64 | glibc 2.28 or newer (Debian 10, Ubuntu 18.10, RHEL 8 and later), or musl (Alpine); chosen automatically |
 | Windows | arm64, x64 | Windows 10 or newer |
 
-JavaScript, TypeScript, Python, Ruby and Rust suites are verified on Linux, macOS and Windows -- CPython 3.12, 3.13 and 3.14, and Ruby 3.3, 3.4 and 4.0 on every one. Containers, VMs, and remote executors run the same Linux builds. Every release publishes the same binaries to npm, PyPI (`supercov-cli`, a wheel per platform) and RubyGems (`supercov`, a gem per platform except arm64 Windows, which Ruby has no platform for), and the source to crates.io (`supercov`).
+JavaScript, TypeScript, Python, Ruby, Rust, Go, Java and Kotlin suites are verified on Linux, macOS and Windows -- CPython 3.12, 3.13 and 3.14, Ruby 3.3, 3.4 and 4.0, and Go 1.22 and 1.25 on every one, and JDK 17 and 21 on every one that has them (Temurin publishes no 17 for arm64 Windows, so that pairing is 21 alone). Containers, VMs, and remote executors run the same Linux builds. Every release publishes the same binaries to npm, PyPI (`supercov-cli`, a wheel per platform) and RubyGems (`supercov`, a gem per platform except arm64 Windows, which Ruby has no platform for), and the source to crates.io (`supercov`).
 
 ## Supported test suites
 

package/docs/assertion-maps.md

@@ -70,7 +70,7 @@ examined and acknowledged.
 | `appliesTo` | Select tests by project-relative file and exact displayed test name. |
 | `nodes`, `edges` | Record source locations and relationships ending at `$assertion`. |
 | `countsAsAsserted` | List the node IDs you judge to be checked by the assertion. |
-| `watch` | List additional files the explanation depends on, such as helpers or configuration. |
+| `watch` | List additional files the explanation depends on, such as helpers or configuration. Manifests, lockfiles and runner configuration are already tracked for the whole run; naming one here catches nothing, and the report says so. |
 | `questions` | Record unresolved investigation questions. Questions inside a flow block its credit. |
 
 Source anchors use project-relative paths with `/`, one-based lines and one-based
@@ -108,13 +108,32 @@ token stale.
 ### What makes a review token stale
 
 A flow needs a fresh review when its claim changes, when a file it watches or a
-test it selects changes, or when the project's dependencies, configuration or
-the instrumenter change. The ambient environment does not count: running from
-another directory, a new terminal session, a different package manager or
-another Node installation leaves current flows current. A behavioural
-difference that matters still shows up on its own, because credit requires a
-passing assertion occurrence and execution of the claimed statement in the same
-selected test.
+test it selects changes, or when the configuration that decides what executes
+changes: a transpiler, a test runner, an interpreter pin.
+
+Several things that sound like they should count do not, because an
+acknowledgement demanded for all of them at once stops being read.
+
+Cutting a release does not. A manifest is fingerprinted by what it declares, so
+a version number moving in `package.json`, `Cargo.toml`, `pyproject.toml` or a
+lockfile changes nothing. Neither does reformatting one.
+
+Upgrading Supercov does not. Your claims are about your code, and a new release
+re-derives the evidence they rest on rather than making them wrong. Only a
+deliberate change to the instrumenter contract counts.
+
+Upgrading a dependency does not make every flow stale either. It is recorded
+once, as a change to assess, and flows keep their credit until that assessment
+says otherwise. One explanation answers for the upgrade.
+
+Linters, formatters, type checkers and coverage settings never count, because
+none of them change what the code does when it runs.
+
+The ambient environment does not count: running from another directory, a new
+terminal session, a different package manager or another Node installation
+leaves current flows current. A behavioural difference that matters still shows
+up on its own, because credit requires a passing assertion occurrence and
+execution of the claimed statement in the same selected test.
 
 If your suite genuinely depends on particular variables, name them; only the
 ones you name participate, and an unset variable is recorded as absent.

package/docs/cli.md

@@ -132,6 +132,115 @@ report. Follow the printed next-page command or JSON `pagination.nextOffset`.
 Validation supports `--view flows`, `--view changes` and `--view errors` for large
 maps. The [map reference](assertion-maps.md) describes all fields and gates.
 
+## Fail CI below a coverage floor
+
+```sh supercov-example
+supercov runs check --min-lines 90 --min-branches 80 --min-mcdc 80
+supercov runs check --min-lines 100 --per-file --json
+```
+
+`check` reads a recorded run; it never runs tests again. Give a floor per metric
+with `--min-lines`, `--min-statements`, `--min-functions`, `--min-branches` or
+`--min-mcdc`. `--per-file` applies the same floors to every file that has
+eligible obligations, in addition to the whole run. Both report the counts
+behind the percentage and, for lines, where the gaps are.
+
+Floors are compared against the counts, never a rounded percentage: 9,999
+covered lines out of 10,000 displays as 99.99% and fails a 100% floor, and a
+run that displayed `100.00%` could never pass one while something is uncovered.
+
+A check answers only when the run can answer. These end the command with `2`
+rather than a pass or a failure:
+
+- the wrapped test command did not pass, so a gate over it would turn a red CI
+  run green
+- the run no longer matches the current checkout
+- a requested metric has nothing eligible, which is not the same as complete
+- a requested metric left obligations unmeasured, so no exact judgement exists
+- a requested metric is not recorded by the language adapter
+
+Assertion coverage keeps its own check. Whether a test *examines* what it
+executes is a different question from whether a line ran, and
+`runs <id> assertions check` carries the freshness and acknowledgement rules
+that answer needs.
+
+## Check the lines a change touches
+
+```sh supercov-example
+supercov runs patch --base origin/main --min-lines 100
+supercov runs patch --base origin/main --annotate github
+```
+
+`patch` answers whether the lines this change added or modified are tested. It
+compares against the **merge base** with `--base`, not that branch's tip, so
+commits other people landed after you branched are not counted as your
+obligation. A shallow checkout has no merge base; fetch with full history
+(`actions/checkout` takes `fetch-depth: 0`).
+
+The denominator is the changed lines the run measured. Comments, blank lines and
+declarations fall out because the language adapter already decided they are not
+executable, not because `patch` guesses at syntax. Deleted lines are excluded:
+there is nothing left to cover. Untracked new source counts as entirely added.
+
+A change with nothing executable in it reports **No executable changes** and
+passes, rather than claiming 100% for a patch that changed only comments. A
+changed file that looks like product source but is absent from the run is named
+separately, because treating it as zero uncovered lines would report success for
+code nothing ran.
+
+`--annotate github` prints workflow-command annotations on stdout, combining
+adjacent misses into one range and capping the total (`--max-annotations`). It
+needs no token and posts no comment.
+
+## Export for other tools
+
+```sh supercov-example
+supercov runs report --format lcov --output coverage/lcov.info
+supercov runs report --format cobertura --output coverage/cobertura.xml
+supercov runs report --format html --output coverage/report
+```
+
+Both are written from the same view `check` and `patch` read, so a viewer,
+hosted service or CI integration sees the totals Supercov enforced. Paths are
+repository-relative with forward slashes, ordering is stable, and the file is
+written atomically; an existing file is kept unless you pass `--force`. Without
+`--output` the report goes to stdout and diagnostics to stderr, so a redirect
+captures only the report.
+
+Supercov records that a line ran, not how many times, so `DA:` and `hits` state
+`1` or `0`. They are not execution frequencies, and Supercov will not invent
+one to fill a field.
+
+MC/DC conditions are not exported as ordinary branches. A consumer would then
+show condition obligations as branch coverage, which is a different
+measurement; that evidence stays in the JSON view and the HTML report. A report
+from a failed or stale run is still written, with a warning on stderr — only
+`check` refuses to pass on one.
+
+### The HTML report
+
+`--format html` writes one self-contained document. It opens from a copied CI
+artifact with no server, no network and no login, and nothing is fetched from a
+CDN. Because a source path is never used as an output path, a filename cannot
+write outside the directory you named, and no directory is ever cleared to
+regenerate a report.
+
+It has three levels: the run's metric counts, a filterable and sortable file
+table, and a source view marking each line covered or not covered in words and
+a glyph as well as colour. Every line links as `#<file>:<line>`, so a CI summary
+can point someone at the obligation rather than at the report.
+
+Four states stay distinct, because collapsing them into one score is how a
+report starts to mislead: **uncovered** (measured, nothing reached it), **not
+applicable** (nothing eligible), **partly measured** (Supercov declined some
+obligations, which are excluded from every count) and **stale** (the run no
+longer matches the checkout). A failed suite says so beside its numbers.
+
+Source text is embedded only when the run still matches the checkout; otherwise
+the report shows line numbers and explains why. Embedding makes a report
+portable and also means it contains your code — worth knowing before uploading
+one as a public artifact.
+
 ## Narrow a view
 
 | Option | Meaning |
@@ -233,4 +342,5 @@ SUPERCOV_TEST_KIND=e2e npx supercov -- npx playwright test
 | --- | --- |
 | `0` | The command or query succeeded |
 | Wrapped command's code | The test command failed and Supercov preserved its status |
-| `2` | Supercov could not complete the request |
+| `1` | A valid measurement failed a policy you set, such as a coverage floor |
+| `2` | Supercov could not complete the request, or the evidence cannot answer it |

package/docs/getting-started.md

@@ -16,7 +16,7 @@ When it finishes, review the test change and coverage comparison in your
 conversation. Ask separately if you want a commit or pull request.
 
 No account, config file, import, custom reporter, or hosted service is required.
-Supercov supports JavaScript, TypeScript, Rust, Python, and Ruby today.
+Supercov supports JavaScript, TypeScript, Rust, Python, Ruby, Go, Java, and Kotlin today.
 
 ## What the agent does
 
@@ -108,6 +108,8 @@ if anything is missing.
 - a working test command, including its dependencies, environment variables,
   and any local services;
 - for Rust, the Rust 1.95 toolchain;
+- for Go, Go 1.22 or newer;
+- for Java and Kotlin, JDK 17 or newer, with Maven or Gradle;
 - for Python, CPython 3.12 or newer with pytest or unittest;
 - for Ruby, Ruby 3.4 or newer with RSpec, Minitest, test-unit or Cucumber (3.3 measures lines, methods and simple branches only).
 

package/docs/supported-suites.md

@@ -1,6 +1,6 @@
 # Supported languages and test suites
 
-Supercov supports JavaScript, TypeScript, Rust, Python, and Ruby today. Start with
+Supercov supports JavaScript, TypeScript, Rust, Python, Ruby, Go, Java, and Kotlin today. Start with
 the same test command the repository already uses; Supercov detects supported
 runners inside that command.
 
@@ -10,6 +10,8 @@ npx supercov -- npx playwright test
 npx supercov -- cargo test
 npx supercov -- pytest
 npx supercov -- rspec
+npx supercov -- go test ./...
+npx supercov -- mvn test
 ```
 
 ## Language support
@@ -21,6 +23,9 @@ npx supercov -- rspec
 | Rust | Available | `npx supercov -- cargo test` |
 | Python | Available | `npx supercov -- pytest` |
 | Ruby | Available | `npx supercov -- rspec` |
+| Go | Available | `npx supercov -- go test ./...` |
+| Java | Available | `npx supercov -- mvn test` |
+| Kotlin | Available | `npx supercov -- ./gradlew test` |
 | Zig | Coming soon | — |
 | PHP | Coming soon | — |
 | C | Coming soon | — |
@@ -211,6 +216,131 @@ npx supercov -- ruby -Itest test/shapes_test.rb
 npx supercov -- bin/rails test
 ```
 
+## Go
+
+| Runner | Attribution | Current requirement |
+| --- | --- | --- |
+| `go test` | Exact per test | Go 1.22 or newer |
+| A test that calls `t.Parallel()` | Aggregate: its coverage counts run-wide | — |
+| An `Example` with an `Output` comment, and a `Fuzz` target's seed corpus | Aggregate: measured, but named by no test | — |
+
+Supercov instruments an isolated copy of the module and runs your own command
+against it. Your tree is not touched, and your test sources are not rewritten
+beyond one deferred line per test that binds it to its evidence.
+
+`go test` builds one binary per package, so each test package records its own
+evidence and Supercov merges them. It also caches packages that passed, and a
+cached package does not run — so Supercov adds `-count=1` unless your command
+already says otherwise, and tells you it did.
+
+A test that calls `t.Parallel()` runs alongside others. Probes are a store into
+one array shared by the process, so nothing can say which of two concurrent
+tests reached a line. That coverage is reported against the run rather than
+assigned to a test by guesswork: the lines count as covered, and no test claims
+them. It counts only when the run passed, for the same reason a failing test's
+coverage never counts — a failed run cannot say which of it came from the test
+that failed.
+
+An `Example` with an `Output` comment and a `Fuzz` target's seed corpus are
+measured the same way. `go test` runs both, so what they reach is real
+coverage, but neither takes a `*testing.T` for a result to be named by.
+
+Supercov also writes evidence as the suite runs, not only at the end. Go offers
+no way to run code on `os.Exit`, and a `TestMain` need not reach the `m.Run()`
+call Supercov wraps — `goleak.VerifyTestMain(m)` runs the suite and exits
+itself. Without periodic writes such a run recorded nothing at all.
+
+For assertion maps, `t.Error`, `t.Errorf`, `t.Fatal`, `t.Fatalf` and testify's
+`assert` and `require` are inventoried. A Go test states its claim with an `if`
+and reports the violation, so the report is the site.
+
+A repository with several modules works either way it is laid out. A directory
+with a `go.mod` of its own that no `go.work` names is a different module, and
+`go test ./...` walks past it, so Supercov leaves it alone. A `go.work`
+workspace has no module at its root, so each module it names gets a runtime of
+its own.
+
+```sh
+npx supercov -- go test ./...
+npx supercov -- go test -run TestParser ./internal/...
+npx supercov -- go test ./core/... ./app/...
+```
+
+## Java and Kotlin
+
+| Runner | Attribution | Current requirement |
+| --- | --- | --- |
+| JUnit 5 (Jupiter) | Exact per test | JDK 17 or newer, Maven or Gradle |
+| JUnit 4 (through Vintage) | Exact per test | — |
+| Kotest | Exact per test, under the names Kotest itself reports | — |
+| Spock | Exact per feature, under the names Spock itself reports | — |
+| TestNG | Exact per test, each data-provider invocation its own | — |
+| JUnit 4 alone | Exact per test, through Vintage — see below | Maven |
+
+Multi-module builds are measured module by module: each compiles its own source
+set and forks its own JVM, so each gets a runtime and records evidence of its
+own, and the run merges them. A build that forks several JVMs to run tests in
+parallel — Gradle's `maxParallelForks`, surefire's `forkCount` — is measured
+the same way: each JVM writes evidence of its own and the run merges every
+one.
+
+Attribution comes from the framework's own lifecycle rather than from rewritten
+test sources: a JUnit Platform listener sees every engine built on the platform,
+which is what covers Kotest and Spock, whose tests are not annotated methods any
+rewriter could find. TestNG is not a platform engine and has a listener of its
+own. Tests keep the names their framework chose, so a coverage report and a test
+report name the same thing.
+
+JUnit 4 on its own is not a platform engine and does not run on one. Maven and
+Gradle choose a test provider from what is on the classpath, so putting the
+platform there makes the build pick a provider that finds no engine and fail.
+For a Maven module, Supercov adds `junit-vintage-engine` to the copy — the
+platform's own way of running exactly those JUnit 4 tests through the lifecycle
+it listens to — and measures them; your own build still runs JUnit 4 as it did.
+A Gradle module is left alone and told about rather than broken.
+
+Supercov instruments an isolated copy and leaves your build file alone. In the
+copy it adds a test-scoped `junit-platform-launcher`, because the listener is
+compiled from the project's test sources and neither Maven nor Gradle puts that
+API on the compile classpath; it disables JUnit's parallel execution, keeping
+whatever else your `junit-platform.properties` set; and it stops the copy
+failing its build on warnings, because the copy holds instrumented code your
+project never wrote a style policy for. Warnings are still reported.
+
+If tests do run concurrently anyway, Supercov says so and stops attributing
+rather than reporting numbers nobody can trust: statements and branches still
+count run-wide, and condition coverage is dropped, because concurrent
+evaluations corrupt the state it is computed from.
+
+Some conditions are read by the compiler as well as evaluated at runtime, and
+those Supercov leaves exactly as written. `x instanceof String s`, a record
+deconstruction pattern, and Kotlin's `x is String` or `x != null` all narrow a
+type for the code beneath them; wrapping such a condition to observe its
+operands would take the narrowing away and the code would stop compiling. An
+`if` is still measured — which way it went is recorded from inside its arms
+instead — but it carries no condition vectors, so it contributes no MC/DC
+obligation. A loop is a harder case: it has one arm, and no place to record an
+exit a `break` would not also reach, so a loop whose condition narrows a type
+carries no branch obligation at all rather than one no test could close. The
+same goes for a loop over a constant, `while (true)`, which can only go one
+way. A Kotlin `contract { }` has to stay the first statement of its function,
+so the probe that records the function being entered is written after it.
+
+Every one of these is named in the run: ask for `supercov runs latest
+limitations` and each appears with its file, its line, and why it was left
+alone. A source file the parser cannot read is declared there too, so a hole in
+the denominator stays visible after the build log is gone.
+
+For assertion maps, forms spelled `assertSomething`, `assertThat` or `fail` are
+inventoried, which covers JUnit, TestNG, AssertJ, Hamcrest and kotlin.test.
+Kotest's infix matchers are not.
+
+```sh
+npx supercov -- mvn test
+npx supercov -- ./gradlew test
+npx supercov -- ./mvnw verify
+```
+
 ## Containers, VMs, and remote execution
 
 Supercov can collect from supported processes launched through a container, VM,

package/docs/troubleshooting.md

@@ -75,6 +75,33 @@ Its lines, methods and simple branches stay measured; everything that needs a
 probe is declared as a measurement limit for that file. Please report the file,
 since Supercov aims to instrument every Ruby source correctly.
 
+## A test that reads your source fails under Supercov
+
+A test that opens your source files and asserts on their text sees the probes,
+because that is what instrumentation is. RxJava has one: `CheckCatchThrowIfFatal`
+reads every `catch` block in the project and requires the first statement to be
+`Exceptions.throwIfFatal`, and under Supercov the first statement is a probe. An
+architecture or convention test that scans bytecode or source can fail the same
+way.
+
+Nothing is wrong with the measurement and nothing your code does has changed --
+the run still records every test that ran -- but the command exited non-zero, so
+its coverage is reported as diagnostic and cannot gate. Leave that one test out
+of the command you give Supercov. Surefire excludes by name:
+
+```sh supercov
+npx supercov -- mvn test -Dtest='!CheckCatchThrowIfFatalTest'
+```
+
+Gradle's `--tests` only includes, so exclude it in your build file instead --
+Supercov measures the copy, and your own build is unaffected by what it runs:
+
+```groovy
+test { filter { excludeTestsMatching "*CheckCatchThrowIfFatal*" } }
+```
+
+Either way your own build still runs the test, against your own sources.
+
 ## A run is marked stale
 
 A stored run remains valid history, but it stops describing the current

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "supercov",
-  "version": "0.0.47",
+  "version": "0.0.49",
   "description": "Coverage for coding agents and software factories \ud83c\udf19",
   "license": "MIT",
   "repository": {
@@ -76,7 +76,7 @@
     "benchmark:check": "cargo build --release -p supercov && node scripts/rust-transform-benchmark.mjs",
     "benchmark:python-monitoring": "cargo build -p supercov && node scripts/python-monitoring-benchmark.mjs",
     "check": "cargo fmt --all -- --check && cargo clippy --workspace --all-targets -- -D warnings && npm run test && npm run test:runtime && npm run test:rust-assets && npm run test:assertion-maps && node scripts/package-preflight.mjs && node scripts/verify-binstall-metadata.mjs --offline",
-    "release:check": "cargo clean && node scripts/sweep-target.mjs && npm run check && npm run test:engine && npm run test:fixture && npm run test:watchdog && npm run test:engine-contract && npm run test:agent && npm run test:child-attribution && npm run test:host-loader && npm run test:python-monitoring && npm run test:ruby-coverage && npm run test:rust-public-cargo && npm run test:packed-npx && npm run test:clang-mcdc && npm run benchmark:check",
+    "release:check": "cargo clean && node scripts/sweep-target.mjs && npm run check && npm run test:engine && npm run test:go && npm run test:jvm && npm run test:fixture && npm run test:watchdog && npm run test:engine-contract && npm run test:agent && npm run test:child-attribution && npm run test:host-loader && npm run test:python-monitoring && npm run test:ruby-coverage && npm run test:rust-public-cargo && npm run test:packed-npx && npm run test:clang-mcdc && npm run benchmark:check",
     "release:bump": "node scripts/bump-version.mjs",
     "sweep": "node scripts/sweep-target.mjs",
     "oracle:rust": "cargo build --release -p supercov && node scripts/rust-coverage-oracle.mjs",
@@ -86,6 +86,8 @@
     "test:host-loader": "cargo build -p supercov && node scripts/rust-host-loader-integration.mjs",
     "test:python-monitoring": "cargo build -p supercov && node scripts/python-monitoring-integration.mjs",
     "test:ruby-coverage": "cargo build -p supercov && node scripts/ruby-coverage-integration.mjs",
+    "test:go": "cargo test --no-fail-fast -p supercov-engine --test go_frontend --test go_run",
+    "test:jvm": "cargo test --no-fail-fast -p supercov-engine --test jvm_frontend --test jvm_run -- --include-ignored --test-threads=1",
     "test:rust-public-cargo": "cargo build -p supercov && node scripts/rust-public-cargo-integration.mjs",
     "test:assertion-maps": "cargo build -p supercov && node scripts/assertion-map-schema.mjs --check && node scripts/assertion-map-integration.mjs && node scripts/assertion-map-js-integration.mjs && node scripts/assertion-dogfood-integration.mjs",
     "test:assertion-maps:js": "cargo build -p supercov && node scripts/assertion-map-schema.mjs --check && node scripts/assertion-map-js-integration.mjs && node scripts/assertion-dogfood-integration.mjs",
@@ -94,14 +96,14 @@
     "docs:check": "node scripts/sync-docs.mjs --check"
   },
   "optionalDependencies": {
-    "@supercov/cli-darwin-arm64": "0.0.47",
-    "@supercov/cli-darwin-x64": "0.0.47",
-    "@supercov/cli-linux-arm64-gnu": "0.0.47",
-    "@supercov/cli-linux-arm64-musl": "0.0.47",
-    "@supercov/cli-linux-x64-gnu": "0.0.47",
-    "@supercov/cli-linux-x64-musl": "0.0.47",
-    "@supercov/cli-win32-arm64": "0.0.47",
-    "@supercov/cli-win32-x64": "0.0.47"
+    "@supercov/cli-darwin-arm64": "0.0.49",
+    "@supercov/cli-darwin-x64": "0.0.49",
+    "@supercov/cli-linux-arm64-gnu": "0.0.49",
+    "@supercov/cli-linux-arm64-musl": "0.0.49",
+    "@supercov/cli-linux-x64-gnu": "0.0.49",
+    "@supercov/cli-linux-x64-musl": "0.0.49",
+    "@supercov/cli-win32-arm64": "0.0.49",
+    "@supercov/cli-win32-x64": "0.0.49"
   },
   "peerDependencies": {
     "@playwright/test": ">=1.55.0",