Plugin build fails under corepack when `/understand` runs from a project that pins a different `packageManager`

[parkerault]

Summary

The one-time plugin build in SKILL.md Phase 0 (pnpm install … && pnpm --filter @understand-anything/core build) fails when the command's working directory resolves to a project whose package.json declares a non-pnpm "packageManager" (e.g. a repo pinned to yarn or npm). Corepack's project-spec enforcement refuses to run pnpm, so packages/core/dist/ is never built and every later phase that imports @understand-anything/core breaks. It seems likely that most users will install the plugin in a session started from the repo they plan to index, so this could be a common problem when following the installation steps in the README.

Trigger condition

• Running /understand from (or with a CWD inside) any project that pins "packageManager": "<non-pnpm>@x" in a package.json, and
• the plugin's packages/core/dist/ does not yet exist (fresh install), so Phase 0 attempts the build.

Steps to reproduce

1. From within a repo that sets "packageManager": "yarn@x" (or npm@x) in a package.json, run /understand <subdir> on a fresh plugin install.
2. Phase 0 reaches the build step because packages/core/dist/index.js is missing.
3. Corepack invokes pnpm and aborts.

Actual behavior

Corepack refuses to run pnpm:

This project is configured to use yarn because <host-repo>/path/to/package.json has a "packageManager" field

Two additional, independent papercuts surface at this step:

• pnpm -C <pluginRoot> does not help. Corepack selects the package manager from the current working directory, not from pnpm's -C target, so redirecting pnpm's project dir doesn't avoid the host's pin.
• The shipped lockfile is stale. pnpm install --frozen-lockfile aborts with ERR_PNPM_OUTDATED_LOCKFILE; pnpm-lock.yaml is missing graphology@~0.26.0 and graphology-communities-louvain@^2.0.2.

Expected behavior

The plugin should build regardless of the host project's packageManager pin. The build happens inside the plugin's own directory and is unrelated to whatever package manager the host repo uses.

Root cause

The build commands run with the session's working directory (the host repo), so corepack reads the host's packageManager and enforces it against pnpm.

Suggested fixes (any combination)

1. Make the build immune to the host's pin — e.g. set COREPACK_ENABLE_PROJECT_SPEC=0 for the build commands, and/or cd "$PLUGIN_ROOT" before invoking pnpm so corepack resolves the plugin's own package manager rather than the host's.
2. Declare an explicit "packageManager": "pnpm@<version>" in the plugin root package.json so corepack selects pnpm when the build runs from the plugin root.
3. Regenerate pnpm-lock.yaml so --frozen-lockfile succeeds (it currently omits the two graphology deps).
4. Document/enforce the Node version the build requires (the core build needs a Node version that satisfies the package's engines); surface a clear error when the active Node is too old, since the build can silently fall over otherwise.

Related

Related to #270 (pnpm dependency / npm fallback) but distinct: this is specifically the corepack packageManager-pin collision plus the stale lockfile, not an npm-fallback request.