From 73922fc7b7d249919a03a0e39531bc0595bed53c Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Tue, 8 Sep 2026 18:15:52 +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/vale-raw-scope-line-numbers.md | 18 ------ .claude-plugin/plugin.json | 2 +- package.json | 2 +- packages/cli/CHANGELOG.md | 62 +++++++++++++++++++ packages/cli/package.json | 2 +- skills/taskless/SKILL.md | 2 +- 10 files changed, 66 insertions(+), 78 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/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/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..84290b85 100644 --- a/packages/cli/CHANGELOG.md +++ b/packages/cli/CHANGELOG.md @@ -1,5 +1,67 @@ # @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. + +- 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. ---