@visulima/vis 4.3.1 → 6.0.0

package/schemas/vis-config.schema.json

@@ -157,6 +157,13 @@
                     "description": "Default giget provider for `owner/repo` shorthand inputs.",
                     "default": "github"
                 },
+                "defaultTemplate": {
+                    "type": "string",
+                    "description": "Template used by a bare `vis create`. Accepts any template input, including an organization scope (`@acme` opens the `@acme/create` manifest picker, `@acme:app` selects one entry directly). In a terminal the usual prompts still run, minus the template step.",
+                    "examples": [
+                        "@acme"
+                    ]
+                },
                 "gitInit": {
                     "type": "boolean",
                     "description": "Initialize a git repository after scaffolding standalone projects.",
@@ -248,9 +255,6 @@
                         "biome": {
                             "$ref": "#/$defs/LintFmtAdapterOverride"
                         },
-                        "deno-fmt": {
-                            "$ref": "#/$defs/LintFmtAdapterOverride"
-                        },
                         "dprint": {
                             "$ref": "#/$defs/LintFmtAdapterOverride"
                         },
@@ -283,7 +287,7 @@
                 }
             },
             "additionalProperties": false,
-            "description": "Configuration for `vis fmt` — the formatter orchestrator.\n\nTunes adapter detection precedence, per-extension routing, and per-adapter overrides. Flags on the CLI always win over config.\n\nThe default fmt precedence is `oxfmt → biome → dprint → prettier → deno-fmt`. When multiple adapters claim the same extension, the first in this order owns it unless overridden here."
+            "description": "Configuration for `vis fmt` — the formatter orchestrator.\n\nTunes adapter detection precedence, per-extension routing, and per-adapter overrides. Flags on the CLI always win over config.\n\nThe default fmt precedence is `oxfmt → biome → dprint → prettier`. When multiple adapters claim the same extension, the first in this order owns it unless overridden here."
         },
         "gem": {
             "type": "object",
@@ -360,7 +364,7 @@
                     "type": "boolean"
                 }
             ],
