Offline DSH plugin install: shortlist with the market first

An offline install of DSH plugins begins long before the isolated network, because the only chance to choose packages is while the DSH Plugin market is still reachable. Define the list first, carry everything it needs, and let the closed network do nothing but verify and install.

Define the DSH plugin list before the network disappears

The plugin list is a decision made on the connected side, and every later step only executes it.

Inside an isolated network there is no browsing, no search and no way to discover that a dependency was forgotten. That makes the connected side the only place where judgment happens. A shortlist written there is a contract: these packages, these versions, this platform, these hashes.

Start from the workflow rather than from package names. Name the jobs the machine must do, then find one plugin per job in the market. Fewer, well-understood plugins are easier to carry and easier to verify than a broad set chosen by curiosity.

Write down the exact version for each choice, never "latest". A version is a fact you can verify offline; a range is a promise the isolated network cannot keep. The same discipline applies to the runtime itself, whose version constrains which plugins can load.

What an offline DSH plugin shortlist must contain

A shortlist is complete only when someone else could install from it without asking you a question.

The manifest needs the package name, the exact version and the dependency tree that resolution produced. It also needs the target platform: operating system, architecture and Node version. Checksums belong there too, because transfer is the one step you cannot inspect later.

The table below is the minimum shape of that record. It is intentionally boring; the offline side should never need to interpret it. Anything ambiguous here becomes a support call later.

Packing DSH plugins for the isolated network

Tarballs travel better than directories, because they preserve a package and can be hashed.

Copying node_modules looks convenient and usually fails. The directory contains platform-specific artifacts, links that break across filesystems, and versions that may not match the manifest. A packed tarball is self-contained and gives you a stable value to compare on arrival.

Pack every package in the tree, not just the plugin. Use the exact version from the shortlist and record the hash immediately. If a package has a build step, note it, because the isolated machine may not have the toolchain or may forbid scripts.

npm pack @scope/example-plugin@1.4.2
shasum -a 256 example-plugin-1.4.2.tgz

Organize the media so the offline side can follow the list without guessing: plugins, dependencies, hashes. The structure is not bureaucracy; it is what lets a different person execute the same plan next quarter. A labeled folder is faster than a search through a disk image at the other end.

Installing DSH plugins offline in order

Install order matters offline, because a plugin cannot resolve against packages that are not there yet.

Verify the media before installing anything. A hash mismatch means the transfer failed or the record is wrong, and both are cheaper to fix now than after a partial install. Only then begin with the dependencies.

The numbered sequence below is the order that avoids most dead ends. It assumes the runtime is already present at the version recorded in the shortlist. If it is not, stop and treat that as a separate project.

1. Check every checksum against the shortlist.
2. Place the dependency tarballs in the target environment.
3. Install the plugin itself from its local tarball.
4. Confirm the versions with the plugin list command.
5. Restart the runtime and confirm the plugin reaches active state.
6. Run one real task that exercises the plugin's main function.

A failed step here is a shortlist defect, not an install mystery. The missing item is almost always a dependency, a platform artifact or a runtime version that was never carried across. Write that gap down before retrying so the next transfer fixes it once.

Verifying an offline DeepSeek Harness plugin install

Verification is a separate step, and an installed DeepSeek Harness plugin is not a working one.

A plugin can install cleanly and still fail to load, usually because of a runtime mismatch or a missing initialization dependency. The status field is the first check: pending or failed means the load stage never completed. Active means the package was accepted, not that its behavior is correct.

Run the task the plugin was chosen for, not a smoke test that only proves the process starts. Compare the result with what the connected-side checklist expected. If the plugin writes files or calls a service, confirm those effects are visible where they should be.

Record the result against the shortlist: package, version, install date, status and the task that passed. That record is what makes the next offline round faster, because it separates what was verified from what was merely assumed. The next person can then start from a known-good state instead of rediscovering it.