Session auto-lander queue-status notice

What it is

A small in-thread notice at the foot of the conversation (below the last reply, right where the "Auto-landed" note appears) that tells you where a finished session's branch is in the auto-lander's merge queue. When a dev-pipeline session finishes and tags its branch ready-to-merge, it has "handed off" to the auto-lander — this notice reports its live queue position, so you don't have to open the Dev Pipeline panel to check.

It is purely informational — there are no buttons on it. It renders nothing for a session the auto-lander has no active queue status for.

Where to find it

The notice appears inside the session itself, at the foot of the conversation — below the last reply, in the same place the auto-landed note shows. There is no menu, panel or setting to open: if a finished session's branch is sitting in the auto-lander's queue, the line is simply there; if there is nothing queued for that session, nothing renders at all.

It is purely informational, with no buttons on it, and it updates live while you are looking at that session. On a phone it works over Web Access like the rest of the session view.

How it behaves

What you see

Only the live queue states show, as a centered divider notice (icon + one line) — calm for everything the auto-lander is handling, amber for the one case that genuinely needs you:

• Next up to auto-land — first in line; the auto-lander attempts it next.
• Queued to merge · #N of M — ready to merge, waiting its turn: your current slot plus the queue count. M counts only the branches the auto-lander will actually work through — a branch waiting on a person holds no slot. The sessions-sidebar footer chip counts its land-queue depth by the same rule, summed across every repo, so when one repo holds the queue the two numbers are the same.
• Landing now… — reserved; not shown today. The worker status carries no in-flight "landing branch X" signal (its only landing state is a tick-END summary meaning "this tick landed something", and the branch that landed has already left the queue), so this line is wired but unreachable. A branch mid-land reads as Next up until the notice clears (and, for a session that asked for one, its "Auto-landed …" note appears).
• Landing automatically: <reason> · <N>m — deferred this round but the auto-lander OWNS it (a queued or running rescue, a translation, a rebase, or a transient retry), so it reads calm with no action needed — e.g. "it needs a rebase onto the latest master". This is the handledBy: 'auto' wait.
• Needs you: <reason> · <N>m — shown in amber, the genuine human cases: a flagged secret to rotate, uncommitted changes in the repo's main folder to commit/stash, a rescue that ran past its window without landing, a give-up the auto-lander recorded (its reason names the cause), or a branch whose land kept being deferred — or whose ready-to-merge tag stayed stale — for a full stuck window with no rescue in flight ("it needs a look" / "it needs a fresh tag from you"). It flips to "Needs you" ONLY when the auto-lander truly can't handle it (handledBy: 'you'). A rescue counts as "in flight" only while a session stands behind it: the lander books an attempt before it spawns, and keeps that booking when the spawn is refused, so a branch whose rescue never started reads Needs you rather than Landing automatically with nothing actually landing it.
• Needs you: it changes a dependency — approve the request above — shown in amber. The branch bumps a dependency, and a dependency change is never landed without a person (it pulls in code from outside the project). The request itself is an ordinary approval card, sitting a little further down the same conversation — and also in your Inbox and your Approvals list, so you can answer it from your phone or after this session is archived. This line only tells you the card is there; Approve and Decline live on the card.
• You approved the dependency change — it lands on its own shortly — calm, no longer amber. You answered, so the wait is the auto-lander's now; it picks the branch up on its next pass (a few minutes). This line changes the moment you answer, rather than waiting for that pass — if it did not, the strip would still be asking for a sign-off you had just given.
• Waiting to land: <reason> · <N>m — the neutral legacy wording, used when the entry carries no handledBy at all (a version-skewed payload from an older worker): the auto-lander's own reason (e.g. "another branch is landing") and how long, with no ownership framing either way.

The queue lines (next-up / queued / landing) also carry a muted "· N ago" age — how long the branch has been tagged ready-to-merge — with the exact tag time on hover. (The waiting line is left alone: it already shows its own deferred-minutes.) The age reads from the ready tag's set-at:<ISO>; a legacy tag without that suffix simply shows no age.

The notice updates live as the branch moves up the line — but ONLY while you're viewing that session (see "Efficient refresh"), so it costs nothing for sessions you aren't looking at.