-            "description": "Auto-create targets from detected config files (Project Crystal-style). Detectors run by default; set `false` to disable them entirely, or use the object form to disable individual ones. See the note at the bottom of this block for what \"unset\" allows versus an explicit `true`.\n\nInferred targets sit *below* explicit ones — the command from `package.json#scripts`, `project.json#targets`, or `vis.task.ts` always wins per-key, so enrichment never changes what runs. As a caching aid, when a `package.json` script's command *is* a detector's command (optionally with extra flags, no shell chaining) and the script declares no `inputs`/`outputs`, the detector's `inputs`/`outputs` are adopted so the script target can cache precisely and restore its artifacts. Customised/compound scripts are left untouched.\n\nBuilt-in detectors and the targets they synthesize:\n\n- **App frameworks** — `nuxt` (build/dev/preview/generate),   `next` (build/dev/start), `remix` (build/dev/start), `astro`   (build/dev), `gatsby` (build/develop/serve), `docusaurus`   (build/start/serve).\n- **Bundlers** — `vite` (build/dev/preview), `rolldown` (build),   `tsdown` (build), `tsup` (build), `packem` (build), `rollup`   (build), `webpack` (build).\n- **Docs sites** — `vitepress` (docs:build/docs:dev/docs:preview),   `typedoc` (docs).\n- **Server frameworks** — `nest` (build/start/start:dev).\n- **Test runners** — `vitest` (test/test:watch), `jest`   (test/test:watch), `bun` (test), `playwright` (test:e2e),   `cypress` (test:e2e/cypress:open).\n- **Stories** — `storybook` (storybook/build-storybook).\n- **Type checking** — `typescript` (typecheck via `tsc --noEmit`).\n- **Lint / format** — `eslint` (lint), `prettier` (format /   format:check), `biome` (lint, format), `oxlint` (lint),   `oxfmt` (format / format:check), `stylelint` (lint:css),   `knip` (knip).\n- **Runtimes** — `deno` (test/lint/fmt/check).\n- **Database tooling** — `prisma` (db:generate/db:migrate/   db:push/db:studio), `drizzle` (db:generate/db:migrate/   db:push/db:studio).\n- **Codegen / release** — `graphql-codegen` (codegen),   `api-extractor` (api-extract), `changeset` (changeset:version /   changeset:publish / changeset:status).\n\nTrigger: presence of any matching config file in the project root. Most detectors additionally match when their framework appears in `dependencies` / `devDependencies` / `peerDependencies` / `optionalDependencies` — covering convention-only setups (e.g. vitest with default config). Detectors that intentionally require a config file (because the package frequently appears transitively and a dep-only match would synthesize broken commands): `vite`, `rolldown`, `rollup`, `webpack`, `storybook`, `nest`, `remix`, `vitepress`, `bun`, `deno`, `changeset`.\n\nConflict resolution: detectors are evaluated in registration order (see `BUILT_IN_DETECTORS`) and the first to claim a target name wins. Per-name priorities: `build` → nuxt > next > remix > astro > gatsby > docusaurus > vite > nest > rolldown > tsdown > tsup > packem > rollup > webpack; `test` → vitest > jest > bun > deno; `test:e2e` → playwright > cypress; `lint` → eslint > biome > oxlint > deno; `format` → prettier > biome > oxfmt; `db:*` → prisma > drizzle.\n\nAlso accepts an object form (`{ vite: false, vitest: true }`) to opt individual detectors in or out by name. Detectors omitted from the object run at their default (enabled). Useful when one detector misfires for a given workspace without disabling the rest.\n\n**Leaving this unset is not the same as setting `true`.** Detectors always *enrich* the targets a project already has — adopting their `type`, `inputs` and `outputs`, which is the caching aid and changes nothing about what runs. *Synthesizing* a target the project never had does change what runs, so on the unset default it is limited to projects that declare no scripts and no targets of their own. Setting this to `true` (or the object form) opts in to synthesis everywhere.\n\nThe distinction exists because a package can deliberately omit a script: a shared eslint-config ships an `eslint.config.js` but no `lint` script, because linting its own flat-config export crashes eslint. Synthesizing `lint` there turned a package `pnpm -r run lint` had always skipped into a failing task, on a workspace that had never asked for inference.\n\nDeliberately no `@default` tag: there is no single value that describes the unset behaviour, and advertising `true` would invite tooling to write it into a config and silently widen synthesis."
+            "description": "Auto-create targets from detected config files (Project Crystal-style). Detectors run by default; set `false` to disable them entirely, or use the object form to disable individual ones. See the note at the bottom of this block for what \"unset\" allows versus an explicit `true`.\n\nInferred targets sit *below* explicit ones — the command from `package.json#scripts`, `project.json#targets`, or `vis.task.ts` always wins per-key, so enrichment never changes what runs. As a caching aid, when a `package.json` script's command *is* a detector's command (optionally with extra flags, no shell chaining) and the script declares no `inputs`/`outputs`, the detector's `inputs`/`outputs` are adopted so the script target can cache precisely and restore its artifacts. Customised/compound scripts are left untouched.\n\nBuilt-in detectors and the targets they synthesize:\n\n- **App frameworks** — `nuxt` (build/dev/preview/generate),   `next` (build/dev/start), `remix` (build/dev/start), `astro`   (build/dev), `gatsby` (build/develop/serve), `docusaurus`   (build/start/serve).\n- **Bundlers** — `vite` (build/dev/preview), `rolldown` (build),   `tsdown` (build), `tsup` (build), `packem` (build), `rollup`   (build), `webpack` (build).\n- **Docs sites** — `vitepress` (docs:build/docs:dev/docs:preview),   `typedoc` (docs).\n- **Server frameworks** — `nest` (build/start/start:dev).\n- **Test runners** — `vitest` (test/test:watch), `jest`   (test/test:watch), `bun` (test), `playwright` (test:e2e),   `cypress` (test:e2e/cypress:open).\n- **Stories** — `storybook` (storybook/build-storybook).\n- **Type checking** — `typescript` (typecheck via `tsc --noEmit`).\n- **Lint / format** — `eslint` (lint), `prettier` (format /   format:check), `biome` (lint, format), `oxlint` (lint),   `oxfmt` (format / format:check), `stylelint` (lint:css),   `knip` (knip).\n- **Database tooling** — `prisma` (db:generate/db:migrate/   db:push/db:studio), `drizzle` (db:generate/db:migrate/   db:push/db:studio).\n- **Codegen / release** — `graphql-codegen` (codegen),   `api-extractor` (api-extract), `changeset` (changeset:version /   changeset:publish / changeset:status).\n\nTrigger: presence of any matching config file in the project root. Most detectors additionally match when their framework appears in `dependencies` / `devDependencies` / `peerDependencies` / `optionalDependencies` — covering convention-only setups (e.g. vitest with default config). Detectors that intentionally require a config file (because the package frequently appears transitively and a dep-only match would synthesize broken commands): `vite`, `rolldown`, `rollup`, `webpack`, `storybook`, `nest`, `remix`, `vitepress`, `bun`, `changeset`.\n\nConflict resolution: detectors are evaluated in registration order (see `BUILT_IN_DETECTORS`) and the first to claim a target name wins. Per-name priorities: `build` → nuxt > next > remix > astro > gatsby > docusaurus > vite > nest > rolldown > tsdown > tsup > packem > rollup > webpack; `test` → vitest > jest > bun; `test:e2e` → playwright > cypress; `lint` → eslint > biome > oxlint; `format` → prettier > biome > oxfmt; `db:*` → prisma > drizzle.\n\nAlso accepts an object form (`{ vite: false, vitest: true }`) to opt individual detectors in or out by name. Detectors omitted from the object run at their default (enabled). Useful when one detector misfires for a given workspace without disabling the rest.\n\n**Leaving this unset is not the same as setting `true`.** Detectors always *enrich* the targets a project already has — adopting their `type`, `inputs` and `outputs`, which is the caching aid and changes nothing about what runs. *Synthesizing* a target the project never had does change what runs, so on the unset default it is limited to projects that declare no scripts and no targets of their own. Setting this to `true` (or the object form) opts in to synthesis everywhere.\n\nThe distinction exists because a package can deliberately omit a script: a shared eslint-config ships an `eslint.config.js` but no `lint` script, because linting its own flat-config export crashes eslint. Synthesizing `lint` there turned a package `pnpm -r run lint` had always skipped into a failing task, on a workspace that had never asked for inference.\n\nDeliberately no `@default` tag: there is no single value that describes the unset behaviour, and advertising `true` would invite tooling to write it into a config and silently widen synthesis."
         },
         "install": {
             "type": "object",
@@ -388,7 +392,7 @@
                             "type": "boolean"
                         }
                     ],
-                    "description": "Whether to dispatch PM invocations through `corepack`.\n- `\"auto\"` (default): use corepack only when the workspace   pins a PM via the `packageManager` field AND `corepack` is   on PATH AND the PM is one corepack manages (pnpm/yarn/npm).\n- `true`: always prefix `corepack` when the binary is on PATH   and the PM is corepack-managed (errors loudly otherwise).\n- `false`: never go through corepack — invoke the PM directly.\n\nMirrors nypm's `corepack: true` flag. Bun, deno, and aube are never wrapped — corepack does not manage them.",
+                    "description": "Whether to dispatch PM invocations through `corepack`.\n- `\"auto\"` (default): use corepack only when the workspace   pins a PM via the `packageManager` field AND `corepack` is   on PATH AND the PM is one corepack manages (pnpm/yarn/npm).\n- `true`: always prefix `corepack` when the binary is on PATH   and the PM is corepack-managed (errors loudly otherwise).\n- `false`: never go through corepack — invoke the PM directly.\n\nMirrors nypm's `corepack: true` flag. Bun and aube are never wrapped — corepack does not manage them.",
                     "default": "auto"
                 }
             },
