MultiRoombaRover/plans/rover learning service.md

# Rover learning service implementation tracker

## Resume here

Latest repair: full learning-path audit. Fixed missing command labels between
video samples with a shared causal 100ms grid; added real-data score/baseline/
training-probe diagnostics and normalized saved control profiles for retained
recordings. Continues policy 5 / lineage v6; this audit does not reset progress.
See the final audit results section for measured synthetic evidence and limits.

Latest scope (authorized IPI): only drive, camera tilt, headlight and the four
operating-mode/dock commands (128/131/132/143). Exclude horn, song, laser and all
brush/vacuum motor commands from both learning and execution, including raw OI
bypasses. Raw recordings stay intact. Policy format 5, training lineage v6;
startup removes earlier models and lineages through v5. Earlier scope below is
historical. No configuration change required.

Latest change (2026-09-29 IPI): format 4 seeds known user-control command shapes
before training. Generic peripherals are excluded; sensorStream is ignored without
invalidating footage. Drive includes zero-speed drive, with no separate stop type.
Drive, camera, brushes/vacuum, headlight, laser, horn, songs and operating modes
remain supported. Raw recordings and the existing checked command pipe stay intact.

Held-out data cannot expand the schema. Unknown control variants exclude nearby
windows only, with command/count/reason diagnostics and a coverage gate that blocks
promotion. Supported portions still receive evaluation. Current training lineage
is resume-v5.pt / schedule-v5.json. Startup removes obsolete format 1-3 models and
old lineages through v4; recordings and current-format models are preserved.

Verification for this increment is recorded at the end. Earlier version-specific
notes are historical. Manual inputs never pause/cancel autonomy; disabled service
remains dormant. Actual autonomous performance has not been established.

This document preserves the conversation's decisions across compactions and
usage cutoffs. Keep the checklist and handoff section current during authorized
implementation. Do not treat proposals or open questions as user decisions.

The user explicitly authorized feature implementation with: "okay cool. begin
implementation, use the md to track. IPI". Continue the agreed implementation
without requesting IPI again. Follow the current
AGENTS.md instructions: targeted investigation, minimal edits, no new tests unless
requested, proportional direct verification, and no development processes left
running. This development machine is not the actual rover server.

The user declined the manual server checklist and explicitly asked to continue.
Do not block further work or repeatedly ask them to do it. Preserve the unverified
status and have the reader reject unusable recordings automatically.

Latest increment: see the command-event policy handoff at the end. Earlier
format 2 wheel-specific design notes below are historical and superseded.

Next work: verify the integrated feature against actual recordings and the real
camera/rover pipeline when that environment is available; inspect the VIP card in
the running browser. Do not invent successful driving results or block further
implementation on the previously declined manual checklist.

## Intended product

Learn from ordinary human rover use, then let a user select a saved model and
press Start to have it roam and operate the rover's controls. No destination or
structured route is required. Users should not need dedicated demonstration
sessions before collection becomes useful. Build the complete collection and
training pipeline; do not reduce the intended product to a single-route demo.

Chat is out of scope. The user explicitly dropped it to keep the model compact.
This is a learned control policy, not a language model generating instructions.

Learning useful behavior is an experimental objective, not a guaranteed result
of accumulating recordings. Autonomous performance must be observed; low training
loss or fast inference alone does not establish competent driving.

## Agreed requirements

- One self-contained server service, provisionally `roverLearningService`.
- Minimal integration elsewhere: configuration/startup, command recording hook,
  checked command submission hook, and the necessary UI connection.
- The service owns its video recorder processes. Do not move this feature into
  replay, rover management, turn management, or unrelated services.
- Configuration defaults to disabled. Disabled means no active feature runtime.
- Record every rover control input, video, and all available rover sensors.
- Model inputs use recent control history/current state, useful sensors, and
  video. Model outputs can use the rover's supported operating controls, not just
  wheel speeds. Available hardware/control capabilities must be accounted for.
- Record broadly; choosing training features must not discard raw source data
  prematurely within the configured retention window.
- Retain a reasonable bounded rolling training dataset, with ongoing background
  training. The model architecture/parameter count remains bounded as it learns.
- Periodically publish immutable named model versions. Two random words plus a
  unique identifier/sequence is the proposed naming scheme.
- Keep every published model permanently. No automatic model pruning.
- Users can choose which compatible model controls their rover.
- Add the UI card at the top of the VIP tab, using the existing verified-feature
  mechanism. The card is absent when the feature is disabled.
- Model control must use the same permissions and eligibility rules as manual
  rover control. Verified feature access does not grant rover control.
- Favorites are client-side saved model IDs only. No server favorite/pin state,
  endpoints, or retention behavior tied to favorites.
- All server information needed to populate the card arrives in one coherent
  state object. Action commands remain separate from that state object.

Earlier suggestions to prune old model versions or retain only server-pinned
favorites are superseded. Rolling retention applies to training data, not the
published model catalog.

## Architecture and containment

Proposed internal ownership (not a requirement to scaffold empty directories):

```text
server/src/services/roverLearningService/
  configuration.js       Schema/defaults; no runtime side effects
  index.js               Small enable/disable lifecycle entry point
  runtime.js             Enabled runtime coordination
  recording/             Commands, sensors, video processes, synchronization
  dataset/               Rolling storage, training sampling, retention
  training/              Training scheduling and checkpoint production
  models/                Permanent catalog, names, metadata, publication
  driving/               Inference sessions and action scheduling
  workers/               Python model/training implementation
  socketGateway.js       Full card state and authorized user actions
```

Persistent video, datasets, checkpoints, and catalog metadata belong under the
application's existing data-path convention, not the service source directory.
The agreed root is `<data>/rover-learning/`, normally `/data/rover-learning/` in
the deployed container (`SERVER_DATA_DIR`), or `server/data/rover-learning/` with
the default development path. Intended layout:

```text
rover-learning/
  recordings/       Rolling video/events/session metadata (implemented)
  models/           Permanent UUID directories: weights.pt and model.json
  training/         resume-v4.pt, schedule-v4.json, and current job.json
```

Training/model directories are created only when service and training are enabled.
Session/model manifests and a small scheduling ledger are sufficient at present;
the previously proposed catalog.sqlite is not needed or created.
Python compute and video processing must not block the Node event loop. Worker
dependencies, deployment packaging, and process shutdown must be included in the
implementation plan; installing Python packages at server startup is not assumed.

The outside command system should know only about optional observation and
checked submission. It should know nothing about model architecture, datasets,
training, model names, or video recorders.

### Existing integration findings (recheck before edits)

- `server/index.js` explicitly loads services.
- `server/src/configuration/definition.js` assembles service-owned configuration
  fragments. `configuration/index.js` provides live reload handlers.
- `server/src/services/commandService/index.js` exports `issueCommand()` and
  `commandEvents`. Existing `observation` events intentionally omit payloads;
  they are analytics events and insufficient as training examples.
- `issueCommand()` is a low-level send function. Many authorization, turn,
  cooldown, private-drive safety, and overcurrent checks occur in the browser
  command handler before calling it. Direct autonomous calls must not bypass
  those checks.
- `roverManager.managerEvents` already emits decoded `sensor` events and rover
  lifecycle events. The sensor event is not necessarily every raw telemetry field;
  inventory what is available before claiming complete sensor capture.
