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. The validator does not itself confirm a clean working tree, a Git tag, a remote publication, or the authenticity of external dependencies.

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 readiness check. 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, BUILD_TIME, the exact PACKAGE filename, and its source marker. If Git identity cannot be read, the engine uses unknown; the current verifier only requires a non-empty commit value, so operators must compare release identity with the expected publication record.

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 official v1.0.0 package digest is13d953b17d0dc43a29ebafff6015a2a1f74bf79ffbc29f8222d45b74c22bf719.

The manifest includes a SHA256 field, but the v1 manifest generator and official v1.0.0 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.

1. Obtain the expected .tar.gz and its matching .tar.gz.sha256 sidecar in the same directory.
2. Confirm the expected version, commit-derived filename, and digest from an independently trusted publication record.
3. Run acc release verify <PACKAGE> against the explicit package path.
4. Review every structure, manifest, identity, and integrity check; accept the package only when the command exits 0.

The verifier requires embedded VERSION, README.md,RELEASE.report, and release.manifest. It requires manifest version 1, package-name equality, embedded VERSION equality, a non-empty commit field, and a valid sidecar. It does not compare the manifest commit to Git history, validate the report content, enumerate every source file, or perform a clean-room installation.

The archive commit and baseline registration are later repository records, not outputs ofacc release package. The baseline links release and publication evidence but does not replace package verification, and its checksum file is not a digital signature. Keep the package sidecar and baseline checksum in their separate scopes.

• 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 verify before extraction or installation and use the Installation guide for the separate installer workflow.

acc release validate
acc release report
acc release package
acc release verify release/v1.0.0/ACC-1.0.0-23ffa25.tar.gz

integrity is present in acc release --help and accepts an explicit package, although the top-level acc help summary lists validate, report, package, and verify only. Prefer verify for downloaded official artifacts because it reads the existing sidecar and performs the additional package checks.