@@ -404,9 +408,6 @@
                         "biome": {
                             "$ref": "#/$defs/LintFmtAdapterOverride"
                         },
-                        "deno-lint": {
-                            "$ref": "#/$defs/LintFmtAdapterOverride"
-                        },
                         "eslint": {
                             "$ref": "#/$defs/LintFmtAdapterOverride"
                         },
@@ -424,6 +425,9 @@
                         },
                         "stylelint": {
                             "$ref": "#/$defs/LintFmtAdapterOverride"
+                        },
+                        "typecheck": {
+                            "$ref": "#/$defs/LintFmtAdapterOverride"
                         }
                     },
                     "additionalProperties": false,
@@ -438,7 +442,7 @@
                 }
             },
             "additionalProperties": false,
-            "description": "Configuration for `vis lint` — the linter orchestrator.\n\nTunes adapter detection precedence and per-adapter overrides. Flags on the CLI always win over config.\n\nThe default lint precedence is `oxlint → biome → eslint → stylelint → deno-lint`. Override with `order` to e.g. let biome fire before oxlint when the workspace standardises on biome."
+            "description": "Configuration for `vis lint` — the linter orchestrator.\n\nTunes adapter detection precedence and per-adapter overrides. Flags on the CLI always win over config.\n\nThe default lint precedence is `oxlint → biome → eslint → stylelint`. Override with `order` to e.g. let biome fire before oxlint when the workspace standardises on biome."
         },
         "maven": {
             "type": "object",
@@ -2059,7 +2063,7 @@
                 },
                 "autoFingerprint": {
                     "type": "boolean",
-                    "description": "Enable auto-fingerprinting mode (Vite Task-style). When enabled, the task runner automatically tracks which files a task accesses during execution and uses that for cache invalidation instead of requiring manual input configuration.\n\nFalls back to explicit inputs (Nx-style) when file tracking is not supported on the current platform.\n\nThis is the workspace-wide switch. To opt a single target into traced hashing without flipping it for the whole graph, set  {@link  TargetConfiguration.hashMode }  to `\"trace\"` on that target instead.",
+                    "description": "Enable auto-fingerprinting mode. When enabled, the task runner automatically tracks which files a task accesses during execution and uses that for cache invalidation instead of requiring manual input configuration.\n\nWhen the tracker observes no workspace access for a run, the run is keyed on the declared hash if the target declares `inputs` (see  {@link  TaskResult.hashSource } ). Otherwise it is not cached (see  {@link  TaskResult.emptyFingerprint } ).\n\nThis is the workspace-wide switch. To opt a single target into traced hashing without flipping it for the whole graph, set  {@link  TargetConfiguration.hashMode }  to `\"trace\"` on that target instead.",
                     "default": false
                 },
                 "bail": {
@@ -2092,6 +2096,31 @@
                     "description": "Dry-run mode: compute hashes and check cache but don't execute tasks. Useful for debugging cache hits/misses.",
                     "default": false
                 },
