Merge current upstream and resolve PR 581 conflicts

b4067f9 moved the OpenSky states/all fetch into fetchOpenSkyStates, with a
10-second limit per attempt and one retry. Keep that and drop this branch's
20-second exchange deadline; the 8 MiB body cap now reads inside the helper
under each attempt's signal. The CHANGELOG bullet moves under [Unreleased],
and CURRENT-STATE describes the per-attempt OpenSky deadline.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs/CURRENT-STATE.md

@@ -1,10 +1,51 @@
 # God's Eye View Current State
 
-## Cyber HUD — September 23, 2026
+## God's Eye View in conversations — October 2, 2026
+
+Tool answers that can be shown in God's Eye View include a view: camera, layers,
+style, map, marks and an aircraft or satellite to follow, written in the
+share-link format (`gods-eye-view/view`). `show_in_gods_eye_view` shows a view as live
+God's Eye View inside clients that display MCP Apps, and as a link everywhere.
+The panel runs the app's panel build (`npm run build:panel`, served at
+`/panel/`) and loads it, with its data, through the MCP server, so it works
+in Claude Desktop and in the Codex and ChatGPT desktop apps with a local
+server and no HTTPS. `?embed=1` shows the app as the globe alone and takes
+new views from the page that frames it; framing is off unless
+`GEV_EMBED_FRAME_ANCESTORS` allows the framing page. MCP leads with the tools that find
+what to show. See [tools and the MCP server](TOOLS.md).
+
+## Tools and local MCP server — October 1, 2026
+
+`gods-eye-view/tools` defines queries that answer questions from the app's data,
+and `gods-eye-view/tools/mcp` exposes a composed catalog over the Model Context
+Protocol. `npm run mcp` serves Core's tools over stdio to a local MCP client,
+reading from a running app's `/api` routes (default `http://localhost:4173`).
+The development and preview servers also serve the tools over HTTP at `/mcp`,
+accepting only direct local requests: a loopback host on the port reached,
+an `Origin` (when sent) from that same host, no proxy forwarding headers, and
+launcher sharing off.
+Queries cover earthquakes, active fires, recent launches, aircraft (in an
+area, by identifier, tracks, and type and route lookups), ships (in an area,
+by identifier, and tracks), satellites (next
+pass over a point, and those overhead now), public cameras (including a
+camera's current image), license plate reader cameras, radio stations, place search, routing, bike-share
+stations, transit vehicles, road traffic flow, weather, weather map images
+(radar, satellite, lightning), wind, the most recent satellite image of an
+area, submarine cables, datacenters and dams, the Bhote Koshi flood event pack, regional briefs, tropical cyclones, fire
+perimeters, terrain height, military installations and map features, plus a
+combined situation brief, military awareness around a point, the app's heads-up display caption, and a link that
+opens the app over an area. Tools reuse the layers' portable source factories, take a
+shared `area` argument (place name, bounding box, or point and radius) and cap
+lists at 25 rows by default. Voice offers the same queries next to its app
+actions: the session lists them, and the browser runs them through the same
+catalog, loaded on first use. See [tools and the MCP server](TOOLS.md).
+
+## Cyber HUD — September 30, 2026
 
 Display > HUD > Layout includes Cyber, also available through the HUD voice
 action and shared visual state. An explicit first transition into Cyber selects
-FLIR with Ironbow 0.42; restored links and subsequent visual tuning remain
+FLIR with Ironbow 0.42. An explicit switch back to another HUD layout restores
+the visual preset used before Cyber; restored links and scenes remain
 authoritative. The skin uses shared red/slate panel treatments in map and cockpit,
 with compact 200px collapsed controls and wider expanded panels. Other HUD
 layouts retain their existing presentation.
@@ -17,6 +58,21 @@ headers and decorative frames. The narrow-screen rail remains scrollable to reac
 each panel. Radio retains the shared nested Context player and compact
 header disclosure, without relocating playback controls on theme changes.
 
+Voice help/error popups and Location/Visual Presets pins extend beyond their
+Cyber frames without being clipped: the shapes decorate non-interactive
+pseudo-elements. The lower-left telemetry card leaves room for attribution's
+full logo row. New panels can use the [shared surface contract](panel-surfaces.md)
+for theme tokens, rail input and a fixed header with a bounded scroll body.
+The contract is intentionally future-facing and opt-in; its first production
+adopter will land after this change. Existing owners still control disclosure,
+persistence and placement, while small-screen rail popup clipping and other
+integration limits remain documented in the contract.
+
+On desktop, Cyber raises the left rail so it clears the lower coordinate card.
+`layoutRightPanelRail` reads that rendered top as its measured `baseTop`, which
+keeps the right rail aligned. Cockpit retains its separate rail placement for
+its visor layout.
+
 Sonar has one contact-highlighting method. Native Cesium points, billboards and
 labels are treated in GPU draw commands without replacing their positions,
 identities or pick commands. Model and canvas/DOM overlays retain their own
@@ -875,10 +931,21 @@ errors.
 ## Places and CCTV request bounds
 
 With a Google key configured, nearby and text search reject missing, blank,
-non-numeric and out-of-range coordinates before the opt-in limiter and upstream
+non-numeric and out-of-range coordinates before the per-IP limiter and upstream
 request. Text search also requires a nonblank query. Keyless requests retain
 their `configured: false` response.
 
+The cost-bearing proxies are throttled per client IP without configuration:
+`/api/realtime/token` and `/api/openai/hud-summary` share 30 requests per
+minute per IP, `/api/google/nearby-places` and `/api/google/text-search` share
+120 — the caps the Pinokio build already sets, so the packaged app is
+unaffected. `GEV_RATELIMIT_OPENAI_PER_MIN` and `GEV_RATELIMIT_GOOGLE_PER_MIN` override
+those; exactly `0` disables the limiter, while a value that cannot be read as a
+number falls back to the default rather than to unlimited. Over-limit requests
+receive a sanitized `429` with `Retry-After: 5` and never reach the provider.
+The client key is the socket peer address only — a forwarded-for header is not
+trusted, so a proxied deployment shares one bucket per upstream hop.
+
 CCTV media waits at most 15 seconds for upstream response headers and returns
 504 on timeout. Its timer stops when headers arrive, so live bodies can continue
 streaming; a separate 30-second idle deadline then bounds the gap between
@@ -907,12 +974,11 @@ tiles use it alongside GTFS-Realtime. Caps are bounds, not budgets, sized well
 above measured payloads: FIRMS 64 MiB per satellite source, CelesTrak 16 MiB
 per group, OpenSky `states/all` 8 MiB, adsb.lol `/v2/mil` 8 MiB, TomTom tiles
 8 MiB and adsbdb lookups 1 MiB. Where a route already had a deadline (FIRMS
-60 s, CelesTrak 20 s, TomTom 15 s, adsbdb 8 s) that deadline now covers the
-body read as well as the headers. Two polls that had no deadline gain one: the
-adsb.lol military poll waits at most 12 seconds, and the OpenSky `states/all`
-exchange, including its Basic-auth retry, at most 20. A rejected or timed-out
-body is an upstream miss and follows each route's existing error and
-cached-data paths. FIRMS map-key status, the OpenSky token exchange and CCTV
+60 s, CelesTrak 20 s, TomTom 15 s, adsbdb 8 s, and each 10 s OpenSky
+`states/all` attempt) that deadline now covers the body read as well as the
+headers. The adsb.lol military poll, which had no deadline, now waits at most
+12 seconds. A rejected or timed-out body is an upstream miss and follows each
+route's existing error and cached-data paths. FIRMS map-key status, the OpenSky token exchange and CCTV
 media keep their current handling.
 
 ## Remaining local service modules
