providers.sgit.ai / Release history
Release history
Every release of this hub, with what changed and when. The estate's convention: one file owns the version, the release commit's subject repeats it, and the pipeline refuses to tag anything if the two disagree.
| Version | Date | What changed |
|---|---|---|
| v0.1.1 | 2026-09-08 | Both canonical domains came up hours after v0.1.0 shipped, so where a provider site serves is now measured rather than assumed: bin/sync-providers.py probes each canonical host by fetching that site's own published index from it, records the answer as live: and canonical_resolves: in data/providers.yml, and every family link the build emits — cards, comparison rows, prose — resolves through that value via a new `live:` shortcode, so no provider URL is typed anywhere. check_family_links_live now fails in both directions: a canonical link while a domain is dead, and a stale project-path link after it comes up. The claim that both domains were unconfigured is replaced by a dated claim that both now serve, sourced from the probe rather than from a report. |
| v0.1.0 | 2026-09-08 | First release. The hub of the *.providers.sgit.ai family: the four credential patterns as canonical shared content with the capability-tier axis and their intersection; a comparison matrix synced from each provider site's own published front-matter rather than kept here; the family index; the page contract every provider site obeys, including the per-product rule that has already caught somebody; the six claim states with a roll-up of the family's actual mix; estate-wide disclosures; and the estate pipeline — validate → tag → deploy, a secret scan, relative URLs and a licence stamp, all enforced rather than promised. |
How a release is made here
The same three steps as every other site in this estate — validate → tag-release → deploy.
One file owns the version: admin/build/version.txt. The nav badge, the footer, llms.txt and the table above are all rendered from it, and the gate fails if any of them disagree.
bin/bump.py "what changed in this release" # --major for vR.M+1.0 python3 build.py admin/build/validate.sh git commit -am "site v0.1.1: what changed in this release"
The commit subject is load-bearing. tag-release reads version.txt, finds the commit whose subject carries the same version, and tags it — HEAD on a direct push, HEAD's parent when a pull request lands as a merge.
The sync is not part of the build
bin/sync-providers.py refreshes data/providers.yml from the provider sites. It is never run by CI, because a build that reaches the network is a build that breaks when somebody else deploys, and because a sync should be a dated act rather than a silent one. --check reports drift without changing anything.