Code and releases

When a git PR linked to an Issue is merged into the protected branch, the auto-link-to-pr webhook updates the pull request links row (Status: Open → Merged, merged at stamped); if project auto transition on merge is on, the Issue auto-transitions in review → Done (subject to any QA gate in workflow transitions). On in review → Done, status-transition-routing flips issue resolved at, issue resolution: Fixed, recomputes current sprint progress without incrementing an unversioned historical counter, and unblocks any issue links of type is blocked by pointing at this Issue. QA verification of bug-type Issues holds at in review until QA approves the gated transition.

As Issues complete with fix version = <version>, the Project Lead readies the Version. On version status: Unreleased → Released (typically after a release-board sign-off and CI green), release-cut-from-version fires, validates every Issue in the proposed version is completed or explicitly excluded before the reviewed release scope is frozen; for those eligible Issues, stamps released at, applies an issue labels row released-<version>, updates parent epic progress rollups, and emails the release-notes digest (Issues grouped by Type — Story / Bug / Improvement) to the Stakeholder distribution list. A Released Version is not modified — additional fixes ship in the next Version.

A version can contain several completed issues and one unfinished fix. Before recording the release, review its actual scope and either complete that work or explicitly remove it from the version through an authorized change. A version label alone cannot make an unfinished issue releasable.

The release record preserves the accepted issue scope, required gate results and source revision. Only those eligible issues receive the retained release marker. Later fixes belong to another reviewed version; modifying a current issue must not change which work was included in the earlier cut.

Repository events retain their provider and event identity. A repeated merge notification updates the same observation, while an unknown delivery result remains tied to the original operation. Check the configured repository, protected target branch and required checks before applying any permitted automatic transition.

A Released version describes a reviewed release cut. The deployment system still owns whether that revision reached an environment. Keep deployment evidence as an external observed outcome so a successful email or release-note generation does not become a production claim.

• Open PR Activity. Open the current records for this module within your assigned role and permitted scope.