The home page opens, the upload command exits successfully and an HTTP check returns 200. Those observations are useful, but they do not establish that the intended article, script and downloads reached the public URL.
These field notes describe a real November 7 Lab publication, batch-20261107-r1. That historical build contained nine articles and 55 public files; later publications can contain more. Thirteen files were added or changed and 42 stayed byte-for-byte identical. We use that bounded record to separate a successful upload from a verified publication, without treating either as traffic or advertising revenue.
1. Decide what a passing release must demonstrate
HTTP 200 describes a successful request. It does not compare the returned body with your candidate. A cached previous article, a home-page fallback at the wrong path or HTML returned where a script was expected can still make a simple status-only check look successful.
For our static publication, the acceptance questions are separate:
- Did the candidate build contain the intended pages, links and downloadable bytes?
- Did the server select that immutable candidate as its current release?
- Did origin HTTPS return that release, using normal certificate verification?
- Did public HTTPS return the expected bytes for the changed paths?
- Could a real browser open the changed content and perform the relevant interaction?
- Did the change preserve the other services and the previous recoverable release?
2. Check the artifact before uploading it
Give the candidate a unique release ID and a list of relative public paths and SHA256 hashes. Compare it with the preceding release: review additions, changes and removals explicitly. The archive should contain public files only, with no credentials, private settings, traversal paths, unexpected symlinks or duplicate archive names.
Check links and fragment targets, metadata, assets, downloads, RSS and sitemap. A same-page anchor check does not establish that another article contains the fragment you linked to; cross-page checks matter. Repeat only the behavioral tests relevant to the change. Changing an input calculation deserves arithmetic tests; a new article needs source review and link checks.
Then preview the candidate at desktop and narrow widths and use the keyboard for changed navigation. A screenshot can reveal wrapping or clipping, but a simulated narrow desktop browser is not an actual phone test. Keep failed captures and unverified behavior visible rather than upgrading them to a pass.
3. Compare bytes at the origin and public URL
A small release.json can identify the selected version, but checking that one file is not enough: another path can still serve stale or incorrect content. We compare each changed public file with the expected candidate hash and separately fetch the origin through the intended TLS hostname.
Python's hashlib provides SHA256 for this byte comparison. A matching digest establishes that the bytes read by this check match the expected bytes. It does not establish that those bytes are correct, that they will execute successfully, or that every reader reaches the same CDN cache.
Keep content-type, redirect and missing-path behavior in the acceptance contract too. Nginx's try_files can choose a fallback URI or return a status code. A single-page application's deliberate fallback and an article publication's missing-page behavior are different requirements; a blanket home fallback can conceal broken article URLs.
Caches are another boundary
Record the public response's identity and expected cache behavior. Cache-Control directs caches; for example, no-store tells private and shared caches not to store a response. It does not retrospectively prove that every previously stored object has disappeared. A successful request from our checker is one observation, not a global cache purge or a continuous freshness monitor.
4. What the November 7 release actually verified
| Boundary | Recorded result |
|---|---|
| Public artifact | 55 files; 13 added/changed, 42 unchanged |
| Offline content | 18 HTML pages, 17 sitemap URLs, nine RSS items, no broken local links |
| Extra links and downloads | 29 cross-page/worksheet fragment checks; eight-entry starter ZIP matched its source files |
| Origin and public HTTPS | All 13 changed paths matched their expected SHA256 values |
| Public browser | Reading paths, the new guide and its four configuration-download links were visible |
| Other services and recovery | Three existing health endpoints returned 200 before/after; monitored Nginx config hashes unchanged; prior static release retained |
The browser checks included desktop layout, simulated 390px titles and navigation, DOM bounds and a keyboard path jump. A lower narrow-screen table capture was affected by system scaling, so complete narrow-table visual acceptance was not recorded as passed. We did not test a physical phone. The underlying Docker examples were JSON/YAML parsing examples, not an Engine rotation or service-migration experiment.
The downloadable record below reduces our existing publication receipts to public file hashes and technical acceptance facts. It excludes host addresses, account information, private settings and operational credentials. Its date belongs to that historical release, not the time you download it.
5. Recovery must not overwrite later work
We keep the preceding static directory and switch a dedicated current link rather than overwriting the live files one by one. On our same-filesystem POSIX deployment, os.replace performs the successful rename atomically. The documentation notes that a cross-filesystem operation can fail. This mechanism is specific to our deployment; it is not a guarantee about every hosting platform or every in-flight request.
Before switching, compare the current live release and its full hashes with the expected baseline. Before recovering, check that current still refers to the failed candidate. If someone else has published a newer release, stop and reconcile rather than restoring an old pointer over it. Preserve the failure, selected previous release and remaining checks.
A static-content rollback also does not undo a separate DNS, certificate, database or Nginx change. Keep those procedures scoped to the state they actually changed. Our November 7 publication changed only the dedicated static link and content; it did not deploy another business service or alter the monitored Nginx configuration.
Use the checklist for your next publication
The checklist is a manual worksheet, not an uploader or an automatic monitor. Adapt the expected paths, bytes and failure response to your site; a dynamic application needs additional checks. Put the result and any unperformed step in a run record.
Passing this release's checks established a bounded technical publication result. It did not establish uptime over time, Google indexing, independent readers, advertising approval or sales. Those need their own observations. For the surrounding workflow, follow the automation reading path.
Sources and the original release receipts were checked November 7, 2026 (Asia/Shanghai). No new deployment benchmark or audience experiment was performed for this article.