One inspection described a VR menu leading to a black view and a loading indicator. The starting HTML can open correctly while its runtime or scene files remain unavailable. Treating the move as a transfer of one screen is insufficient to preserve those dependencies.
The records contain separate checks of the launch document, runtime script, scene XML and preview images. Historical template tests also retain rules for a dedicated VR path and preservation of the starting file’s relative directory. I read menu availability, package completeness and actual exploration as distinct results.
An open launch file does not establish an available scene
A launch document loads a runtime and locates descriptions and image resources for its scenes. A successful first response does not mean every later request succeeds. The original issue report also identified a missing runtime request. Looking for the cause of a black view only at its first address can miss the relevant connection.
I compare what the document requests with the folders actually retained. I check whether the scene list exists and how the initial scene and preview paths are resolved. Matching names and relative placement matter more than merely counting files. Mixing runtimes from different versions is another decision that requires evidence, not an automatic repair.
Preserve the dedicated path and relative structure together
The archived template checks address both a dedicated placement for the VR package and the launch document’s relative directory. Flattening folders or moving only the starting file changes the base for relative requests. That is why the package cannot simply follow the cleanup rule used for unrelated website images.
After relocation, requests need to be checked at the new destination. The launch page and runtime can open while files requested only on a later scene change are missing. A general web capture is not proof that every execution dependency was collected. The scope needs to include material used during the experience.
Keep a retained viewer and an official destination as separate choices
For particular broken cases, the historical repair offers links to checked official VR destinations in place of a downloaded viewer. A separate preservation record says another working VR kept its configuration and links. The repair of one broken viewer was therefore not used as a blanket reason to replace every case.
An external destination requires an identified source, navigation method and responsibility for future address changes. An internally retained package requires responsibility for its execution files and deployed paths. I name the selected approach instead of claiming both are complete. Original customer VR addresses are not published in this article.
Component responses and actual exploration provide different evidence
The historical source check records successful responses for launch documents, scripts, XML and preview images, along with a scene list. That supports availability of selected components and paths. It does not establish that rotation, zooming and scene navigation were all observed on screen. Response codes should not be reported as a complete exploration.
Past template execution also records passing code checks for dedicated placement and relative directories. I compared those outputs and asset-check records without newly operating the original VR. An application inspection still needs initial loading, scene changes, narrow-screen controls and a return route. The actual actions checked matter more than a broad test label.
Distinguish an absent feature from a package awaiting verification
An earlier request says that unavailable downloaded video or VR should not have a related menu. No material and material whose runtime dependencies are not yet verified are different states. The first is not offered; the second has outstanding checks. Both should avoid an unready public promise, while their administrative reasons remain distinct.
A customer can provide the original package and any permitted official connection, rather than only a screenshot of its start. The maker preserves the structure and checks components and behavior in order. The useful method is not to cover a black screen with another picture, but to understand the execution boundary and report exactly how far the evidence goes.