You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The server already supports reordering a thread's queue (queued-run.reorder, with guards that keep automatic completion deliveries first), but only agents can use it, through t3_queue_reorder. In the UI I can Send now, edit or remove a queued message, but not change its order.
When I hit it. During a long turn I queue three follow-ups, then realise the third one ("actually, skip the migration") should run before the other two. Today I have to remove and retype two messages (and re-attach their images) to get the order right.
Proposal (UI only, no contract or server change):
Web/desktop: Move up / Move down on each queued message, next to edit and remove, when two or more user messages are queued. Disabled at the ends and while another queue action is in flight. Automatic completion deliveries aren't in the visible queue, so they stay first.
Mobile: the same two actions in the queued message's long-press menu in ThreadQueueControl.
The new order shows at once and rolls back with the server's error if the command is refused.
Docs: one paragraph in docs/user/composer.md → Queued messages.
Drag-to-reorder could come later. Buttons first because they work with a keyboard and on touch, and stay small.
I have a working branch on my fork, with tests for the client command, the move logic, the web control (browser test) and the mobile row controls. I'll keep it unopened until the direction and scope are approved here. Would a PR scoped to this be welcome?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
The server already supports reordering a thread's queue (
queued-run.reorder, with guards that keep automatic completion deliveries first), but only agents can use it, throught3_queue_reorder. In the UI I can Send now, edit or remove a queued message, but not change its order.When I hit it. During a long turn I queue three follow-ups, then realise the third one ("actually, skip the migration") should run before the other two. Today I have to remove and retype two messages (and re-attach their images) to get the order right.
Proposal (UI only, no contract or server change):
ThreadQueueControl.docs/user/composer.md→ Queued messages.Drag-to-reorder could come later. Buttons first because they work with a keyboard and on touch, and stay small.
I have a working branch on my fork, with tests for the client command, the move logic, the web control (browser test) and the mobile row controls. I'll keep it unopened until the direction and scope are approved here. Would a PR scoped to this be welcome?
All reactions