Validate and check coverage
Read the two reports that decide whether a package is correct.
Two commands stand between a package and a release. Coverage answers "does the binding read the page?". Validate answers "does the whole package produce the right records, deterministically, and render them?".
Coverage
yarn fruitful plugin coverage feed-packages/<name> --jsonPer fixture, coverage reports:
matchedEntryCount,extractedEntryCount,processedEntryCount: how many entries theentryselector found, how many produced an extract, how many survived post-processing.requiredFieldsand, per entry, which were missing. A required-field gap on any entry is a problem to explain or fix.neverObservedFields: declared fields no entry had. Either the selector is wrong or the field should not be required.rejectedEntryIndexes: entries the post-processor dropped, with the reason.entries[].semanticSignature: the set of fields each entry had, so you can see every shape the page produced.
Require complete coverage: no unexplained required gaps or rejections, and every observed semantic shape represented in a fixture.
Validate
yarn fruitful plugin validate feed-packages/<name> --jsonThe summary is the canonical, content-free view of the evaluator. It runs every review case through the locked route, binding, transform, and presentation, and reports:
| Check | What passing means |
|---|---|
execution | the transform ran inside the sandbox without error on every case |
determinism | two runs produced byte-identical output |
coverage | the coverage thresholds above hold |
lexicons | every record validated against its pinned Lexicon |
views | buildView produced a valid View for every root |
goldens | records match the committed expectation |
presentation | rendered surfaces match the committed presentation examples |
Per case it lists record counts by type, input and output digests, golden agreement, and diagnostics. resolutionDigest at the top is the exact package graph that was evaluated.
What the summary does not prove
It cannot tell you the record values are right, that the Activity root's identity is stable, that a fixture was approved, or that the presentation means what you intended. Review those against the approved evidence, the product preview, and the release.
Generate, then check
Regeneration is how expectations and presentation examples are produced; checking is how CI knows they are current:
yarn fruitful plugin generate feed-packages/<name> --write --json
yarn fruitful plugin generate feed-packages/<name> --check --jsonReview regenerated expectations as semantic diffs. If a golden changes identity or relationships unexpectedly, stop and repair the Lexicon, binding, or transform first.
Reference: CLI.