Bug: dsh plugin remove can leave a stale dsh.profile.bundles entry that permanently breaks the profile

[MicroHEROX]

Summary

dsh plugin --profile <X> remove <bundle> intermittently leaves a stale entry in dsh.profile.bundles in the profile package.json. The profile then fails to boot with cannot resolve profile bundle, and neither dsh plugin install nor any later dsh plugin invocation can repair it — the only recovery is manually editing the manifest.

Environment

• dsh v0.1.0-rc.6 (npm global install), Windows 11, Node 24, pnpm 11.21.0
• Bundle: a github-hosted bundle (github:owner/repo spec) — failure observed once; 4/4 controlled reruns of the same remove flow passed, so it is non-deterministic

Observed sequence

1. Fresh profile: dsh plugin --profile X add github:owner/repo — bundle registers and works.
2. dsh plugin --profile X remove <bundle>:
   • pnpm removes the entry from dependencies in package.json (manifest written),
   • but dsh.profile.bundles keeps "<bundle>" (reconcile did not run or did not splice).
3. Boot fails:

   dsh: cannot resolve profile bundle "<bundle>" from the dsh installation or C:\...\profiles\X; run dsh plugin --profile X install if its dependency is not installed
   

4. dsh plugin --profile X install and dsh plugin --profile X ls do not remove the stale entry (verified).
5. Manual removal of the entry from dsh.profile.bundles restores the profile.

Related observation: on a brand-new profile, the first dsh plugin add sometimes fails to populate dsh.profile.bundles (the row is missing from --dump-config until a second add is run) — likely the same class of transient reconcile skip.

Root-cause hypothesis

In apps/cli/src/plugin.ts, reconcilePlugins runs only if (exitCode === 0). If pnpm exits non-zero after having already written the manifest (this machine showed repeated transient HEAD https://github.com/... ETIMEDOUT failures during git-hosted pnpm operations), reconcile is skipped while the manifest is already in the removed state.

The stale entry is then permanent: on every later invocation, wasDependency = beforeDeps.has(packageName) || dependencySet.has(packageName) is false (the dependency is gone from both the pre- and post-manifest), so the removal branch never fires, and the entry is treated as user-owned.

Suggested fixes (any would work)

1. Run reconcile regardless of pnpm exit code (or reconcile on the next successful invocation using a dependency diff rather than installed state).
2. Make the removal branch independent of beforeDeps: an entry in dsh.profile.bundles that is neither a template bundle nor present in dependencies (nor resolvable) should be removed or warned about.
3. Make pnpm manifest write conditional on success (atomic add/remove), or restore the manifest on failure.

Impact

Any bundle type (verified independent of the bundle: a link:-installed bundle removed cleanly; the failure was observed with a github-hosted bundle). Affected profiles are unbootable until the user hand-edits package.json — a poor first-time experience for dsh plugin users.

[DRAG0NM]

已定位根因：**dsh plugin remove 在 pnpm 非零退出（如 git-hosted 源瞬时网络错误）时，manifest 已被写入"依赖已删"状态，但 reconcile 因 exitCode === 0 门控被跳过，dsh.profile.bundles 残留条目；此后该条目 wasDependency 恒为 false，删除分支永不… 完整源码定位与修复方案见 #917 。