Experience validation and reproducibility
Relevance, reproducibility, and authorization are distinct questions. Search ranking, author scores, and one successful run do not replace evidence for the target task.
Use a checkable example
For an asset claiming to fix a menu clipped at 320px, open the same page with matching data and viewport. Verify every option is visible and clickable, then check desktop behavior. Formatting checks and exit code zero do not prove the menu was fixed.
Record input and environment, target behavior and allowed effects, actual assertions and interactions, failures and skips, and the scope of the reuse conclusion. See developer review and validation for execution. Desktop readers should inspect task results; an asset score is not a reason to run CLI commands or promote trust.
Fix conditions first
Record asset ID, source, signals, runtime, dependencies, and repository revision. Read the complete asset and referenced scripts. Define allowed effects, validation commands, and recovery before selecting an isolated or low-impact environment.
Inspect actual results
Keep commands, working directory, exit status, key assertions, actual diff, and external effects. Exit code zero without the required assertion does not prove the objective. Record missing commands, skipped checks, timeouts, and absent output separately from success.
Reproduce with unchanged input and asset first, then vary one meaningful environment condition. Compare behavior and side effects, not just exit codes. Preserve failures, mismatches, and expired evidence.
Decide on reuse
Evidence must explain scope and limitations. Cross-node results require equivalent inputs and validation; more nodes do not repair weak assertions. Successful validation still leaves trust promotion, execution authorization, and publication as separate decisions.