feat(simulation): add provider-neutral worker profile

docs/01_IMPLEMENTATION_PLAN.md

@@ -24,7 +24,7 @@ Each gate produces evidence and an explicit GO, PAUSE or BLOCKED result.
 | Plugin isolation | GO (laboratory control plane) — vendor backend/frontend and optional scene controls are plugin-owned; manifest/runtime descriptor parity, versioned handshake, lifecycle health and transport correlation fail closed while execution remains in-process |
 | K1 application control | GO (physical staged cycle) — after fixing the PCAP-proven `sint64` time field, one explicit UI launch completed all 14 canonical operations on one control session, reached live `SCANNING + project + init_ready`, displayed real points, then one explicit STOP returned K1 to unbound `READY`. No retry or fallback command was sent. Native-project reuse through LixelGO/USB remains an independent verification |
 | Stage 8 product storage | PAUSE — retention, replication, encryption, capacity monitoring and long-run browser/WASM stress remain deployment gates |
-| Simulation Polygon | SIM S0 GO; S1A complete; S1B lifecycle PASS; S1C registered live worker PASS; UI-2 browser surface PASS; S1D Ackermann command/motion slice PASS — exact code generation `49b0f47` passed 40 focused tests on the immutable D-only generation. The capability-gated `Полигон` root owns one procedural 3D Ackermann Rover workspace with full azimuth/vertical orbit, zoom, pan, follow/reset and live diagnostic ENU state. Cold start completed in one request after 32.08 s. Run `s1c-49b0f47-20260724t195259z-62edd2` proved 3.74 m straight motion, a curved turn, reverse, 44.6 ms sampled command admission, 250 ms TTL expiry and clean zero-residue stop through PX4 rover-level Offboard throttle/steering setpoints. Differential Rover, calibrated closed-loop speed, canonical PX4/ROS 2 telemetry, pause/step/reset, heartbeat/offboard/link-loss cases, navigation/safety acceptance, shared-deployment auth/RBAC and real actuator authority remain absent |
+| Simulation Polygon | SIM S0 GO; S1A–S1D lifecycle/browser/Ackermann command slices PASS on the accepted Gazebo/PX4 regression profile. S1E now makes provider interchangeability executable through a strict provider profile, generic live-state source and generic command acceptance. Gazebo remains the frozen low-cost regression tier; ADR 0017 gates a measured native Unreal/CARLA/Project AirSim U0 selection before any production bridge. Differential Rover, calibrated closed-loop speed, canonical PX4/ROS 2 telemetry, pause/step/reset, heartbeat/offboard/link-loss cases, navigation/safety acceptance, shared-deployment auth/RBAC and real actuator authority remain absent |
 
 USB project copying remains optional ground truth rather than a blocker for the
 now-verified network path. Owner-operated LixelGO traffic verifies the MQTT
@@ -128,8 +128,9 @@ The Polygon branch follows
 [`docs/12_SIMULATION_POLYGON_PRODUCT_AND_SRS.md`](12_SIMULATION_POLYGON_PRODUCT_AND_SRS.md)
 and
 [`ADR 0015`](adr/0015-simulation-polygon-qualification-boundary.md). Component
-placement and field/offline topology follow
-[`ADR 0016`](adr/0016-distributed-product-edge-and-worker-topology.md).
+placement follows [`ADR 0016`](adr/0016-distributed-product-edge-and-worker-topology.md);
+provider neutrality and the Unreal evaluation follow
+[`ADR 0017`](adr/0017-provider-neutral-simulation-and-unreal-evaluation.md).
 It does not reorder or weaken the K1 physical-evidence gates in this document.
 Its first gate, SIM S0, is accepted:
 

docs/12_SIMULATION_POLYGON_PRODUCT_AND_SRS.md

