Skip to main content

Objectives Screen

This page owns the player-facing workspace for clues, missions, objectives, and important discoveries, with links into the persistent Journal when discovery or memory context matters.

Role

The Objectives screen should tell the player what matters and why.

It is the planning workspace for the high-level stack: objective first, then clues, missions, and any composed activity approach the player is using to pursue them. It should also surface the Journal entries that record how the MC understands those threads without turning the screen into a prose log.

It sits below Current Plan and above Queue: Current Plan summarizes what matters now, Objectives explains why it matters, and Queue carries the atomic activities that execute it.

It Should Show

  • current objectives as high-level goals or arcs
  • unresolved clues or leads, with clue uncertainty kept visible
  • active missions
  • journal-linked discoveries or prior Journal records when they materially explain why a clue, mission, or territory now matters
  • active composite or routine activity shapes where a mission or recurring routine has a recognizable composed approach
  • recent discoveries with strategic consequence
  • direct links into Territories, sites, actors, and the queue activities the player may need next

State-Gated Objective Flow

Objective rows unlock, redirect, or resolve on explicit preconditions. A new day does not by itself create a new objective, upgrade a clue into a mission, or surface later-act story beats. If the player camps or trains for several days while the same state remains unresolved, Objectives should preserve that unresolved state until the next gate actually fires.

Design Rules

  • Keep uncertainty visible when a clue is only partial.
  • Show strategic context, not only a flat todo list.
  • Let the Journal own long-form rereadable prose. Objectives should show the planning consequence and link back to the relevant Journal page when memory or interpretation matters.
  • Do not let composite or routine activity labels replace the underlying mission structure or the shared Activity Detail inspector. The screen should explain the structure, not hide it; players should be able to drill from a mission or objective row to the Activity Detail inspector for the specific atomic activities that execute it (see gd-shell-screen-model.md § Activity Detail). "Routine Activity" and "Composite Activity" are planning-layer readback labels — they are not SECS source keywords, not separate runtime executor types, and not new planning nouns above activity / policy.
  • Let the player drill into the queue or dossier from any important row.
  • Do not let absolute day count stand in for a real objective-state change.

Activity Detail Cross-Reference

Activity links surfaced in Objectives — the linked activity chip on a clue, a mission's step list, or an objective row that points at an atomic activity — are canonical openers for the shared Activity Detail inspector defined in gd-shell-screen-model.md § Activity Detail. Opening an activity link from Objectives passes objective opener context to Activity Detail: source surface 'objectives', the activity def id, the objective reference, and the mission reference when present. Objectives does not own activity execution state; it links to Activity Detail for inspection and to Queue for execution.

Map Navigation From Objectives

Territory links inside Objectives route through the canonical map interaction contract documented in gd-shell-screen-model.md § Map Interaction Contract. A Territory chip click is equivalent to a left-click on that Territory on the map: it selects the Territory and updates the compact or wide panel state. Double-clicking the chip is equivalent to a double-click on the Territory (focus, zoom, open the full-mode planning board). Objectives does not bypass the canonical interaction contract with a dedicated drill-in surface.

Implementation status

Surface / BehaviorShipped waveStatus
Objectives screen — current objectives, clues, missionsWave CShips via ObjectivesReadModel + useObjectivesDossier; richer mission and clue structure remains partial per gd-journal.md § Runtime Status
Objectives activity link chip → Activity Detail (source: 'objectives')DeferredObjective-to-activity link chip is not yet shipped; the canonical opener-context tag 'objectives' is the Wave M target
"Routine Activity" / "Composite Activity" readback labelsWave C / docs-onlyPlanning-layer readback labels only; no source-language commitment (Routine / Composite ADR remains open)
Map navigation from objectives chipsWave CRoutes through the canonical map interaction contract, not a dedicated drill-in surface