How this site is built

Static HTML in the sgit.ai design language, released the same way as the main site and nhi.sgit.ai: 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, the version agrees everywhere, every page declares a canonical URL on the host named in CNAME, and a key-leak tripwire bans anything shaped like a vault key from the tree. A failure stops the release: no tag, no publish. It also runs on pull requests, so branch work is gated before it reaches dev.
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.
3. deploy — publishes the tagged working tree to GitHub Pages. Runs on manual dispatch even without a tag, never when validation failed, never from a pull request.

The one check this site adds

This site was refactored out of the PKI section of nhi.sgit.ai, so the specific mistake worth catching automatically is a page whose canonical URL still points at the old host. Validation reads CNAME and requires every <link rel="canonical"> and og:url to sit on that host — and requires every page to declare one.

Releasing a change

# 1. bump the version — exactly once per release
echo "v0.1.2" > 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.2: what changed"
git push origin dev

The UX carried across

• The version badge in the nav links to the release history, so any page tells you which release you are reading and CI enforces that they all agree.
• The stage pill states the site's maturity in the nav rather than in a footer nobody reads.
• The in-page markdown reader (assets/mdreader.js) renders a captured document from its raw file, including mermaid fences as diagrams — so the raw markdown stays the source of truth and the page is presentation. Any failure falls back to a link to the raw file, so a document is never unreachable.
• Print styles: every page prints as a clean document — sticky nav flattened, navigation links dropped, tables and figures kept off page breaks.
• The comms page: the working channel between the project lead and the site agent, in public, updated every release.

Conventions carried from sgit.ai and nhi.sgit.ai

• Light theme, same design tokens, same honest-limitations posture.
• Source documents captured verbatim under briefs/, with a curated presentation page alongside — the raw file stays the source of truth.
• Machine-readable entry points: llms.txt, index.md. Full .md twins per page and llms-full.txt are queued (T5 on comms).
• Nav and footer are hand-duplicated per page; a shared page generator is queued (T3), to be shared across the three sites.