Teaching the suite to recover its own devices

A virtual device can outlive the window that created it. If the app quits unexpectedly or an extension finishes activating late, the next launch still needs to understand what belongs to the suite and how to stop it safely. The first October 5 candidate concentrated on that recovery problem.

A durable resource journal recorded ownership before persistent creation. Startup discovered the app's cables, cameras, network managers and mounted images, exposing recovery and Stop actions. Cancellation and late callbacks were tied back to the original request instead of being allowed to create an unexplained leftover resource.

Audio installation became an atomic, validated operation with rollback. The helper checked the actual staged signed bundle, preserved unknown or unsigned installations and restricted its operations to the suite's own bundled cables. Replacing a cable can interrupt system audio, so that action needs to be explicit and bounded.

Storage gained similar care. New images used unique default paths, reuse required a matching app-created image and configuration, and ordinary files were rejected without overwriting them. Cleanup didn't force-detach an image just to make the interface look finished.

Product-specific ownership verification and bounded offline access were added as well, while Stop and cleanup stayed available without a license. That matters when someone needs to remove a device after access expires.

The 26.10.5.1 record includes 47 strict app tests, 18 backend tests and notarized package checks. It was a candidate with commercial and runtime acceptance still open at that stage, including HID approval. The following October 5 revisions addressed more of those gaps; this chapter records the safety foundation they built on.