Valenar - Territory Dossier

This page owns the deep inspection surface for a selected Territory. The Territory dossier surfaces in three panel modes — compact, wide, and full — coordinated with the shell-level panel-mode vocabulary in gd-shell-screen-model.md.

Role

The dossier explains why a Territory matters and what the player currently knows about it.

It should gather only the world truth the player has earned so far:

• Territory facts and current knowledge state
• nearby approaches and travel context
• generated clues and Features
• visible Threats
• discovered or enterable Sites
• place-specific activities and follow-up planning
• linked Journal records, lore records, or annotations when prior discovery is part of why the place matters
• presentation-layer marker summary derived from Feature, Site, Threat, clue, and activity-availability state

Conceptual Sections

• Overview - terrain, topology, control, and broad strategic readability
• Survey - knowledge depth, unknowns, survey progress, and notable signs
• Activities - causal activities available from current Territory, Feature, Threat, and Site state
• Features - notable signs, facts, or generated content that are not yet full site entries
• Approaches - routes, access lines, nearby ingress or egress, and dangerous approach context; hosts the route preview overlay handoff
• Threats - pressure or hostile presence attached to the Territory, Features, or Sites
• Sites - first-class places such as mines, wards, restored ruins, and dungeon sites

These are conceptual sections, not a commitment to one exact tab or row implementation.

State-Gated Place Context

The dossier surfaces place truth according to knowledge state and linked objective, clue, mission, or branch preconditions. A calendar day change does not by itself promote a Feature into a Site, advance a threat state, or unlock a Journal link. If the player camps or trains for several days, the dossier remains anchored to the last earned place state until new scouting, mission, or branch conditions resolve.

Panel Modes

Compact

Compact mode answers "what is this / what matters now?" It keeps the map visibly dominant and surfaces:

• Territory name and terrain identity
• knowledge state (unknown / hinted / scouted / surveyed)
• headline survival readback (water / shelter / food / fuel availability where known, without inventing specific numeric thresholds)
• danger and corruption pressure where known
• top three to five quick activities relevant to current Territory state
• marker summary line — a one-line count of Features, Sites, Threats, or clues currently visible at this Territory
• a "Right-click for quick activities" hint surfacing the ContextPanel entry point
• an "Open Dossier" cue that promotes the selection to wide mode

Compact mode does not show every available activity. The full ContextPanel quick-activity menu is reached via right-click on the map; compact's top-N activities are a shortcut, not a replacement for the canonical entry point.

Wide

Wide mode answers "what can I do / what are the consequences?" It preserves shell context (rail visible, map present) and provides deep inspection:

• Overview tab with terrain, control, topology, claim state
• Activities tab with available activities grouped by context source (Territory, Feature, Approach, Camp, Survey — matching the Stage0 grouping model); each row carries a hover tooltip for read-only summary and a Queue button as the canonical enqueue affordance; clicking the row name or icon opens the shared Activity Detail inspector (see gd-shell-screen-model.md § Activity Detail) with Territory Dossier context preserved (territory id, source surface 'dossier'); a blocked-reason chip is shown on the row when a blocked reason is available (client-derived today; server-confirmed blocked reason is Wave B-owned, pending sync — see gd-queue-screen.md § Queue State Vocabulary)
• Features tab with notable signs and generated content
• Approaches tab with travel routes, access lines, and the route preview handoff (see Route Preview below)
• Threats tab with pressure and hostile presence; explicit empty-state copy when no threats are known
• Sites tab with discovered or enterable Sites; explicit empty-state copy when no sites are identified
• known versus unknown facts kept legible — unknown information reads as unknown, not as empty or falsely precise

Wide mode does not fabricate site, threat, or service content. Surfaces with no real backing data display an explicit empty-state string rather than mock rows; this is the rule that retired the prior mockServices() placeholder.

Activities tab detail behavior

The Activities tab in wide mode is one of the canonical openers for the shared Activity Detail inspector defined in gd-shell-screen-model.md § Activity Detail.

Opening a row from the Activities tab passes Territory Dossier opener context to Activity Detail: the source surface is 'dossier', the territory id is preserved as the place context, and the opener back-stack records the dossier tab so the player can return to the dossier at the same tab via the back affordance or by clicking the source-surface crumb in the Activity Detail breadcrumb. Activity Detail does not replace the Territory Dossier — the dossier retains its compact / wide / full panel-mode contract and Activity Detail opens as a nested drill-in state of the same left overlay slot.

Territory Dossier does not own activity execution state. Queue, Schedule, and Cancel commands exposed inside Activity Detail route through the canonical queue path; the dossier read model updates reactively when queue state changes.

For each row the dossier surfaces:

• a hover tooltip (read-only) for compact preview, driven by the shared data-tip-id tooltip engine
• a Queue button as the canonical enqueue affordance
• a blocked-reason chip when a blocked reason is available (client-derived today; server-confirmed blocked reason is Wave B-owned, pending sync)
• an explicit "open Activity Detail" affordance on the row name / icon

The dossier no longer surfaces a per-row inline detail panel; deep inspection lives inside the shared Activity Detail inspector.

Full

Full mode answers "how do I plan, compare, manage, optimize?" Full is the Territory planning board. It is not a stretched wide layout; full is a distinct component (TerritoryPlanningBoard in the Wave C client) with a two-row layout:

