fix(release): fold the unpublished 0.11.3 into 0.12.0

.changeset/check-rule-filter.md

@@ -0,0 +1,5 @@
+---
+"@taskless/cli": patch
+---
+
+`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.

.changeset/detect-oxlint.md

@@ -0,0 +1,5 @@
+---
+"@taskless/cli": patch
+---
+
+`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`.

.changeset/feedback-survey-0-12-0.md

@@ -0,0 +1,5 @@
+---
+"@taskless/cli": patch
+---
+
+The feedback survey is replaced for 0.12.0. 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.

.changeset/migration-9-atomicity.md

@@ -0,0 +1,15 @@
+---
+"@taskless/cli": patch
+---
+
+Scaffold migration `9` — the one that renames a rule id held by more than one engine — now survives being interrupted, and no longer double-suffixes a fixture you had already named `<id>-sg-…`.
+
+Migration 9 has not been in a released version, so nothing on disk anywhere was produced by the old behaviour and there is no repair step to run. `latest` is `0.11.2`, tagged 2026-09-19; the migration landed 2026-09-22.
+
+**It could not resume.** It renamed the rule directory first and then chased the files inside it, but renaming the directory is what resolves the collision, and the migration returns early when no collision is left. So a run that died in between — a `Ctrl-C`, a full disk, an editor holding a file open — left `sg/no-eval-sg/` containing `no-eval.yml` with `id: no-eval` and fixtures still under the `no-eval-` prefix. `verify` reported that as broken, and running `taskless init` again fixed nothing, because every later run found no collision and returned.
+
+The order is reversed: the rule file, its `id:` field, the `.tests/` fixtures and a Vale rule's `.vale.ini` are all rewritten under the old directory name, and the directory rename is the last thing to happen. A directory rename is a single atomic operation, so it is the moment a rule is done. A rule interrupted before it still collides and is picked up by the next run; a rule interrupted after it is already whole. Each inner step also tolerates having already run, and every file rewrite is committed by renaming a temporary sibling, so an interrupted write cannot truncate a rule file.
+
+One asymmetry can survive an interruption. Where `sg` and `vale` both hold an id, a complete run moves both and neither keeps the bare id. If a run is interrupted between the two halves, the half that finished keeps its suffix and the other keeps the bare id, because the collision it would have been renamed for is gone. The tree is collision-free and every rule is internally consistent; only the symmetry is lost. Rename it yourself if you want the pair to match.
+
+**A fixture already named `<id>-sg-…` is no longer renamed again.** The predicate picking fixtures to rename matched every name it produced, so `no-eval-sg-basic-test.yml` in `sg/no-eval/.tests/` came out as `no-eval-sg-sg-basic-test.yml` on the first run. Such a fixture is already at the right prefix, so it now keeps its name and only its `id:` field follows — which still matters, since ast-grep attributes cases by the `id:` inside the file and a stale one reads as a rule that shipped no cases.

.changeset/migration-failure-reporting.md

@@ -0,0 +1,7 @@
+---
+"@taskless/cli": patch
+---
+
+A failing schema migration is now reported once instead of twice, and the message names the migration that refused. `runMigrations` used to print `Migration N failed: <message>` itself and then rethrow the original, so the caller printed the same text again without the migration number — the longer and more useful the refusal, the worse it read. The prefix now rides on the rethrown error, so there is one string and one printer, and the original `CLIError` code (for example `SCAFFOLD_CONFLICT`) is preserved.
+
+`taskless init --json` also emits an error envelope when a migration fails. It previously wrote nothing at all to stdout and put prose on stderr, leaving a machine consumer with only the exit code; it now writes the standard `{ ok: false, code, message }` envelope, with the migration number in `message`.

.changeset/notice-list-contract.md

@@ -0,0 +1,11 @@
+---
+"@taskless/cli": patch
+---
+
+`taskless check` now marks every notice it prints. A run with more than one advisory used to print the first behind a `Notice: ` marker and the rest as bare, unindented lines with nothing identifying them as notices — so a Vale config advisory sitting beside Vale's own diagnostic read as stray output. `verify` had the same defect and it was fixed earlier; `check` did not get the fix until now.
+
+A second, related gap in the same output: the notices from runtime rule planning — what was repaired, what could not be, and why — were printed by their own loop with no `Notice: ` marker at all, while engine notices were marked. `check --json` merges both into one `notices` array, so the same message looked like two different kinds of thing depending on which list it arrived on. Every notice `check` prints is now marked, and every line of one is.
+
+The cause was that notices were joined into one string before they reached the renderer, so `check --json` also published array elements that were several notices glued together, with no separator a consumer could rely on to split them back apart. Notices are now carried as a list from producer to output: in `check --json` the `notices` array keeps its name and type, and only its element boundaries change — one element is now exactly one notice.
+
+**What a consumer crosses:** the optional `notice` string on `verify --json` and `test --json` per-rule results is now a `notices` array of strings, present and empty rather than absent when there is nothing to say. The same replacement applies to the exported `verifyOutputSchema` (its `schema` layer) and `valeVerifyOutputSchema`. Read `notices` where you read `notice`, and render one marker per element instead of splitting on a separator. It was replaced rather than mirrored because a joined `notice` kept alongside would preserve the convention this change removes, and nothing ever published the separator that would have made splitting it safe. `check --json` consumers need change nothing.

.changeset/onboard-host-tool-detection.md

@@ -0,0 +1,38 @@
+---
+"@taskless/cli": patch
+---
+
+`taskless info --json` renames its `tools` key to `harnesses`, and gives
+`tools` to the command-line binaries found on `PATH`.
+
+**This is the consumer-visible part.** The array that lists Claude Code,
+Codex, Cursor and OpenCode, with each one's installed skills and their
+staleness, is unchanged in shape — it now lives under `harnesses`. Anything
+reading `.tools[].skills` from `info --json` reads `.harnesses[].skills`
+instead. The new `tools` array carries `{ name, present, applicable, path? }`
+for `gh`, `git` and `jq`.
+
+`present` is established by looking for a file of that name on `PATH`.
+Taskless does not spawn a detected binary, does not read its version, and does
+not hash it, so `present: true` is presence and not a working install. A
+sha256-against-published-releases tier was considered and dropped on
+measurement: GitHub publishes digests for `gh`'s release archives and
+installers rather than for the extracted binary, and a Homebrew-installed `gh`
+2.97.0 matched 0 of the 21 official digests — a tier that reports "unverified"
+for the ordinary macOS install path is worse than no tier at all.
+
+`applicable` is the separate question of whether a tool could accomplish
+anything where it is being asked to. `gh` in a repository with no GitHub
+`origin` is present and inapplicable, and reporting that as "missing" would
+produce the one instruction that cannot help — "install `gh`".
+
+The `onboard` recipe (topic v4) uses both. Its source menu now states what was
+found rather than telling the agent to run `command -v gh`, says in one line
+why a source is not offered instead of dropping it silently, and no longer
+names Linear as the expected issue tracker: a bug-tracker scan is offered when
+the agent has an MCP that reaches one, with Jira and Linear as examples of the
+class. `@taskless/cli/prompts` is unaffected — with no host state supplied the
+recipe renders its full menu, unchanged.
+
+`patch` rather than `minor`: the package is `0.y.z`, where semver puts added
+surface outside the stability guarantee.

.changeset/rule-id-uniqueness.md

@@ -0,0 +1,15 @@
+---
+"@taskless/cli": patch
+---
+
+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.

.changeset/sg-fixture-findings.md

@@ -0,0 +1,20 @@
+---
+"@taskless/cli": patch
+---
+
+`test` now reports the findings an ast-grep rule's fixtures produced, with the
+message as ast-grep rendered it. Previously only Vale and runtime rules carried
+`findings`; an ast-grep rule reported an empty array, so a rule whose message
+interpolated its metavariables in the wrong order fired in exactly the right
+places and was reported green.
+
+Each snippet is replayed through `ast-grep scan --stdin`, so the language comes
+from the rule's own `language:` key and no temporary file is written. A finding
+names the test YAML that declares the snippet, at the snippet's real line and
+column in that file.
+
+Additive, and `patch` under the pre-1.0 rule: the `findings` array was already
+present on every rule result and documented as possibly empty, so nothing a
+consumer reads changes shape. Vale and runtime behaviour is untouched, and the
+verdict `ast-grep test` decides is unchanged — findings are gathered after it
+and cannot alter it.

.changeset/test-show-fixture-findings.md

@@ -0,0 +1,17 @@
+---
+"@taskless/cli": patch
+---
+
+`test --json` now reports the findings a rule's fixtures produced.
+
+Each rule result carries a `findings` array: the same finding shape `check --json` prints — `source`, `ruleId`, `severity`, `message`, `file`, `range`, `matchedText`, and the optional `note` and `fix` — plus a `bucket` of `"pass"` or `"fail"` naming the fixture that produced it. The rendered `message` is the point. A rule whose message interpolates its captures can have the slots in the wrong order, fire on every `fail/` fixture, stay quiet on every `pass/` one, and be reported as a rule that passed; the rendered message is the only evidence otherwise, and until now the only way to see it was a second `check` run against a fixture path you had to construct yourself.
+
+The array is **always present and empty rather than absent** — for a rule that produced nothing, one whose verification failed before its fixtures ran, a refused runtime rule, `verify` (which runs no fixtures at all), and ast-grep rules, whose findings are not surfaced yet. Fail-bucket findings are reported on a passing run too, since that is the only run that produces them.
+
+On the human path a passing rule still prints one line. A **failing** rule now prints the findings that bear on the failure beneath it, labelled by bucket and rendered the way `check` renders a finding. That includes pass-bucket findings: `pass fixture wrongly fired: <file>` said _that_ it happened and never what matched.
+
+Vale and runtime rules only. ast-grep follows separately: the vendored binary's `sg test` has no `--json` and no output-format flag, and its fixtures are inline YAML scalars rather than files.
+
+No flag was added, and nothing new is executed: the findings were already in hand and were being discarded.
+
+**If you consume `@taskless/cli/schemas`:** `zod`'s `.parse()` strips keys the schema does not declare, so a consumer still on the previously published `verifyTestOutputSchema` will silently drop `findings` from the payload it returns until the dependency is upgraded. Nothing breaks — but the field simply not being there, on a CLI that is emitting it, is the kind of thing that generates a bug report.

.changeset/vale-3-22-0.md

@@ -0,0 +1,22 @@
+---
+"@taskless/cli": patch
+---
+
+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.

.changeset/vale-config-schema.md

@@ -0,0 +1,7 @@
+---
+"@taskless/cli": patch
+---
+
+`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`.

.changeset/vale-raw-authoring.md

@@ -0,0 +1,5 @@
+---
+"@taskless/cli": patch
+---
+
+`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.

.changeset/vale-recipe-regex-and-fixtures.md

@@ -0,0 +1,7 @@
+---
+"@taskless/cli": patch
+---
+
+`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.