- `fleetReportService` demonstrates subscriptions and configuration lifecycle,
  but its persistent storage/lifecycle is not automatically the desired disabled
  behavior for this new service.
- `replayEngineV2` demonstrates FFmpeg capture and RTSP/TCP source handling. Reuse
  applicable media conventions without making this feature depend on replay
  being enabled or sharing replay's retention ownership.

### Command recording

Proposed optional observation contract includes timestamp, rover, operator/source,
requested command payload, dispatched payload, outcome, and command ID where
available. Requested and dispatched values can differ due to safety processing.
Distinguish dispatched/acknowledged commands from measured physical execution.

Record human, autonomous, and service-generated commands with distinct provenance.
Autonomous predictions are not automatically correct human training labels.
Include rejected/ignored outcomes where relevant; do not present them as executed
actions. Inventory control paths outside the common browser command handler so
camera/accessory controls are not silently omitted.

The hook only enqueues bounded work. Recording failures or disk pressure must not
block/fail manual command delivery. Preserve the existing payload-free analytics
event contract instead of putting detailed recordings into general logging.
Requested payload snapshots must precede any in-place command transformation.

### Checked command sending and ownership

Proposed implementation: extract a reusable checked submission path from the
current browser command handler, preserving existing manual behavior. Autonomy
submits on behalf of its initiating user's actual control context. Do not invent
an admin identity or send directly to the rover WebSocket.

Recheck permissions server-side for actions and continued control. Losing the
turn/assignment/connection or otherwise losing eligibility stops the autonomous
session. A safe stop must still be possible after ordinary permission is revoked.
Explicit user decision: incoming human commands do not stop or pause autonomy.
Both pass through the existing checked command path; subsequent model commands
can replace human commands. Stop remains explicit, with permission/disconnect,
stale input, and worker failure stops. Model-influenced sessions are excluded
from human demonstration recording, including manual inputs during autonomy.

Model actions describe operating controls, not arbitrary server maintenance.
Inventory reboot/update/raw commands and capability restrictions explicitly rather
than allowing unrestricted command dictionaries from model outputs.

### Disabled lifecycle

Only configuration metadata and a small lifecycle handler remain registered while
disabled, to support live enablement. Lazy-load runtime modules on enable.

When disabled there are no feature recording subscriptions, command observers,
video/Python workers, runtime timers, dataset scans, open feature databases,
created directories, inference/training, or feature socket handlers. The existing
config/feature mechanism hides the card without starting this runtime.

On disable: stop autonomous motion, detach observers, stop and await owned child
processes, flush/close storage appropriately, remove socket handlers/timers, and
release runtime state. Preserve all saved data/models. Serialize enable/disable
transitions so overlapping reloads cannot leave duplicate workers or listeners.

## Data and model design

The benchmark architecture is a representative workload, not a selected final
policy. It uses four RGB frames at 160x120, 32 sensor and 32 control/state values
per frame, a spatial CNN and GRU, eight continuous outputs, and sixteen button
logits. These counts are placeholders, not the actual rover control schema.

- Past controls/current state are inputs; the human's next action is a training
  target. Avoid future-action leakage into model input.
- Maintain temporal coherence. Independent guesses can hesitate or oscillate;
  multiple human intentions must not simply average into meaningless controls.
- Continuous controls and discrete button/toggle events require different output
  semantics. Do not retrigger a one-shot action every inference tick.
- Include camera pose/state when available, and supported control capabilities.
- Preserve synchronized timestamps and sequence boundaries. Server receive time
  does not prove which frame the remote driver saw. Exact displayed-frame timing
  may need a small frontend timing hook; that is not yet designed or authorized as
  a settled integration requirement.
- Human takeovers/corrections are valuable demonstrations. Do not indiscriminately
  discard playful behavior: the goal includes human-like unstructured roaming.
- An action timeout/stale-video stop and existing hardware safety remain outside
  the model's learned decision-making.

Training proposal: shuffle windows from retained sessions, including recent and
older examples. Publish after a configured amount of training work, potentially
with a minimum elapsed interval. Steps/examples are less ambiguous than epochs
over a continuously changing dataset. Continue training independently of active
inference; published models are immutable and do not change beneath a session.

Background work should be resource-limited and lower priority. Pausing after
sufficient reuse of unchanged data is proposed; continuous repeated passes are
not automatically useful. A small reserve of older valuable sessions was suggested
to reduce forgetting but is not a settled retention requirement.

Training readers must not lose files mid-batch to retention. Publish checkpoints
atomically so clients cannot select partially written models. Store sufficient
architecture, feature/action schema, normalization, and training metadata to load
each permanent model correctly or report it as incompatible.

## Model catalog and UI mechanics

Proposed model names: `curious-otter-0042`, `amber-finch-0043`. Names are display
labels; stable unique IDs are used for selection and local favorites. Record
creation time, architecture/schema identity, training progress, and dataset
provenance/summary. Never assume a newer model is better.

Card scope: model selection with local favorites, Start/Stop, current session
status, and compact training status. Reuse current VIP appearance and existing
settings persistence rather than inventing a new storage layer. UI implementation
locations have not been inspected yet.

Illustrative single state object (not a finalized protocol):

```js
{
  available: true,
  roverId,
  control: { canStart, canStop, reason },
  session: { status, modelId, startedBy, startedAt },
  models: [{ id, name, createdAt, trainingSteps, compatible }],
  training: { status, examplesProcessed, latestModelId }
}
```

Derive per-user permissions on the server and recheck on execution. State updates
should be coherent and event-driven/coalesced, not broadcast at camera frequency.
The permanent catalog can grow; avoid blocking command handling while assembling
or delivering card state. Any future pagination must preserve the user's single
card-state contract rather than silently introducing independent UI data feeds.

Selection semantics proposed earlier: stop before switching an active model,
reset temporal state, and resume only explicitly. Confirm exact behavior as part
of UI design. Client favorites do not affect server retention or permissions.

## Hardware and measured feasibility

Actual server: Fedora 43, two Xeon E5-2620 v4 processors, 16 physical cores / 32
threads, AVX2, about 125 GiB RAM with 118 GiB available in the initial sample.
The server only runs the rover server. Approximately 80% CPU idle was measured
under normal working load, not on an otherwise idle test machine.

The relevant benchmark is the custom vision/control workload, not the earlier
Qwen text benchmark. Server run: Python 3.14.7, PyTorch 2.14.0+cpu, FP32,
488,008 parameters, four RGB frames at 160x120. Training batch size 16.

