Install a capture module
This page is the install flow every capture module shares. A module’s own page links here and documents only what differs for that module: a native dependency, an extra host component, a prerequisite driver. See the module catalogue for the full list.
Where modules come from
| Source | Configured by |
|---|---|
VRAI-supplied .hcz configuration package | Imported from HEAT Capture’s Settings; contains the approved modules and deployment settings |
| VRAI curated registry | A Module Library token in the installer or the Modules configuration section; used only for self-service installation |
| A local directory | A repository entry of type Local |
| An individual package file | A .zip dropped onto the module page |
Most customer deployments use the VRAI-supplied .hcz and need no registry token; see
Install HEAT Capture. If neither an .hcz nor a module source is
configured, the available-module catalogue is empty.
Install a module
Installing, updating and uninstalling a module all apply live. HEAT Capture stops, swaps and restarts only the affected module’s child process; the application itself keeps running and needs no restart.
-
Stop any active session. The module page is locked while a session is running: “Modules cannot be installed or changed during a session.”
-
Open the module page and pick the module and version. The catalogue marks versions that are incompatible with the installed application.
-
Install. The package is downloaded, its signature is verified, and it is extracted into the modules directory. The page reports each phase as it happens: checking, downloading, extracting, starting, done.
-
Enable the module and configure it. A module is disabled until you enable it.
An enabled module that runs at application startup starts as soon as the install finishes. A session-bound module joins at the next session boundary.
Updating swaps the package in place: the module process stops, the new version is copied in, and it restarts if eligible. A failed swap restores the previous version. Uninstalling stops the module, unregisters it and deletes the package folder.
Install a package file by drag and drop
A module supplied as a single .zip, outside any registry, is installed by dropping the file onto
the module page. There is no file picker; drag and drop is the only path for a loose package file.
-
Stop any active session. Drops are ignored while a session is running.
-
Drag the
.zipover the module page. The page shows a drop target: “Drop .zip file here to validate module package”. -
Drop it. Exactly one
.zipper drop. Anything else is refused: “Drop a single module .zip. The manifest is packaged inside it.” -
The file is staged and validated before anything is installed. The page reports the first failure it finds rather than installing a partial package.
-
Confirm the action the validator resolved:
Install {displayName} v{uploadedVersion}?for a new package, orUpdate {displayName} from v{installedVersion} to v{uploadedVersion}?when a lower version is already installed. -
The staged package is installed live, the same as a registry install. No restart.
Validation covers, in order:
| Check | Refusal |
|---|---|
File name ends in .zip | Only .zip module packages are supported |
Signature, when Modules:RequirePackageSignatures is true | Package signature verification failed, with the reason. An unsigned package passes only with the AllowUnsignedModules opt-in, and the acceptance is logged |
| Archive is readable | Invalid zip archive |
heat.module.json present inside the archive | Repackage the module with heat.module.json inside the archive |
Manifest declares name, version, assembly file name, and module metadata with name, typeName, settingsSection and settingsSchema | Package manifest is invalid, or the missing-metadata message |
| The declared assembly file is in the archive | Archive is missing assembly '{AssemblyFileName}' |
| Compatible with the installed application | The compatibility reason |
| Version is newer than an installed copy | Uploaded package version {new} is not newer than installed version {installed} |
The upload request limit is 512 MiB. A staged package that is never confirmed is discarded when you leave the page, and the staging token is spent once execution runs, successfully or not.
Trust and signatures
Every published module package is signed by VRAI. HEAT Capture verifies the signature twice: when the package is acquired, and again from the extracted files each time a module is started.
| Case | Behaviour |
|---|---|
| Signature valid and from a trusted VRAI key | The module loads |
| Signature invalid, or files modified after signing | The module is refused, always. No setting overrides this |
| No signature | The module is refused |
The refusal for a modified package reads:
Module '{name}' failed signature verification and will not be loaded: {reason}Trusted signing keys are built into the application, so verification works with no network access and no certificate infrastructure on your side. Installing a newer application version is what updates the set of trusted keys.
An unsigned-module opt-in exists for building and testing your own custom module before it is signed by VRAI. Enabling it means any module code placed on that machine runs, not only the one you are developing; modules loaded this way are badged as untrusted in the interface. Restrict it to development and evaluation workstations. Leave it off on a workstation that runs real exercises. See Configure HEAT Capture.
Capabilities
Each module declares the capabilities it needs, such as network access to a named host and port, or access to a USB or Bluetooth device. HEAT Capture validates that declaration before starting the module. There is no consent prompt: an invalid or unrecognised declaration refuses the start outright.
Refusing to start module {ModuleName}: invalid capability manifest ({Errors})Network capabilities are enforced by the host. Device and filesystem capabilities are recorded as declarations and are not mediated by the host, so treat them as documentation of intent rather than as a sandbox boundary when accrediting a module. A module with no declared capabilities, most commonly one that only reads local files or has no external dependency, has nothing to validate at this step.
See Manage capture modules for what happens once a module is running: enabling, misbehaviour handling, and locking down a shared workstation.