diff --git a/ui/docs/cargo-routes-ux.md b/ui/docs/cargo-routes-ux.md
index 6d27897..c8ddfb4 100644
--- a/ui/docs/cargo-routes-ux.md
+++ b/ui/docs/cargo-routes-ux.md
@@ -1,9 +1,10 @@
 # Cargo routes UX
 
-This document covers the cargo-route surface: the four-slot
-inspector subsection, the map-driven destination pick, and the
-optimistic overlay that keeps the inspector and the map in lock-step
-with the local order draft. The engine semantics are quoted from
+This document covers the cargo-route surface: the inspector
+subsection (a single-row dropdown + contextual actions after
+F8-05), the map-driven destination pick, and the optimistic
+overlay that keeps the inspector and the map in lock-step with
+the local order draft. The engine semantics are quoted from
 [`game/rules.txt`](../../game/rules.txt) section "Грузовые маршруты"
 (lines 808–843); this file is the source of truth for how the UI
 surfaces those rules.
@@ -25,29 +26,35 @@ than `40 × driveTech` world units along the torus-shortest path
 destination becomes unreachable at the next turn is auto-removed
 (`RemoveUnreachableRoutes`).
 
-## Four-slot inspector subsection
+## Single-row inspector subsection
 
 The cargo-routes subsection renders below the production controls
-on every owned planet inspector. Slots appear in
-`CARGO_LOAD_TYPE_VALUES` order (COL, CAP, MAT, EMP) so visual order
-matches the engine's load priority — players who scan top-down see
-the highest-priority cargo first.
+on every owned planet inspector. F8-05 collapsed the previous
+four-slot grid into a single `<select>` that lists the load-types
+in `CARGO_LOAD_TYPE_VALUES` order (COL, CAP, MAT, EMP) — same
+order as the engine's load priority — preceded by a placeholder
+option that absorbs the old "cargo routes" section title. Nothing
+else is rendered until the player picks a type; after a pick the
+dropdown stays on the chosen type and the row reveals one of two
+states:
 
-Slot states:
-
-- **Empty** — `(no route)` text plus a single `Add` button.
+- **Empty** — a single `Add` button.
 - **Filled** — `→ {destination name}` plus `Edit` and `Remove`.
 
 `Add` and `Edit` open a renderer-driven destination pick (see next
-section). `Remove` emits a `removeCargoRoute` command. The collapse
-rule on the order draft store ensures only one entry per
+section). `Remove` emits a `removeCargoRoute` command. The
+collapse rule on the order draft store ensures only one entry per
 `(source, loadType)` slot survives in the draft at any time, so a
-sequence of `Add → Edit → Remove` collapses to the latest verb only
-(matching the production-controls pattern).
+sequence of `Add → Edit → Remove` collapses to the latest verb
+only (matching the production-controls pattern). After a
+successful pick or remove the dropdown deliberately stays on the
+just-acted type so the player sees the result of the gesture in
+place.
 
-Disabled state: every button is disabled when the
-`OrderDraftStore` or `MapPickService` context is missing (the
-component is mounted outside the in-game shell, in tests, etc.).
+Disabled state: the dropdown and every action button are disabled
+when the `OrderDraftStore` or `MapPickService` context is missing
+(the component is mounted outside the in-game shell, in tests,
+etc.).
 
 ## Map-driven destination pick
 
diff --git a/ui/docs/order-composer.md b/ui/docs/order-composer.md
index 236ad44..2f5a451 100644
--- a/ui/docs/order-composer.md
+++ b/ui/docs/order-composer.md
@@ -62,7 +62,11 @@ transition. The validator (`lib/util/entity-name.ts`) is a TS port
 of `pkg/util/string.go.ValidateTypeName`, exercised on every render
 in the inline editor and re-run by the store on every `add`. The
 submit pipeline filters the draft to `valid` entries only — any
-`invalid` row blocks the Submit button.
+`invalid` row blocks the Submit button. The entry point in the
+inspector is the planet name itself: clicking it opens an inline
+`<input>` with a single ✓ confirm icon on the right; Escape (or
+leaving the inspector) cancels the edit without touching the
+draft.
 
 ## Command status state machine
 
@@ -178,6 +182,17 @@ optimistic overlay rewrites `planet.production` using
 mirrors the engine's `Cache.PlanetProductionDisplayName` so the
 overlay stays byte-equal with the next server report.
 
+The inspector surface that composes a `setProductionType`
+(`lib/inspectors/planet/production.svelte`) is two dropdowns on
+one row — a primary `industry / materials / research / ship`
+plus a secondary one (tech / science / ship class) that appears
+for the `research` and `ship` contexts — together with a green ✓
+apply and yellow ✗ cancel icon. The ✓ button stays disabled
+until the row selection differs from the planet's current
+effective production; ✗ resets the local row state back to that
+effective value without touching the draft. The Order tab is
+the only place that can revoke an already-applied command.
+
 ### Collapse-by-target rule
 
 `setProductionType` carries a collapse-by-target rule.
diff --git a/ui/docs/science-designer-ux.md b/ui/docs/science-designer-ux.md
index afd83c9..701c100 100644
--- a/ui/docs/science-designer-ux.md
+++ b/ui/docs/science-designer-ux.md
@@ -74,22 +74,26 @@ which surfaces as `rejected` in the order tab.
 
 ## Production-picker integration
 
-The planet inspector's Research sub-row
-(`lib/inspectors/planet/production.svelte`) renders the four tech
-buttons and one extra button per defined science from the player's
-`localScience` overlay. A click on a science button dispatches
+The planet inspector's production row
+(`lib/inspectors/planet/production.svelte`) is two `<select>`s
+plus a green ✓ apply / yellow ✗ cancel pair after F8-05. With
+the primary picker on `research`, the secondary picker lists the
+four tech display strings and one extra option per defined
+science from the player's `localScience` overlay. Picking a
+science target and pressing ✓ dispatches
 `setProductionType("SCIENCE", "<scienceName>")`, mirroring the
 wire-level `CommandPlanetProduce` shape
 (`pkg/schema/fbs/order.fbs.CommandPlanetProduce`).
 
-The active highlight is derived from `planet.production` — the
-display string the engine emits in the report. A science name
-shadows the matching tech display string when they collide (a
-science deliberately named `Drive` wins over the Drive tech
-button), because the wire string is ambiguous and the user clearly
-intended the named science. This is a pragmatic accept; a
-structured production tag on the wire would let us disambiguate
-without the shadow rule, but that is a separate backend concern.
+The active value of both selects is derived from
+`planet.production` — the display string the engine emits in the
+report. A science name shadows the matching tech display string
+when they collide (a science deliberately named `Drive` wins over
+the Drive tech option), because the wire string is ambiguous and
+the user clearly intended the named science. This is a pragmatic
+accept; a structured production tag on the wire would let us
+disambiguate without the shadow rule, but that is a separate
+backend concern.
 
 ## Tests
 
@@ -102,5 +106,5 @@ without the shadow rule, but that is a separate backend concern.
   fractions, view-mode Delete dispatches `removeScience`,
   duplicate-name guard against the overlay.
 - `tests/e2e/sciences.spec.ts` — full Playwright walkthrough:
-  create → list → set planet production via the Research sub-row
-  → delete.
+  create → list → set planet production via the research/target
+  dropdown pair + ✓ apply → delete.