| Mode | Threads | Rover/training batch | p50 ms | p95 ms | Max ms | Examples/s | CPU cores used | Peak MiB |
|---|---:|---:|---:|---:|---:|---:|---:|---:|
| Inference | 4 | 1 | 5.8 | 8.0 | 16.5 | 165.43 | 3.97 | 321 |
| Inference | 4 | 2 | 10.4 | 13.6 | 24.1 | 187.39 | 3.96 | 334 |
| Inference | 4 | 4 | 18.7 | 25.1 | 34.1 | 207.08 | 3.96 | 357 |
| Inference | 8 | 1 | 4.4 | 5.9 | 12.9 | 219.98 | 7.95 | 318 |
| Inference | 8 | 2 | 7.5 | 9.2 | 13.2 | 272.28 | 7.95 | 330 |
| Inference | 8 | 4 | 15.3 | 17.5 | 26.0 | 263.88 | 7.81 | 359 |
| Inference | 16 | 1 | 4.9 | 7.3 | 23.1 | 191.94 | 15.77 | 318 |
| Inference | 16 | 2 | 7.5 | 10.9 | 21.0 | 257.54 | 15.76 | 333 |
| Inference | 16 | 4 | 11.6 | 17.9 | 33.6 | 319.84 | 14.98 | 359 |
| Training | 4 | 16 | 210.7 | 227.4 | 245.5 | 75.36 | 3.79 | 655 |
| Training | 8 | 16 | 141.2 | 172.8 | 176.5 | 108.57 | 7.09 | 673 |
| Training | 16 | 16 | 121.6 | 228.9 | 263.4 | 112.37 | 13.29 | 669 |

Inference latency is per entire batch, not per rover within it. CPU measurements
are saturation runs, not paced 10 Hz operation. Eight threads is a promising
starting point, not a finalized resource allocation. At 10 Hz there are 36,000
training windows per recorded rover-hour; one pass takes about 5.5 compute-only
minutes at eight threads. Dataset hours and repeat passes multiply that cost.

Limits: synthetic data/random weights, no decoding/resizing/network/dataset I/O,
no concurrent inference and training, and no measured autonomous driving quality.
The target of 10 decisions/second is provisional. A larger model or higher image
resolution requires renewed measurement. These results do not mandate a GPU.

Approximate storage for this architecture: 1.9 MiB FP32 inference weights; 5.6 MiB
for weights plus Adam optimizer state, before metadata/serialization overhead.
One hundred inference versions are about 186 MiB. Dataset video dominates storage.
Published inference artifacts and resumable training state need not be identical.

## Open implementation decisions

- Exact operating-control catalog, continuous/event action encoding, capability
  masking, selected sensors, model architecture/history, and update rate.
- Dataset disk budget, segment format, sampling strategy, session quality markers,
  and whether to retain a reserved historical subset.
- Time alignment between video observed by the driver and command generation.
- Python packaging, IPC, process supervision, CPU limits, and worker failure policy.
- Checkpoint cadence/names, resume-state retention, evaluation metadata, and how
  new versions become selectable. Do not add an unrequested admin approval flow.
- Exact ownership/takeover behavior, disconnect/turn-loss handling, model switch
  behavior, and which user may stop an active session under existing permissions.
- Card fields and existing client persistence mechanism; current UI paths still
  need targeted inspection.

## Implementation checklist

- [x] Discuss scope: autonomous roaming, full rover controls, no chat.
- [x] Add standalone CPU benchmark and verify its execution locally.
- [x] Obtain and interpret results from the actual server.
- [x] Record containment, default-disabled behavior, VIP placement, permissions,
  permanent model retention, client favorites, and single card-state requirement.
- [x] Obtain IPI for feature implementation.
- [ ] Inspect remaining UI/control paths and settle concrete contracts.
- [x] Add service-owned config and dormant lifecycle integration.
- [x] Add optional detailed command observer and shared checked submission path.
- [ ] Implement timestamped recording, video worker ownership, and bounded dataset.
  Code is implemented for common commands, raw/decoded rover sensor frames,
  host stats, and existing rover state events. Live video/timing/retention
  verification and full control-path inventory remain; do not mark complete yet.
- [x] Implement feature/action encoding and training worker with resource limits.
  Runtime import/dependency checks passed; training on actual recordings is still
  unverified. The current schema limits and next inference work are described below.
- [x] Implement atomic checkpoint publication and permanent model catalog.
  Code complete; no actual-data published checkpoint has been produced locally.
- [x] Implement model inference, ownership, explicit stops, and worker cleanup.
  Human input does not stop autonomy; live execution remains unverified.
- [x] Implement service socket gateway with complete per-user card state.
- [x] Implement verified VIP card at top, model selection, local favorites, controls,
  and expandable diagnostics. Browser appearance remains unverified.
- [ ] Verify disabled startup and enable/disable cleanup directly.
- [ ] Verify manual-control behavior remains intact and autonomous permission loss
  stops motion using an appropriate authorized runtime.
- [ ] Measure real video pipeline and concurrent training/inference on the server.
- [ ] Evaluate autonomous behavior with supervised rover runs before claiming
  useful driving performance.

Verification must follow user policy: no new/expanded tests unless explicitly
requested; use existing small relevant checks or actual affected runtime. Do not
automatically run full suites/builds. Hardware/server checks must be handed to
the user when the development environment cannot perform them.

## Handoff log

### First implementation increment

Implemented files:

- `server/src/services/roverLearningService/configuration.js`: default disabled;
  recording budget 20 GiB, minimum free space 2 GiB, session duration 300 seconds.
  These are initial implementation defaults, adjustable in the existing admin
  configuration editor, not measured final production sizing.
- `server/src/services/roverLearningService/index.js`: serialized lifecycle bridge;
  lazy runtime require; no recording side effects while disabled.
- `server/src/services/roverLearningService/runtime.js`: enabled-only subscriptions,
  recorder ownership, bounded startup/rotation event buffering, retention scheduling,
  disconnect/rotation handling, and signal/disable cleanup.
- `server/src/services/roverLearningService/recording.js`: per-session metadata,
  bounded NDJSON output, and FFmpeg RTSP/TCP video packet copy into Matroska.
  No camera re-encoding, Python process, training, or autonomous commands yet.
- `server/src/services/roverLearningService/storage.js`: oldest-first recording
  retention, free-space enforcement, and interrupted-session recovery.
- `server/src/services/commandService/recording.js`: optional failure-isolated
  request/dispatch/result/ack observer with payload snapshots and IDs. Source is
  `client` or `server`; browser automation is not falsely classified as proven
  intentional human action. Async safety timers do not retain client attribution.

External changes are limited to startup, configuration definition, command-hook
wiring, and adding the new feature to an existing configuration test's expected
feature list (required by the feature addition). No new tests were created.
Raw sensor capture reads `lastSensor.raw` during the existing synchronous sensor
event; rover manager/sensor pipeline did not need modification.

Recording format:

```text
recordings/<unix-ms>-<uuid>/
  session.json      Schema version, rover/session identity, timing description,
                    start/end/reason/error, loss count, video exit information
  events.ndjson    Unix ms + process monotonic ns, kind, data
  video.mkv        Original video codec; receiver wall-clock PTS retained
```

Request/dispatch/ack IDs let later training join requested and applied commands.
The recorded `source` is provenance, not proof of a correct demonstration.
Queued events preserve their observation timestamp; file order around a new
session's snapshot is not necessarily chronological. Sort by timestamps when
constructing training windows. Rotations can have video gaps; do not train across
session boundaries as if footage were continuous.

Limits and follow-up:

- Retention is checked every 15 seconds and is a soft disk budget, not a filesystem
  quota. Active files are closed before becoming eligible for pruning. Low free
  space pauses capture. Models/training paths are never traversed by retention.
