Code and releases

PR-merged Done flow

When a git PR linked to an Issue is merged into the protected branch, the auto-link-to-pr webhook updates the PullRequestLinks row (Status: Open → Merged, MergedAt stamped); if Projects.AutoTransitionOnMerge is on, the Issue auto-transitions InReview → Done (subject to any QA gate in WorkflowTransitions). On InReview → Done, status-transition-routing flips Issues.ResolvedAt, Issues.Resolution: Fixed, recomputes current sprint progress without incrementing an unversioned historical counter, and unblocks any IssueLinks of type IsBlockedBy pointing at this Issue. QA verification of bug-type Issues holds at InReview until QA approves the gated transition.

Release cut

As Issues complete with FixVersion = <version>, the Project Lead readies the Version. On Versions.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 ReleasedAt, applies an IssueLabels row released-<version>, updates parent EpicProgress 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.

Prepare a release when one fix is unfinished

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.