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

Compare with v0.11.2

Patch Changes

• aa49d45: taskless check --rule <id> (repeatable) restricts a run to the named rules, so a rule can be measured over the whole project without running every other rule and filtering the JSON afterwards. The filter applies to both static engines and to runtime rules, keeps every exclusion a whole-project run applies, and refuses an id no rule directory has.

• d7b33ab: taskless detect recognizes oxlint alongside eslint, biome and stylelint, from .oxlintrc.json, .oxlintrc.jsonc, oxlint.config.ts, oxlint.config.mts, or an oxlint entry in package.json.

• 5047148: The feedback survey is replaced for 0.11.3. Only the kind of rule the user was trying to create is required now; the user's own words, the completion verdict, what worked, what did not, the agent in use, and the most valuable rule so far are all optional. A skip at the invite no longer dismisses the survey: the agent sends its own account of the session and leaves the user's words out. feedback dismiss is reserved for a user who asks that nothing be sent. Every install is invited once more, since the new survey keeps its own cadence.

• d41576f: Two rules can no longer share an id across engines. verify fails a rule whose id is also a directory name under another engine, and a new scaffold migration (9) renames the ones that already exist.

  .taskless/rules/sg/no-eval/ beside .taskless/rules/vale/no-eval/ was silent: check's human output prints error[no-eval] with no engine, so a collision shows two identical lines, and every id-addressed command had two answers to choose between.

  Your rule ids may change on upgrade, and check output changes with them. The first taskless init after upgrading renames the colliding sg and vale copies to <id>-<engine> — sg/no-eval becomes sg/no-eval-sg, vale/no-eval becomes vale/no-eval-vale. Where both move, neither keeps the bare id, so nobody has to work out which of their two rules kept the name. If <id>-<engine> is already taken it uses the next free <id>-<engine>-2, -3, … and never overwrites an existing rule.

  A runtime rule is never renamed and keeps the bare id, so a collision between runtime and another engine moves only the other one. Runtime rules are the signed and blessed tier, and this keeps the upgrade clear of that machinery. Nothing is left colliding either way, because one engine can only hold one directory per id.

  Everything the rename touches is inside the rule's own directory: the directory name, the rule file, its id: field, an sg rule's .tests/ fixtures and their id: fields, and a Vale rule's .vale.ini breadcrumb and both segments of its <id>.<id> assignment. Every rename is printed — old path, new path, and each file rewritten — as is any runtime rule that kept its id, so you can see exactly what moved before committing it. Update any CI config, baseline file or suppression comment that names an old id — including check --rule <id>, which errors with RULE_NOT_FOUND rather than reporting zero findings when the id it names has been renamed out from under it.

  .taskless/rule-metadata/<id>.yml is left where it is rather than following either rule, since a symmetric rename gives it no owner. In practice there is nothing there: this CLI has never written a sidecar, because the service does not return the metadata block they are written from.

