Problem
Reviewing a UI change currently means checking out the branch and running it
locally. That is friction for maintainers and a genuine barrier for outside
contributors, who cannot easily show what their change looks like.
What to do
- Preview deployment per pull request, with the URL posted as a comment.
- Preview builds must point at testnet and staging services, never production —
and must be visibly badged as previews.
- Block indexing on preview domains (see the robots issue) so they do not
compete with production in search results.
- Run Lighthouse against the preview and post the scores, so performance and
accessibility regressions are visible in review.
- Expire previews on merge or close so they do not accumulate.
Acceptance criteria
Notes
Posting Lighthouse scores in the pull request is what makes the accessibility
and performance work stick — otherwise regressions are only caught when someone
remembers to audit.
Problem
Reviewing a UI change currently means checking out the branch and running it
locally. That is friction for maintainers and a genuine barrier for outside
contributors, who cannot easily show what their change looks like.
What to do
and must be visibly badged as previews.
compete with production in search results.
accessibility regressions are visible in review.
Acceptance criteria
Notes
Posting Lighthouse scores in the pull request is what makes the accessibility
and performance work stick — otherwise regressions are only caught when someone
remembers to audit.