Summary
Build the foundation for the new Missions mode by replacing the static mission-selection view with a generated district map centered on a persistent Workshop/Homebase.
This issue covers:
deterministic daily mission world generation
generated graph/maze paths
Workshop placement
6 contract POIs
visible vs locked contract support
persistent active-run skeleton
initial map-shell rendering
Why
Missions is being redesigned as a Cyberpunk Courier Run loop:
start at Workshop
choose a contract physically embedded in the district
travel to the POI
resolve the mission
return to Workshop for the run to count
This issue creates the spatial and persistence foundation required for everything else.
Scope
Add deterministic district generation keyed per-user/per-day
Add connected graph generation
Add a single Workshop origin node
Add 6 contract POIs distributed onto the graph
Support always-visible and unlockable contracts
Add active-run persistence skeleton
Render the district map shell with path lines and markers
Acceptance Criteria
Opening Missions loads a valid district map instead of only a static mission menu.
The generated district contains a single clearly identified Workshop node.
The generated district contains exactly 6 daily contract POIs.
The graph is connected such that all POIs are reachable from the Workshop.
The same user sees the same district/contracts for the same day unless the daily seed/version changes.
Some contracts are visible immediately and some are marked as locked/hidden behind unlock conditions.
The Missions page renders the district background area, path network, Workshop marker, and contract markers.
An active mission run record can be created and reloaded after refresh, even if full travel logic is not yet implemented.
The data contracts introduced in this issue are sufficient for later work to add pathfinding, encounters, and final mission resolution without redefining the world model.
Design constraints carried across the Missions series
Missions are modeled as round trips starting and ending at the Workshop.
Mission worlds should be generated per-user per-day for consistency, resumability, and cost control.
Generated media should be aggressively cached:
backdrop by user/day world seed
sprite by card + prompt version
Trust-sensitive outcomes should remain server-validated at checkpoints.
Only successful returns mutate the player card.
Failed runs may be recorded as history but should not incur gameplay penalties.
Summary
Build the foundation for the new Missions mode by replacing the static mission-selection view with a generated district map centered on a persistent Workshop/Homebase.
This issue covers:
deterministic daily mission world generation
generated graph/maze paths
Workshop placement
6 contract POIs
visible vs locked contract support
persistent active-run skeleton
initial map-shell rendering
Why
Missions is being redesigned as a Cyberpunk Courier Run loop:
start at Workshop
choose a contract physically embedded in the district
travel to the POI
resolve the mission
return to Workshop for the run to count
This issue creates the spatial and persistence foundation required for everything else.
Scope
Add deterministic district generation keyed per-user/per-day
Add connected graph generation
Add a single Workshop origin node
Add 6 contract POIs distributed onto the graph
Support always-visible and unlockable contracts
Add active-run persistence skeleton
Render the district map shell with path lines and markers
Acceptance Criteria
Opening Missions loads a valid district map instead of only a static mission menu.
The generated district contains a single clearly identified Workshop node.
The generated district contains exactly 6 daily contract POIs.
The graph is connected such that all POIs are reachable from the Workshop.
The same user sees the same district/contracts for the same day unless the daily seed/version changes.
Some contracts are visible immediately and some are marked as locked/hidden behind unlock conditions.
The Missions page renders the district background area, path network, Workshop marker, and contract markers.
An active mission run record can be created and reloaded after refresh, even if full travel logic is not yet implemented.
The data contracts introduced in this issue are sufficient for later work to add pathfinding, encounters, and final mission resolution without redefining the world model.
Design constraints carried across the Missions series
Missions are modeled as round trips starting and ending at the Workshop.
Mission worlds should be generated per-user per-day for consistency, resumability, and cost control.
Generated media should be aggressively cached:
backdrop by user/day world seed
sprite by card + prompt version
Trust-sensitive outcomes should remain server-validated at checkpoints.
Only successful returns mutate the player card.
Failed runs may be recorded as history but should not incur gameplay penalties.