Reproducibility

A deployment tool tells you what happened. cwp leaves the record.

cwp refuses an upward effect with no source in the repository. Not a warning: a refusal. Every upward command satisfies that one rule a different way:

What goes up	Its committed source
cwp push, deploy — the tracked paths	the paths themselves
cwp push --only inventory	inventory.yml
cwp push --only bricks	the bricks/ tree
cwp push --only content	content/<type>/<slug>.yml
cwp ability	--from <repo-path>, or --adhoc

The first four rows are one command. Each artifact answers for its own effects, and a push that carries six of them satisfies the rule six times in one plan.

--adhoc is the interesting one. It looks like an escape hatch and is not. It does not waive the rule; it records it. The payload goes to cwp/adhoc/<timestamp>-<ability>.json before the call. The run says out loud that the change is not reproducible. On a protected environment cwp refuses it outright: there, “I accept this is not reproducible” is not an answer anybody should give in passing.

Why the artifacts are canonical

A committed file only helps if two pulls of the same thing produce the same bytes. Otherwise every diff is noise and nobody reads them.

So cwp writes the artifacts canonically: sorted keys, two-space indent, a trailing newline, one item per file. It strips volatile fields. It stores the site URL as a placeholder and every attachment id as its upload path. So the same page pulled from dev and from prod produces byte-identical files. A pull that changes nothing writes nothing, so re-running one does not dirty the tree or move an mtime.

Without that, every push would look like a conflict, and the reproducibility claim would be true and useless.

The design system follows the same rule, and it took more work than the content did. Bricks’ export format describes the export as much as the design system: a timestamp, the exporting site’s URL, a post ID in every file name. cwp pull writes a committed form with all of that removed: fonts named by family, templates without the export date, no post or attachment IDs. It is still a package Bricks imports, because every field removed is one its importer never reads.

What this buys on a builder site

A page built in Bricks is database state. Without a committed artifact it has no diff, no review and no history: you build one, and git status stays empty.

With one, the change is reviewable before it happens and findable afterwards. Reproducible means exactly that here: not that you can rebuild the site from scratch, but that you can answer who changed this, and when without restoring a backup.