• top row: spatial overview of the Territory and its neighbourhood, plus the route preview card for any pending travel
• bottom row: activity planning card, nearby Territory comparison, camp suitability comparison grid, and a queue preview strip

Full mode surfaces:

• Territory summary headline reused from compact
• nearby Territory comparison — neighbours with quick readback of their terrain, survival readback, danger pressure, and known activity availability
• marker stack overview — every marker currently presented at this Territory, grouped by source row (Feature / Site / Threat / clue / activity hint)
• route preview — the same overlay surface as in Approaches, expanded for planning, including travel time, stamina cost, danger per segment, nightfall risk, and known versus unknown segment shading
• camp suitability comparison — relevant camp candidate markers and how current Territory compares to neighbours
• activity category rows — the same category labels the ContextPanel uses (Travel, Survival, Explore, Planning) presented as planning rows; the labels are presentation grouping, not a behavior taxonomy
• queue preview strip — the activities already enqueued from this Territory and the activities the player is staging
• map-mode legend reused from the strategic shell
• known versus unknown breakdown

Full mode reuses wide-mode tabs (Features, Approaches, Threats, Sites) inside the planning board where appropriate. Reuse does not collapse the distinction between wide and full: full owns the planning-board layout, the comparison columns, and the route preview surface in its planning form.

Marker Presentation Summary

The Territory dossier surfaces a marker summary in compact mode and a marker stack overview in full mode. Markers are presentation-layer visualizations derived from existing Territory / Feature / Site / Threat / clue / activity data; they are not a new gameplay entity.

This section is summary only. The authoritative marker taxonomy, positioning rules, zoom aggregation, and priority order live in ../systems/gd-map-markers.md.

Route Preview

The Approaches section and the full-mode planning board surface a route preview overlay before the player commits a travel activity to the queue. The overlay shows:

• pre-enqueue route line on the map canvas
• destination marker at the target Territory
• travel time and stamina readback
• danger per segment
• nightfall risk
• known versus unknown segment shading
• hover breakdown per segment

The route preview is a shell overlay, not a queue row. Committing the previewed route enqueues a travel activity through the canonical queue path; the preview overlay then clears.

ContextPanel Cross-Reference

Right-clicking the Territory on the map surfaces the anchored TerritoryContextPanel with grouped quick activities (Travel / Survival / Explore / Planning). The ContextPanel is part of the shell map interaction contract, not part of the dossier; the dossier surfaces a hint to it from compact mode and reuses the same category-label grouping in the full-mode planning board's activity rows. See gd-shell-screen-model.md § ContextPanel for the canonical behavior.

Taxonomy Rules

• Use site-first wording. A dungeon, mine, ruin interior, or ward Territory belongs in Sites once discovered or enterable.
• Unknown dungeons can appear only as clues, Features, or threat signs until they become Sites.
• Unknown or nonexistent content must not be shown as known rows.
• Site wording should stay explicit about state: wild, discovered, secured, active, owned, developed, depleted, sealed, destroyed.
• Threats stay attached to the relevant Territory, Feature, or Site context; they do not replace the underlying place entry.
• From a Site row, the player can move into related activities or the separate combat/dungeon surface without losing Territory context.

Design Rules

• The dossier must preserve uncertainty. Unknown information should read as unknown, not as empty or falsely precise.
• Feature, Threat, and Site sections should stay causal and world-specific.
• The dossier should connect scouting, survey, threat handling, site exploitation, and planning without inventing content the player has not earned.
• The dossier can link out to Journal, but it does not replace the Journal's structured memory records and annotations.
• Compact, wide, and full are three distinct surfaces with three distinct questions. Full must never be authored as a wider-canvas copy of wide.
• Empty states must be truthful. Surfaces with no real backing data must show explicit empty-state copy rather than mock rows or fabricated services.
• Territory progression follows knowledge and mission state, not day count.

Implementation status

Surface / Behavior	Shipped wave	Status
Wide-mode Activities tab — grouped rows, hover tooltip, Queue button	Wave C	Ships via Stage0ActivityRows in the territory panel; per-row inline detail panel was removed in favor of tooltip
Activities row → shared Activity Detail navigation	Wave C	Partial: clicking a row navigates to the Activities panel today; opener-context tag 'dossier' and dossier back-stack are deferred (Wave C / Wave D follow-through)
Forest Stand / available-activity dossier example (e.g. ForageForest)	Wave C	Ships: row appears under the Forest Stand group when the territory is forest-tagged in Act 0
Blocked-reason chip on dossier activity rows	Deferred, Wave B	Client-derived only today; server-confirmed blocked reason is Wave B-owned, pending sync
Recursive drill from a dossier-origin Activity Detail	Deferred, Wave B	Requires the activity run snapshot to project parent-run / child-run references — Wave B-owned, pending sync

Cross-Links

• gd-shell-screen-model.md
• gd-journal.md
• gd-objectives-screen.md
• gd-queue-screen.md
• ../catalogs/gd-activity-catalog.md
• ../systems/gd-territories-features-sites.md
• ../systems/gd-sites-and-dungeons.md
• ../systems/gd-map-markers.md
• ../systems/gd-objectives-clues-missions.md
• ../generation/gd-territory-generation-contract.md