- Record only rovers with a connected human driver who currently passes the
  existing control checks, including deterrence. Membership is required even for
  admins so an admin login alone does not record unattended rovers. Preserve pauses
  within an eligible human-control session. Driver/turn/mode/permission changes
  reconcile recording immediately; telemetry buffering uses the same eligibility.
  This supersedes the initial all-connected-rovers policy at the user's request.
  Autonomous sessions will need explicit exclusion/provenance when implemented;
  there are currently no autonomous controllers.
- Each event stream has a 2 MiB pending-write bound; startup/rotation buffering has
  a shared 4 MiB bound. Session loss counters/capture-gap events identify overload.
- Video timestamps represent packet receipt at this server, not the frame a human
  browser displayed. Actual FFmpeg output PTS still needs inspection on the server.
- Enabled recorders are stopped on disable and awaited; process-exit hooks kill
  surviving children. Existing MediaMTX shutdown can exit the whole Node process
  before async metadata flush finishes; next enable marks those sessions interrupted.
- Storage leases for concurrent training reads are pending with dataset sampling.
- Safe command submission extraction, autonomous provenance, model selection,
  client favorites, and UI remain pending. Training/catalog code follows below.

Verification completed:

- `node --check` on new recording/lifecycle modules and modified command service:
  passed (repeat only for subsequently changed modules as needed).
- `node --test server/src/configuration/configuration.test.js`: 14 passed, 1 failed.
  The failing pre-existing default-values assertion omits
  `$.discord.channels.liveStatus`; the current HEAD already defines it as empty.
  New configuration validation, descriptions, normalization, and feature flags
  passed. Leave the unrelated Discord assertion untouched.
- Direct disabled service startup with a disposable `SERVER_DATA_DIR` returned
  `{"runtimeLoaded":false,"storageCreated":false}` and exited normally. Temporary
  configuration storage was removed. No development service was left running.
- Local FFmpeg help confirms the RTSP transport and timeout options used.
- No full build, full lint, new tests, live server startup, or rover hardware run.

Optional server verification reference (user declined doing this checklist;
do not require it before continuing implementation):

1. Deploy normally, initially disabled; confirm no `rover-learning` directory or
   learning FFmpeg workers are created by a fresh disabled startup.
2. Enable `roverLearning.enabled` through the existing admin configuration. An
   online unattended rover must not produce recordings. Take human control and
   confirm session files appear beneath the actual data mount; pauses should keep
   recording. Release control/disconnect the last eligible driver and confirm
   capture stops. Repeat across turn changes and mode/permission changes.
3. Drive, move the camera, and operate accessories. Check that event records contain
   requested and dispatched payloads with matching IDs, sensor frames, and host stats.
4. For a completed session, inspect video with:
   `ffprobe -v error -select_streams v:0 -read_intervals '%+#3' -show_entries packet=pts_time,dts_time -of json /actual/session/video.mkv`.
   Compare packet timestamps (seconds) with event timestamps (milliseconds).
   Report FFmpeg/session errors rather than assuming timestamp alignment is correct.
5. Disable: confirm owned FFmpeg processes exit, session metadata closes, no further
   writes occur, and saved recordings remain. Re-enable to check clean restart.
6. Verify rotation and retention with an intentionally chosen small recording
   budget, and confirm manual driving remains responsive during recording.

Actual server capture/timing and live cleanup remain unverified. These steps are
a reference for future runtime investigation, not a pending request to the user.

### Dataset/training/checkpoint increment

The user supplied IPI, then asked to continue after a rate-limit interruption.
Authorization remains in effect. Implemented:

- `workers/policy.py`: fixed-size spatial CNN/GRU with 64 action-shape slots and
  up to 8 numeric output fields per shape. Four 160x120 RGB frames, spaced roughly
  300 ms apart, with 32 selected sensors plus missing-value masks and previous
  command values/ages/known flags. About 805k parameters (larger than the benchmark).
- Numeric controls are normalized with `2/pi * atan(value/scale)`; the model
  produces per-shape event logits and numeric values for the next 100 ms.
  Command types supported: drive, motors, servo, headlight, laser, horn, peripheral,
  song, raw. Strings/bools/arrays remain exact template constants; variable-size
  songs/raw OI payloads are discrete demonstrations, not generated arbitrary bytes.
  Maintenance commands, audio/text and sensor-stream setup are not action targets.
  All recordings remain intact until normal dataset retention, regardless of
  whether the trainer can use their commands.
- The schema grows only into unused fixed slots and is saved with each model.
  Overflow (64 shapes/8 numeric fields/4096-byte commands) skips the affected
  recording with a reason instead of silently truncating controls. This is a
  concrete initial encoding limit, not a promise to represent unlimited hardware
  or arbitrary song libraries. Revisit it if real recordings exhaust capacity.
- `workers/dataset.py`: bounded event loading (64 MiB/session), PyAV decoding,
  absolute timestamp checks, causal sensor/action history, accepted-client-command
  targets, and masks for observed action slots. Actual measured wheel speeds are
  among the selected sensor inputs. Missing/stale sensors, video gaps, clock shifts,
  incomplete recordings, data loss, and ambiguous conflicting actions are excluded.
  Server-generated control overrides are history/boundaries, not demonstrations.
- Validation is automatic and cannot establish what frame a browser displayed.
  A session is only accepted after its video finishes decoding; samples from a
  subsequently corrupt session are discarded. Commands/sensors at future times
  do not enter observation history.
- `workers/train.py`: finite CPU jobs, lower OS priority, shuffled bounded reservoir
  sampling, sparse-event classification plus masked numeric regression, gradient
  clipping, finite-loss checks, and AdamW resume state. Never sends rover commands.
- `training.js`: one owned worker, recording leases acquired within serialized
  maintenance, bounded stdout/stderr, interval and wall-clock limits, shutdown,
  persistent per-recording visit/rejection ledger, and progress state for the
  future card. Retention protects leased recordings. Disk pressure cancels the
  training job before files become eligible for pruning again.
- Atomic `training/resume.pt` includes model and optimizer state, schema, cumulative
  steps/examples, and publication progress. Permanent model directories are
  atomically renamed into visibility with weights and metadata together.
- `models.js`: reads the permanent metadata catalog. Each model has a UUID, two-word
  generated name plus UUID suffix, creation time, steps/examples, schema, source
  session IDs, trained rover IDs, training loss, parameter count, weight hash/size,
  and `evaluation: unevaluated`. No model pruning, favorites, or server pin state.
- Dockerfile packages a CPU-only Python venv at `/opt/rover-learning` during image
  build. Pinned requirements: torch 2.14.0+cpu, NumPy 2.5.3, PyAV 18.1.0. No runtime
  downloads/installers. A disabled service does not load or run these dependencies.

Training defaults beneath `roverLearning.training`:

| Setting | Default |
|---|---:|
| enabled (still gated by outer service enabled=false) | true |
| threads | 8 |
| batchSize | 16 |
| maxSamples / minimumSamples | 1024 / 128 |
| passesPerJob | 2 |
| minimumDrivingMinutes / newDrivingMinutesPerModel | 30 / 10 |
| maxStepsPerJob | 200 |
| checkpointEverySteps | 1000 |
| intervalSeconds | 60 |
| maxJobSeconds | 600 |

