Release

acc release is the public entrypoint to the current release subsystem. Validation establishes whether the repository meets its implemented gates. Reporting records that result. Packaging is allowed only from a READY result, then embeds a report and manifest and writes a SHA-256 sidecar. Verification checks those concrete artifacts and their internal relationships; it does not publish a release or install the package.

The release engine adds the current short Git commit and a UTC timestamp, then maps the combined validation result to READY or BLOCKED. Packaging raises an error when the result is not READY. Readiness alone does not confirm publication or dependency authenticity. Packaging separately rejects dirty source and admits only tracked allowlisted files; do not override this gate.

acc release report writesruntime/release-reports/release-<version>-<commit>.report. It records the version, commit, UTC timestamp, overall status, and PASS or FAIL result for each release gate. For release readiness it also records analysis status, implemented checks, and a deny-all authority block. The command writes a report even when validation is BLOCKED, then exits non-zero so the file can be retained as failure evidence.

Packaging runs report generation again. Because validation and timestamps are evaluated during each call, a separately generated report is not automatically the same run embedded later in a package. Preserve the embedded report when reviewing a particular package.

A successful build writes runtime/releases/ACC-<version>-<commit>.tar.gz. Its embedded manifest format is version 1 and records VERSION,COMMIT, SOURCE_COMMIT, SOURCE_DIRTY,SOURCE_DESCRIBE, BUILD_TIME, the exact PACKAGE filename, and the readiness file, schema, and digest binding. Operators must still compare those values with an independently trusted publication record; self-consistency does not authenticate the publisher or build host.

The sidecar path appends .sha256 to the package path. Its single line contains the lowercase SHA-256 digest, two spaces, and the package basename. Verification requires both the recorded filename and a newly computed digest to match. The verified GA 1.3.3 package digest is 1322defb49797901cbfcb0ce5b6cb4166d5f2b5d4788e5dba01671bae9bb88f2.

The manifest includes a SHA256 field, but the v1 manifest generator and official GA manifest leave it empty. The authoritative implemented checksum comparison uses the adjacent sidecar. Because integrity generates that sidecar before checking it, useverify when consuming published artifacts without intentionally replacing their checksum record.

Without an already trusted ACC CLI, start with the canonical Zero-ACC bootstrap: independently trusted OOB identity and fingerprint are required; absent inputs mean BLOCKED. Mirrors only distribute trust material. System OpenSSH authenticates the original checksum before parsing and archive hashing. Success is only PACKAGE_AUTHENTICITY=VERIFIED, not readiness or installer admission. Do not run the downloaded CLI to bootstrap its own trust.

1. Obtain the package, original checksum, detached signature and authenticity artifact together from the authorized distributor.
2. Obtain the allowed-signers file and signer public key independently of the bundle. Keep original filenames and sidecar placement.
3. Use an already trusted ACC CLI with all three authenticity options shown below.
4. Stop if any input is missing or any check fails. Neither READY nor a matching checksum substitutes for authentication.

acc release verify /path/to/ACC-1.3.3-d55e48c.tar.gz \
  --authenticity /path/to/authenticity.json \
  --allowed-signers /path/to/allowed_signers \
  --signer-public-key /path/to/signer.pub

Paths are examples; replace them with actual absolute paths. Bare release verify PACKAGE does not request authenticity. Checks cover structure, manifest identity, source provenance, readiness schema and hash, denied authority, filename and digest; trust options add authenticity checks. Do not assume the historical 1.1.0 27/27 count applies to authenticated verification.

Verification grants no installation, update, deployment, mutation, recovery or deletion authority. Trusted installer admission is a separate operational gate.

Current GA: v1.3.3, source d55e48ca98c43c0cb0d789cca618324bc7e6530c, recorded READY on October 10, 2026. The sealed GA package matches 1322defb49797901cbfcb0ce5b6cb4166d5f2b5d4788e5dba01671bae9bb88f2. The repository now contains the authenticated release/v1.3.3 publication archive with its original checksum, detached signature, authenticity artifact, manifest, and report. Review the version-matched artifact set. Website deployment and independent signer trust remain separate from archive readiness.

The artifact archive is a website publication record, not a digital signature or provenance attestation. Verify the adjacent sidecar and compare the full source identity with the independently trusted v1.1.0 tag before installation. The v1.0.0 certified baseline remains a historical record and must not be presented as v1.1.0 evidence.

• An unsupported release subcommand is rejected by argument parsing with exit code 2.
• Failed readiness makes validate and report return 1; packaging refuses to proceed.
• A missing explicit package makes integrity or verify return 1.
• A missing, malformed, misnamed, or mismatched sidecar makes package verification unhealthy.
• Missing required archive members, manifest version mismatch, package-name mismatch, VERSION disagreement, or an empty commit makes verification unhealthy.
• Malformed or unreadable archives can raise a verification exception; the public CLI surfaces the error and returns 1.

Do not repair a published mismatch by regenerating its sidecar. Reacquire the artifacts from the expected release channel and compare them with the official archive or publication evidence.

• Build from the intended clean source commit and record the canonical VERSION, full Git commit, and expected short commit before generation.
• Run validation before creating public artifacts; inspect the individual checks rather than relying only on the final status line.
• Keep the package, embedded report and manifest, adjacent sidecar, release notes, and publication metadata associated with one version.
• Archive immutable copies of the reviewed artifacts; do not silently replace a package while retaining its version or filename.
• Publish the package digest through a channel consumers can compare independently. SHA-256 detects mismatch but does not authenticate the publisher by itself.
• Have consumers run authenticated verify with independently trusted signer inputs before extraction or installation and use the Installation guide for the separate installer workflow.

Maintainers assemble signed releases only from reviewed clean source with explicitly authorized signing inputs:

acc release signed-package \
  --private-key /secure/path/to/signing-key \
  --signer-public-key /secure/path/to/signer.pub \
  --signer-identity RELEASE_SIGNER_IDENTITY

Private keys stay outside release sources. This producer operation neither generates trust nor publishes a release. Follow docs/product/release-signing-operations-policy-v1.md for publisher identity, independent trust distribution, key rotation and compromise response. Never use test-mode signing or a newly generated key as production publisher trust.

What changed in 1.2.x

Release packaging adds tracked-source hygiene, signed authenticity and trusted consumption. Installer admission precedes mutation; successful installation retains installed-release identity, exact CLI ownership and footprint provenance. Clean-room installation validation is a separate release validation capability, not an implied result of a checksum check.

Safe update readiness and preview

./update.sh <TARGET_VERSION> <BACKUP_ID> <INSTALLED_RELEASE_RECORD> <TARGET_PACKAGE> <TARGET_AUTHENTICITY> <TARGET_ALLOWED_SIGNERS> <TARGET_SIGNER_PUBLIC_KEY>

The gateway binds installed identity, authenticates the target and checks backup context before persisting readiness evidence and entering safe preview. It is not a general operational updater. Missing or invalid evidence blocks the workflow; a healthy preview is not a completed upgrade.

Non-destructive uninstall diagnostics

acc release uninstall-status --json

This command intentionally returns 1 with deletion authority blocked. Footprint, CLI ownership, uninstall planning and approval diagnostics do not expose a deletion executor. The source-checkout uninstall.sh wrapper is not included in the release package; use the packaged CLI diagnostic. Canonical V2/V3 analysis-only boundaries remain unchanged.