• d3befa0: Update the bundled Vale to 3.22.0.

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

  • scope: text & ~link (and ~strong, ~emphasis, ~code) runs on the paragraph and blanks the element's text out of it before the rule sees it, so a wording or casing rule can leave link text and bold terms alone without giving up the sentence around them. Positions after the blanked element do not move. The release note's text.raw and paragraph.link spellings are not scopes; verify rejects them, so write the bare inline name.
  • split: true on a spelling rule checks the parts of an identifier (getHTTPResponsze_v2 reports Responsze) and places each at its own position. 3.21.0 accepted the key and did neither.
  • A frontmatter or frontmatter.<key> rule reports every occurrence in a field at the field's own position; a token appearing twice in one field was reported once.
  • A one-line MDX element's text (<Note>...</Note>) is linted.

  What changes for a rule you already have:

  • BasedOnStyles = is removed from every rule's .vale.ini, by migration 0008 on the next init, and verify now rejects the key with any value (vale-config-no-based-on-styles). Every earlier version of the create-vale-rule recipe wrote the line into every matcher, where it was inert: no bundled style loads unless a run-level BasedOnStyles names one, and the assembled header names none. On 3.22.0 an empty value clears every setting a file inherited from an earlier matcher, and the assembled run config is every rule's matchers in id order, so a rule writing the line under [docs/**] silenced every alphabetically earlier rule under docs/, and [*.md] beside another rule's [*.{md,markdown}] silenced the first on every .md file, with nothing reported. check and verify refuse to run until init has migrated the configs, and name it; commit the rewritten files. A migrated config enables exactly what the old one did on 3.21.0.
  • A rule whose scope negates link, strong, emphasis or code no longer sees that element's text inside a paragraph. Through 3.21.0 the paragraph still carried it, so findings inside those elements disappear. Drop the negation if the rule was meant to reach them.
  • The isolating config test and verify build no longer writes BasedOnStyles =. Measured on both binaries, nothing fires without it and Vale.Spelling never could, so fixtures behave as before.

  Not changed for a rule this CLI assembles: a [formats] key may now be a file name or a glob, but no rule config can carry one and the assembled header writes none, so the extension still decides the parser. UNSET as a rule's value behaves as NO and is not accepted; YES and NO remain the two values.

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

• 620865e: verify validates a Vale rule's .vale.ini against a schema and names the constraint each rejection violates. The config is parsed into an ordered structure and checked there: an assignment above the first matcher, a matcher without its tskl) rule breadcrumb, a key naming another rule, a value other than YES/NO, a BasedOnStyles assignment with any value, a config with no matcher or no YES, and a NO matcher that precedes every YES (both judged by each matcher's final verdict, so a YES a later NO in the same matcher overrides does not count) are each rejected under a vale-config-* constraint that verify --json reports in violations[] and reference.json publishes. A repeated key, a [*] matcher, and a .taskless/** matcher are reported as a notice without failing the rule.

  check runs the same schema before assembling the Vale run config, and a rejected config refuses the Vale engine for that run: the failure names the rule and the line, reaches the exit code, and ast-grep still runs. A rule is never silently left out of the assembled config. Accepted configs are written verbatim under their breadcrumb, so the one string edit assembly used to make (dropping a copied-in StylesPath) is gone; that line is now a rejection. Advisories reach check's notices. To find every rejected line at once, run taskless verify.

  This is still patch. The package is 0.y.z, and every config the schema refuses was already being misread by Vale: a rule enabled nowhere with a W101 on stderr, a rule silently overriding a neighbour, a disable the following enable cancelled. The release surfaces a defect the consumer already had rather than introducing one, the same call as linting files over 128 KB again in 0.11.3.

• 78dc643: verify warns when a Vale rule's raw list has more than one entry, since Vale concatenates them into one pattern rather than alternating them; the create-vale-rule recipe explains the (a|b) form. The warning rides on notice and does not fail the rule.

• 3acb5a1: agent create-vale-rule (topic v13) corrects two claims that cost rule authors work. Vale patterns are not RE2-only: Vale compiles with Go's regexp and falls back to regexp2, so lookahead, lookbehind and backreferences work, and the recipe no longer tells you to split a rule that one pattern expresses. Two silent limits are measured and documented alongside it: a backreference does nothing as a swap key, and the implicit word boundary on tokens/swap lands after a trailing lookahead, so that lookahead has to peek at a non-word character. check on a rule's .tests/fail bucket is a supported way to read a rendered message, because .taskless/ is excluded from the whole-project walk only; when that bucket comes back empty, the recipe now sends you to the rule's own config, specifically a [.taskless/**] matcher, before the pattern.

  verify carried the same imprecision and now states both halves: a [.taskless/**] matcher is unnecessary on a whole-project check, AND it silences the rule on a path you name, such as the rule's own fixture bucket. It was previously described as acting only under a bare vale invocation, which read as harmless. agent update (topic v10) is corrected to match.

• b2e2662: check no longer skips Vale target files over 128 KB. The guard
  (VALE_MAX_FILE_BYTES, added in 0.11.2) was written against Vale 3.20.0,
  whose lint time grew superlinearly with the size of a single Markdown block,
  so one large file could consume the run's whole timeout and, because Vale
  writes nothing until the run finishes, cost every other file its findings.
  The same release moved the vendored Vale to 3.21.0, whose perf work makes that
  cost linear regardless of block structure, so the cap no longer separates a
  cheap file from an expensive one. Re-measured on the reproduction from
  Track upstream: Vale lint time is superlinear in single-block size, and no output is emitted until the run finishes #325 against the vendored 3.21.0 binary (darwin/arm64, warm, median
  of three):

  fixture	Vale 3.20.0	Vale 3.21.0
  3.2 MB, one block (huge.md)	~81,000 ms	~230 ms
  3.2 MB, blank-line separated	~4,400 ms	~290 ms
  128 KB, one block (the old cap)	~770 ms	~26 ms
  25 MB, one block	—	~2,200 ms

  What a user sees: a file that 0.11.2 named in a Vale did not check N file(s) over 131072 bytes notice is linted again and produces findings; the notice is
  gone. The per-file retry for a target whose front matter Vale cannot parse
  (One unparseable file zeroes findings for the whole check run #300) is unchanged, as is the 60 s run timeout. Vale still emits
  nothing until the run completes, so a run killed by an external time limit
  still loses every finding; with linear cost that takes a file in the hundreds
  of megabytes rather than the hundreds of kilobytes.

• f97365d: taskless --version and -v print the version. Before, both fell through to the full usage banner, and -v was not recognised at all.

Build Info

npx @taskless/cli-nightly@0.11.3-20260922213651xb1896ef

Built from: b1896ef
Built at: 2026-09-22 21:36:51