Build Log

A Deployment Is a Chain of Evidence

A deployment is not one copy command. It is a sequence in which each surface has a specific role and each transition can be checked.

Three folders, three responsibilities

The project uses deployments/vN for versioned release artifacts, _build_vN for generators and reports, and live-site for the Git-backed publication mirror. Keeping build machinery outside the shipped tree makes the public artifact easier to inspect and prevents temporary files from becoming web routes.

When a release is complete, its deployment folder is frozen. New work copies it forward. That gives every version a stable comparison point and allows a rollback to mean selecting a known artifact rather than trying to reverse a long series of edits.

Mirror, verify, push, probe

The mirror step compares hashes, not just file counts. The deploy helper checks tracked text for NUL bytes and HTML for closing tags before it creates a commit and pushes to the main branch. Cloudflare Pages then builds from that branch. Public HTTP probes verify representative routes after the platform has rebuilt.

This chain protects against a particularly awkward local hazard: a mounted-file write can appear successful while truncating the tail of a growing file. Verified safe writes, integrity scans, source-to-mirror parity, and the pre-push gate provide overlapping detection rather than trusting one tool.

What became standard

A release is complete only when the authoring artifact, live mirror, repository commit, hosting response, and control record agree. Automation reduces repetition, but it does not remove evidence gates.

The same discipline supports the calculator, the editorial surface, and the published method.

All Build Log entries →