[ANT1OFF]

Builds on #108 (condition wakes, merged). Changes merge-gate behaviour: held for an independent review.

What

merge_freeze (orchestrator and worker tool): a thread freezes Gram's own merges onto a repo's branch (the default branch unless branch is given) for a reason, for at most 60 minutes (minutes, default 60). Calling it again renews the freeze. lift: true ends it.

• Gate: while a freeze stands, merge_when_ready waits instead of merging and records why on the PR, so the ledger shows main is frozen by "Release 1.6" for release 1.6 cut until 14:05Z. set_auto_merge refuses, because GitHub's auto-merge, once armed, would merge under a freeze Gram can't hold back.
• Race: a merge's last check and its gh pr merge launch run under a per-repo fence that freeze also takes. A freeze is either seen by that last check or lands after the launch; it can't slip between them. The check also runs at evaluate and at the start of each attempt.
• Authority: only the thread that froze a branch can renew it. That thread, or the orchestrator of the workspace it was in, can lift it. Anyone else is refused, with the expiry time. Freezing over another thread's freeze is refused and points at freezeLifted.
• Always expires: every read compares until with the clock, so neither a timer that never fired nor a restart past the expiry keeps a freeze alive. Timers also end it on time and are re-armed at start. Rows are persisted in a new merge_freezes table (migration 0002_merge_freezes), so a freeze survives a restart until it expires. A closed thread's freezes end with it; an archived or stopped thread's simply run out.
• Lift/expiry re-checks: any change on MergeFreezes.changes re-checks every armed merge in that repo, so a held merge goes as soon as the freeze ends.
• Limits: it governs only Gram's merges. A person or GitHub can still merge, and the tool description and docs say so.

