Produced with model assistance. Every page on this site, and every document in the dev packs area, was drafted with a large language model and reviewed by a person before publication. Nothing on this site is a compliance assessment, and no page claims conformity to any standard. What we do not say, and why · how every claim here is evidenced

store.sgit.ai / Release history

Release history

Every push to the release branch is a release, and every release is tagged. The version is owned by admin/build/version.txt, moved only by bin/bump.py, repeated in the release commit's subject, and CI refuses to tag if the two disagree. The same records are served as JSON.

Releases

VersionReleasedWhat changedCommit
v0.1.1current2026-09-10the delivery pages stop printing the page navigation twice
v0.1.02026-09-10the offer page, the four codes, the two rails and the pack3779062835

The pipeline that gates each one

Three jobs, in this order, the same order as every sibling site in this estate.

1 · validate. admin/build/validate.sh — the build is reproducible against the committed output, the version agrees everywhere it appears, internal links resolve, every canonical URL is on the host in CNAME, the credential tripwire is clean, every inline script parses, and this site's own acceptance assertions hold. A failure stops the release: no tag, no publish. It runs on pull requests too, so branch work is gated before it ever reaches the release branch.

2 · tag-release. The version file is read, the release commit is found by its subject line, and the two must agree. The tag must be the next minor — or a deliberate major — after the previous latest. Historical tags missing from the remote are backfilled, idempotently. Then the tag is pushed.

3 · deploy. The site is rebuilt from content/ and published. It never runs when validation failed, and never from a pull request.

What this site's gate checks that a sibling's does not

This is the first site in the estate that carries a price, and a page with a price is an offer. So the gate carries the rules that constrain an offer, as machine assertions rather than as advice in a document:

A rule that only lives in a document gets broken by the next person who has not read it. These live in tools/check_site.py, and each one names the rule it enforces.