Max range display is the guaranteed (worst-case headwind) full-tank range (ISS-099, v0.51.0)

Extract the queue-line color from an inline literal to exported
QUEUE_ROUTE_LINE_COLOR and retune it #64748b -> #d4a017. Dashed style
and width unchanged. Unit test pins the constant; existing e2e specs
(queue.spec.ts, relocation.spec.ts) already cover the rendering path.

CHANGELOG.md

@@ -4,6 +4,10 @@
 - **Max range display is now guaranteed flyable in all weather (ISS-099).** The spec card's "Max range" (`components/RightPane.tsx`) showed `maxRangeKm` — the weighted-model closed form with NO wind — while dispatch's fuel guard (`flyPlane`, and the engine's auto-chain) uses wind-adjusted burn (up to +20% headwind, v0.36.0), so a leg inside the displayed range could 409 "insufficient fuel" when the departure airport had a headwind. New `MAX_WIND_BURN_FACTOR` (= 1.2 — pinned in tests to be exactly `windBurnFactor`'s maximum) and `guaranteedRangeKm(burnPerKm, emptyWeightKg, maxFuel)` = `maxRangeKm` under worst-case headwind burn (`lib/sim/movement.ts`). The UI now shows the guaranteed range: any leg within it is flyable in all weather. ATR 72-600: 4436 → 3696 km; Boeing 777: 13045 → 10871 km — matching the `maxRangeKm ÷ 1.2` convention seed.ts already uses for its job-generation cap
 - **Tests.** Unit +15: new `guaranteedRangeKm` block in `lib/sim/movement.test.ts` (3 tests — MAX_WIND_BURN_FACTOR pinned to `windBurnFactor(30, 90, 90)`, ATR ≈ 3697 km ±5%, zero-fuel/invalid-weight guards) and a per-type consistency loop in `lib/game/catalog.test.ts` (12 tests — for ALL six catalog types: `requiredFuelFor(guaranteed range)` ≤ maxFuel under worst-case headwind, tightness at 1.05× > maxFuel, and the no-wind closed form still an exact inverse). E2E: `e2e/right-pane.spec.ts` market-tab test now imports and asserts `guaranteedRangeKm` directly (local mirror deleted)
 
+## v0.50.0 — 2026-09-22 08:00
+- **Queued/planned route line is now amber/gold instead of gray (ISS-098).** The dotted queue line in `components/Map.tsx` (a flying plane's not-yet-started legs, ISS-043) was drawn in muted slate `#64748b`. It is now an amber/gold `#d4a017`, readable on both light and dark tiles. The color was extracted from the inline literal to a new exported module-scope constant `QUEUE_ROUTE_LINE_COLOR` so it is testable; the dashed/dotted style (`line-dasharray [0.1, 1.5]`) and width (3) are unchanged
+- **Tests.** Unit +1: new `components/map.test.ts` pins `QUEUE_ROUTE_LINE_COLOR === '#d4a017'`. No new e2e spec — the existing queued-route rendering paths (`e2e/queue.spec.ts`, `e2e/relocation.spec.ts`) already exercise this layer, and a pure color swap needs no behavioral coverage
+
 ## v0.49.0 — 2026-09-22 07:25
 - **Airport popup Relocate now works for flying/repairing planes (ISS-096).** The Relocate row in the map's airport popup (`components/Map.tsx`) previously listed only grounded planes and showed "No grounded planes to relocate." when none was available. It now lists ALL planes from the latest snapshot, and the click handler picks the endpoint by the SELECTED plane's current status: `available` → `POST /api/planes/{id}/fly` (immediate relocation, unchanged), `flying`/`repairing` → `POST /api/planes/{id}/queue` (the destination is appended to the plane's flight queue and chains on landing). Success text is "Relocation started." for fly and "Added to queue." for queue; the no-planes fallback guard is reworded to "No planes to relocate." No API changes — both endpoints existed since v0.25.0/v0.46.0
 - **Tests.** E2E +1 (`e2e/relocation.spec.ts`): dispatches the starter plane on a leg via the API so it is flying, slows the sim to 1x so the leg cannot land mid-test, opens the airport popup for a different airport, selects the flying plane from the (now full) list and clicks "Relocate here", then asserts via state that the plane's `queue` contains the clicked airport's ICAO while it is still flying its original destination

components/Map.tsx

@@ -32,6 +32,8 @@ const ROUTES_LEGS_LAYER_ID = 'routes-legs';
 // (dest → queue[0] → …) as their own source + layer, drawn under everything else dynamic.
 const QUEUE_ROUTES_SOURCE_ID = 'queue-routes';
 const QUEUE_ROUTES_LAYER_ID = 'queue-routes';
+// ISS-098 (v0.50.0): amber/gold — planned legs read as "queued", visible on light and dark tiles alike.
+export const QUEUE_ROUTE_LINE_COLOR = '#d4a017';
 // ISS-002 (v0.15.0): top-most hover-highlight layers, added after the base layers so they
 // render above them. Each starts filtered to match nothing; applyHoverRef drives the filters.
 const PLANES_HIGHLIGHT_LAYER_ID = 'planes-highlight';
@@ -382,8 +384,8 @@ export default function FlightMap({ state, hovered, applySnapshot }: MapProps) {
           });
         }
         // ISS-043 (v0.26.0): dotted queue line — added after routes-legs but BEFORE the hover
-        // layers so a hovered trace still draws on top of it. Muted slate + fine dots reads as
-        // "planned/future", distinct from the solid amber active leg and the [2,2] yellow hover dash.
+        // layers so a hovered trace still draws on top of it. Amber/gold + fine dots reads as
+        // "planned/future", distinct from the solid bright-amber active leg and the [2,2] yellow hover dash.
         if (!map.getSource(QUEUE_ROUTES_SOURCE_ID)) {
           map.addSource(QUEUE_ROUTES_SOURCE_ID, {
             type: 'geojson',
@@ -396,7 +398,7 @@ export default function FlightMap({ state, hovered, applySnapshot }: MapProps) {
             type: 'line',
             source: QUEUE_ROUTES_SOURCE_ID,
             paint: {
-              'line-color': '#64748b', // muted slate — planned legs, not actively flying
+              'line-color': QUEUE_ROUTE_LINE_COLOR, // amber/gold — planned legs, not actively flying (ISS-098)
               'line-width': 3,
               'line-dasharray': [0.1, 1.5], // dotted — distinct from solid legs and the [2,2] hover dash
             },

components/map.test.ts

@@ -0,0 +1,11 @@
+import { describe, expect, it } from 'vitest';
+import { QUEUE_ROUTE_LINE_COLOR } from './Map';
+
+// ISS-098 (v0.50.0): the dotted queued/planned route line is amber/gold, not gray — pinned so a
+// future retune is deliberate. E2E already exercises the rendering path (queue.spec.ts, relocation.spec.ts).
+
+describe('queued route line color', () => {
+  it('pins the amber/gold queue-line color readable on light and dark tiles', () => {
+    expect(QUEUE_ROUTE_LINE_COLOR).toBe('#d4a017');
+  });
+});