Sectors: Defense, Warp, Navigation¶

What players actually do within and between sectors. Generation is in generation.md; this doc covers runtime mechanics. A sector's celestial contents — star (sun) type, the habitable zone, planets and their orbits, belt/nebula/debris, and the windshield viewport — are specified in star-systems.md.

Movement basics¶

services/gameserver/src/services/movement_service.py:MovementService.move_player_to_sector:

Lock the player row (with_for_update) — prevents double-spending turns from concurrent requests.
Reject if docked or landed.
Reject if the player has no current ship (Player.current_ship_id IS NULL).
Resolve the movement type:
Direct warp (adjacent sector) → cost is Ship.turn_cost (≈1, ship-modified).
Warp tunnel → cost from WarpTunnel.turn_cost (1–3).
Neither → "no path available."
Verify player.turns >= cost.
Execute: deduct turns, update current_sector_id, set home_region_id if crossing into a new region.
Run encounter checks (_check_for_encounters) — pirates, sector drones, etc.
Commit and return.

Movement on the same sector returns success with 0 turn cost.

Warp tunnels¶

Two flavors (covered in definitions.md):

Natural warp tunnels¶

Pre-existing during galaxy generation.
60–80% of sectors connect to the main network via natural tunnels.
Mostly bidirectional; some one-way.
Must be discovered before use — undiscovered tunnels don't appear on the player's map.
Cost: 1 turn to use (some longer-range tunnels cost up to 3).
Cannot be destroyed.

WarpTunnel.type has two values. Full enum in DATA_MODELS/galaxy.md → Type enum:

Type	Source	Gameplay flavor
`NATURAL`	Galaxy generation	Default. Spacetime fold linking sectors based on cluster proximity. Stable, low-risk traversal; the bulk of the universe's tunnel network.
`ARTIFICIAL` (generator)	Galaxy generation	Engineered connections placed among the first `fedspaceSize` sectors of each region (default 1–10) so the starter area stays densely interconnected regardless of random natural-tunnel layout. Indistinguishable from natural tunnels in routing cost and stability; flagged for lore.
`ARTIFICIAL` (player)	Warp gates	Player-built via the beacon/focus pipeline. Owner-controlled, toll-able, destructible. Distinguished from generator-placed by `created_by_player_id IS NOT NULL`.

Direction is captured by is_bidirectional on the row, not by the type. Spacetime-anomaly events fire on low-stability tunnels (see SYSTEMS/sector-presence.md).

One-way warps¶

Full design rationale and alternatives in ADR-0034.

Some natural warps and the long-distance variant of ESCAPE_HATCH are one-way (is_bidirectional = false). One-ways come in two discovery flavors:

Marked (~80% of one-ways). The directional restriction is visible in the player's sector view as a glyph; jumping is informed. The graph has the warp recorded as one-way from the moment the player learns the warp exists.
Latent (~20% of one-ways, is_latent = true). The warp looks bidirectional in the raw sector view until revealed. Reveal happens via a Warp Jumper's existing scan suite — Quantum Jump scan reveals latent warps as part of its standard output, no new module required. Once revealed for a player (or one of their corp-mates — corp-shared scan knowledge applies), the directionality becomes visible. Pre-reveal, the player can attempt to traverse a latent one-way in the wrong direction; the attempt costs the standard turn but lands them right back where they started, with the latent flag now resolved for that player.

Nexus warp visibility filter for free-tier viewers (per ADR-0064 R-V3). The corp-shared scan knowledge rule above creates a corner case for the natural Nexus warp per ADR-0043: a Galactic Citizen corp-mate's discovery would otherwise leak the Nexus warp's existence to free-tier corp-mates who cannot traverse it. The map-visibility query intersects corp-shared knowledge with a per-viewer subscription-tier filter for the Nexus warp specifically — free-tier viewers see no nexus_warp_sector marker regardless of corp-mate discovery. Other latent warps remain corp-shared without filter; the Nexus warp is the singular exception, because its narrative weight is tied to the Galactic Citizen subscription.

No player-placed natural one-ways. Genesis devices and any future "create natural warp tunnel" mechanic produce bidirectional natural warps only — one-way natural warps are a worldgen-only primitive (BACKDOOR, WARP_SINK, ESCAPE_HATCH, and the lost-formation exits below). Player-built warp gates are intrinsically one-way and are a separate mechanism (see warp-gates.md) — they live on WarpTunnel.is_bidirectional = false but are excluded from the natural-warp anti-cheese rule.

