6 Ship with confidence
Publishing is a sequence of independently verifiable states. A successful local preview proves that the content and theme can render together; it does not prove that a remote module tag exists or that the public site has deployed that revision.
Name every delivery state
| State | Evidence | What it does not prove |
|---|---|---|
| Local preview | The site renders against the intended checkout | A public theme release exists |
| Site integration | Content, configuration, and dependency changes are reviewed together | The hosting platform has deployed them |
| Theme release | The public tag and module checksum resolve without a local replacement | A consumer site has upgraded |
| Hosted deployment | The public revision and representative routes are reachable | Every language and viewport is correct |
Validate the smallest useful surface
Start with the checker that owns the changed contract, then widen the scope. For this site, a strict local build against the sibling theme checkout is an explicit development operation:
Before a public release, repeat the build without the replacement and verify
the module selected by go.mod. Record which command produced each result so
another maintainer can reproduce it.
Review the rendered result
Automated checks catch broken links, duplicate IDs, invalid shortcodes, and accessibility regressions. They do not decide whether a Hero crops well or whether a dense table remains readable on a phone. Review representative English and Chinese routes at desktop and narrow widths, including navigation, theme controls, code blocks, and the whole-book output.
Hand off facts, not implications
A useful handoff lists changed files, commands and results, known limitations, and the next state still waiting to happen. Use Table 6-1 to say exactly which state has been reached instead of compressing validation, release, and deployment into the word “done.”
The full operational references are Preview the site, Deploy the site, and Troubleshoot a build.