Release Proof
The checks and evidence that should exist before and after a docs change lands.
Shipping a docs change should feel as disciplined as shipping an application change. The surface is public, branded, and product-defining, so it deserves proof.
Local proof
The minimum local checks stay the same:
npm run typechecknpm run lintnpm run build
For preview-sensitive work, the stronger loop matters:
npm run preview:review-localnpm run preview:prove-localnpm run delivery:prove-local
What the proof should establish
The docs tree, routes, metadata, and preview diagnostics all resolve correctly.
Browser review confirms the layout, navigation, auth boundaries, and key product copy still behave the way the feature expects.
Screenshots, test results, and the evidence packet should make it possible to review the release after the fact.
Production proof
Verify the merged site
Check the production docs route and confirm the live experience still matches the intended layout and navigation.
Verify auth boundaries
Make sure public docs stay public, while the control plane remains protected and routes to the correct sign-in surface.
Verify the deployment story end to end
A successful build is not enough. The live site should actually render the improved shell and content.