Lost-formation exit warps are a special case (per ADR-0070). When the generator stamps a LOST_SECTOR, LOST_CLUSTER, or ARCHIPELAGO and the per-type exit roll lands positive, the resulting one-way warp is marked-only (never latent — discoverers must be able to rely on it for return), is anchored to the formation row via properties.exitWarp / properties.exitWarps[], and is generated as part of the formation stamping pass rather than the ambient one-way pass. From the source side the exit is the only edge out of the lost formation; from the destination side it looks like an ordinary outbound warp with no inbound. The validator correlates each lost-formation exit warp with its parent formation row at import time.

Federation Zone (sectors 1–10) forbids natural one-ways entirely as a worldgen invariant — the starter area's connectivity is guaranteed bidirectional. Player-built gates to Federation Zone destinations are still permitted; the prohibition is on natural directionality, not gate-mediated traversal.

Recovery from one-way stranding (e.g., trapped behind a WARP_SINK): two mechanisms ship in v1.

Slipdrive (Warp Jumper module) — multi-turn charge, fuel cost scaled by graph distance to the nearest non-sink sector. Self-rescue.
Federation distress beacon — free transport to the nearest fedspace sector, at the cost of −10 Terran Federation reputation per use, with a 24-hour cooldown. The panic button. The reputation hit lives in ../gameplay/factions-and-teams.md#reputation-triggers.

Quantum Jump (Warp Jumper) does not bypass one-ways for transit — that would devalue the Warp Jumper's combat-mobility role. Quantum Jump does reveal latent warps as part of its existing scan output.

Player-created warp gates¶

One-way only — round-trip requires two gates.
0 turns to use (the speed advantage that justifies the build cost).
Permanent unless destroyed by attack.
Owner controls access permissions and toll fees.
Built using a Warp Jumper ship (consumed at Phase 3 destination focus anchor per ADR-0029) + 1 Quantum Crystal (= 5 Quantum Shards) + ~1.1M cr all-in + ~14–17 real-time days for the first gate.

🚧 Partial — full gate construction pipeline (beacon/focus placement, multi-day build state, toll collection) is design-stage; the Warp Jumper ship itself is implemented.

Quantum Crystal gathering¶

Tunnel construction needs Quantum Crystals (full chain in quantum-resources.md; player-built gates detailed in warp-gates.md). To make one:

Equip a Quantum Field Harvester (50,000 cr) on a Scout / Fast Courier / Defender / Warp Jumper.
Travel to a nebula cluster — Crimson is best (quantum field 80–100 → highest yield).
Run a harvest: 1,000 cr + 15 turns + 2 hours real-time per attempt; yields 1–3 shards.
Once you have 5 shards, dock at any Class 3+ station or SpaceDock: 10,000 cr + 24 hours = 1 Quantum Crystal (per ADR-0009 — Class 7+ remains required for the harvester install only).

Other shard sources: anomalies (low yield), combat salvage from rare NPCs, black market (50–100k cr/shard, requires Federation-hostile reputation), team pooling.

Quantum Jump (Warp Jumper)¶

