improvement(audits): check rule frontmatter globs in check:guidance-refs

A paths glob that matches nothing silently stops the rule from loading.
sim-api-contracts still targeted the removed apps/sim/hooks/selectors; drop
it, and name check:api-validation:strict as the gate the rule describes.

Author: waleedlatif1

.claude/rules/sim-api-contracts.md

@@ -5,7 +5,6 @@ paths:
   - "apps/sim/lib/api/**"
   - "apps/sim/lib/**/application/**"
   - "apps/sim/hooks/queries/**"
-  - "apps/sim/hooks/selectors/**"
 ---
 
 # API Contracts and Routes
@@ -19,15 +18,15 @@ Boundary HTTP request and response shapes for all routes under `apps/sim/app/api
 
 ## Enforcement
 
-`bun run check:api-validation` enforces boundary policy and prints ratchet metrics (route Zod imports, route-local schema constructors, route `ZodError` references, client hook Zod imports, and related counters). `bun run check:api-validation:strict` is the CI gate: it additionally fails on annotations with empty reasons. Both must pass on PRs.
+`bun run check:api-validation:strict` is the gate (it runs in `check:audits`): it enforces boundary policy, prints ratchet metrics (route Zod imports, route-local schema constructors, route `ZodError` references, client hook Zod imports), and fails on annotations with empty reasons. `check:api-validation` is the same audit without the strict reason check.
 
 Whole-file allowlists for routes that legitimately import Zod for non-boundary reasons go through `INDIRECT_ZOD_ROUTES` in `scripts/check-api-validation-contracts.ts`, not per-line annotations.
 
 ## Boundary annotations
 
 A small number of legitimate exceptions are tolerated when annotated. The audit recognizes four forms:
 
-- `// boundary-raw-fetch: <reason>` — directly above a raw `fetch(` inside `apps/sim/hooks/queries/**`, `apps/sim/hooks/selectors/**`, or any other source under `apps/sim/**` (outside an API route handler) that targets a same-origin `/api/...` URL. Only for streaming responses, binary downloads, multipart uploads, signed-URL flows, OAuth redirects, and external-origin requests.
+- `// boundary-raw-fetch: <reason>` — directly above a raw `fetch(` inside `apps/sim/hooks/queries/**` or any other source under `apps/sim/**` (outside an API route handler) that targets a same-origin `/api/...` URL. Only for streaming responses, binary downloads, multipart uploads, signed-URL flows, OAuth redirects, and external-origin requests.
 - `// double-cast-allowed: <reason>` — directly above an `as unknown as X` cast outside test files.
 - `// boundary-raw-json: <reason>` — directly above a raw `await request.json()` / `await req.json()` read (or the multi-line `await request.clone().json()` shim variant) in a route handler. Only when the body is a JSON-RPC envelope, a tolerant `.catch(() => ({}))` parse, or otherwise cannot go through `parseRequest`.
 - `// untyped-response: <reason>` — directly above a `schema: z.unknown()` / `schema: z.object({}).passthrough()` / `schema: z.record(z.string(), z.unknown())` response declaration (or a simple alias to one of those) in a contract file. Only when the response body is genuinely opaque (user-supplied data, third-party passthrough).

.cursor/rules/emcn-components.mdc

@@ -22,7 +22,7 @@ The menu surface intentionally diverges from the pill: `dropdown-menu.tsx` items
 
 ## Component catalogue
 
