diff --git a/.changeset/engine-partitioned-layout.md b/.changeset/engine-partitioned-layout.md deleted file mode 100644 index 597179b8..00000000 --- a/.changeset/engine-partitioned-layout.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -"@taskless/cli": minor ---- - -Partition `.taskless/` by rule engine. Migration `0004` moves ast-grep rules to `sg/rules/` and `sg/rule-tests/`, the runtime tree to `runtime/rules/` and `runtime/rule-tests/`, and scaffolds an inert `vale/`. Files move byte-for-byte, so runtime rule signatures survive. - -The directory a rule sits in now **is** its engine: dispatch reads the path and never parses a rule file to decide who owns it. `check` runs ast-grep against the committed `.taskless/sg/sgconfig.yml` instead of generating an ephemeral config each run. - -A rule engine the CLI does not recognize is now rejected with a message instead of failing silently: an unsupported engine from the server previously exited 0 with no output, which read as success. - -Runtime rules are discovered under `runtime/rules/` rather than the pre-migration `runtime-rules/`. Migration `0004` moves that tree byte-for-byte, so the signatures the server validates are unchanged. - -`check` and `rule verify` read the committed `.taskless/sg/sgconfig.yml` rather than writing an ephemeral config on every run, so the config ast-grep uses is the one you can edit and review. A pre-migration rule set still gets a generated config, so an unmigrated project keeps running. - -Existing projects keep working without action. The pre-`0004` `.taskless/rules/` still runs as ast-grep, and a delivered rule that names no engine is still treated as ast-grep — a rule engine this CLI does not recognize is rejected rather than guessed at. A migration that would have to merge a file into an engine directory now refuses up front with `SCAFFOLD_CONFLICT` rather than failing part-way. diff --git a/.changeset/export-knowledge-prompts.md b/.changeset/export-knowledge-prompts.md deleted file mode 100644 index 45f9d9f6..00000000 --- a/.changeset/export-knowledge-prompts.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -"@taskless/cli": minor ---- - -Add a `@taskless/cli/prompts` subpath export exposing the CLI's knowledge prompts as importable, topic-keyed render functions. - -`getPrompt(topic, options?)` and the `PROMPTS` map return fully rendered recipe text, with every `%(KEY)s` placeholder already resolved from values the package holds, so a consumer never handles a template dialect. Topic names are typed as `PromptTopic` and start at `static`, the one recipe a service-side consumer can act on; everything else stays internal until a consumer needs it. `PromptOptions` covers the anonymous variant, a `packageManagerDlx` override, and `header: false` for callers placing the text in an LLM system prompt, where the CLI version in the header would otherwise churn the prompt-cache key on every publish. - -The export is sourced from the same embedded recipes and the same render path `taskless help ` serves, so the two surfaces cannot drift, and it carries no CLI runtime, so a Worker can import it without pulling in the command tree. diff --git a/.changeset/vale-platform-packages.md b/.changeset/vale-platform-packages.md deleted file mode 100644 index f1c08155..00000000 --- a/.changeset/vale-platform-packages.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -"@taskless/cli": minor ---- - -Ship Vale as per-platform binary packages. - -The CLI now declares `@taskless/vale--` as `optionalDependencies` pinned -to an exact version, so installing it also brings down a verified Vale binary for -the host platform — no lifecycle script, and nothing to download at runtime. Only -the matching platform installs; unsupported hosts install cleanly with none -present and continue to fall back to a `vale` found on `PATH`. diff --git a/.changeset/wild-jars-repeat.md b/.changeset/wild-jars-repeat.md deleted file mode 100644 index 488fdb1e..00000000 --- a/.changeset/wild-jars-repeat.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -"@taskless/cli": patch ---- - -Resolve the ast-grep binary without relying on an install-time step, and drop -the `@ast-grep/cli` wrapper from what consumers install. - -- **The wrapper moves to `devDependencies`.** The seven `@ast-grep/cli-` - packages were already declared in `optionalDependencies`, and the CLI already - resolved them by path — the wrapper was a leftover whose only job is a - `postinstall` that hardlinks the binary into itself so its `bin` entries work. - Nothing here invoked those entries. Consumers now install only the platform - package matching their host, and the wrapper's `postinstall` — which leaves a - placeholder text file where the binary should be under `pnpm dlx`'s strict - isolation — is out of the shipped product entirely. It stays as a - `devDependency` because `fetch-ast-grep-schema` reads its version. -- **Platform packages are pinned exactly at `0.41.0`.** They were carets, and the - wrapper had been enforcing alignment implicitly by pinning its own - `optionalDependencies`; without it, two hosts could resolve different ast-grep - versions against the same rules and disagree about findings. Held at `0.41.0` - rather than taking upstream's `0.45.0`, so this change stays structural. -- **Binary resolution exhausts every candidate before failing.** It now searches - the platform package, `node_modules/.bin`, then `sg` and `ast-grep` on `PATH`, - and throws naming what it tried. Previously it returned a bare `"sg"` and let - `spawn`'s `ENOENT` be the error, from a caller that could not say where it had - looked. - -Alpine improves as a side effect: upstream publishes no musl build and marks its -Linux packages `libc: ["glibc"]`, so today the wrapper's `postinstall` resolves a -package that does not exist and exits 1, failing the install wherever dependency -scripts run. Installing now succeeds and resolution falls through to `PATH`. diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json index 22a15c42..250467c8 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.10.2", + "version": "0.11.0", "author": { "name": "Taskless" }, diff --git a/package.json b/package.json index dbd9e4cb..2d9e411c 100644 --- a/package.json +++ b/package.json @@ -1,7 +1,7 @@ { "private": true, "name": "@taskless/skills", - "version": "0.10.2", + "version": "0.11.0", "license": "MIT", "repository": "taskless/cli.git", "scripts": { diff --git a/packages/cli/CHANGELOG.md b/packages/cli/CHANGELOG.md index ec084400..972c714f 100644 --- a/packages/cli/CHANGELOG.md +++ b/packages/cli/CHANGELOG.md @@ -1,5 +1,64 @@ # @taskless/cli +## 0.11.0 + +### Minor Changes + +- f7ee186: Partition `.taskless/` by rule engine. Migration `0004` moves ast-grep rules to `sg/rules/` and `sg/rule-tests/`, the runtime tree to `runtime/rules/` and `runtime/rule-tests/`, and scaffolds an inert `vale/`. Files move byte-for-byte, so runtime rule signatures survive. + + The directory a rule sits in now **is** its engine: dispatch reads the path and never parses a rule file to decide who owns it. `check` runs ast-grep against the committed `.taskless/sg/sgconfig.yml` instead of generating an ephemeral config each run. + + A rule engine the CLI does not recognize is now rejected with a message instead of failing silently: an unsupported engine from the server previously exited 0 with no output, which read as success. + + Runtime rules are discovered under `runtime/rules/` rather than the pre-migration `runtime-rules/`. Migration `0004` moves that tree byte-for-byte, so the signatures the server validates are unchanged. + + `check` and `rule verify` read the committed `.taskless/sg/sgconfig.yml` rather than writing an ephemeral config on every run, so the config ast-grep uses is the one you can edit and review. A pre-migration rule set still gets a generated config, so an unmigrated project keeps running. + + Existing projects keep working without action. The pre-`0004` `.taskless/rules/` still runs as ast-grep, and a delivered rule that names no engine is still treated as ast-grep — a rule engine this CLI does not recognize is rejected rather than guessed at. A migration that would have to merge a file into an engine directory now refuses up front with `SCAFFOLD_CONFLICT` rather than failing part-way. + +- d4fca88: Add a `@taskless/cli/prompts` subpath export exposing the CLI's knowledge prompts as importable, topic-keyed render functions. + + `getPrompt(topic, options?)` and the `PROMPTS` map return fully rendered recipe text, with every `%(KEY)s` placeholder already resolved from values the package holds, so a consumer never handles a template dialect. Topic names are typed as `PromptTopic` and start at `static`, the one recipe a service-side consumer can act on; everything else stays internal until a consumer needs it. `PromptOptions` covers the anonymous variant, a `packageManagerDlx` override, and `header: false` for callers placing the text in an LLM system prompt, where the CLI version in the header would otherwise churn the prompt-cache key on every publish. + + The export is sourced from the same embedded recipes and the same render path `taskless help ` serves, so the two surfaces cannot drift, and it carries no CLI runtime, so a Worker can import it without pulling in the command tree. + +- 6b07695: Ship Vale as per-platform binary packages. + + The CLI now declares `@taskless/vale--` as `optionalDependencies` pinned + to an exact version, so installing it also brings down a verified Vale binary for + the host platform — no lifecycle script, and nothing to download at runtime. Only + the matching platform installs; unsupported hosts install cleanly with none + present and continue to fall back to a `vale` found on `PATH`. + +### Patch Changes + +- db8adfa: Resolve the ast-grep binary without relying on an install-time step, and drop + the `@ast-grep/cli` wrapper from what consumers install. + - **The wrapper moves to `devDependencies`.** The seven `@ast-grep/cli-` + packages were already declared in `optionalDependencies`, and the CLI already + resolved them by path — the wrapper was a leftover whose only job is a + `postinstall` that hardlinks the binary into itself so its `bin` entries work. + Nothing here invoked those entries. Consumers now install only the platform + package matching their host, and the wrapper's `postinstall` — which leaves a + placeholder text file where the binary should be under `pnpm dlx`'s strict + isolation — is out of the shipped product entirely. It stays as a + `devDependency` because `fetch-ast-grep-schema` reads its version. + - **Platform packages are pinned exactly at `0.41.0`.** They were carets, and the + wrapper had been enforcing alignment implicitly by pinning its own + `optionalDependencies`; without it, two hosts could resolve different ast-grep + versions against the same rules and disagree about findings. Held at `0.41.0` + rather than taking upstream's `0.45.0`, so this change stays structural. + - **Binary resolution exhausts every candidate before failing.** It now searches + the platform package, `node_modules/.bin`, then `sg` and `ast-grep` on `PATH`, + and throws naming what it tried. Previously it returned a bare `"sg"` and let + `spawn`'s `ENOENT` be the error, from a caller that could not say where it had + looked. + + Alpine improves as a side effect: upstream publishes no musl build and marks its + Linux packages `libc: ["glibc"]`, so today the wrapper's `postinstall` resolves a + package that does not exist and exits 1, failing the install wherever dependency + scripts run. Installing now succeeds and resolution falls through to `PATH`. + ## 0.10.2 ### Patch Changes diff --git a/packages/cli/package.json b/packages/cli/package.json index 6b0d1a5e..9f6139c1 100644 --- a/packages/cli/package.json +++ b/packages/cli/package.json @@ -1,6 +1,6 @@ { "name": "@taskless/cli", - "version": "0.10.2", + "version": "0.11.0", "license": "MIT", "repository": { "type": "git", diff --git a/skills/taskless/SKILL.md b/skills/taskless/SKILL.md index 1a32ef12..5ed1303d 100644 --- a/skills/taskless/SKILL.md +++ b/skills/taskless/SKILL.md @@ -20,7 +20,7 @@ description: | `taskless help route`; it does NOT suppress the skill. metadata: author: taskless - version: 0.10.2 + version: 0.11.0 commandName: tskl compatibility: Designed for Agents implementing the Agent Skills specification. ---