@@ -1963,11 +2029,12 @@ down | auth-failed` (plus the unchanged `missing-key`/`unsupported`) with
 >   registered for lifecycle and restoration but is not duplicated in Data Layers.
 >   Inside Cockpit, the focused summary card is titled Contact in both visible
 >   copy and its accessible control labels.
->   The top-center Cockpit vision cycle shows the inherited map preset name
->   (for example, `NOIR`) followed by CRT, NVG, FLIR, and NOIR. That inherited entry
->   leaves the selected map preset unchanged inside Cockpit. NONE is not offered
->   in the cycle; CRT, NVG, FLIR, and NOIR temporarily override that preset, while returning to it or exiting
->   Cockpit restores the captured map style and its exact shader intensities.
+>   The top-center Cockpit vision cycle is the fixed, duplicate-free sequence
+>   Normal, CRT, NVG, FLIR, Anime, Noir, and Snow. Entry selects the map preset
+>   already in use, so a FLIR map opens on the existing FLIR item while
+>   Normal remains available exactly once. NONE is not offered. Cockpit choices
+>   temporarily override the map preset, while Exit Cockpit and Reset both restore
+>   the captured map style and its exact shader intensities.
 >   Selecting a Cockpit vision treatment with configurable parameters opens
 >   Cockpit Display and reveals those parameters through the existing right-side
 >   accordion; an inherited parameterless Normal preset does not force it open.
@@ -3807,8 +3874,9 @@ and unreachable upstream (502/504) separately from road geometry.
   first, activates the Contacts sub-view, and returns the settled 250 km window.
   Its `aircraft` count is the exact civilian-plus-military total when both feeds
   can answer, or `unknown` when either component is unavailable.
-- Cockpit's top vision switch cycles five rendered looks: the inherited map
-  style, CRT, NVG, FLIR, and Noir. There is no empty `NONE` entry.
+- Cockpit's top vision switch cycles all seven map looks: Normal, CRT, NVG,
+  FLIR, Anime, Noir, and Snow. Entry selects the matching map style without adding
+  a duplicate carousel item. There is no empty `NONE` entry.
 
 ### Live AIS Vessels (June 2026)
 
@@ -4179,7 +4247,7 @@ are omitted rather than framing the wrong part of the globe.
 - **Cockpit left-panel clearance:** the Cockpit Contact card and peripheral HUD participate in the adaptive left accordion's live obstacle measurements, including live viewport-height changes. Expanding Layers or Scenes keeps the active panel in the available upper-left corridor with internal scrolling; it does not cover the Contact card, lower Cockpit controls, or Cesium credit line. Outside Cockpit the hidden card does not alter the normal corridor.
 - **Cockpit Context scope:** the 250 km radius applies to the air/sea proximity cohorts. Installation counts come only from the currently loaded viewport and are labeled `CURRENT VIEWPORT ONLY` in the cockpit as well as the normal Context panel; neither surface presents them as a complete 250 km installation survey.
 - **Cockpit camera anchor:** first-person mode does not write feed-boundary corrections directly into the camera. A cockpit-only inertial anchor advances from the selected aircraft's displayed course and speed, then converges toward the authoritative delayed track with correction capped below forward motion. The displayed kinematics are derived from the same consecutive fix segment as the rendered position, with raw feed speed/course used only as fallback; a transient zero/missing feed speed therefore cannot freeze a visibly moving aircraft after layer enable or a map/cockpit handoff. Rendered altitude continues to come from that interpolated track position. Late ADS-B fixes and short render stalls can remove drift without accelerating or reversing the view. Camera placement runs before scene update/culling at a bounded 20 Hz so a moving cockpit does not force Photoreal 3D Tiles to retraverse on every display frame; textual instruments update at 10 Hz and context/layout work at 4 Hz. Every far Cockpit contact pip shares one stable Cesium texture-atlas entry and skips unused screen-projected course calculations, while only in-range 2D aircraft silhouettes pay the screen-projected rotation cost; ambient glTF collections are hidden/retained rather than synchronously destroyed at cockpit entry, and context rails lay out only on explicit content/state changes and viewport resize. The deliberate 15/30-second layer interpolation delays and per-Cesium-frame position caches remain unchanged.
-- **Cockpit route, vision, and view controls:** visible on-screen `COCKPIT`, `RESET`, and `EXIT COCKPIT` controls replace reliance on the `C` shortcut. RESET uses the same canonical globe route as the map and voice actions, exits Cockpit, and releases its camera ownership rather than exposing the hidden map-style top action. When the tracked commercial flight has a plausible ADSBDB route, the top of the right briefing rail shows a compact `FROM → TO` airport strip and the visor shows a centered estimated-destination chevron with its relative bearing; absent or implausible route data hides the strip and cue rather than guessing. The cockpit-local vision control is an interactive `PREV / CURRENT / NEXT` carousel over the inherited map preset, `CRT`, `NVG`, `FLIR`, and `NOIR`; its previous/next actions wrap, and activating the current value advances to the next style. The inherited entry is named directly, such as `NOIR`, and retains that map shader. There is no empty `NONE` entry. CRT, NVG, FLIR, and NOIR temporarily activate the existing Cesium post-process stages, while returning to the inherited entry or exiting Cockpit restores the pre-entry visual style. The regional-news page uses a free Google News RSS locality query first, with the existing GDELT query retained only as a fail-soft fallback; linked headlines remain reporting, not verified incidents or risk intelligence.
+- **Cockpit route, vision, and view controls:** visible on-screen `COCKPIT`, `RESET`, and `EXIT COCKPIT` controls replace reliance on the `C` shortcut. RESET uses the same canonical globe route as the map and voice actions, exits Cockpit, and releases its camera ownership rather than exposing the hidden map-style top action. When the tracked commercial flight has a plausible ADSBDB route, the top of the right briefing rail shows a compact `FROM → TO` airport strip and the visor shows a centered estimated-destination chevron with its relative bearing; absent or implausible route data hides the strip and cue rather than guessing. The cockpit-local vision control is an interactive `PREV / CURRENT / NEXT` carousel over `NORMAL`, `CRT`, `NVG`, `FLIR`, `ANIME`, `NOIR`, and `SNOW`; its previous/next actions wrap, and activating the current value advances to the next style. Cockpit enters on the active map preset, so a Cyber FLIR map opens Cockpit on FLIR while Normal remains a distinct option instead of producing a second FLIR entry. Cockpit choices temporarily activate the existing Cesium post-process stages, while exiting Cockpit through either EXIT or RESET restores the pre-entry map style. The regional-news page uses a free Google News RSS locality query first, with the existing GDELT query retained only as a fail-soft fallback; linked headlines remain reporting, not verified incidents or risk intelligence.
 - **Cockpit weather status:** the earlier multi-canvas atmospheric compositor remains fail-closed and is not attached to the live viewer. Cockpit clouds are a separate transparent WebGL pass with a capped 520×320 framebuffer, 24 ray steps, three FBM octaves, and a 12 FPS ceiling. It defaults off and starts only when local storage explicitly contains the persisted `WX ON` opt-in (`'1'`). When opted in, observations refresh after five minutes or 25 km of aircraft movement, fail transparent when unavailable or clear, and stop on exit or disable. `WX OFF` governs atmospheric rendering only: the briefing still fetches source-backed Natural Earth region, headline, and Open-Meteo local-information data, aborting and replacing any in-flight request when the selected aircraft changes. No weather effect runs in map mode and no synthetic fallback is shown.
 - **Cockpit trail visibility:** entering cockpit hides the selected aircraft's trail body and head so they cannot cross the first-person view; exit restores them. This cockpit-only presentation change does not alter the normal map-mode invariant that aircraft trails render through terrain using their depth-fail material.
 - **Aircraft course slew:** civilian and military 3D models retain the 60°/s course limiter, but each rendered frame can consume at most 250 ms of accumulated slew time. A long tile/render stall therefore catches up over multiple visible frames instead of turning one delayed frame into a heading snap.

docs/MCP_SETUP.md

@@ -0,0 +1,71 @@
+# MCP setup
+
+Use God's Eye View from Claude and Codex: tools, links, and the live globe
+inside the conversation. Agents: follow these steps in order and check each
+one before going on.
+
+## 1. Run the app
+
+```sh
+npm install
+npm run build:panel   # the in-conversation globe; rerun after app changes
+npm run dev           # http://localhost:5173, keep it running
+```
+
+The MCP server reads from this app.
+
+## 2. Add the server to a client
+
+The server is `server/mcp/stdio.js` in this checkout. Use absolute paths
+(clients do not load your shell profile), with each argument as its own entry.
+
+| Client | How |
+| --- | --- |
+| Claude Code | `claude mcp add gods-eye-view -- node /abs/path/gods-eye-view/server/mcp/stdio.js --api-base http://localhost:5173` |
+| Codex CLI | `codex mcp add gods-eye-view -- node /abs/path/gods-eye-view/server/mcp/stdio.js --api-base http://localhost:5173` |
+| Codex and ChatGPT desktop | Same `~/.codex/config.toml` as the CLI (block below), or Settings → MCP servers → Add server (STDIO). |
+| Claude Desktop | Settings → Developer → Edit Config, then add the JSON below. |
+
+```toml
+[mcp_servers.gods-eye-view]
+command = "node"
+args = ["/abs/path/gods-eye-view/server/mcp/stdio.js", "--api-base", "http://localhost:5173"]
+```
+
+```json
+{
+  "mcpServers": {
+    "gods-eye-view": {
+      "command": "node",
+      "args": ["/abs/path/gods-eye-view/server/mcp/stdio.js", "--api-base", "http://localhost:5173"]
+    }
+  }
+}
+```
+
+**Windows with the checkout in WSL:** use `"command": "wsl.exe"` and put
+`"-e"` and the absolute Linux path to `node` first in `args`, for example
+`["-e", "/home/you/.local/share/mise/installs/node/24/bin/node", "/home/you/gods-eye-view/server/mcp/stdio.js", "--api-base", "http://localhost:5173"]`.
+
+## 3. Restart and try it
+
+Fully quit the client (on Windows, from the tray icon) and reopen it, then
+start a new chat; clients keep the server they started with. Ask: *"Show San
+Diego in God's Eye View with military flights on."*
+
+- Claude Desktop (a chat, not the Code tab), Codex and ChatGPT desktop show
+  the live globe; the first load takes 10–20 seconds.
+- Claude Code and the Codex CLI answer with data and a link.
+
+## Troubleshooting
+
+- **The server does not appear:** run the command from step 2 in a terminal;
+  it should print `God's Eye View MCP server reading http://localhost:5173`
+  and wait. A path or `args` mistake fails here.
+- **The panel says it could not load:** `npm run build:panel` was not run, or
+  the dev server is down.
+- **Logs:** the server writes each call, and why one failed, to stderr. Claude
+  Desktop keeps it in its logs folder as `mcp-server-gods-eye-view.log`; in
+  Codex, right-click the panel → DevTools for the panel's console.
+
+See [tools and the MCP server](TOOLS.md) for what the tools do.

