vulkro-sf coverage-attest and vulkro-sf coverage-risk
vulkro-sf coverage-attest and vulkro-sf coverage-risk are part of Pro: Org-scale operations (sf-org-scale), recertification, limits, coverage risk and masking rules. On Free it stops before doing any work, prints what it needs and where to get it, and exits 1. See Pricing.
Two subcommands that turn raw Apex test coverage into something a
reviewer can act on. coverage-attest produces a signed-off coverage
record for a deploy: which classes are covered, by how much, and
whether the change set meets the bar. coverage-risk goes further and
weights the gaps by business-process criticality, so a 70 percent
class on a billing path ranks above a 70 percent class on an internal
utility.
Both run over a coverage report you supply (exported from your test run) plus the local project. No org connection is required by the commands themselves.
vulkro-sf coverage-attest
Synopsis
vulkro-sf coverage-attest [PATH] --coverage <path> [flags]
PATH defaults to the current directory. --coverage points at the
coverage report exported from your Apex test run.
Flags
| Flag | Type | Default | Description |
|---|---|---|---|
--coverage <path> | string | (required) | The Apex coverage report to attest (the export from your test execution). |
--threshold <pct> | integer | 75 | The minimum per-class coverage percentage the attestation requires. |
--format <fmt> | enum | table | Output format: table (human-readable attestation summary) or json (machine-readable attestation record, for a deploy gate or an audit trail). |
Exit codes
0- every class in scope meets the threshold; the attestation passes.1- one or more classes fall below the threshold; the attestation records the shortfall.2- error: the coverage report could not be read or parsed, or an internal error. The message names the cause and the next step.
What it does
coverage-attest reads the coverage report, joins it against the
classes in the project, and produces an attestation: a per-class record
of covered lines, coverage percentage, and pass or fail against the
threshold. The record is the artifact you attach to a deploy or an
audit to show the coverage bar was met, with the specific classes that
did or did not clear it.
vulkro-sf coverage-risk
Synopsis
vulkro-sf coverage-risk [PATH] --coverage <path> [flags]
Flags
| Flag | Type | Default | Description |
|---|---|---|---|
--coverage <path> | string | (required) | The Apex coverage report to evaluate. |
--criticality <path> | string | (none) | A business-process criticality map that tags classes or objects with a criticality weight. When omitted, all classes are weighted equally. |
--format <fmt> | enum | table | Output format: table (human-readable ranked risk summary) or json (machine-readable risk records, for a triage tool). |
Exit codes
0- no coverage gap crosses the risk-reporting threshold.1- one or more coverage gaps were reported, ranked by criticality.2- error: the coverage report or criticality map could not be read or parsed, or an internal error. The message names the cause and the next step.
What it does
coverage-risk reads the coverage report and the criticality map, then
ranks each coverage gap by the criticality of the business process the
class supports. A thin-coverage class on a critical path (billing,
provisioning, customer-facing automation) ranks above an equally thin
class on a low-criticality utility. This turns "raise coverage
everywhere" into "raise coverage here first", which is the prioritization
a real team needs.
Example
# Attest a deploy at the default 75 percent bar.
vulkro-sf coverage-attest . --coverage ./coverage.json
# Attest at a stricter bar, as a JSON audit record.
vulkro-sf coverage-attest . --coverage ./coverage.json --threshold 85 \
--format json > attestation.json
# Rank coverage gaps by business-process criticality.
vulkro-sf coverage-risk . --coverage ./coverage.json \
--criticality ./criticality.yaml