docs(changelog): merge queue stacked PRs via /trunk stack

[samgutentag]

What shipped

Comment /trunk stack on any PR in a dependent chain (each PR's base is the PR below it) and Trunk combines the chain into one stacked PR the queue tests and merges as a single unit. When the stacked PR merges, every member PR auto-closes.

Source

• Eng PRs: trunk-io/trunk2#3122, #3430, #3490, #3694, #3696, #3707, #3751, #3798
• Linear: TRUNK-18069 (no absorbed duplicates)
• Date basis: 2026-04-30 = latest source PR mergedAt (#3798)

Wired into all 4 sites

• changelog/2026-04-30-merge-queue-stacked-prs-trunk-stack.mdx (new entry)
• docs.json (Changelog tab, 2026 group)
• changelog/index.mdx (April 2026 section)
• merge-queue/changelog.mdx (April 2026 section)

Note

Ticket is tagged [feature not live]. The existing docs page merge-queue/using-the-queue/stacked-pull-requests currently documents the older sequential /trunk merge per-PR flow, not the new /trunk stack single-unit command. Linked as the closest existing page; the page needs an update once the feature is live. Kept as draft pending eng confirmation.

🤖 Generated with Claude Code

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
trunk	🟢 Ready	View Preview	May 29, 2026, 5:48 AM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[samgutentag]

Verification status (2026-05-29): staged

On in staging only. Re-run after prod rollout.

• Flag state: read directly from LaunchDarkly (production: OFF; test/staging: ON_100). For enabledMergeQueueStackedPrs in frontend-web-2, the enabling variation is index 0 (value=true). Production: on=false (OFF). Staging (test): on=true, fallthrough variation 0 = 100% enabled (ON_100).
• Eng PRs: trunk-io/trunk2#3798 (latest, merged 2026-04-30, intact on main), plus #3122, #3430, #3490, #3694, #3696, #3707, #3751. All merged and intact.
• Flag: enabledMergeQueueStackedPrs (LaunchDarkly, org-keyed, frontend-web-2).
• Signals: the base-chain walk is gated on this flag. LaunchDarkly reads it as ON in staging, OFF in prod. Upgraded from the prior pending verdict (which assumed disabled when LD was unavailable) to staged now that LD confirms staging-on / prod-off.

Next: keep in draft. Re-run after the flag reaches 100% in production.

[samgutentag]

Code verification (2026-05-28): 6 confirmed / 0 contradicted / 0 ambiguous / 0 unverifiable

Claim	Verdict	Source
/trunk stack is the command	confirmed	controller/utils/index.ts
A stack is a chain where each PR's base is the PR below	confirmed	stacked_pr_comment.test.ts:309
A "Stacked" pill marks stacked PRs in Queue/Graph views	confirmed	trunk2#3430 diff (<span>Stacked</span>)
The merge item detail page lists every member PR	confirmed	trunk2#3430 diff (memberPrs -> #{member.prNumber} / {member.prTitle})
Stack-specific cancellation reasons appear in the conclusion chart	confirmed	trunk2#3122 ClickHouse migration add_stacked_pr_cancellation_reasons
Member PRs resolve when the stacked PR merges	confirmed	merge-types/index.ts (STACKED_PR_MEMBER_MERGED)

No contradictions. Every factual claim in the entry matches source. The entry deliberately omits internal terminology (--force, StackedPrMember, trunk-stack/ branch prefix) per the ticket's writer guidance, so there are no claims to over-verify there.

---

Source #1 — `/trunk stack` command (confirmed)

File: trunk-io/trunk/trunk/services/merge/src/controller/utils/index.ts

The command string is defined and parsed by the merge controller. Tests assert parseCommand("/trunk stack") and the integration suite drives '/trunk stack --title "..."'. The browser-extension constant TRUNK_STACK_COMMENT = "/trunk stack" matches.

Source #2 — stack is a dependent chain (confirmed)

File: stacked_pr_comment.test.ts#L309

reacts with -1 when the PR directly targets the merge branch (single-PR, not a stack) confirms a stack requires each PR's base to be another PR in the chain, not the merge branch directly. The test also builds a 2-member group, matching the "chain of dependent PRs" framing.

Source #3 — "Stacked" pill (confirmed)

File: trunk-io/trunk2#3430 diff

The PR adds <span>Stacked</span> to the Queue/Graph item rendering. This is the pill referenced in the entry.

Source #4 — member PR list on detail page (confirmed)

File: trunk-io/trunk2#3430 diff

The merge item detail page maps stackedPrGroup.memberPrs to render #{member.prNumber} and {member.prTitle} for each member, backed by the StackedPrMemberInfo GraphQL type.

Source #5 — stack-specific cancellation reasons (confirmed)

File: trunk-io/trunk2#3122 ClickHouse migration V20260302000000__add_stacked_pr_cancellation_reasons.sql

Adds STACKED_PR_MEMBER_PUSHED_TO, STACKED_PR_MEMBER_CLOSED, STACKED_PR_MEMBER_MERGED, STACKED_PR_MEMBER_BASE_BRANCH_CHANGED to merge_item_state_transition. These power the stack-specific reasons broken out in the conclusion chart.

Source #6 — member PRs resolve on stack merge (confirmed)

File: trunk-io/trunk/trunk/services/merge-types/index.ts (STACKED_PR_MEMBER_MERGED)

The STACKED_PR_MEMBER_MERGED cancellation reason is the terminal state for a member PR whose code reached the target branch via the stacked PR. This is the mechanism behind "every member PR auto-closes since its code is already in the target branch."

[samgutentag]

Verification status (May 30, 2026): staged

On in staging only. Re-run after prod rollout.

• Flag state: read directly from LaunchDarkly (production: OFF; test: ON_100). enabledMergeQueueStackedPrs in frontend-web-2: prod on=false, test on=true fallthrough variation 0 (true) = ON_100. Test env version incremented to 3 (was 2 yesterday). No targeting rules. Unchanged verdict.
• Eng PR: trunk-io/trunk2#3798 (latest, merged 2026-04-30, intact on main), plus #3122, #3430, #3490, #3694, #3696, #3707, #3751. All merged.
• Flag: enabledMergeQueueStackedPrs (project frontend-web-2, maintainer: Eli).
• Signals: LaunchDarkly get-flag called directly this sweep. Prod OFF, staging ON_100. No change since last sweep.

Hold publishing until enabledMergeQueueStackedPrs is enabled in production. Re-run after the prod rollout.

---

Generated by Claude Code

[samgutentag]

Verification status (May 31, 2026): staged

On in staging only. Re-run after prod rollout.

• Flag state: read directly from LaunchDarkly (production: OFF; test: ON_100). enabledMergeQueueStackedPrs in frontend-web-2: prod on=false, test on=true fallthrough variation 0 (true) = ON_100. Confirmed same state as May 30.
• Eng PR: trunk-io/trunk2#3798 (latest, merged 2026-04-30), plus #3122, #3430, #3490, #3694, #3696, #3707, #3751. All merged and intact on main.
• Flag: enabledMergeQueueStackedPrs (project frontend-web-2, maintainer: Eli)
• Signals: LaunchDarkly get-flag called directly this sweep. Prod OFF, staging ON_100. No change since last sweep.

Hold publishing until enabledMergeQueueStackedPrs is enabled in production. Re-run after the prod rollout.

---

Generated by Claude Code

[samgutentag]

Verification status (June 1, 2026): staged

On in staging only. Re-run after prod rollout.

• Flag state: read directly from LaunchDarkly (production: OFF; test/staging: ON_100). For enabledMergeQueueStackedPrs in frontend-web-2, the enabling variation is index 0 (value=true). Production: on=false (OFF). Staging (test): on=true, fallthrough variation 0 = 100% enabled (ON_100). No targeting rules in either env. Same state as prior sweep (test env version 3).
• Eng PRs: trunk-io/trunk2#3798 (latest, merged 2026-04-30) plus #3122, #3430, #3490, #3694, #3696, #3707, #3751. All merged and intact on main per prior sweeps.
• Flag: enabledMergeQueueStackedPrs (project frontend-web-2, maintainer Eli).
• Signals: LaunchDarkly is the primary signal here. Prod flag is off, so customers cannot use /trunk stack yet.

Next: keep in draft. Re-run after the flag flips on in production. PR is conflicting on shared changelog nav files; conflicts handled separately. Unchanged from prior sweep.

---

Generated by Claude Code