Preview in the product

Validation tests package consistency. A person must also examine whether the preview shows the intended content correctly.

Build and open a stored case

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

The command uses the first review case if you omit --case. It stores the preview under <data-root>/feed-packages/dev. The data root defaults to ~/.fruitful through FRUITFUL_AUTHORING_DATA_ROOT. Use --local-data-root to select another directory.

The command opens the Desktop app through fruitful-development://open. Use --no-open to create the artifact without an app launch. The preview remains available after the command exits.

Open a new capture's result

For MCP capture validation, use the preview returned by validate_capture_package. Its desktopUrl opens the exact result. Its previewPath gives the app route. The stored snapshot is <data-root>/feed-packages/dev/<package-name>/preview.json. Do not reconstruct records from fixture fields or put captured content in a query string.

The preview consumes the exact RegistryActivityPresentationEnvelope from the locked graph. It uses the same compact and expanded Activity surfaces as the Inbox. A separate preview renderer cannot prove the product result.

Examine the result

Examine both the Preview Inbox row and its Reader detail:

• Make sure the feed and case names are clear.
• Make sure the package's exact compact and reader A2UI surfaces render correctly.
• Open provenance through the standard Activity control.
• Make sure unavailable linked content has an accurate explanation.
• Keep package IDs, versions, digests, transport details, tab chrome, and mutation controls out of the primary reading UI.

Test selection, keyboard movement, refresh, and browser history. Record the case, clients examined, and remaining product limitations.

Repair an incorrect entry

Keep extraction errors separate from personal preferences. A correctly extracted entry can still be irrelevant to you. A relevance preference does not justify changing its identity or discarding correct source data.

1. Record the capture ID or review case, package revision, resolution digest, and preview artifact.
2. Identify the affected record by its stable identity.
3. Identify the incorrect value or missing entry. Give the expected title, author, link, or other affected field.
4. Edit the canonical Lexicon, binding, transform, or presentation files.
5. Validate the candidate against the active evidence and each stored review case.
6. Examine changes to expected records and presentation to make sure their meaning is correct.
7. Create a preview after validation passes.
8. Examine the new preview.

Use Validate the package and its coverage for the required commands and reports. Do not change record identities only to hide an incorrect result.

Keep the last preview artifact that passed validation until the candidate passes. If the candidate fails, report its diagnostics. Identify the last preview that passed validation. Do not show the failed candidate as a preview that passed validation. This procedure preserves an artifact for comparison. It does not supply an automatic rollback control in the product.

Product failures

Treat these behaviors as failures at the product boundary:

• A separate data projection for the preview.
• Presentation selected by provider name.
• Duplicate A2UI hydration.
• A generic Inbox card that hides incomplete package presentation.

Repair the package or the shared Activity surface. Do not add another preview renderer. For changes to client routing or presentation, run the package-authoring-preview Product Scenario for both web and Electron. Follow test/CLAUDE.md in the repository for the hermetic stack. Examine the scenario screenshots.

Reference: Compact and reader surfaces.