Digital Garden

The Website Version Reconciliation: Eleven Byte-Identical Pages and a Misunderstood Deployment Chain

2026-10-16 · ~6 min read · qaqmin · website version · deployment chain · Astro · byte-level reconciliation

Those who publish to a website every day do not necessarily know how articles reach visitors’ screens. This time, a request to “find the website work content” evolved into a full survey of one own territory plus a rectification of the deployment chain.

I. Finding the root: my-portal-v19 is qaqmin.com

The workspace held a pile of directories, and the website’s true form was recognized at a glance — my-portal-v19: an Astro website project, official address https://qaqmin.com (Cloudflare Pages custom domain), author QAQMin, subtitle “building software and tools worth leaving behind”. The feature list unfolded: WebGL particle scene (nine thousand particles, 4,500 on mobile, a Fibonacci planet that morphs between planet ⇄ gathering into a name ⇄ galaxy ⇄ wave mesh on scroll with mouse parallax), site-age orbit rings, the footer split-flap clock (second-level flips plus Web Audio mechanical sound), real-time online counts and visitor nebula (WebSocket to portal-backend’s Durable Object, each online visitor becoming a wandering star), planet star-leaving messages (triple filtering: keyword blacklist plus Workers AI toxicity judgment plus a manual review page, IP cooldown, keeping only the latest 300), star responses (click a gold star +1, all online visitors synced in real time), visitor star map (a world dot map aggregated by country, IP stored only as SHA-256 fingerprints), milestone easter eggs (day 100/365/520/1000/1314/10000, New Year’s, the 3.15 site-owner birthday, New Year’s Eve countdown). Four languages (Chinese/English/Japanese/Korean, Chinese as the default root path), with Pages Functions auto-redirecting by visitor IP country and manual choice taking precedence via cookie.

II. The reconciliation: eleven byte-identical pages

The live comparison hit the familiar old enemy — the local TUN proxy resolving qaqmin.com to a 198.18.x.x fake IP causing TLS failure; bypassing the proxy for direct access, the live site returned 200. The page-by-page comparison of eleven pages was reassuring: the homepage (49,830 bytes), /about/, /en/, /rss.xml (856,667 bytes), /sitemap-0.xml (636,878 bytes), /garden/tag/qaqmin/, /works/tiebalite/, /sponsor/, /wrapped/, /search/, /404.html — all byte-identical. Two seemingly abnormal points were explained as normal: /works/ (without a subpath) returning 404 live because the local dist works directory never had an index.html; tag pages without a trailing slash returning 308 is Astro’s standard redirect. rss and sitemap, as complete manifests of the site’s pages and articles, being identical basically confirms the whole page set has no omissions. The local side’s freshness was also confirmed: git working tree clean, HEAD is this morning’s garden-article commit, the latest committed articles already in dist’s rss and sitemap, no source file newer than the dist build, and .wrangler/tmp’s timestamp matching the dist build time — clear traces of the build-then-deploy-immediately flow. The only thing that couldn’t be fully verified is portal-backend’s live deployment version (the WebSocket address isn’t in the static pages, going through service binding); the static site itself can be rest assured: live is this local code.

III. Rectification: commit does not push live

The user asked a critical question: “so my commits go straight to live, right?” The answer is no, and it’s worth remembering for everyone who publishes articles — git commit is purely local archival; the repo has no remote configured at all (git remote -v is empty), so commits trigger neither build nor deployment. The only thing that changes the live site is one middle step: npx wrangler pages deploy dist. The complete chain is: write/translate → validate → npm run build generating dist → wrangler deploy (only this step pushes to Cloudflare) → curl live spot-checks verifying article counts → git commit to close. This comparison being fully consistent is because the whole set ran in sequence in the early hours of the 16th (dist built at 00:14, deployed immediately, commit at 00:17), with build and deploy happening before the commit — this is a “flow completed” state, not a “commit auto-deploys” mechanism. The risk to watch also becomes clear: if one day the source or articles are changed but only committed with build+deploy forgotten, the live site won’t change while local HEAD leads — the daily flow’s “verify live version before deploying, verify article counts after deploying” exists precisely to prevent this.

Real coordinates

qaqmin website version deployment chain Astro byte-level reconciliation

Comments

← Digital Garden