Refactor ship control layers and update docs

NEXT-STEPS.md

@@ -0,0 +1,130 @@
+# Next Steps
+
+## Economic Growth
+
+The current economy already supports:
+
+1. mining ore
+2. hauling to refining
+3. refining / fabricating goods
+4. spending those goods on ships and outposts
+
+The next step is not “invent a use for refined goods.” That use already exists.
+
+The next step is to make faction growth more intentional and legible.
+
+Recommended work:
+
+- make shipbuilding priorities reactive
+  - build more miners / haulers when ore throughput is low
+  - build escorts when industrial losses rise
+  - build warships when frontier pressure rises
+- make expansion logic consume the economy more visibly
+  - use industrial stock to claim and fortify central systems
+- expose production pressure in UI
+  - show ore throughput
+  - show fabricated goods
+  - show queued faction priorities
+
+## Pirate Harassment
+
+Pirates already exist and can raid, fight, and destroy ships.
+
+What they are missing is sharper industrial harassment behavior.
+
+Recommended work:
+
+- prioritize miners, haulers, and refinery approaches as pirate targets
+- add local threat weighting around:
+  - resource nodes
+  - refinery docking lanes
+  - undefended transport routes
+- force empires to react by:
+  - escorting miners
+  - patrolling refinery systems
+  - building defensive stations sooner
+
+This will make the industrial loop produce strategic tension instead of just passive growth.
+
+## High-Value Gameplay Sequence
+
+The most useful short-term gameplay loop to solidify is:
+
+1. miners feed refining
+2. refining feeds ship production
+3. pirates harass industry
+4. empires respond with escorts, patrols, and new outposts
+5. stronger economies produce stronger military presence
+6. system control shifts based on industrial strength and protection
+
+That turns the simulation into a real strategy loop.
+
+## Concrete Implementation Order
+
+1. Add faction production heuristics based on current economy and losses.
+2. Make pirate target selection explicitly prefer economic targets.
+3. Surface faction stocks, throughput, and build priorities in the HUD/debug views.
+4. Expand the order/behavior set with higher-value RTS actions like `hold-here`, `attack`, and `defend-area`.
+5. Break [src/game/GameApp.ts](/home/jbourdon/repos/space-game/src/game/GameApp.ts) into smaller planning / faction / combat / logistics modules.
+
+## Migration To .NET
+
+If the long-term goal is multiplayer, scale, persistence, or server authority, a .NET migration is a sensible next architectural track.
+
+Recommended direction:
+
+- keep the current Vite / Three.js client for rendering and input
+- move simulation authority into a .NET backend
+- treat the browser client as a renderer + command UI
+
+Suggested migration phases:
+
+1. Define a shared simulation contract.
+   - ship state snapshots
+   - orders
+   - behaviors
+   - assignments
+   - combat / economy events
+
+2. Extract the pure simulation model from the Three.js runtime.
+   - separate rendering state from simulation state
+   - remove direct scene dependencies from game logic
+
+3. Rebuild the simulation core in .NET.
+   - `Order`
+   - `DefaultBehavior`
+   - `Assignment`
+   - `ControllerTask`
+   - faction economy
+   - combat resolution
+
+4. Add server-driven ticking.
+   - authoritative world step on the server
+   - deterministic or near-deterministic update model
+   - event stream / snapshot replication to clients
+
+5. Add persistence and multiplayer infrastructure.
+   - saves
+   - world seeds
+   - reconnect support
+   - eventually player ownership / fog / permissions
+
+Suggested .NET stack:
+
+- ASP.NET Core for API / realtime transport
+- SignalR or custom websocket layer for simulation updates
+- PostgreSQL for persistence
+- background hosted service for world ticks
+
+Suggested immediate prep before migration:
+
+- isolate simulation data structures from rendering objects
+- isolate faction AI from UI code
+- isolate travel / docking / mining / combat systems into separate modules
+- make event emission explicit and serializable
+
+The key rule for the migration is:
+
+- do not port Three.js-shaped code into .NET
+- first separate the simulation from rendering in TypeScript
+- then move the pure simulation into .NET cleanly