@@ -13,7 +13,7 @@ Ops source of truth:
 - [MISSIONCOR-41](https://ops.nodedc.ru/nodedc/browse/MISSIONCOR-41) is the
   active S1 lifecycle/authority implementation and qualification gate.
 
-This document, ADR 0015 and ADR 0016 are the repository truth. A material change
+This document, ADR 0015, ADR 0016 and ADR 0017 are the repository truth. A material change
 to run kinds, authority, clocks, frames, source-of-record, provider boundaries,
 component placement or phase gates must update the ADR/SRS and MISSIONCOR-39
 together.
@@ -103,6 +103,15 @@ Polygon is now a parallel product branch. As of this document:
 - this is not a calibrated closed-loop speed controller acceptance and does
   not close Differential Rover, canonical PX4/ROS 2 telemetry,
   heartbeat/offboard/link-loss, failsafe, navigation or safety checkers;
+- the next repository slice introduces
+  `missioncore.simulation-provider-profile/v1`, worker status v2 and command
+  acceptance v2. Runtime roles/capabilities, authoritative simulation clock,
+  canonical frames and control profiles are no longer inferred from hardcoded
+  Gazebo/PX4 names;
+- the stock Gazebo/PX4 profile remains the accepted regression baseline.
+  Unreal is a candidate high-fidelity provider family; native Unreal, CARLA and
+  Project AirSim require the bounded U0 comparison from ADR 0017 before one is
+  selected;
 - `actuator_authority=false`;
 - `navigation_or_safety_accepted=false`.
 
@@ -166,10 +175,13 @@ Mission Core owns:
 
 Providers remain replaceable:
 
-- Gazebo owns simulated world state, sensors, contacts and physics.
-- PX4 SITL owns rover control loops, constraints, offboard lifecycle and
-  autopilot failsafe.
-- ROS 2 transports typed telemetry and commands.
+- a world/physics/state provider owns simulated world state, sensors, contacts,
+  truth and the declared simulation clock; the accepted regression provider is
+  Gazebo, while Unreal candidates remain unaccepted;
+- a controller provider owns rover control loops, constraints, command
+  lifecycle and controller failsafe; the accepted stock controller is PX4 SITL;
+- a transport provider carries typed telemetry and commands; the stock profile
+  uses ROS 2 and Micro XRCE-DDS;
 - Nav2 supplies the first mature planning/costmap/collision-checking baseline.
 - Rerun or another viewer presents derived evidence and never becomes a queue,
   orchestrator or source-of-record.
@@ -201,14 +213,15 @@ Simulation Orchestrator
        +---- clock, namespace, port and process ownership
        +---- artifact/provenance store and evaluator
        |
-       +---- Gazebo adapter ---- Gazebo world/physics/sensors
-       +---- PX4 adapter ------- PX4 SITL rover controller/failsafe
-       +---- ROS 2 adapter ----- Micro XRCE-DDS and canonical topics
+       +---- provider profile -- roles/capabilities/clock/frames
+       +---- world adapter ----- Gazebo baseline or admitted Unreal profile
+       +---- control adapter --- PX4 SITL or another admitted controller
+       +---- transport adapter - ROS 2/XRCE or another admitted transport
        +---- planner adapter --- Nav2 or Mission Core planner
        +---- viewer adapter ---- canonical state/derived report
 ```
 
-Gazebo and PX4 never run inside the web process. The browser never owns process
+Native simulation and controller providers never run inside the web process. The browser never owns process
 lifecycle or command authority. Losing the browser cannot terminate the only
 copy of run state and cannot bypass the server-side authority gate.
 
@@ -388,7 +401,10 @@ last. An orphan process is an S0/S1 failure.
 
 For `simulation_closed_loop`:
 
-- Gazebo `/clock` is authoritative.
+- the admitted provider profile declares exactly one authoritative simulation
+  clock and a provider with `clock.simulation`;
+- the stock regression profile uses Gazebo `/clock`; an Unreal adapter must
+  publish a distinct fixed-step clock domain;
 - ROS 2 consumers use `use_sim_time=true`.
 - PX4 uXRCE-DDS time synchronization is disabled when Gazebo time is used.
 - Canonical timestamps are integer nanoseconds and include their clock domain.
@@ -496,7 +512,7 @@ incompatible.
 
 ## 14. Upstream baseline
 
-The S0 accepted line is:
+The S0 accepted regression line is:
 
 - Windows 11 AI worker;
 - dedicated `MissionCore-Sim` WSL2 Ubuntu 24.04 distribution physically on D;
@@ -558,6 +574,8 @@ context and are not misattributed to headless S0.
 | P0 | 2–4 days | Product thesis, SRS, ADR and canonical contracts accepted |
 | S0 | 3–5 days | Target compatibility, D-only runtime, exact pins, clock/process/resource evidence |
 | S1 | 7–12 days | Stock Ackermann and Differential lifecycle/control/failsafe evidence |
+| U0 | 2–4 days | Native Unreal/CARLA/Project AirSim selection matrix with measured worker fit |
+| U1 | 5–10 days | Selected Unreal candidate proves canonical clock/state/command lifecycle |
 | S2 | 15–25 days | LiDAR/odometry/Nav2 baseline, evaluator and obstacle scenarios |
 | S2B | 5–8 days | Representative 30-world BARN pilot |
 | S3 | 20–35 days | K1-like virtual sensors and Mission Core perception closed loop |
@@ -572,12 +590,14 @@ Implementation cards follow this order:
 3. Clock, frame and authority contracts.
 4. Orchestrator lifecycle and artifact store.
 5. PX4 stock rover control and failsafe.
-6. Nav2 adapter and truth baseline.
-7. Evaluator, report and BARN pilot.
-8. Virtual K1 and perception.
-9. Replay/shadow datasets.
-10. RAVNOVES00 twin.
-11. Trike, HIL and safety gate.
+6. Provider-neutral profile/status/command boundary.
+7. Complete the U0 Unreal candidate comparison; U1 may run in parallel.
+8. Nav2 adapter and truth baseline on the frozen Gazebo profile.
+9. Evaluator, report and BARN pilot.
+10. Virtual K1 and perception; promote an Unreal provider only after U1.
+11. Replay/shadow datasets.
+12. RAVNOVES00 twin and Unreal physical/sensor world if U2 is accepted.
+13. Trike, HIL and safety gate.
 
 ## 17. SIM S0 acceptance
 
@@ -761,6 +781,27 @@ Differential Rover, deceleration/emergency-stop profiles, accepted PX4/ROS 2
 telemetry, reset/repeatability, heartbeat/offboard/link-loss, full failsafe and
 navigation/safety cases.
 
+#### S1E provider-neutral boundary status
+
+The next repository increment makes provider interchangeability executable
+rather than aspirational:
+
+- `SimulationProviderProfile` strictly declares logical provider roles,
+  capabilities, authoritative simulation clock, canonical ENU/FLU frames and
+  supported rover control profiles;
+- worker status v2 separates the configured provider stack from currently
+  active process IDs;
+- `VehicleState` retains the v1 canonical frame/safety contract but accepts any
+  safe named diagnostic ground-truth provider;
+- command acceptance v2 reports a generic controller provider, canonical
+  control profile, readiness and bounded boolean diagnostics;
+- the stock Gazebo/PX4/XRCE profile satisfies the new contract;
+- backend and browser tests admit an Unreal-shaped profile without adding
+  Unreal-specific branches.
+
+This is contract acceptance only. It does not claim that Unreal is installed,
+selected, running or qualified. ADR 0017 U0 is the next decision gate.
+
 ### S2
 
 - Gazebo LiDAR/odometry feed the ROS 2/Nav2 baseline.
@@ -846,6 +887,10 @@ history. It does not claim command authority. Scenarios, pause/step/reset,
 canonical rover commands, Compare and Report remain planned. UI-2 cannot own
 provider processes, bypass authority checks or write directly to PX4.
 
+The browser scene remains a canonical-state product view, not the physics
+engine. A future Unreal worker supplies the same state/evidence contracts; it
+is not embedded into React and its native editor/window remains diagnostic.
+
 ## 21. Change control
 
 A material change requires:

docs/adr/0015-simulation-polygon-qualification-boundary.md

@@ -35,9 +35,10 @@ reports easy to misuse.
 5. Simulation Orchestrator is the sole process-lifecycle owner. Gazebo and PX4
    do not run inside the Mission Core web process, and the browser has no direct
    PX4 channel.
-6. Gazebo `/clock` is authoritative in closed-loop simulation. ROS 2 uses
-   simulated time and PX4 uXRCE-DDS time synchronization is disabled for this
-   profile.
+6. Each admitted closed-loop provider profile declares exactly one
+   authoritative simulation clock. The accepted stock profile uses Gazebo
+   `/clock`; ROS 2 uses simulated time and PX4 uXRCE-DDS time synchronization
+   is disabled for that profile.
 7. Mission Core uses ENU/FLU. PX4 uses NED/FRD. Exactly one adapter boundary
    converts frames and requires golden tests.
 8. The first command boundary permits only rover speed+steering and
@@ -67,6 +68,10 @@ reports easy to misuse.
     [ADR 0016](0016-distributed-product-edge-and-worker-topology.md). Native
     Gazebo GUI is worker-local diagnostics; the operator product remains the
     browser Control Station over canonical state.
+18. Provider roles, capabilities, clock and canonical frames follow
+    [ADR 0017](0017-provider-neutral-simulation-and-unreal-evaluation.md).
+    Gazebo remains the regression baseline; Unreal is an unevaluated
+    high-fidelity provider family, not a replacement product architecture.
 
 ## Consequences
 

docs/adr/0017-provider-neutral-simulation-and-unreal-evaluation.md

@@ -0,0 +1,179 @@
+# ADR 0017: Provider-neutral simulation and Unreal evaluation
+
+## Status
+
+Accepted for architecture on 2026-07-25. The provider contract is implemented
+on the Polygon branch. Gazebo remains the accepted regression baseline. No
+Unreal integration, Unreal runtime profile or choice between native Unreal,
+CARLA and Project AirSim is accepted by this decision.
+
+## Context
+
+The first Polygon vertical proved that Mission Core can own a virtual Ackermann
+run, display canonical ENU/FLU state in React, persist evidence and deliver
+bounded virtual-only rover commands through PX4. That proof used one concrete
+stack: Gazebo Harmonic, PX4 SITL, ROS 2 and Micro XRCE-DDS.
+
+Treating that stack as the product architecture would make later work expensive:
+
+- a realistic vehicle, road surface, terrain and sensor model may be easier to
+  build and inspect in Unreal;
+- reconstructed Gaussian scenes are primarily visual evidence and do not by
+  themselves supply collision, friction, road or navigation geometry;
+- native Unreal, CARLA and Project AirSim have different vehicle, sensor,
+  controller, platform and lifecycle assumptions;
+- a browser cannot and should not execute the full physics/autopilot stack;
+- replacing Gazebo must not replace Mission Core run identity, authority,
+  evidence, UI or evaluator contracts.
+
+The choice is therefore not “Gazebo or Unreal for the whole product.” It is
+which worker-side provider profile is appropriate for each qualification case.
+
+## Decision
+
+1. Mission Core remains simulation-provider neutral. A worker publishes an
+   exact `missioncore.simulation-provider-profile/v1` before it may be used by
+   the browser or gateway.
+2. A provider profile declares logical providers, roles, capabilities,
+   authoritative simulation clock, supported canonical control profiles and
+   the fixed `map_enu`/`base_link_flu` boundary.
+3. Provider roles are `world`, `physics`, `state`, `controller`, `transport`,
+   `sensor` and `traffic`. One process may implement several roles; several
+   processes may compose one profile.
+4. Component pins and provider roles remain separate:
+   component pins prove exact software provenance, while provider descriptors
+   explain runtime responsibility and interoperability.
+5. Worker status v2 exposes the configured provider profile separately from
+   currently active process IDs. `VehicleState` names its source provider.
+   Command acceptance v2 names the delivering controller provider and canonical
+   control profile.
+6. The browser consumes canonical state and evidence. Unreal, Gazebo, PX4,
+   ROS 2 and their native windows remain outside React and run on registered
+   workers.
+7. Gazebo/PX4 remains the frozen, comparatively cheap deterministic regression
+   profile until another profile passes the same lifecycle, clock, command,
+   safety and evidence gates.
+8. Unreal is evaluated as a high-fidelity provider family. Native Unreal,
+   CARLA and Project AirSim are separate candidates and are not interchangeable
+   labels:
+   - native Unreal maximizes project control but requires Mission Core-owned
+     vehicle, sensor, clock and bridge work;
+   - CARLA is evaluated when road/traffic simulation and its supported vehicle
+     model fit the rover case;
+   - Project AirSim is evaluated only against its current supported vehicle,
+     PX4, ROS 2, platform and maintenance constraints.
+9. A Gaussian scene may provide appearance and sensor-rendering context. Every
+   qualification world still needs separately versioned physical collision
+   meshes, road/drivable surfaces, materials/friction, semantic regions,
+   spawn/goal definitions and evaluator truth.
+10. Unreal does not block S1 completion or the S2 Gazebo/Nav2 baseline. It
+    becomes most valuable in S3 virtual-sensor/perception work and S5
+    high-fidelity/digital-twin work. An earlier bounded adapter spike is allowed
+    because it reduces architectural risk.
+11. PX4 remains a replaceable controller provider. An Unreal profile may use
+    PX4 through an admitted external-simulator boundary or may use a different
+    virtual controller, but each choice creates a distinct profile and cannot
+    inherit the other profile's evidence.
+12. No real actuator authority is introduced. All current profiles remain
+    `virtual-only`.
+
+## Fidelity ladder
+
+| Level | Purpose | Initial provider |
+| --- | --- | --- |
+| L0 contract tests | Fast lifecycle, schema and safety regression | In-process fakes |
+| L1 dynamics regression | Cheap repeated control/navigation qualification | Gazebo + PX4 SITL |
+| L2 sensor/scene fidelity | Camera/LiDAR/perception and difficult visual worlds | Unreal candidate |
+| L3 hardware/control integration | Controller-in-loop and HIL | Separate gated profile |
+| L4 physical evidence | Shadow and later controlled field qualification | Vehicle Edge Agent |
+
+A higher level does not replace lower-level regression. Evidence is comparable
+only when scenario, provider profile, metric profile and reproducibility tier
+allow it.
+
+## Unreal evaluation gates
+
+### U0 — selection spike
+
+For native Unreal, CARLA and Project AirSim, record:
+
+- supported rover/Ackermann dynamics and controllable wheel/suspension model;
+- fixed-step clock, pause/step/reset and headless execution;
+- external command/state bridge and PX4 compatibility;
+- camera, depth, LiDAR, IMU, GNSS and ground-truth availability;
+- collision/contact and semantic truth;
+- Linux/Windows worker placement, GPU/VRAM/RAM and startup time;
+- automation, packaging, licensing, upstream activity and version pinning;
+- import path for existing Unreal assets and Gaussian reconstructions.
+
+Exit: one candidate or native implementation is selected for a disposable U1
+adapter. “Looks better” is not an exit criterion.
+
+### U1 — canonical adapter proof
+
+- publish one provider profile and authoritative fixed-step clock;
+- launch/reset/stop through the Simulation Orchestrator;
+- map a stock Ackermann pose to `VehicleState`;
+- accept `rover-speed-steering/v1` under the existing TTL/watchdog boundary;
+- prove straight, turn, reverse, command expiry and clean zero-residue stop;
+- retain exact world, provider, host and resource evidence on D.
+
+Exit: the existing React panel and run archive work without Unreal-specific
+branches in Mission Core.
+
+### U2 — physical and sensor world
+
+- add reviewed collision/drivable geometry alongside visual assets/Gaussians;
+- pin vehicle mass, inertia, wheelbase, steering limits, suspension, friction
+  and sensor extrinsics;
+- publish evaluator-only truth separately from planner/perception inputs;
+- validate camera/LiDAR timing, noise and frame conversion.
+
+Exit: sensor/perception experiments are repeatable and do not consume hidden
+ground truth.
+
+### U3 — comparative qualification
+
+- run equivalent scenarios through the Gazebo and Unreal profiles;
+- report control, collision, latency, resource and reproducibility differences;
+- declare which conclusions are portable across providers and which are not.
+
+Exit: Unreal supplies measurable product value beyond rendering quality.
+
+## Immediate work policy
+
+Continue work that remains valuable across providers:
+
+- provider-neutral orchestration and capability admission;
+- run, event, command, artifact and report contracts;
+- TTL, heartbeat, watchdog, failsafe and authority gates;
+- canonical frames, clocks, telemetry and evaluator metrics;
+- scenario/profile registry and browser presentation of canonical state;
+- Gazebo regression cases needed to validate those boundaries.
+
+Defer until U0 selects a direction:
+
+- a polished custom Gazebo vehicle;
+- large Gazebo world/model libraries;
+- simulator-specific UI controls;
+- a production Unreal bridge;
+- Gaussian collision or road generation assumptions;
+- provider-specific perception contracts.
+
+## Consequences
+
+- Existing Polygon work is retained as the control plane and regression tier.
+- Unreal experimentation can proceed independently without forking the product
+  model or exposing a native engine to the browser.
+- The first Unreal work is a measured adapter spike, not a platform migration.
+- More explicit provider metadata and compatibility testing is required.
+- Two physics providers increase qualification cost, but allow fast regression
+  and high-fidelity experiments to coexist.
+
+## References
+
+- [PX4 simulator MAVLink API](https://docs.px4.io/main/en/simulation/)
+- [CARLA documentation](https://carla.readthedocs.io/)
+- [Project AirSim documentation](https://iamaisim.github.io/ProjectAirSim/)
+- [ASAM OpenDRIVE](https://www.asam.net/standards/detail/opendrive/)
+

docs/runbooks/SIM_S1C_LIVE_WORKER.md

@@ -48,14 +48,62 @@ Expected status through the backend gateway:
 
 ```json
 {
-  "schema_version": "missioncore.simulation-worker-status/v1",
+  "schema_version": "missioncore.simulation-worker-status/v2",
   "worker_id": "mission-gpu-s1",
   "transport": "unix",
   "mode": "simulation",
   "available": true,
   "control_available": true,
   "active_run_id": null,
-  "run_state": null
+  "run_state": null,
+  "active_provider_ids": [],
+  "provider_profile": {
+    "schema_version": "missioncore.simulation-provider-profile/v1",
+    "profile_id": "stock-rover-gazebo-px4-s1d",
+    "providers": [
+      {
+        "provider_id": "gazebo",
+        "roles": ["world", "physics", "state", "sensor"],
+        "capabilities": [
+          "clock.simulation",
+          "state.vehicle-pose",
+          "truth.ground-truth",
+          "sensor.virtual"
+        ]
+      },
+      {
+        "provider_id": "px4-ros2-offboard",
+        "roles": ["controller"],
+        "capabilities": ["command.rover-speed-steering/v1"]
+      },
+      {
+        "provider_id": "micro-xrce-dds-agent",
+        "roles": ["transport"],
+        "capabilities": ["transport.ros2"]
+      }
+    ],
+    "clock": {
+      "provider_id": "gazebo",
+      "domain": "gazebo:/clock",
+      "unit": "nanoseconds",
+      "mode": "simulation"
+    },
+    "control_profiles": ["rover-speed-steering/v1"],
+    "canonical_frames": {
+      "world": "map_enu",
+      "body": "base_link_flu"
+    }
+  },
+  "isolation": {
+    "network": "loopback-only-netns",
+    "process_identity": "missioncore",
+    "artifact_policy": "d-only"
+  },
+  "authority": {
+    "scope": "virtual-only",
+    "actuator_authority": false,
+    "direct_actuator_setpoints_allowed": false
+  }
 }
 ```