fix(desktop): stabilize burst follow-up messages

[hqhq1025]

Summary

• route rapid follow-up submissions using submit-time Runtime Host state instead of a stale rendered streaming value
• expose explicit Queue and Steer modes while a turn is active
• render the authoritative next-turn queue and let users retract full message content back into the composer
• deduplicate identical active error toasts from one burst failure

Refs #2262

Visual verification

Before: an active turn has no visible follow-up mode or queued-message state.

After: Queue is the default, Steer remains explicit, and queued content is visible and retractable.

Verification

• npm --workspace @maka/ui run test:dist (204 passed)
• npm --workspace @maka/desktop run test:dist (1158 passed)
• npm --workspace @maka/desktop run build:with-deps
• npx playwright test --config e2e/playwright.config.ts streaming-remount.spec.ts (3 passed)
• npx biome check on changed TypeScript, TSX, and CSS files
• isolated real Electron startup and visual inspection
• GitHub CI passed on bbf8bbbcc

Scope

This intentionally leaves queue editing, per-entry deletion, reordering, promotion, and pause/resume for separate Runtime Host protocol and durability work.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Codex implemented the focused Desktop queue integration, tests, documentation, and verification. The affected commit retains the Generated-by: Codex trailer.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[Astro-Han]

I found one P3 at exact head bbf8bbbcc4fb0de41fc47b4f99b791d8ec7937d4; no P0–P2 findings.

[P3] “Retract all” remains visible when only an in-flight steering entry exists

When a steering entry has moved from queued to in_flight and there are no queued or follow-up entries, the composer still renders the queue area and the “Retract all” control. The desktop action then reaches Runtime Host’s #retractQueued path, which only handles state.steering and state.followup, not state.inFlight. The action therefore returns an empty result: it neither retracts the delivered message nor restores the draft, while the UI presents it as available.

Please either render the control only when at least one entry is queued, or define the control explicitly as applying only to queued entries and hide it for an in-flight-only state.

中文

在精确 head bbf8bbbcc4fb0de41fc47b4f99b791d8ec7937d4 上发现 1 个 P3，没有 P0–P2。

[P3] 仅剩 in-flight steering entry 时仍显示 “Retract all”

当 steering entry 从 queued 变成 in_flight，且没有其他 queued/followup entry 时，composer 仍会渲染队列区域和 “Retract all” 控件。桌面端随后进入 Runtime Host 的 #retractQueued 路径，但该路径只处理 state.steering 和 state.followup，不处理 state.inFlight。因此该动作返回空结果：既不会撤回已投递的消息，也不会恢复草稿，但 UI 仍把它呈现为可用操作。

建议只在至少存在一个 queued entry 时渲染该控件；或者明确该动作只作用于 queued entry，并在仅剩 in-flight 状态时隐藏它。

[Astro-Han]

Following up on our earlier comment at this head — a second reviewer went over the same diff independently, and found one thing the first pass did not. Still at exact head bbf8bbbcc4fb0de41fc47b4f99b791d8ec7937d4; the test check is green but the aggregate commit status is still pending, so this remains a COMMENT.

[P3, reachable on a concurrent-failure path] Toast de-duplication drops the session, so one session's error can hide another's.

toastContentKey in packages/ui/src/toast.tsx builds its key from [variant, title, description, action?.label] only. push then reuses the existing toast id for a matching key, so a second toast with identical content replaces the first rather than appearing alongside it.

The session identity is available and discarded: ToastInput carries diagnosticTarget, whose variants all include sessionId, and the session error path populates it.

Concretely: two sessions fail concurrently with the same message text — which is precisely the burst condition this PR addresses. The second toast overwrites the first, so one failure never becomes visible to the user, and the action attached to the surviving toast (Retry, for instance) targets the other session. The user sees one error and retries something they did not intend to.

The added toast.test.ts covers same-content de-duplication and non-merging of different errors, but has no cross-session case, so nothing here fails today.

Including sessionId (or a scope discriminator) in the key, or bucketing toasts per session, would close it. Not blocking, and orthogonal to the queue changes that are the substance of this PR.

One thing we withdrew. We had a candidate finding about lastIndexOf re-anchoring during reference remapping and dropped it: for any realistic input the appended text's start is the rightmost occurrence within the window, and the empty-displayText and activeId-switch cases are both guarded. We could not construct a reproducing input, so we are not reporting it.

Also re-verified independently: the Retract all behaviour from our earlier comment holds — #retractQueued takes [...state.steering, ...state.followup] and never touches state.inFlight, and the UI clears the whole queue display afterwards, so the in-flight message is still delivered while its queue indicator disappears. Two reviewers reached that one separately.

We also checked and found nothing wrong with the routing change itself: the legacy sessions:steer path and the new sessions:enqueue(current_turn) both reach the host's submitMessage with placement=current_turn, so there is no semantic regression, and the new path handles the started/queued disposition the old one ignored.

---

This review was AI-assisted. Findings were verified against the exact head listed above; any mistakes are ours to correct — please push back where we got it wrong.

[jackwener]

Authorized by @WAWQAQ in Raft task #9 after independent review at exact head d7c5d4e. The two prior old-head P3 findings are closed; no new blocking findings; required test is terminal green.

[Astro-Han]

Thanks — both points from our previous comments are fixed, and each is fixed at the right level rather than at the symptom.

Re-reviewed at exact head d7c5d4e146ea8e6e3b052cabbf0b787f8fe3dab7. Our earlier comments were against bbf8bbbc, so they no longer bound; this is a fresh pass.

Retract with only an in-flight entry — fixed. composer-message-queue.tsx now derives hasRetractableEntries from entry.state === 'queued' and gates both the render and the handler on it, so the control is absent rather than present-and-inert. Guarding the render alone would have left the callback reachable; guarding both is the thorough version. does not offer retract when only an in-flight steering message remains pins it.

Toast de-duplication across sessions — fixed, and fixed at the key rather than at the call site. toastContentKey now folds in a diagnosticScope derived from diagnosticTarget — ['session', sessionId, …] or ['profile', profileId]. Two sessions failing with identical text no longer collide, which was the case this PR's own burst scenario made reachable. Patching the individual caller would have left the next one exposed; changing the key closes the class. The three added cases cover same-session de-duplication, cross-session non-merging, and different errors within one session.

The delta over the previous head is confined to those two fixes and their tests — four files, nothing else carried along.

No findings — no P0, P1, P2 or P3. test is green on this head. Approving.

---

This review was AI-assisted. Findings were verified against the exact head listed above; any mistakes are ours to correct — please push back where we got it wrong.