-- **`Chip` / `ChipLink`** — the pill button (`<button>` / Next `<Link>`). Variants: `primary`, `destructive`, `border-shadow`, `border`, `outline` (a true `--border` border, no shadow or hover fill); the bare chip is implicit (omit `variant`). `filled` is deliberately NOT a `Chip` variant — it is reserved for chip fields/triggers. For a selected/toggle chip use the `active` prop, never a variant. `leftIcon`/`rightIcon`, `active`, `fullWidth`. Chips carry **no outer margin** — space between them is the parent's `gap`. The old `mx-0.5` default and its `flush` opt-out are gone; do not reintroduce either, and never add a margin to a chip through `className`.
+- **`Chip` / `ChipLink`** — the pill button (`<button>` / Next `<Link>`). Variants: `primary`, `destructive`, `border-shadow`, `border`, `outline` (a true `--border` border, no shadow or hover fill); the bare chip is implicit (omit `variant`). `filled` is deliberately NOT a `Chip` variant — it is reserved for chip fields/triggers. For a selected/toggle chip use the `active` prop, never a variant. `leftIcon`/`rightIcon`, `active`, `fullWidth`. Chips carry **no outer margin** — space between them is the parent's `gap`, so never give a chip a margin, by default or through `className`.
 - **`ChipInput`** — single-line text field. `icon`, `endAdornment`, `error`, `inputClassName` (inner `<input>`); `className` styles the chrome wrapper.
 - **`ChipCopyInput`** — the canonical view-only field: a read-only `ChipInput` at full opacity with a trailing copy-to-clipboard button. View-only is a display mode, not a disabled state — reach for it (or `ChipModalField type='copy'`) over a `disabled` (greyed) input for values the user cannot edit.
 - **`ChipTextarea`** — multi-line sibling. `error`, `resizable` (off by default), `viewOnly` (read-only at full opacity with the default cursor — the multi-line counterpart of `ChipCopyInput`).
@@ -53,8 +53,8 @@ Declare keyboard intent on the action-owning primitive; never add document-level
 - **Props over `className` overrides.** When a consumer needs to change chrome, expose a prop (`error`, `icon`, `endAdornment`, `inputClassName`); reaching for `className` to restyle chrome is the smell.
 - **`cn()` for a single state toggle, CVA for genuine multiple variants.** A lone `error` boolean is `cn()`, not a CVA variant.
 - **Discriminated-union props for modes** (e.g. `multiple`, the modal field `type`) instead of near-duplicate components.
-- **Delete legacy variants after migration** — don't leave dead paths (this paradigm removed `Input variant='chip'` and `ChipMultiSelect`).
-- **Verify CSS vars exist.** An undefined var resolves to `currentColor` (caused a real black-border bug). Align to the canonical tokens: normal weight, `--text-body`, `--text-icon`.
+- **Delete legacy variants after migration** — leave no dead paths.
+- **Verify CSS vars exist.** An undefined var resolves to `currentColor`, which draws black borders. Align to the canonical tokens: normal weight, `--text-body`, `--text-icon`.
 - Use Radix UI primitives for accessibility. Export the component and its `variants` (when using CVA). Document with TSDoc + a usage example.
 
 Color tokens and icon-size conventions are canonical in `.claude/rules/sim-styling.md` — follow it rather than restating.

.cursor/rules/sim-api-contracts.mdc

@@ -1,6 +1,6 @@
 ---
 description: "API contracts, route builders, boundary annotations, and the requestJson client boundary"
-globs: ["apps/sim/app/api/**","apps/sim/lib/api/**","apps/sim/lib/**/application/**","apps/sim/hooks/queries/**","apps/sim/hooks/selectors/**"]
+globs: ["apps/sim/app/api/**","apps/sim/lib/api/**","apps/sim/lib/**/application/**","apps/sim/hooks/queries/**"]
 ---
 
 <!-- Generated from .claude/rules/sim-api-contracts.md by `bun run skills:sync`. Edit the source, not this file. -->
