Release Freeze Triage: Only Changes That Meet the Bar Reach the Release Branch

A freeze is only as good as its admission bar

During a release freeze the release branch takes only what meets the admission standard. Section 1 of the standard decides which pull requests are in scope at all. The rest decides whether an in-scope pull request is admitted, deferred until the freeze lifts or rejected, and with which reason code. Admitted pull requests are merged, and every decision goes on the freeze board so the release manager can see the whole branch at once.

The pull requests and their checks are in GitHub, the board is in ClickUp, the standard and its amendments are in Google Drive, and the arguments happen in Slack. Freezes go wrong in the middle: an exception is granted, the bar is raised the night before release, or CI results come back for a handful of pull requests. Re-checking only what someone named, or forgetting that a raised bar applies to what has already merged, leaves the branch holding changes the standard no longer allows.

Who works in the room

Each freeze gets its own Kylon room, with Nova as the default agent for scope and dispositions, so every pull request question goes to Nova first. The room guidelines give CI readbacks to Fin, along with a second look at every revert before the release manager sees it, so Nova mentions Fin on each revert it proposes. Both agents use GitHub through a lasting grant the repository owner approved for this room, and every merge and revert still waits for the release manager in the thread.

Triage under the freeze, scope first

Scope always comes first. Out-of-scope pull requests are never touched, and nothing merges, reverts or moves on the board until the release manager approves.

When the bar moves after merges have landed

Raising the bar is the change that catches teams out. The night before release the standard is amended to admit only P0 fixes. Nova re-derives every in-scope pull request, including those merged earlier in the freeze, because a merge under the old bar does not admit a change under the new one. For each merged pull request that no longer admits, Nova proposes a revert pull request and a revert card, Fin checks each one, and the release manager approves them one by one. Each turn's run history records which pull requests were read and which were changed.

Reason codes move with the decisions. A deferred pull request that is now rejected, or an admitted one that is now reverted, gets its new code on the ClickUp board as well as in the thread, so the board never disagrees with what happened. When QA posts a CI readback that names only two pull requests, Fin re-derives those two under tonight's bar, not the bar in force when they were opened. Green checks alone do not admit a change the new standard defers.

What the checks catch

• An out-of-scope pull request triaged anyway because it targets the release branch
• A pull request merged under the old bar that no longer admits and has no revert
• A changed decision whose reason code was updated in the thread but not on the board
• A readback re-derived under the bar from the day the pull request was opened

What stays with people

• Approving every merge and every revert before it touches the release branch
• Granting an exception to the admission standard
• Raising or lowering the bar, which stays with the release manager
• Confirming CI results that look wrong, which stays with the QA lead

Integrations in this workflow

Kylon is not a CI service or a release management tool, and it does not replace either. It sits next to the code host, the board and the documents the release team already uses, and is where the triage between them happens.

• ClickUp
• GitHub
• Google Drive
• Slack

• GitHub holds the pull requests, their checks, the merges and the revert pull requests
• ClickUp carries the freeze board, one card per in-scope pull request with its reason code
• Google Drive keeps the admission standard and every amendment to it
• Slack is where exceptions are requested, readbacks are posted and the group closeout is shared

Where to start

Your next freeze is the place to begin. Connect the repository and the ClickUp board, put the admission standard in a Drive folder the room can read, and write one rule in the room guidelines: scope is decided first under section 1, and nothing merges or reverts until the release manager approves it in the thread.

“The bar went up the night before release. By morning the two changes it no longer admitted were reverted and on the board with their reason codes.”

Set it up with your agent

Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it.