void 0.10.5 → 0.10.7

package/skills/void/docs/node_modules/void/node_modules/@void/md/node_modules/vite-plus/docs/guide/commit-hooks.md

@@ -22,8 +22,17 @@ If you use [`vp create`](/guide/create) or [`vp migrate`](/guide/migrate), Vite+
 ```bash
 vp config
 vp config --hooks-dir .vite-hooks
+vp config --no-hooks
+vp config --no-agent
 ```
 
+Use `--no-hooks` when you want `vp config` to leave existing Git hook setup unchanged. Use
+`--no-agent` when you want it to skip updates to existing coding agent instruction files. You
+can pass both flags when you want `vp config` to skip both setup steps.
+
+You can also set `VITE_GIT_HOOKS=0` to disable hook installation from lifecycle scripts such as
+`prepare` or `postinstall`.
+
 ### `vp staged`
 
 `vp staged` runs staged-file checks using the `staged` config from `vite.config.ts`. If you set up Vite+ to handle your commit hooks, it will automatically run when you commit your local changes.

package/skills/void/docs/node_modules/void/node_modules/@void/md/node_modules/vite-plus/docs/guide/create.md

@@ -27,7 +27,7 @@ Vite+ ships with these built-in templates:
 - `vite:monorepo` creates a new monorepo
 - `vite:application` creates a new application
 - `vite:library` creates a new library
