releaselisted

# Release an accepted commit A release distributes an accepted candidate; it is not another acceptance cycle. Reuse review, test, closure, and verification evidence while their content, scope, inputs, and target environment remain unchanged. <HARD-GATE>Require an accepted Git commit, applicable successful review evidence, disclosed material risks, and explicit owner authorization before external writes. Human-facing release records use the shortest unambiguous commit reference before tagging and the release tag after tagging. A full-length commit object ID, diff/content hash, archive checksum, or artifact checksum is never a workflow anchor; checksums are evidence only. If source behavior, specification meaning, acceptance, scope, design intent, execution authority, dependency behavior, packaging behavior, or target obligations changed without accepted evidence, stop and route only that impact cone through `gmgn`.</HARD-GATE> ## Recover missing historical acceptance Never infer an accepted commit from a historical status, tag, summary, or unbound test output. When usable acceptance history is missing, prepare and review one current committed candidate, run only the verification required by its risk and environment, obtain owner acceptance, and release that commit. Do not rewrite historical closure records. ## 1. Reuse accepted evidence Compare only inputs that can invalidate existing evidence. When reviewed content, required test plan, target environment, and relevant p