docs/TOOLS.md

@@ -0,0 +1,302 @@
+# Tools and the MCP server
+
+Tools answer questions from God's Eye View data for language-model clients.
+They are defined once and exposed through adapters: the Model Context Protocol
+(MCP) and function calling, which voice uses.
+
+To use them from Claude or Codex, see [MCP setup](MCP_SETUP.md).
+
+## Layers
+
+| Owner                | Responsibility                                                                                    |
+| -------------------- | ------------------------------------------------------------------------------------------------- |
+| `src/tools/`         | Tool definitions, catalog composition, argument validation, shared `area` and result helpers      |
+| `src/tools/queries/` | Queries, one file per domain, reading only portable source contracts                              |
+| `src/tools/mcp/`     | MCP protocol (JSON-RPC) and a stateless HTTP transport; knows the catalog interface, not queries |
+| `src/tools/functions.js` | Function-calling adapter: tool records and results for function-calling clients |
+| `src/tools/services.js` | The default services: the layers' source factories and request services, given a resolving fetch |
+| `server/mcp/`        | Node composition: points the sources at a running app's `/api` routes; serves stdio and `/mcp`  |
+| `server/standalone/voiceTools.js`, `src/standalone/toolCatalog.js` | Standalone voice composition: the session's tool list and the browser catalog |
+
+Dependencies point downward only. `gods-eye-view/tools` and
+`gods-eye-view/tools/mcp` are portable exports: they reach no application,
+rendering, Node, Cesium or browser-global code, which
+`npm run check:boundaries` enforces. In the application, only voice reaches
+them: `withToolCatalog` in `src/voice/gevRealtime.js` imports the
+function-calling adapter, and the standalone entry supplies the catalog.
+
+## Definitions and composition
+
+`defineTool({ name, kind, title, description, inputSchema, requires, run })`
+validates and freezes a tool. `kind` is `query` (answers from data, read-only)
+or `action`. `inputSchema` uses a JSON Schema subset that `src/tools/schema.js`
+checks completely; unsupported keywords are rejected at definition time.
+`run(args, { services, signal })` resolves to `{ summary, data }`: one sentence
+for people and a structured object for programs. A tool may also return `images`,
+each `{ mimeType, data }` with base64 data; the MCP adapter sends them as image
+content. MCP results carry the summary and the data as JSON text, plus the data
+as `structuredContent`, for clients that read only one of them.
+
+`composeCatalog({ tools, services, replace, interceptors })` builds a catalog:
+
+- **Tools**: an application adds its own tools to `coreTools`. Reusing a name
+  fails unless the name is listed in `replace`.
+- **Services**: each tool names the services it reads in `requires`. Tools
+  whose services are not supplied are left out.
+- **Interceptors**: `(call, next) => next(call)` functions wrap every call,
+  outermost first. They can observe, reject or change a call.
+- **Composite tools**: `run` receives `tools`, with `has(name)` and
+  `call(name, args)`, to call other tools through the same catalog, so
+  replaced tools and interceptors apply. Interceptors see such calls with
+  `parent`, the calling tool's name.
+
+### Surfaces
+
+`src/tools/surfaces.js` lists which tools MCP and voice offer. A tool is on
+both unless `TOOL_SURFACES` turns it off; edit an entry to turn a tool on or
+off for one surface. MCP leaves out place search, routing, plain
+weather and wind, the regional brief, the HUD caption, radio, bike share and
+transit, which assistants already cover or which add little without the
+globe. `catalogForSurface(catalog, surface, overrides)` is the
+view a surface exposes: it lists and calls only the tools it offers, while
+composite tools still reach the whole catalog. `toolsForSurface` gives the
+same selection as a list of definitions, such as for the voice session's tool
+list. Voice leaves out tools that answer with images, link to the app, or
+repeat what its app actions answer.
+
+Expected failures throw `ToolError` with one of `invalid_arguments`,
+`unavailable`, `unsupported`, `malformed` or `retry_later`. Other errors are
+reported to clients without details.
+
+## Services
+
+`gods-eye-view/tools/services` builds the default set with
+`createToolServices({ fetchImpl, appUrl })`. Services are the portable source factories the layers already use, such as
+`createUsgsEarthquakeSource`, `createFirmsSource` and `createLaunchSource`,
+plus a `places` service with `resolve(name, { signal })`. Sources request
+relative `/api/...` paths through an injected `fetchImpl`, so the same tool
+code runs wherever an application routes those paths.
+The `weather`, `regional`, `terrain`, `summary` and `features` services are the
+application request services from `gods-eye-view/application/requests`.
+`situation_brief` and `military_awareness` run each section whose services are supplied and mark the
+others unavailable. `app` is `{ baseUrl }`, the address links open. The `bikeshare` service is `{ systems, getStations }`: the system registry and
+the GBFS source. `createGeocodePlaceService` resolves place names through `/api/geocode`;
+`createPlaceSearchService` searches `/api/google/*` and reports when no search key
+is configured; `createRouteService` plans routes through `/api/route`.
+
+## Views
+
+`gods-eye-view/view` (`src/view/index.js`) describes what the app shows,
+independent of how it is shown: a camera (lat, lon, altitude, heading,
+pitch), data layers, visual style, map imagery, and an aircraft, military
+aircraft or satellite to follow. `createView` builds and bounds one,
+`viewToParams` and `viewFromParams` write and read it in the share-link
+format the app restores, and `viewUrl` gives the address that opens it. The
+style names are the ones share links use. Ships cannot be followed from a
+link yet. An aircraft's `follow` may ask for its cockpit view
+(`cockpit: true`); links cannot carry that and open the app following it.
+
+A view can also carry `annotations`, the marks the app's `annotate_map`
+action draws (pins, highlights, areas, arrows, routes and labels at a place
+name or coordinates). Links carry them in the `an` parameter, and the app
+draws them once the link has been restored.
+
+Tools take a view as `VIEW_ARGUMENTS`: an `area` to frame from above, or a
+`camera`, plus `layers`, `style`, `map`, `follow` and `annotations`. A
+tilted camera over an area looks at its center from behind; camera fields
+given with an area override its framing. `resolveViewArguments` turns them
+into a view.
+
+### The God's Eye View panel
+
+`show_in_gods_eye_view` names an MCP Apps view (`io.modelcontextprotocol/ui`):
+`_meta.ui.resourceUri` is `ui://gods-eye-view/globe`, a `text/html;profile=mcp-app`
+resource from `createGlobePanelResource({ runtime })` in
+`src/tools/globePanel.js`, with the panel's script from
+`src/app/globePanelRuntime.js`. Clients that display apps render it inside
+the conversation. The panel completes the MCP Apps handshake
+(`ui/initialize`, `ui/notifications/initialized`,
+`ui/notifications/size-changed`), and for each
+`ui/notifications/tool-result` carrying a view it loads the app in inline
+embed mode the first time and posts later views to that same app, so the
+globe changes without reloading. Its "Open in God's Eye View" button asks
+the host to open the link (`ui/open-link`).
+
+Hosts serve panels from their own sites and may refuse other addresses;
+Codex, for one, refuses any address on the user's machine. So the panel
+never requests the app's server itself. It loads everything from the app's
+own paths through `panel_request`, a tool meant for the panel: it is
+marked `_meta.ui.visibility: ["app"]`, and each call must carry the key the
+MCP server puts in its panel page. Any client can read that page, so the key
+keeps the tool from clients that only list it, and is not access control. The
+MCP server requests the path from the app's server and returns the response,
+compressed and in parts when large.
+The same path works in every host. Only
+map imagery, tiles and fonts load directly, from the providers the
+resource's `csp` lists. `panel_request` refuses Provider Settings
+(`/api/setup`), credential and model endpoints (`/api/realtime`,
+`/api/openai`), `/mcp` and the development server's internal routes, in any
+letter case, encoding or dot suffix.
+
+The panel loads the app's panel build, which `npm run build:panel` writes to
+`dist/panel` and the servers serve at `/panel/`: one app script, one
+stylesheet, and Cesium's script, which carries its workers and starts them
+from memory (`CESIUM_WORKERS`). Files those workers load themselves are
+embedded in a prelude the panel runs ahead of them, since a worker's
+requests reach the panel page's own site. Rebuild it after changing
+the app.
+
+Hosts differ in ways the panel works around, all inside the panel only:
+images and stylesheet files arrive as `data:` URLs, since some hosts refuse
+`blob:` images; code that needs an https address for the app gets
+`GEV_APP_BASE_URL`, since some hosts serve the page from their own scheme;
+the globe keeps drawing from a timer when the host reports the panel hidden
+and stops animation frames; and 2D canvases are kept in memory
+(`willReadFrequently`), since a host that treats the panel as off screen may
+drop their GPU contents and show the overlays as black over the globe.
+
+Tools declare a UI resource with `defineTool({ ui: { resourceUri } })`, and
+an app-only tool with `ui: { visibility: ['app'] }`;
+`createMcpServer({ resources })` serves `resources/list` and
+`resources/read`.
+
+### Embed mode
+
+`?embed=1` shows only the globe: clean view, with the HUD, panels, welcome
+and setup prompts hidden; provider attribution stays. A page that frames it
+changes the view by posting `{ type: 'gev:view', id, view }` to the frame.
+The app applies it through its own actions (style, map, exactly the view's
+layers, annotations, then the followed entity, retried until its layer has
+it, or the camera when nothing is followed or the entity is not there yet,
+since a camera flight would end the follow; then cockpit view when asked) and
+answers `{ type: 'gev:view-applied', id, ok, steps }` to the origin that
+sent the view. It posts `{ type: 'gev:ready' }` once it can take views, and
+only its parent page can send them. See `src/app/embed.js`.
+
+No page may frame the app by default: every document keeps
+`X-Frame-Options: DENY` and `frame-ancestors 'none'`. Setting
+`GEV_EMBED_FRAME_ANCESTORS` lets the pages it names (CSP frame-ancestors
+sources, or `*` for any page) frame embed-mode documents only. The MCP Apps
+panel loads the app into its own page and needs no framing.
+
+Answers that have something to show include `data.view`: the view that
+shows them, with the matching layers on, an area framed from above, and a
+single aircraft or satellite followed, plus `url` to open it (null when the
+app's address is not configured). `suggestView` in `src/tools/views.js`
+builds one.
+
+## The `area` argument
+
+Location-scoped tools take `area` as exactly one of a `place` name, a `bbox`
+(`[west, south, east, north]`, crossing the antimeridian when west exceeds
+east), or `lat`, `lon` and `radius_km`. Lists default to 25 rows, at most 200,
+and report `total`, `returned` and `truncated`.
+
+## MCP
+
+`createMcpServer({ catalog, name, version, instructions, descriptions, decorate })`
+implements `initialize`, `ping`, `tools/list` and `tools/call` for protocol
+revisions 2025-11-25, 2025-06-18 and 2025-03-26. `descriptions` overrides a
+tool's title or description for this surface; `decorate(definition, tool)`
+merges extra fields into each listed definition. `createMcpHttpHandler(server)`
+returns a `Request`-to-`Response` handler for stateless Streamable HTTP: one
+JSON-RPC message per POST, answered with JSON. The host owns routing and any
+access control in front of it.
+
+## Voice
+
+Voice offers the catalog's queries next to its app actions.
+`toFunctionTools(tools, { exclude })` turns tools into
+`{ type: 'function', name, description, parameters }` records, and
+`toFunctionOutput(name, result)` turns a result into
+`{ ok, tool, summary, data }`, counting images in `images_omitted` instead of
+sending them.
+
+The voice session token endpoint takes its tool list as `realtime.tools`.
+`realtimeSessionTools(additional)` appends function tools to the app actions,
+skipping names an action already uses, so `next_satellite_pass` stays the
+action. The standalone server supplies the core queries that
+`src/tools/surfaces.js` offers on voice, which leaves out tools that answer
+with images, link to the app, or repeat what voice's app actions answer
+(aircraft, ships, earthquakes, fires, datacenters, dams and satellites
+overhead, which `analyst_query` covers).
+
+In the browser, `initGevVoiceCommands({ toolCatalog })` takes a function that
+resolves a catalog. App action names go to the action runner; other names the
+catalog has go to `catalog.call` with the call's abort signal. The standalone
+entry composes the catalog with `createToolServices` over the page's fetch and
+loads it the first time voice calls a query.
+
+## Running locally
+
+Start the app (`npm run dev` or `npm run preview`), then register the stdio
+server with an MCP client, for example Claude Code:
+
+```bash
+claude mcp add gods-eye-view -- npm --prefix /path/to/gods-eye-view run --silent mcp
+```
+
+`npm run mcp -- --api-base http://localhost:4173` selects another server.
+
+The development and preview servers also serve the same tools over HTTP at
+`/mcp`, for clients that connect by URL:
+
+```bash
+claude mcp add --transport http gods-eye-view http://localhost:4173/mcp
+```
+
+The route accepts only requests from this machine that name a loopback host
+on the port they reached and, when a browser sends an `Origin`, come from
+that same host. It refuses requests a proxy forwarded and refuses all
+requests while launcher sharing is on. This is local transport safety, not
+authentication. The
+local server's tools request the app's `/api` routes and the public feeds
+the sources already use. The panel's `panel_request` also requests the app's
+own files and data routes for the panel: it requires the key in the panel's
+page, and refuses Provider Settings, credential and model endpoints, `/mcp`
+and the development server's internal routes. See SECURITY.md.
+
+## Tools
+
+| Tool                  | Reads         | Returns                                                       |
+| --------------------- | ------------- | ------------------------------------------------------------- |
+| `get_earthquakes`     | `earthquakes` | USGS M2.5+ events in the last 24 hours, strongest first        |
+| `get_active_fires`    | `fires`       | NASA FIRMS detections in an area, highest radiative power first |
+| `get_recent_launches` | `launches`    | Launch Library 2 launches in the last 30 days, newest first    |
+| `aircraft_in_area`    | `aircraft`    | Aircraft in an area, nearest first; `military: true` reads the `military` feed |
+| `find_aircraft`       | `aircraft`    | Aircraft anywhere by callsign, ICAO address or registration    |
+| `get_aircraft_track`  | `aircraft`    | Recent positions of one aircraft, thinned to 200 points        |
+| `get_aircraft_info`   | `aircraft`    | Aircraft type and registration, and flight route, from adsbdb  |
+| `vessels_in_area` | `vessels` | Ships reported by AIS in an area, nearest first, optionally by type |
+| `find_vessel` | `vessels` | Ships anywhere by MMSI, IMO number or name |
+| `get_vessel_track` | `vessels` | Recent positions of one ship, thinned to 200 points |
+| `next_satellite_pass` | `satellites` | Next pass over a place or point (default the ISS), with naked-eye visibility |
+| `satellites_overhead` | `satellites` | Satellites in a CelesTrak group above a place or point now, highest first |
+| `find_cctv_cameras` | `cctv` | Public cameras in an area, nearest first |
+| `get_cctv_snapshot` | `cctv` | The current image from one camera, returned as image content |
+| `find_alpr_cameras` | `alpr` | OpenStreetMap-mapped license plate readers in a US/Canadian area up to 3° |
+| `find_radio_stations` | `radio` | Radio Browser stations by area and/or search terms, with stream URLs |
+| `search_places` | `placeSearch` | Points of interest matching a query within an area (Google Places) |
+| `places_nearby` | `placeSearch` | Notable places around a place or point (Google Places) |
+| `plan_route` | `routing` | Walking, driving or cycling route over OpenStreetMap, with a simplified path |
+| `get_bike_share` | `bikeshare` | Live GBFS stations in an area, with bikes and docks available |
+| `get_transit_vehicles` | `transit` | Live GTFS-Realtime vehicle positions in an area, optionally one route |
+| `get_traffic_flow` | `traffic` | TomTom flow in a city-sized area: speed vs free flow, congested and closed road |
+| `get_weather` | `weather` | Current conditions at a place or point |
+| `get_weather_map` | `weatherMaps` | The latest NOAA radar, satellite or lightning map image over an area |
+| `get_wind` | `wind` | GFS or IFS model wind 10 m above ground at a location |
+| `get_recent_imagery` | `imagery` | The most recent clear Landsat/Sentinel-2 image of an area (VIIRS fallback) |
+| `find_submarine_cables` | `cables` | TeleGeography cables and landing points by area or name (CC BY-NC-SA 3.0) |
+| `find_infrastructure` | `infrastructure` | OpenStreetMap datacenters or dams in an area, nearest first (ODbL) |
+| `get_bhote_koshi_flood` | `events` | The 2026 Bhote Koshi flood: evidence trail in story order, flood path and imagery dates (CC BY-NC 4.0) |
+| `get_regional_brief` | `regional` | What and where a location is, its weather and recent headlines |
+| `get_cyclones` | `cyclones` | Active NHC/CPHC tropical cyclones, optionally in an area |
+| `get_fire_perimeters` | `perimeters` | Mapped WFIGS wildfire perimeters in an area, largest first |
+| `get_terrain_height` | `terrain` | Ground, geoid and ellipsoid heights at up to 20 points |
+| `find_military_installations` | `installations` | OpenStreetMap military sites in an area of at most 10° per side |
+| `get_map_features` | `features` | Administrative areas, named places or monuments at a location (needs Overpass) |
+| `situation_brief` | `weather` | Weather, earthquakes, fires, aircraft, ships and cyclones for an area, by section |
+| `military_awareness` | `military` | Military and other aircraft, ships and military installations within 250 km of a point, by section |
+| `get_hud_caption` | `weather`, `summary` | The app's heads-up display caption for an area |
+| `show_in_gods_eye_view` | `app` | A view in God's Eye View: the live panel in clients with MCP Apps, and a link everywhere; takes another answer's view or an area or camera, layers, style, map, marks and something to follow |
+| `panel_request` | `app` | Panel only: loads a path from the app's server for the God's Eye View panel |

docs/panel-surfaces.md

@@ -0,0 +1,150 @@
+# Panel surface contract
+
+`src/ui/styles/panel-surfaces.css` supplies an opt-in visual surface for new
+panels. It uses the application's default color, font, border and radius tokens;
+Cyber supplies its existing red/slate palette, monospace typography and shaped
+frame. This is CSS shared by the existing panel system, not a panel registry or
+a controller. A panel ID does not need a new theme selector.
+
+## Markup
+
+A rail panel uses an outer owner with its existing stable `id`, matching
+`data-panel-id`, and `panel-collapsible` class. Its first non-glow child is the
+surface. Keep the header and any outward popup outside the scrolling body:
+
+```html
+<section
+  id="example-panel"
+  data-panel-id="example-panel"
+  class="panel-collapsible"
+>
+  <div data-panel-surface>
+    <header data-panel-header>
+      <h2 class="panel-title panel-surface-title">Example</h2>
+      <button
+        class="panel-collapse-btn panel-surface-control"
+        data-collapse-target="example-panel"
+        aria-expanded="true"
+        aria-label="Collapse Example"
+      >
+        −
+      </button>
+    </header>
+    <div data-panel-body data-rail-scroller>
+      <label>Filter <input class="panel-surface-control" type="text" /></label>
+      <button class="panel-surface-control" type="button">Apply</button>
+      <p class="panel-surface-error" role="status" hidden></p>
+    </div>
+    <aside data-panel-popup hidden aria-label="Example help">
+      <!-- The panel owns this popup's placement and interactions. -->
+    </aside>
+  </div>
+</section>
+```
+
+Use native controls and accessible names. `.panel-surface-control` is an
+optional skin for buttons, text fields, selects and textareas; it provides
+hover, focus, disabled and invalid-state styling. Native `disabled` owns actual
+disablement; `aria-disabled` alone only describes a state and must be enforced
+by the controller. `.panel-surface-error` supplies error color, not announcement
+or validation behavior. Keep checkbox/radio semantics and labels intact.
+
+`data-panel-header` stays outside `data-panel-body`, so it remains reachable
+when content scrolls. Give the body a bounded height through its containing
+surface. The rail's allocation supplies that bound; a dock or dialog owner must
+supply its own `max-height` or height. Avoid a flex body whose contents shrink to
+fit when those contents should instead scroll.
+
+## Placement and ownership
+
+| Mount                                 | Shared contract                                                                                     | Owner responsibilities                                                                                                                                                                                   |
+| ------------------------------------- | --------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Direct child of `#left-panel-stack`   | An owner with a direct `[data-panel-surface]` child receives relative positioning and allocated height; inner surface/body skin | Add the wrapper shown above, use the existing layout/disclosure owners, and retain left-rail focus/auto-collapse rules.                                                                                  |
+| Direct child of `#right-context-rail` | The same hooks with right-rail allocation and intrinsic measurement                                 | Keep `data-rail-scroller` on the body so measurement preserves its scroll position. Respect Cyber's one-expanded-panel policy.                                                                           |
+| Surface inside `#command-dock`        | Surface, controls, popup decoration and inherited dock concealment                                  | Supply geometry, stacking, disclosure, pin behavior if wanted, safe viewport bounds and dismissal. This CSS does not extend the existing Location/Visual Presets tray stack manager to arbitrary panels. |
+| `dialog[data-panel-surface]`          | The same surface/body skin; a closed dialog remains hidden                                          | Set width/max-height, use `showModal()` or `show()` and `close()`, and own labels, initial/return focus and dismissal. Do not put `panel-collapsible` on a dialog.                                       |
+
+For rails, `--panel-expanded-width` and `--panel-collapsed-width` customize
+the desired widths within the rail; otherwise Cyber uses its existing left,
+right and collapsed panel widths. `--left-panel-allocated-height` and
+`--right-panel-allocated-height` belong
+to the existing layout owner, not to individual panels. The surface must be
+the wrapper's first non-glow child because left-rail intrinsic measurement
+inspects that child. Do not put an absolutely positioned popup before the
+surface or inside its body. Position a popup beside or above its surface using
+component CSS; the shared rules deliberately do not choose a direction that
+could run beyond the viewport.
+
+Rail measurement still considers visible child extents. A popup extending
+below the surface can therefore increase its measured height. Prefer a popup
+beside or above the surface, or integrate an external overlay host with the
+feature's layout owner; this CSS does not change measurement algorithms.
+
+At viewport widths of 720px or less, both rails are intentional scroll
+containers. Their overflow can clip outward popups even when the panel's own
+surface is unclipped. Use a popup contained within the rail's visible bounds,
+or an explicitly owned overlay host outside the rail; the surface contract
+does not provide automatic popup escape from these small-screen scroll regions.
+
+For dock disclosure, use a semantic button with `.panel-surface-control` and
+the feature's own accessible name, `aria-expanded` state and event binding.
+Do not copy the rail example's `.panel-collapse-btn` class into the dock:
+existing dock rules intentionally hide that class. The generic surface skin
+does not replace the dock's disclosure policy.
+
+The existing `PanelChrome` binds `.panel-collapse-btn[data-collapse-target]`
+at initialization and routes state through `setPanelCollapsed`. For additions
+present at startup, keep those hooks and the existing chrome lifecycle. A
+dynamically mounted panel must bind and dispose its own disclosure using
+`bindPanelDisclosure` / `collapsePanelOnEscape` from `panelDisclosure.js`, with
+the application owning state changes. Do not rerun the whole application chrome
+initializer just to add one panel. `layoutLeftPanelRail` and
+`layoutRightPanelRail` accept arbitrary direct `data-panel-id` children; their
+host owns layout scheduling, observations and collapse callbacks. Dynamic
+content that changes size may require an owner-scheduled layout pass or an
+owned `ResizeObserver`; adding CSS attributes does not register new observers.
+
+Persisted/share-link state, pinning, provider loading, keyboard shortcuts and
+Cockpit-specific mounting still require deliberate integration with their
+current owners. This contract does not add entries to named persistence, dock,
+Cockpit or share-state policies. Dispose listeners, observers and timers,
+dismiss open popups/dialogs and restore focus before removing a dynamic panel.
+
+## Decoration, popups and visibility
+
+The shared surface reserves `::before` for its non-interactive background. The
+Cyber frame clips this pseudo-element only; the surface stays unclipped with
+visible overflow. This follows the existing Display and Global Context pattern.
+Putting the shape on an interactive ancestor clips all descendant popups even
+if their `z-index` is high. A scrolling body also clips descendants by design,
+so outward popups must be siblings of the body, or use an explicitly owned
+overlay host outside every clipping ancestor.
+
+`data-panel-popup` gives a positioned popup the same decorative and control
+tokens. It is not a popover API, focus trap, collision solver or top-layer
+manager. The owner must keep it inside the viewport, above relevant siblings,
+and reachable by pointer and keyboard. A native modal dialog participates in
+the browser top layer; a surface in a rail does not. Transform, containment,
+mask, clipping or stacking rules on an additional ancestor can still obstruct
+either an ordinary panel or its popup. Arbitrary future markup is not covered.
+
+`hidden`, a closed native dialog and collapsed bodies/popups remain hidden.
+Clean UI and recording conceal conforming surfaces, including outward popups;
+owners must close modal dialogs when entering these modes so an invisible
+modal cannot leave the application inert. Existing Cockpit rail and dock
+exclusions remain in force. New left-rail/Cockpit functionality needs an
+explicit product integration; the surface attribute grants no mode exception.
+Never use theme styling to alter stored preferences or force hidden content
+visible.
+
+## Check an addition
+
+Use the real application with the default and Cyber themes. Check open,
+collapsed, hidden, disabled/error, theme round trips, clean UI/recording and
+the intended Cockpit behavior. Exercise keyboard focus, Escape, pointer input,
+the last scrolling item, resize without reload and any pin/unpin controls.
+For an outward popup, test visible pixels and pointer hit-testing outside the
+surface; a positive bounding box alone does not prove it escaped clipping.
+Check each mount the addition actually supports. The CSS contract cannot
+establish provider correctness, disclosure lifecycle or responsive placement
+without those feature-specific checks.