BT6 Release Validation
Validate an existing tag before publishing or promoting release artifacts. Apply
bt6-maintainer-guardrails. This workflow does not create, move, or delete tags
and does not publish a release without separate explicit authorization.
Required context
- Resolve the canonical repository, CI remote, base branch, profile, expected
actor, and release authority from project configuration and live state.
- Resolve the requested tag to an immutable commit and record whether the tag
is signed or annotated when repository policy requires it.
- Refuse an ambiguous, missing, moving, or policy-disallowed tag. Never validate
the working tree as a substitute for the exact tagged commit.
- Use an isolated checkout or worktree so validation does not overwrite local
work.
Required validation
- Run every repository-profile
validation.full command at the exact tagged
commit.
- Run applicable
documentation, researchIntegrity, and risk-surface checks.
- Run repository-defined source-snapshot integrity, compatibility, and
supported-platform checks. Verify the release ZIP comes from the tagged
source rather than an unrelated checkout; do not require a compiled package.
- Compare local evidence with CI for the same tag and commit. Record missing or
stale evidence as incomplete, not passing.
- Treat warnings, flakes, skips, coverage changes, and conditional-gate gaps
according to repository release policy; do not inherit the relaxed PR
turnaround budget as a release exemption.
- When
releaseEvidence is configured, verify every artifact against the
canonical checksum manifest, authenticate its SLSA/in-toto attestation,
validate the source-SBOM binding, and prove promotion uses the tested
snapshot-once ZIP bytes. A checksum without authenticated provenance is
incomplete evidence.
Decision
pass only when every required check succeeds for the exact tag commit.
fail for any failed required check or artifact/source mismatch.
hold when the tag, authority, profile, platform evidence, or required command
cannot be resolved safely.
Do not promote artifacts or describe the tag as released after fail or hold.
Use templates/bt6-release-validation-report.md and record the event that makes
the evidence stale.
1---2name: bt6-release-validation3description: Validate an exact tagged BT6 release with the repository's exhaustive suite before artifacts are promoted.4---56# BT6 Release Validation78Validate an existing tag before publishing or promoting release artifacts. Apply9`bt6-maintainer-guardrails`. This workflow does not create, move, or delete tags10and does not publish a release without separate explicit authorization.1112## Required context13141. Resolve the canonical repository, CI remote, base branch, profile, expected15 actor, and release authority from project configuration and live state.162. Resolve the requested tag to an immutable commit and record whether the tag17 is signed or annotated when repository policy requires it.183. Refuse an ambiguous, missing, moving, or policy-disallowed tag. Never validate19 the working tree as a substitute for the exact tagged commit.204. Use an isolated checkout or worktree so validation does not overwrite local21 work.2223## Required validation24251. Run every repository-profile `validation.full` command at the exact tagged26 commit.272. Run applicable `documentation`, `researchIntegrity`, and risk-surface checks.283. Run repository-defined source-snapshot integrity, compatibility, and29 supported-platform checks. Verify the release ZIP comes from the tagged30 source rather than an unrelated checkout; do not require a compiled package.314. Compare local evidence with CI for the same tag and commit. Record missing or32 stale evidence as incomplete, not passing.335. Treat warnings, flakes, skips, coverage changes, and conditional-gate gaps34 according to repository release policy; do not inherit the relaxed PR35 turnaround budget as a release exemption.366. When `releaseEvidence` is configured, verify every artifact against the37 canonical checksum manifest, authenticate its SLSA/in-toto attestation,38 validate the source-SBOM binding, and prove promotion uses the tested39 snapshot-once ZIP bytes. A checksum without authenticated provenance is40 incomplete evidence.4142## Decision4344- `pass` only when every required check succeeds for the exact tag commit.45- `fail` for any failed required check or artifact/source mismatch.46- `hold` when the tag, authority, profile, platform evidence, or required command47 cannot be resolved safely.4849Do not promote artifacts or describe the tag as released after `fail` or `hold`.50Use `templates/bt6-release-validation-report.md` and record the event that makes51the evidence stale.