✅ Shipped. Distinct from gate travel. The Warp Jumper ship has built-in directional FTL — a multi-phase loop with bearing selection, long-range scanning, and a commit/resolve step. It is the only way to reach isolated clusters that have no natural tunnel to the main network, and it feeds the Warp Gate construction pipeline (see ./warp-gates.md). Decision context: ../../ADR/0030-q1-quantum-jump-multi-step-commit.md, ../../ADR/0031-s1-long-range-scanner-fuzzy-disclosure.md. Backend (services/gameserver/src/services/quantum_service.py, routes at the /api/v1/quantum/* prefix) and the full interactive client console (components/quantum/QuantumDriveConsole.tsx, the NAV "QUANTUM DRIVE" tab) are wired end-to-end; verified live (Echo Scan spends 5 turns and returns resonance/texture/echo telemetry with recharge + fade timers). Residual 📐 design-only pieces remain below (passive compass) and in FINDINGS (sector is_discovered not set on arrival; anonymous defender sweep; HARMONIZING window; companion tow).

Range tiers (in sector hops along bearing):

Band	Range	Cost
Near	5–6 sectors	5 turns scan
Mid	7–8 sectors	5 turns scan
Far	9–10 sectors	5 turns scan + 1 Quantum Shard
Extended	12–15 sectors	5 turns scan + 1 Quantum Shard, requires Sensor L3

Hard constraints across all bands: 24-hour cooldown on the jump itself; 4-hour real-clock cooldown on scans, independent of the jump cooldown; commit costs 50 turns + 1 Quantum Charge regardless of band.

Phase 1 — Bearing, ambient compass, and scan¶

Performed in space at the origin sector with the Warp Jumper undocked. Phase 1 has two information layers — a passive quantum compass that gives free real-time directional feedback as the player rotates the reticle, and an active long-range scan that drills into a chosen bearing for detail.

Minimap. A 3D minimap centred on the current sector renders sectors within ~25 hop-units of true Euclidean distance, computed from Sector.x_coord/y_coord/z_coord integers (see ../../DATA_MODELS/galaxy.md#sector).
Reticle. The player rotates a directional reticle on yaw and pitch and selects a range band (Near / Mid / Far, plus Extended at Sensor L3).

Quantum compass (passive, free)¶

📐 Design-only. As the reticle rotates, a passive quantum compass readout updates in real-time. The compass projects a much wider cone than a scan (half-angle ~60°, so the player is sweeping whole quadrants, not narrow beams) and aggregates two signals into a single coarse reading:

Warp activity — the sum of warp connections across all sectors that fall inside the wide cone.
Sector presence — whether any other players are currently in any of the cone's sectors.

The compass deliberately fuses these two channels into one number so the readout cannot be used as a pure player-tracker. The fused signal is exposed as one of three tiers:

Tier	Player-facing label	Meaning
Cold	"Compass: cold."	No warp activity and no presence in this quadrant — the bearing is not worth scanning.
Stirring	"Compass: stirring."	Some warp activity OR some presence (or both at low levels). The bearing is worth a scan to learn more.
Active	"Compass: active."	Substantial warp activity AND presence, or one of the two at a high level. The bearing is the strongest candidate the player is currently sweeping.

Cost: zero turns, zero credits, zero Shards. No cooldown. The compass updates as fast as the reticle moves and is entirely passive — it does not emit the anonymous "long-range quantum sweep detected" event that scans emit, because nothing is actively probing the destination.

Why it exists: without the compass, the player must spend 5 turns and (on Far/Extended bands) 1 Quantum Shard blind — guessing a bearing, scanning, and discarding scans that hit Cold quadrants. The compass turns scan investment from a guess into an informed bet.

Information leak boundary: the compass never distinguishes between warp activity and player presence — a Stirring reading could be 8 sectors with no players, or 1 sector with 2 players, or anything in between. Players cannot use the compass as a stealth-breaking presence tracker; the scan is the only way to get the echo binary fuzzy on hostile presence, and even then it never reveals identity or count.

Scan (paid, fuzzy detail)¶

Scan. Pressing Scan spends 5 turns; Far and Extended also consume 1 Quantum Shard. The server projects a much narrower cone from the origin along the bearing — half-angle 15°, range = band × inter-sector spacing — and returns a fuzzy resonance reading.
Cooldown. A scan starts a 4-hour real-clock cooldown on further scans from the same ship. Results expire after 10 real-minutes; re-scan to refresh.

Resonance bands¶

The cone returns one of four bands describing connection density in the destination volume:

Band	Threshold	Player text
Bright resonance	≥4 warps avg (5+ warps in volume)	"Bright resonance"
Steady resonance	2–3 connections (3–4 warps)	"Steady resonance"
Faint resonance	1 connection (1–2 warps)	"Faint resonance"
Silent	0 connections, cone empty, or off-region edge	"Silent"

The "Silent" label honors the disclosure rule that low-density readings imply rather than enumerate: the player never sees a literal warp count or a "0 warps" message.

Texture and echo vocabulary¶

Each scan also returns a single texture word and a binary motion echo:

Sector type	Texture word
STANDARD	hollow
ASTEROID_FIELD	mineral
NEBULA	chromatic
BLACK_HOLE	heavy
RADIATION_ZONE	hot
WARP_STORM	turbulent

Hostile-presence echo is binary: silent vs faint motion. The echo never returns counts or identities.

Drift and Sensor upgrades¶

The scan reports a drift estimate — the cone half-angle precision — which narrows when the player stacks scans on similar bearings.

L0 (default): 15% misread probability — the reported band shifts ±1 from true.
Each Sensor level reduces misread by 5pp; L3 → 0%.
L3 also unlocks the Extended (12–15) band.
Texture word and motion echo are exact regardless of Sensor level.

Anonymous sweep event¶

Each scan emits a "long-range quantum sweep detected" event in the destination cone. Defenders in any sector inside the cone see the event with bearing precision degraded to ±45° and a 30-second delay; the scanner's identity is not disclosed. The event reads as "someone is looking from spinward ±45°" — directional only, never a name.

Phase 2 — Commit¶

The player clicks Engage Quantum Jump. The jump tab is greyed out unless a Quantum Charge is loaded in the ship's special-equipment slot.

Spend 50 turns.
Consume 1 Quantum Charge (refined upfront from 1 Quantum Shard at any port that supports refining; pre-staged in the special-equipment slot).
Set the 24-hour jump cooldown.
Lock the Warp Jumper in space at the origin sector while resolution runs.

Phase 3 — Resolve¶

The server projects the bearing vector to the committed range and identifies candidate destination sectors:

Find every existing sector within an accuracy radius of 1.5 inter-sector spacings of the projected endpoint.
1+ candidates: pick one weighted by inverse distance (closest is most likely).
0 candidates: expand the radius once by 1.5×.
Still 0 candidates — MISFIRE. The ship arrives in the nearest existing sector on the bearing line shorter than the committed range. Apply a flat 5% hull damage (insurance does not cover misfire damage; this is not destruction). The 24-hour cooldown and 1 Quantum Charge are still consumed.
On any successful arrival (including misfire), mark the destination as discovered: set sector.is_discovered = true and sector.discovered_by_id = player.id.

Combat during QJ phases¶

Per ADR-0067 X-D4, Quantum Jump is uninterruptible by combat. Combat damage during QJ phases applies to the WJ hull / shields normally; if hull reaches zero at any point, the standard destruction handler fires. There is no ERR_QJ_IN_COMBAT_LOCK validation — the WJ pilot can scan, commit, and resolve a jump while taking fire.

Phase	WJ state	Combat damage handling
Phase 1 (scan)	Attackable; standard `IN_SPACE`	Damage applies normally per `../../SYSTEMS/combat-resolver.md`. If hull → 0, scan aborts; standard destruction handler fires.
Phase 2 (commit window)	Attackable; `IN_SPACE` until Phase 3 transition	Damage applies normally. If hull → 0, standard destruction handler fires; tow auto-detaches per `../gameplay/ships.md#tractor-beam-tow-operations`; towed ship enters `Drifting` at the destruction sector.
Phase 3 (HARMONIZING)	Invulnerable per `../../DATA_MODELS/ships.md` Ship `status` enum	No combat possible. Phase 3 destruction commit fires at timer completion (1-hour harmonization window), not at attacker call time.

The "Quantum Jump as combat escape" pattern this enables is intentional — a WJ pilot who manages to commit Phase 2 before destruction succeeds in escaping; one who doesn't, dies. This fits the WJ's role as a high-cost, high-mobility ship per ADR-0029.

Companion tow through Quantum Jump¶

Tow-through-QJ is a special exception in the Tractor Beam tow rules — see ../gameplay/ships.md#tractor-beam-tow-operations for the base mechanic. Conditions:

The hauler must be a Warp Jumper using its own Tractor Beam (40,000 cr equipment, added to the WJ's eligibility list alongside Cargo Hauler / Defender / Carrier). No other ship class can tow through QJ.
Towed ship size cap: medium max (size_units ≤ 4).
One passenger per jump.
Commit-phase turn cost gets a flat +5 turn surcharge (50 → 55 turns), regardless of towed size.
The towed pilot remains in their own ship (not a Carrier-hangar passenger) and sees the same resonance band reading as the WJ pilot.
If the WJ is destroyed mid-Phase-2, the tow auto-detaches per existing tow rules.
If the WJ is destroyed at the Phase 3 anchor, the tow auto-detaches; the towed ship survives intact in the destination sector.

Quantum Jump endpoints¶

services/gameserver/src/api/routes/quantum.py, backed by services/gameserver/src/services/quantum_service.py. All endpoints are auth-gated (Bearer token); caller must be the WJ pilot of record.

Method	Path	Phase	Purpose
GET	`/api/v1/quantum/minimap`	1	3D minimap of sectors within ~25 hop-units of the origin
POST	`/api/v1/quantum/scan`	1	Run a long-range scan on a bearing + range band
POST	`/api/v1/quantum/refine-charge`	pre-2	Refine 1 Quantum Shard into a Quantum Charge at a refining port
POST	`/api/v1/quantum/jump`	2	Commit to bearing + range; consume Charge, lock the WJ
GET	`/api/v1/quantum/status`	any	Current cooldown, scan-cooldown, lock state, attached tow

POST `/api/v1/quantum/scan` — Phase 1¶

// request
{ "yaw_degrees": 45.0, "pitch_degrees": -10.0, "range_band": "near" }

// response 200
{
  "scan_id": "uuid",
  "expires_at": "2026-05-08T13:35:00Z",       // 10-min result freshness
  "resonance_band": "steady",                  // bright | steady | faint | silent
  "texture": "mineral",                        // hollow | mineral | chromatic | heavy | hot | turbulent
  "echo": "faint_motion",                      // silent | faint_motion
  "drift_arc_degrees": 12.5,
  "scan_cooldown_until": "2026-05-08T17:25:00Z" // 4-hour scan cooldown
}

Validation: WJ undocked, not in nebula, no scan-cooldown active, range_band ∈ {near, mid, far, extended}; extended requires Sensor L3; far and extended require 1 Quantum Shard in cargo (consumed on success). 5 turns deducted on success.

Errors: ERR_QJ_DOCKED · ERR_QJ_FROM_NEBULA · ERR_QJ_SCAN_COOLDOWN · ERR_QJ_SHARD_REQUIRED · ERR_QJ_SENSOR_L3_REQUIRED

POST `/api/v1/quantum/refine-charge` — pre-Phase 2¶

// request
{ "shard_count": 1 }

// response 200
{
  "charges_loaded": 1,
  "shards_consumed": 1
}

Refines 1 Quantum Shard into 1 Quantum Charge and loads it into the WJ's special-equipment slot. The WJ must be docked at a port that supports refining.

Validation: WJ docked at a refining-capable port; ≥1 Quantum Shard in cargo (consumed on success).

Errors: ERR_QJ_NOT_AT_REFINING_PORT · ERR_QJ_SHARD_REQUIRED

POST `/api/v1/quantum/jump` — Phase 2¶

// request
{
  "scan_id": "uuid",        // optional; if provided, server verifies bearing/range match
  "towed_ship_id": "uuid"   // optional; attach a tow companion for this jump
}

// response 202
{
  "jump_id": "uuid",
  "committed_at": "2026-05-08T13:30:00Z",
  "resolve_estimated_at": "2026-05-08T13:30:30Z",
  "consumed": {
    "quantum_charge": 1,
    "turns": 50,
    "tow_surcharge_turns": 5,             // 0 if no tow attached
    "total_turns": 55
  },
  "cooldown_until": "2026-05-09T13:30:00Z",
  "ship_lock_active": true
}

// terminal status arrives via websocket: jump_resolved
{
  "jump_id": "uuid",
  "outcome": "arrived",                    // arrived | misfired
  "destination_sector_id": 4173,
  "destination_region_id": "uuid",
  "hull_damage_pct": 0.0,                  // 5.0 on misfire
  "tow_arrived": true,                     // false if WJ was destroyed during resolve
  "ship_lock_active": false
}

Validation: 1 Quantum Charge in special-equipment slot; no QJ cooldown active per-player or per-ship; WJ undocked; not in nebula; if towed_ship_id is supplied, the hauler is a Warp Jumper with Tractor Beam installed, the towed ship is in the same sector, consents (separate UI handshake on the towed pilot's client), and is ≤ medium size. Per ADR-0040, ERR_QJ_FROM_HANGAR rejects commits from inside a Carrier hangar (and Phase 1 scan symmetric).

Per-player cooldown (per ADR-0049): a player may commit at most one Quantum Jump per 24h regardless of which Warp Jumper they pilot. A team of 4 players with 4 Warp Jumpers can still perform 4 jumps in 24h — but each player can jump only once. Closes the team-rotation stacking exploit. The per-ship cooldown remains as a secondary lock (a ship that just QJ'd is locked through Phase 3 resolve regardless of pilot); the per-player check is the primary anti-stacking gate. Rejection: ERR_QJ_PLAYER_COOLDOWN_ACTIVE with the player's last-jump timestamp + cooldown expiry in the payload.

Errors: ERR_QJ_NO_CHARGE · ERR_QJ_COOLDOWN_ACTIVE · ERR_QJ_DOCKED · ERR_QJ_FROM_NEBULA · ERR_QJ_FROM_HANGAR · ERR_QJ_HAULER_NOT_WJ · ERR_QJ_TRACTOR_NOT_INSTALLED · ERR_QJ_TOWED_SIZE_EXCEEDS_MEDIUM · ERR_QJ_TOWED_NOT_IN_SECTOR · ERR_QJ_TOW_CONSENT_PENDING · ERR_QJ_TOW_LOST (towed ship left sector before commit).

GET `/api/v1/quantum/status`¶

// response 200
{
  "ship_id": "wj-uuid",
  "jump_cooldown_until": "2026-05-09T13:30:00Z",   // null if ready
  "scan_cooldown_until": "2026-05-08T17:25:00Z",   // null if ready
  "ship_lock_active": false,
  "active_jump_id": null,
  "tow_state": null,
  "charges_loaded": 1
}

The websocket channel wj:{ship_id}:quantum_jump carries scan_completed, commit_started, and jump_resolved events.

Sector contents¶

A sector can contain (any combination): - Stations (5–15% of sectors carry one). - Planets (10–25%). - Player ships (transient). - Deployed drones (sector-defense). - Genesis devices in formation. - Mines.

Player count and last_combat timestamp are tracked on the Sector row.

Sector defense system¶

SectorDefense lets a player defend a sector — a presence mechanic, not territorial ownership — by deploying drones, mines, or NPC defenders. Sector defense is presence-only; territorial control at the region level lives in ../gameplay/regional-governance.md.

Drone deployment¶

Player ship's drones can be transferred to a sector.
Restrictions:
Cannot deploy in the Capital Sector or its adjacent fedspace anchor sectors (the first fedspaceSize sectors of each region — default 10 — that hold the welcome hub and starter stations).
Can only deploy in the player's current sector.
Only one player can hold deployed drones in a sector at a time (others must defeat them first).
Visibility: any player entering the sector sees the drone count and owner.
Deployed drones get +5% effectiveness over ship-mounted drones.

Drone retrieval¶

Player must be in the sector.
Ship must have spare drone capacity.
Instantaneous, 0 turns.
Partial retrieval allowed.

Combat against deployed drones¶

When an enemy attacks deployed drones: 1. Sector owner is notified. 2. Combat resolves via combat_service.attack_sector_drones (2-turn cost, defender pays 0). 3. Drone exchanges roll probabilistically (50% base hit) until one side hits zero. 4. Owner notified of result.

Other sector-defense options¶

Mines — 2,000 cr each (design); damage hostile entrants.
Owned port defenses — port classes 1–5 carry built-in drones (Class 1: 50; Class 2: 100; Class 3: 200; Class 4: 300 + auto-turrets; Class 5: 500 + advanced grid — see ../gameplay/combat.md#port-assault).
Owned planet defenses — see planets/defense.md for layered defenses.
NPC defenders — design only, not implemented.
Automated drone recall — design only.

Galaxy map UI — discovered sectors shown with warp connections.
A* pathfinding (design) — optimal route calculation between sectors.
Route optimization service (services/route_optimizer.py) — fuel-vs-time-vs-danger tradeoffs.
ARIA — personalized recommendations based on visited sectors and player trade history.

Player-facing affordances¶

Click destination sector on the galaxy map → preview turn cost → confirm to spend turns.
Sector view shows other ships present (with name colors driven by personal reputation).
Drone deploy/retrieve UI when standing in your sector.
Notifications when someone enters a sector you've defended.
Discovery state per-player — you only see what you've visited (or what's pre-discovered for Terran/Nexus).

Source map¶

Topic	Path
Movement	`services/gameserver/src/services/movement_service.py`
Sector model	`services/gameserver/src/models/sector.py`
Warp tunnel model	`services/gameserver/src/models/warp_tunnel.py`
Sector REST routes	`services/gameserver/src/api/routes/sectors.py`
Combat against sector drones	`services/gameserver/src/services/combat_service.py:attack_sector_drones`
Drone deployment	`services/gameserver/src/services/drone_service.py`
Route optimization	`services/gameserver/src/services/route_optimizer.py`
Encounter generation	`services/gameserver/src/services/movement_service.py:_check_for_encounters`