Defaults tuned to the user's dual E5-2620 v4 server benchmark: eight training
threads improved throughput substantially over four, while sixteen gave little
additional benefit. The larger sample pool and shorter interval are starting
choices for its available resources, not measured learning-quality improvements.
Inference remains four threads per rover. Existing explicit configuration values
override these defaults; this change does not rewrite deployed configuration.

At most four completed retained sessions are selected per job. Samples are spread
over each full video via reservoir sampling, not always taken from its beginning.
The prior three-visit limit is removed. Retained usable training sessions remain
eligible for repeated sampling; finite jobs still yield between runs.
Candidate publication happens at job boundaries after data, step, and held-out gates;
it does not automatically deploy a model. No all-no-action sample pool is trained.

Container rebuild is needed to include Python packages. For a non-container
deployment, install `workers/requirements.txt` into a dedicated venv and set
`training.python` to its Python path. The default path is container-specific.

Verification performed in this increment:

- Installed the actual pinned requirements in `/tmp/rover-bench-check-env`.
- Ran the production worker's `--check-dependencies`: PyTorch/PyAV/NumPy imports,
  dataset imports, policy construction, and specification output succeeded.
- Four existing focused configuration tests passed (defaults, descriptions,
  generated feature paths, normalization). The unrelated prior Discord default
  assertion was not rerun or changed.
- Node syntax checks on scheduler/runtime/catalog passed.
- No new tests, fake recording fixtures, or throwaway test programs were created.
- No real recordings are available locally. Actual decoding/alignment, optimizer
  execution against recordings, checkpoint publication/resume, and concurrent
  server performance are not claimed verified. No full container build was run.

The following controller/UI increment implements those remaining code paths.
Real-data and live-hardware verification still remain before claiming usable autonomy. The initial model is an experimental imitation policy, not a demonstrated
competent driver or a final architecture choice.

When resuming after implementation begins, append concrete changed files, commands
run/results, unresolved failures, decisions approved by the user, and the next
bounded task here. Do not mark a checkbox complete merely because code exists;
record verification limits and outstanding server/hardware work explicitly.


### Controller and VIP card increment

- `commandService/index.js` exports the existing checked handler as `submitCommand`;
  browser behavior remains in the same handler. Recording distinguishes model
  requests from human requests without changing command payloads.
- `driving.js` owns per-rover CPU workers under the initiating live socket's
  permissions. Explicit Stop, permission/connection loss, stale predictions, or
  worker failure stop the session and send zero drive/motors and horn stop.
  Human commands deliberately neither stop nor pause the model.
- `workers/infer.py` consumes live RTSP/TCP video plus sensor/command observations,
  uses the training history format, validates weights/specification, resolves
  competing command families, and latches discrete actions. It never writes to
  the rover directly. Driving defaults: four CPU threads, 0.7 action threshold,
  2000ms stale limit, with a 30-second worker startup allowance.
- `capabilities.js` matches recorded hardware control profiles against the target
  rover. Recordings, resumable training state, and published manifests preserve
  those profiles; models without a matching profile are not selectable for Start.
- `runtime.js` excludes autonomous sessions from human demonstrations, manages
  controller shutdown, and supplies bounded recent activity and storage state.
- `socketGateway.js` emits one complete authorized card object every second to
  subscribers, refreshes the permanent catalog every 15 seconds, and accepts
  checked Start/Stop actions. No server-side favorites are stored.
- `VipRoverLearningCard.jsx` is at the top of the verified VIP tab, gated by the
  service feature flag. It uses existing CardFrame, field/button/surface styles;
  favorites use browser settings. Its expandable section includes storage,
  recording sessions, dataset rejection reasons, training progress/resource
  limits, model size/loss/control count, inference timing, last action, and events.
- Verification: focused ESLint on the new card and VipPanel passed; four existing
  configuration tests passed. The live worker's actual `--help` entry point loaded
  PyTorch/PyAV/NumPy successfully. Shared-handler diff reviewed with whitespace
  ignored: extraction preserves the previous command handler logic.
- No real dataset, checkpoint, camera stream, or rover was available locally;
  end-to-end inference/training and browser rendering remain unverified. No new
  tests or background processes were added for verification, and no full build
  or full test suite was run.


### Dock capture, live diagnostics, and publication correction

Authorized by IPI after the user reported idle dock recording, many premature
models, silent controllers, and training stopping after a few jobs.

- VipPanel now renders only `<VipRoverLearningCard />`; the card owns feature and
  verification gating, rover selection context, and grid wrapper. The user's
  pre-existing card edit was preserved.
- Human docked sessions maintain disposable packet-copy video segments and a
  bounded five-second event buffer. Segments are keyframe-aligned (target two
  seconds); old closed segments are pruned, with an extra edge segment retained
  for decoding. Undocking promotes the buffer and sets trainingStartedAt to five
  seconds earlier. After docking, recording closes after five seconds (250ms
  polling granularity) and returns to buffering. Never-undocked buffers are
  deleted on close/recovery and never offered to training. Disk retention still
  applies. The reader handles chronological segments and filters the lead-in
  boundary; no RTSP restart is needed to promote a dock buffer.
- The service still excludes autonomous sessions and still requires an eligible
  human. Human input does not stop or pause autonomy.
- Expanded card diagnostics opt into complete volatile snapshots at 10Hz;
  collapsed cards receive 1Hz. Predictions include all known command shapes,
  scores, decoded controls, below-threshold/competing/latched reasons, and actual
  submission results. "Predicting no new action" is separate from worker running.
- Removed roundsPerSession from configuration and scheduling. Completed usable
  recordings remain eligible indefinitely within rolling retention. Jobs remain
  finite, lower-priority, and separated by the configured interval. Waiting and
  publication reasons are visible in the card.
- Default publication gates: 1000 optimizer steps, 30 distinct usable training
  minutes, and 10 additional distinct minutes since the previous publication.
  Usable minutes count enumerated aligned 100ms windows once per training session,
  not repeated optimizer exposures; only a reservoir is used in each job.
- Entire sessions are deterministically partitioned 80/20 by session-ID hash.
  Held-out sessions never supply gradient updates or new command vocabulary.
  Evaluation requires at least 128 windows and 32 positive events, precision and
  recall >=0.5 at the configured action threshold, and normalized numeric MSE
  <=0.1 with numeric targets present. These are initial imitation gates, not proof
  of autonomous competence. Evaluation uses the current job's held-out reservoir;
  jobs with no usable held-out cohort cannot publish.
- Fresh `training/resume-v2.pt` prevents old training exposure contaminating the
  new validation split. Existing published models and old resume.pt are preserved.
  New checkpoints retain optimizer progress even when publication is blocked.
- Deployment config: migration 3 automatically removes the obsolete
  `training.roundsPerSession` key from saved revisions before startup validation. Set `checkpointEverySteps: 1000`, `minimumDrivingMinutes: 30`,
  and `newDrivingMinutesPerModel: 10`; saved values override changed defaults.
- Verification: four focused configuration tests passed, modified Node entry
  points passed syntax checks, targeted VIP ESLint passed, and the production
  training dependency entry point loaded the policy and segmented dataset reader.
  No fixtures/test files, full builds, or background servers were created.