The terminal outcomes are NOT shown here. Merged, gave-up, and conflict are already reported in the thread by the passive "Auto-landed …" / "Couldn't auto-land …" notes (and a conflict is handed back to the author to rebase). So this notice never shows a "Merged to master" line — it is purely the live queue heads-up.

On a merge, the notice goes away and an "Auto-landed …" note follows. The landed note is ON by default and is declined only when the branch was tagged with land-notice: [off] — its reader is the operator watching the fleet, for whom that green row is the signal that work reached the base. So the ordinary sight is the strip disappearing with a green note under it. (It was briefly opt-in between 2026-09-14 and 2026-09-17, which silenced it across the fleet; see land-notice-field.) The "Couldn't auto-land …" note is likewise not gated and always posts: bad news always finds the author.

Because the terminal give-up line never renders here, this notice never duplicates a give-up line in-thread — the passive "Couldn't auto-land …" transcript note is the single record. (The old pinned red "Merge failed · Workspace preserved" session banner this once had to avoid double-reddening against was removed 2026-08-24 as redundant noise.)

Relationship to the Dev Pipeline panel

The Dev Pipeline panel shows the auto-lander globally (its queue, live status, and land history across all repos). This notice is the per-session view of that same data, surfaced where you're already looking — in the thread of the session that did the work. Both are read-only views over the one auto-lander.

Mobile

Works over Web Access on your phone like the rest of the session view — the status read is a read-only channel exposed to the mobile bridge (it carries no controls, so there is nothing to gate).

For agents

How it works

• Read-only, no new tracking. It is derived on demand from the auto-lander's existing reads — the ready-to-merge queue, the live worker status (whose per-branch "waiting" reason powers "why it's stuck"), and the durable land-event history — combined per session.
• The "waiting" reason is a TOP-8 sample, not a census — the queue count is not. The worker status carries at most 8 waiting branches, sorted longest-waiting-first, and it is emptied when the auto-lander is switched off, so a branch outside that sample shows no reason. Whether a branch holds a slot does NOT come from that sample: it is the wait ledger's own "a person owns this" verdict, the same one the footer chip's depth and the auto-lander's own attempt order use, so "#N of M" never disagrees with the chip. A branch a person owns that the sample does not name reads as amber Waiting to land with no slot; an automatically-handled deferral outside the sample still reads as plain "Queued to merge". Both are display gaps, never a landing decision.
• Correct session linkage. Each branch is matched back to its owning session using the same resolver the durable land history uses, so the notice agrees with the history even for dev-pipeline sessions whose managed branch field is blank (matched by their worktree path).
• Efficient refresh — only while you're viewing it. Only the visible session panel drives the refresh (mount load + the auto-lander's on-change push + a light poll while a branch is still in flight); hidden panels read the one shared data slate passively, so there is no redundant background polling. That is the "super low-CPU, updates only when you're looking" path.
• No feature flag. It self-gates by data: with no active auto-lander queue status for a session there is no notice, so it never clutters the UI of anyone who isn't using the auto-lander.
• "Landing automatically" vs. "Needs you" is decided from who actually owns the branch — the auto-lander's own live fix-tracking (an active rescue → an agent is on it), the outcome (a transient retry, a translation, a rebase → automatic), and the two inherently-human cases (a flagged secret, or uncommitted main-folder changes when the auto-preserve setting is off). If a rescue runs past its window without landing, it honestly flips to Needs you — so the strip never claims "automatic" for a branch that is actually stuck. "Automatic" is also bounded: a deferral or a stale tag that has persisted for a full stuck window with no rescue in flight flips to Needs you even though nothing "failed", and a give-up the auto-lander recorded is shown the moment it exists — a wait that reads as self-healing forever is exactly the lie the strip is meant to prevent. The calm "still landing" wording is used only for a land the auto-lander can positively see running slowly, and only while that attempt is still the live one: once nothing is attempting the branch, the row says what the last attempt did instead of claiming a land is running — a row describing a process that is not running is the same lie from the other side. A deferral the auto-lander cannot name reads as a plain deferral.

Related

dev-pipeline-panel.md shows the auto-lander globally — its queue, live status and land history across every repo — where this notice is that same data narrowed to the one session in front of you. For the rest of what this library holds, INDEX.md is the map.