The essentials
From change to review.
Follow a pull request through planning, browser execution, and evidence review.
1. Start with the change
The GitHub App is Diffraction’s entry point for pull-request review. Repository and change context help identify the surfaces that may affect the UI, including shared components, styles, routes, and interaction logic.
A review belongs to a specific commit. When a pull request changes, the new revision needs its own review; the old recording remains evidence of the old code.
2. Plan the important flows
The review plan connects the change to meaningful user actions. It describes what to inspect, why it matters, and which browsers and viewports are in scope.
Project commands, routes, expectations, and review budgets belong in versioned configuration. Credentials and other private values belong in secret stores, outside repository configuration.
3. Run and record
The changed application runs in an isolated environment. Browser execution follows the selected flows and records the actions and evidence for each target.
A failed setup or blocked flow limits what the run can establish. That missing coverage must remain visible rather than being treated as a successful review.
4. Inspect the result
Start with the review scope and status. Then inspect each finding in context: the triggering action, the observed behavior, the expected result, and the supporting recording.
Use the evidence to decide what to change. After a fix, a new execution is needed to establish that the affected experience works at the new revision.