From 6861b66ecd0392b5bc051afe1c256b13613b4676 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 9 Sep 2026 20:12:38 +0000 Subject: [PATCH] chore: version packages --- .../fix-nightly-stub-package-reference.md | 15 -- .changeset/info-json-onboarded.md | 12 -- .changeset/init-json-envelope.md | 13 -- .changeset/one-bad-file-zeroes-the-run.md | 16 --- .changeset/rule-guard-json-envelope.md | 20 --- .changeset/schema-verify-docstrings.md | 11 -- .changeset/skip-oversized-vale-files.md | 35 ----- .changeset/telemetry-adoption-dimensions.md | 17 --- .changeset/vale-raw-scope-line-numbers.md | 18 --- .claude-plugin/plugin.json | 2 +- package.json | 2 +- packages/cli/CHANGELOG.md | 132 ++++++++++++++++++ packages/cli/package.json | 2 +- skills/taskless/SKILL.md | 2 +- 14 files changed, 136 insertions(+), 161 deletions(-) delete mode 100644 .changeset/fix-nightly-stub-package-reference.md delete mode 100644 .changeset/info-json-onboarded.md delete mode 100644 .changeset/init-json-envelope.md delete mode 100644 .changeset/one-bad-file-zeroes-the-run.md delete mode 100644 .changeset/rule-guard-json-envelope.md delete mode 100644 .changeset/schema-verify-docstrings.md delete mode 100644 .changeset/skip-oversized-vale-files.md delete mode 100644 .changeset/telemetry-adoption-dimensions.md delete mode 100644 .changeset/vale-raw-scope-line-numbers.md diff --git a/.changeset/fix-nightly-stub-package-reference.md b/.changeset/fix-nightly-stub-package-reference.md deleted file mode 100644 index 15b985a3..00000000 --- a/.changeset/fix-nightly-stub-package-reference.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -"@taskless/cli": patch ---- - -Fixed reference stubs (`.claude/`, `.agents/`, etc.) freezing a stale, -unpinned `npx @taskless/cli` invocation into their own frontmatter -`description` forever, even on a nightly install whose canonical -`.taskless/skills/taskless/SKILL.md` correctly names the pinned -`@taskless/cli-nightly@` package. A stub's `description` is copied -verbatim from source and, unlike canonical content, is never rewritten for -the current build target — so any CLI invocation baked into it would go -stale on the very first release that changed. The invocation is removed from -the skill and command `description` fields entirely: the canonical file -already carries the correct, per-build invocation, and a stub always defers -to it, so there is no longer a second copy that can drift. diff --git a/.changeset/info-json-onboarded.md b/.changeset/info-json-onboarded.md deleted file mode 100644 index 96e70dd0..00000000 --- a/.changeset/info-json-onboarded.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -"@taskless/cli": patch ---- - -`info --json` now includes `install.onboarded`, matching the field the -`onboard` recipe already instructs agents to read from that command. Before -this, the field was written to `.taskless/taskless.json` and enforced by -`onboard`'s own gate, but omitted from the `info --json` payload, so an agent -following the recipe read `undefined` and re-ran a full discovery pass on a -project that had already onboarded. A manifest that omits the field now -reports `onboarded: false`, matching the strict-equality gate `onboard` -itself applies, rather than `null` or leaving the key out. diff --git a/.changeset/init-json-envelope.md b/.changeset/init-json-envelope.md deleted file mode 100644 index 5194f842..00000000 --- a/.changeset/init-json-envelope.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -"@taskless/cli": patch ---- - -`init --json` now writes only the parseable envelope to stdout. Previously, -the non-interactive install path (also reached from `init --no-interactive ---json`) unconditionally logged human-readable prose — the "no tools -detected" fallback notice and the per-target skill/command summary — to -stdout ahead of the JSON envelope, so `taskless init --json | jq .` failed -with a JSON parse error. That prose now goes to stderr, where it stays -visible to a person watching the terminal without corrupting a machine -consumer's view of stdout, matching how `verify`/`test` and the migration -notice already behave under `--json`. diff --git a/.changeset/one-bad-file-zeroes-the-run.md b/.changeset/one-bad-file-zeroes-the-run.md deleted file mode 100644 index 0e132690..00000000 --- a/.changeset/one-bad-file-zeroes-the-run.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -"@taskless/cli": patch ---- - -`check` no longer loses every finding in a run because one file's front -matter could not be parsed. A Vale front-matter error used to abort the -entire Vale invocation before any result was written, so `results` came back -`[]` for the whole run regardless of how many other files had findings — and -`[]` was indistinguishable from a genuinely clean pass. - -`runVale` now retries around a file Vale's own error attributes to one of the -run's targets, excluding it and reporting it as a per-file finding -(`ruleId: "vale-parse-error"`, `severity: "error"`) instead of failing the -whole run. Every other file's findings are reported normally. A failure Vale -does not attribute to a single target file — a malformed rule, a timeout, a -crash — is unaffected and still fails the run exactly as before. diff --git a/.changeset/rule-guard-json-envelope.md b/.changeset/rule-guard-json-envelope.md deleted file mode 100644 index 4338c6ff..00000000 --- a/.changeset/rule-guard-json-envelope.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -"@taskless/cli": patch ---- - -`rule create --json` and `rule improve --json` now emit the standard `{ ok: -false, code, message }` envelope on stdout when a file-set rule arrives with -a stray `tests` field, instead of throwing a bare, unreported `CLIError`. -Previously the guard threw from inside the command's own `try` without going -through the command's `fail()` helper, so under `--json` nothing was written -to stdout at all — prose landed on stderr and the process exited 1, -indistinguishable from a crash, and the `RULE_GENERATION_FAILED` code the -`create-remote-rule` recipe documents as a branch target was never actually -reachable for this guard. Both call sites now route through `fail()`, and the -duplicated guard itself was consolidated into one shared check so the two -copies cannot drift again silently. - -Not addressed here: rules written to disk earlier in the same delivery loop -(before the guard fires) are still not named in the failure envelope. The -published envelope shape (`CLIErrorEnvelope`) has no field for a partial file -list, and adding one is a schema change out of scope for this fix. diff --git a/.changeset/schema-verify-docstrings.md b/.changeset/schema-verify-docstrings.md deleted file mode 100644 index 17e9ffbf..00000000 --- a/.changeset/schema-verify-docstrings.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -"@taskless/cli": patch ---- - -Corrected the published `@taskless/cli/schemas` docstrings for -`verifyOutputSchema` and `valeVerifyOutputSchema`, which named a command form -— `taskless rule verify --json` — that was removed when rule addressing -moved from id to path. No runtime behavior changes; the schemas themselves -are unchanged. A consumer reading these docstrings (e.g. via editor -tooltips or generated docs) would previously be pointed at a command that -does not exist. diff --git a/.changeset/skip-oversized-vale-files.md b/.changeset/skip-oversized-vale-files.md deleted file mode 100644 index 2ebd3f0e..00000000 --- a/.changeset/skip-oversized-vale-files.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -"@taskless/cli": patch ---- - -`check` no longer risks losing every Vale finding in a run to one oversized -file. Vale's cost is quadratic in a single file's size (measured against the -pinned binary: 128KB is ~0.8s for one rule, 384KB is already ~7s), and -`VALE_TIMEOUT_MS` bounds the whole run, not one file — a large enough -document could consume most or all of that budget on its own, and a timeout -discards every other file's findings along with it (the same failure #300 -fixed, on a path #300 did not cover). - -`runVale` now excludes a target file over 128KB (`VALE_MAX_FILE_BYTES` in -`src/rules/vale/run.ts`) before invoking Vale at all, the same preemptive -treatment already given to a format Vale cannot parse — but only when some -Vale rule's own `.vale.ini` section could actually reach that file. -`assembleValeConfig` now returns the section patterns it wrote alongside the -config path, and the size scan globs by those patterns (`findOversizedFiles` -in `src/rules/vale/formats.ts`) instead of walking every file in the project. -A first version of this fix scanned the whole tree unconditionally and named -`pnpm-lock.yaml` and `packages/cli/CHANGELOG.md` as "not checked" on this very -repository, even though no rule's matcher touches either file — Vale was -never going to open them, so that was a false positive, not a caught coverage -hole. Excluded files are named in a `notices` entry rather than a finding: -unlike an unparseable file (where Vale itself proves the file was a real -target by erroring on it), this exclusion is a preemptive guess from a -filesystem walk, and a soft advisory fits an unconfirmed guess better than a -hard error. - -A consumer may now see a `check` that previously counted a large file's -prose findings instead report a `notices` entry naming that file as skipped -— but only for a file some rule's own scope actually reaches. 128KB is -comfortably past hand-written prose (roughly 20,000 words); this should only -affect generated output, pasted data, or exported notes checked directly -against a matching rule. diff --git a/.changeset/telemetry-adoption-dimensions.md b/.changeset/telemetry-adoption-dimensions.md deleted file mode 100644 index 802d08b3..00000000 --- a/.changeset/telemetry-adoption-dimensions.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -"@taskless/cli": patch ---- - -Telemetry now records six adoption dimensions on every event: `workspaceId` and -`repositoryId` (both hashed), `envOS`, `ci`, `ciProvider`, and `languageStack`. -`cli_check_completed` also reports `ruleCount`, so a scan that loaded no rules -is distinguishable from one that loaded rules and found nothing. - -Nothing to react to. No command changes behaviour, no output changes shape, and -every dimension falls back to a sentinel rather than failing — telemetry is not -a precondition for any command. `TASKLESS_TELEMETRY_DISABLED=1` and -`DO_NOT_TRACK=1` continue to short-circuit before any of it is resolved, so the -opt-out remains an opt-out of the work rather than only of the send. - -`patch` rather than `minor` because the package is pre-1.0, where added surface -does not earn a `minor`, and because none of this is API a consumer can call. diff --git a/.changeset/vale-raw-scope-line-numbers.md b/.changeset/vale-raw-scope-line-numbers.md deleted file mode 100644 index ce41fa0c..00000000 --- a/.changeset/vale-raw-scope-line-numbers.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -"@taskless/cli": patch ---- - -Fixed `check --json` reporting a `raw`-scope Vale finding's `range.start.line` -one line earlier than the flagged text (#297). A `raw` pattern is -conventionally anchored with a leading `\n` so it can require "start of line" -against the unparsed document; that `\n` is part of Vale's reported match, and -Vale attributes `Line` to the newline ending the previous line rather than to -the line the flagged text is actually on. The mapper now counts a match's -leading newlines and adds them back before converting to the 0-indexed -`CheckResult.range` every source uses. - -`default`-scope findings were not affected: Vale already reports the correct -1-based line for them, and `range.start.line` is 0-indexed by design (every -source in `CheckResult.range` is — `format.ts` adds 1 back when it displays, -and #297's "off by one" for default-scope rules was this documented -convention compared against a 1-based file line, not a bug). diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json index 368e0cea..df2e100b 100644 --- a/.claude-plugin/plugin.json +++ b/.claude-plugin/plugin.json @@ -1,7 +1,7 @@ { "name": "taskless", "description": "Taskless skills for code quality rules, authentication, and project management", - "version": "0.11.1", + "version": "0.11.2", "author": { "name": "Taskless" }, diff --git a/package.json b/package.json index 6e7b8ed2..c3699026 100644 --- a/package.json +++ b/package.json @@ -1,7 +1,7 @@ { "private": true, "name": "@taskless/skills", - "version": "0.11.1", + "version": "0.11.2", "license": "MIT", "repository": "taskless/cli.git", "scripts": { diff --git a/packages/cli/CHANGELOG.md b/packages/cli/CHANGELOG.md index 635b5155..32762b4c 100644 --- a/packages/cli/CHANGELOG.md +++ b/packages/cli/CHANGELOG.md @@ -1,5 +1,137 @@ # @taskless/cli +## 0.11.2 + +[Compare with v0.11.1](https://github.com/taskless/cli/compare/v0.11.1...v0.11.2) + +### Patch Changes + +- b8b6f32: Fixed reference stubs (`.claude/`, `.agents/`, etc.) freezing a stale, + unpinned `npx @taskless/cli` invocation into their own frontmatter + `description` forever, even on a nightly install whose canonical + `.taskless/skills/taskless/SKILL.md` correctly names the pinned + `@taskless/cli-nightly@` package. A stub's `description` is copied + verbatim from source and, unlike canonical content, is never rewritten for + the current build target — so any CLI invocation baked into it would go + stale on the very first release that changed. The invocation is removed from + the skill and command `description` fields entirely: the canonical file + already carries the correct, per-build invocation, and a stub always defers + to it, so there is no longer a second copy that can drift. +- 2d088fa: `info --json` now includes `install.onboarded`, matching the field the + `onboard` recipe already instructs agents to read from that command. Before + this, the field was written to `.taskless/taskless.json` and enforced by + `onboard`'s own gate, but omitted from the `info --json` payload, so an agent + following the recipe read `undefined` and re-ran a full discovery pass on a + project that had already onboarded. A manifest that omits the field now + reports `onboarded: false`, matching the strict-equality gate `onboard` + itself applies, rather than `null` or leaving the key out. +- 548f268: `init --json` now writes only the parseable envelope to stdout. Previously, + the non-interactive install path (also reached from `init --no-interactive +--json`) unconditionally logged human-readable prose — the "no tools + detected" fallback notice and the per-target skill/command summary — to + stdout ahead of the JSON envelope, so `taskless init --json | jq .` failed + with a JSON parse error. That prose now goes to stderr, where it stays + visible to a person watching the terminal without corrupting a machine + consumer's view of stdout, matching how `verify`/`test` and the migration + notice already behave under `--json`. +- 54cd0c0: `check` no longer loses every finding in a run because one file's front + matter could not be parsed. A Vale front-matter error used to abort the + entire Vale invocation before any result was written, so `results` came back + `[]` for the whole run regardless of how many other files had findings — and + `[]` was indistinguishable from a genuinely clean pass. + + `runVale` now retries around a file Vale's own error attributes to one of the + run's targets, excluding it and reporting it as a per-file finding + (`ruleId: "vale-parse-error"`, `severity: "error"`) instead of failing the + whole run. Every other file's findings are reported normally. A failure Vale + does not attribute to a single target file — a malformed rule, a timeout, a + crash — is unaffected and still fails the run exactly as before. + +- 3cfbe5b: `rule create --json` and `rule improve --json` now emit the standard `{ ok: +false, code, message }` envelope on stdout when a file-set rule arrives with + a stray `tests` field, instead of throwing a bare, unreported `CLIError`. + Previously the guard threw from inside the command's own `try` without going + through the command's `fail()` helper, so under `--json` nothing was written + to stdout at all — prose landed on stderr and the process exited 1, + indistinguishable from a crash, and the `RULE_GENERATION_FAILED` code the + `create-remote-rule` recipe documents as a branch target was never actually + reachable for this guard. Both call sites now route through `fail()`, and the + duplicated guard itself was consolidated into one shared check so the two + copies cannot drift again silently. + + Not addressed here: rules written to disk earlier in the same delivery loop + (before the guard fires) are still not named in the failure envelope. The + published envelope shape (`CLIErrorEnvelope`) has no field for a partial file + list, and adding one is a schema change out of scope for this fix. + +- b6668ea: Corrected the published `@taskless/cli/schemas` docstrings for + `verifyOutputSchema` and `valeVerifyOutputSchema`, which named a command form + — `taskless rule verify --json` — that was removed when rule addressing + moved from id to path. No runtime behavior changes; the schemas themselves + are unchanged. A consumer reading these docstrings (e.g. via editor + tooltips or generated docs) would previously be pointed at a command that + does not exist. +- 878a53d: `check` no longer risks losing every Vale finding in a run to one oversized + file. Vale's cost is quadratic in a single file's size (measured against the + pinned binary: 128KB is ~0.8s for one rule, 384KB is already ~7s), and + `VALE_TIMEOUT_MS` bounds the whole run, not one file — a large enough + document could consume most or all of that budget on its own, and a timeout + discards every other file's findings along with it (the same failure #300 + fixed, on a path #300 did not cover). + + `runVale` now excludes a target file over 128KB (`VALE_MAX_FILE_BYTES` in + `src/rules/vale/run.ts`) before invoking Vale at all, the same preemptive + treatment already given to a format Vale cannot parse — but only when some + Vale rule's own `.vale.ini` section could actually reach that file. + `assembleValeConfig` now returns the section patterns it wrote alongside the + config path, and the size scan globs by those patterns (`findOversizedFiles` + in `src/rules/vale/formats.ts`) instead of walking every file in the project. + A first version of this fix scanned the whole tree unconditionally and named + `pnpm-lock.yaml` and `packages/cli/CHANGELOG.md` as "not checked" on this very + repository, even though no rule's matcher touches either file — Vale was + never going to open them, so that was a false positive, not a caught coverage + hole. Excluded files are named in a `notices` entry rather than a finding: + unlike an unparseable file (where Vale itself proves the file was a real + target by erroring on it), this exclusion is a preemptive guess from a + filesystem walk, and a soft advisory fits an unconfirmed guess better than a + hard error. + + A consumer may now see a `check` that previously counted a large file's + prose findings instead report a `notices` entry naming that file as skipped + — but only for a file some rule's own scope actually reaches. 128KB is + comfortably past hand-written prose (roughly 20,000 words); this should only + affect generated output, pasted data, or exported notes checked directly + against a matching rule. + +- 665802d: Telemetry now records six adoption dimensions on every event: `workspaceId` and + `repositoryId` (both hashed), `envOS`, `ci`, `ciProvider`, and `languageStack`. + `cli_check_completed` also reports `ruleCount`, so a scan that loaded no rules + is distinguishable from one that loaded rules and found nothing. + + Nothing to react to. No command changes behaviour, no output changes shape, and + every dimension falls back to a sentinel rather than failing — telemetry is not + a precondition for any command. `TASKLESS_TELEMETRY_DISABLED=1` and + `DO_NOT_TRACK=1` continue to short-circuit before any of it is resolved, so the + opt-out remains an opt-out of the work rather than only of the send. + + `patch` rather than `minor` because the package is pre-1.0, where added surface + does not earn a `minor`, and because none of this is API a consumer can call. + +- 4626c20: Fixed `check --json` reporting a `raw`-scope Vale finding's `range.start.line` + one line earlier than the flagged text (#297). A `raw` pattern is + conventionally anchored with a leading `\n` so it can require "start of line" + against the unparsed document; that `\n` is part of Vale's reported match, and + Vale attributes `Line` to the newline ending the previous line rather than to + the line the flagged text is actually on. The mapper now counts a match's + leading newlines and adds them back before converting to the 0-indexed + `CheckResult.range` every source uses. + + `default`-scope findings were not affected: Vale already reports the correct + 1-based line for them, and `range.start.line` is 0-indexed by design (every + source in `CheckResult.range` is — `format.ts` adds 1 back when it displays, + and #297's "off by one" for default-scope rules was this documented + convention compared against a 1-based file line, not a bug). + ## 0.11.1 [Compare with v0.11.0](https://github.com/taskless/cli/compare/v0.11.0...v0.11.1) diff --git a/packages/cli/package.json b/packages/cli/package.json index 72c36696..3d2aadfd 100644 --- a/packages/cli/package.json +++ b/packages/cli/package.json @@ -1,6 +1,6 @@ { "name": "@taskless/cli", - "version": "0.11.1", + "version": "0.11.2", "license": "MIT", "repository": { "type": "git", diff --git a/skills/taskless/SKILL.md b/skills/taskless/SKILL.md index 3e9e5a03..c570e9d7 100644 --- a/skills/taskless/SKILL.md +++ b/skills/taskless/SKILL.md @@ -20,7 +20,7 @@ description: | `agent route`; it does NOT suppress the skill. metadata: author: taskless - version: 0.11.1 + version: 0.11.2 commandName: tskl compatibility: Designed for Agents implementing the Agent Skills specification. ---