+                "env": {
+                    "type": "object",
+                    "properties": {
+                        "allow": {
+                            "type": "array",
+                            "items": {
+                                "type": "string"
+                            },
+                            "description": "Names and `*` wildcard patterns kept from the parent environment in `clean` mode. Ignored under `inherit`. Matching is case-insensitive on Windows, where environment names are case-insensitive."
+                        },
+                        "mode": {
+                            "type": "string",
+                            "enum": [
+                                "inherit",
+                                "clean"
+                            ],
+                            "description": "Whether the child inherits the parent environment."
+                        }
+                    },
+                    "required": [
+                        "mode"
+                    ],
+                    "additionalProperties": false,
+                    "description": "Workspace child-environment policy. `clean` gives every task a child with only the allow-listed parent variables, `PATH`, `HOME`, `TERM`, `CI`, the platform essentials, and whatever the executor injects. Default `inherit` (the whole parent environment).\n\nThe executor that spawns the task applies the policy. `vis run` does. The cache key follows it only when the runner context also carries a `childEnvPolicy` hook (see  {@link  TaskRunnerContext } ). Then a name the clean child cannot see hashes as unset. Without that hook every name is keyed as the parent sees it. Allow-listed names are not added to the key."
+                },
                 "envVars": {
                     "type": "array",
                     "items": {
@@ -2104,7 +2133,7 @@
                     "items": {
                         "type": "string"
                     },
-                    "description": "Environment variable patterns to include in auto-fingerprint. Supports wildcard patterns like \"VITE_*\". Only used when autoFingerprint is enabled."
+                    "description": "Environment variable patterns to include in the trace-mode fingerprint (`autoFingerprint` or a `hashMode: \"trace\"` target). Supports `*` wildcards anywhere in a pattern, e.g. \"VITE_*\" or \"*_TOKEN\". Per-target additions go in  {@link  TargetConfiguration.fingerprintEnv } ."
                 },
                 "frameworkInference": {
                     "type": "boolean",
@@ -2556,13 +2585,20 @@
                                 "type": "string",
                                 "description": "The executor/command to run"
                             },
+                            "fingerprintEnv": {
+                                "type": "array",
+                                "items": {
+                                    "type": "string"
+                                },
+                                "description": "Env vars folded into this target's cache key, as names or `*` patterns (`\"VITE_*\"`). In `\"declared\"` mode each match becomes an env input, the same as `env://NAME`; in `\"trace\"` mode it extends  {@link  TaskRunnerOptions.fingerprintEnvPatterns }  for this target."
+                            },
                             "hashMode": {
                                 "type": "string",
                                 "enum": [
                                     "declared",
                                     "trace"
                                 ],
-                                "description": "How this target's cache key is derived.\n\n- `\"declared\"` (default): the Nx-style path — the hash is built   up-front from explicitly declared `inputs` (plus named/global   inputs and the lockfile). Deterministic and portable across   machines: two runners with the same workspace state produce the   same key regardless of OS or syscall surface.\n- `\"trace\"`: the task is run under the file-access tracker   (strace on Linux, an fs preload shim elsewhere) and the cache   key is derived from the files it actually *read* during   execution — no `inputs` declaration required. Mirrors the   shipped `{ auto: true }` output capture, but for the input   side. Use for compound or opaque commands whose real input set   is impractical to enumerate.\n\nOpt-in per target precisely because trace mode trades reproducibility for convenience: the observed read set can differ across runners with different syscall surfaces (a static binary on a host without strace records nothing), so a trace key is **not** guaranteed portable between machines. Leave targets on `\"declared\"` whenever the input set can reasonably be listed.\n\nEquivalent to flipping  {@link  TaskRunnerOptions.autoFingerprint }  on for this one target while every other target stays declared."
+                                "description": "How this target's cache key is derived.\n\n- `\"declared\"` (default): the Nx-style path — the hash is built   up-front from explicitly declared `inputs` (plus named/global   inputs and the lockfile). Deterministic and portable across   machines: two runners with the same workspace state produce the   same key regardless of OS or syscall surface.\n- `\"trace\"`: the task is run under the file-access tracker   (strace or seccomp on Linux; DYLD/IAT interposition on macOS and   Windows for directly-executed commands; a Node preload otherwise)   and the cache   key is derived from the files it actually *read* during   execution — no `inputs` declaration required. Mirrors the   shipped `{ auto: true }` output capture, but for the input   side. Use for compound or opaque commands whose real input set   is impractical to enumerate.\n\nOpt-in per target precisely because trace mode trades reproducibility for convenience: the observed read set can differ across runners with different syscall surfaces (a static binary on a host without strace records nothing), so a trace key is **not** guaranteed portable between machines. Leave targets on `\"declared\"` whenever the input set can reasonably be listed.\n\nEquivalent to flipping  {@link  TaskRunnerOptions.autoFingerprint }  on for this one target while every other target stays declared."
                             },
                             "inputs": {
                                 "type": "array",
@@ -2704,6 +2740,17 @@
                                 "type": "boolean",
                                 "description": "Per-target PTY override. When `true`, every task spawned from this target runs inside a pseudo-terminal (so `isatty()` returns true and the child preserves color / progress UI). When `false`, the workspace-level PTY toggle is suppressed for this target. Useful when most targets are happy with piped stdio but one tool (vitest, prettier, a colorising linter) needs a real TTY, or vice versa.\n\nAbsent means \"follow the workspace default\" — the executor decides based on its own toggles."
                             },
+                            "splitCompound": {
+                                "type": "boolean",
+                                "description": "Split the target's command on top-level `&&` into one chained task per segment, each with its own cache key. Segment _n_ folds in the key of segment _n−1_, so changing a later segment re-runs only that segment and later ones, and a failing segment stops the chain. Works in declared and trace mode. A traced segment is tracked on its own command, and its trace key folds in the trace key of the segment before it.\n\nDeclared `outputs` attach to the last segment, so a cache hit on the whole chain restores them. A partial hit does not restore an earlier segment's files, so a later segment that reads a file written by an earlier segment needs that file to be a declared output of its own target. Opt-in. The split is refused, with a diagnostic and the target run whole, when the command contains a construct the splitter does not model (`;`, `||`, subshells, `cd`, `export`, `VAR=…` prefixes, command substitution, …), when an output is `{ auto: true }` (write tracking covers the whole target, not one segment), when it has a `when` condition, or when it is `always`."
+                            },
+                            "untrackedEnv": {
+                                "type": "array",
+                                "items": {
+                                    "type": "string"
+                                },
+                                "description": "Env vars this target receives but keeps out of its cache key, as names or `*` patterns (`\"CI_*\"`). Applies on top of  {@link  TaskRunnerOptions.untrackedEnvVars }  and wins over `fingerprintEnv`, `autoEnvVars`, framework inference and trace-mode fingerprint patterns. Explicit `env://` inputs and the workspace `envVars` / `globalEnv` lists are not affected."
+                            },
                             "warningPattern": {
                                 "anyOf": [
                                     {
@@ -2978,7 +3025,7 @@
                     "items": {
                         "type": "string"
                     },
-                    "description": "Environment variables that should be passed to tasks but NOT included in the cache fingerprint. Useful for CI-specific vars. Only used when autoFingerprint is enabled."
+                    "description": "Environment variables that are passed to tasks but kept out of their cache key. Accepts names and `*` wildcard patterns (e.g. \"CI_*\"). Applies to the trace-mode fingerprint and to the implicit env sources of declared-mode hashing (`autoEnvVars`, framework inference). Explicit `env://` inputs and `envVars` / `globalEnv` are not affected. Per-target overrides go in  {@link  TargetConfiguration.untrackedEnv } ."
                 }
             },
             "additionalProperties": false,
@@ -3126,13 +3173,20 @@
                         "type": "string",
                         "description": "The executor/command to run"
                     },
+                    "fingerprintEnv": {
+                        "type": "array",
+                        "items": {
+                            "type": "string"
+                        },
+                        "description": "Env vars folded into this target's cache key, as names or `*` patterns (`\"VITE_*\"`). In `\"declared\"` mode each match becomes an env input, the same as `env://NAME`; in `\"trace\"` mode it extends  {@link  TaskRunnerOptions.fingerprintEnvPatterns }  for this target."
+                    },
                     "hashMode": {
                         "type": "string",
                         "enum": [
                             "declared",
                             "trace"
                         ],
-                        "description": "How this target's cache key is derived.\n\n- `\"declared\"` (default): the Nx-style path — the hash is built   up-front from explicitly declared `inputs` (plus named/global   inputs and the lockfile). Deterministic and portable across   machines: two runners with the same workspace state produce the   same key regardless of OS or syscall surface.\n- `\"trace\"`: the task is run under the file-access tracker   (strace on Linux, an fs preload shim elsewhere) and the cache   key is derived from the files it actually *read* during   execution — no `inputs` declaration required. Mirrors the   shipped `{ auto: true }` output capture, but for the input   side. Use for compound or opaque commands whose real input set   is impractical to enumerate.\n\nOpt-in per target precisely because trace mode trades reproducibility for convenience: the observed read set can differ across runners with different syscall surfaces (a static binary on a host without strace records nothing), so a trace key is **not** guaranteed portable between machines. Leave targets on `\"declared\"` whenever the input set can reasonably be listed.\n\nEquivalent to flipping  {@link  TaskRunnerOptions.autoFingerprint }  on for this one target while every other target stays declared."
+                        "description": "How this target's cache key is derived.\n\n- `\"declared\"` (default): the Nx-style path — the hash is built   up-front from explicitly declared `inputs` (plus named/global   inputs and the lockfile). Deterministic and portable across   machines: two runners with the same workspace state produce the   same key regardless of OS or syscall surface.\n- `\"trace\"`: the task is run under the file-access tracker   (strace or seccomp on Linux; DYLD/IAT interposition on macOS and   Windows for directly-executed commands; a Node preload otherwise)   and the cache   key is derived from the files it actually *read* during   execution — no `inputs` declaration required. Mirrors the   shipped `{ auto: true }` output capture, but for the input   side. Use for compound or opaque commands whose real input set   is impractical to enumerate.\n\nOpt-in per target precisely because trace mode trades reproducibility for convenience: the observed read set can differ across runners with different syscall surfaces (a static binary on a host without strace records nothing), so a trace key is **not** guaranteed portable between machines. Leave targets on `\"declared\"` whenever the input set can reasonably be listed.\n\nEquivalent to flipping  {@link  TaskRunnerOptions.autoFingerprint }  on for this one target while every other target stays declared."
                     },
                     "inputs": {
                         "type": "array",
@@ -3269,6 +3323,17 @@
                         "type": "boolean",
                         "description": "Per-target PTY override. When `true`, every task spawned from this target runs inside a pseudo-terminal (so `isatty()` returns true and the child preserves color / progress UI). When `false`, the workspace-level PTY toggle is suppressed for this target. Useful when most targets are happy with piped stdio but one tool (vitest, prettier, a colorising linter) needs a real TTY, or vice versa.\n\nAbsent means \"follow the workspace default\" — the executor decides based on its own toggles."
                     },
+                    "splitCompound": {
+                        "type": "boolean",
+                        "description": "Split the target's command on top-level `&&` into one chained task per segment, each with its own cache key. Segment _n_ folds in the key of segment _n−1_, so changing a later segment re-runs only that segment and later ones, and a failing segment stops the chain. Works in declared and trace mode. A traced segment is tracked on its own command, and its trace key folds in the trace key of the segment before it.\n\nDeclared `outputs` attach to the last segment, so a cache hit on the whole chain restores them. A partial hit does not restore an earlier segment's files, so a later segment that reads a file written by an earlier segment needs that file to be a declared output of its own target. Opt-in. The split is refused, with a diagnostic and the target run whole, when the command contains a construct the splitter does not model (`;`, `||`, subshells, `cd`, `export`, `VAR=…` prefixes, command substitution, …), when an output is `{ auto: true }` (write tracking covers the whole target, not one segment), when it has a `when` condition, or when it is `always`."
+                    },
+                    "untrackedEnv": {
+                        "type": "array",
+                        "items": {
+                            "type": "string"
+                        },
+                        "description": "Env vars this target receives but keeps out of its cache key, as names or `*` patterns (`\"CI_*\"`). Applies on top of  {@link  TaskRunnerOptions.untrackedEnvVars }  and wins over `fingerprintEnv`, `autoEnvVars`, framework inference and trace-mode fingerprint patterns. Explicit `env://` inputs and the workspace `envVars` / `globalEnv` lists are not affected."
+                    },
                     "warningPattern": {
                         "anyOf": [
                             {
@@ -3568,9 +3633,6 @@
                         "bun": {
                             "type": "string"
                         },
-                        "deno": {
-                            "type": "string"
-                        },
                         "go": {
                             "type": "string"
                         },
@@ -3868,7 +3930,6 @@
             "type": "string",
             "enum": [
                 "biome",
-                "deno-fmt",
                 "dprint",
                 "oxfmt",
                 "prettier",
@@ -3880,13 +3941,13 @@
             "type": "string",
             "enum": [
                 "biome",
-                "deno-lint",
                 "eslint",
                 "markdownlint",
                 "oxlint",
                 "ruff-check",
                 "shellcheck",
-                "stylelint"
+                "stylelint",
+                "typecheck"
             ],
             "description": "Adapter IDs that can lint (adapter `kind` is `\"lint\"` or `\"both\"`)."
         },
@@ -5050,17 +5111,6 @@
                     },
                     "description": "Per-package `extra-files` rules with paths relative to the package directory. Merged with workspace-level `release.publish.extraFiles` (per-package wins on path collision)."
                 },
-                "jsrConfigPath": {
-                    "type": "string",
-                    "description": "Relative path from the package directory to the JSR manifest (`jsr.json` or `deno.json`) for the `jsr` versionActions. Set automatically by the `jsr()` preset from its `manifestPath` option. Defaults to `\"jsr.json\"`."
-                },
-                "jsrPublishArgs": {
-                    "type": "array",
-                    "items": {
-                        "type": "string"
-                    },
-                    "description": "Extra arguments forwarded verbatim to `jsr publish` for the `jsr` versionActions (the `jsr()` preset wires this from its `publishArgs` / `allowSlowTypes` options). The most common entry is `\"--allow-slow-types\"`, which JSR requires for packages whose public API has types it can't statically infer. `--allow-dirty` is always passed by vis (the version is bumped on disk before publish) and need not be listed here."
-                },
                 "managed": {
                     "type": "boolean",
                     "description": "Hard opt-in/out — overrides every other rule."
@@ -5122,7 +5172,7 @@
                 },
                 "versionActions": {
                     "type": "string",
-                    "description": "Built-in id (`\"npm\"`, `\"native-addon\"`, `\"private\"`, `\"shell\"`, `\"cargo\"`, `\"python\"`, `\"maven\"`, `\"container\"`, `\"jsr\"`) or a path to a custom implementation module."
+                    "description": "Built-in id (`\"npm\"`, `\"native-addon\"`, `\"private\"`, `\"shell\"`, `\"cargo\"`, `\"python\"`, `\"maven\"`, `\"container\"`) or a path to a custom implementation module."
                 },
                 "versionFiles": {
                     "type": "array",
@@ -5643,7 +5693,7 @@
                 "bun",
                 "node"
             ],
-            "description": "JS runtimes vis can target today. `\"deno\"` is deferred."
+            "description": "JS runtimes vis can target today."
         },
         "ScopedTasksBlock": {
             "type": "object",
@@ -5794,13 +5844,20 @@
                                 "type": "string",
                                 "description": "The executor/command to run"
                             },
+                            "fingerprintEnv": {
+                                "type": "array",
+                                "items": {
+                                    "type": "string"
+                                },
+                                "description": "Env vars folded into this target's cache key, as names or `*` patterns (`\"VITE_*\"`). In `\"declared\"` mode each match becomes an env input, the same as `env://NAME`; in `\"trace\"` mode it extends  {@link  TaskRunnerOptions.fingerprintEnvPatterns }  for this target."
+                            },
                             "hashMode": {
                                 "type": "string",
                                 "enum": [
                                     "declared",
                                     "trace"
                                 ],
-                                "description": "How this target's cache key is derived.\n\n- `\"declared\"` (default): the Nx-style path — the hash is built   up-front from explicitly declared `inputs` (plus named/global   inputs and the lockfile). Deterministic and portable across   machines: two runners with the same workspace state produce the   same key regardless of OS or syscall surface.\n- `\"trace\"`: the task is run under the file-access tracker   (strace on Linux, an fs preload shim elsewhere) and the cache   key is derived from the files it actually *read* during   execution — no `inputs` declaration required. Mirrors the   shipped `{ auto: true }` output capture, but for the input   side. Use for compound or opaque commands whose real input set   is impractical to enumerate.\n\nOpt-in per target precisely because trace mode trades reproducibility for convenience: the observed read set can differ across runners with different syscall surfaces (a static binary on a host without strace records nothing), so a trace key is **not** guaranteed portable between machines. Leave targets on `\"declared\"` whenever the input set can reasonably be listed.\n\nEquivalent to flipping  {@link  TaskRunnerOptions.autoFingerprint }  on for this one target while every other target stays declared."
+                                "description": "How this target's cache key is derived.\n\n- `\"declared\"` (default): the Nx-style path — the hash is built   up-front from explicitly declared `inputs` (plus named/global   inputs and the lockfile). Deterministic and portable across   machines: two runners with the same workspace state produce the   same key regardless of OS or syscall surface.\n- `\"trace\"`: the task is run under the file-access tracker   (strace or seccomp on Linux; DYLD/IAT interposition on macOS and   Windows for directly-executed commands; a Node preload otherwise)   and the cache   key is derived from the files it actually *read* during   execution — no `inputs` declaration required. Mirrors the   shipped `{ auto: true }` output capture, but for the input   side. Use for compound or opaque commands whose real input set   is impractical to enumerate.\n\nOpt-in per target precisely because trace mode trades reproducibility for convenience: the observed read set can differ across runners with different syscall surfaces (a static binary on a host without strace records nothing), so a trace key is **not** guaranteed portable between machines. Leave targets on `\"declared\"` whenever the input set can reasonably be listed.\n\nEquivalent to flipping  {@link  TaskRunnerOptions.autoFingerprint }  on for this one target while every other target stays declared."
                             },
                             "inputs": {
                                 "type": "array",
@@ -5937,6 +5994,17 @@
                                 "type": "boolean",
                                 "description": "Per-target PTY override. When `true`, every task spawned from this target runs inside a pseudo-terminal (so `isatty()` returns true and the child preserves color / progress UI). When `false`, the workspace-level PTY toggle is suppressed for this target. Useful when most targets are happy with piped stdio but one tool (vitest, prettier, a colorising linter) needs a real TTY, or vice versa.\n\nAbsent means \"follow the workspace default\" — the executor decides based on its own toggles."
                             },
+                            "splitCompound": {
+                                "type": "boolean",
+                                "description": "Split the target's command on top-level `&&` into one chained task per segment, each with its own cache key. Segment _n_ folds in the key of segment _n−1_, so changing a later segment re-runs only that segment and later ones, and a failing segment stops the chain. Works in declared and trace mode. A traced segment is tracked on its own command, and its trace key folds in the trace key of the segment before it.\n\nDeclared `outputs` attach to the last segment, so a cache hit on the whole chain restores them. A partial hit does not restore an earlier segment's files, so a later segment that reads a file written by an earlier segment needs that file to be a declared output of its own target. Opt-in. The split is refused, with a diagnostic and the target run whole, when the command contains a construct the splitter does not model (`;`, `||`, subshells, `cd`, `export`, `VAR=…` prefixes, command substitution, …), when an output is `{ auto: true }` (write tracking covers the whole target, not one segment), when it has a `when` condition, or when it is `always`."
+                            },
+                            "untrackedEnv": {
+                                "type": "array",
+                                "items": {
+                                    "type": "string"
+                                },
+                                "description": "Env vars this target receives but keeps out of its cache key, as names or `*` patterns (`\"CI_*\"`). Applies on top of  {@link  TaskRunnerOptions.untrackedEnvVars }  and wins over `fingerprintEnv`, `autoEnvVars`, framework inference and trace-mode fingerprint patterns. Explicit `env://` inputs and the workspace `envVars` / `globalEnv` lists are not affected."
+                            },
                             "warningPattern": {
                                 "anyOf": [
                                     {
@@ -6427,6 +6495,31 @@
                     "description": "How to forward affected files to the task process. Only used when invoked via `vis affected <target>`.",
                     "default": false
                 },
+                "env": {
+                    "type": "object",
+                    "properties": {
+                        "allow": {
+                            "type": "array",
+                            "items": {
+                                "type": "string"
+                            },
+                            "description": "Names and `*` wildcard patterns kept from the parent environment in `clean` mode. Ignored under `inherit`. Matching is case-insensitive on Windows, where environment names are case-insensitive."
+                        },
+                        "mode": {
+                            "type": "string",
+                            "enum": [
+                                "inherit",
+                                "clean"
+                            ],
+                            "description": "Whether the child inherits the parent environment."
+                        }
+                    },
+                    "required": [
+                        "mode"
+                    ],
+                    "additionalProperties": false,
+                    "description": "Child-process environment for this target. Overrides the workspace `taskRunner.env`.\n- `mode: \"inherit\"`: the child gets the whole parent environment, even   when the workspace is `clean`.\n- `mode: \"clean\"`: the child gets only the allow-listed names, `PATH`,   `HOME`, `TERM`, `CI`, the platform essentials and what vis injects   (`VIS_TASK_SLOTS`, `VIS_ARG_*`, `envFile` values, service env).\n- `allow`: names and `*` wildcard patterns kept under `clean`. Added to   the workspace allow-list when the workspace is also `clean`.\n\nA traced target (`hashMode: \"trace\"`, or a workspace `autoFingerprint`) can be `clean` too: it gets the same environment plus the tracker's own variables, and the tracker then runs without its native backends. Without this option the workspace `taskRunner.env` applies, and that defaults to `inherit`."
+                },
                 "envFile": {
                     "anyOf": [
                         {

package/schemas/vis-release-config.schema.json

@@ -977,17 +977,6 @@
                     },
                     "description": "Per-package `extra-files` rules with paths relative to the package directory. Merged with workspace-level `release.publish.extraFiles` (per-package wins on path collision)."
                 },
-                "jsrConfigPath": {
-                    "type": "string",
-                    "description": "Relative path from the package directory to the JSR manifest (`jsr.json` or `deno.json`) for the `jsr` versionActions. Set automatically by the `jsr()` preset from its `manifestPath` option. Defaults to `\"jsr.json\"`."
-                },
-                "jsrPublishArgs": {
-                    "type": "array",
-                    "items": {
-                        "type": "string"
-                    },
-                    "description": "Extra arguments forwarded verbatim to `jsr publish` for the `jsr` versionActions (the `jsr()` preset wires this from its `publishArgs` / `allowSlowTypes` options). The most common entry is `\"--allow-slow-types\"`, which JSR requires for packages whose public API has types it can't statically infer. `--allow-dirty` is always passed by vis (the version is bumped on disk before publish) and need not be listed here."
-                },
                 "managed": {
                     "type": "boolean",
                     "description": "Hard opt-in/out — overrides every other rule."
@@ -1049,7 +1038,7 @@
                 },
                 "versionActions": {
                     "type": "string",
-                    "description": "Built-in id (`\"npm\"`, `\"native-addon\"`, `\"private\"`, `\"shell\"`, `\"cargo\"`, `\"python\"`, `\"maven\"`, `\"container\"`, `\"jsr\"`) or a path to a custom implementation module."
+                    "description": "Built-in id (`\"npm\"`, `\"native-addon\"`, `\"private\"`, `\"shell\"`, `\"cargo\"`, `\"python\"`, `\"maven\"`, `\"container\"`) or a path to a custom implementation module."
                 },
                 "versionFiles": {
                     "type": "array",

package/skills/vis/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: vis
-description: Use when the workspace contains a vis.config.ts (or vis.config.js/json) at the repo root, or when the user mentions "vis", "task-runner", or "@visulima/vis". This skill orchestrates the vis MCP server's eight read-only tools to inspect projects, plan task graphs, and diagnose remote-cache rotations.
+description: Use when the workspace contains a vis.config.ts (or vis.config.js/json) at the repo root, or when the user mentions "vis", "task-runner", or "@visulima/vis". This skill orchestrates the vis MCP server's thirteen read-only tools to inspect projects, plan task graphs, lint, and diagnose remote-cache rotations.
 ---
 
 # Working with the `vis` task runner
 
-`vis` is the Visulima monorepo task runner — a Turborepo/Nx-class tool with a remote cache, REAPI gRPC backend, and project graph. When this skill is active you have the **`@visulima/vis-mcp` server** mounted, exposing eight read-only tools. Use them in preference to running `vis` shell commands yourself: the tools give you structured JSON and run faster.
+`vis` is the Visulima monorepo task runner — a Turborepo/Nx-class tool with a remote cache, REAPI gRPC backend, and project graph. When this skill is active you have the **`@visulima/vis-mcp` server** mounted, exposing thirteen read-only tools. Use them in preference to running `vis` shell commands yourself: the tools give you structured JSON and run faster.
 
 The MCP server deliberately does NOT execute targets or scaffold templates — Nx-style "agent prepares, human executes". When the user wants to run `<project>:<target>` or `vis generate <template>`, prepare the command (use `list_targets`/`describe_template` to confirm it exists and capture required arguments) and ask the user to run it themselves; afterwards use `get_run_logs` to read the result of any task run.
 
@@ -18,9 +18,14 @@ The MCP server deliberately does NOT execute targets or scaffold templates — N
 | `list_targets`      | Per-target rows across the workspace, optionally narrowed to a single project                                                     |
 | `list_templates`    | Scaffolding templates discovered in `.vis/templates/`, `.moon/templates/`, and `vis.config.ts` `generator.templates`              |
 | `describe_template` | Variable schema, default destination, and description for a single template — required before suggesting a `vis generate` command |
-| `get_run_logs`      | Most recent run summary from `.vis/`, or a specific `runId`, optionally filtered to one task                              |
+| `list_runs`         | Recorded runs in `.vis/runs/`, newest first — the IDs feed `get_run_logs` and the cache tools                                     |
+| `get_run_logs`      | Most recent run summary from `.vis/`, or a specific `runId`, optionally filtered to one task                                      |
 | `cache_why`         | Diff a task's cache hash against the previous run — pinpoints what changed (command, nodes, runtime, implicit deps)               |
-| `cache_hash`        | Recorded hash and per-input hash details for a task                                                                               |
+| `cache_hash`        | Recorded hash and per-input hash details for a task (trace-mode tasks: the tracked files and env instead)                         |
+| `lint`              | Check-only lint across the detected linters, merged findings (never applies fixes)                                                |
+| `fmt`               | Check-only formatting: each finding is a file that would change (never writes)                                                    |
+| `audit`             | Vulnerability audit of installed packages; uses the offline advisory cache when one exists                                        |
+| `advisory_status`   | Freshness of the local advisory database — check it before an offline `audit`                                                     |
 
 ## Workflow patterns
 
@@ -34,16 +39,23 @@ Default opening move when the user asks about the workspace:
 ### Plan a build
 
 1. `list_targets` (optionally with `project: "@scope/name"`) to see what `build`/`test`/`lint`/etc. targets exist.
-2. Tell the user the exact command (`vis run @scope/name:build`) and let them run it.
-3. Use `get_run_logs` afterwards to inspect status, cache hits, and stderr tails.
+2. Tell the user the exact command (`vis run @scope/name:build`) and let them run it. `vis run` exits 1 when the target is missing, or when `--filter`, `--query` or `--tag` selects no project; `vis ci` and `vis affected` behave the same. Suggest `--if-present` (exit 0 with a one-line notice) only when an empty selection is acceptable, such as one script shared across repos that don't all define the target. An empty `--affected` set is not an error.
+3. Use `get_run_logs` afterwards to read each task's `exitCode`, `cacheStatus`, and the run's `stats`.
+
+### Check lint and formatting
+
+1. `lint` and `fmt` are check-only: `lint` returns findings, `fmt` returns the files that would change. `files` narrows either one.
+2. A clean `lint` does not mean the types check. The `typecheck` adapter (`tsc`) runs only when the workspace sets `lint.adapters.typecheck.enabled`, and then it checks the whole project, not just the listed files.
+3. Hand the user `vis lint --fix` or `vis fmt` to apply changes.
 
 ### Investigate a cache miss
 
 When a build that should have been cached re-ran:
 
-1. `get_run_logs` (no args → latest summary) — surfaces all task statuses for the last run.
-2. For any task with status `success` but `cacheStatus: "miss"`, call `cache_why` with that `taskId`. It diffs hashDetails against the previous run and tells you which input rotated (command string, file content, `implicitDependency`, runtime version, …).
-3. If `cache_why` shows the change but the user wants to see the raw hash inputs, `cache_hash` returns the full per-input breakdown.
+1. `get_run_logs` (no args → latest summary) — each task carries `exitCode` and `cacheStatus` (`HIT`, `MISS`, `REMOTE_HIT`, `SKIPPED`).
+2. For a task with `exitCode: 0` and `cacheStatus: "MISS"` that should have hit, call `cache_why` with that `taskId`. For a task with declared inputs it diffs `hashDetails` against the previous run and names the bucket that rotated (`command`, `nodes`, `runtime`, `implicitDeps`). A `hashMode: "trace"` task has no `hashDetails`; read `task.cacheMissReasons` instead. These are `{ type, detail }` entries such as `file-changed`, `env-changed`, or `tracker-changed` (the run used a different tracker than the stored trace). The field is `null` on a hit. `task.hashSource: "declared-fallback"` means the run was keyed on its declared inputs because the tracker saw no workspace access.
+3. If `cache_why` shows the change but the user wants the raw inputs, `cache_hash` returns the per-input breakdown. For a trace-mode task it returns `trackedFingerprint` (the files, env names, and missing paths the run tracked) instead.
+4. If `cache_why` shows nothing changed, the result was a hit, and it is still wrong, one possible cause is an env var the command reads that no cache key covers. Ask the user to run `vis doctor`: its Env Coverage section lists those variables per target, with the fixes (`fingerprintEnv`, `autoEnvVars`, or `untrackedEnv`). It is a warning; `vis doctor --exit-code --strict` turns it into a failure.
 
 ### Scaffold a new package or component
 
@@ -76,9 +88,9 @@ User: _"Scaffold a new React button component called PrimaryButton."_
 
 ### Diagnose a failed run
 
-1. `get_run_logs` to see which task(s) failed.
-2. `get_run_logs` with `taskId` set to the failing task — returns just that entry, including the captured stderr tail.
-3. Decide: is it a code bug (read the project's source), a cache poisoning issue (`cache_why`), or environmental (look at the run summary's `runtime` block)?
+1. `get_run_logs` to see which task(s) failed; `stats.failed` counts them.
+2. `get_run_logs` with `taskId` set to the failing task — returns just that entry. The summary records the exit code, cache status, and hash, not the task's output, so ask the user for the failing output if you need it.
+3. Decide: is it a code bug (read the project's source), a cache poisoning issue (`cache_why`), or environmental (the summary's `environment` block gives platform, arch, and Node version)?
 
 ## Safety rules