@@ -16,15 +16,15 @@ Boundary HTTP request and response shapes for all routes under `apps/sim/app/api
 
 ## Enforcement
 
-`bun run check:api-validation` enforces boundary policy and prints ratchet metrics (route Zod imports, route-local schema constructors, route `ZodError` references, client hook Zod imports, and related counters). `bun run check:api-validation:strict` is the CI gate: it additionally fails on annotations with empty reasons. Both must pass on PRs.
+`bun run check:api-validation:strict` is the gate (it runs in `check:audits`): it enforces boundary policy, prints ratchet metrics (route Zod imports, route-local schema constructors, route `ZodError` references, client hook Zod imports), and fails on annotations with empty reasons. `check:api-validation` is the same audit without the strict reason check.
 
 Whole-file allowlists for routes that legitimately import Zod for non-boundary reasons go through `INDIRECT_ZOD_ROUTES` in `scripts/check-api-validation-contracts.ts`, not per-line annotations.
 
 ## Boundary annotations
 
 A small number of legitimate exceptions are tolerated when annotated. The audit recognizes four forms:
 
-- `// boundary-raw-fetch: <reason>` — directly above a raw `fetch(` inside `apps/sim/hooks/queries/**`, `apps/sim/hooks/selectors/**`, or any other source under `apps/sim/**` (outside an API route handler) that targets a same-origin `/api/...` URL. Only for streaming responses, binary downloads, multipart uploads, signed-URL flows, OAuth redirects, and external-origin requests.
+- `// boundary-raw-fetch: <reason>` — directly above a raw `fetch(` inside `apps/sim/hooks/queries/**` or any other source under `apps/sim/**` (outside an API route handler) that targets a same-origin `/api/...` URL. Only for streaming responses, binary downloads, multipart uploads, signed-URL flows, OAuth redirects, and external-origin requests.
 - `// double-cast-allowed: <reason>` — directly above an `as unknown as X` cast outside test files.
 - `// boundary-raw-json: <reason>` — directly above a raw `await request.json()` / `await req.json()` read (or the multi-line `await request.clone().json()` shim variant) in a route handler. Only when the body is a JSON-RPC envelope, a tolerant `.catch(() => ({}))` parse, or otherwise cannot go through `parseRequest`.
 - `// untyped-response: <reason>` — directly above a `schema: z.unknown()` / `schema: z.object({}).passthrough()` / `schema: z.record(z.string(), z.unknown())` response declaration (or a simple alias to one of those) in a contract file. Only when the response body is genuinely opaque (user-supplied data, third-party passthrough).

.cursor/rules/sim-architecture.mdc

@@ -11,7 +11,7 @@ Repository layout, package boundaries, the application operation boundary, namin
 
 ## The `'use client'` server boundary
 
-Every export of a `'use client'` module becomes a *client reference* on the server — server-evaluated code (RSC pages/layouts, `prefetch.ts`, route handlers, block definitions, triggers) can only *render* it as a component or pass it as a prop, never *call* it (doing so throws at runtime, e.g. `tableKeys.list is not a function`; `next build` does not catch it). Keep server-importable query primitives (key factories, fetchers, mappers, constants) in non-`'use client'` modules — see `.claude/rules/sim-queries.md`. Enforced by `scripts/check-client-boundary-imports.ts`.
+Server-evaluated code (RSC pages/layouts, `prefetch.ts`, route handlers, block definitions, triggers) can render an export of a `'use client'` module but never call it; the call throws at runtime and `next build` does not catch it. Keep anything a server module calls (key factories, fetchers, mappers, constants) in a non-`'use client'` module. Detail and the escape hatch: `.claude/rules/sim-queries.md`. Enforced by `bun run check:client-boundary`.
 
 ## The app/worker runtime boundary
 

.cursor/rules/sim-components.mdc

