Queued prompts - every variant
The queued-prompt pile, in the variants it can be in. Every tile is the same foot: the queue pile above the surface, whose first lane is the strip and whose second is the box or the prompt's own lane - the lanes are drawn as web-session.html and web-composer.html draw them today, and the pile is new here. Every tile draws the real states; the timings under
The wire are the measured ones.
sources: you · cron · gotify · slack · peer · forge
one 16px arc per queued prompt; no cap
words only on the face; arcs are clean
How many are queued
Where the cursor is
Delete and delivery
A question is parked
Edges
What the wire does (measured)
send forge writes the prompt with uuid 4f9c… - the card enters the pile
queued {"type":"command_lifecycle","state":"queued","command_uuid":"4f9c…"} - card stays; 1-5 ms after the send
started {"type":"command_lifecycle","state":"started","command_uuid":"4f9c…"} - that card drains into the chat, as the row it becomes, carrying its wait (queued 0:0n · sent); 2-3 ms after the CLI removes it from its queue, which is the turn boundary or an absorption into the running turn. While it waited, the card was the only drawing of the words - the chat row is drawn at this frame, inside the interrupted turn when it was absorbed
completed {"state":"completed","command_uuid":"4f9c…"} - the turn that carried it ended
delete {"subtype":"cancel_async_message","message_uuid":"4f9c…"} - the CLI drops it; answers {"cancelled":true}. Too late answers false, and the card has usually drained by then
parked question - every prompt arriving is queued and stays; the answer lands, and all of them go started in the same instant, delivered in the one request that carries the answer. A row that left by discarded or refused leaves its words on the ending line, truncated like a card
All of this carries only when forge stamps a uuid on each prompt; without it the CLI emits no lifecycle frames at all (measured: 0 frames with no uuid, 6-9 with).