[Feature]: Post-merge follow-ups — let a thread register work to run when its PR merges or reaches a release branch

[iamtoled]

Area

apps/server (orchestration, pull request sync, MCP orchestrator tools)

Problem

Plenty of work only makes sense after a PR is merged or deployed: run a data backfill, flip a flag, update a long-lived checkout, check that a cron's next run behaves, verify the change in production. The thread that wrote the PR is the best place to do it — it has the whole context — but by then it has been settled and nobody remembers to come back.

T3 Code already watches linked PRs and settles the thread when the PR merges (ThreadSettlementService.ts). The missing step is the opposite: waking the thread with a to-do list at that moment.

What we built around T3 today

We use T3 Code daily with agents opening PRs. To close this gap we glued together:

1. A small CLI registry: before handing the PR back, the agent writes { threadId, prs, wait: "merge" | "release", releaseBase, tasks[] }.
2. A dedicated "Ops" thread with a webhook scheduled task subscribed to GitHub pull_request events.
3. On each delivery, the Ops agent checks the registry, unsettles the feature thread and queues a message there (t3_thread_send) listing the tasks. The feature thread runs them and reports back.

"release" means the merge commit has reached the production branch (e.g. dev → main release PRs merged with a merge commit), since many teams deploy from a branch other than the PR's base.

It works, but it needs a webhook, a second thread spending tokens on every PR event, and a registry outside T3.

Proposal

A native "follow-up" attached to a linked PR:

• MCP tool, e.g. register_pull_request_follow_up({ pullRequest, when: "merged" | { branchContains: "main" }, tasks: string[] }), also editable in the UI on the PR chip.
• When the condition is met (T3 already polls linked PRs), T3 unsettles the thread and queues a message with the tasks, like a scheduled task run bound to the thread.
• The pending follow-ups are visible on the thread (and in a global "after deploy" list) so the user knows what is still waiting for a merge or a release.
• Optional: a "wait until deployed" hook (commit status / deployment API) instead of branch containment.

Why it matters

Agents are good at finishing the PR; the risky part is everything that happens after it lands. Making "what to do after the merge" a first-class, visible part of the thread would help every team shipping with T3 Code, not only ours.

Version or commit

Source inspected at a4c9494b. Our workaround is in production use on a self-hosted T3 Code server (Linux).