chore: version packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@taskless/cli@0.11.2

Compare with v0.11.1

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@<version> 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 <id> --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.

• 4626c20: Fixed check --json reporting a raw-scope Vale finding's range.start.line
  one line earlier than the flagged text (check --json reports Vale findings 1 line early, or 2 lines early for raw-scope rules #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 check --json reports Vale findings 1 line early, or 2 lines early for raw-scope rules #297's "off by one" for default-scope rules was this documented
  convention compared against a 1-based file line, not a bug).

Build Info

npx @taskless/cli-nightly@0.11.2-20260909051148x9818bc6

Built from: 9818bc6
Built at: 2026-09-09 05:11:48