Queue Screen
This page owns the explicit execution view for queued work. It sits below Current Plan and Objectives. It executes atomic activities, with mission or planning context shown only as supporting labels.
Role
The Queue screen should answer:
- what activities are executing now
- what activities are queued next
- what is blocked or waiting
- what mission or planning context each activity belongs to when that context exists
- what actor or site each line belongs to
Queue State Vocabulary
The queue has one canonical state vocabulary. Every UX surface that surfaces a queue row — Queue screen, Current Plan, Location dossier wide and full panels, Objectives — uses these words verbatim. Local synonyms drift the player's mental model and are a process FAIL.
| State | Meaning |
|---|---|
| Running | The activity is the active head of the queue and is consuming actor or world time right now. |
| Queued | The activity has been committed to the queue and will run when its predecessors finish; no blocker is known. |
| Blocked | The activity is in the queue but cannot start. A blockedReason chip on the row explains why (missing prerequisite, prevailing condition, prior blocker). |
| Preview | A pre-commit overlay state for activities the player is staging but has not yet enqueued. The route preview overlay is the canonical example. Preview is not a queue row; it surfaces in the shell overlay layer. |
| Suggested | A recommendation surfaced in the queue's footer section. The player has not committed it; it is a presented option, not a queued activity. |
| Scheduled-Repeat | A routine activity authored to fire on a cadence or trigger. Schedule-repeat rows have their own visual treatment so the player can distinguish "this fires every day at dawn" from a one-shot Queued row. |
Filter vs decoration vs section
The QueueNavigator filter tabs are all | now | queued | scheduled and only
these four. Blocked is not a filter tab; it is a row decoration chip
applied to a Queued or Running row when a blocker is known. Suggested is not
a filter tab; it is a footer section underneath the filtered queue rows.
Today the Suggested footer is populated from "first five activities currently available at the player's location" client-side. Server-pushed Suggested activities are a planned extension, not yet implemented; until that ships, the Suggested footer is best-effort client derivation.
blockedReason on a queue row is client-only today. The server snapshot does
not yet carry a blockedReason field; populating it from the server is
planned but deferred.
ContextPanel as a Queue Entry Point
The right-click LocationContextPanel on the strategic map is one of the
canonical entry points into the queue. ContextPanel selections route through
the same enqueue path as compact and wide panel buttons (the
enqueueScheduledActivity and enqueueTravel calls), so a ContextPanel-driven
queue row is indistinguishable from any other queue row except by source
attribution. See
gd-shell-screen-model.md § ContextPanel for the
shell-level contract.
Design Rules
- The queue should stay concrete and low-ambiguity.
- Queue rows should remain atomic activities even when the player thinks about them as part of a larger plan.
- Higher-level planning labels should not replace queue rows.
- Ordering, cancellation, and dependencies must be readable.
- Queue rows should link back to the objective or place that caused them.
- Older shorthand should be rewritten to activity rather than treated as a competing behavior noun.
- Queue-state wording follows the canonical vocabulary above. Surfaces that drift from this vocabulary are corrected back, not allowed to coexist.