Skip to content

feat: one directory per rule, and path-addressed verify/test - #103

Merged
thecodedrift merged 21 commits into
openspec/agent-command-and-vale-authoringfrom
openspec/self-contained-vale-rules
Aug 19, 2026
Merged

feat: one directory per rule, and path-addressed verify/test#103
thecodedrift merged 21 commits into
openspec/agent-command-and-vale-authoringfrom
openspec/self-contained-vale-rules

Conversation

@thecodedrift

@thecodedrift thecodedrift commented Aug 14, 2026

Copy link
Copy Markdown
Member

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.ini and 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: sg and runtime rules are also split between a rules/ tree and a parallel rule-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:

.taskless/rules/sg/no-eval/
    no-eval.yml
    .tests/no-eval-20260101-test.yml

.taskless/rules/vale/no-simply/
    no-simply.yml
    .vale.ini            # this rule's matchers, excludes, tskl) metadata
    .tests/pass/ok.md
    .tests/fail/bad.md

.taskless/rules/runtime/unused-exports/
    check.ts
    captures/exported-symbol.yml
    .tests/…

check assembles the Vale and ast-grep configs from the per-rule tree and gitignores them. rule verify <id> is replaced by path-addressed verify <path> (required components) and test <path> (tests), with verify running as a prerequisite layer of test.

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 a check test so it can't drift.

The dot on .tests/ is load-bearing, and measured

Probe ast-grep 0.41.0 Vale 3.17.1
tests/ inside the rule dir failsmissing field 'language' fine
__tests__/ fails fine
.tests/ skipped by rule discovery fine, even containing a .yml
test runner reads it testDir: …/.tests works; snapshots land inside buckets lint when targeted

ruleDirs recurses and parses every .yml beneath as a rule, so a plain tests/ 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>.yml resolves as check <id>.<id> only under a StylesPath naming its parent; under StylesPath = . it resolves to nothing. This reverses the note in migration 0004 — correct for the flat layout, backwards for this one — so the task list rewrites that docstring rather than deleting it.
  • Vale rejects unknown keys in a style (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. 0005 layers on 0004; 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 --strict will flag the cli-agent-authoring delta 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 --strict is 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". --strict needs at least one requirement. specs/ describes what's 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 — 18 errors. Scenarios and SHALL keywords added to 15 requirements. The five specifying taskless rule verify are removed: this stack deleted that command in favour of the path-addressed verify and test, now owned by cli-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:

Spec In file Visible before --strict before
cli-rules 33 23 failing
infrastructure 20 1 passing
skills 7 1 passing

infrastructure and skills passed 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 the cli-help defect 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 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>.

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 --strict alone 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

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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, and runtime, including .tests/ and per-rule .vale.ini.
  • Add path-addressed verify and test commands (with shared path resolution) and remove id-addressed rule 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 current rule delete implementation 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.

Comment thread packages/cli/test/example-project.test.ts Outdated
Comment thread packages/cli/src/help/delete-rule.txt
@thecodedrift

Copy link
Copy Markdown
Member Author

@claude /review

@claude

claude Bot commented Aug 15, 2026

Copy link
Copy Markdown

Claude finished @thecodedrift's task in 12m 42s —— View job


Claude finished the review

Todo list

  • Gather context and diff (origin/openspec/agent-command-and-vale-authoring...HEAD)
  • Angle A: line-by-line diff scan
  • Angle B: removed-behavior audit
  • Angle C: cross-file tracer
  • Reuse / Simplification / Efficiency / Altitude / Conventions angles
  • Verify candidates
  • Post inline comments + final summary

Overall assessment

This 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 — assemble.ts:122 / dispatch.ts's runValeEngine: check never verifies that assembleValeConfig produced a fresh .taskless/.vale.ini for the current run before invoking Vale — unlike the ast-grep path, which explicitly skips when assembleSgConfig returns undefined. A Vale rule directory that exists without yet (or no longer) contributing a valid .vale.ini — the exact "mid-authoring" state the now-deleted mixed-engine-check.test.ts test used to guarantee check handles quietly — will either make Vale error on a missing config file or silently reuse a stale one from an earlier run. I couldn't run the real Vale binary in this sandbox to pin down which of the two happens, but the code path and the deleted-without-replacement test both point at a real gap.

Other findings (see inline comments for detail):

  • rules/inspect.tstest <path> spawns sg test twice per ast-grep rule (verifyOneRule and testOneRule each call verifyRule, which always runs the test layer).
  • test/example-project.test.ts — the "commits no assembled config" test's git ls-files pathspec is wrong (cwd is already example/), so it always returns empty and the assertion passes vacuously.
  • help/delete-rule.txt — now documents rule delete as engine-generic, but deleteRuleFiles still only ever deletes the sg rule directory (pre-existing limitation, but the doc update overclaims what changed).
  • filesystem/migrations/0005-rule-directories.ts — the Vale-config-splitting migration depends on a tskl) breadcrumb that no pre-this-PR code or docs ever wrote; likely moot given the PR's claim that 0004+0005 always ship together, but worth confirming that's airtight.
  • rules/resolve-path.ts — a dead branch where both arms of an if return the same value.
  • commands/verify.tsverify/test process rules strictly sequentially despite each being an independent subprocess call; could run concurrently.

Branch: openspec/self-contained-vale-rules

Comment thread packages/cli/src/rules/dispatch.ts
Comment thread packages/cli/src/rules/inspect.ts Outdated
Comment thread packages/cli/src/rules/files.ts
Comment thread packages/cli/test/example-project.test.ts Outdated
Comment thread packages/cli/test/bootstrap.test.ts Outdated
Comment thread packages/cli/src/rules/assemble.ts
Comment thread packages/cli/src/rules/inspect.ts Outdated
Comment thread packages/cli/test/example-project.test.ts Outdated
Comment thread packages/cli/src/help/delete-rule.txt
Comment thread packages/cli/src/filesystem/migrations/0005-rule-directories.ts
Comment thread packages/cli/src/rules/resolve-path.ts Outdated
Comment thread packages/cli/src/commands/verify.ts Outdated
thecodedrift added a commit that referenced this pull request Aug 17, 2026
`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
thecodedrift added a commit that referenced this pull request Aug 17, 2026
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
thecodedrift added a commit that referenced this pull request Aug 17, 2026
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
thecodedrift and others added 21 commits August 18, 2026 17:42
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
@thecodedrift
thecodedrift force-pushed the openspec/agent-command-and-vale-authoring branch from 456dd01 to 6e7d8cd Compare August 19, 2026 01:40
@thecodedrift
thecodedrift force-pushed the openspec/self-contained-vale-rules branch from 449a9c5 to 9cdf77e Compare August 19, 2026 01:40
@thecodedrift
thecodedrift merged commit dc57dbe into openspec/agent-command-and-vale-authoring Aug 19, 2026
3 checks passed
thecodedrift added a commit that referenced this pull request Aug 19, 2026
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
@thecodedrift
thecodedrift deleted the openspec/self-contained-vale-rules branch August 19, 2026 02:21
thecodedrift added a commit that referenced this pull request Aug 19, 2026
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants