Preview Environments
What DevDocs previews should expose for reviewers, automation, and operators.
Preview environments are the public rehearsal stage for a docs change. They should feel safe, reviewable, and close enough to production that a reviewer can trust the result.
Required behavior
- the docs root should load and stay on the expected route
/preview-statusshould surface lightweight review diagnostics- docs metadata should match the preview host
- protected environments should remain testable with automation bypass when configured
Preview-safe mode
Keep previews intentionally narrow
Previews are for review, not for broad managed-agent work. Heavy background automation should stay disabled unless the planned release explicitly requires it.
Event flow
| Trigger | Expected effect |
|---|---|
| Pull request open or sync | Refresh preview lifecycle state |
| Preview becomes reachable | Run lightweight verification |
| Review passes | Mark the preview ready for human promotion judgement |
| Pull request closes | Tear down preview-only resources |
Reviewer checklist
Load the docs root
Confirm the page lands on the correct route and still shows the branded docs experience, not a stale marketing shell.
Scan the shell, not just the copy
Verify the richer sidebar, sticky right rail, and root-section selector still behave correctly.
Check preview diagnostics
The diagnostics surface should clearly say that preview deployment is detected and that heavy managed work stays disabled.