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

• 80e5309: Update the bundled ast-grep to 0.45.3 (from 0.45.2).

  What a rule author sees in taskless check on ast-grep rules:

  • An inline ast-grep-ignore comment in scanned code now takes effect only when it is the comment's first alphabetic text. A comment that merely mentioned the directive as prose above a flagged line used to suppress the finding; it no longer does, so findings can appear that were hidden before. Move ast-grep-ignore to the start of the comment if the suppression was meant.
  • The same prose mentions no longer produce unused-suppression hints.
  • Rule files, taskless verify, and the language list are unchanged. Nothing installed under .taskless/ needs migrating.

• 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.

• b68b095: taskless init is now the batch install in every context, and --no-interactive is dropped: a bare npx @taskless/cli in a terminal is the wizard, init is the install and upgrade path for agents, scripts, and CI, and agent init is the recipe. A script that still passes the flag gets init unchanged. init ends with an upgrade trailer naming the directories that hold changed files and, after a CLI version move, pointing at taskless update; the --json envelope gains cliVersion, a per-target targets summary, and a changed flag. A canonical .taskless/ file whose bytes already match the bundle is no longer rewritten or reported as written. The agent subcommand serves every recipe under a fetch-time directive (fetch again next task; a session that installed or upgraded Taskless holds a stale skill), which the @taskless/cli/prompts export does not carry and which header: false strips with the version. The agent init recipe is rewritten for the agent that runs it, and the skill and tskl command say a recipe is fetched again for each task. The skill and command sources name the CLI through the %(TASKLESS_CLI)s placeholder, rendered at install, so a nightly or dev build no longer depends on finding the literal npx @taskless/cli in prose.

• 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.

• 46eccf7: .taskless/.gitignore now ignores /.tmp-*, the scratch request files the agent recipes write (.tmp-rule-request.json, .tmp-improve-request.json), so a file an agent forgot to clean up is a stray rather than a commit. This is scaffold migration 7; the scaffold's own version field carries the compatibility signal, and a project at 6 gains one ignore line the next time it is bootstrapped.

  A feedback subcommand joins the CLI, reached only through the survey invite a served recipe carries and so absent from the taskless agent index: feedback send --from <file> validates a human-keyed payload (verbatim, goal, completed as Yes/No/Unknown, optional workedWell and needsImprovement), maps it to the PostHog survey's question ids, and captures survey sent; feedback dismiss captures survey dismissed. Both hold the next invite off for 20 days and, under the telemetry opt-out, say nothing was sent and exit 0.

  Two recipes back it: taskless agent feedback tells the agent it is the survey's respondent (the user's reply verbatim, the rest from its own account of the session) and embeds the payload schema; feedback-invite is the fragment a served recipe carries, rendered header-less.

  The four recipes where an agent-driven session most often goes wrong (onboard, create-sg-rule, create-vale-rule, create-remote-rule) now end with a short feedback invite when telemetry is on, the run is not in CI, and the survey's next_ask has passed. Serving it captures survey shown and holds the next invite off for 10 days; taskless onboard and taskless agent onboard both carry it. The @taskless/cli/prompts export never does. DO_NOT_TRACK=1, TASKLESS_TELEMETRY_DISABLED=1, or CI=true means no invite is served.

• 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.

• 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 One unparseable file zeroes findings for the whole check run #300
  fixed, on a path One unparseable file zeroes findings for the whole check run #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.

• 18871a1: Update the bundled Vale to 3.21.0.

  For a rule under .taskless/rules/vale/, what you can now write:

  • scope: doc(<selector>) picks part of a document by CSS selector, where a heading and everything under it is a section: text & doc(section:has(> h2:contains("Decision"))) is one section's prose, ~doc(...) is everything outside it, and a metric scoped to doc(...) puts a word budget on that section alone. A leaf element on its own (doc(h2)) is inert; chain it (text & doc(h2)). verify accepts the family and leaves the selector to Vale, which rejects one it cannot compile at load.
  • A metric honors its scope: scope: sentence measures each sentence rather than the whole document. An absent scope, or scope: text, still measures the document.
  • .ipynb is a format: Markdown cells are read as Markdown, code cells as their kernel's comments, raw cells and outputs not at all. Findings point at the notebook file's own lines.
  • BlockIgnores and TokenIgnores in a rule's .vale.ini now apply under an [*.html] matcher.

  What changes for a rule you already have:

  • A [glob] section repeated in a rule's .vale.ini, or a key repeated inside one, now keeps its last assignment rather than its first. Precedence is last-wins in both directions, so a disable placed after the enable it narrows works in every shape.
  • An unknown action name is refused when the rule loads, and one config serves the whole run, so a typo there fails every Vale rule in the project. verify now rejects a name outside replace, remove, suggest, convert, edit.
  • A metric that declared a scope was measuring the whole document anyway; it now measures what the scope names, so its findings move.
  • A rule matching [*.ipynb] was linting the notebook's JSON; it now reads cells, so findings from outputs and metadata are gone.

  taskless agent update carries the same list, with what to do about each.

• 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-20260919030302xb1280ac

Built from: b1280ac
Built at: 2026-09-19 03:03:02