How this site is built

Static HTML in the sgit.ai design language, released the same way as the main site: every push to dev is validated, auto-tagged, and deployed to GitHub Pages.

The release pipeline

1. validate — node admin/build/validate.js: internal links resolve, version agrees everywhere, and a key-leak tripwire bans anything shaped like a vault key from the tree. A failure stops the release: no tag, no publish.
2. tag-release — every push to dev ends tagged v{release}.{major}.{minor}. The version is owned by admin/build/version.txt, bumped exactly once per release, and must agree with the release commit's subject (site vX.Y.Z: ...). CI verifies the two agree and that the bump is the next minor (or a deliberate major), then tags. The first run backfills tags for historical releases from commit subjects. Adapted from the SGit-AI__Website workflow.
3. deploy — publishes the tagged working tree to GitHub Pages. Runs on manual dispatch even without a tag, never when validation failed.

Releasing a change

# 1. bump the version — exactly once per release
echo "v0.1.1" > admin/build/version.txt
# 2. add a row to admin/versions.html, update admin/comms.html
# 3. validate locally
node admin/build/validate.js
# 4. commit with the version in the subject, push to dev
git commit -am "site v0.1.1: what changed"
git push origin dev

Conventions carried from sgit.ai

• Light theme, same design tokens, same honest-limitations posture.
• Evidence status stated per claim (the evbox pattern on option pages).
• Machine-readable entry points: llms.txt, index.md. Full .md twins and llms-full.txt are queued (T8 on comms).
• The git-and-sgit co-existence pattern (site tree simultaneously a vault) is queued (T12) — the MVP is plain git.