freezeLifted condition kind (on #108's interface): { kind: "freezeLifted", repo, branch? } fires when the freeze ends, lifted or expired. Without branch it takes the freeze standing on the repo; it is refused if nothing is frozen. It is driven by MergeFreezes.changes, with a 1-minute poll fallback and a 5-second debounce.

Release flow: docs/RELEASING.md § Holding main during the cut. The cutting thread freezes main just before merging the release PR, renews while needed, and lifts once release:rc has recorded the Linux dispatch, instead of asking the orchestrator to hold merges. The release-worker brief itself lives in orchestrator memory, outside the repo, so it should point at this section.

Review fixes (c259b65, findings 1–9 from the independent review of 204a03c)

1. Release flow no longer blocks itself: allow: [PR numbers] (at most 4) lets the named PRs merge under the freeze. I chose this over exempting the owner's bound PR because it names exact PRs. RELEASING.md now freezes with allow: [<release PR>]. Test: the allowed PR merges while the freeze stands.
2. GitHub auto-merge armed before the freeze: on freeze, Gram turns off GitHub auto-merge on open PRs into the branch that belong to Gram threads (except allowed ones) and records them on the freeze with their method. When the freeze ends, by lift, expiry or after a restart, it arms them again, or hands them to a freeze standing on the branch by then. The result lists autoMergeOff and any autoMergeStillArmed. Not covered, and said so in the tool and docs: a person merging, auto-merge on a PR no Gram thread has, and merge-queue entries. Tests: taken down and re-armed on lift; re-armed on expiry after a restart; a PR no Gram thread has is left alone.
3. Workspace scope: a freeze is refused unless the repo is the origin of one of the caller's workspace projects. Refusal test.
4. set_auto_merge: the check and the launch run under the freeze fence, and when a freeze stands on the repo it reads the PR's base afresh (gh pr view --json baseRefName). Test: a stale badge base plus a fresh main is refused; an allowed PR merges.
5. Branch validation: branches are checked in the tool schema and on the resolved default branch, and the row is written before the in-memory map. Test: release+1 and a default branch named trunk+1 are refused, and nothing is left standing.
   6–7. Expiry: one watcher per freeze re-reads the freeze and the clock at least every 60 s and ends it once expired. lift and the thread-closed path no longer touch timers, and ending can't be interrupted partway. Every read still compares against the clock. Test: lift, then a new freeze by the owner still ends on time and its end lets the held merge go. A macOS sleep that suspends timers can't be faithfully simulated under TestClock, so 7 rests on the 60-second re-read by design.
6. Total cap: a freeze stands at most 4 hours from when it was first set (since). Past that, renewal is refused and a fresh freeze is needed after it ends. Test included.
7. Reason text: collapsed to a single line, with control characters removed. Test included.

• Note: the docs say a freeze can wait behind an in-flight merge's fresh gh read, since the fence covers it.

Re-review fixes (8225a52, findings A and B from the re-review of c259b65; rebased on main after #111)

• A. Re-arm no longer overrides a deliberate choice: a PR leaves the freeze's re-arm list the moment someone turns its auto-merge off (set_auto_merge enabled:false), holds its merge (merge_when_ready hold), unbinds it (pr_unbind), or Gram sees it closed or merged. The change is saved at once, so a restart can't bring it back. At the end, re-arm also checks each PR fresh: it skips one that no Gram thread binds any more, whose thread is archived, babysat or in a paused workspace, or whose merge is held. Tests cover turn-off and hold (both survive a restart), unbind and close, and archived and paused. With the fix disabled, both turn-off tests fail.
• B. A quit partway through no longer loses the record: each PR goes on the freeze's record before its auto-merge is turned off, under the branch's lock, and comes off again if GitHub refuses. A quit partway can at worst leave a PR recorded that wasn't turned off, and arming that again is harmless. Test: GitHub hangs on the second PR and the app quits there; after the restart and expiry, both are armed again.
• Rebase: the branch is rebased onto feat(orchestration): wake on stuck CI and on machine load or low disk #111 (stuck-CI and machine kinds) and squashed. freezeLifted now sits beside those kinds in the union, the sources and schedule_wake's description, and wakeConditionsLayer takes all the GitHub and machine readers as one layer.
• Prompt budget: with feat(orchestration): wake on stuck CI and on machine load or low disk #111's kinds and merge_freeze both in, I tightened the tool's text and then raised orchestrator from 62,400 to 63,000 and worker from 35,700 to 36,600 (measured 62,424 and 36,318). Plain is unchanged at 24,642 of 24,900.
• Verification: 22 related test files pass (348 tests), including feat(orchestration): wake on stuck CI and on machine load or low disk #111's wake-conditions, service-condition-wakes-ci-machine and ci-stuck. Typecheck, lint, docs and scaffold checks are clean.

Files

• packages/contracts/src/wake-conditions.ts: FreezeLiftedCondition, MergeFreeze, mergeFreezeText, MERGE_FREEZE_MAX_MINUTES = 60, MERGE_FREEZE_REASON_MAX = 200
• packages/server/src/git/merge-freezes.ts: the MergeFreezes service (freeze, lift, active, list, fence, changes), plus MergeFreezesNone for test layers that don't exercise freezes
• packages/server/src/git/merge-when-ready.ts: the freeze check at evaluate, at attempt start and inside the launch fence; the re-check on freeze changes
• packages/server/src/app-tools/pr-tools.ts: the merge_freeze tool; set_auto_merge refusal
• packages/server/src/wakes/condition-sources.ts: the freezeLifted source; wakeConditionsLayer
• packages/server/src/persistence/migrations.ts: 0002_merge_freezes
• docs: AGENTS_AND_FEATURES.md (merge freezes, freezeLifted row), RELEASING.md

Verification

• service-merge-freeze.test.ts (real harness, full-autonomy workspace, PR armed with merge_when_ready):
  • Gate and authority: freezing the default branch with a reason; minutes: 61 refused; the ready PR waits with the exact line main is frozen by "Release 1.6" for the 1.6 release cut until HH:MMZ and no gh pr merge; set_auto_merge refused naming the freeze. A non-owning worker can't freeze over it or lift it ("Only "Release 1.6" or its orchestrator…"). The owner renews. The orchestrator lifts, and the merge then launches pinned with --match-head-commit.
  • Restart and expiry: the freeze survives a restart and the ready PR still waits. The owning agent is interrupted and never returns, yet the freeze expires at its time (active is undefined) and the merge goes. A plain thread's freezeLifted wake fires once after its debounce; freezeLifted on an unfrozen branch is refused.
• feat: condition wakes for schedule_wake (branch moved, thread finished) #108's service-condition-wakes.test.ts still passes (6 tests).
• merge-after-local-check, merge-base-lock, merge-moved-base, merge-ci-launch, pr-tools, pr-tools-merge, pr-tools-merge-launch, migrations, held-briefs, service-wakes, tools, tool-ergonomics, http/server, registry: pass (16 files, 258 tests, with the 3 migrations cases updated for 0002; re-run green).
• prompt-budget.test.ts: the worker limit is raised on purpose from 34,700 to 35,600. merge_freeze plus feat: condition wakes for schedule_wake (branch moved, thread finished) #108's condition text bring the worker to 35,137 characters. The orchestrator is at 61,243 of 62,400; plain threads don't get the tool.
• bun run typecheck, bun run lint, bun run fmt, bun run check:docs, bun run check:scaffold: clean. No full local bun run check; CI and the managed check gate it.

Known limits

• A PR whose badge doesn't name its base is held by a freeze anywhere on its repo (the conservative choice).
• The fence is per repo, so two Gram merges onto different bases of one repo serialize their final launch. This only matters if they launch at the same moment.
• The user has no "lift" button; the freeze is at most 60 minutes and the orchestrator can lift it. Adding a UI control would mean a new surface, which the brief rules out.
• Migration 0002 is the first 1.x migration. A parallel PR adding one must renumber.