fix(taskless): close two holes the rules could not see through

From review of #187. Both findings verified before acting, and both real.

`ci-uses-workspace-cli` matched `npx @taskless/cli` and nothing else, so the
invocation CLAUDE.md names by name, `pnpm dlx @taskless/cli@latest`, went
straight through the rule written to forbid it. `yarn dlx` and a global install
did too. A rule that permits the exact string its own repository documents as
the thing to avoid is worse than no rule, because it reads as coverage.

Widening it to the bare package name overcorrected, and the dogfooding caught
that within one run: it fired on `pnpm --filter @taskless/cli build:nightly` in
`release-cli-nightly.yml`, which is the WORKSPACE package addressed as a
filter. `pnpm exec @taskless/cli` is the same story, running the local binary.

What separates a published build is being FETCHED, so the rule matches the
fetch verbs: `npx`, `dlx`, and `-g`. Fixtures now carry `pnpm dlx`, `yarn dlx`
and the two-step global install on the invalid side, and `pnpm exec` and
`--filter` on the valid side, so neither the hole nor the overcorrection can
come back. Measured: `pnpm dlx` and `npx` both exit 1, the clean tree exits 0.

`pr-workflow-ready-for-review` anchored on a `types:` node, so it only fired on
an explicit list that omitted `ready_for_review`. A `pull_request:` with no
`types:` at all falls through to GitHub's default set, which omits
`ready_for_review` just as surely — and the rule said nothing, because there
was no node to anchor to. That is the #103 gap the rule exists to prevent,
reachable by writing less rather than more.

It now also matches a `pull_request:` with no `types:` descendant. Nothing on
`main` hits it today (all three triggers declare `types:`), so this was latent;
a probe workflow with a bare `pull_request:` is now reported where it
previously was not. Severity stays `warning`, unchanged.

Author: thecodedrift

.taskless/rules/sg/ci-uses-workspace-cli/.tests/ci-uses-workspace-cli-20260826-test.yml

@@ -18,6 +18,14 @@ valid:
         run: |
           pnpm build
           pnpm cli check
+  - |
+    steps:
+      - name: pnpm exec runs the LOCAL binary, not a published build
+        run: pnpm exec @taskless/cli check
+  - |
+    steps:
+      - name: --filter addresses the workspace package, not a published one
+        run: pnpm --filter @taskless/cli build:nightly
 invalid:
   - |
     steps:
@@ -33,3 +41,17 @@ invalid:
         run: |
           pnpm install
           npx @taskless/cli check
+  - |
+    steps:
+      - name: The invocation CLAUDE.md names by name
+        run: pnpm dlx @taskless/cli@latest check
+  - |
+    steps:
+      - name: Another runner, same published build
+        run: yarn dlx @taskless/cli check
+  - |
+    steps:
+      - name: Global install names the package too
+        run: |
+          npm i -g @taskless/cli
+          taskless check

.taskless/rules/sg/ci-uses-workspace-cli/ci-uses-workspace-cli.yml

@@ -17,9 +17,26 @@ note: |
   rather than written down: the comment it replaces asked a reader not to
   "fix" the invocation back, which is a request, not a boundary.
 
+  Matched on the FETCH VERBS, not on `npx` alone and not on the package
+  name alone. `npx` is one of several ways to reach a published build:
+  `pnpm dlx @taskless/cli@latest` is the invocation CLAUDE.md names by
+  name, `yarn dlx` is the same thing, and `npm i -g` reaches it in two
+  steps whose install line still names the package. Anchoring to `npx`
+  let every one of those through, including the exact string this
+  repository documents as the thing `pnpm cli` replaces.
+
+  Anchoring to the bare package name is too wide in the other direction,
+  and measurably so: it fires on `pnpm --filter @taskless/cli
+  build:nightly` in `release-cli-nightly.yml`, which is the WORKSPACE
+  package addressed as a filter, not a published install. `pnpm exec
+  @taskless/cli` is out for the same reason — it runs the local binary.
+  What distinguishes a published build is being FETCHED, so the verbs are
+  what the rule matches.
+
   `@taskless/cli-nightly` is deliberately not matched. The nightly IS a
   published artifact by design, and the release workflows reference it on
-  purpose.
+  purpose. The pattern ends before a `-` so the nightly's name cannot
+  match.
 
   Only a `run:` value matches, never a comment: `npx @taskless/cli` appears
   in prose in `validate.yml` and `release-cli-nightly.yml`, explaining this
@@ -43,6 +60,6 @@ rule:
           # block_scalar under `|` or `>`. Both spellings are ordinary in
           # these workflows, so both have to match.
           - kind: flow_node
-            regex: 'npx\s+@taskless/cli($|[@\s])'
+            regex: '(npx|dlx|-g)\s+@taskless/cli($|[@\s])'
           - kind: block_scalar
-            regex: 'npx\s+@taskless/cli($|[@\s])'
+            regex: '(npx|dlx|-g)\s+@taskless/cli($|[@\s])'

.taskless/rules/sg/pr-workflow-ready-for-review/.tests/pr-workflow-ready-for-review-20260824-test.yml

@@ -25,3 +25,6 @@ invalid:
     on:
       pull_request:
         types: [opened, reopened, edited, closed]
+  - |
+    on:
+      pull_request:

.taskless/rules/sg/pr-workflow-ready-for-review/pr-workflow-ready-for-review.yml

@@ -20,21 +20,38 @@ files:
   - ".github/workflows/*.yml"
   - ".github/workflows/*.yaml"
 rule:
-  kind: block_mapping_pair
-  has:
-    field: key
-    kind: flow_node
-    regex: '^types$'
-  not:
-    has:
-      field: value
-      stopBy: end
-      kind: flow_node
-      regex: 'ready_for_review'
-  inside:
-    stopBy: end
-    kind: block_mapping_pair
-    has:
-      field: key
-      kind: flow_node
-      regex: '^pull_request$'
+  any:
+    # An explicit `types:` that omits `ready_for_review`.
+    - kind: block_mapping_pair
+      has:
+        field: key
+        kind: flow_node
+        regex: '^types$'
+      not:
+        has:
+          field: value
+          stopBy: end
+          kind: flow_node
+          regex: 'ready_for_review'
+      inside:
+        stopBy: end
+        kind: block_mapping_pair
+        has:
+          field: key
+          kind: flow_node
+          regex: '^pull_request$'
+    # NO `types:` at all. GitHub then applies its default set — `opened`,
+    # `synchronize`, `reopened` — which omits `ready_for_review` exactly as
+    # an incomplete explicit list does. Anchoring only on a `types:` node
+    # cannot see this: there is no node to anchor to.
+    - kind: block_mapping_pair
+      has:
+        field: key
+        kind: flow_node
+        regex: '^pull_request$'
+      not:
+        has:
+          field: value
+          stopBy: end
+          kind: flow_node
+          regex: '^types$'