# Private CLI distribution for dsh-story

Evidence date: 2026-09-10. This investigation covers only a CLI installation command containing the plugin address. It inspected DSH, the installed pnpm source and official documentation without accessing private release artifacts, downloading or installing packages, reading credential values or publishing anything. At the time of inspection, the repository had been created but its source had not been pushed. The commands below remain templates for a future release; they do not establish that the plugin is currently installable.

**Recommendation: publish a release commit containing the built artifacts in the private Git repository, and install it by its full commit SHA.**

```sh
dsh plugin --profile web add 'git+ssh://git@github.com/hldz-top/dsh-story.git#<40-character-release-commit-SHA>'
```

Replace `web` with the target DSH profile, then start that profile normally after installation. DSH passes the package argument unchanged to pnpm in the profile directory and registers the bundle from the package's `dsh.bundle.patch` only after installation succeeds. No additional DSH URL handler or installation interface is needed. [DSH argument handling](/Users/hldz2/project/ai/deepseek-harness/apps/cli/src/args.ts:190), [installation and registration](/Users/hldz2/project/ai/deepseek-harness/apps/cli/src/plugin.ts:120)

**A single-command installation assumes authentication is already configured.** The locally installed pnpm version is **11.7.0**. The target machine also needs compatible versions of DSH, pnpm and Git, a GitHub SSH key that can read the private repository without interactive input, and a previously verified GitHub host key. Completing `gh auth login`, signing into a browser or downloading a GitHub Release in a browser does not establish that pnpm can fetch the repository over SSH. Never put a token in the installation URL. Version 11.7.0's hosted-Git resolver probes public HTTPS before trying SSH and can fall back to cloning with Git HTTPS authentication. An explicit SSH address therefore does not mean this version avoids HTTPS probes entirely. [Installed pnpm resolution and probing](/Users/hldz2/.cache/node/corepack/v1/pnpm/11.7.0/dist/pnpm.mjs:134307)

**Use the full 40-character SHA to pin the release.** The package's `version` communicates compatibility information. A tag such as `#v0.1.0` is stable only under a release policy that prohibits moving tags. Version 11.7.0 resolves a full SHA directly, and its Git fetcher checks that HEAD matches the requested SHA after checkout; the lockfile also records the resolved result. Pinning the Git SHA does not automatically pin every transitive dependency resolved by the consumer, so retain the profile lockfile as acceptance evidence. At the time of inspection, the pnpm website defaulted to 12.x, whose Git-source normalization behavior had changed. This finding uses the locally installed 11.7.0 implementation. [Resolution](/Users/hldz2/.cache/node/corepack/v1/pnpm/11.7.0/dist/pnpm.mjs:134555), [checkout verification](/Users/hldz2/.cache/node/corepack/v1/pnpm/11.7.0/dist/pnpm.mjs:134609), [pnpm package sources and version changes](https://pnpm.io/package-sources)

**The release commit must be directly runnable.** Its root must provide an installable `package.json`, ESM exports and `dsh.bundle.patch`, together with the referenced `lib/` files, type declarations, bundle configuration and any required prompts, templates or client assets. The `files` field and ignore rules must retain these artifacts. Run release builds explicitly during development or CI. The release manifest must not contain `prepare`, `prepublish`, `prepack` or installation-time build hooks. In 11.7.0, a nonempty `prepare` script triggers Git preparation even when built artifacts already exist, and preparation fails without the required `allowBuilds` permission. The Git fetcher ultimately collects files through the packlist. An ordinary `build` script alone does not trigger this preparation check. Declare DSH peer compatibility and actual runtime dependencies explicitly; avoid source aliases, external `workspace:` references and any requirement for consumers to install a compiler. [Preparation check](/Users/hldz2/.cache/node/corepack/v1/pnpm/11.7.0/dist/pnpm.mjs:133526), [Git package file collection](/Users/hldz2/.cache/node/corepack/v1/pnpm/11.7.0/dist/pnpm.mjs:134650)

**A private Release HTTPS tarball is not the preferred distribution route.** pnpm supports HTTP(S) tarballs, but its download client does not automatically reuse Git SSH authentication. GitHub's private Release asset API requires appropriate authentication; a fine-grained token needs repository Contents read permission. Binary downloads also involve `Accept: application/octet-stream` and redirects. Authenticated downloading followed by local installation is possible, but adds authentication and distribution steps unnecessary for this scope. A browser download address for a private GitHub Release is not evidence of a release URL that pnpm can use directly. [GitHub Release asset API](https://docs.github.com/en/rest/releases/assets), [pnpm package sources](https://pnpm.io/package-sources)

**Minimum real installation acceptance, not yet performed:**

1. After explicit publication and installation authorization and creation of a real release SHA, confirm that the test account can read that SHA through Git. Run the complete command above with an isolated `DSH_HOME` and empty profile. Record the exit status, installed package inventory and pinned commit without exposing credentials.
2. Confirm installation in an environment without a plugin compiler or any new build allowlist entry. Inspect the installed files, automatic bundle registration and ESM loading, and confirm that installation did not depend on a build hook. Reinstalling the same SHA must not create duplicate bundles.
3. Start the plugin through an actual DSH profile with a local deterministic model. Produce a settings candidate, accept and apply it, exit, then restart and read it back. This verifies the complete path from remote package installation through model tools and the writing service to DSH persistence. The existing source-profile prototype does not replace a real release-artifact installation test.

## Evidence boundary

Confidence is high in the source-code and official-protocol findings; successful installation of an actual private release artifact has not been established. Reuse the DSH CLI, Git authentication, pinned-commit resolution and bundle registration. The initial distribution route does not use browser activation or a private Release API download wrapper. The next distribution validation belongs to T15 and requires a real release artifact and explicit authorization.