Preview in the product

Validation proves the package is consistent with itself. The preview shows whether it is good: a human reads the row and the reader view as a user would.

Build and open it

yarn fruitful plugin preview feed-packages/<name> --case <review-case-id> --json

The case defaults to the first review case. The command builds a durable preview under <data-root>/feed-packages/dev (default ~/.fruitful, override with --local-data-root) and opens it in the Desktop app through fruitful-development://open. --no-open skips the launch. The preview survives the command exiting.

The preview consumes the exact presentation envelope the locked package graph produced and renders it through the same compact and expanded Activity surfaces as the Inbox. It is a product checkpoint, not another renderer.

What to look at

In the Preview Inbox row and its reader detail, confirm:

• feed and case names read clearly;
• the package's exact compact and reader surfaces render;
• provenance opens through the standard Activity affordance;
• unavailable linked content is described accurately;
• package ids, versions, digests, transport details, and mutation controls do not appear in the reading UI.

Exercise selection, keyboard movement, refresh, and browser history.

What counts as a failure

A preview-only projection, a branch on the provider name, duplicate surface hydration, or a generic Inbox card fallback is a product-boundary failure. Fix the package or the shared Activity surface; never add a preview renderer.

When the change touches client routing or presentation, also run the package-authoring-preview Product Scenario for web and Electron against a hermetic stack (see the repository's test/CLAUDE.md) and inspect its screenshots.

Reference: Compact and reader surfaces.