- Still unverified on this development machine: live RTSP segment timestamps and
  dock transitions, actual optimizer/evaluation/publication runs on recordings,
  browser appearance/live updates, and real autonomous behavior. Do not claim
  these checks passed or that the existing event-based policy now drives well.


### Startup regression repair

The actual server crash reported CONFIG_VALIDATION_FAILED for the removed
roverLearning.training.roundsPerSession field. Added configuration database
migration 3 to remove only that obsolete key from all saved revisions before
startup validation. Other settings remain intact; normal default filling adds
new fields. No manual database/config edits are required. Existing focused
migration and normalization tests passed (2/2); production restart is unverified.


### Continuous wheel policy and copyable diagnostics (latest IPI)

Requirements: learn solely from ordinary use. Never require prescribed routes,
exercises, or demonstrations. Keep eight training threads until actual timings
justify changes. No artificial model-size increase. Manual controls still do not
stop or pause the controller. Keep card layout in the existing feature-card stack.

Implemented:
- Policy format 2 adds an independent two-value tanh wheel head (805,234 total
  parameters), scaled to +/-500 mm/s. Accessory event/value heads remain separate;
  drive command shapes remain causal history inputs but are masked as event targets.
- Dataset reconstructs accepted human wheel intent at frame time +100ms, using
  dispatched wheel values, explicit zero stops, and the recorded hardware limit
  when available. Inspection of roverd dispatch found persistent wheel commands,
  not a short wheel-command expiry timer. Permission boundaries, server overrides,
  failed/ambiguous drive commands and raw/mode/system changes invalidate wheel
  intent until another accepted human drive. Uncertain windows are excluded.
  Raw OI controls are consequently not reliable trainable events in this revision;
  their effects require dedicated decoding before relaxing that exclusion.
- Four bounded training reservoirs preserve stopped, forward, reverse and turn
  examples without requiring humans to behave differently. Held-out reservoirs
  remain uniformly sampled and entire sessions retain deterministic partitioning.
- Loss reports separate wheel, accessory-event and accessory-value components.
  Held-out wheel MAE is compared with stopped-wheel and previous-command baselines,
  with separate error on actual wheel changes. Publication needs >=128 evaluation
  windows, >=32 moving and >=32 changed windows, improvement over stopped and
  changed-window persistence baselines, and overall error no worse than persistence.
  Accessory precision/recall gates remain when events exist; absent accessory
  events must not produce false positives. These remain experimental imitation
  criteria, not proof of autonomous competence.
- Existing footage can be reused. New learning state is resume-v3.pt and
  schedule-v3.json, preventing old-shape weights or stale rejection ledgers from
  being reused. Existing published files remain untouched and visibly marked as
  older format/incompatible. New compatible models are required to start driving.
- Live inference emits a wheel command every decision, independent of the accessory
  threshold. Server clamps wheel values to hardware limits through the unchanged
  shared authorization path. Start/Stop and manual-input behavior are preserved.
- Main card shows centered signed wheel bars, accessory score/status bars and a
  session-local threshold slider (0.05..0.99). Only users with current rover control
  can adjust it. Worker receives settings over its existing stdin channel; desired
  and applied thresholds are separately observable. Active controllers get 10Hz
  snapshots even when details are collapsed.
- Copy diagnostics exports compact reportVersion=1 JSON from the same complete
  card object. It includes application version, service-source SHA256 fingerprint,
  policy version, settings, host load/memory, dataset timing/availability counters,
  separate losses, baseline evaluation, decode/train/evaluation/checkpoint timing,
  CPU seconds and peak RSS, publication blockers, 20 job summaries and up to 30s
  of controller history sampled at 2Hz (top eight action scores per entry).
- Reports use an explicit allowlist: no socket IDs, nicknames, rover IDs, filesystem
  paths, raw video, credential-bearing URLs or raw command templates. Errors are
  categorized rather than copying potentially sensitive arbitrary exception text.
  Browser video latency and actual physical command execution are explicitly
  unavailable. Diagnostics payloads are sent only while details are expanded;
  active action visualization remains live in the main card.
- Clipboard failure exposes a selectable compact report instead of silently failing.
- No recorded dataset exists under this checkout's server/data/rover-learning.
  Production worker dependency/entry-point checks succeeded; policy construction
  reports 805,234 parameters. Targeted card ESLint and Node syntax checks passed.
  Actual optimizer execution, held-out results, RTSP inference, clipboard/slider
  behavior and browser appearance remain unverified here. No new tests, fake data,
  or background development processes were created.

Next: use real diagnostic reports to assess timing, sample rejection, target
coverage and baseline performance. Do not infer competence from lower training
loss or increase architecture size without that evidence. If training was disabled
through the configuration UI, the operator must re-enable it to train this policy.


### Ongoing learner and administrator snapshots

Authorized by the latest IPI. Training continues from the same resume-v3.pt;
no new training reset or configuration migration is required.

- Each completed training job exports immutable weights/metadata beneath
  training/checkpoints/<uuid>. A serialized Node catalog atomically updates
  index.json with candidate, latest, and previous pointers after worker exit.
- Existing data/step/evaluation gates govern Latest promotion. Previous retains
  the former Latest. Candidate tracks the latest completed learner even when
  those gates fail. No automatic permanent named-model creation remains.
- The model picker exposes Latest and Previous alongside existing permanent
  snapshots. Running sessions acquire a checkpoint lease and keep their original
  weights; promotion does not reload them. Retention removes superseded automatic
  checkpoints, with leased ones removed after their running session closes.
- Admin-only Save learner snapshot copies the candidate atomically to a new
  permanent two-word/UUID model directory, carrying its evaluation and source
  checkpoint ID. Candidates without a passing evaluation are labeled experimental.
  Non-admin requests are rejected server-side. Normal rover-control permissions
  still apply when starting any model. Existing models/favorites remain intact.
- Source fingerprints and controller diagnostics include the pinned checkpoint ID.
  Configuration field names are unchanged; descriptions now refer to Latest
  promotion rather than permanent publication. Permanent snapshots are never pruned.
- Focused Node syntax and Python worker entry-point checks passed. Targeted card
  lint is run for the UI change. End-to-end training/promotion, snapshot copying,
  active-session pinning and browser behavior remain unverified without live data.


### UI cleanup and obsolete models

User explicitly requested removal of UI narration and deletion of obsolete models.
Removed snapshot/threshold explanatory prose and the old commented manual-control
note; idle status now says Stopped. Kept operational status/errors and diagnostics.
Enabled-service startup now deletes permanent model directories whose validated
manifest explicitly identifies policy format 1, even when training is disabled.
Format 2 snapshots, Latest/Previous, recordings and current training state remain.
This supersedes earlier promises to preserve incompatible format 1 model files.
Deletion occurs on the actual server when the updated service starts; no production
files were accessed from this development machine.


### Recording maintenance race and diagnostic error details

Authorized by "fix it and fix that IPI" after a production report showed two
maintenance failures but omitted their error details. Scoped to those two defects;
evaluation/cache changes remain proposals, not part of this repair.

- listRecordings now tolerates ENOENT for directories/files removed between listing
  and stat (dock-buffer pruning or atomic metadata rename). Other filesystem
  errors still propagate; no broad error suppression or retries were added.
