Consistent vocabulary with `hasCapability`: `disabledWhen: ["react-compiler"]` reads "disabled when react-compiler is present." Pure rename of the rule-metadata field and the `shouldEnableRule` parameter across 21 files; behavior is unchanged (net 0 LOC). Historical CHANGELOG entries keep the old name.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…ned union

`requires` / `disabledWhen` / `hasCapability` were stringly typed, so a
misspelled token ("sever-actions") was a silently never-matching gate.
The vocabulary now lives in one typed `Capability` union in the plugin
(core imports the plugin, never the reverse), and core's `Framework`
aliases the plugin's `FrameworkToken` so the two unions cannot drift.
Registry codegen emits `new Set<Capability>(...)` so the merged
`requires` arrays keep their literal types through the spread.

Also adds the (not yet consumed) `recommendationFor` hook: a
capability-conditioned override of `recommendation`, evaluated later by
core's diagnostic pipeline — groundwork for moving rule prose out of
parse-output.ts.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…oized, straight-line

`buildCapabilities` is a pure projection over `ProjectInfo`, consumed by
the oxlint config, the security scan, and (next commit) the diagnostic
pipeline — it never belonged to the oxlint runner. It now lives in
`project-info/`, and `getCapabilities` memoizes one set per `ProjectInfo`
identity (discoverProject caches one instance per directory, so every
consumer shares a single computation).

The `CapabilityRule` closure table (three mutually-exclusive row shapes +
interpreter loop) is replaced by straight-line adds — the rows were
closures, so the table was never data; the ifs read the same, typecheck
against `Capability`, and drop ~50 lines of mechanism. One helper remains
for the react/preact major ladders.

New `client-only` trait row: the SPA / mobile framework list moves out of
`no-prevent-default` (consumed there in the next commit) into the one
projection, so rules ask a capability question instead of keeping their
own framework sets.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…special cases

`parse-output.ts` carried a rule-name string match rewriting
nextjs-no-client-side-redirect's advice under static export (reading
`project.isStaticExport` directly, bypassing the capability vocabulary)
plus a second special case for no-secrets-in-client-code's per-framework
env-prefix advice. Both move into the rules themselves via the
`recommendationFor(hasCapability)` hook; `getRuleRecommendation`
collapses to one generic dispatch and core's
build-no-secrets-recommendation.ts / get-public-env-prefix.ts are
deleted. Core now carries zero rule-specific prose.

`no-prevent-default` finishes its capability conversion: the hardcoded
CLIENT_ONLY_FRAMEWORKS set (kept alongside the hasCapability check in
the original conversion) becomes the `client-only` capability, checked
at runtime so the `<a onClick preventDefault>` variant still fires on
SPA frameworks. The framework list now lives only in buildCapabilities.

All 75 regression pins (no-prevent-default framework matrix, #976
static-export e2e, no-secrets prose, rule-messages) pass unchanged.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Full-ProjectInfo snapshots over a workspace fixture matrix (pnpm named
catalogs, yarn-workspaces web monorepo with an RN workspace, nx, leaf
scan through monorepo catalogs, lowest-react-major merge, overlapping
globs, the tailwind piggyback quirk). Every fixture is traversal-order-
independent, so these pins must hold bit-for-bit across the legacy
multi-walk discovery and the single-pass rewrite that follows.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

`discoverProject` ran up to ~7 separate workspace traversals per project
— react/tailwind/zod/framework, RN awareness, reanimated, expo,
flash-list, and next each re-resolved the same globs and re-visited the
same manifests, and the react walk used raw readdir order
(nondeterministic) while the others sorted. `collectWorkspaceFacts` now
enumerates the workspace directories once (pattern order, sorted within
each pattern, deduped across overlapping globs) and evaluates every
workspace-derived fact per manifest, recording the source directory that
supplied each dependency signal.

Semantics preserved exactly: the stage-D react group still fills only
when the root leaves react/framework unresolved (the tailwind/zod
piggyback quirk), settles on the legacy early-exit condition (react ≤ 17
+ tailwind + framework), and skips its catalog work entirely when the
gate is closed; expoVersion/nextjsVersion/hasReanimated keep their
semantic nulls; the leaf-vs-root fallback asymmetry in
findDependencyInfoFromMonorepoRoot is unchanged (and now documented).
The one intended change: framework/react workspace precedence is now
sorted-deterministic instead of readdir-order.

The full discovery spec (~100 cases), the new characterization pins, and
all 2,022 react-doctor e2e tests pass with zero assertion edits.
Deletes per-dependency-version.ts and the five per-fact walkers.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The static-export probe read `next.config.*` at the scan root only, while
the `nextjs` framework signal can come from a workspace — so a monorepo
whose `apps/web` sets `output: "export"` kept the `server-actions`
capability and the impossible server advice #976 is about (the deferred
Bugbot finding on this PR). The probe now reads the config next to the
manifest that supplied the `next` dependency signal, riding the source
directory the single-pass collector already records: the scan root when
it declares `next` itself (unchanged), otherwise the first workspace in
walk order that does — the same first-match attribution `nextjsVersion`
uses, pinned for the multi-Next-workspace case.

Covered at both levels: discovery tests (root config, workspace config,
two-apps first-match, no-export), and a no-override e2e in the #976
regression suite proving a monorepo-root scan now softens the redirect
advice.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…ce merge

Validated the sorted-order determinism change against the 863-repo RDE
corpus by diffing discoverProject output pre/post rewrite. Plain
first-in-sorted-order let an `apps/mobile` Expo workspace claim the
framework slot from an `apps/web` Next.js app purely because "mobile"
sorts first — silently dropping all 23 `requires: ["nextjs"]` rules on
web-primary monorepos (linkwarden, t4-app, taro in the corpus).

The merge is now two-tier: web frameworks outrank expo/react-native,
walk order only breaks ties within a tier — the same web-over-mobile
priority detectFramework already applies within one manifest, and
strictly coverage-preserving (`rn-*` / Expo rules ride
hasReactNativeWorkspace / expoVersion, not the framework slot; mobile
and web SPA frameworks carry `client-only` alike). A full-priority rank
across all workspaces was measured too and rejected: it reclassified 34
corpus repos (vite apps flipping to their Next.js docs-site workspace).

Final corpus blast radius: 23/863 repos (2.7%) — no repo loses RN/Expo
coverage, several web-primary monorepos regain their Next.js rules, the
two isStaticExport flips are real workspace static exports (dual-mode
conditional configs, treated as export-capable by design), and the rest
is deterministic version re-attribution.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>