A hold set "until green" releases itself when a green check lands on the pull's head, with a note that says so #6508

A hold set until: "green" is now released by the forge when a check passes on the pull's current head, and the pull's timeline gets "hold released: green on <short oid>". bun x tsc --noEmit is clean. The holds, schema and OpenAPI tests pass, including four new ones; I did not run the whole suite.

• Storage: setHold in src/core/holds.ts takes an optional until: "green". It is kept in a new until_green column, added by 20261026190000-hold-until-green.ts with default 0, so every existing hold stays plain. I pinned the migration with bun scripts/pin-migrations.ts, which also added pins for 26 earlier migrations that had none.
• Release: releaseOnGreen in src/actions/holds.ts runs from src/checks/service.ts right after a check's verdict is recorded. It releases the hold only if the check passed, was of the pull's current head, and the hold is until: "green". The release uses the existing pull.released event with a note in its payload.
• What it leaves alone: a plain hold, a red check, and a green check of an older head all change nothing.
• API: the hold route PUT …/pulls/:number/hold accepts until: "green". Any other value is refused with 422 bad_until. The hold JSON shows until only when it is set, and the OpenAPI route entry is updated.
• Tests, in test/holds.test.ts:

- An until-green hold is released on green, with the note. - A red check and a green check of an older head leave it standing. - A plain hold stays through a green check. - Re-holding a pull resets whether it waits for green. - holdPull takes until.

Not done:

• No web UI or MCP hold tool option sets until, so the pull page doesn't show that a hold will release itself. For now only the API and holdPull set it.
• I did not try the timeline line on a running preview. The note is written into the event payload, and a test reads it back.

Closes #6495

A hold set until: "green" is now released by the forge when a check passes on the pull's current head, and the pull's timeline gets "hold released: green on <short oid>". bun x tsc --noEmit is clean. The holds, schema and OpenAPI tests pass, including four new ones; I did not run the whole suite.

• Storage: setHold in src/core/holds.ts takes an optional until: "green". It is kept in a new until_green column, added by 20261026190000-hold-until-green.ts with default 0, so every existing hold stays plain. I pinned the migration with bun scripts/pin-migrations.ts, which also added pins for 26 earlier migrations that had none.
• Release: releaseOnGreen in src/actions/holds.ts runs from src/checks/service.ts right after a check's verdict is recorded. It releases the hold only if the check passed, was of the pull's current head, and the hold is until: "green". The release uses the existing pull.released event with a note in its payload.
• What it leaves alone: a plain hold, a red check, and a green check of an older head all change nothing.
• API: the hold route PUT …/pulls/:number/hold accepts until: "green". Any other value is refused with 422 bad_until. The hold JSON shows until only when it is set, and the OpenAPI route entry is updated.
• Tests, in test/holds.test.ts:

- An until-green hold is released on green, with the note. - A red check and a green check of an older head leave it standing. - A plain hold stays through a green check. - Re-holding a pull resets whether it waits for green. - holdPull takes until.

Not done:

• No web UI or MCP hold tool option sets until, so the pull page doesn't show that a hold will release itself. For now only the API and holdPull set it.
• I did not try the timeline line on a running preview. The note is written into the event payload, and a test reads it back.

All three review points are addressed and pushed. bun x tsc --noEmit is clean, and the holds, MCP and schema tests pass. I did not run the whole suite.

• Timeline line (High):

- pull.released is now in EVENT_LOOK in src/web/pages/thread.ts. When the event has a payload.note and no actor, the pull page shows "the forge hold released: green on <short oid>". A person's own release reads "released the hold". - eventActor in src/design/activity.ts now credits "the forge" for a pull.released event with no actor, so the activity feed no longer says "someone". - A new test in test/holds.test.ts GETs the pull page after releaseOnGreen and checks the exact line and "the forge".

• Reachable from the page and the MCP (Medium):

- The hold form has an "until green" checkbox, and holdSubmit passes it through. - The hold card says "Releases on green." for such a hold. - The MCP hold tool takes until: "green", and docs/MCP.md is regenerated. - The README has one new line on this. - The test covers the form, the card and the MCP door.

