Michael Chus
a44133aff2
identifier-normalization, no-hardcoded-vendors, vendor-installer-verification, and build-version-display follow the go-database split: rules in contract.md, snippets in README.md. Routed contract reads get cheaper; examples stay available on demand. Lint now also rejects stale kit/patterns references. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1.2 KiB
1.2 KiB
Contract: Build Version Display
Version: 1.1
Rule
The build version must be visible in the footer on every page of the web application, so users and support staff can identify exactly which version is running.
See README.md for implementation snippets.
Requirements
- The version is shown in the footer on all pages, including error pages (404, 500, etc.).
- The version string is injected at build time — it is never hardcoded in source and never fetched at runtime.
- The version value comes from a single authoritative source (e.g.
package.json,version.go, a CI environment variable). It is not duplicated manually. - Format: any human-readable string that uniquely identifies the build — a semver tag, a git commit SHA, or a combination (e.g.
1.4.2,1.4.2-abc1234,abc1234). - The version text must be legible but visually subordinate — use a muted color and small font size so it does not compete with page content.
What is NOT allowed
- Omitting the version from any page, including error pages.
- Fetching the version from an API endpoint at runtime (network dependency for a static value).
- Hardcoding a version string in source code.
- Storing the version in more than one place.