- Diagnostics reportVersion 2 includes actual redacted error messages, rejection
  reasons, controller results, event detail, and worker stderr. Runtime catches
  retain error name/code/syscall/path/stack, timestamp and operation. Recording
  failures retain the same structured details through session finalization.
- A shared redactor removes URLs, credentials, user keys, email addresses and home
  usernames while retaining filesystem operation context and stack frames. Error
  categories remain supplementary, not replacements for actual failures.
- Node syntax checks passed for affected modules. No actual production recording
  stream is available here; the race is fixed by inspection but cannot yet be
  confirmed as the cause of the earlier production events. Previously discarded
  error details cannot be reconstructed. No new tests or processes were created.

### Deliberate held-out selection

Latest IPI authorizes the scheduler correction only. Randomly shuffled eligible
sessions are now partitioned with exactly the worker's SHA256 first-eight-hex
modulo-five rule. Jobs select up to three training sessions and one held-out
session when both partitions exist; otherwise up to four training sessions.
No worker starts with held-out sessions alone. Existing split assignments, model
weights, and training progress are unchanged. Diagnostics expose timestamped
available/selected partition counts and the reason when evaluation cannot be
scheduled. Selection guarantees a held-out recording, not usable evaluation
windows: decoding/vocabulary/sample checks still apply in the worker.
Node syntax checks and diff whitespace checks passed; actual job selection on
production recordings remains unverified. No new tests or background processes.

### Active implementation: command-event policy (authorized IPI)

Supersedes format 2 continuous wheel output. The model predicts numeric command
scores and payload values; ordinary code constructs commands for the existing
shared command pipe. It does not generate JSON text. Drive, recorded key-release
stops, and accessories all use the threshold. Remove wheel-speed sensors and
previous drive-command inputs, but preserve raw recordings. Exact zero values
remain template constants so a demonstrated stop cannot regress into creeping.

Keep one continuing learner, Latest/Previous, admin snapshots, recording lifecycle,
permissions, and manual inputs that never cancel autonomy. No prescribed human
driving. Start a new format 3 lineage, reuse recordings, show older snapshots as
incompatible. No model-size increase or recording redesign in this change.

Update the upper card to show every command proposal with decoded parameters,
score, threshold marker and dispatch result, including below-threshold proposals.
Update copied diagnostics and evaluation for command events, parameter error,
missed stops and unwanted commands. Evaluate more than one held-out recording;
event validation is not proof of autonomous driving or physical rollout quality.

Progress: implemented; focused checks passed. User's unrelated webui/package.json
edit was preserved. No changes to runtime recording, disabled startup, control
permissions or manual-input override semantics.

Implementation details for resume:
- workers/policy.py VERSION=3, CNN/GRU unchanged in size; two heads for scores and
  command parameters. Shared select_slots chooses one winner per command family
  (peripheral id/control are separate families). No unconditional drive head.
- Numeric zeros and address fields stay exact template constants. Stop is the
  normal recorded driveDirect {left:0,right:0} command. Unknown templates still
  reject explicitly at the 64-shape limit. Arrays remain exact demonstrations.
- workers/dataset.py yields five arrays: images, state, event labels, parameters,
  available shapes. It includes accepted human drive events, excludes ambiguous
  conflicting events in the same 100ms window, and no longer requires an inferred
  held wheel-speed target. Raw recorded sensors/commands are unchanged.
- Training reserves separate bounded samples for stop events, other commands and
  no-command windows. Evaluation remains uniformly sampled. Scheduler selects
  up to three training and two held-out recordings under the unchanged SHA split.
- Gate: complete evaluation, >=2 usable held-out sessions, >=128 windows, >=32
  command events, >=8 stops, >=16 movement events; command precision/recall, stop
  recall and movement recall each >=0.5; normalized numeric MSE <=0.1 where
  applicable. Diagnostics expose each failing reason and per-command counts.
  These are experimental screening thresholds, not a guarantee of useful driving.
- New optimizer/scheduler filenames prevent silently reusing format 2 weights or
  old rejected-session bookkeeping. No config values need changing. Existing
  permanent format 2 snapshots are preserved, but cannot start; attempting to
  snapshot an old candidate reports that a new command-policy checkpoint is needed.
- Live inference keeps existing discrete toggle latching and common command limits.
  The threshold applies to drive and stop just like the other command predictions.
  No-event means send nothing: it DOES NOT implicitly stop an already moving rover.
  It must learn explicit stop events; removing the copy shortcut is not proof that
  learning will succeed. Other motion-related sensors still remain as observations.
- Upper card replaces separate wheel meters with generic scored proposals and
  decoded parameters; shows applied threshold and post-clamp submitted parameters.
  Copied diagnostics retain top eight proposals and up to 16 submissions per
  sampled controller-history entry, including their command objects.

Verification: actual train.py --check-dependencies loaded Torch/NumPy/PyAV and
constructed format 3 (803,440 parameters); infer.py --help loaded successfully;
Node --check passed for six changed service modules; targeted card ESLint passed.
No new tests or throwaway programs. Live end-to-end training/inference and browser
visual verification require the actual environment and have not been performed.

Deferred explicitly: chronological commanded-motion replay/closed-loop evaluation,
prepared frame caching and larger architectures. Current evaluation uses held-out
100ms event windows with the live threshold/family selection, but cannot assess
temporal latching or accumulated motion from random reservoir samples. It does
not claim to verify actual physical command execution. After normal deployment,
let the new learner process retained recordings; copied reportVersion 3 diagnostics
provide the next evidence. Do not demand prescribed driving or a manual checklist.

### Obsolete model cleanup after format 3 transition

Latest user IPI explicitly authorizes deleting obsolete snapshots, checkpoints and
training state. This supersedes earlier format 2 preservation notes above.
Enabled-service startup, before trainer/driving/gateway startup, scans both models/
and training/checkpoints/. Identity-validated manifests with integer policy version
>=1 and < current POLICY_VERSION are removed. Current/future/unknown-format models
and recordings are preserved. Candidate/Latest/Previous references to obsolete
checkpoints are atomically removed before directory deletion; leased directories
are retired until release. Cleanup also removes legacy resume/schedule files and
temporary files for the unversioned and v1-v3 lineages. Current v4 state is kept.
Cleanup runs even when training is disabled, but not when the whole service is off.
Production deletion occurs on the next enabled-service startup after deployment.
Verification: focused Node syntax and diff whitespace checks passed. No production
storage was accessed; actual deletion awaits enabled-service startup on the server.

### User-control scope and evaluation coverage (2026-09-29)

Authorized by latest IPI after user clarified that controls include camera, brushes,
lights, laser, horn and songs but NOT generic peripherals. No new command pipe or
separate stop command. sensorStream is neither input/target nor a boundary. Actual
reset/reboot/update remain temporal boundaries because they interrupt observations.

Format 4 seeds drive and motor zero/nonzero field combinations, servo, light/laser
actions, the two four-frequency horn waveforms and horn release, OI start/safe/full/
dock bytes and default song. Seed values describe shapes, not artificial training
examples. Horn frequencies are numeric parameters; integral JSON numbers share
shapes with equivalent floating representations for drive/motors/servo/horn. Songs
remain exact demonstrated note arrays; other song/raw variants can extend the
training schema within its existing 64-slot bound. No promise to pre-enumerate all
possible tunes. Seeded slots receive negative examples even in sessions where that
control was not used, avoiding untrained random seeded outputs.

