Proof check reference
Account for configured build targets
A result from one configuration should not silently stand in for every supported target. This check compares declared build targets with the configuration labels attached to collected test results.
What the check reads
The verify-stage check has warning severity and skips when no build targets are configured. For each target, it normalizes the target’s config tokens and looks for a test result whose config includes all of them. A result may contain additional tokens. An empty target configuration has no match. The matching predicate does not inspect result status, freshness or execution provenance, and it does not derive targets from source-level conditional compilation.
proof audit --check build_matrix_completeAn illustrative case
Illustrative case: the project declares linux with amd64 and linux with arm64 as separate targets. A result labeled linux, amd64 can cover the first configured token set, but cannot cover arm64. Conversely, an arm64-labeled failed result can satisfy this inventory check even though the tests failed. The distinction matters when someone reads “matrix complete” as evidence that every platform passed.
Resolve the finding
- Inspect the declared build_targets and identify the configurations your release actually supports. Use meaningful tokens that distinguish relevant runtime, architecture or feature variants.
- Run the relevant suite on each missing configuration and import results with accurate config labels. Do not add a target label to evidence produced on a different environment.
- Rerun the matrix check, then examine failures, revision freshness and execution provenance separately. Review issue-specific platform coverage when a KnownIssue has a narrower or different impact.
What a clear result means
A clear result establishes metadata coverage of the configured targets. It does not show that every build or test passed, that the matrix is exhaustive or that a particular failure is fixed on every target. Keep the target inventory, actual run outcomes and supported-platform claim visible as separate parts of the release decision.
Continue with one real issue
Known issue platform coverage · Known issue closure platform bound
Bring one finding, its requirement and the current evidence to scope a walkthrough of what your reviewer can establish and what still needs work.