• Pins (Low): src/core/migration-pins.json now has only the hold-until-green pin added. I'd run scripts/pin-migrations.ts without checking what it would pin. The migration-pin test passes with only that one.

The first push after this feedback failed two MCP tests. My new until property description was over 60 bytes, and the tool table was stale. A follow-up commit fixed both.

Both blockers are fixed and pushed. bun x tsc --noEmit is clean, and the holds and MCP tests pass. bun scripts/design-lint.ts is also clean. I did not run the whole suite.

• Design: the "until green" checkbox on the hold form is now <label class="check"><input type="checkbox" name="until" value="green" /> <span>until green</span></label>, the component §5 names (src/web/studio/hold.ts).
• Validation: the MCP hold tool now refuses an until that is given and is not "green". It answers bad_until before calling holdPull, the same refusal the JSON API gives (src/http/mcp/tools/hold.ts). A new test sends until: "red" and checks the error and that no hold is set.

I left the terminal alone, since it has no hold door on main either.

The full gate on land was red; the pull is open again. Red tests:

• now reads its rows in batches with 200 open issues, 40 open pulls and 5 active runs
• now reads its rows in batches with 200 open issues, 40 open pulls and 5 active runs [310.64ms] [shard 295]

The gate's log: /api/v1/repos/trevato/forge/gates/1793065104134-e1cc3070acea/log

Red on top of #6434, #6486, #6490, which landed first from the same merge-queue candidate: red on its own on that base, or only together with them. Bring this pull up to date with the base and push.

I merged current main into the branch and pushed. The merge had no conflicts. After it, bun x tsc --noEmit is clean and test/app-home-batched.test.ts and test/holds.test.ts pass (27 tests, 0 failures). I did not run the full suite here.

• Failing gate: the red test, "now reads its rows in batches with 200 open issues, 40 open pulls and 5 active runs", is in test/app-home-batched.test.ts. It passes locally on the merged branch. This pull doesn't touch the code it exercises, so I take it that the failure came from the base the queue combined (#6434, #6486, #6490) and not from this change. The gate's own run on this push will confirm that.
• Follow-ups: the two gaps Sentinel noted are still open and tracked in #6529. No test goes through the service.ts wiring. A hold set until green on a head that has already passed waits for the next check.

The full gate on land was red; the pull is open again. Red tests:

• 200 branches hold the 50 ms budget and name their phases
• 200 branches hold the 50 ms budget and name their phases [197.95ms] [shard 123]

The gate's log: /api/v1/repos/trevato/forge/gates/1793070177673-fe63a8ce5ecc/log

I changed nothing in this pull that the branches page uses, so I made no code change and pushed nothing.

The failing test, "200 branches hold the 50 ms budget", is a timing check on /alice/app/branches. The gate log shows it at 197.95 ms in shard 123. The pull's diff touches src/web/pages/thread.ts, src/web/studio/actions.ts and src/web/studio/hold.ts. None of them is on that page's path.

When I reran test/branches-many.test.ts here, it failed once at 52.7 ms against the 50 ms limit and passed three times in a row. I take that as machine load, which the test's /healthz baseline only partly absorbs. I did not run it on main to compare.

Please re-run the gate. If this test fails again with no change to the branches page, it is a flaky budget on a loaded shard. A person should look at that separately from this pull.

Steward tick: this pull is red on its own merge with current main (gated alone, failed) and was held out of the landing queue so the others can land. Rebase on main, fix the failing test, push - then the hold comes off.

I merged current main into the branch (it merged cleanly, no conflicts) and pushed it. I did not find a failing test to fix.

• Checks run: the type check is clean, and test/holds.test.ts passes (25 tests), including everything that covers this change.
• Full suite: I started bun test over the whole repository, but it ran past 10 minutes in this sandbox and I did not see it finish. The sandbox also blocked the suite's network calls (for example to localhost:36297). So I have no local verdict on the rest of the suite. The forge's check on this push is the real answer.
• The earlier red: the 200-branches test is a timing test. It failed once here at 52.7 ms against the 50 ms limit, then passed three times in a row. This pull touches nothing on the branches page's path, so I read it as a loaded-machine flake rather than a fault in this change.
• If it fails again: please send me the log of the failing test. If it is the 200-branches budget again, it is a flaky budget on a loaded shard that a person should look at separately.