Evaluation freezes the training schema. Unsupported commands are reported with
payload, reason, occurrence count (up to 32 distinct descriptions), total count and
affected-window count. The affected observation history/target interval is excluded
without labeling the unknown command as inaction or skipping the entire recording.
Any unsupported held-out command blocks promotion; metrics describe only supported
windows. If none survive, dataset diagnostics still report the coverage problem.
Existing permission checks, threshold mechanics, recording and manual input behavior
are unchanged. Generic peripherals are also removed from execution allowlist and
rover compatibility profile. Previous policy models are automatically cleaned up;
no configuration edit is required.

Verification completed: train.py --check-dependencies loaded the production
worker and constructed format 4 with 803,440 parameters and predefined command
shapes. infer.py --help, Node syntax checks for the four changed service modules,
focused VipRoverLearningCard ESLint and diff whitespace checks passed.
No live server data/hardware/browser available locally. Actual training, driving,
and browser appearance remain unverified. No new tests or background processes.
Deploying starts a new learner using existing recordings; enabled-service startup
removes older policy models and optimizer/scheduler lineages through v4. Current
lineage is v5. No settings changes or prescribed human driving are required.

### Simplified controls, policy 5

User authorized removal of horn/song/laser/brush motors. Retained 13 seeded shapes:
four drive zero/nonzero combinations, two camera angle shapes, three headlight
actions, four raw operating-mode/dock constants. Generic peripherals remain excluded.
Removed excluded command history/targets via policy allowlist and execution via
Node allowlist; raw payloads must exactly match one of the four mode commands at
both boundaries. Controller shutdown now sends only zero-speed drive, leaving
manual brush/horn state alone. Raw recording and sensor telemetry unchanged.
Old policies are deleted on enabled startup; resume-v6.pt/schedule-v6.json begin a
fresh learner using retained recordings. Existing evaluation behavior unchanged.
Verification passed: production train.py --check-dependencies (policy 5, 13 seeded
shapes), infer.py --help, changed Node module syntax, focused card ESLint, and diff
whitespace checks. No live hardware/data available locally; actual learning and
driving quality remain unverified. No tests added or background processes left.

### Active full learning-path audit (authorized IPI)

User explicitly permits local training/inference with controlled synthetic input;
there are NO real recordings on this machine. Existing user-control simplification
edits were present at start and must be preserved. No new schema reset is planned.

Reproduced: production reader with a generated lossless 25 FPS video and 31 valid
human drive events labeled ZERO commands. Old sampler used 120ms frame intervals
with only 100ms target coverage. Fixed causal 100ms grid shared by dataset/inference
uses latest past image; no future pixels. The repaired fixture preserves all 31
commands. Sensor cutoff is strictly before decision in both paths.

Original objective experiment: 12 easy colored-frame samples, 120 steps, seed 7,
4 threads: loss 0.8206 -> 0.1996, mean true-command score 0.5106 -> 0.7268, recall
at 0.7 reached 2/3; at 80 steps recall was still zero. This disproves a wholly
broken gradient path; it does not diagnose real-data score suppression. Keep
existing loss/threshold until real-data diagnostics justify changing them.

New learning.py shares the actual objective for ongoing training and disposable
probe. Per-job before/after evaluation on <=96 unchanged training examples, full
held-out score distributions, threshold sweep, training-only frequency and no-op
baselines, decoded pre-server-limit parameter error, gradient norms and sampled
versus natural frequencies. Bounded <=20s/80-step memorization probe on <=12
training examples at first job/every 1000 steps; copy only, never published or
used for generalization gate. Continues current checkpoint/optimizer lineage.

Audit results (synthetic only):
- Round-tripped eight representative retained command payloads, including signed
  drive/servo values, zero-speed drive, headlight and all four mode commands.
- Lossless 25 FPS recording with 31 command events: old sampler labeled 0; new
  sampler labeled 31/31, including interleaved ignored sensorStream events.
- Full production train.py decoded five generated recordings, trained/exported
  checkpoints, evaluated held-out sessions, and resumed optimizer/weights for a
  second job. 120 -> 240 cumulative steps improved recall at unchanged 0.7 from
  0 to 0.2553, with precision 1.0 at step 240. Mean true-event score rose 0.5346
  -> 0.6303. Gate correctly remained failed. A lower 0.5 threshold had precision
  0.6629/recall 0.8369 and 120 false-positive actions, so threshold was NOT lowered.
- Disposable diverse probe covered zero-speed drive, moving drive and servo;
  reached recall 0.75 after 39 steps under its 20s budget. Sampling was corrected
  to avoid probing only the first event category. Probe uses a copy and higher
  learning rate for memorization; never adopts weights or changes main optimizer.
- Exported trained checkpoint reload, forward inference and decoding passed.
- Retained recordings had extra removed actuator fields, causing false model
  incompatibility. Normalize saved and current profiles through controlProfile.
  Direct Node exercise accepts removed laser/peripheral differences and still
  rejects a changed retained camera configuration.

Diagnostics now report accepted vs represented command counts, request/dispatch
delay, maximum sensor/image age; sampled vs natural command frequencies; gradient
norms; same training-subset before/after scores; per-command score distributions;
threshold sweep and no-op/training-frequency baselines; pre-server-limit decoded
parameter errors; and bounded diverse memorization probe. Evaluation-step identity
separates last evaluation from current-job progress. Compact history avoids
repeating entire command/score tables for every job. Four concise numeric rows
were added to expanded details; full evidence is in Copy diagnostics.

The original loss and configured 0.7 threshold remain unchanged because experiments
did not establish that a different objective/threshold fixes real recordings.
Promotion keeps existing checks and additionally must beat the simple training-
frequency baseline F1. One-time retry of old reader-specific no-aligned-window
rejections preserves optimizer state and unrelated errors.

Limits: actual human footage and rover/RTSP transport unavailable. Isolated held-out
windows cannot measure sequential latch behavior or physical driving; decoded
parameter errors are explicitly before Node's rover limits/permission/safety
handling. Main model learned some synthetic cues but has not demonstrated useful
autonomous driving. Camera command encoding still uses whole-degree predictions.
The user must not be asked to drive prescribed routes or perform a manual checklist.

Verification: full synthetic worker jobs and checkpoint inference above passed;
focused Node syntax/card ESLint/diff checks passed before final report additions.
One experimental seeded run failed because its runpy launcher omitted worker
import path; corrected launcher succeeded. No production import failure occurred.
Synthetic inference-worker media exercise passed: eight prediction batches,
threshold update to 0.3, retained command types and discrete latching exercised.
This check used a generated checkpoint and a FIFO media adapter preserving
synthetic PTS (RTSP wall-clock override disabled in the experiment only); it does
not validate real network capture timing. Trained checkpoint forward/decode was
verified separately. Temporary media launchers needed fixes for file lifetime
and command-string escaping; these were experiment issues, not production fixes.
No repository tests added. Experiments finished and no background worker remains.
Final focused Node syntax and diff whitespace checks passed. Card lint passed.
No additional schema/optimizer reset introduced by this audit.