-- `vite:generator` creates a new generator
+- `vite:generator` creates a new code generator (monorepo only, see [Code Generators](#code-generators))
 
 ## Template Sources
 
@@ -35,7 +35,7 @@ Vite+ ships with these built-in templates:
 
 - Use shorthand templates like `vite`, `@tanstack/start`, `svelte`, `next-app`, `nuxt`, `react-router`, and `vue`
 - Use full package names like `create-vite` or `create-next-app`
-- Use local templates such as `./tools/create-ui-component` or `@acme/generator-*`
+- Use local monorepo templates declared in [`create.templates`](#code-generators) (for example an internal component or service generator)
 - Use remote templates such as `github:user/repo` or `https://github.com/user/template-repo`
 
 Run `vp create --list` to see the built-in templates and the common shorthand templates Vite+ recognizes.
@@ -44,13 +44,29 @@ Run `vp create --list` to see the built-in templates and the common shorthand te
 
 - `--directory <dir>` writes the generated project into a specific target directory
 - `--agent <name>` creates agent instructions files during scaffolding
+- `--no-agent` skips agent instruction setup
 - `--editor <name>` writes editor config files
+- `--no-editor` skips editor config setup
+- `--git` initialize a git repository
+- `--no-git` skips git repository initialization
 - `--hooks` enables pre-commit hook setup
 - `--no-hooks` skips hook setup
+- `--package-manager <name>` uses a specified package manager (`pnpm`, `npm`, `yarn`, or `bun`)
+- `--approve-builds` approves and runs gated dependency build scripts without prompting
 - `--no-interactive` runs without prompts
 - `--verbose` shows detailed scaffolding output
 - `--list` prints the available built-in and popular templates
 
+### Dependency build scripts
+
+For security, pnpm, bun, and yarn (Berry) do not run a dependency's build scripts (`install` / `postinstall`, e.g. native builds like `better-sqlite3`) until you approve them. When a template adds such a dependency directly, `vp create` surfaces it after installing instead of leaving the project in a half-built state:
+
+- Interactive: you are asked which of those dependencies to approve and build (nothing is selected by default).
+- Non-interactive: a note lists them and points at `vp pm approve-builds`.
+- `--approve-builds`: approves and builds them automatically, so non-interactive runs (CI) can produce a ready-to-use project.
+
+Approval is recorded the way each package manager expects: pnpm's `allowBuilds`, bun's `trustedDependencies`, or yarn's `dependenciesMeta.<pkg>.built` (in the workspace root manifest). Transitive build scripts you did not choose (e.g. `esbuild` pulled in by Vite) are left at the package manager's defaults and are not surfaced. npm runs build scripts by default, so there is nothing to approve there.
+
 ## Template Options
 
 Arguments after `--` are passed directly to the selected template.
@@ -86,3 +102,240 @@ vp create create-next-app
 vp create github:user/repo
 vp create https://github.com/user/template-repo
 ```
+
+## Code Generators
+
+Monorepos often need to scaffold their own building blocks: a UI component, a service, or an internal package that follows house conventions. Vite+ supports this through generator packages powered by [Bingo](https://www.create.bingo/) templates.
+
+### Scaffold a generator
+
+Inside a Vite+ monorepo, run:
+
+```bash
+vp create vite:generator
+```
+
+This requires a monorepo workspace. If you don't have one yet, create it first with `vp create vite:monorepo`.
+
+The scaffolded generator package contains:
+
+- `src/template.ts` defines the template using `createTemplate` from `bingo`: an options schema built with [Zod](https://zod.dev/) and a `produce()` function that returns the files to generate
+- `bin/index.ts` is the CLI entry, powered by Bingo's `runTemplateCLI`
+
+If the monorepo has a parent directory matching `generators` or `tools`, the new package is placed there by default.
+
+### Registration
+
+Local generators are declared in [`create.templates`](/config/create#create-templates) in the monorepo's `vite.config.ts`. This is the source of truth: only registered templates appear in the `vp create` picker.
+
+`vp create vite:generator` registers the generator for you, adding an entry to `create.templates` in the root `vite.config.ts`:
+
+```ts
+import { defineConfig } from 'vite-plus';
+
+export default defineConfig({
+  create: {
+    templates: [
+      { name: 'my-generator', description: 'Generate new components', template: 'my-generator' },
+    ],
+  },
+});
+```
+
+Re-running is idempotent (no duplicate entries), and an existing `create.defaultTemplate` is preserved. You can also add entries by hand, for example to register a template you didn't scaffold this way. The `template` value is the generator's workspace package name, or a relative `./path` to it.
+
+### Run a generator
+
+Inside the monorepo, run `vp create` and pick the generator from the template list, or pass its entry `name` directly:
+
+```bash
+# Interactive mode lists registered local templates alongside the built-ins
+vp create
+
+# Run a registered template by its name
+vp create component
+
+# Pass options to the generator after --
+vp create component -- --name @your-org/button
+```
+
+When the generator depends on `bingo`, Vite+ appends `--skip-requests` automatically so it skips Bingo's outbound network requests (such as GitHub API calls).
+
+After the generator runs, the created package goes through the regular monorepo integration: workspace registration, dependency installation, and formatting.
+
+### Customize a generator
+
+Edit `src/template.ts` to define the options and the files to produce:
+
+```ts
+import { createTemplate } from 'bingo';
+import { z } from 'zod';
+
+export default createTemplate({
+  options: {
+    name: z.string().describe('Package name'),
+  },
+  async produce({ options }) {
+    return {
+      files: {
+        'package.json': JSON.stringify({ name: options.name, version: '0.0.0' }, null, 2),
+        src: {
+          'index.ts': `export const name = '${options.name}';\n`,
+        },
+      },
+    };
+  },
+});
+```
+
+- `options` defines the generator's prompts and flags using Zod schemas
+- `produce()` returns the [files](https://www.create.bingo/build/concepts/creations#files) to create, plus optional [scripts](https://www.create.bingo/build/concepts/creations#scripts) to run after generation and [suggestions](https://www.create.bingo/build/concepts/creations#suggestions) to print for the user
+
+See the [Bingo documentation](https://www.create.bingo/) for the full template API.
+
+## Organization Templates
+
+An organization can publish a curated set of templates under a single npm scope by shipping an `@org/create` package whose `package.json` carries a `createConfig.templates` manifest. Once published, `vp create @org` opens an interactive picker over those templates.
+
+### Pick from an org
+
+```bash
+# Open an interactive picker over @your-org/create's manifest
+vp create @your-org
+
+# Run a specific manifest entry directly
+vp create @your-org:web
+
+# Pin to an exact version or a dist-tag
+vp create @your-org@1.2.3
+vp create @your-org:web@next
+
+# Set the org as the default for a repo (see create.defaultTemplate config)
+vp create
+```
+
+Behind the scenes, `vp create @org` maps to `@org/create` (the existing npm `create-*` convention). If that package has no `createConfig.templates` field, Vite+ falls back to running the package normally — so adopting the manifest is zero-risk for orgs that already publish `@org/create`.
+
+Private registries work automatically: Vite+ reads `.npmrc` files from the project root and `~/`, honoring `@your-org:registry=...` scope mappings and `//host/:_authToken=...` credentials.
+
+### Authoring `@org/create`
+
+There are two common layouts. Pick the one that matches the org's template count and release cadence.
+
+**Bundled (recommended for most orgs).** All templates live as subdirectories of `@org/create` itself. Manifest entries use relative `./path` values. One repo, one publish, one versioning story — the same pattern used by `create-vite` and `create-next-app`.
+
+```
+@your-org/create/
+├── package.json              # "createConfig": { "templates": [{ "template": "./templates/web" }, ...] }
+├── templates/
+│   ├── web/
+│   │   ├── package.json
+│   │   └── src/...
+│   └── library/...
+└── README.md
+```
+
+**Manifest-only.** When the org already publishes independent `@org/template-*` packages (or hosts them on GitHub), `@org/create` stays a thin index.
+
+```
+@your-org/create/
+├── package.json              # "createConfig": { "templates": [{ "template": "@your-org/template-web" }, ...] }
+└── README.md
+```
+
+The two layouts can be mixed — a manifest can point most entries at external packages and keep a few as bundled subdirectories.
+
+Optionally, provide a `bin` script so `npm create @org` (the legacy path) keeps working for non-Vite+ users. `vp create @org` reads the manifest directly and never runs the `bin`.
+
+### Manifest schema
+
+The manifest lives at `createConfig.templates` in `@org/create`'s `package.json`:
+
+```json
+{
+  "name": "@your-org/create",
+  "version": "1.0.0",
+  "createConfig": {
+    "templates": [
+      {
+        "name": "monorepo",
+        "description": "Monorepo",
+        "template": "@your-org/template-monorepo",
+        "monorepo": true
+      },
+      {
+        "name": "web",
+        "description": "Web app template (Vite + React)",
+        "template": "@your-org/template-web"
+      },
+      {
+        "name": "demo",
+        "description": "Bundled demo template",
+        "template": "./templates/demo"
+      }
+    ]
+  }
+}
+```
+
+Each entry supports:
+
+| Field         | Required | Notes                                                                                                                                                                                                                                      |
+| ------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `name`        | yes      | Kebab-case identifier. Used by `vp create @org:<name>` for direct selection. Must be unique within the array.                                                                                                                              |
+| `description` | yes      | One-line description shown in the picker.                                                                                                                                                                                                  |
+| `template`    | yes      | An npm specifier (`@org/template-foo`, optionally `@version`), a GitHub URL (`github:user/repo`), a `vite:*` builtin, a local workspace package name, or a relative path (`./templates/foo`) that resolves against the `@org/create` root. |
+| `monorepo`    | no       | If `true`, marks this entry as a monorepo-creating template. Hidden from the picker when `vp create` runs inside an existing monorepo, mirroring the built-in `vite:monorepo` filter.                                                      |
+
+An invalid manifest is a hard error, not a silent fall-through — a maintainer who shipped a manifest should hear about the offending field, e.g. `@your-org/create: createConfig.templates[2].template must be a non-empty string`.
+
+### Bundled subdirectory templates
+
+Relative `./...` paths resolve against the enclosing `@org/create` package root — **not** the user's cwd. The referenced directory is copied into the target project as-is (no template-engine processing); the only exception is that a small set of underscore-prefixed scaffold files (`_gitignore`, `_npmrc`, `_yarnrc.yml`) are renamed to their dotfile equivalents. Paths that escape the package root are rejected.
+
+### Make the org the default in a repo
+
+Commit this in `vite.config.ts` at the project root:
+
+```ts
+import { defineConfig } from 'vite-plus';
+
+export default defineConfig({
+  create: { defaultTemplate: '@your-org' },
+});
+```
+
+Now `vp create` (with no argument) drops straight into the `@your-org` picker. See [`create.defaultTemplate`](/config/create) for details.
+
+The picker always appends a trailing **Vite+ built-in templates** entry so `vite:monorepo` / `vite:application` / `vite:library` / `vite:generator` stay reachable from the picker — selecting it routes to the standard built-in flow. For scripts and CI, explicit specifiers (`vp create vite:library`) bypass the configured default.
+
+### Non-interactive inspection
+
+`vp create @org --no-interactive` prints the manifest as a table and exits 1:
+
+```
+A template name is required when running `vp create @your-org` in non-interactive mode.
+
+Available templates in @your-org/create:
+
+  NAME     DESCRIPTION                          TEMPLATE
+  web      Web app template (Vite + React)      @your-org/template-web
+  library  TypeScript library template          @your-org/template-library
+  demo     Bundled demo template                ./templates/demo
+
+Examples:
+  # Scaffold a specific template from the org
+  vp create @your-org:web --no-interactive
+
+  # Or use a Vite+ built-in template
+  vp create vite:application --no-interactive
+```
+
+### Publishing checklist
+
+1. Create `@org/create` (scoped npm package) if you don't already have one.
+2. Add a `createConfig.templates` array to `package.json`. (Bundle the templates under `./templates/...` or point at external packages.)
+3. (Optional) Provide a `bin` launcher for `npm create @org` compatibility.
+4. Publish.
+5. Verify: `vp create @org --no-interactive` prints the manifest table; `vp create @org` opens the picker.
+6. (Optional) Commit `create: { defaultTemplate: '@org' }` in your internal template repos.

package/skills/void/docs/node_modules/void/node_modules/@void/md/node_modules/vite-plus/docs/guide/docker.md

@@ -0,0 +1,175 @@
+# Docker
+
+Vite+ publishes an official Docker image with the `vp` CLI preinstalled:
+
+```bash
+ghcr.io/voidzero-dev/vite-plus
+```
+
+Use it for builds, CI, and devcontainers. It is not intended as a production
+runtime image.
+
+`vp` resolves the Node.js version from your project (`.node-version`,
+`devEngines.runtime`, or `engines.node`) and downloads that exact version during
+install/build. This means the image does not need Node-version-specific tags.
+
+For production, use a multi-stage build: build the app with the Vite+ image, then
+copy only the resolved Node.js binary, build output, and production dependencies
+into a smaller runtime image.
+
+## Image tags
+
+Tags track the `vp` version:
+
+| Tag                                                      | Meaning        |
+| -------------------------------------------------------- | -------------- |
+| `ghcr.io/voidzero-dev/vite-plus:latest`                  | Latest release |
+| `ghcr.io/voidzero-dev/vite-plus:<major>`                 | Latest major   |
+| `ghcr.io/voidzero-dev/vite-plus:<major>.<minor>`         | Latest minor   |
+| `ghcr.io/voidzero-dev/vite-plus:<major>.<minor>.<patch>` | Exact version  |
+
+The examples use `:latest` to track the newest release; pin an exact tag or a
+digest if you need reproducible builds. The image is published for `linux/amd64`
+and `linux/arm64` and runs as a non-root user by default.
+
+Browse all published versions and digests on the [GitHub package page](https://github.com/voidzero-dev/vite-plus/pkgs/container/vite-plus).
+
+## Production: SSR / Node.js server app
+
+For apps that run Node.js in production (SvelteKit, Nuxt, a custom Vite SSR
+server, and so on), build with the toolchain image and copy the resolved Node.js
+and the built app into a slim runtime stage:
+
+```dockerfile [Dockerfile]
+# syntax=docker/dockerfile:1
+
+# --- build stage: the official Vite+ toolchain image ---
+FROM ghcr.io/voidzero-dev/vite-plus:latest AS build
+WORKDIR /app
+
+# Install dependencies first so this layer is cached across source changes.
+COPY --chown=vp:vp package.json pnpm-lock.yaml .node-version* ./
+RUN vp install --frozen-lockfile
+
+# Build. vp reads .node-version and provisions that exact Node.js automatically.
+COPY --chown=vp:vp . .
+RUN vp build
+
+# Export the exact resolved Node.js binary for the runtime stage.
+RUN cp "$(vp env which node | head -1)" /tmp/node
+
+# --- deps stage: production-only dependencies ---
+# A separate, fresh `--prod` install so devDependencies (including the vite-plus
+# toolchain) are excluded. Running `--prod` over the full install above would not
+# prune the already-installed devDependencies.
+FROM ghcr.io/voidzero-dev/vite-plus:latest AS deps
+WORKDIR /app
+COPY --chown=vp:vp package.json pnpm-lock.yaml .node-version* ./
+RUN vp install --frozen-lockfile --prod
+
+# --- runtime stage: small, glibc, no vp ---
+FROM debian:bookworm-slim AS runtime
+WORKDIR /app
+ENV NODE_ENV=production
+
+# The exact Node.js from .node-version (official, signature-verified build).
+COPY --from=build /tmp/node /usr/local/bin/node
+
+COPY --from=build /app/dist ./dist
+COPY --from=deps /app/node_modules ./node_modules
+COPY --from=build /app/package.json ./
+
+USER nobody
+EXPOSE 3000
+CMD ["node", "dist/server.js"]
+```
+
+The deployed image contains only Node.js plus your app and production
+dependencies, and matches `.node-version` exactly. It is much smaller than the
+default `node:*` image; see the distroless tip below for the smallest result.
+
+::: warning Prune production dependencies in a separate stage
+Install production dependencies in their own `deps` stage as shown. Running
+`vp install --prod` after a full `vp install` in the same stage does not remove
+the already-installed devDependencies, so the `vite-plus` toolchain would be
+copied into the runtime image. If your server bundle is fully self-contained (no
+un-bundled runtime dependencies), you can skip copying `node_modules` entirely.
+:::
+
+::: tip Smaller still
+For a shell-less, minimal-CVE runtime, swap the runtime base for distroless
+(`gcr.io/distroless/cc`) and keep an `ENTRYPOINT` in vector form. It is glibc
+based, so the copied Node.js binary remains compatible.
+:::
+
+## Production: static SPA / SSG
+
+A static site needs no Node.js at runtime; serve the build output with any static
+server:
+
+```dockerfile [Dockerfile]
+FROM ghcr.io/voidzero-dev/vite-plus:latest AS build
+WORKDIR /app
+COPY --chown=vp:vp package.json pnpm-lock.yaml .node-version* ./
+RUN vp install --frozen-lockfile
+COPY --chown=vp:vp . .
+RUN vp build
+
+FROM nginx:alpine AS runtime
+COPY --from=build /app/dist /usr/share/nginx/html
+```
+
+## Continuous integration
+
+Use the image directly in container-based CI (GitLab CI, Buildkite, CircleCI,
+Jenkins, and others):
+
+```yaml [.gitlab-ci.yml]
+build:
+  image: ghcr.io/voidzero-dev/vite-plus:latest
+  script:
+    - vp install --frozen-lockfile
+    - vp check
+    - vp test
+    - vp build
+```
+
+On GitHub Actions, prefer [`setup-vp`](./ci) instead of the image.
+
+## Devcontainers
+
+Use the image as a ready-to-go development container with the toolchain
+preinstalled:
+
+```jsonc [.devcontainer/devcontainer.json]
+{
+  "image": "ghcr.io/voidzero-dev/vite-plus:latest",
+}
+```
+
+## Ad-hoc usage
+
+Run any `vp` command against a project without installing vp on your machine:
+
+```bash
+docker run --rm -it -v "$PWD:/app" -w /app ghcr.io/voidzero-dev/vite-plus vp build
+```
+
+## Notes
+
+- **Node.js version**: provisioned from `.node-version`, `engines.node`, or
+  `devEngines.runtime` at build time, so there is no Node.js-specific image tag. The
+  dependency `COPY` uses a `.node-version*` glob so the file is optional: projects
+  that pin via `engines.node`/`devEngines.runtime` need no `.node-version`, and
+  those that use one have it available in every stage.
+- **Non-root user**: the image runs as the non-root `vp` user, so copy sources
+  with `COPY --chown=vp:vp ...` as shown. Without it, `COPY` writes root-owned
+  files that `vp install` cannot update (permission denied).
+- **Native addons**: the image includes a C/C++ build toolchain (`build-essential`,
+  `python3`), so native dependencies such as `better-sqlite3` compile during
+  `vp install`.
+- **glibc**: the image is glibc based so it uses the official, signature-verified
+  Node.js builds.
+- **Custom base image**: to add `vp` to your own base image instead, run the
+  installer: `curl -fsSL https://vite.plus | bash` (set `VP_VERSION` to pin a
+  version).

package/skills/void/docs/node_modules/void/node_modules/@void/md/node_modules/vite-plus/docs/guide/env.md

@@ -6,6 +6,17 @@
 
 Managed mode is on by default, so `node`, `npm`, and related shims resolve through Vite+ and pick the right Node.js version for the current project.
 
+The project Node.js version is resolved from these sources, in priority order:
+
+1. `.node-version` file (current or parent directories)
+2. `devEngines.runtime` in `package.json` (the [devEngines standard](https://docs.npmjs.com/cli/v11/configuring-npm/package-json#devengines))
+3. `engines.node` in `package.json`
+4. The global default (`vp env default`), then the latest LTS
+
+`devEngines.runtime` ranks above `engines.node` because it declares the development-environment requirement, while `engines.node` is a consumer-facing support range. `vp env doctor` warns when declared sources conflict.
+
+When a project declares `packageManager` (or `devEngines.packageManager`) in `package.json`, matching package-manager shims also use that package-manager version. For example, `packageManager: "npm@10.9.4"` makes both `npm` and `npx` run through npm 10.9.4. Alias pairs follow the installed package-manager shims: `npm`/`npx`, `pnpm`/`pnpx`, `yarn`/`yarnpkg`, and `bun`/`bunx`. Vite+ does not translate mismatched commands, so a project pinned to `pnpm` still lets `npm` fall back to the npm that comes with the resolved Node.js runtime.
+
 By default, Vite+ stores its managed runtime and related files in `~/.vite-plus`. If needed, you can override that location with `VP_HOME`.
 
 If you want to keep that behavior, run:
@@ -28,16 +39,38 @@ This switches to system-first mode, where the shims prefer your system Node.js a
 
 ### Setup
 
-- `vp env setup` creates or updates shims in `VP_HOME/bin`
+- `vp env setup` creates or updates shims in `VP_HOME/bin` (and writes the per-shell setup scripts under `~/.vite-plus/`)
 - `vp env on` enables managed mode so shims always use Vite+-managed Node.js
 - `vp env off` enables system-first mode so shims prefer system Node.js first
 - `vp env print` prints the shell snippet for the current session
 
+PowerShell needs to dot-source the generated setup script in the current shell before `vp env use` can affect only that shell session:
+
+```powershell
+. "$env:USERPROFILE\.vite-plus\env.ps1"
+```
+
+Add that line to the end of your PowerShell `$PROFILE` to apply it automatically in new shells. It does not require elevated privileges.
+
+Create the profile file if it does not already exist:
+
+```powershell
+if (-not (Test-Path $PROFILE)) { New-Item $PROFILE -Force }
+```
+
+Open the profile file for editing:
+
+```powershell
+Invoke-Item $PROFILE
+```
+
+In CI, `vp env use` can still run without shell initialization. It writes a temporary session file under `VP_HOME` so later shim calls in the same job can resolve the selected Node.js version.
+
 ### Manage
 
 - `vp env default` sets or shows the global default Node.js version
-- `vp env pin` pins a Node.js version in the current directory
-- `vp env unpin` removes `.node-version` from the current directory
+- `vp env pin` pins a Node.js version in the current directory: an existing `.node-version` keeps being updated; otherwise the pin is written to `package.json#devEngines.runtime`; `.node-version` is only created when the directory has no `package.json`. Use `--target node-version` or `--target dev-engines` to choose explicitly. An existing `engines.node` is never modified.
+- `vp env unpin` removes the pin from the same source `vp env pin` would write
 - `vp env use` sets a Node.js version for the current shell session
 - `vp env install` installs a Node.js version
 - `vp env uninstall` removes an installed Node.js version
@@ -54,7 +87,7 @@ This switches to system-first mode, where the shims prefer your system Node.js a
 
 ## Project Setup
 
-- Pin a project version with `.node-version`
+- Pin a project version with `vp env pin`
 - Use `vp install`, `vp dev`, and `vp build` normally
 - Let Vite+ pick the right runtime for the project
 
@@ -62,7 +95,7 @@ This switches to system-first mode, where the shims prefer your system Node.js a
 
 ```bash
 # Setup
-vp env setup                  # Create shims for node, npm, npx
+vp env setup                  # Create shims for node, npm, npx, corepack
 vp env on                     # Use Vite+ managed Node.js
 vp env print                  # Print shell snippet for this session
 
@@ -77,6 +110,7 @@ vp env use --unset            # Remove the session override
 vp env current                # Show current resolved environment
 vp env current --json         # JSON output for automation
 vp env which node             # Show which node binary will be used
+vp env which npx              # Show pinned package-manager alias when packageManager matches
 vp env list-remote --lts      # List only LTS versions
 
 # Execute
@@ -86,6 +120,25 @@ vp node script.js             # Shorthand: run a Node.js script with the resolve
 vp node -e "console.log(1+1)" # Shorthand: forward any node flag or argument
 ```
 
+## Corepack
+
+Vite+ creates a `corepack` shim by default, so corepack works without a system Node.js installation:
+
+- On Node.js 24 and earlier, the shim runs the corepack bundled with the resolved Node.js version.
+- On Node.js 25 and later, where corepack is no longer bundled, Vite+ installs corepack as a managed global package on first use. Only the `corepack` binary is linked; run `vp install -g corepack` yourself if you also want the package's pnpm/yarn launchers exposed directly.
+- If you install corepack explicitly with `vp install -g corepack`, that installation is always preferred.
+
+`corepack enable` normally creates `pnpm`/`yarn` launchers next to the corepack binary, which under Vite+ would not be on `PATH`. The shim fixes this by defaulting `--install-directory` to `VP_HOME/bin`, so after `corepack enable` the launchers are available everywhere and still resolve the project's Node.js and package-manager versions:
+
+```bash
+corepack enable               # pnpm and yarn now resolve via corepack
+corepack disable              # Remove the pnpm/yarn launchers again
+```
+
+The launchers reference the corepack copy that created them. If that copy is later removed (for example by uninstalling the Node.js version it shipped with), rerun `corepack enable` to recreate them.
+
+Shims owned by Vite+ (`npm`, `npx`, and binaries installed with `vp install -g`) are protected: if corepack removes or replaces them, Vite+ restores them and prints a warning.
+
 ## Custom Node.js Mirror
 
 By default, Vite+ downloads Node.js from `https://nodejs.org/dist`. If you're behind a corporate proxy or need to use an internal mirror (e.g., Artifactory), set the `VP_NODE_DIST_MIRROR` environment variable:
@@ -100,3 +153,15 @@ VP_NODE_DIST_MIRROR=https://my-mirror.example.com/nodejs/dist vp env default lts
 # Set it permanently in your shell profile (.bashrc, .zshrc, etc.)
 echo 'export VP_NODE_DIST_MIRROR=https://my-mirror.example.com/nodejs/dist' >> ~/.zshrc
 ```
+
+## Node.js Signature Verification
+
+When installing Node.js from the official `nodejs.org` distribution, Vite+ downloads the PGP-signed `SHASUMS256.txt.asc` and verifies it against the bundled Node.js release keys before trusting any checksum. This protects against a tampered `SHASUMS256.txt` paired with a matching malicious archive. The SHA-256 checksum of the downloaded archive is always verified afterward.
+
+Custom mirrors (`VP_NODE_DIST_MIRROR`) that publish only the plain `SHASUMS256.txt` fall back to checksum-only verification. A mirror that does publish a `.asc` still has its signature verified, and an invalid signature is a hard error.
+
+If a future keyring or certificate issue blocks downloads, set `VP_NODE_SKIP_SIGNATURE_VERIFY` to temporarily bypass PGP verification. The SHA-256 checksum is still verified, and Vite+ prints a warning when the signature check is skipped:
+
+```bash
+VP_NODE_SKIP_SIGNATURE_VERIFY=1 vp env install 22
+```