void 0.10.5 → 0.10.6

package/skills/void/docs/node_modules/void/node_modules/pg/README.md

@@ -18,6 +18,7 @@ $ npm install pg
 
 ### Features
 
+- [Fastest PostgreSQL client for Node.js](https://github.com/nigrosimone/postgres-benchmarks)
 - Pure JavaScript client and native libpq bindings share _the same API_
 - Connection pooling
 - Extensible JS ↔ PostgreSQL data-type coercion
@@ -42,7 +43,7 @@ When you open an issue please provide:
 - version of Postgres
 - smallest possible snippet of code to reproduce the problem
 
-You can also follow me [@briancarlson](https://twitter.com/briancarlson) if that's your thing. I try to always announce noteworthy changes & developments with node-postgres on Twitter.
+You can also follow me [@brianc](https://bsky.app/profile/brianc.bsky.social) on bluesky if that's your thing for updates on node-postgres with nearly zero non node-postgres content. My old twitter/x account is no longer used.
 
 ## Sponsorship :two_hearts:
 

package/skills/void/docs/node_modules/void/node_modules/tinyglobby/README.md

@@ -1,7 +1,7 @@
 # tinyglobby
 
 [![npm version](https://img.shields.io/npm/v/tinyglobby.svg?maxAge=3600)](https://npmjs.com/package/tinyglobby)
-[![monthly downloads](https://img.shields.io/npm/dm/tinyglobby.svg?maxAge=3600)](https://npmjs.com/package/tinyglobby)
+[![weekly downloads](https://img.shields.io/npm/dw/tinyglobby.svg?maxAge=3600)](https://npmjs.com/package/tinyglobby)
 
 A fast and minimal alternative to globby and fast-glob, meant to behave the same way.
 

package/skills/void/docs/node_modules/void/node_modules/vite-plus/AGENTS.md

@@ -11,5 +11,6 @@ Docs are local at `node_modules/vite-plus/docs` or online at https://viteplus.de
 - [ ] Run `vp install` after pulling remote changes and before getting started.
 - [ ] Run `vp check` and `vp test` to format, lint, type check and test changes.
 - [ ] Check if there are `vite.config.ts` tasks or `package.json` scripts necessary for validation, run via `vp run <script>`.
+- [ ] If setup, runtime, or package-manager behavior looks wrong, run `vp env doctor` and include its output when asking for help.
 
 <!--VITE PLUS END-->

package/skills/void/docs/node_modules/void/node_modules/vite-plus/README.md

@@ -3,7 +3,7 @@
 **The Unified Toolchain for the Web**
 _runtime and package management, create, dev, check, test, build, pack, and monorepo task caching in a single dependency_
 
-This package provides the project-local version of Vite+. The global `vite` command automatically delegates to this package for all project-specific tasks.
+This package provides the project-local version of Vite+. The global `vp` command automatically delegates to this package for all project-specific tasks.
 
 ---
 
@@ -111,6 +111,7 @@ Use `vp migrate` to migrate to Vite+. It merges tool-specific config files such
 
 - **run** - Run monorepo tasks
 - **exec** - Execute a command from local `node_modules/.bin`
+- **node** - Run a Node.js script with the resolved Vite+ environment
 - **dlx** - Execute a package binary without installing it as a dependency
 - **cache** - Manage the task cache
 
@@ -122,7 +123,7 @@ Use `vp migrate` to migrate to Vite+. It merges tool-specific config files such
 
 #### Manage Dependencies
 
-Vite+ automatically wraps your package manager (pnpm, npm, or Yarn) based on `packageManager` and lockfiles:
+Vite+ automatically wraps your package manager (pnpm, npm, Yarn, or Bun) based on `packageManager` and lockfiles:
 
 - **add** - Add packages to dependencies
 - **remove** (`rm`, `un`, `uninstall`) - Remove packages from dependencies
@@ -133,6 +134,7 @@ Vite+ automatically wraps your package manager (pnpm, npm, or Yarn) based on `pa
 - **why** (`explain`) - Show why a package is installed
 - **info** (`view`, `show`) - View package metadata from the registry
 - **link** (`ln`) / **unlink** - Manage local package links
+- **rebuild** - Rebuild native modules
 - **pm** - Forward a command to the package manager
 
 #### Maintain
@@ -150,6 +152,16 @@ vp create
 
 You can run `vp create` inside of a project to add new apps or libraries to your project.
 
+Organizations can expose a curated set of templates under their npm scope by
+publishing `@org/create` with a `createConfig.templates` manifest in its `package.json`.
+Once published, `vp create @org` opens an interactive picker over those
+templates, and setting `create: { defaultTemplate: '@org' }` in
+`vite.config.ts` makes it the default for bare `vp create`. See the
+[Organization Templates guide](https://viteplus.dev/guide/create#organization-templates)
+for the authoring workflow and
+[`create.defaultTemplate`](https://viteplus.dev/config/create) for the
+config reference.
+
 ### Migrating an existing project
 
 You can migrate an existing project to Vite+:
@@ -177,12 +189,12 @@ If you are manually migrating a project to Vite+, install these dev dependencies
 npm install -D vite-plus @voidzero-dev/vite-plus-core@latest
 ```
 
-You need to add overrides to your package manager for `vite` and `vitest` so that other packages depending on Vite and Vitest will use the Vite+ versions:
+You need to add overrides to your package manager so that other packages resolve the Vite+ versions: alias `vite` to `@voidzero-dev/vite-plus-core`, and pin `vitest` to the version Vite+ bundles (run `vp --version`) so the whole project shares a single Vitest copy with `vp test`. Without the `vitest` pin, a dependency or workspace package can pull a different Vitest than the bundled runner, splitting Vitest's internals (mocks, `expect`, runner state):
 
 ```json
 "overrides": {
   "vite": "npm:@voidzero-dev/vite-plus-core@latest",
-  "vitest": "npm:@voidzero-dev/vite-plus-test@latest"
+  "vitest": "4.1.9"
 }
 ```
 
@@ -191,7 +203,7 @@ If you are using `pnpm`, add this to your `pnpm-workspace.yaml`:
 ```yaml
 overrides:
   vite: npm:@voidzero-dev/vite-plus-core@latest
-  vitest: npm:@voidzero-dev/vite-plus-test@latest
+  vitest: 4.1.9
 ```
 
 Or, if you are using Yarn:
@@ -199,7 +211,7 @@ Or, if you are using Yarn:
 ```json
 "resolutions": {
   "vite": "npm:@voidzero-dev/vite-plus-core@latest",
-  "vitest": "npm:@voidzero-dev/vite-plus-test@latest"
+  "vitest": "4.1.9"
 }
 ```
 

package/skills/void/docs/node_modules/void/node_modules/vite-plus/docs/config/build.md

@@ -4,7 +4,7 @@
 
 ## Example
 
-```ts
+```ts [vite.config.ts]
 import { defineConfig } from 'vite-plus';
 
 export default defineConfig({

package/skills/void/docs/node_modules/void/node_modules/vite-plus/docs/config/check.md

@@ -0,0 +1,35 @@
+# Check Config
+
+`vp check` runs format, lint, and type checks together. The `check` block in `vite.config.ts` sets defaults for the composite command, mirroring the `--no-fmt` and `--no-lint` CLI flags.
+
+This is useful when a project wants to keep most of the toolchain but skip one step by default. For example, a team that lints but does not format can disable `check.fmt` so a plain `vp check` (the command agents and contributors run most) only lints, without anyone needing to remember `--no-fmt`.
+
+## Example
+
+```ts [vite.config.ts]
+import { defineConfig } from 'vite-plus';
+
+export default defineConfig({
+  check: {
+    // Skip the format step in `vp check`. Defaults to true.
+    fmt: false,
+    // Skip lint rules in `vp check`. Type-check still runs when both
+    // `lint.options.typeAware` and `lint.options.typeCheck` are enabled.
+    // Defaults to true.
+    lint: true,
+  },
+});
+```
+
+When a step is disabled here, `vp check` prints a short `note:` line so it is clear why the step did not run. With the `check.fmt: false` config above:
+
+```bash
+$ vp check
+note: Format skipped (check.fmt: false in vite.config.ts)
+pass: Found no warnings or lint errors in 1 file (12ms, 8 threads)
+```
+
+## Scope and precedence
+
+- These options only affect the composite `vp check`. Standalone [`vp fmt`](/config/fmt) and [`vp lint`](/config/lint) are unaffected, so you can still run a disabled tool directly when you need it once. Note that any `vp check` invocation honors these defaults, including one run from a pre-commit hook: if your [`staged`](/config/staged) tasks call `vp check`, that step is skipped there too.
+- A step is skipped if the config disables it **or** the matching CLI flag is passed. There is no flag to re-enable a step disabled in config; run `vp fmt` or `vp lint` directly instead.

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

@@ -0,0 +1,70 @@
+# Create Config
+
+`vp create` reads the `create` block in `vite.config.ts` to set per-repo defaults. See the [Creating a Project guide](/guide/create#organization-templates) for the full `@org` template workflow.
+
+## `create.defaultTemplate`
+
+When `vp create` is invoked with no `TEMPLATE` argument, Vite+ uses this value as if the user had typed it. Typically set to an npm scope whose `@scope/create` package publishes a `createConfig.templates` manifest — so bare `vp create` drops into the org picker.
+
+```ts
+import { defineConfig } from 'vite-plus';
+
+export default defineConfig({
+  create: {
+    defaultTemplate: '@your-org',
+  },
+});
+```
+
+Any value accepted by `vp create` as a first argument works here: `@your-org` for an org picker, `@your-org:web` for a direct manifest entry, `vite:application` for a built-in, or the `name` of a local `create.templates` entry (see below).
+
+## `create.templates`
+
+Declare local templates available to `vp create` inside a monorepo. Each entry is listed in the `vp create` picker, and selecting it (or passing its `name` as the template argument) runs the resolved `template`.
+
+```ts
+import { defineConfig } from 'vite-plus';
+
+export default defineConfig({
+  create: {
+    templates: [
+      {
+        name: 'component',
+        description: 'Internal UI component',
+        template: './tools/create-component',
+      },
+      { name: 'service', description: 'Backend service', template: 'service-generator' },
+    ],
+  },
+});
+```
+
+Each entry has:
+
+| Field         | Required | Notes                                                                                                                                                                                                                                            |
+| ------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `name`        | yes      | Identifier shown in the picker and accepted as `vp create <name>`. Must be unique within the array. The `vite:` prefix is reserved for built-in templates.                                                                                       |
+| `description` | yes      | One-line description shown in the picker.                                                                                                                                                                                                        |
+| `template`    | yes      | A workspace package name, a relative `./path` to a local package's directory (resolved against the workspace root), a `vite:*` built-in, a GitHub URL, or a full npm package name (e.g. `create-foo`). It is run as-is (not shorthand-expanded). |
+
+`create.templates` is the source of truth for local templates: only entries listed here appear in the picker. Vite+ does not infer templates from package.json keywords. A `create.templates` entry whose `template` does not match any workspace package, or resolves to a local package without a `bin`, is reported as an error rather than falling through to an unrelated npm package.
+
+[`vp create vite:generator`](/guide/create#code-generators) adds an entry here automatically (idempotently, preserving `defaultTemplate`); you can also edit the list by hand.
+
+`create.defaultTemplate` can name a local entry, so bare `vp create` opens it directly.
+
+## Precedence
+
+CLI argument > `create.defaultTemplate` > the standard built-in picker.
+
+Explicit specifiers always win, so scripts and CI can bypass the configured default:
+
+```bash
+# Uses create.defaultTemplate
+vp create
+
+# Explicitly ignores the default
+vp create vite:library
+```
+
+The org picker also appends a trailing "Vite+ built-in templates" entry — selecting it routes to the `vite:monorepo` / `vite:application` / `vite:library` / `vite:generator` flow, so built-ins stay reachable interactively even when a default is configured.

package/skills/void/docs/node_modules/void/node_modules/vite-plus/docs/config/fmt.md

@@ -4,7 +4,7 @@
 
 ## Example
 
-```ts
+```ts [vite.config.ts]
 import { defineConfig } from 'vite-plus';
 
 export default defineConfig({
@@ -16,3 +16,5 @@ export default defineConfig({
   },
 });
 ```
+
+For package-specific formatting settings in a workspace, use [`fmt.overrides`](/guide/monorepo#format-overrides) from the root `vite.config.ts`.

package/skills/void/docs/node_modules/void/node_modules/vite-plus/docs/config/index.md

@@ -2,7 +2,7 @@
 
 Vite+ keeps project configuration in one place: `vite.config.ts`, allowing you to consolidate many top-level configuration files in a single file. You can keep using your Vite configuration such as `server` or `build`, and add Vite+ blocks for the rest of your workflow:
 
-```ts
+```ts [vite.config.ts]
 import { defineConfig } from 'vite-plus';
 
 export default defineConfig({
@@ -10,10 +10,12 @@ export default defineConfig({
   build: {},
   preview: {},
 
-  test: {},
-  lint: {},
-  fmt: {},
+  create: {},
   run: {},
+  fmt: {},
+  lint: {},
+  check: {},
+  test: {},
   pack: {},
   staged: {},
 });
@@ -23,9 +25,11 @@ export default defineConfig({
 
 Vite+ extends the basic Vite configuration with these additions:
 
-- [`lint`](/config/lint) for Oxlint
+- [`create`](/config/create) for project and template scaffolding defaults
+- [`run`](/config/run) for Vite Task
 - [`fmt`](/config/fmt) for Oxfmt
+- [`lint`](/config/lint) for Oxlint
+- [`check`](/config/check) for `vp check` defaults
 - [`test`](/config/test) for Vitest
-- [`run`](/config/run) for Vite Task
 - [`pack`](/config/pack) for tsdown
-- [`staged`](/config/staged) for staged-file checks
+- [`staged`](/config/staged) for staged-file checks

package/skills/void/docs/node_modules/void/node_modules/vite-plus/docs/config/lint.md

@@ -4,7 +4,7 @@
 
 ## Example
 
-```ts
+```ts [vite.config.ts]
 import { defineConfig } from 'vite-plus';
 
 export default defineConfig({
@@ -22,3 +22,5 @@ export default defineConfig({
 ```
 
 We recommend enabling both `options.typeAware` and `options.typeCheck` so `vp lint` and `vp check` can use the full type-aware path.
+
+For package-specific lint rules in a workspace, use [`lint.overrides`](/guide/monorepo#root-config-with-overrides) from the root `vite.config.ts`.

package/skills/void/docs/node_modules/void/node_modules/vite-plus/docs/config/pack.md

@@ -4,7 +4,7 @@
 
 ## Example
 
-```ts
+```ts [vite.config.ts]
 import { defineConfig } from 'vite-plus';
 
 export default defineConfig({

package/skills/void/docs/node_modules/void/node_modules/vite-plus/docs/config/run.md

@@ -2,7 +2,7 @@
 
 You can configure Vite Task under the `run` field in `vite.config.ts`. Check out [`vp run`](/guide/run) to learn more about running scripts and tasks with Vite+.
 
-```ts
+```ts [vite.config.ts]
 import { defineConfig } from 'vite-plus';
 
 export default defineConfig({
@@ -27,7 +27,7 @@ Whether to automatically run `preX`/`postX` package.json scripts as lifecycle ho
 
 When enabled (the default), running a script like `test` will automatically run `pretest` before it and `posttest` after it, if they exist in `package.json`.
 
-```ts
+```ts [vite.config.ts]
 export default defineConfig({
   run: {
     enablePrePostScripts: false, // Disable pre/post lifecycle hooks
@@ -46,7 +46,7 @@ This option can only be set in the workspace root's `vite.config.ts`. Setting it
 
 Controls whether task results are cached and replayed on subsequent runs.
 
-```ts
+```ts [vite.config.ts]
 export default defineConfig({
   run: {
     cache: {
@@ -61,17 +61,37 @@ export default defineConfig({
 
 ## `run.tasks`
 
-- **Type:** `Record<string, TaskConfig>`
+- **Type:** `Record<string, Task | string | string[]>`
 
 Defines tasks that can be run with `vp run <task>`.
 
+As a shorthand, a task value can be a command string or an array of command strings directly:
+
+```ts [vite.config.ts]
+tasks: {
+  build: 'vp build',
+  check: ['vp lint', 'vp build'],
+}
+```
+
+These are equivalent to setting only `command` on a task config:
+
+```ts [vite.config.ts]
+tasks: {
+  build: { command: 'vp build' },
+  check: { command: ['vp lint', 'vp build'] },
+}
+```
+
+Use the object form when a task needs other fields like `cache`, `dependsOn`, `env`, or `input`.
+
 ### `command`
 
-- **Type:** `string`
+- **Type:** `string | string[]`
 
-Defines the shell command to run for the task.
+Defines the shell command to run for the task. The string is interpreted by a shell, so spaces, quoting, `&&`, pipes, and redirects all work as written on the command line.
 
-```ts
+```ts [vite.config.ts]
 tasks: {
   build: {
     command: 'vp build',
@@ -79,18 +99,35 @@ tasks: {
 }
 ```
 
+An array runs each entry as its own command, sequentially, equivalent to joining them with `&&`. It is **not** a way to split one command into argv tokens — `['vp', 'build']` would try to run a command called `vp` with no arguments, then a command called `build`, instead of `vp build`.
+
+```ts [vite.config.ts]
+tasks: {
+  check: {
+    // Two commands, run in order
+    command: ['vp lint', 'vp build'],
+  },
+  bad: {
+    // Wrong: this is NOT `vp build`; it is `vp` followed by `build`
+    command: ['vp', 'build'],
+  },
+}
+```
+
 Each task defined in `vite.config.ts` must include its own `command`. You cannot define a task in both `vite.config.ts` and `package.json` with the same task name.
 
-Commands joined with `&&` are automatically split into independently cached sub-tasks. See [Compound Commands](/guide/run#compound-commands).
+Commands joined with `&&` (or supplied as an array) are automatically split into independently cached sub-tasks. See [Compound Commands](/guide/run#compound-commands).
 
 ### `dependsOn`
 
-- **Type:** `string[]`
+- **Type:** `Array<string | { task: string, from: DependsOnFrom }>`
 - **Default:** `[]`
 
+`from` accepts the dependency types `"dependencies"`, `"devDependencies"`, `"peerDependencies"`, or an array of those values, such as `["dependencies", "devDependencies"]`.
+
 Tasks that must complete successfully before this one starts.
 
-```ts
+```ts [vite.config.ts]
 tasks: {
   deploy: {
     command: 'deploy-script --prod',
@@ -101,10 +138,23 @@ tasks: {
 
 Dependencies can reference tasks in other packages using the `package#task` format:
 
-```ts
+```ts [vite.config.ts]
 dependsOn: ['@my/core#build', '@my/utils#lint'];
 ```
 
+Use the object form `{ task: string, from: DependsOnFrom }` to reference tasks from all dependencies:
+
+```ts [vite.config.ts]
+tasks: {
+  test: {
+    command: 'vp test',
+    dependsOn: [{ task: 'build', from: ['dependencies', 'devDependencies'] }],
+  },
+}
+```
+
+For the example above, Vite Task reads the declaring package's direct `dependencies` and `devDependencies`, and runs the `build` task in each dependency that defines one. Packages without `build` are skipped.
+
 See [Task Dependencies](/guide/run#task-dependencies) for details on how explicit and topological dependencies interact.
 
 ### `cache`
@@ -114,7 +164,7 @@ See [Task Dependencies](/guide/run#task-dependencies) for details on how explici
 
 Whether to cache this task's output. Set to `false` for tasks that should never be cached, like dev servers:
 
-```ts
+```ts [vite.config.ts]
 tasks: {
   dev: {
     command: 'vp dev',
@@ -130,20 +180,22 @@ tasks: {
 
 Environment variables included in the cache fingerprint. When any listed variable's value changes, the cache is invalidated.
 
-```ts
+```ts [vite.config.ts]
 tasks: {
   build: {
-    command: 'vp build',
+    command: 'node build.mjs',
     env: ['NODE_ENV'],
   },
 }
 ```
 
-Wildcard patterns are supported: `VITE_*` matches all variables starting with `VITE_`.
+Wildcard patterns and `!` exclusion patterns are supported: `VITE_*` matches all variables starting with `VITE_`, and `!VITE_SECRET` excludes the `VITE_SECRET` variable from the match.
+
+For `vp build`, Vite reports Vite environment variables through [automatic tracking](/guide/automatic-data-tracking#cooperative-tracking). Do not add `VITE_*` or `NODE_ENV` here for a standard Vite build unless your project has extra build behavior Vite cannot report.
 
 ```bash
 $ NODE_ENV=development vp run build    # first run
-$ NODE_ENV=production vp run build     # cache miss: variable changed
+$ NODE_ENV=production vp run build     # cache miss: env 'NODE_ENV' changed
 ```
 
 ### `untrackedEnv`
@@ -153,32 +205,36 @@ $ NODE_ENV=production vp run build     # cache miss: variable changed
 
 Environment variables passed to the task process but **not** included in the cache fingerprint. Changing these values won't invalidate the cache.
 
-```ts
+```ts [vite.config.ts]
 tasks: {
   build: {
-    command: 'vp build',
+    command: 'node build.mjs',
     untrackedEnv: ['CI', 'GITHUB_ACTIONS'],
   },
 }
 ```
 
-A set of common environment variables are automatically passed through to all tasks:
+`untrackedEnv` accepts the same wildcard and `!` exclusion patterns as [`env`](#env).
+
+Do not put a variable in `untrackedEnv` if its value changes the task result. If a cache-reporting tool covers the variable through [automatic tracking](/guide/automatic-data-tracking#cooperative-tracking), leave it out of both `env` and `untrackedEnv`.
+
+Vite Task passes a set of common environment variables to all tasks:
 
 - **System:** `HOME`, `USER`, `PATH`, `SHELL`, `LANG`, `TZ`
 - **Node.js:** `NODE_OPTIONS`, `COREPACK_HOME`, `PNPM_HOME`
 - **CI/CD:** `CI`, `VERCEL_*`, `NEXT_*`
-- **Terminal:** `TERM`, `COLORTERM`, `FORCE_COLOR`, `NO_COLOR`
+- **Terminal:** Color variables (`FORCE_COLOR`, `NO_COLOR`, `COLORTERM`, `TERM`, `TERM_PROGRAM`) aren't passed to tasks unless you list them under `env` (the value gets fingerprinted, so changing it invalidates the cache) or `untrackedEnv` (passed without fingerprinting). If `FORCE_COLOR` isn't in either list, the child gets `FORCE_COLOR=1` so cached logs stay colored. Colors get stripped on display when the terminal can't render them.
 
 ### `input`
 
 - **Type:** `Array<string | { auto: boolean } | { pattern: string, base: "workspace" | "package" }>`
 - **Default:** `[{ auto: true }]` (auto-inferred)
 
-Vite Task automatically detects which files are used by a command (see [Automatic File Tracking](/guide/cache#automatic-file-tracking)). The `input` option can be used to explicitly include or exclude certain files.
+Vite Task automatically detects which files a command uses. See [Automatic Data Tracking](/guide/automatic-data-tracking) for the details and when to add manual config.
 
 **Exclude files** from automatic tracking:
 
-```ts
+```ts [vite.config.ts]
 tasks: {
   build: {
     command: 'vp build',
@@ -190,7 +246,7 @@ tasks: {
 
 **Specify explicit files** only without automatic tracking:
 
-```ts
+```ts [vite.config.ts]
 tasks: {
   build: {
     command: 'vp build',
@@ -201,7 +257,7 @@ tasks: {
 
 **Resolve patterns relative to the workspace root** using the object form:
 
-```ts
+```ts [vite.config.ts]
 tasks: {
   build: {
     command: 'vp build',
@@ -214,12 +270,13 @@ tasks: {
 ```
 
 The `base` field is required and controls how the glob pattern is resolved:
+
 - `"package"`: relative to the package directory
 - `"workspace"`: relative to the workspace root
 
 **Disable file tracking** entirely and cache only on command/env changes:
 
-```ts
+```ts [vite.config.ts]
 tasks: {
   greet: {
     command: 'node greet.mjs',
@@ -232,6 +289,64 @@ tasks: {
 String glob patterns are resolved relative to the package directory by default. Use the object form with `base: "workspace"` to resolve relative to the workspace root.
 :::
 
+### `output`
+
+- **Type:** `Array<string | { auto: boolean } | { pattern: string, base: "workspace" | "package" }>`
+- **Default:** automatic write tracking
+
+Vite Task automatically archives files generated by a successful task run and restores them on a cache hit.
+
+If you omit `output`, Vite Task uses automatic write tracking to choose those files. Add explicit `output` entries when you need to override which files are restored.
+
+```ts [vite.config.ts]
+tasks: {
+  build: {
+    command: 'node build.mjs',
+    output: ['dist/**', '!dist/cache/**'],
+  },
+}
+```
+
+Use `{ auto: true }` to keep automatic write tracking while adding explicit output globs.
+
+This is useful when a task writes files that should not be restored from the cache. For example, exclude TypeScript `.tsbuildinfo` files:
+
+```ts [vite.config.ts]
+tasks: {
+  typecheck: {
+    command: 'tsc --build',
+    output: [{ auto: true }, '!*.tsbuildinfo'],
+  },
+}
+```
+
+If a task writes outside its own package, use the object form with `base: "workspace"`:
+
+```ts [vite.config.ts]
+tasks: {
+  build: {
+    command: 'node build.mjs',
+    output: [
+      'dist/**',
+      { pattern: 'shared-artifacts/**', base: 'workspace' },
+    ],
+  },
+}
+```
+
+Set `output: []` to disable output restoration for a cached task:
+
+```ts [vite.config.ts]
+tasks: {
+  report: {
+    command: 'node scripts/report.mjs',
+    output: [],
+  },
+}
+```
+
+Unlike `cache: false`, `output: []` still lets Vite Task fingerprint the task. On a cache hit, Vite Task skips the command and replays its terminal output. Use this for local caches when the task's output files are already there and do not need to be restored.
+
 ### `cwd`
 
 - **Type:** `string`
@@ -239,7 +354,7 @@ String glob patterns are resolved relative to the package directory by default.
 
 Working directory for the task, relative to the package root.
 
-```ts
+```ts [vite.config.ts]
 tasks: {
   'test-e2e': {
     command: 'vp test',

package/skills/void/docs/node_modules/void/node_modules/vite-plus/docs/config/staged.md

@@ -4,7 +4,7 @@
 
 ## Example
 
-```ts
+```ts [vite.config.ts]
 import { defineConfig } from 'vite-plus';
 
 export default defineConfig({

package/skills/void/docs/node_modules/void/node_modules/vite-plus/docs/config/test.md

@@ -4,7 +4,7 @@
 
 ## Example
 
-```ts
+```ts [vite.config.ts]
 import { defineConfig } from 'vite-plus';
 
 export default defineConfig({