feat: one directory per rule, and path-addressed verify/test - #103
Conversation
There was a problem hiding this comment.
Pull request overview
This PR standardizes Taskless rule authoring around a “one directory per rule” layout under .taskless/rules/<engine>/<id>/, replaces id-addressed rule verify with path-addressed verify <path> / test <path>, and introduces deterministic assembly of engine configs (Vale .vale.ini + ast-grep .sgconfig.yml) from per-rule sources. It also updates migrations/spec/docs/tests accordingly and adds a committed example/ project kept honest by tests.
Changes:
- Introduce per-rule directory layout across
sg,vale, andruntime, including.tests/and per-rule.vale.ini. - Add path-addressed
verifyandtestcommands (with shared path resolution) and remove id-addressedrule verify. - Add deterministic config assembly for Vale and ast-grep; update check/dispatch, migration wiring, and fixtures; add a committed
example/project plus coverage.
Reviewed changes
Copilot reviewed 89 out of 93 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| packages/cli/test/vale-verify.test.ts | Updates Vale verification tests to the per-rule directory + .tests/ layout and new check naming. |
| packages/cli/test/vale-run.test.ts | Updates Vale runner tests to read the assembled config and new per-rule style locations. |
| packages/cli/test/vale-orchestration.test.ts | Adjusts orchestration tests to new assembled config flow and per-rule rule tree. |
| packages/cli/test/vale-map.test.ts | Updates mapping tests to the new Vale check id shape <id>.<id> and normalization behavior. |
| packages/cli/test/sgconfig.test.ts | Removes tests for legacy sgconfig generation (now replaced by assembly). |
| packages/cli/test/sg-committed-config.test.ts | Removes tests for committed sg config handling (replaced by assembly + new layout). |
| packages/cli/test/runtime-harness.test.ts | Updates runtime harness fixture writer to new runtime rule directory structure (captures/). |
| packages/cli/test/rule-verify-dispatch.test.ts | Removes tests for id-addressed rule verify dispatch/ambiguity behavior. |
| packages/cli/test/onboard.test.ts | Updates install manifest version expectations to version 5. |
| packages/cli/test/mixed-engine-check.test.ts | Updates integration test to author Vale rules/config per-rule and validate runtime warnings behavior. |
| packages/cli/test/migrate-round-trip.test.ts | Adds end-to-end behavioral migration coverage (rules still fire, tests still run, bytes stable). |
| packages/cli/test/migrate-install.test.ts | Updates migration/version assertions to version 5. |
| packages/cli/test/init-no-interactive.test.ts | Updates init scaffold manifest version assertion to version 5. |
| packages/cli/test/fixtures/mixed-engines-project/.taskless/vale/.vale.ini | Removes old committed shared Vale config from the fixture. |
| packages/cli/test/fixtures/mixed-engines-project/.taskless/taskless.json | Bumps fixture manifest version to 5. |
| packages/cli/test/fixtures/mixed-engines-project/.taskless/sg/sgconfig.yml | Removes old committed ast-grep config from the fixture. |
| packages/cli/test/fixtures/mixed-engines-project/.taskless/rules/vale/no-simply/no-simply.yml | Adds Vale rule fixture in the new per-rule directory layout. |
| packages/cli/test/fixtures/mixed-engines-project/.taskless/rules/vale/no-simply/.vale.ini | Adds per-rule Vale config fixture enabling <id>.<id>. |
| packages/cli/test/fixtures/mixed-engines-project/.taskless/rules/vale/no-obviously/no-obviously.yml | Adds a second Vale rule fixture for mixed-engine coverage. |
| packages/cli/test/fixtures/mixed-engines-project/.taskless/rules/vale/no-obviously/.vale.ini | Adds per-rule config for the second Vale rule fixture. |
| packages/cli/test/fixtures/mixed-engines-project/.taskless/rules/sg/no-eval/no-eval.yml | Adds sg rule fixture in the new per-rule directory layout. |
| packages/cli/test/fixtures/mixed-engines-project/.taskless/rules/sg/no-console-warn/no-console-warn.yml | Adds another sg rule fixture in the new directory layout. |
| packages/cli/test/example-project.test.ts | Adds tests ensuring the committed example/ project remains a valid, non-drifting demo. |
| packages/cli/test/error-envelope.test.ts | Removes rule verify error-envelope coverage and updates delete paths to new layout. |
| packages/cli/test/engine-layout.test.ts | Adds tests pinning the .tests/ dot-directory behavior required for ast-grep discovery. |
| packages/cli/test/detect.test.ts | Updates detect tests to report .taskless/rules/sg as a rule style source. |
| packages/cli/test/bootstrap.test.ts | Updates bootstrap/migration tests to the new rule directory layout and .tests/ placement. |
| packages/cli/test/assemble.test.ts | Adds direct tests for deterministic Vale/sg config assembly outputs. |
| packages/cli/test/anonymous-flag.test.ts | Removes rule verify --anonymous coverage (command removed). |
| packages/cli/src/rules/verify.ts | Updates sg verification to new path helpers and assembly-based test execution. |
| packages/cli/src/rules/vale/verify.ts | Updates Vale verify to use per-rule directories and new StylesPath resolution. |
| packages/cli/src/rules/vale/run.ts | Switches Vale runs to the assembled config path and keeps “no paths” behavior safe (.). |
| packages/cli/src/rules/vale/map.ts | Updates Vale check id normalization to collapse only <id>.<id> and leave foreign styles intact. |
| packages/cli/src/rules/scan.ts | Switches ast-grep scanning to the assembled config path. |
| packages/cli/src/rules/runtime/discover.ts | Updates runtime discovery to load capture rules from captures/ under each rule directory. |
| packages/cli/src/rules/resolve-path.ts | Adds path→(engine, ruleId) resolution for verify/test, including directory scoping rules. |
| packages/cli/src/rules/owner.ts | Removes id-based owner detection (no longer needed with path addressing). |
| packages/cli/src/rules/inspect.ts | Adds per-engine verify/test logic used by the new CLI commands. |
| packages/cli/src/rules/files.ts | Updates rule file/test writing and deletion to operate on per-rule directories. |
| packages/cli/src/rules/dispatch.ts | Updates Vale presence detection and ast-grep dispatch to use a single assembled config. |
| packages/cli/src/rules/assemble.ts | Adds deterministic assembly for .taskless/.vale.ini and .taskless/.sgconfig.yml. |
| packages/cli/src/index.ts | Registers new top-level verify and test commands. |
| packages/cli/src/help/verify-rule.txt | Updates recipe to the new verify/test commands and path semantics. |
| packages/cli/src/help/route.txt | Updates detect output example paths to the new .taskless/rules/sg location. |
| packages/cli/src/help/improve-rule.txt | Updates rule location references for improving existing rules in the new layout. |
| packages/cli/src/help/improve-rule.anonymous.txt | Updates anonymous improvement flow to use verify/test and new file paths. |
| packages/cli/src/help/detect.txt | Updates rule style source path examples to .taskless/rules/sg. |
| packages/cli/src/help/delete-rule.txt | Updates delete-rule documentation to new layout (but currently overstates engine support). |
| packages/cli/src/help/create-sg-rule.txt | Updates sg authoring recipe for per-rule directory layout and verify/test. |
| packages/cli/src/help/create-runtime-rule.txt | Updates runtime authoring docs for captures/ + new directory layout. |
| packages/cli/src/help/create-remote-rule.txt | Updates remote authoring docs to new per-rule directory + .tests/ layout. |
| packages/cli/src/help/ci.txt | Updates CI documentation paths for runtime rules under the new root. |
| packages/cli/src/help/check.txt | Updates check documentation to new rule locations and per-rule file naming. |
| packages/cli/src/filesystem/sgconfig.ts | Removes legacy sgconfig generation (superseded by assembly). |
| packages/cli/src/filesystem/migrations/0004-vale-engine.ts | Updates docstring notes to clarify StylesPath correctness depends on layout. |
| packages/cli/src/filesystem/migrate.ts | Wires in migration 0005. |
| packages/cli/src/detect/scan.ts | Updates rule style discovery to only use the new .taskless/rules/sg root. |
| packages/cli/src/commands/verify.ts | Adds the new top-level verify and test commands operating on paths. |
| packages/cli/src/commands/rules.ts | Removes rule verify and updates delete errors for the new layout. |
| packages/cli/src/commands/check.ts | Switches check to assembled config generation and new sg rule discovery. |
| openspec/specs/cli-rule-validation/spec.md | Adds the new capability spec for path-addressed validation/testing. |
| openspec/specs/cli-agent-authoring/spec.md | Updates authoring requirements to per-rule config + verify/test usage. |
| openspec/changes/archive/2026-08-15-self-contained-rules/tasks.md | Archives task list for the self-contained rule layout change. |
| openspec/changes/archive/2026-08-15-self-contained-rules/specs/cli-vale-rule-engine/spec.md | Archived delta documenting Vale engine behavior under the new layout. |
| openspec/changes/archive/2026-08-15-self-contained-rules/specs/cli-rule-validation/spec.md | Archived delta documenting verify/test behavior and requirements. |
| openspec/changes/archive/2026-08-15-self-contained-rules/specs/cli-rule-format/spec.md | Archived delta documenting the new canonical rule layout and config assembly. |
| openspec/changes/archive/2026-08-15-self-contained-rules/specs/cli-agent-authoring/spec.md | Archived delta updating agent authoring requirements for per-rule layout. |
| openspec/changes/archive/2026-08-15-self-contained-rules/proposal.md | Archives proposal for the self-contained rules change. |
| openspec/changes/archive/2026-08-15-self-contained-rules/.openspec.yaml | Adds archive metadata for the self-contained rules change. |
| openspec/changes/archive/2026-08-15-agent-command-and-vale-authoring/resume.md | Notes the stacked PR relationship and measured constraints relied on by implementation. |
| example/README.md | Adds human-readable demo documentation for the new layout and commands. |
| example/example.html | Adds example prose file intended to trigger Vale rules. |
| example/example.cjs | Adds example JS file intended to trigger sg rules. |
| example/.taskless/taskless.json | Adds version-5 manifest for the demo project. |
| example/.taskless/rules/vale/no-simply/no-simply.yml | Adds example Vale rule style. |
| example/.taskless/rules/vale/no-simply/.vale.ini | Adds example per-rule Vale config + scope. |
| example/.taskless/rules/vale/no-simply/.tests/pass/direct.md | Adds example passing Vale fixture. |
| example/.taskless/rules/vale/no-simply/.tests/fail/hedged.md | Adds example failing Vale fixture. |
| example/.taskless/rules/sg/no-eval/no-eval.yml | Adds example sg rule. |
| example/.taskless/rules/sg/no-eval/.tests/no-eval-20260814-test.yml | Adds example sg test cases under .tests/. |
| example/.taskless/.gitignore | Ignores assembled config artifacts inside the demo project. |
| eslint.config.js | Excludes example/ from linting (demo includes intentionally “bad” content). |
| .prettierignore | Excludes example/ from formatting (fixtures and demo content are intentionally shaped). |
| .changeset/vale-rule-engine.md | Updates changeset to include new layout and verify/test command changes. |
Suppressed comments (1)
packages/cli/src/help/delete-rule.txt:26
- This removal list still describes deleting
.taskless/rules/<engine>/<id>/, but the currentrule deleteimplementation deletes only the ast-grep rule directory (.taskless/rules/sg/<id>/). Either the command needs an engine-aware argument or this doc should be narrowed to what is actually removed.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
@claude /review |
|
Claude finished @thecodedrift's task in 12m 42s —— View job Claude finished the reviewTodo list
Overall assessmentThis is a well-reasoned refactor — the design docs and the new test suite are unusually thorough about the failure modes they're guarding against (silent-disable, stale config, ambiguous ids). I found one high-severity correctness gap, one real performance bug, a vacuous test assertion, a doc/behavior mismatch, and a couple of smaller cleanup items. All are posted as inline comments; summary below. Most significant — Other findings (see inline comments for detail):
Branch: |
`pull_request: branches: [main]` matches the PR's base ref, and GitHub also resolves a stacked PR's eventual target and matches on that — so the filter did run on PRs based on another branch. Until it didn't. On the #71→#106 stack every PR up to #102 got a Validate run and #103/#106 got none, across 16 pull_request events that other workflows handled fine. #103 is a ~93-file change that has never been linted, typechecked, or tested in CI. Lint, typecheck, and tests have no interest in where a PR eventually merges, so the filter is dropped rather than repaired. `ready_for_review` is named explicitly because it is not in the default event set; without it a draft marked ready gets no fresh run until someone pushes again, which is the state #103 sat in. Committed directly to main: the fix restores CI coverage, and routing it through a PR would have it validated by the mechanism it repairs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
Three docs stated that GitHub's stacked-PR support makes `pull_request: branches: [main]` match every PR in a stack, and presented it as dependable. It is not. On the #71→#106 stack the filter matched through #102 and then silently stopped: #103 and #106 produced no `Validate` and no `Require a changeset` run across 16 pull_request events that filter-less workflows handled fine. That belief is why a ~93-file change reached "ready for review" having never been linted, typechecked, or tested in CI. The corrected rule is split by intent. A workflow that must run everywhere carries no `branches:` filter and names `ready_for_review` in `types:`, since it is absent from the default event set. A workflow that must act only on the PR merging to `main` establishes that inside the job, from the base ref or stack position. Also fixes a factual error: iterate-pr claimed `pr-check-openspec.yml` is scoped by `branches: [main]`. It has no `branches:` filter, which is the actual reason it runs on every PR. Adds the corollary worth internalizing: an absent check reads like a passing one, so a check you expected and cannot find is a reason to suspect the trigger, not to assume the PR is clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
Six approved review fixes from PR #103. `assembleValeConfig` returns undefined when no Vale rule declares a matcher, writing nothing and deleting nothing. Dispatch gated Vale on `hasValeRules`, which counts *directories*, so a project with a rule directory that assembles to nothing ran Vale against a stale config from a previous run — or one that never existed. `DispatchOptions` now carries `valeConfigPath`, `check` threads `assembled.vale` through, and `runValeEngine` returns no results when it is undefined, mirroring the ast-grep skip. Also: - Fix the vacuous "commits no assembled config" test: the pathspec was relative to `<repo>/example` and resolved to `example/example/.taskless`, so stdout was always empty. Assert on the exact assembled paths rather than basenames, since a per-rule `.vale.ini` is committed source. - Restore the deleted "rule directory present, nothing enabled" coverage at the dispatch level, spying on `runVale` so a skip is distinguishable from a run that found nothing. - Narrow the `delete-rule` recipe back to sg. `deleteRuleFiles` hardcodes `ruleDirectory(cwd, "sg", id)`; the doc claimed a generic `<engine>`. - Stop `taskless test` spawning `sg test` twice per rule. `verifyRule` takes a `runTests` option, and `verifyOneRule`/`testOneRule` share one call through `verifySgRule`. Same results, ordering, and errors. - Resolve a file sitting where a rule directory belongs as `RuleNotFoundError` instead of a rule id that fails two layers down. - Point the second `bootstrap` stat at `rules/vale` and `rules/runtime`; it duplicated `rules/sg`. - Record in migration 0005's docstring that 0004 ships with it, so no published install can hold a hand-written 0004-era `.vale.ini`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
A Vale rule is currently three locations, one of which every rule in the project shares. That shared .vale.ini is where all five harness runs found silent failures — an assignment above the first matcher, a glob that missed the fixture extension, three names that had to agree with nothing reporting when they didn't. A single write-contended config is the wrong shape at any scale. Each rule becomes a directory holding its style and its own .vale.ini; check assembles the run config from them and gitignores it. Measured against Vale 3.17.1: rules/<id>/<id>.yml resolves as check <id>.<id> under StylesPath = rules and resolves to nothing under StylesPath = ., Vale rejects unknown keys in a style so scope cannot ride along inside it, and a .yml sidecar in a style directory is loaded as a rule and fails E201 while a .vale.ini in the same place is ignored. Also replaces rule verify <id> with path-addressed verify and test. An id does not name one thing — the same id can exist under two engines, which is why the id form needed an ambiguity error at all. Adds an example/ project so a reader can see an install rather than infer it from tests that build their own fixtures. Stacked on #102 and merging down: a layout change without its migration ships a project whose rules silently stop running.
Widens the change from Vale to every engine, and renames it to match. One directory per rule, identical shape everywhere: `.taskless/rules/<engine>/<id>/` holding the rule, any config that engine requires, and its tests in `.tests/`. A rule becomes one path rather than two, which is what makes `verify <path>` and `test <path>` work without an id lookup. The dot on `.tests/` is load-bearing and measured. ast-grep's ruleDirs recurses and parses every .yml beneath as a rule, so a plain `tests/` directory fails the scan with "missing field 'language'"; `__tests__/` fails the same way; a dot-directory is skipped, and `sg test` still reads it when testDir names it. Vale is unaffected either way — a `.tests/` inside a style directory is harmless even containing a .yml. That is a dependency on undocumented behavior, recorded as one in D2 with two mitigations: the failure is loud (a parse error naming the file, not a silently reinterpreted test), and a test pins it. The rejected alternative — materializing a rules-only tree for ast-grep — is written down as the fallback if the assumption ever breaks. Also drops the per-rule sg config: ast-grep expresses scoping inside the rule, so the slot would be an empty file every author creates, no author fills, and every reader learns to ignore. And renames runtime's capture rules to `captures/`, since "matcher" now means a Vale glob section in this same tree. 0005 layers on 0004; both are unreleased and both ship in this stack, so consumers run them as one upgrade and never see the intermediate layout.
…ting Started the layout refactor and hit something the proposal missed: `.taskless/rules/` is the new root and is also LEGACY_RULES_DIRECTORY, the pre-0004 flat location. Same string, different meaning. The legacy read paths turn out to be removable rather than renameable, because they are unreachable: ensureTasklessDirectory runs migrations before anything reads a rule, so 0004 has already moved .taskless/rules/*.yml to sg/rules/ and 0005 moves it again. Under the new layout a legacy lookup would resolve .taskless/rules/<id>.yml inside a tree whose real contents are rules/<engine>/<id>/ — reading the new root as though it were the old flat directory. A stale read path that resolves into the live tree is worse than no fallback. Also adds the migration precondition that follows: 0005 asserts the new root holds no top-level *.yml before writing engine directories into it, since a file still there means 0004 did not complete. Reverting the partial engines.ts refactor so this PR stays spec-only and green rather than carrying a tree with twelve broken callers.
Groups 1-3 of self-contained-rules, plus the `rule verify` removal. ENGINE_LAYOUTS now describes a rule *directory* rather than parallel rules/ and rule-tests/ trees, and every path derives from it. Tests live in `.tests/` — the dot is load-bearing, since ast-grep's ruleDirs recurses and parses every .yml beneath as a rule, and the constant carries that measurement plus the fallback if it ever breaks. Both engine configs are now assembled per run and gitignored. Assembly is deterministic — rules sorted by id, each rule's matcher order verbatim — because Vale's precedence is positional and a config built in directory-iteration order would give a rule a different effective scope per machine. Migration 0005 moves everything and rewrites nothing: capture bytes determine reconciliation hashes. It asserts `.taskless/rules/` holds no loose .yml first, since that path is both the new root and the pre-0004 flat location. Vale matchers split by their `tskl) rule` breadcrumb; one without a breadcrumb is left in place and reported rather than guessed at or dropped, because it is a user's hand edit. Deleted with their layouts: the legacy read paths (unreachable — the migrations run before any read), filesystem/sgconfig.ts (assembly replaces it), rules/owner.ts and `rule verify` (an id does not name one rule; the path form has no ambiguity case). 0004's StylesPath docstring now explains both layouts. It said `StylesPath = rules` is wrong, which was true flat and is exactly backwards here — a bare contradiction invites a future reader to revert it. Typecheck and build clean. Tests still assert the old layout; they are next.
Caught by migrating a real 0004 project and running check: ast-grep kept reporting, Vale went silent. A Vale check is named <style>.<rule>, and the style is whatever StylesPath points at. Flat, that was `rules`, so assignments read `rules.<id> = YES`. Per-rule directories make each rule its own style, so the same rule is `<id>.<id>`. The migration moved the assignment across verbatim, producing a config Vale parses happily, reports nothing for, and exits zero on — every migrated rule silently disabled, which is precisely the failure this layout exists to prevent. 0005 now rewrites the assignment as it splits, and the mapper collapses `<id>.<id>` to `<id>` so findings carry the id the user filed under. It only collapses when both halves match: a `<style>.<check>` where they differ came from a user's own Vale styles, and halving that name would report under an id identifying nothing. Verified end to end — a 0004 project migrates and both engines fire.
Fixture project, engine dispatch, and the Vale suites now build rules as directories. Adds assemble.test.ts covering what task 2.5 asks for: the StylesPath header, sorted rule order, byte-identical output across runs, each rule's own matcher order preserved, and provenance tagging. Also makes 0005 scaffold rules/<engine>/ — it prunes 0004's directories, so without this a freshly migrated project had no rules tree at all, every engine reporting absent and nowhere obvious to write a first rule. Deletes sg-committed-config.test.ts (the committed config it covers is now assembled) and rule-verify-dispatch.test.ts (rule verify is gone; its replacement lands with the path-addressed commands). 55 failures left, all layout paths in the remaining suites.
Also fixes buildIsolatingConfig, which still enabled `rules.<id>` under a StylesPath that no longer produces that name — the same silent-disable the migration hit, one file over. Verification would have reported every rule as not firing. migrate-engine-layout now asserts the end state of 0004+0005 rather than 0004's intermediate layout: both are unreleased and ship together, so a user upgrades through the pair and never sees the middle. 90 failures down to 30.
Retires the two tests describing behavior that no longer exists — a rule at the pre-0004 flat path, and merging two layouts with de-duplication. There is one tree now, so there is no overlap to collapse. Drops the `rule verify --anonymous` case with the command it covered. 30 failures down to 21.
566 passing, typecheck and lint clean. Adds engine-layout.test.ts, which is what design D2 promised: it asserts a scan stays clean with test YAML inside a rule's .tests/, and that the same file in a plain tests/ fails. The dot-directory behavior is undocumented and the binary is version-pinned, so this test is what fires at a deliberate bump — turning the discovery into a migration task with a changelog rather than a mystery in CI. Two reconcile/ingest tests needed rethinking rather than repathing. The signature test discovered the pre-migration tree to sign it, which no longer works now that discovery reads one layout; it describes the old rule directly instead, since the property under test is that the signature survives the move. Retires the assertions that only made sense with two layouts.
Group 4. `verify <path>` checks a rule has the components its engine requires; `test <path>` runs its tests and runs verify first. The split is about preconditions: an agent mid-authoring has a rule and no fixtures yet, and needs to know the rule is valid before it can write a meaningful test. So verify deliberately does not require tests. Running verify first is the ordering fix. When a rule is both malformed and under-fixtured, the fixture complaint is the less useful error and is the one that surfaced first before — the author was told their fixtures were incomplete while the reason the rule could never have run went unmentioned. A test pins that. A path names one thing, so there is no ambiguity case to report: the same id under two engines is just two paths. The engine comes from the path's <engine> segment, never from the file, which is what dispatch already does — so a rule cannot be validated by one engine and run by another. A directory means everything beneath it, which is the CI form. Verify also catches the two Vale silent-disables by name: a rule with no config of its own is scoped to nothing, and a config that never enables <id>.<id> leaves the rule present but off. 577 tests pass; typecheck and lint clean.
Group 6, and the lint fixes for group 4 that I pushed past. The tests cover behavior thoroughly but build their fixtures inside the test that reads them, so nothing in the repo showed the layout as a reader would meet it. example/ is that: two rules, one per engine, in a project small enough to take in at once. Its README explains the two things that are not self-evident — why .tests/ is dot-prefixed (ast-grep reads every .yml under the rules tree as a rule) and why only Vale has a per-rule config (it rejects unknown keys, so scope cannot live in the style file). example-project.test.ts is the other half. It runs check, verify, and test against a copy and asserts on the results, including the exact finding shape the README quotes, so a layout change that breaks the demo fails the build rather than leaving something misleading in the repo. It also asserts neither assembled config is committed — an example that checked in generated files would teach that. example/ joins the root eslint and prettier ignores: its source calls eval on purpose and its fixtures are prose written to be flagged. 582 tests pass; typecheck and lint clean.
No em dashes, no antithesis, contractions throughout, shorter sentences. Extended past the README to the rule messages and the .vale.ini comment, because those are the example's most-read prose and would have taught the habit. `Avoid eval — it executes...` became `Avoid eval. It executes...`, and the no-simply message dropped its "not what to do" tail. The README's quoted check output was regenerated from a real run so it still matches byte for byte. 582 tests pass.
Every recipe that named a path still described the flat layout. This repoints them at `.taskless/rules/<engine>/<id>/` and replaces the id-addressed `rule verify` with the path-addressed `verify` and `test`. `create-vale-rule` changes most: the shared `.vale.ini` walkthrough becomes a per-rule config with its `tskl)` breadcrumb, and the `W101` outside-a-matcher warning is gone with the situation that caused it. The old text also warned at length that verification could not catch a missing assignment. It can now, so that becomes the `<id>.<id>` naming rule and a pointer at the command. Two findings from running the recipes rather than reading them: A `consistency` rule compiles its own name into its pattern as a Go RE2 capture group, and RE2 rejects a hyphen there. Measured against Vale 3.17.1, `ize-ise` fails with E201 and takes every Vale rule in the project down with it, since Vale reads one config per run: 9 rules, 0 findings. Our own recipes teach kebab-case, so we were teaching the break. `verify` now rejects it, two tests pin it, and design D10 records it. A hyphen is a word boundary, so `obviously` fires inside `obviously-named`. The recipe stated the boundary rule but not that case, and a harness agent used a hyphenated compound as a `pass/` near-miss that then fired. Verified by extracting all nine worked rules from the *rendered* recipe and executing them, and by re-running the authoring harness with fresh agents that had no repository access. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
The existing migration tests assert where files land and that their bytes survive. Both can be perfect while the migrated project reports nothing, which is how the Vale silent-disable shipped: 0004 enables a check named `rules.<id>`, 0005's StylesPath resolves the same rule as `<id>.<id>`, and carrying the old assignment forward leaves every Vale rule present, valid, enabled against a check that does not exist, and quiet. It was caught by hand, by noticing ast-grep still reported while Vale had gone silent. So this seeds a version-4 project and runs the real CLI over it after migrating: both static engines still report, the assignment is retargeted, every rule still verifies, the tests that moved still run, runtime capture bytes are unchanged, and a second run is a no-op. The ast-grep half is the control, so a silent Vale shows up as a difference between engines rather than a plausibly-empty run. The changeset also described a layout this stack has since replaced, and promised an `engine-selection` topic that #102 merged into `route`. Rewritten for what actually ships. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
7.1-7.6 verified. 7.7 is blocked on #102: a change archives once on the tip, and the gate wants openspec/changes/ empty, but agent-command-and-vale-authoring still has 14 open tasks. Archiving it early would drop the spec deltas for work nobody has done. #102's delta also has to reach specs/ before this change's delta has a target. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
The stack's second and final archive, which is why #102 had to go first: this change's `cli-agent-authoring` delta modifies a requirement that one introduces, so it needed a target in specs/. The archive refused twice, both times on a rename expressed as a MODIFIED. Five of the six MODIFIED entries across cli-rule-format and cli-vale-rule-engine renamed their requirement, which openspec matches by header, so each became a REMOVE of the old name plus an ADD of the new. cli-rule-format's MODIFIED section emptied out entirely. Two requirements the deltas never retired, both now describing code this change deletes: - "Both the legacy and engine-partitioned layouts are readable" promises a legacy read path that task 1.5 removes. The legacy constant now names the same string as the rules root, so a stale read path would resolve into the live tree (design D9). - "The scaffolded Vale config carries no section" describes a file that no longer exists. Verified against a fresh `init`: the scaffold contains no `.ini` at all, because scope is declared per rule. `cli-rules` and `cli-update-engine` still fail --strict; both fail on main and neither is touched by this stack. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
Six approved review fixes from PR #103. `assembleValeConfig` returns undefined when no Vale rule declares a matcher, writing nothing and deleting nothing. Dispatch gated Vale on `hasValeRules`, which counts *directories*, so a project with a rule directory that assembles to nothing ran Vale against a stale config from a previous run — or one that never existed. `DispatchOptions` now carries `valeConfigPath`, `check` threads `assembled.vale` through, and `runValeEngine` returns no results when it is undefined, mirroring the ast-grep skip. Also: - Fix the vacuous "commits no assembled config" test: the pathspec was relative to `<repo>/example` and resolved to `example/example/.taskless`, so stdout was always empty. Assert on the exact assembled paths rather than basenames, since a per-rule `.vale.ini` is committed source. - Restore the deleted "rule directory present, nothing enabled" coverage at the dispatch level, spying on `runVale` so a skip is distinguishable from a run that found nothing. - Narrow the `delete-rule` recipe back to sg. `deleteRuleFiles` hardcodes `ruleDirectory(cwd, "sg", id)`; the doc claimed a generic `<engine>`. - Stop `taskless test` spawning `sg test` twice per rule. `verifyRule` takes a `runTests` option, and `verifyOneRule`/`testOneRule` share one call through `verifySgRule`. Same results, ordering, and errors. - Resolve a file sitting where a rule directory belongs as `RuleNotFoundError` instead of a rule id that fails two layers down. - Point the second `bootstrap` stat at `rules/vale` and `rules/runtime`; it duplicated `rules/sg`. - Record in migration 0005's docstring that 0004 ships with it, so no published install can hold a hand-written 0004-era `.vale.ini`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
Two specs failed. Fixing them surfaced a third problem that was not failing, which is the worse one. `cli-update-engine` is deleted. It was a tombstone: the capability was decommissioned, every requirement removed, and the file kept "for historical reference". specs/ describes what is true now, and the history is already in the 2026-03-30-remove-scaffold-dependency archive, including that change's own cli-update-engine delta. Nothing outside the archives referenced it. `cli-rules` gets scenarios and SHALL keywords on 15 requirements, and loses the five that specify `taskless rule verify` — a command this stack removed and replaced with the path-addressed `verify` and `test`, now owned by cli-rule-validation. A requirement stating the subcommand is gone replaces them. Two requirements also named pre-layout paths (`.taskless/rule-tests/<id>.yml`, and deleting "rule and test files" rather than the rule directory); both repathed while being touched. The third problem: a second `##` inside a requirements section ends it, so every requirement below stops being read. `cli-rules` hid 10 behind `## API Contract`, `infrastructure` hid 19, and `skills` hid 6. Those last two PASSED --strict throughout, because the single requirement each still exposed was well-formed. 35 requirements were unread while the validator reported success. The groupings are preserved as bold lead-in lines instead, and un-nesting infrastructure immediately exposed a real requirement with no SHALL, now fixed. `skills` also still told agents to fetch recipes via `npx @taskless/cli help <topic>`. 23 specs, 0 failures. Refs #105 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
Two self-contradictions the strict-validation pass left behind. The create requirements still wrote rules to the flat `.taskless/rules/<id>.yml` and tests to `.taskless/rule-tests/<id>.yml`, while delete had already been repathed to the rule directory. `files.ts` agrees with delete, so create was the stale one. The new "`taskless rule verify` SHALL NOT exist" requirement was contradicted three lines up, where the surface list still advertised it, and again where two scenarios named it as a live command. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
Work that previously lived only inside a merge commit, reapplied as an ordinary commit so the branch is linear. A merge can hold content present in neither parent, and this one did. Replaying the branch reproduces every commit but not the merge's own resolutions, so these changes would otherwise be silently dropped: - `RuleTestResult` carries Vale's config `notice` and `verify`/`test` print it, on a pass as well as a failure. Without this the schema field survives with nothing reading it, and a rule Vale never enabled still verifies clean. - The `--json` engine-failure fixture and the notice fixture both used pre-layout paths, so neither provoked what it claimed. Corrected, plus a `taskless.json` in the fixture: without it the tree reads as schema version 0 and the migrations relocate a current-layout project, after which `check` scans nothing and reports success (issue #109). - `example/README.md` re-synced with real `check` output. Verified by tree equality against the merge-based head this replaces: `git diff` reports no difference. 602 tests, lint, and typecheck pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
456dd01 to
6e7d8cd
Compare
449a9c5 to
9cdf77e
Compare
dc57dbe
into
openspec/agent-command-and-vale-authoring
Six approved review fixes from PR #103. `assembleValeConfig` returns undefined when no Vale rule declares a matcher, writing nothing and deleting nothing. Dispatch gated Vale on `hasValeRules`, which counts *directories*, so a project with a rule directory that assembles to nothing ran Vale against a stale config from a previous run — or one that never existed. `DispatchOptions` now carries `valeConfigPath`, `check` threads `assembled.vale` through, and `runValeEngine` returns no results when it is undefined, mirroring the ast-grep skip. Also: - Fix the vacuous "commits no assembled config" test: the pathspec was relative to `<repo>/example` and resolved to `example/example/.taskless`, so stdout was always empty. Assert on the exact assembled paths rather than basenames, since a per-rule `.vale.ini` is committed source. - Restore the deleted "rule directory present, nothing enabled" coverage at the dispatch level, spying on `runVale` so a skip is distinguishable from a run that found nothing. - Narrow the `delete-rule` recipe back to sg. `deleteRuleFiles` hardcodes `ruleDirectory(cwd, "sg", id)`; the doc claimed a generic `<engine>`. - Stop `taskless test` spawning `sg test` twice per rule. `verifyRule` takes a `runTests` option, and `verifyOneRule`/`testOneRule` share one call through `verifySgRule`. Same results, ordering, and errors. - Resolve a file sitting where a rule directory belongs as `RuleNotFoundError` instead of a rule id that fails two layers down. - Point the second `bootstrap` stat at `rules/vale` and `rules/runtime`; it duplicated `rules/sg`. - Record in migration 0005's docstring that 0004 ships with it, so no published install can hold a hand-written 0004-era `.vale.ini`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
Six approved review fixes from PR #103. `assembleValeConfig` returns undefined when no Vale rule declares a matcher, writing nothing and deleting nothing. Dispatch gated Vale on `hasValeRules`, which counts *directories*, so a project with a rule directory that assembles to nothing ran Vale against a stale config from a previous run — or one that never existed. `DispatchOptions` now carries `valeConfigPath`, `check` threads `assembled.vale` through, and `runValeEngine` returns no results when it is undefined, mirroring the ast-grep skip. Also: - Fix the vacuous "commits no assembled config" test: the pathspec was relative to `<repo>/example` and resolved to `example/example/.taskless`, so stdout was always empty. Assert on the exact assembled paths rather than basenames, since a per-rule `.vale.ini` is committed source. - Restore the deleted "rule directory present, nothing enabled" coverage at the dispatch level, spying on `runVale` so a skip is distinguishable from a run that found nothing. - Narrow the `delete-rule` recipe back to sg. `deleteRuleFiles` hardcodes `ruleDirectory(cwd, "sg", id)`; the doc claimed a generic `<engine>`. - Stop `taskless test` spawning `sg test` twice per rule. `verifyRule` takes a `runTests` option, and `verifyOneRule`/`testOneRule` share one call through `verifySgRule`. Same results, ordering, and errors. - Resolve a file sitting where a rule directory belongs as `RuleNotFoundError` instead of a rule id that fails two layers down. - Point the second `bootstrap` stat at `rules/vale` and `rules/runtime`; it duplicated `rules/sg`. - Record in migration 0005's docstring that 0004 ships with it, so no published install can hold a hand-written 0004-era `.vale.ini`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
Stack (root → tip):
Why
A rule is spread across locations today, and for Vale one of them is shared by every rule in the project. Five sandboxed harness runs against
create-vale-rule(on #102) found silent failures in that shared.vale.iniand nowhere else — an assignment above the first matcher, a glob that missed the fixture's extension, three names that had to agree with nothing reporting when they didn't.The same reasoning generalizes past Vale:
sgandruntimerules are also split between arules/tree and a parallelrule-tests/tree, so no engine has a single path meaning "this rule". Fixing Vale alone would leave three layouts instead of one.What changes
One directory per rule, identical across engines:
checkassembles the Vale and ast-grep configs from the per-rule tree and gitignores them.rule verify <id>is replaced by path-addressedverify <path>(required components) andtest <path>(tests), withverifyrunning as a prerequisite layer oftest.Adds
example/— a small real project so a reader can see an install rather than infer it from tests that build their own fixtures, with achecktest so it can't drift.The dot on
.tests/is load-bearing, and measuredtests/inside the rule dirmissing field 'language'__tests__/.tests/.ymltestDir: …/.testsworks; snapshots land insideruleDirsrecurses and parses every.ymlbeneath as a rule, so a plaintests/directory hard-fails the scan.This is a dependency on undocumented behavior and D2 records it as one, with two mitigations: the failure is loud — a parse error naming the file, not a test silently reinterpreted as a rule — and a test pins it. The rejected alternative (materialize a rules-only tree for ast-grep, keeping a plain
tests/) is written down as the fallback if the assumption breaks.Other measured constraints
<id>/<id>.ymlresolves as check<id>.<id>only under aStylesPathnaming its parent; underStylesPath = .it resolves to nothing. This reverses the note in migration0004— correct for the flat layout, backwards for this one — so the task list rewrites that docstring rather than deleting it.E201), so scope cannot ride inside the style file. ast-grep can express scoping in the rule, which is why it gets no per-rule config — an empty file per rule is symmetry as decoration.Delivery shape
Stacked, merging down on #102.
0005layers on0004; both are unreleased and both ship in this stack, so consumers run them as one upgrade and never observe the intermediate layout.openspec validate --all --strictwill flag thecli-agent-authoringdelta until #102 archives — that capability is introduced there.Spec-only. Implementation follows on approval.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
Contains #106
Cleanup on top of the stack so
pnpm openspec validate --all --strictis green and the gate in #105 can be turned on without landing red.Two failures, and a third problem that wasn't failing
cli-update-engine— deleted. A tombstone: capability decommissioned, every requirement removed, file kept "for historical reference".--strictneeds at least one requirement.specs/describes what's true now, and the history is already in the2026-03-30-remove-scaffold-dependencyarchive, including that change's owncli-update-enginedelta. Nothing outside the archives referenced it.cli-rules— 18 errors. Scenarios and SHALL keywords added to 15 requirements. The five specifyingtaskless rule verifyare removed: this stack deleted that command in favour of the path-addressedverifyandtest, now owned bycli-rule-validation. A requirement stating the subcommand is gone replaces them. Two requirements named pre-layout paths (.taskless/rule-tests/<id>.yml, and deleting "rule and test files" rather than the rule directory); both repathed while being touched.The one worth reading. A second
##inside a requirements section ends it, so every requirement below stops being parsed:--strictbeforecli-rulesinfrastructureskillsinfrastructureandskillspassed throughout, because the single requirement each still exposed was well-formed. 35 requirements were unread while the validator reported success. This is the same shape as thecli-helpdefect repaired earlier in the stack, where a lost code fence turned a documentation template into real headings.The topical groupings are kept as bold lead-in lines instead of headings. Un-nesting
infrastructureimmediately exposed a real requirement with no SHALL, now fixed.skillsalso still told agents to fetch recipes vianpx @taskless/cli help <topic>.Result
23 specs, 0 failures, with every requirement actually visible to the parser. 594 tests, lint and typecheck unchanged: this PR touches only
openspec/specs/.Note that
--strictalone would not have caught the hidden-requirement class. Detecting it needs a separate check that every### Requirement:sits under## Requirements— noted on #105 for whoever wires the gate.Refs #105
🤖 Generated with Claude Code
https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3