ci: enforce the house-style rules instead of documenting them

The rules in `.taskless/` have been in the tree for nine commits with
nothing running them. `validate.yml` had no Taskless step at all, so
every finding they can produce depended on a person remembering to run
`pnpm cli check` locally. #104 asks for enforcement, and a rule nothing
runs is documentation.

A step inside the existing `Validate` job rather than the standalone
`.github/workflows/taskless.yml` the `taskless agent ci` recipe writes.
The recipe is right for a consumer being onboarded, where touching a
pipeline you do not own is the larger risk; here the two things the
check needs only exist inside this job. Branch protection requires
`Validate` and nothing else, so a separate workflow would run, report,
and block nothing. And the job has already built `dist/` from this exact
commit by the time the step runs, so the check costs one process rather
than a second checkout, install, and build.

It runs `pnpm cli check`, the workspace build, not `npx @taskless/cli`.
This repository IS the CLI: checking our own documents with a published
release would exempt the engine at HEAD from its own rules and defer a
rule-evaluation regression to whenever the next version ships. The step
comment says this is a deliberate divergence from the recipe so a future
reader does not correct it back.

It blocks. `check` exits non-zero on an error-severity finding and on an
engine that failed or timed out, so an em dash added to a README,
CLAUDE.md, or `.conventions/*.md` turns the build red. That is the
intended cost. Warning-severity rules still only report, which is what
`severity: warning` means.

Verified non-vacuous rather than assumed. Appending an em dash to
CLAUDE.md and to README.md each exits 1; a missing `dist/` exits 1
rather than passing empty; a `branches:` filter added under
`pull_request:` exits 1, which is the ast-grep engine reporting on this
very file. Clean tree exits 0. Both engines are therefore live, not
silently skipped.

Full scan, not the recipe's diff scan, for the reason the `Validate
specs` step gives: rot accumulates in the files a PR does not touch, and
the scoped corpus is small enough that a diff scan buys nothing.

No secrets. Static rules run unauthenticated; `.taskless/rules/runtime/`
is empty, so there is nothing a `TASKLESS_TOKEN` would unlock yet.

Fixes #104

Author: theCodeDrift

.github/workflows/validate.yml

@@ -65,6 +65,51 @@ jobs:
       - name: Test workflow scripts
         run: node --test .github/scripts/*.test.cjs
 
+      # House style, enforced rather than documented. The rules live in
+      # `.taskless/` and are scoped to the documents people and agents actually
+      # read: every README, CLAUDE.md, `.conventions/*.md`, this directory's
+      # workflows, and comments under `packages/cli/src/`.
+      #
+      # A step here, not a standalone `taskless.yml`. The canonical recipe
+      # (`taskless agent ci`) writes a separate workflow so that onboarding
+      # never touches a pipeline it does not own, but the two things this repo
+      # needs are only available inside this job. Branch protection requires
+      # `Validate` and nothing else, so a separate workflow would report and
+      # block nothing, which is the whole of what #104 asked for; and `check`
+      # runs this repo's own build, which the `Build` step above has already
+      # produced. Full scan rather than the recipe's diff scan, for the reason
+      # `Validate specs` gives below: rot accumulates in the files a PR does
+      # not touch, and the scoped corpus is small enough that a diff scan buys
+      # nothing.
+      #
+      # Placed after the test steps rather than immediately after `Build`, so
+      # that the existing signal order (lint, types, build, tests) stays intact
+      # for anyone used to reading these logs. It only needs to be after
+      # `Build`; nothing above it depends on it.
+      #
+      # `pnpm cli` is the workspace build (`packages/cli/dist/index.js`), NOT a
+      # published release, and that is a deliberate divergence from `ci.txt`.
+      # The recipe is written for consumers installing the published CLI; here
+      # the repository IS the CLI, so running `npx @taskless/cli check` would
+      # test the published artifact and exempt the engine at HEAD from its own
+      # rules. Do NOT "fix" this back to `npx`: a commit that breaks rule
+      # evaluation has to fail on the commit that breaks it, not one release
+      # later. `Build` above ran `pnpm build` on this same commit, so `dist/`
+      # here can be neither stale nor missing, and an absent `dist/` would fail
+      # this step loudly rather than pass it empty.
+      #
+      # This blocks. `check` exits non-zero on any error-severity finding and
+      # on an engine that failed or timed out, so an em dash added to a covered
+      # document turns the build red. Warning-severity rules report without
+      # failing, which is what `severity: warning` in a rule means.
+      #
+      # No authentication and no secrets: static rules (Vale and ast-grep) run
+      # unauthenticated. Runtime rules under `.taskless/rules/runtime/` are
+      # skipped without a token; that directory is empty today, and wiring
+      # `TASKLESS_TOKEN` is the separate decision to make when it is not.
+      - name: Check house style
+        run: pnpm cli check
+
       # Repo-wide, not changed-files-only: spec rot accumulates in the specs a
       # PR does not touch, so a scoped check would never surface it.
       - name: Validate specs