@@ -33,8 +33,7 @@ export function Component({ requiredProp, optionalProp = false }: ComponentProps
 
 When rendering or sorting a list of rows against a lookup collection (members, folders, tags), keep the per-row work O(1):
 
-- **Precompute a lookup `Map` once**, never `array.find(...)` per row. Build `const byId = useMemo(() => { const m = new Map<string, T>(); for (const x of items ?? []) m.set(x.id, x); return m }, [items])` and read `byId.get(id)` in the sort comparator, `.map(...)`, and cell builders. A `.find` inside a sort comparator is O(n²·log n) — the worst offender. Depend memos on the derived `Map`, not the raw array.
-- **Sort a copy with `[...array].sort(cmp)`**, never `toSorted` in client code — see `sim-react-performance.md` → "Never mutate a shared array in place".
+- **Precompute a lookup `Map` once** (`useMemo` over the collection) and read `byId.get(id)` in the sort comparator, `.map(...)`, and cell builders. A `.find` inside a sort comparator is O(n²·log n). Depend downstream memos on the derived `Map`, not the raw array. Map-building and copy-then-sort rules: `sim-react-performance.md`.
 - **Partition in a single pass** — when splitting one collection into several (`fileIds`/`folderIds`), do one `for…of` pushing into each bucket and return `{ a, b }` from a single `useMemo`, not two memos that each `map→filter→map` the same source twice.
 
 ## react-doctor (`bunx react-doctor`) — apply the wins, skip the false positives

.cursor/rules/sim-list-ordering.mdc

@@ -9,8 +9,6 @@ globs: ["apps/sim/app/**/*.tsx","apps/sim/ee/**/*.tsx","apps/sim/components/**/*
 
 **A list orders itself the way the user already reads the same things somewhere else.** Dropdowns, context menus, tab strips, command palettes, and settings navs are all *second* presentations of a set the user has already seen — in a toolbar, in the settings nav, in a column-header row. When the second presentation reorders that set, the user re-reads it from scratch every time.
 
-This is not a style preference. Order is the cheapest affordance a list has, and the only one that costs nothing to get right.
-
 ## The rule
 
 Before writing a list of items, find where the user sees those same items *first*. That surface owns the order; your list mirrors it.
@@ -93,14 +91,10 @@ const hasDestructiveSection = (showLeave && onLeave) || showDelete
 {hasActionsAboveDestructive && hasDestructiveSection && <DropdownMenuSeparator />}
 ```
 
-This is the failure that put a dangling rule at the bottom of the logs row menu, where two
-unconditional separators sat above conditional items.
+Unconditional separators above conditional items leave a dangling rule at the bottom of the menu.
 
-**Do not add a prop to move a rule.** The shared workflow context menu grew
-`groupNonDestructiveActions` and `separateNavigationAction` for this; between them they moved one
-separator for one caller, four of six branches were unreachable, and `separateNavigationAction`
-had no observable effect anywhere in the repo. Both are gone. A menu that wants different
-grouping wants the standard grouping.
+**Never add a prop to move a rule.** Per-caller grouping props multiply unreachable branches; a
+menu that wants different grouping wants the standard grouping.
 
 ## Encode the order once
 
@@ -130,7 +124,7 @@ The most common way a canonical order gets silently defeated: emitting all items
 {groups.filter((g) => !FOLDERED.has(g.type)).map(renderFlat)}
 
 // ✓ Good — one ordered pass; each entry picks its own rendering
-{entries.sort(byResourceMenuOrder).map((entry) =>
+{[...entries].sort(byResourceMenuOrder).map((entry) =>
   sectionByType.has(entry.type) ? renderTree(entry) : renderFlat(entry)
 )}
 ```

.cursor/rules/sim-queries.mdc

@@ -141,7 +141,6 @@ const handler = useCallback(() => {
 // ✓ Good — omit from deps, mutate is stable
 const handler = useCallback(() => {
   createEntity.mutate(data)
-  // eslint-disable-next-line react-hooks/exhaustive-deps
 }, [data])
 ```
 

.cursor/rules/sim-settings-pages.mdc

@@ -110,17 +110,9 @@ Adding a new settings page:
 
 ## Text-scale tokens (no literal pixel sizes)
 
-Settings pages never use a literal `text-[Npx]` class — always the named Tailwind
-scale token from the `@theme` block in `apps/sim/app/_styles/globals.css` (`text-micro`
-10px, `text-xs` 11px, `text-caption` 12px, `text-small` 13px, `text-sm` 14px
-[Tailwind default, unmodified], `text-base` 15px, `text-md` 16px, `text-lg` 18px
-[Tailwind default]). A literal size is either a straight rename to the equivalent
-token (if the pixel value matches one exactly) or a sign the page never migrated —
-grep `text-\[1[0-8]px\]` under `apps/sim/app/workspace/*/settings/**` and
-`apps/sim/ee/**` to find stragglers.
-
-Watch `text-xs`: it is 11px here, so a "caption" written as `text-xs` is a pixel
-short. See `sim-styling.md` for the full scale.
+Settings pages never use a literal `text-[Npx]` class — always a named token from
+the scale in `sim-styling.md` ("Text Scale"). Find stragglers with
+`rg 'text-\[1[0-8]px\]' apps/sim/app/workspace apps/sim/ee`.
 
 The two-line list row (title over a muted subtitle — a name + email, a tool name
 + description, a server name + status) is **not something you build**: it is
@@ -399,4 +391,4 @@ A settings page is design-system-clean when:
 - [ ] Decorative trailing content is in `badge`, not `trailing`.
 - [ ] Labeled sections use `SettingsSection`; read-only fields use `SettingsField`; empty/loading/error use `SettingsEmptyState`.
 - [ ] Delete is a plain `id:'delete'` header action behind a `ChipConfirmModal`; `destructive` is reserved for bulk actions.
-- [ ] `tsc`, `biome`, and the page's tests pass.
+- [ ] The local gate in the root `CLAUDE.md` ("How your work is checked") passes.