release: publish npm alpha and verify clean-HOME install/uninstall

[Altairpaca]

Goal

Turn the current source-preview distribution into a verifiable public alpha that a user can install without knowing the repository layout.

Acceptance criteria

• publish the alpha package set required by the public entry point (dshelm, @dshelm/dsh, and any internal packages that must be externally resolvable);
• npx dshelm init --yes succeeds from a clean HOME with a supported DSH installation;
• dshelm doctor reports the installed profile/bundle and gives an actionable next command;
• uninstall removes DSHelm-owned discovery/profile state while preserving unrelated profiles and product-owned credentials;
• record the exact package versions and DSH version used for verification;
• create a GitHub prerelease with install, upgrade, limitations, and uninstall notes.

Evidence to attach

• clean-HOME command transcript with secrets/user paths redacted;
• installed profile/bundle paths;
• doctor output before and after install;
• uninstall proof showing unrelated state remains intact.

This is the P0 distribution gate from docs/community-roadmap.zh-CN.md; passing unit tests alone is not sufficient evidence for this issue.

[Altairpaca]

Pre-release packaging audit (2026-09): the clean pack-install CI already exercises all six publishable artifacts (dshelm, @dshelm/core, @dshelm/dsh, @dshelm/auth, @dshelm/model-knowledge, @dshelm/compat-omo), but the package manifests are not yet consistently ready for a public npm surface.

Before publishing the alpha, add a small release-hygiene pass:

1. normalize package metadata (description, license, repository, homepage, bugs, engines, publishConfig.access=public) across every publishable package;
2. ensure each npm package has a useful package-level README instead of an empty/minimal npm landing page;
3. add a repository CHANGELOG.md and a maintainer release checklist documenting version/tag/prerelease order and the exact clean-HOME evidence required here;
4. keep publish automation separate until the manual alpha path is proven once end-to-end.

This deliberately defers Changesets/automatic publishing until after the first real registry release, so release tooling does not hide package-boundary problems.

[Altairpaca]

Release-maintenance audit (2026-09-03): two version-coherence risks were found before the first public npm alpha.

1. Fixed in PR fix: keep init bundle version aligned with installed CLI #18 / main: dshelm init had hard-coded @dshelm/dsh@0.3.0-alpha.0; it now derives the adapter bundle version from the installed CLI package version.
2. Still a release gate: several published manifests declare verified DSH prerelease dependencies as ^0.1.0-rc.7, while compatibility.json and the current lockfile only verify 0.1.0-rc.7. A registry consumer is not protected by the repository lockfile and may resolve a later, unverified prerelease-compatible version. Before publishing release: publish npm alpha and verify clean-HOME install/uninstall #7, regenerate the lockfile together with exact DSH prerelease pins (or deliberately broaden compatibility only after evidence). Do not make a manifest-only change, because pnpm install --frozen-lockfile must continue to prove manifest/lockfile coherence.

PR #17 also removes release-version literals from pack/install CI and makes the QA journey read the DSH package baseline from compatibility.json.tested.dshPackages.

[Altairpaca]

2026-09-03 DSH 0.1.2 source-target update

The latest upstream source release is now dsh-v0.1.2-rc.1. PR #21 prepares forward-compatible source bridges, but does not promote the verified install baseline.

New release blocker discovered during the full package audit:

• the 0.1.2 source tree no longer contains the old packages/client/runtime / @deepseek-ai/dsh-client-runtime package currently used by @dshelm/dsh;
• @deepseek-ai/dsh-client-modules@0.1.2-rc.1 now owns dsh.client scanning, boot graph composition, /plugins bundle delivery and lazy module materialization;
• DSHelm browser source in feat: bridge DSH 0.1.2 APIs and redesign the project landing page #21 is decoupled from the removed runtime type package, but packages/dsh/package.json intentionally remains on the verified legacy dependency/inject graph until the candidate manifests and pnpm-lock.yaml can move together.

Exact promotion work is tracked in #20. The first npm alpha should not publish until #20 has resolved the 0.1.2 client graph (or selected another explicitly verified DSH baseline), regenerated the lockfile, and passed packed install + isolated profile boot + real Web client materialization.

This adds to the previously recorded prerelease-range blocker: do not publish a mixed or caret-resolved DSH prerelease graph.

[Altairpaca]

Update after PR #28 merge:

Repository-side npm alpha bootstrap preparation is complete on main (680db824a0720c489641535718673ef59f514f4b). Verified:

• guarded npm release workflow merged;
• six-package release order validated;
• deterministic package closure passed;
• npm 11.19.1 npm publish --dry-run --access public --tag alpha succeeded for all 0.3.0-alpha.0 packages;
• release evidence artifact: 9938939100 (sha256 376d1c1e3a9b4881ed0108ad199bfe5c36ad9de6027e87272f3c24666ea238bf).

Remaining blocker is maintainer-side first publication bootstrap only: npm ownership/scope access, 2FA-enabled credential path, then immediate migration to Trusted Publishing/OIDC. After the first real publish, run public-registry clean-HOME smoke before closing this issue.