Mission control selection represents an operator’s current focus in one surface: a Mission stage, Mission task, Mission artifact, Agent execution, or other valid focus target. It is not part of the Mission’s durable work record.
Selection is surface-controlled and resolved by Open Mission against canonical Entity data. A surface may request selection changes, but it validates and normalizes those requests against the shared client-side Entity instances held in the Open Mission application context for that host process. This prevents surfaces from inventing invalid focus while keeping focus local to the operator/session that requested it.
Mission control selection must not be persisted as durable Mission state or broadcast as the current focus for every surface. One operator clicking a task should not move another operator’s current focus. Durable shared navigation changes belong in canonical Entity relationships, not selection.
Mission uses two selection layers in Mission mode:
- raw selection: the current surface/operator focus target
- resolved selection: the Open Mission app-resolved work bundle companion panes consume
Raw selection records what the operator selected. Resolved selection records what the Mission control surface should present alongside that target, such as an active instruction artifact, an active stage result artifact, or an active Agent execution.
Selection resolution belongs to the Open Mission app model layer or a shared semantic selection resolver beneath it. It operates on the application context Entity graph and must not be duplicated in component-local state, artifact bindings, Agent execution bindings, terminal substrate observations, or host-specific Open Mission code.
.svelte components may display the current selection and dispatch selection requests, but they are not independent owners of selection truth. The client host must keep one coherent selection state over one shared application context Entity graph so every pane reads the same resolved focus instead of reconciling its own private copy.
Task selection resolves from explicit semantic relationships. A task row resolves to its canonical instruction artifact and, when task-scoped Agent executions exist, the most recently updated task-scoped Agent execution. A task artifact row may pin the active instruction artifact while preserving the same preferred execution rule. A task without a resolvable canonical instruction artifact is invalid Mission state, not a UI fallback case.
Stage selection resolves to the stage’s canonical result artifact. If a workflow permits more than one result artifact for a stage, the Mission workflow definition must identify the canonical result artifact for selection resolution.
Agent execution selection pins the explicitly selected Agent execution. If that Agent execution is task-scoped, resolved selection may include the owning task and its canonical instruction artifact. Mission-scoped, repository-scoped, system-scoped, and artifact-scoped Agent executions resolve from their explicit AgentExecutionScope and must not be forced through a task relationship.
Resolved selection is derived view state. It must not be persisted as pane state in Mission runtime data, and surfaces must not infer it from filenames, tree order, or host-local cursor state.
This keeps operator focus ergonomic and local while preserving daemon authority over valid Mission references and companion-pane semantics.