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>
26 lines
1.2 KiB
Markdown
26 lines
1.2 KiB
Markdown
# 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.
|