# Lab 006: SIM S0 worker bootstrap and stock-rover smoke

Date: 2026-07-24 (Europe/Moscow).

## Scope

The reviewed Windows 11 AI worker received a dedicated Docker-free
`MissionCore-Sim` WSL2 Ubuntu 24.04 distribution physically stored at
`D:\NDC_MISSIONCORE\simulation\wsl\MissionCore-Sim`. Source, build, cache,
runtime, artifacts and datasets are all under the same D-only root. Existing
Docker Desktop co-tenants were inventoried but not stopped, reconfigured or
used.

This lab grants no real or simulated actuator authority. Every smoke run kept
`actuator_authority=false`; it observed the stock rover while disarmed.

## Redacted worker inventory

- Windows 11 Pro, build 26200;
- WSL2 kernel `6.18.33.1-microsoft-standard-WSL2`;
- Ubuntu 24.04.4 LTS, x86_64;
- 13th Gen Intel Core i9-13900KF, 32 WSL-visible logical CPUs;
- 50,427,760,640 WSL-visible RAM bytes and 12,884,901,888 swap bytes;
- NVIDIA GeForce RTX 4090, driver 610.47, 24,564 MiB VRAM;
- D capacity 2,000,381,014,016 bytes;
- D free after bootstrap and builds: 392,758,685,696 bytes.

The remaining D capacity is above the 300 GiB S0 start threshold and 200 GiB
stop threshold. This does not waive continuous disk monitoring.

## Installed candidate generation

- ROS 2 Jazzy `ros-base=0.11.0-1noble.20260616.084325`;
- `ros-gz=1.0.22-1noble.20260616.074726`;
- Gazebo Harmonic `1.0.0-1~noble`, Gazebo Sim `8.14.0-1~noble`,
  SDFormat `14.9.0-1~noble`;
- PX4 Autopilot v1.17.0 commit
  `d6f12ad1c4f70ad3230afd7d86e971421e02fef4`;
- `px4_msgs` v1.17.0 commit
  `86d8239e962f6939e05c3737784f60c02fa884db`;
- PX4 Gazebo models commit
  `b6127f4ec20de867e215fb5f78ae88b80f371909`;
- Micro XRCE-DDS Agent v2.4.3 commit
  `73622810d984349b80bbac0ef55fc0b694d62222`;
- Nav2 `navigation2=1.3.12-1noble.20260615.181551` and
  `nav2-bringup=1.3.12-1noble.20260616.082701`.

PX4 SITL and `px4_msgs` were built successfully from the pinned D-only source.
The Micro XRCE-DDS Agent was built from source and installed under the D-only
runtime root. Nav2 is installed but has not yet passed an S2 navigation case.

## Observed smoke result

Two consecutive canonical runs and one preliminary resource run passed:

- `20260724T134400Z-stock-rover`;
- `20260724T134600Z-stock-rover-repeat`;
- `20260724T135000Z-stock-rover-baseline`.

The final smoke-script generation also passed as
`20260724T135800Z-stock-rover-final` and added a runtime listener inventory plus
the point resource snapshot.

Each run started PX4 v1.17.0 with Gazebo world `rover` and model
`rover_ackermann_0`, established a Micro XRCE-DDS session, observed
`/fmu/out/vehicle_status_v1`, observed Gazebo `/clock`, requested PX4 shutdown
and found no owned runtime residue. The captured vehicle state was disarmed,
`failsafe=false`, with pre-flight checks passing.

Each provider set ran inside a new Linux network namespace containing only
`127.0.0.1` and `::1`. The Agent's UDP `0.0.0.0:8888` bind was therefore
effective only inside that loopback boundary. No PX4, Gazebo or Agent service
was exposed to the LAN.

The two canonical artifact directories are 68 KiB each. The preliminary
resource run completed in 38.75 seconds. One point sample observed approximately
202 MiB RSS for headless Gazebo, 19 MiB for PX4 and 17 MiB for the Agent. The
worker GPU was already occupied by unrelated co-tenants; no S0 GPU allocation
was attributable in this headless run. These point observations are not the
accepted 1× or 2× resource baselines.

## Diagnostics retained

Earlier bootstrap attempts remain outside Git under the D-only artifact root:

- one check raced the asynchronous DDS connection even though the session
  subsequently established;
- one used an unsupported ROS 2 Jazzy long option;
- one used ROS domain 42 while PX4 v1.17.0 published on domain 0.

The smoke contract now waits for the Agent session plus the PX4
`vehicle_status_v1` writer, uses Jazzy `topic list -t`, and relies on the
loopback-only namespace to isolate domain 0.

An initial malformed interactive log repeatedly captured PX4 terminal repaint
output and reached approximately 1.1 GiB. That generated diagnostic artifact
was removed, then the case was rerun non-interactively; the valid standalone
PX4 log was approximately 8 KiB.

## Target doctor

The exact candidate profile was executed through the read-only doctor inside
`MissionCore-Sim`. Profile SHA-256:
`70bf0df44c85dd57eb3cedb98a474a46ba498c6ffc60ce0d8a06829e28587df1`.

Target identity, authority, clock, port/process registries, all seven D-only
mutable roots, the disk threshold and all eight required executables passed.
Version acceptance and the nine-item digest-bound evidence set remain
incomplete, so the doctor correctly returned `INCOMPLETE`.

## Verdict

`INCOMPLETE`.

Worker compatibility, D-only placement, exact candidate pins, PX4 build,
stock-rover launch, DDS telemetry, authoritative clock observation and repeated
clean lifecycle are factually proven. S0 still requires:

- pause/resume and deterministic single-step evidence;
- 1× speed/real-time-factor acceptance;
- isolated 2× resource/coexistence baseline;
- a complete digest-bound evidence manifest;
- final `GO`, `INCOMPLETE` or `BLOCKED` decision.

This lab does not accept Nav2 behavior, navigation safety, real-time guarantees,
or real actuator control.
