plugin: avoid allowBuilds hint for unrelated Git fetch failures

[adoresever]

Summary

dsh plugin prints an allowBuilds/prepare hint after any failed Git install, including failures that happen before the repository is fetched.

Reproduction

Environment reported by a real user:

• DSH 0.1.1-rc.2
• Node 24.14.1
• Windows x64
• command: dsh plugin --profile web add git+https://github.com/adoresever/graph-memory.git

pnpm reports ERR_PNPM_GIT_FETCH_FAILED and Failed to connect to github.com port 443: Timed out.

DSH then says that Git-hosted plugins build through prepare and asks the user to edit allowBuilds. No checkout or plugin prepare step was reached, so changing allowBuilds cannot resolve this failure.

Root cause

apps/cli/src/plugin.ts currently emits prepare/allowBuilds guidance whenever the argument looks like a Git spec and pnpm exits non-zero. The diagnostic is selected from the command shape rather than the actual failure category.

Expected behavior

• Always report the profile directory on pnpm failure.
• Only print allowBuilds guidance for prepare/build-policy failures such as ERR_PNPM_GIT_DEP_PREPARE_NOT_ALLOWED or ERR_PNPM_IGNORED_BUILDS.
• For Git fetch/network failures, preserve pnpm diagnostics without suggesting an unrelated profile policy mutation.

Original downstream report: adoresever/graph-memory#87

[weijiafu14]

Confirmed your root cause line-for-line against apps/cli/src/plugin.ts (the copy in my tree was last touched by the feat/npm-public merge, so it is upstream code, not something my branch changed). Two refinements — one narrows your ask, one widens it.

1. The profile-directory line is already unconditional, so the ask is narrower than you wrote.

process.stderr.write(`${NAME}: pnpm failed in profile directory ${dir}\n`)
if (args.some(argument => /^git\+|^github:|\.git(?:#|$)/.test(argument))) {
  // ... the prepare/allowBuilds hint ...
}

Your first expected-behavior bullet ("Always report the profile directory on pnpm failure") is already satisfied — that write is outside the if. And pnpm is spawned with stdio: 'inherit', so your third bullet is satisfied too: pnpm's own ERR_PNPM_GIT_FETCH_FAILED output was never suppressed.

That leaves exactly one defect, which makes the fix purely subtractive: the hint's gate is a regex over argv and reads neither the exit code nor pnpm's ERR_PNPM_* code. It isn't that the diagnostic is mostly selected by command shape — argv is literally the only input.

2. The same gate fails in the other direction, and that half isn't in your report.

Because the predicate is git-shape-only, a plain npm spec that fails for precisely the reason the hint describes gets no hint at all. dsh plugin add <npm-package> whose transitive dependency carries an install script fails with ERR_PNPM_IGNORED_BUILDS — a build-policy failure, not git-shaped, hint suppressed. This is not hypothetical for us: one dependency chain we ship through (pi-ai → a genai client → protobufjs) carries an install script, and pnpm's block on it is the first thing a fresh user meets. The user who most needs the allowBuilds sentence is the one who never sees it.

So keying the hint off the ERR_PNPM_* code fixes both directions at once, and the set you named (ERR_PNPM_GIT_DEP_PREPARE_NOT_ALLOWED, ERR_PNPM_IGNORED_BUILDS) is the right one to key on — it just needs to apply regardless of whether the spec was git-shaped.

Interest disclosure: we publish a plugin that users install through this exact code path, so dsh plugin add failure text is something we read a lot of. We do not touch this file — it is DSH's own CLI and only DSH can fix it.

[adoresever]

Thanks @weijiafu14 — confirmed both refinements line-for-line. I narrowed the change to the actual classifier defect and covered the inverse npm-spec failure mode you identified.

The tested patch is ready here:

• Branch: https://github.com/adoresever/deepseek-harness/tree/fix/plugin-build-policy-diagnostic
• Commit: adoresever@dc907a3
• Compare: master...adoresever:deepseek-harness:fix/plugin-build-policy-diagnostic

It:

• preserves the already-unconditional profile-directory diagnostic and streams pnpm stderr unchanged;
• selects the extra allowBuilds guidance only when stderr contains ERR_PNPM_GIT_DEP_PREPARE_NOT_ALLOWED or ERR_PNPM_IGNORED_BUILDS, independent of package-spec shape;
• avoids the hint for ERR_PNPM_GIT_FETCH_FAILED;
• adds built-CLI regression coverage for Git fetch failure, Git prepare-policy failure, and registry-spec ignored-build failure.

Validation passed: built CLI E2E 19/19, lint, doc-sync 28/28, pre-push typecheck, and diff check.

I attempted to open the upstream PR, but this repository currently reports “New Pull request creation is restricted” and both GitHub GraphQL and REST reject external PR creation. The branch is ready for a maintainer to pull/cherry-pick, or I can open the PR immediately if external PR creation is enabled.

Thank you for the precise review — it made the fix smaller and correct in both directions.

[yangfei222666-9]

Independent confirmation of the inverse direction @weijiafu14 described: on DSH 0.1.1-rc.2 (macOS, pnpm 11), dsh plugin installs of registry packages whose transitive deps carry install scripts failed with ERR_PNPM_IGNORED_BUILDS and produced no allowBuilds guidance at all — I only resolved it by manually editing the placeholder keys in the profile's pnpm-workspace.yaml. I reported the registry-package side of this friction earlier in #3699 (same account, 2026-08-21). Keying the hint off the ERR_PNPM_* code, the direction of your commit dc907a3, looks aligned with both directions you two described, pending regression testing — happy to help test or reproduce anything.