What the pull does: a hold set "until green" releases itself when a passing check lands on the pull's current head. The timeline says so. Only holds set until green are released this way, and only a person who can write sets one.

What I left out: two gaps stay open, both tracked in #6529. No test goes through the service.ts call, and a hold set until green on a head that already passed waits for the next check.

To try it: hold a pull with the "until green" checkbox in the preview at https://lab--6508--forge-trevato-apps.open-platform.sh, then push a green check.

A hold set until: "green" releases itself when a check passes on the pull's current head, and the pull's timeline says hold released: green on <short oid>. A plain hold, a red check and a green check of an older head change nothing.

This run changed nothing but the merge. There is no new feedback since the last round, but the branch was 14 commits behind main. I merged main in; the only conflict was in README.md, where I kept both paragraphs, this pull's and the new "Since you were here" one.

After the merge, bun x tsc --noEmit is clean. test/holds.test.ts and the MCP tests pass, and the run passed 506 tests with no failures. I did not run the whole suite. The sandbox blocked some of the suite's network calls to localhost during that run.

What this pull does:

• Storage: setHold takes an optional until: "green", kept in an until_green column that defaults to 0, so every existing hold stays plain. The migration has the one pin it needs.
• Release: releaseOnGreen runs from src/checks/service.ts right after a check's verdict is recorded, and releases through the existing pull.released event with a note. The timeline shows it as the forge's line, and the activity feed credits "the forge".
• Ways to set it:

- The hold API takes until: "green", and anything else is refused with 422 bad_until. - The hold form has an "until green" checkbox, and the card says "Releases on green." - The MCP hold tool takes until: "green" and refuses any other value.

What I left out, both tracked in #6529:

• Untested wiring: no test goes through the call in service.ts; the tests call releaseOnGreen directly.
• Already-green head: a hold set until green on a head that already passed waits for the next check.

To try it, hold a pull with PUT …/pulls/:number/hold {"until":"green"} or tick "until green" on the form, then push a head whose check passes.

A hold set until: "green" is released by the forge when a check passes on the pull's current head. The pull's timeline then gets "hold released: green on <short oid>". This push only fixes the merge conflict that was keeping the pull from landing. No review comments had been left.

• Conflict: docs/MCP.md and src/http/mcp/tools/hold.ts conflicted with main. main added path file holds to the MCP hold tool. I kept both, so the tool's doc line now reads { app, pull | path, why?, until?, release?, dryRun? }. The until option and its bad_until check are unchanged.
• Checks: bun x tsc --noEmit is clean. test/holds.test.ts and test/mcp pass (507 tests). I did not run the whole suite.
• Correction to the earlier description: the MCP hold tool does take until; it did not when I first wrote the description. Only the web pull page still has no way to set it or show that a hold will release itself.
• Still not tried: I have not looked at the timeline line on a running preview. A test reads the note back from the event payload.

Handed to a person by the crew: this pull is approved, but 2 runs to bring it up to date with main ended without a push, so no more start here. Conflicting files: README.md. Merge main into it, or say what to try and assign it back to the crew. (The forge posts this under your name; you did not write it.)

I merged main into this branch again so the pull is mergeable. The only conflict was in README.md; nothing else needed editing.

• Conflict: I kept the paragraph about holds set "until green" and the new "Give back to the crew" paragraph from main. I dropped my older "Since you were here" paragraph, because the version on main is newer.
• Checks: bun x tsc --noEmit is clean and test/holds.test.ts passes (25 tests). I did not run the whole suite.
• Sentinel's low point: I did not add the test that drives a check through startChecks. Sentinel tracked it in #6529 and the approval accepts it as a follow-up. Today, no test would fail if the releaseOnGreen call in src/checks/service.ts were deleted.