eslint-plugin-llm-core-mcp 0.29.8 → 0.29.9

package/dist/embedded-docs.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"embedded-docs.d.ts","sourceRoot":"","sources":["../src/embedded-docs.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,YAAY,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CA2C/C,CAAC;AAEF,eAAO,MAAM,SAAS,EAAE,MAAM,EAAi+B,CAAC"}
+{"version":3,"file":"embedded-docs.d.ts","sourceRoot":"","sources":["../src/embedded-docs.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,YAAY,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAkD/C,CAAC;AAEF,eAAO,MAAM,SAAS,EAAE,MAAM,EAAkpC,CAAC"}

package/dist/embedded-docs.js

@@ -15,6 +15,7 @@ export const embeddedDocs = {
     "no-any-in-generic": "# llm-core/no-any-in-generic\n\n📝 Disallow `any` as a generic type argument in type references, arrays, and other parameterized types.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, ✅ `recommended`, ⌨️ `typescript`.\n\n<!-- end auto-generated rule header -->\n\nDisallow `any` as a generic type argument in type references like `Array<any>`, `Record<string, any>`, `Map<string, any>`, and other parameterized types.\n\n## Rule Details\n\nLLMs frequently use `any` inside generic types as a \"good enough\" placeholder. Unlike bare `any` annotations, this pattern is subtler — the code looks typed because there's a generic wrapper, but `any` silently leaks through every access, assignment, and function call that touches the contained values.\n\n## Examples\n\n### Incorrect\n\n```ts\n// any leaks into every array access\nconst items: Array<any> = [];\n\n// any leaks into every property access\nconst cache: Record<string, any> = {};\n\n// any leaks into every map.get() call\nconst lookup: Map<string, any> = new Map();\n\n// any leaks into the resolved value\nconst promise: Promise<any> = fetch(\"/api\");\n\n// any in generic function calls\nconst store = createStore<any>();\n```\n\n### Correct\n\n```ts\n// Specific types\nconst items: Array<User> = [];\nconst cache: Record<string, CacheEntry> = {};\nconst lookup: Map<string, Handler> = new Map();\nconst promise: Promise<Response> = fetch(\"/api\");\n\n// unknown when the type is genuinely dynamic\nconst items: Array<unknown> = [];\nconst cache: Record<string, unknown> = {};\n\n// Narrow unknown values with type guards\nfor (const item of items) {\n  if (isUser(item)) {\n    process(item); // TypeScript knows it's a User\n  }\n}\n```\n\n## What This Rule Catches\n\nThe rule flags `any` used as a type argument in:\n\n1. **Type references** — `Array<any>`, `Record<string, any>`, `Map<any, any>`, `Set<any>`, `Promise<any>`, custom generics\n2. **Generic function calls** — `createStore<any>()`, `useState<any>()`\n3. **Multiple `any` arguments** — `Map<any, any>` reports two errors\n\n### What This Rule Does NOT Catch\n\n- `any` in type annotations (`const x: any`) — use `@typescript-eslint/no-explicit-any` for this\n- `any` in type assertions (`value as any`) — use `llm-core/no-type-assertion-any` for this\n- Generic type parameter definitions (`interface Foo<T = any>`) — these define defaults, not usage\n\n## Error Messages\n\nThe error message teaches the proper alternative:\n\n1. **What's wrong** — `any` inside a generic disables type checking for contained values\n2. **Why** — the `any` leaks into every access and assignment through the container\n3. **How to fix** — use a specific type, or `unknown` with type guards for dynamic data\n",
     "no-async-array-callbacks": "# llm-core/no-async-array-callbacks\n\n📝 Disallow async callbacks passed to array methods where Promises are silently discarded or misused.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, 🏆 `best-practices`, ✅ `recommended`.\n\n<!-- end auto-generated rule header -->\n\nDisallow passing async functions to array methods where the returned Promises are silently discarded or semantically wrong.\n\n## Rule Details\n\nLLMs frequently write `items.forEach(async (item) => { await ... })` or `items.filter(async (item) => { return await check(item) })` assuming the method understands async callbacks. It doesn't — these methods are synchronous and either ignore the return value (forEach) or receive a Promise object where a boolean was expected (filter, some, every).\n\n### Methods that always flag async callbacks\n\n| Method    | Why async is wrong                                              |\n| --------- | --------------------------------------------------------------- |\n| `forEach` | Return value is always ignored; Promises are silently discarded |\n| `filter`  | Receives a truthy Promise object, not the resolved boolean      |\n| `some`    | Receives a truthy Promise, always returns `true`                |\n| `every`   | Receives a truthy Promise, always returns `true`                |\n| `reduce`  | Accumulator becomes a Promise, chaining breaks silently         |\n| `flatMap` | Returns an array of Promises instead of flattened values        |\n\n### `map` — conditional flagging\n\n`items.map(async ...)` returns an array of Promises. This rule only allows that pattern when the result is **immediately awaited or returned** through `Promise.all(...)` or `Promise.allSettled(...)`. The rule flags async map callbacks in all other contexts.\n\n## Examples\n\n### Incorrect\n\n```ts\n// forEach: Promises are silently discarded\nitems.forEach(async (item) => {\n  await processItem(item);\n});\n\n// filter: resolves to [Promise, Promise, ...] not booleans\nconst active = items.filter(async (item) => {\n  return await isActive(item);\n});\n\n// map without Promise.all: returns array of unresolved Promises\nconst results = items.map(async (item) => {\n  return await fetchData(item);\n});\n\n// Promise.all without await/return still drops the outer promise\nPromise.all(\n  items.map(async (item) => {\n    return await fetchData(item);\n  }),\n);\n```\n\n### Correct\n\n```ts\n// Sequential with for...of\nfor (const item of items) {\n  await processItem(item);\n}\n\n// Parallel with Promise.all — the documented safe pattern for map\nawait Promise.all(\n  items.map(async (item) => {\n    return await processItem(item);\n  }),\n);\n\n// Synchronous callbacks are always fine\nitems.forEach((item) => process(item));\nitems.filter((item) => item.active);\n```\n\n## What This Rule Does NOT Catch\n\n- Named function references (e.g., `forEach(processItem)`) — cannot determine if the referenced function is async without type information\n- Async callbacks on named function references stored elsewhere\n\n## Syntax-Only Limitation\n\nThis rule is intentionally syntax-only. It looks for familiar method names like `.forEach()`, `.filter()`, or `.map()` and does **not** use type information to prove that the receiver is a real JavaScript array.\n\nThat means custom collection APIs that intentionally expose array-like method names may also be flagged. If your codebase relies on async-aware custom collections, scope or disable this rule for those files.\n\n## Error Messages\n\nTwo distinct messages are used:\n\n1. **`noAsyncArrayCallback`** — for forEach, filter, some, every, reduce, flatMap: teaches that Promises are discarded or misused and offers concrete alternatives\n2. **`noAsyncMapCallback`** — for map without immediate await/return through `Promise.all(...)`: teaches the `await Promise.all(items.map(...))` pattern\n",
     "no-async-promise-executor": "# llm-core/no-async-promise-executor\n\n📝 Disallow async Promise executor functions because thrown errors are not captured by the outer Promise.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, 🏆 `best-practices`, ✅ `recommended`.\n\n<!-- end auto-generated rule header -->\n\nDisallow `async` functions as `new Promise(...)` executors. LLMs often wrap an already-async operation in a Promise constructor and mark the executor `async`, but the Promise constructor does not await that executor.\n\n## Rule Details\n\nThe Promise constructor expects a synchronous executor. If an async executor throws after an `await`, that error belongs to the executor's implicit Promise, not the outer Promise being constructed. That can leave the outer Promise unresolved while the async failure escapes through an unhandled rejection.\n\n## Examples\n\n### Incorrect\n\n```ts\nconst result = new Promise(async (resolve) => {\n  resolve(await loadValue());\n});\n\nconst loaded = new Promise(async function (resolve, reject) {\n  try {\n    resolve(await loadValue());\n  } catch (error) {\n    reject(error);\n  }\n});\n```\n\n### Correct\n\n```ts\nconst result = loadValue();\n\nconst loaded = new Promise((resolve, reject) => {\n  loadValue().then(resolve, reject);\n});\n\nconst fromCallback = new Promise((resolve, reject) => {\n  readFile(path, (error, contents) => {\n    if (error) {\n      reject(error);\n      return;\n    }\n\n    resolve(contents);\n  });\n});\n```\n\n## What This Rule Catches\n\n| Pattern                                    | Triggers? |\n| ------------------------------------------ | --------- |\n| `new Promise(async (resolve) => { ... })`  | Yes       |\n| `new Promise(async function () { ... })`   | Yes       |\n| `new Promise((resolve) => { ... })`        | No        |\n| `queueTask(async () => { await save(); })` | No        |\n\n## Error Messages\n\nThe error message teaches:\n\n1. **What's wrong** -- an async function is being used as a Promise executor\n2. **Why** -- the Promise constructor does not await async executors\n3. **How to fix** -- return the async operation directly, or keep manual Promise executors synchronous\n",
+    "no-chained-type-assertions": "# llm-core/no-chained-type-assertions\n\n📝 Disallow chained TypeScript type assertions that discard type evidence.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, ✅ `recommended`, ⌨️ `typescript`.\n\n<!-- end auto-generated rule header -->\n",
     "no-commented-out-code": "# llm-core/no-commented-out-code\n\n📝 Disallow commented-out code to keep the codebase clean and reduce noise.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, 🧹 `hygiene`, ✅ `recommended`.\n\n<!-- end auto-generated rule header -->\n\nDisallow commented-out code to keep the codebase clean and reduce noise.\n\n## Rule Details\n\nLLMs frequently leave commented-out code in their output — old implementations, \"alternative approaches\", half-removed logic, and abandoned experiments. This is one of the most recognizable LLM code smells. Commented-out code adds noise, creates confusion about intent, and makes files harder to read.\n\nThis rule detects comments that contain code-like patterns (variable declarations, function calls, control flow, imports/exports) and flags them for removal.\n\n## Examples\n\n### Incorrect\n\n```ts\n// const oldConfig = loadLegacyConfig();\n// if (oldConfig.enabled) {\n//   processLegacy(oldConfig);\n// }\nfunction loadConfig() {\n  return getNewConfig();\n}\n```\n\n```ts\n/* const previousImplementation = async () => {\n  const data = await fetchData();\n  return transform(data);\n}; */\nasync function fetchAndTransform() {\n  return newApproach();\n}\n```\n\n```ts\n// import { oldHelper } from './utils';\n\n// processData(items);\n\nfunction main() {\n  newProcess(items);\n}\n```\n\n### Correct\n\n```ts\n// This function handles the new config loading approach\nfunction loadConfig() {\n  return getNewConfig();\n}\n```\n\n```ts\n// TODO: add caching support in next sprint\nasync function fetchAndTransform() {\n  return newApproach();\n}\n```\n\n```ts\n/**\n * @param items - The items to process\n * @returns The processed result\n */\nfunction main(items: Item[]) {\n  return newProcess(items);\n}\n```\n\n## What This Rule Allows\n\nThe following comment patterns are **not** flagged:\n\n- **Prose comments** — explanations, notes, descriptions\n- **TODO/FIXME/HACK/NOTE** — task markers\n- **JSDoc comments** — documentation blocks starting with `/**`\n- **ESLint directives** — `eslint-disable`, `eslint-enable`\n- **TypeScript directives** — `@ts-expect-error`, `@ts-ignore`\n- **URLs** — links to documentation or references\n- **Short comments** — comments under 3 characters\n\n## Detection Heuristic\n\nThe rule uses pattern matching to identify code in comments. It looks for:\n\n- Variable declarations (`const`, `let`, `var`)\n- Function and class declarations\n- Import/export statements\n- Control flow (`if`, `for`, `while`, `switch`, `try/catch`)\n- Function/method calls ending with semicolons\n- Assignments ending with semicolons\n- `await` expressions\n- `return`/`throw` statements\n\nConsecutive line comments (`//`) on adjacent lines are grouped and analyzed together, catching multi-line commented-out code blocks.\n\n## Error Messages\n\nError messages follow a structured teaching format designed for LLM self-correction:\n\n1. **What's wrong** — identifies the commented-out code\n2. **Why** — explains that git preserves history, making commented-out code unnecessary\n3. **How to fix** — instructs to delete the code or link to the relevant commit\n",
     "no-debug-scaffolding": "# llm-core/no-debug-scaffolding\n\n📝 Disallow temporary debugger statements and console debug scaffolding left behind during development.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, 🧹 `hygiene`, ✅ `recommended`.\n\n<!-- end auto-generated rule header -->\n\nDisallow temporary `debugger` statements and console debug probes that are commonly left behind by LLM-assisted edits.\n\n## Rule Details\n\nLLMs often debug by inserting ad-hoc `console.log` calls or `debugger` statements and then fail to remove them. These probes make code noisier, can expose sensitive runtime data, and rarely become intentional observability.\n\nThis rule targets high-confidence scaffolding rather than every possible console call. It reports:\n\n- `debugger` statements\n- empty `console.log`, `console.debug`, and `console.trace` calls\n- console probes with temporary labels such as `debug`, `here`, `TODO remove`, or `response`\n- raw dumps of identifiers, objects, arrays, member expressions, or function calls through `console.log`, `console.debug`, or `console.trace`\n\nIt does not replace `structured-logging`; that rule handles dynamic log messages. This rule catches the temporary debug residue that should be deleted or intentionally converted into project logging.\n\n## Examples\n\n### Incorrect\n\n```ts\ndebugger;\n\nconsole.log(\"debug\", value);\nconsole.log(\"here\");\nconsole.debug(\"response\", response);\nconsole.trace(\"trace\", value);\nconsole.log(user);\nconsole.log(user?.id);\nconsole.log(user.id as string);\nconsole.log({ user });\nconsole.log(getState());\nconsole.log(\"TODO remove\", result);\n```\n\n### Correct\n\n```ts\nconsole.error(\"Failed to save user\", error);\nconsole.warn(\"Deprecated API used\", { route });\nconsole.info(\"Migration complete\", { rows });\nconsole.log(\"Server started\");\nconsole.log(\"Processed batch\", { batchId, count });\n\nlogger.debug(\"Cache hit\", { key });\naudit.log(\"User authenticated\", { userId });\n```\n\n## Non-goals\n\n| Pattern                                           | Reason                                                                                     |\n| ------------------------------------------------- | ------------------------------------------------------------------------------------------ |\n| `console.error(...)` and `console.warn(...)`      | Often intentional CLI/script diagnostics or error reporting                                |\n| Meaningful static `console.log(\"Server started\")` | Not enough signal to call it temporary scaffolding                                         |\n| `logger.debug(...)`                               | Project logger calls should be governed by logging policy, not console-scaffolding cleanup |\n| Dynamic console messages                          | Covered by `structured-logging`                                                            |\n| Shadowed local `console` variables                | Not the global console API                                                                 |\n\n## Error Messages\n\nThe error messages teach:\n\n1. **What's wrong** -- a debugger statement, temporary console marker, or raw console dump remains\n2. **Why** -- this is likely debug-session residue and weak observability\n3. **How to fix** -- delete it or convert intentional telemetry to structured logging\n",
     "no-dynamic-code-execution": "# llm-core/no-dynamic-code-execution\n\n📝 Disallow dynamic code execution through eval, Function constructors, and string-based timers.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, 🏆 `best-practices`, ✅ `recommended`.\n\n<!-- end auto-generated rule header -->\n\nDisallow dynamic code execution APIs that compile strings as JavaScript. LLMs often use these APIs as shortcuts for configurable dispatch, plugin systems, expression evaluation, or timer callbacks, but they create injection risk and hide the allowed command surface from reviewers.\n\n## Rule Details\n\nThis rule reports obvious, framework-agnostic dynamic execution patterns:\n\n- direct `eval(...)`\n- global member eval calls such as `window.eval(...)` and `globalThis.eval(...)`\n- `new Function(...)`\n- `Function(...)`\n- global member Function calls such as `globalThis.Function(...)` and `window.Function(...)`\n- `setTimeout(...)` and `setInterval(...)` when the first argument is a string or template literal\n- global member timer calls such as `window.setTimeout(...)` and `globalThis.setInterval(...)` when the first argument is a string or template literal\n\nThe rule intentionally does not try to prove whether a string is user-controlled. These APIs are unsafe-by-default and should be reviewed explicitly when they are truly unavoidable.\n\n## Examples\n\n### Incorrect\n\n```ts\neval(userInput);\n\nconst fn = new Function(\"ctx\", generatedBody);\n\nconst readEnv = globalThis.Function(\"return process.env\");\nconst readCookie = window.Function(\"return document.cookie\");\n\nsetTimeout(\"refreshToken()\", 1000);\nwindow.setTimeout(\"refreshToken()\", 1000);\nsetInterval(`poll()`, 5000);\n```\n\n### Correct\n\n```ts\nconst handlers = {\n  refreshToken,\n  poll,\n} satisfies Record<string, () => void>;\n\nhandlers[action]?.();\n\nsetTimeout(() => refreshToken(), 1000);\nsetInterval(() => poll(), 5000);\n```\n\n## What Counts as Dynamic Code Execution\n\n| Pattern                                  | Triggers? | Notes                                |\n| ---------------------------------------- | --------- | ------------------------------------ |\n| `eval(userInput)`                        | Yes       | Direct string execution              |\n| `window.eval(template)`                  | Yes       | Global eval member call              |\n| `new Function(\"return value\")`           | Yes       | Function constructor compiles string |\n| `Function(\"return value\")`               | Yes       | Function constructor call            |\n| `globalThis.Function(\"return value\")`    | Yes       | Global Function member call          |\n| `window.Function(\"return value\")`        | Yes       | Global Function member call          |\n| `setTimeout(\"run()\", 1000)`              | Yes       | String timer compiles code           |\n| `globalThis.setInterval(\"poll()\", 1000)` | Yes       | Global string timer compiles code    |\n| `setTimeout(() => run(), 1000)`          | No        | Function callback                    |\n| `handlers[action]?.()`                   | No        | Explicit dispatch table              |\n| `sandbox.eval(expression)`               | No        | Non-global object method             |\n\n## Error Messages\n\nThe error message teaches:\n\n1. **What's wrong** -- a string is being executed as code\n2. **Why** -- dynamic execution creates injection risk and obscures valid behavior\n3. **How to fix** -- use dispatch tables, callbacks, schema/config parsing, or explicit plugin registration instead of compiling strings\n",
@@ -25,15 +26,21 @@ export const embeddedDocs = {
     "no-hallucinated-package-imports": "# llm-core/no-hallucinated-package-imports\n\n📝 Disallow package imports and re-exports whose package root is not declared in the relevant package manifest.\n\n💼 This rule is enabled in the 🌐 `all` config.\n\n<!-- end auto-generated rule header -->\n\nDisallow package `import` and `export ... from` declarations when the package root is not declared in the relevant package manifest.\n\n## Rule Details\n\nLLM coding agents often invent plausible package names, assume a dependency is already installed, or import from a package that exists in another project but not in the current one. These hallucinated package imports look reasonable during review but fail at install, build, test, or runtime.\n\nThis rule reports package roots that are absent from the configured package manifest dependency sources. It intentionally ignores relative and absolute local paths because `llm-core/no-hallucinated-local-imports` handles local modules.\n\nBy default, this rule treats these sources as allowed:\n\n- `dependencies`\n- `devDependencies`\n- `peerDependencies`\n- `optionalDependencies`\n- Node.js builtins, including `node:` specifiers\n- the current package's own `name` for valid package self-references\n- workspace package names discovered from explicit workspace paths and simple workspace glob patterns such as `packages/*`\n- packages listed in the `allow` option\n\n## Examples\n\n### Incorrect\n\n```ts\nimport { retry } from \"super-retry-utils\";\n// super-retry-utils is not declared in package.json\n\nimport type { Client } from \"@vendor/nonexistent-sdk\";\n// @vendor/nonexistent-sdk is not declared in package.json\n\nexport { thing } from \"plausible-helper-package\";\n// plausible-helper-package is not declared in package.json\n\nconst mod = await import(\"made-up-package\");\n// made-up-package is not declared in package.json\n```\n\n### Correct\n\n```ts\nimport { readFile } from \"node:fs/promises\";\nimport path from \"node:path\";\nimport { z } from \"zod\";\n// zod is declared in package.json\n\nimport { helper } from \"./helper\";\n// relative imports are handled by no-hallucinated-local-imports\n\nimport internal from \"@workspace/internal-package\";\n// workspace package names are allowed when workspace discovery is enabled\n\nimport selfConfig from \"my-package/config\";\n// package self-references are allowed when package.json has \"name\": \"my-package\"\n\nimport localAlias from \"@/utils\";\n// common @/ path aliases are ignored because they are not valid npm package roots\n```\n\n## Options\n\n```ts\ntype Options = [\n  {\n    packageJsonPath?: string;\n    workspace?: boolean;\n    allow?: string[];\n    checkDevDependencies?: boolean;\n    checkPeerDependencies?: boolean;\n    checkOptionalDependencies?: boolean;\n    checkDynamicImports?: boolean;\n    checkRequire?: boolean;\n  },\n];\n```\n\n| Option                      | Default | Description                                                                   |\n| --------------------------- | ------- | ----------------------------------------------------------------------------- |\n| `packageJsonPath`           | nearest | Package manifest to inspect. If omitted, the nearest `package.json` is used.  |\n| `workspace`                 | `true`  | Allow workspace package names from explicit paths and simple workspace globs. |\n| `allow`                     | `[]`    | Additional exact specifiers or package roots to allow.                        |\n| `checkDevDependencies`      | `true`  | Treat `devDependencies` as allowed. Set to `false` to report them.            |\n| `checkPeerDependencies`     | `true`  | Treat `peerDependencies` as allowed. Set to `false` to report them.           |\n| `checkOptionalDependencies` | `true`  | Treat `optionalDependencies` as allowed. Set to `false` to report them.       |\n| `checkDynamicImports`       | `true`  | Check dynamic `import(\"literal\")` package specifiers.                         |\n| `checkRequire`              | `false` | Check CommonJS `require(\"literal\")` package specifiers.                       |\n\n## What This Rule Flags\n\n| Import/export shape                            | Flagged? |\n| ---------------------------------------------- | -------- |\n| `import { x } from \"missing-package\"`          | ✅ Yes   |\n| `import type { X } from \"@scope/missing\"`      | ✅ Yes   |\n| `export * from \"missing-package/subpath\"`      | ✅ Yes   |\n| `import { x } from \"declared-package/subpath\"` | ❌ No    |\n| `import { readFile } from \"node:fs/promises\"`  | ❌ No    |\n| `import { helper } from \"./helper\"`            | ❌ No    |\n| `await import(variableName)`                   | ❌ No    |\n| `require(\"missing-package\")` by default        | ❌ No    |\n\n## Error Messages\n\nThe teaching message explains:\n\n1. **What's wrong** — the imported package root is not declared in the relevant package manifest\n2. **Why** — hallucinated package imports hide dependency changes and break install/build/test/runtime paths\n3. **How to fix** — use an existing declared dependency, add the dependency intentionally, or configure an explicit allow/workspace entry\n",
     "no-incorrect-sort": "# llm-core/no-incorrect-sort\n\n📝 Disallow .sort() without a compare function, which coerces elements to strings and produces incorrect numeric ordering.\n\n💼 This rule is enabled in the 🌐 `all` config.\n\n<!-- end auto-generated rule header -->\n\n## Rule details\n\nThis rule flags `.sort()` calls that omit a compare function. JavaScript's default sort converts elements to strings before comparing, so `[10, 2, 1].sort()` produces `[1, 10, 2]` instead of `[1, 2, 10]`.\n\nFlagged patterns:\n\n```js\nnums.sort(); // no compare function\narr.sort(undefined); // undefined is not a comparator\narr.sort(void 0); // void 0 is semantically undefined\n```\n\nCorrect patterns:\n\n```js\nnums.sort((a, b) => a - b); // numeric ascending\nnames.sort((a, b) => a.localeCompare(b)); // locale-aware string\nitems.sort((a, b) => a.name.localeCompare(b.name)); // object property\n```\n\n## Scope and limitations\n\nThis rule operates on static AST analysis without type information. It:\n\n- **Skips TypedArray receivers** — `new Int32Array([...]).sort()` is correct because `%TypedArray%.prototype.sort` uses numeric comparison by default.\n- **Does not track variable types** — `const buffer = new Float64Array(data); buffer.sort();` will be flagged because the receiver is a plain identifier, not a `new` expression. For files with known TypedArray variables, disable the rule at the config level:\n  ```js\n  // eslint.config.mjs\n  export default [\n    { ignores: [\"src/buffers/*.ts\"] },\n    // or: { files: [\"src/buffers/*.ts\"], rules: { \"llm-core/no-incorrect-sort\": \"off\" } },\n  ];\n  ```\n- **May flag custom APIs** — Methods named `.sort()` on query builders, ORM cursors, or RxJS observables have no relation to `Array.prototype.sort`. Disable the rule in those scopes.\n",
     "no-inline-disable": "# llm-core/no-inline-disable\n\n📝 Disallow eslint-disable comments that suppress lint errors instead of fixing them.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, 🧹 `hygiene`, ✅ `recommended`.\n\n<!-- end auto-generated rule header -->\n\nDisallow eslint-disable comments that suppress lint errors instead of fixing them.\n\n## Rule Details\n\nLLMs frequently add `// eslint-disable-next-line` or `/* eslint-disable */` comments to silence lint errors rather than fixing the underlying code. This bypasses all other lint rules, defeating the purpose of linting.\n\nThis rule catches:\n\n- `// eslint-disable-next-line`\n- `// eslint-disable-line`\n- `/* eslint-disable ... */`\n- `/* eslint-enable ... */`\n\n## Examples\n\n### Incorrect\n\n```ts\n// eslint-disable-next-line no-unused-vars\nconst x = 1;\n\n/* eslint-disable no-console */\nconsole.log(\"debug\");\n/* eslint-enable no-console */\n\nconst y = 1; // eslint-disable-line no-unused-vars\n```\n\n### Correct\n\n```ts\n// Fix the code instead of disabling the rule\nconst x = computeValue();\nuseValue(x);\n\n// Use a proper logger instead of console\nlogger.debug(\"debug info\", { context });\n\n// If a rule doesn't apply to certain files, configure it in eslint.config.mjs\n// instead of disabling inline\n```\n\n## Why No Escape Hatches?\n\nWhen an LLM encounters a lint error, it has two options:\n\n1. Fix the code to satisfy the rule\n2. Add a disable comment to suppress the error\n\nOption 2 is always easier, so LLMs default to it. This rule removes that escape hatch, forcing the LLM to actually fix the code — which is the entire point of linting.\n\n## Error Messages\n\nError messages follow a structured teaching format designed for LLM self-correction:\n\n1. **What's wrong** — identifies the specific disable comment\n2. **Why** — explains that suppressing rules hides problems\n3. **How to fix** — three alternatives: fix the code, configure the rule properly, or refactor\n",
+    "no-known-value-widening": "# llm-core/no-known-value-widening\n\n📝 Disallow broad explicit types that discard known value evidence.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, ✅ `recommended`, ⌨️ `typescript`.\n\n<!-- end auto-generated rule header -->\n",
     "no-llm-artifacts": "# llm-core/no-llm-artifacts\n\n📝 Disallow common LLM placeholder comments and incomplete code markers that indicate skipped implementation.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, 🧹 `hygiene`, ✅ `recommended`.\n\n<!-- end auto-generated rule header -->\n\nDisallow common LLM placeholder comments and stub function bodies that indicate incomplete code generation.\n\n## Rule Details\n\nLLMs frequently save tokens by outputting placeholder comments like `// ... existing code ...`, `// TODO: implement`, or `// rest of the function remains the same` instead of writing the actual code. When applied automatically by an agent, these placeholders silently replace real logic with nothing.\n\nThis rule detects two categories of LLM artifacts:\n\n1. **Placeholder comments** — Comments that indicate skipped or abbreviated code\n2. **Stub function bodies** — Functions whose only statement is `throw new Error(\"Not implemented\")`\n\n## Examples\n\n### Incorrect\n\n```ts\n/* eslint llm-core/no-llm-artifacts: \"error\" */\n\n// ... existing code ...\nfunction processData(items: Item[]) {\n  // implementation goes here\n}\n\n// rest of the function remains the same\n\nfunction validate(input: string) {\n  throw new Error(\"Not implemented\");\n}\n\n// abbreviated for brevity\n// add error handling as needed\n```\n\n### Correct\n\n```ts\n/* eslint llm-core/no-llm-artifacts: \"error\" */\n\n// This function processes items by filtering and transforming\nfunction processData(items: Item[]) {\n  return items.filter(isValid).map(transform);\n}\n\n// TODO(#123): add caching for repeated lookups\nfunction validate(input: string) {\n  if (!input.trim()) {\n    throw new Error(\"Input must not be empty\");\n  }\n  return schema.parse(input);\n}\n```\n\n## Detected Patterns\n\n### Placeholder Comments\n\n| Pattern                | Example                                                    |\n| ---------------------- | ---------------------------------------------------------- |\n| Ellipsis placeholders  | `// ... existing code ...`, `// ...rest of the code...`    |\n| \"Remains the same\"     | `// rest of the function remains the same`                 |\n| Lazy TODO              | `// TODO: implement`, `// TODO implement`                  |\n| \"Code here\" markers    | `// add implementation here`, `// your code here`          |\n| \"As needed\" deferrals  | `// add error handling as needed`                          |\n| Brevity markers        | `// abbreviated for brevity`, `// omitted for clarity`     |\n| Reference to elsewhere | `// similar to above`, `// same as before`                 |\n| \"Continue here\"        | `// continue from here`, `// continue implementation here` |\n| \"See above/below\"      | `// see implementation above`, `// see above for details`  |\n\n### Stub Function Bodies\n\nFunctions whose only statement is `throw new Error(msg)` where `msg` matches \"not implemented\" or \"TODO: implement\" (case-insensitive).\n\n## What This Rule Allows\n\n- **Specific TODOs** — `// TODO(#123): validate input against schema` (has actionable context)\n- **Prose comments** — `// This handles the edge case where input is empty`\n- **Legitimate throws** — `throw new Error(\"XML format is not supported\")` (real error, not a placeholder)\n- **Functions with real logic** — Even if they contain a \"not implemented\" throw alongside other statements\n\n## Error Messages\n\n### `noLlmArtifact`\n\n> LLM placeholder detected: '...'. Replace with actual implementation.\n\nFired for placeholder comments. The message explains that these comments replace real logic when applied, and suggests writing specific TODOs if work must be deferred.\n\n### `notImplementedStub`\n\n> Function body is a 'not implemented' stub — write the actual implementation.\n\nFired for functions whose sole body is a \"not implemented\" throw. The message explains that these stubs pass type checks but fail at runtime.\n",
     "no-magic-numbers": "# llm-core/no-magic-numbers\n\n📝 Disallow magic numbers and enforce named constants for clarity.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, 🏆 `best-practices`, ✅ `recommended`.\n\n<!-- end auto-generated rule header -->\n\nDisallow magic numbers and enforce named constants for clarity.\n\n## Rule Details\n\nLLMs scatter hardcoded numbers throughout generated code — timeouts, limits, sizes, retry counts — without explaining what they represent. This rule forces numbers to be extracted into named constants.\n\n## Examples\n\n### Incorrect\n\n```ts\nif (retries > 5) {\n  throw new Error(\"Too many retries\");\n}\n\nsetTimeout(callback, 3000);\n\nif (file.size > 1048576) {\n  throw new Error(\"File too large\");\n}\n```\n\n### Correct\n\n```ts\nconst MAX_RETRIES = 5;\nif (retries > MAX_RETRIES) {\n  throw new Error(\"Too many retries\");\n}\n\nconst RETRY_DELAY_MS = 3000;\nsetTimeout(callback, RETRY_DELAY_MS);\n\nconst MAX_FILE_SIZE_BYTES = 1048576;\nif (file.size > MAX_FILE_SIZE_BYTES) {\n  throw new Error(\"File too large\");\n}\n```\n\n## What This Rule Allows\n\nBy default, these are permitted without named constants:\n\n- **`0`, `1`, `-1`, `2`** — ubiquitous in loops, checks, and arithmetic\n- **Array indexes** — `items[3]` (configurable)\n- **Default parameter values** — `function retry(attempts = 3)` (configurable)\n- **Enum initializers** — `enum Status { Active = 10 }` (configurable)\n- **Type contexts** — type-level numeric literals\n- **Const declarations** — `const MAX = 5` (this IS the named constant)\n\n## Options\n\n### `ignore`\n\nNumbers to allow without named constants. Default: `[0, 1, -1, 2]`.\n\n### `ignoreArrayIndexes`\n\nAllow numbers as computed array/object indexes. Default: `true`.\n\n### `ignoreDefaultValues`\n\nAllow numbers as default parameter values. Default: `true`.\n\n### `ignoreEnums`\n\nAllow numbers in enum initializers. Default: `true`.\n\n### `skipTestFiles`\n\nWhether to skip test files (`.test.ts`, `.spec.ts`, etc.). Default: `true`.\n\nTest files are full of numeric literals in assertions — `expect(sum(2, 3)).toBe(5)` — where extracting to constants hurts readability.\n\n### `ignoreObjectProperties`\n\nAllow numbers used as object literal property values. Default: `false`.\n\nUseful for data files like pricing tables, model config maps, and HTTP status maps where the values **are** the data:\n\n```ts\n// With ignoreObjectProperties: true — no errors\nconst PRICING = { basic: 9.99, pro: 29.99, enterprise: 99.99 };\nconst HTTP_STATUS = { BAD_REQUEST: 400, NOT_FOUND: 404 };\n```\n\nNumbers outside object literals are still flagged even with this option enabled. This only applies to object literal property values (`ObjectExpression`) — destructuring defaults like `function f({ timeout = 5000 }) {}` are still flagged.\n\n```json\n{\n  \"llm-core/no-magic-numbers\": [\n    \"error\",\n    {\n      \"ignore\": [0, 1, -1, 2, 100],\n      \"ignoreArrayIndexes\": true,\n      \"ignoreDefaultValues\": true,\n      \"ignoreEnums\": true,\n      \"skipTestFiles\": true,\n      \"ignoreObjectProperties\": true\n    }\n  ]\n}\n```\n\n## Error Messages\n\nError messages follow a structured teaching format designed for LLM self-correction:\n\n1. **What's wrong** — identifies the specific magic number\n2. **Why** — explains that readers can't tell what the number represents\n3. **How to fix** — shows a before/after extraction to a named constant using the actual number\n",
+    "no-object-parameters": "# llm-core/no-object-parameters\n\n📝 Disallow broad object types in function parameters.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, ✅ `recommended`, ⌨️ `typescript`.\n\n<!-- end auto-generated rule header -->\n",
     "no-redundant-comments": "# llm-core/no-redundant-comments\n\n📝 Disallow comments that merely narrate the next line of code without adding intent.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, 🧹 `hygiene`, ✅ `recommended`.\n\n<!-- end auto-generated rule header -->\n\nDisallow comments that merely narrate adjacent code instead of explaining intent, constraints, or non-obvious behavior.\n\n## Rule Details\n\nLLMs often add conversational comments that describe the next line of code in plain English: `// Validate the input`, `// Return the result`, or `// Check if the user exists`. These comments do not preserve design intent. They make files noisier and train future edits to keep narrating implementation mechanics instead of documenting why the code exists.\n\nThis rule reports narrow, high-confidence cases where a line comment immediately precedes code that already says the same thing.\n\n## Examples\n\n### Incorrect\n\n```ts\n// Validate the user input\nvalidateUser(input);\n\n// Return the result\nreturn result;\n\n// Check if the user exists\nif (user) {\n  activateUser(user);\n}\n\n// Set the user name\nuser.name = name;\n```\n\n### Correct\n\n```ts\n// Reject webhook payloads before persistence because they are untrusted\nvalidateWebhookPayload(payload);\n\n// Only return cached data when the caller accepts stale results\nreturn cache.get(key);\n\n// This branch handles retry after a 429 response\nif (shouldRetry(response)) {\n  retry();\n}\n```\n\n## What Counts as a Redundant Comment\n\n| Pattern                                                        | Triggers? |\n| -------------------------------------------------------------- | --------- |\n| `// Return the result` before `return result`                  | Yes       |\n| `// Validate the user input` before `validateUser(input)`      | Yes       |\n| `// Set the user name` before `user.name = name`               | Yes       |\n| `// Validate before persisting because payloads are untrusted` | No        |\n| `// TODO(#123): add request tracing`                           | No        |\n| JSDoc API documentation                                        | No        |\n| ESLint or TypeScript directive comments                        | No        |\n\n## Error Messages\n\nThe error message teaches:\n\n1. **What's wrong** -- the comment narrates adjacent code without adding intent\n2. **Why** -- conversational comments are common LLM noise and reduce maintainability\n3. **How to fix** -- delete the comment or rewrite it to explain why, constraints, or tradeoffs\n",
     "no-redundant-logic": "# llm-core/no-redundant-logic\n\n📝 Disallow redundant boolean logic and unnecessary control flow patterns.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, ✅ `recommended`, 🎨 `style`.\n\n💡 This rule is manually fixable by [editor suggestions](https://eslint.org/docs/latest/use/core-concepts#rule-suggestions).\n\n<!-- end auto-generated rule header -->\n\nFlags four patterns where LLMs produce verbose-but-correct boolean logic that can be simplified without changing semantics.\n\n## Rule Details\n\n### Pattern 1 — Redundant boolean comparison\n\nExplicit `=== true`, `!== true`, `=== false`, or `!== false` comparisons on an expression that already evaluates to a boolean.\n\nOnly strict equality (`===`/`!==`) is flagged. Loose equality (`==`/`!=`) has different truthy/falsy semantics and is intentionally excluded.\n\n> **Known limitation:** This rule does not use type information. If the compared expression is a union type (e.g., `string | boolean`), the `=== true` comparison may be intentional type narrowing, not a redundant check. Disable the rule on that line if this applies.\n\n#### Incorrect\n\n```ts\nif (isActive === true) {\n}\nif (isValid !== true) {\n}\nif (hasPermission === false) {\n}\nwhile (running !== false) {}\n```\n\n#### Correct\n\n```ts\nif (isActive) {\n}\nif (!isValid) {\n}\nif (!hasPermission) {\n}\nwhile (running) {}\n```\n\n### Pattern 2 — Unnecessary else after return/throw\n\nAn `else` block that follows an `if` block ending in `return` or `throw` is unreachable via fall-through. The `else` can be removed and its body placed at the outer scope.\n\nOnly flags when:\n\n- The `if` consequent ends with `return` or `throw`\n- The `else` is a simple block (single `return` or `throw`), not an `else if` chain\n- Pattern 4 does not apply to the same node (to avoid double-reporting)\n\n#### Incorrect\n\n```ts\nfunction getLabel(status: string): string {\n  if (status === \"active\") {\n    return \"Active\";\n  } else {\n    return \"Inactive\";\n  }\n}\n```\n\n#### Correct\n\n```ts\nfunction getLabel(status: string): string {\n  if (status === \"active\") {\n    return \"Active\";\n  }\n  return \"Inactive\";\n}\n```\n\n### Pattern 3 — Ternary returning boolean literals\n\nA ternary of the form `condition ? true : false` or `condition ? false : true` is identical to the condition (or its negation).\n\n#### Incorrect\n\n```ts\nconst isEligible = age >= 18 ? true : false;\nconst isBlocked = isAdmin ? false : true;\n```\n\n#### Correct\n\n```ts\nconst isEligible = age >= 18;\nconst isBlocked = !isAdmin;\n```\n\n### Pattern 4 — If/else returning or assigning boolean literals\n\nWhen both branches of an `if`/`else` exclusively `return` or assign the same variable to a boolean literal, the entire construct reduces to a single expression.\n\n#### Incorrect\n\n```ts\nif (items.length > 0) {\n  return true;\n} else {\n  return false;\n}\n\nlet isValid;\nif (age >= 18) {\n  isValid = true;\n} else {\n  isValid = false;\n}\n```\n\n#### Correct\n\n```ts\nreturn items.length > 0;\nconst isValid = age >= 18;\n```\n\n## Out of Scope\n\n- De Morgan transformations (`!(a && b)` → `!a || !b`) — too subjective\n- `!!value` double-negation — intentional type-coercion pattern\n- Loose equality (`== true`) — different semantics\n- Complex boolean simplification — requires symbolic reasoning\n\n## Error Messages\n\nEach pattern has a distinct `messageId`:\n\n| Pattern | `messageId`                  |\n| ------- | ---------------------------- |\n| 1       | `redundantBooleanComparison` |\n| 2       | `unnecessaryElse`            |\n| 3       | `ternaryBooleanLiteral`      |\n| 4       | `ifElseBooleanLiteral`       |\n\nAll four messages follow the standard what/why/how format.\n\n## Suggestions\n\nAll four patterns provide suggestions (not auto-fixes) — the transformations are safe but the developer should confirm intent before applying.\n",
     "no-swallowed-errors": "# llm-core/no-swallowed-errors\n\n📝 Disallow catch blocks that only log to console and swallow the error.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, 🏆 `best-practices`, ✅ `recommended`.\n\n<!-- end auto-generated rule header -->\n\nDisallow `catch` blocks that only call `console.log`, `console.warn`, `console.error`, or `console.debug` without rethrowing, returning, or delegating the failure to a real error handler.\n\n## Rule Details\n\nLLMs often generate placeholder error handling like `catch (error) { console.error(error); }`. That looks intentional, but it still swallows the failure: callers do not see an error, control flow continues, and production systems quietly drift into bad state.\n\nThis rule focuses on the narrow, high-signal case where a non-empty `catch` block contains **only console logging calls**. It deliberately does **not** overlap with `no-empty-catch` — truly empty or comment-only blocks belong to that rule.\n\n## Examples\n\n### Incorrect\n\n```ts\ntry {\n  await processOrder(order);\n} catch (error) {\n  console.error(error);\n}\n\ntry {\n  await loadConfig();\n} catch (error) {\n  console.warn(\"Config failed\", error);\n  console.debug(error);\n}\n```\n\n### Correct\n\n```ts\ntry {\n  await processOrder(order);\n} catch (error) {\n  throw new Error(\"Failed to process order\", { cause: error });\n}\n\ntry {\n  return await loadConfig();\n} catch (error) {\n  logger.error(\"Config load failed\", { error });\n  return null;\n}\n\ntry {\n  await publishEvent(event);\n} catch (error) {\n  Sentry.captureException(error);\n}\n\ntry {\n  await performWork();\n} catch (error) {\n  console.error(error);\n  throw error;\n}\n```\n\n## What This Rule Flags\n\n| Catch body contents                             | Flagged? |\n| ----------------------------------------------- | -------- |\n| `console.error(error)`                          | ✅ Yes   |\n| `console.log(error); console.warn(\"failed\", e)` | ✅ Yes   |\n| `console.error(error); throw error;`            | ❌ No    |\n| `console.error(error); handleError(error);`     | ❌ No    |\n| `handleError(error)`                            | ❌ No    |\n| empty `catch {}`                                | ❌ No    |\n\n## Why Console-Only Handling Is Risky\n\n- Logging alone does not change control flow.\n- Callers cannot recover because they never learn the operation failed.\n- Background tasks can keep running with partial or invalid state.\n- The code looks \"handled\" in review even though the failure was dropped.\n\n## Error Messages\n\nThe teaching message explains:\n\n1. **What's wrong** — the catch block only logs and swallows the error\n2. **Why** — execution continues as if nothing failed\n3. **How to fix** — rethrow, return an explicit fallback, or delegate to a real handler such as a logger or error tracker\n",
     "no-type-assertion-any": "# llm-core/no-type-assertion-any\n\n📝 Disallow type assertions to `any` that bypass TypeScript's type safety.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, ✅ `recommended`, ⌨️ `typescript`.\n\n<!-- end auto-generated rule header -->\n\nDisallow type assertions to `any` (`as any` and `<any>` syntax).\n\n## Rule Details\n\nLLMs reach for `as any` as the default escape hatch when types don't align. This completely disables TypeScript's type checking at the assertion site and for every downstream usage of the value. It is the single most common way generated code defeats type safety.\n\n## Examples\n\n### Incorrect\n\n```ts\n// Bypasses all type checking\nconst result = data as any;\n\n// Silently accesses potentially nonexistent property\n(response as any).body;\n\n// Hides a type incompatibility\nprocess(input as any);\n\n// Angle bracket syntax (same problem)\nconst value = <any>data;\n```\n\n### Correct\n\n```ts\n// Assert to a specific known type\nconst result = data as ExpectedType;\n\n// Double assertion through unknown (explicit escape hatch)\nconst result = data as unknown as ExpectedType;\n\n// Use unknown and narrow with type guards\nfunction process(data: unknown) {\n  if (typeof data === \"string\") {\n    handle(data); // TypeScript knows it's a string\n  }\n}\n\n// Properly type the response\nconst body = (response as ResponseWithBody).body;\n```\n\n## What This Rule Catches\n\nThe rule flags both forms of type assertion to `any`:\n\n1. **`as any`** — `value as any`\n2. **`<any>`** — `<any>value` (angle bracket syntax)\n\n### What This Rule Does NOT Catch\n\n- `any` in type annotations (`const x: any`) — use `@typescript-eslint/no-explicit-any` for this\n- `any` in generic type arguments (`Array<any>`) — use `llm-core/no-any-in-generic` for this\n- Implicit `any` from missing type annotations — use `@typescript-eslint/no-unsafe-*` rules for this\n\n## Error Messages\n\nThe error message teaches the proper alternative:\n\n1. **What's wrong** — the assertion bypasses all type checking\n2. **Why** — `any` disables TypeScript's safety and leaks into downstream code\n3. **How to fix** — assert to a specific type, or use `unknown` with type guards\n",
     "no-type-system-bypass": "# llm-core/no-type-system-bypass\n\n📝 Disallow broad TypeScript escape hatches that hide type errors instead of fixing them.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, ✅ `recommended`, ⌨️ `typescript`.\n\n<!-- end auto-generated rule header -->\n\nDisallow broad TypeScript escape hatches that silence the compiler instead of fixing the type model.\n\n## Rule Details\n\nLLMs commonly resolve TypeScript errors by adding suppression comments, double assertions, non-null assertions, or explicit `any` annotations. These patterns make code compile while removing the compiler evidence that would have caught a real bug.\n\nThis rule complements narrower rules such as `no-type-assertion-any`, `no-any-in-generic`, and `prefer-unknown-in-catch` by catching additional high-risk bypasses:\n\n- `@ts-ignore`\n- unexplained or generic `@ts-expect-error`\n- double assertions through `unknown`\n- non-null assertions (`!`)\n- explicit `any` annotations outside `as any` assertions and catch parameters\n\n## Examples\n\n### Incorrect\n\n```ts\n// @ts-ignore\ncallLibrary({ experimental: true });\n\n// @ts-expect-error\ncallLibrary({ experimental: true });\n\nconst user = data as unknown as User;\nconst legacyUser = <User>(<unknown>data);\nconst name = user!.profile.name;\nlet payload: any = loadPayload();\nfunction handle(payload: any): void {\n  process(payload);\n}\n```\n\n### Correct\n\n```ts\n// @ts-expect-error TS2345: upstream package types reject documented runtime option\ncallLibrary({ experimental: true });\n\nconst user = UserSchema.parse(data);\nif (!user.profile) {\n  throw new Error(\"User profile is required\");\n}\n\nconst payload: unknown = loadPayload();\nif (isPayload(payload)) {\n  process(payload);\n}\n```\n\n## Relationship to Nearby Rules\n\n| Existing rule             | What it covers                     | This rule avoids/reinforces                                |\n| ------------------------- | ---------------------------------- | ---------------------------------------------------------- |\n| `no-type-assertion-any`   | `value as any` and `<any>value`    | Does not duplicate those assertion reports                 |\n| `no-any-in-generic`       | `Array<any>`, `Promise<any>`, etc. | Does not duplicate generic type argument reports           |\n| `prefer-unknown-in-catch` | `catch (error: any)`               | Skips catch parameters so the focused rule can report them |\n\n## Error Messages\n\nThe error messages teach:\n\n1. **What's wrong** -- the code suppresses or bypasses TypeScript's checks\n2. **Why** -- LLMs often use these patterns to hide compiler errors rather than resolving contracts\n3. **How to fix** -- use specific types, `unknown` plus narrowing, runtime guards, schemas, or justified `@ts-expect-error` comments\n",
     "no-unbounded-promise-all": "# llm-core/no-unbounded-promise-all\n\n📝 Disallow Promise.all fan-out over arbitrary collections without an explicit concurrency bound.\n\n💼 This rule is enabled in the 🌐 `all` config.\n\n<!-- end auto-generated rule header -->\n\nDisallow `Promise.all(collection.map(...))` and `Promise.allSettled(collection.map(...))` fan-out over arbitrary collections unless the work is explicitly bounded.\n\nLLM-generated code often reaches for `Promise.all(items.map(...))` as a generic performance improvement. That is safe for small fixed tuples, but dangerous for user-sized arrays, database records, API pages, queues, and other arbitrary collections because it starts all work at once.\n\n## Rule Details\n\nThis rule reports obvious unbounded Promise fan-out patterns:\n\n- `Promise.all(items.map(...))`\n- `Promise.allSettled(items.map(...))`\n- `Promise.all(Array.from(items).map(...))`\n- `const jobs = items.map(...); await Promise.all(jobs)`\n\nIt intentionally allows common bounded alternatives:\n\n- small literal arrays such as `Promise.all([loadUser(), loadSettings()])`\n- `.map(...)` over literal tuples\n- callbacks wrapped in a limiter such as `limit(() => work(item))`\n- explicit batching, for example a `for...of` loop over `chunks(items, 10)`\n- sequential `for...of` loops when backpressure or ordering matters\n\n## Examples\n\n### Incorrect\n\n```ts\n// Starts one email send per user immediately.\nawait Promise.all(users.map((user) => sendEmail(user)));\n```\n\n```ts\n// allSettled still starts every item at once.\nawait Promise.allSettled(records.map((record) => processRecord(record)));\n```\n\n```ts\n// Storing the mapped promises does not make the fan-out bounded.\nconst jobs = Array.from(ids).map((id) => fetchUser(id));\nawait Promise.all(jobs);\n```\n\n### Correct\n\n```ts\n// Small fixed fan-out is bounded by the literal array size.\nconst [user, settings] = await Promise.all([\n  fetchUser(userId),\n  fetchSettings(userId),\n]);\n```\n\n```ts\n// Explicit concurrency limit.\nconst limit = pLimit(5);\nawait Promise.all(users.map((user) => limit(() => sendEmail(user))));\n```\n\n```ts\n// Explicit batching.\nfor (const batch of chunks(users, 10)) {\n  await Promise.all(batch.map((user) => sendEmail(user)));\n}\n```\n\n```ts\n// Sequential backpressure.\nfor (const user of users) {\n  await sendEmail(user);\n}\n```\n\n## What Counts as Unbounded Fan-Out\n\n| Pattern                                                                               | Triggers? |\n| ------------------------------------------------------------------------------------- | --------- |\n| `Promise.all(users.map(sendEmail))`                                                   | Yes       |\n| `Promise.allSettled(items.map(syncItem))`                                             | Yes       |\n| `Promise.all(Array.from(ids).map(fetchUser))`                                         | Yes       |\n| `const jobs = users.map(sendEmail); await Promise.all(jobs)`                          | Yes       |\n| `Promise.all([fetchUser(id), fetchSettings(id)])`                                     | No        |\n| `Promise.all([1, 2, 3].map(fetchUser))`                                               | No        |\n| `Promise.all(users.map((user) => limit(() => sendEmail(user))))`                      | No        |\n| `for (const batch of chunks(users, 10)) { await Promise.all(batch.map(sendEmail)); }` | No        |\n\n## Error Messages\n\nThe error message teaches:\n\n1. **What's wrong** — a collection is being fanned out without a concurrency bound\n2. **Why** — large inputs can overload memory, APIs, or database pools\n3. **How to fix** — use `p-limit`, batching, or a sequential loop depending on the intended backpressure\n",
+    "no-unknown-parameters": "# llm-core/no-unknown-parameters\n\n📝 Disallow explicit unknown function parameters except error-cause enrichment.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, ✅ `recommended`, ⌨️ `typescript`.\n\n<!-- end auto-generated rule header -->\n",
+    "no-unknown-returns": "# llm-core/no-unknown-returns\n\n📝 Disallow function return contracts that expose unknown.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, ✅ `recommended`, ⌨️ `typescript`.\n\n<!-- end auto-generated rule header -->\n",
+    "no-unknown-type-aliases": "# llm-core/no-unknown-type-aliases\n\n📝 Disallow named type aliases that conceal unknown.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, ✅ `recommended`, ⌨️ `typescript`.\n\n<!-- end auto-generated rule header -->\n",
     "no-unsafe-array-access": "# llm-core/no-unsafe-array-access\n\n📝 Require a non-empty array guard before reading the first or last element.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, 🏆 `best-practices`, ✅ `recommended`.\n\n<!-- end auto-generated rule header -->\n\nRequire an explicit non-empty-array guard before reading the first or last element from an array.\n\nLLM-generated code often handles the happy path (`items[0]`, `items[items.length - 1]`, or `const [first] = items`) but forgets the empty-array edge case. That produces `undefined`, which frequently becomes a follow-on crash when code immediately reads properties or calls methods on the value.\n\n## Rule Details\n\nThis rule reports narrow, syntactic array access patterns that read a required element without proving that the array is non-empty:\n\n- `items[0]`\n- `items[items.length - 1]`\n- `const [first] = items`\n- `const [first, ...rest] = items`\n\nThe rule allows common guard patterns in the same control-flow path:\n\n- `if (items.length > 0) { items[0] }`\n- `if (items.length) { const [first] = items }`\n- `if (items.length === 0) return; items[0]`\n- `items.length !== 0 ? items[0] : fallback`\n- `items.length && items[0]`\n\nIt also allows patterns that make the empty case explicit, such as destructuring defaults (`const [first = fallback] = items`) and optional element access (`items?.[0]`). Dynamic indexes such as `items[index]` are outside this rule's first/last-element scope.\n\n## Examples\n\n### Incorrect\n\n```ts\n// Empty arrays produce undefined, then the property read crashes.\nconst firstId = items[0].id;\n```\n\n```ts\n// Empty arrays make length - 1 equal -1, so this reads undefined.\nconst latest = items[items.length - 1];\n```\n\n```ts\n// The first element may be undefined when results is empty.\nconst [head, ...tail] = results;\n```\n\n### Correct\n\n```ts\n// Guard before reading the first element.\nconst first = items.length > 0 ? items[0] : undefined;\n```\n\n```ts\n// Early-return guards make the later access safe.\nif (items.length === 0) {\n  return undefined;\n}\n\nconst latest = items[items.length - 1];\n```\n\n```ts\n// Destructuring defaults make the empty-array behavior explicit.\nconst [first = fallback] = items;\n```\n\n```ts\n// Optional access intentionally returns undefined for absent values.\nconst maybeFirst = items?.[0];\n```\n\n## What Counts as Unsafe Array Access\n\n| Pattern                                     | Triggers? |\n| ------------------------------------------- | --------- |\n| `items[0]`                                  | Yes       |\n| `items[items.length - 1]`                   | Yes       |\n| `const [first] = items`                     | Yes       |\n| `const [first = fallback] = items`          | No        |\n| `if (items.length > 0) { items[0] }`        | No        |\n| `if (items.length === 0) return; items[0]`  | No        |\n| `items.length !== 0 ? items[0] : undefined` | No        |\n| `items?.[0]`                                | No        |\n| `items[index]`                              | No        |\n| `[\"fallback\"][0]`                           | No        |\n\n## Error Messages\n\nThe error message teaches:\n\n1. **What's wrong** — the code reads a first or last array element without a non-empty guard\n2. **Why** — empty arrays return `undefined`, which often causes crashes in follow-on code\n3. **How to fix** — add a length guard, early-return on empty arrays, or provide an explicit fallback/default\n",
+    "no-unsafe-dictionary-type": "# llm-core/no-unsafe-dictionary-type\n\n📝 Disallow dictionary contracts whose values use unsafe escape-hatch types.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, ✅ `recommended`, ⌨️ `typescript`.\n\n<!-- end auto-generated rule header -->\n",
     "no-weak-randomness-for-secrets": "# llm-core/no-weak-randomness-for-secrets\n\n📝 Disallow weak or predictable randomness when creating security-sensitive values.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, 🏆 `best-practices`, ✅ `recommended`.\n\n<!-- end auto-generated rule header -->\n\nRequire cryptographic randomness when creating security-sensitive values such as tokens, sessions, nonces, salts, reset codes, API keys, and credentials.\n\nLLM-generated code often reaches for `Math.random()`, timestamps, or counters because the result looks unique in demos. Those values are predictable and can make authentication or recovery flows guessable.\n\n## Rule Details\n\nThis rule reports weak or predictable sources when the target name is security-sensitive:\n\n- variable declarations such as `const token = Math.random()`\n- assignments such as `user.apiKey = Math.random()`\n- object properties such as `{ secret: Date.now().toString(36) }`\n- sensitive generator functions such as `function generateToken() { return Math.random() }` or `const generateToken = () => Math.random()`\n\nThe default sensitive-name pattern covers `token`, `secret`, `password`, `sessionId`, `apiKey`, `nonce`, `salt`, `resetCode`, `verificationCode`, `authCode`, and `credential`. Non-security randomness is allowed by default so UI jitter, sampling, visual effects, and tests can still use `Math.random()`.\n\n## Examples\n\n### Incorrect\n\n```ts\n// Math.random is predictable and should not create auth tokens.\nconst token = Math.random().toString(36).slice(2);\n```\n\n```ts\n// Timestamp-plus-random session IDs are still guessable.\nconst sessionId = `${Date.now()}-${Math.random()}`;\n```\n\n```ts\n// Short reset codes from Math.random are easy to brute force.\nconst passwordResetCode = Math.floor(Math.random() * 1_000_000).toString();\n```\n\n```ts\n// API keys must not use weak randomness.\nuser.apiKey = Math.random().toString(36);\n```\n\n### Correct\n\n```ts\n// Node: use cryptographic random bytes for token material.\nimport { randomBytes } from \"node:crypto\";\n\nconst token = randomBytes(32).toString(\"hex\");\n```\n\n```ts\n// Node: randomUUID is appropriate for session identifiers.\nimport { randomUUID } from \"node:crypto\";\n\nconst sessionId = randomUUID();\n```\n\n```ts\n// Browser: use crypto.getRandomValues for random bytes.\nconst bytes = new Uint8Array(32);\ncrypto.getRandomValues(bytes);\nconst resetCode = encode(bytes);\n```\n\n```ts\n// Non-security randomness is still allowed by default.\nconst displayJitter = Math.random() * 100;\n```\n\n## What Counts as Weak Randomness for Secrets\n\n| Pattern                                              | Triggers? |\n| ---------------------------------------------------- | --------- |\n| `const token = Math.random().toString(36)`           | Yes       |\n| `const sessionId = Date.now() + \"-\" + Math.random()` | Yes       |\n| `` const nonce = `${Date.now()}-${counter++}` ``     | Yes       |\n| `user.apiKey = Math.random().toString(36)`           | Yes       |\n| `{ secret: new Date().getTime().toString(36) }`      | Yes       |\n| `function generateToken() { return Math.random() }`  | Yes       |\n| `const generateToken = () => Math.random()`          | Yes       |\n| `const token = randomBytes(32).toString(\"hex\")`      | No        |\n| `const sessionId = randomUUID()`                     | No        |\n| `crypto.getRandomValues(bytes)`                      | No        |\n| `const displayJitter = Math.random() * 100`          | No        |\n\n## Options\n\n### `sensitiveNamePattern`\n\nOverride the default case-insensitive sensitive-name regular expression.\n\n```ts\n{\n  \"llm-core/no-weak-randomness-for-secrets\": [\n    \"error\",\n    { \"sensitiveNamePattern\": \"(token|inviteCode|apiKey)\" }\n  ]\n}\n```\n\n### `allowMathRandomForNonSensitiveNames`\n\nDefaults to `true`. Set to `false` to report `Math.random()` even when the target name is not security-sensitive.\n\n### `checkFunctionReturnNames`\n\nDefaults to `true`. Set to `false` to skip checks for sensitive function declarations or function-valued assignments such as `generateToken()` returning weak randomness.\n\n## Error Messages\n\nThe error message teaches:\n\n1. **What's wrong** — weak randomness is being used for a security-sensitive value\n2. **Why** — predictable values compromise sessions, reset flows, API keys, nonces, and similar secrets\n3. **How to fix** — use `crypto.randomBytes`, `crypto.randomUUID`, or browser `crypto.getRandomValues`\n",
     "no-widen-then-assert": "# llm-core/no-widen-then-assert\n\n📝 Disallow declaring a variable's type wider than its value, then asserting it back to the narrow type.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, ✅ `recommended`, ⌨️ `typescript`.\n\n<!-- end auto-generated rule header -->\n\nDisallow declaring a variable's type wider than its value, then asserting it back to the narrow type.\n\n## Rule Details\n\nLLMs sometimes resolve an unrelated type error by loosening a variable's declared type to `T | undefined` or `T | null`, then forcing it back to `T` with an `as` assertion or `!` at the point of use. Neither step fixes anything: the initializer never produced a nullish value, the variable is never reassigned, and the assertion just discards the annotation the code added a moment earlier. The result compiles, but it's a type contract that was never true in either direction.\n\nThis rule flags that specific round trip. It fires only when all of the following hold:\n\n- The variable is declared with an explicit `T | undefined`, `T | null`, or `T | null | undefined` annotation, where `T` is not itself `any`/`unknown`.\n- The variable is declared with `let` or `const` — never `var` (see Known Limitations).\n- The initializer is a provably concrete value — a literal, template literal, object/array literal, `new` expression, or function/arrow expression — never a call whose result could genuinely be nullish.\n- The variable is never reassigned anywhere in its scope.\n- A later read of the variable is forced back to `T` via `as T`, `<T>`, or non-null `!`.\n\nIt intentionally does not use TypeScript's type checker, so it works without a `parserOptions.project` setup, matching every other rule in this plugin. It also intentionally skips `any`/`unknown` widening — including when `any`/`unknown` is the sole non-nullish union member (`T | undefined` where `T` is `any`/`unknown` isn't a real narrowing; TypeScript already collapses `unknown | undefined` to `unknown`) — that pattern is already covered by `no-type-system-bypass`.\n\n## Known Limitations\n\n- **`var` is out of scope entirely.** `var` is function/module-scoped, not block-scoped, so resolving its declaring scope from a nested declarator can miss its binding, and hoisting means a read before the declaration can be genuinely `undefined` at runtime — something `let`/`const` (which throw via the temporal dead zone) can't produce. Rather than partially support `var` with different guarantees than `let`/`const`, the rule skips it.\n- **Type matching is textual, not resolved.** Because there's no type checker, the concrete type is matched by comparing source text. In the rare case where the same type name is shadowed by a different, incompatible declaration between the variable's scope and the assertion site (e.g. a locally redeclared `type T` inside a nested function), the rule can match text that doesn't actually refer to the same type. This is an accepted, narrow tradeoff — full resolution would require the type checker, which would break this rule's zero-config design.\n\n## Examples\n\n### Incorrect\n\n```ts\nlet name: string | undefined = \"Alice\";\nconsole.log(name as string);\n\nlet count: number | undefined = 0;\nuse(count!);\n```\n\n### Correct\n\n```ts\n// The type matches the value — no widening was added.\nconst name: string = \"Alice\";\nconsole.log(name);\n\n// The value is honestly nullable and handled with a check.\nlet name: string | undefined = maybeGetName();\nconsole.log(name ?? \"unknown\");\n\n// The variable is reassigned, so the wider type is doing real work.\nlet name: string | undefined = \"Alice\";\nname = maybeClearName();\nconsole.log(name as string);\n```\n\n## What Counts as Widen-Then-Assert\n\n| Pattern                                                                                | Triggers? |\n| -------------------------------------------------------------------------------------- | --------- |\n| `let x: T \\| undefined = <literal>; ...; x as T;`                                      | Yes       |\n| `let x: T \\| null = <literal>; ...; x!;`                                               | Yes       |\n| `let x: T \\| undefined = <literal>; ...; x = other(); ...; x as T;` (reassigned)       | No        |\n| `let x: T \\| undefined = someCall(); ...; x as T;` (initializer not provably concrete) | No        |\n| `let x: T \\| undefined = <literal>; ...; x ?? fallback;` (no assertion)                | No        |\n| `let x: T \\| any = <literal>; ...; x as T;` (`any`/`unknown` widening)                 | No        |\n| `let x: unknown \\| undefined = <literal>; ...; x as unknown;` (`any`/`unknown` is `T`) | No        |\n| `var x: T \\| undefined = <literal>; ...; x as T;` (`var`, any nesting)                 | No        |\n\n## Relationship to Nearby Rules\n\n| Existing rule           | What it covers                                    | This rule avoids/reinforces                                         |\n| ----------------------- | ------------------------------------------------- | ------------------------------------------------------------------- |\n| `no-type-system-bypass` | `any` widening, `as unknown as T`, `!`, ts-ignore | Skips `any`/`unknown` widening so the two rules don't double-report |\n| `no-type-assertion-any` | `value as any`                                    | Only concerns assertions back to the original concrete type         |\n\n## Error Messages\n\nThe error message teaches:\n\n1. **What's wrong** -- the variable was declared wider than its value, then forced back\n2. **Why** -- the assertion fabricates evidence the compiler never had; the widening never reflected a real possibility\n3. **How to fix** -- remove the added nullish member from the declaration, or handle real nullability with a check instead of an assertion\n",
     "prefer-early-return": "# llm-core/prefer-early-return\n\n📝 Enforce guard clauses (early returns) instead of wrapping function bodies in a single if statement.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, ✅ `recommended`, 🎨 `style`.\n\n<!-- end auto-generated rule header -->\n\nEnforce guard clauses (early returns) instead of wrapping function bodies in a single if statement.\n\n## Rule Details\n\nLLMs consistently wrap entire function bodies in a single `if` statement instead of using guard clauses. This creates unnecessary nesting and obscures the main logic. Guard clauses handle edge cases at the top of the function, leaving the \"happy path\" at the base indentation level.\n\nThis rule complements `max-nesting-depth` by teaching the specific pattern that prevents deep nesting in the first place.\n\n## Examples\n\n### Incorrect\n\n```ts\n// Entire body wrapped in if — should use guard clause\nfunction process(data: string) {\n  if (isValid(data)) {\n    transform(data);\n    save(data);\n  }\n}\n\n// If/else where else is a simple throw — invert to guard\nfunction validate(input: string) {\n  if (input.length > 0) {\n    parse(input);\n    process(input);\n  } else {\n    throw new Error(\"empty input\");\n  }\n}\n\n// Arrow function with wrapped body\nconst fetchUser = async (id: string) => {\n  if (id) {\n    const user = await db.find(id);\n    return user;\n  }\n};\n```\n\n### Correct\n\n```ts\n// Guard clause — early return for the edge case\nfunction process(data: string) {\n  if (!isValid(data)) return;\n  transform(data);\n  save(data);\n}\n\n// Guard clause — early throw\nfunction validate(input: string) {\n  if (input.length === 0) throw new Error(\"empty input\");\n  parse(input);\n  process(input);\n}\n\n// Guard clause in arrow function\nconst fetchUser = async (id: string) => {\n  if (!id) return;\n  const user = await db.find(id);\n  return user;\n};\n```\n\n## What This Rule Catches\n\nThe rule flags functions where:\n\n1. The **only statement** in the function body is an `if` statement\n2. The `if` body contains at least `minBodyStatements` statements (default: 2)\n3. There is **no else**, or the else is a **single return/throw**\n\n### What This Rule Does NOT Catch\n\n- Functions with multiple statements before the `if` (only the wrapping pattern)\n- `if/else` where both branches have substantial logic (genuine branching)\n- `if/else if` chains (multiple conditions, not a simple guard)\n- `if` bodies with fewer statements than the `minBodyStatements` threshold\n\n## Options\n\n### `minBodyStatements`\n\nMinimum number of statements in the `if` body to trigger the rule. Default: `2`.\n\nSetting this to `1` catches even simple cases like `if (x) { doSomething(); }`. Setting it higher reduces noise for shorter functions.\n\n```json\n{ \"llm-core/prefer-early-return\": [\"error\", { \"minBodyStatements\": 3 }] }\n```\n\n## Error Messages\n\nThe error message teaches the guard clause pattern:\n\n1. **What's wrong** — the function body is wrapped in a single `if`\n2. **Why** — unnecessary nesting obscures the main logic\n3. **How to fix** — concrete before/after showing the inverted condition with early return\n",
@@ -43,5 +50,5 @@ export const embeddedDocs = {
     "throw-error-objects": "# llm-core/throw-error-objects\n\n📝 Disallow throwing non-Error values such as strings, template literals, plain objects, or arrays.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, 🏆 `best-practices`, ✅ `recommended`.\n\n<!-- end auto-generated rule header -->\n\nDisallow throwing string literals, template literals, plain objects, arrays, or other non-Error values.\n\n## Rule Details\n\nLLMs often generate `throw \"something went wrong\"` or `throw { code: 404 }` as a shorthand. These patterns lose the stack trace, break `e instanceof Error` checks, and cause silent failures in logging and error-reporting tools that expect an `Error` object.\n\nThis is a syntax-only rule and does not require type information. It allows `throw` of identifiers, member expressions, call expressions, and `new` expressions because it cannot statically prove their type — those forms are assumed to be Error instances or safe wrappers.\n\n## Examples\n\n### Incorrect\n\n```ts\n// String literal — no stack trace\nthrow \"something went wrong\";\n\n// Template literal — still no stack trace\nthrow `failed to connect to ${host}`;\n\n// Plain object — instanceof Error fails, .stack is undefined\nthrow { code: 404, message: \"not found\" };\n\n// Array — completely wrong type\nthrow [\"validation\", \"failed\"];\n\n// Number\nthrow 500;\n```\n\n### Correct\n\n```ts\n// Error instance — stack trace, instanceof, .message all work\nthrow new Error(\"something went wrong\");\n\n// Error subclass\nthrow new ValidationError(\"invalid input\");\n\n// Identifier — may hold an Error, allowed\nthrow err;\n\n// Call expression — assumed to create a proper Error\nthrow createError(\"context\", { cause: err });\n\n// Enrich an existing error with context\nthrow Object.assign(new Error(\"not found\"), { code: 404 });\n```\n\n## What This Rule Does NOT Flag\n\n- `throw identifier` — the identifier may hold an Error; type-checking would be needed to verify\n- `throw expr.property` — same reason\n- `throw callExpression()` — assumed to return an Error\n- `throw new SomeThing()` — assumed to construct an Error\n\n## Error Messages\n\nThe error message teaches:\n\n1. **What's wrong** — the thrown value is not an Error instance\n2. **Why** — stack traces are lost, catch handlers receive unexpected types\n3. **How to fix** — `new Error(msg)`, `Object.assign(new Error(...), extras)`, or Error subclasses\n",
     "uninvoked-array-callback": "# llm-core/uninvoked-array-callback\n\n📝 Disallow callbacks on sparse arrays created with Array(length) because holes skip callback invocation.\n\n💼 This rule is enabled in the following configs: 🌐 `all`, 🏆 `best-practices`, ✅ `recommended`.\n\n<!-- end auto-generated rule header -->\n\n## Rule details\n\nThis rule flags array callback methods called directly on sparse arrays created with `Array(length)` or `new Array(length)`. Those constructors create holes, not present `undefined` elements. JavaScript array callback methods skip holes, so callbacks such as `.map(...)`, `.forEach(...)`, `.filter(...)`, `.some(...)`, and `.every(...)` may run zero times even though the code looks like it should run once per index.\n\nLLMs often generate this pattern when they want to create `n` rows, placeholders, tasks, or test cases. The code silently returns another sparse array or performs no side effects.\n\nFlagged patterns:\n\n```ts\nconst rows = new Array(5).map((_, index) => createRow(index));\n\nArray(count).forEach((_, index) => {\n  save(index);\n});\n\nconst ids = new Array(3).map((_, index) => index).filter((index) => index > 0);\n```\n\nCorrect patterns:\n\n```ts\nconst rows = Array.from({ length: 5 }, (_, index) => createRow(index));\n\nnew Array(count).fill(null).forEach((_, index) => {\n  save(index);\n});\n\nconst ids = [...new Array(3)]\n  .map((_, index) => index)\n  .filter((index) => index > 0);\n```\n\n## What counts as a sparse array callback\n\n| Pattern                                 | Triggers? | Why                                                         |\n| --------------------------------------- | --------- | ----------------------------------------------------------- |\n| `new Array(5).map(callback)`            | Yes       | Length-only arrays contain holes, so callbacks are skipped. |\n| `Array(count).forEach(callback)`        | Yes       | `Array(length)` has the same sparse-array behavior.         |\n| `new Array(5).fill(null).map(callback)` | No        | `.fill(...)` materializes present elements first.           |\n| `new Array(5).fill(null, 1).map(cb)`    | Yes       | Partial fills leave holes outside the filled range.         |\n| `[...new Array(5)].map(callback)`       | No        | Spreading materializes present `undefined` elements.        |\n| `Array.from({ length: 5 }, callback)`   | No        | `Array.from` invokes the mapping callback for each index.   |\n| `new Array(\"a\", \"b\").map(callback)`     | No        | Multiple arguments create present elements.                 |\n| `Array(true).map(callback)`             | No        | Non-number single arguments create one present element.     |\n| `collection.map(callback)`              | No        | The rule stays narrow and only targets Array constructors.  |\n\n## Error messages\n\nThe error message teaches:\n\n1. **What's wrong** — `Array(length)` created sparse slots, so the callback will not run for them.\n2. **Why** — LLM-generated code often expects one callback invocation per index, but array methods skip holes.\n3. **How to fix** — use `Array.from({ length }, mapper)` or materialize elements with `.fill(...)` before calling callback methods.\n",
 };
-export const ruleNames = ["bad-comparison-sequence", "bad-min-max-func", "consistent-catch-param-name", "explicit-export-types", "filename-match-export", "max-complexity", "max-file-length", "max-function-length", "max-nesting-depth", "max-params", "missing-throw", "naming-conventions", "no-any-in-generic", "no-async-array-callbacks", "no-async-promise-executor", "no-commented-out-code", "no-debug-scaffolding", "no-dynamic-code-execution", "no-empty-catch", "no-exported-function-expressions", "no-floating-promise", "no-hallucinated-local-imports", "no-hallucinated-package-imports", "no-incorrect-sort", "no-inline-disable", "no-llm-artifacts", "no-magic-numbers", "no-redundant-comments", "no-redundant-logic", "no-swallowed-errors", "no-type-assertion-any", "no-type-system-bypass", "no-unbounded-promise-all", "no-unsafe-array-access", "no-weak-randomness-for-secrets", "no-widen-then-assert", "prefer-early-return", "prefer-nullish-coalescing", "prefer-unknown-in-catch", "structured-logging", "throw-error-objects", "uninvoked-array-callback"];
+export const ruleNames = ["bad-comparison-sequence", "bad-min-max-func", "consistent-catch-param-name", "explicit-export-types", "filename-match-export", "max-complexity", "max-file-length", "max-function-length", "max-nesting-depth", "max-params", "missing-throw", "naming-conventions", "no-any-in-generic", "no-async-array-callbacks", "no-async-promise-executor", "no-chained-type-assertions", "no-commented-out-code", "no-debug-scaffolding", "no-dynamic-code-execution", "no-empty-catch", "no-exported-function-expressions", "no-floating-promise", "no-hallucinated-local-imports", "no-hallucinated-package-imports", "no-incorrect-sort", "no-inline-disable", "no-known-value-widening", "no-llm-artifacts", "no-magic-numbers", "no-object-parameters", "no-redundant-comments", "no-redundant-logic", "no-swallowed-errors", "no-type-assertion-any", "no-type-system-bypass", "no-unbounded-promise-all", "no-unknown-parameters", "no-unknown-returns", "no-unknown-type-aliases", "no-unsafe-array-access", "no-unsafe-dictionary-type", "no-weak-randomness-for-secrets", "no-widen-then-assert", "prefer-early-return", "prefer-nullish-coalescing", "prefer-unknown-in-catch", "structured-logging", "throw-error-objects", "uninvoked-array-callback"];
 //# sourceMappingURL=embedded-docs.js.map

package/dist/embedded-docs.js.map

@@ -1 +1 @@
-{"version":3,"file":"embedded-docs.js","sourceRoot":"","sources":["../src/embedded-docs.ts"],"names":[],"mappings":"AAAA,sEAAsE;AAEtE,MAAM,CAAC,MAAM,YAAY,GAA2B;IAClD,yBAAyB,EAAE,yyEAAyyE;IACp0E,kBAAkB,EAAE,6oFAA6oF;IACjqF,6BAA6B,EAAE,ipGAAipG;IAChrG,uBAAuB,EAAE,slLAAslL;IAC/mL,uBAAuB,EAAE,8qFAA8qF;IACvsF,gBAAgB,EAAE,8mHAA8mH;IAChoH,iBAAiB,EAAE,wrEAAwrE;IAC3sE,qBAAqB,EAAE,ksEAAksE;IACztE,mBAAmB,EAAE,+qEAA+qE;IACpsE,YAAY,EAAE,i8EAAi8E;IAC/8E,eAAe,EAAE,2vDAA2vD;IAC5wD,oBAAoB,EAAE,0sDAA0sD;IAChuD,mBAAmB,EAAE,srFAAsrF;IAC3sF,0BAA0B,EAAE,yyHAAyyH;IACr0H,2BAA2B,EAAE,ooEAAooE;IACjqE,uBAAuB,EAAE,8kGAA8kG;IACvmG,sBAAsB,EAAE,myGAAmyG;IAC3zG,2BAA2B,EAAE,y/GAAy/G;IACthH,gBAAgB,EAAE,kxFAAkxF;IACpyF,kCAAkC,EAAE,6/HAA6/H;IACjiI,qBAAqB,EAAE,4iHAA4iH;IACnkH,+BAA+B,EAAE,qhFAAqhF;IACtjF,iCAAiC,EAAE,yiKAAyiK;IAC5kK,mBAAmB,EAAE,gwDAAgwD;IACrxD,mBAAmB,EAAE,w7DAAw7D;IAC78D,kBAAkB,EAAE,63HAA63H;IACj5H,kBAAkB,EAAE,o5GAAo5G;IACx6G,uBAAuB,EAAE,w/EAAw/E;IACjhF,oBAAoB,EAAE,g1HAAg1H;IACt2H,qBAAqB,EAAE,kyFAAkyF;IACzzF,uBAAuB,EAAE,oqEAAoqE;IAC7rE,uBAAuB,EAAE,kvFAAkvF;IAC3wF,0BAA0B,EAAE,qqHAAqqH;IACjsH,wBAAwB,EAAE,w6GAAw6G;IACl8G,gCAAgC,EAAE,q6IAAq6I;IACv8I,sBAAsB,EAAE,ssLAAssL;IAC9tL,qBAAqB,EAAE,8mGAA8mG;IACroG,2BAA2B,EAAE,kwDAAkwD;IAC/xD,yBAAyB,EAAE,uzEAAuzE;IACl1E,oBAAoB,EAAE,6hGAA6hG;IACnjG,qBAAqB,EAAE,+2EAA+2E;IACt4E,0BAA0B,EAAE,4nGAA4nG;CACzpG,CAAC;AAEF,MAAM,CAAC,MAAM,SAAS,GAAa,CAAC,yBAAyB,EAAC,kBAAkB,EAAC,6BAA6B,EAAC,uBAAuB,EAAC,uBAAuB,EAAC,gBAAgB,EAAC,iBAAiB,EAAC,qBAAqB,EAAC,mBAAmB,EAAC,YAAY,EAAC,eAAe,EAAC,oBAAoB,EAAC,mBAAmB,EAAC,0BAA0B,EAAC,2BAA2B,EAAC,uBAAuB,EAAC,sBAAsB,EAAC,2BAA2B,EAAC,gBAAgB,EAAC,kCAAkC,EAAC,qBAAqB,EAAC,+BAA+B,EAAC,iCAAiC,EAAC,mBAAmB,EAAC,mBAAmB,EAAC,kBAAkB,EAAC,kBAAkB,EAAC,uBAAuB,EAAC,oBAAoB,EAAC,qBAAqB,EAAC,uBAAuB,EAAC,uBAAuB,EAAC,0BAA0B,EAAC,wBAAwB,EAAC,gCAAgC,EAAC,sBAAsB,EAAC,qBAAqB,EAAC,2BAA2B,EAAC,yBAAyB,EAAC,oBAAoB,EAAC,qBAAqB,EAAC,0BAA0B,CAAC,CAAC"}
+{"version":3,"file":"embedded-docs.js","sourceRoot":"","sources":["../src/embedded-docs.ts"],"names":[],"mappings":"AAAA,sEAAsE;AAEtE,MAAM,CAAC,MAAM,YAAY,GAA2B;IAClD,yBAAyB,EAAE,yyEAAyyE;IACp0E,kBAAkB,EAAE,6oFAA6oF;IACjqF,6BAA6B,EAAE,ipGAAipG;IAChrG,uBAAuB,EAAE,slLAAslL;IAC/mL,uBAAuB,EAAE,8qFAA8qF;IACvsF,gBAAgB,EAAE,8mHAA8mH;IAChoH,iBAAiB,EAAE,wrEAAwrE;IAC3sE,qBAAqB,EAAE,ksEAAksE;IACztE,mBAAmB,EAAE,+qEAA+qE;IACpsE,YAAY,EAAE,i8EAAi8E;IAC/8E,eAAe,EAAE,2vDAA2vD;IAC5wD,oBAAoB,EAAE,0sDAA0sD;IAChuD,mBAAmB,EAAE,srFAAsrF;IAC3sF,0BAA0B,EAAE,yyHAAyyH;IACr0H,2BAA2B,EAAE,ooEAAooE;IACjqE,4BAA4B,EAAE,mQAAmQ;IACjS,uBAAuB,EAAE,8kGAA8kG;IACvmG,sBAAsB,EAAE,myGAAmyG;IAC3zG,2BAA2B,EAAE,y/GAAy/G;IACthH,gBAAgB,EAAE,kxFAAkxF;IACpyF,kCAAkC,EAAE,6/HAA6/H;IACjiI,qBAAqB,EAAE,4iHAA4iH;IACnkH,+BAA+B,EAAE,qhFAAqhF;IACtjF,iCAAiC,EAAE,yiKAAyiK;IAC5kK,mBAAmB,EAAE,gwDAAgwD;IACrxD,mBAAmB,EAAE,w7DAAw7D;IAC78D,yBAAyB,EAAE,yPAAyP;IACpR,kBAAkB,EAAE,63HAA63H;IACj5H,kBAAkB,EAAE,o5GAAo5G;IACx6G,sBAAsB,EAAE,yOAAyO;IACjQ,uBAAuB,EAAE,w/EAAw/E;IACjhF,oBAAoB,EAAE,g1HAAg1H;IACt2H,qBAAqB,EAAE,kyFAAkyF;IACzzF,uBAAuB,EAAE,oqEAAoqE;IAC7rE,uBAAuB,EAAE,kvFAAkvF;IAC3wF,0BAA0B,EAAE,qqHAAqqH;IACjsH,uBAAuB,EAAE,mQAAmQ;IAC5R,oBAAoB,EAAE,2OAA2O;IACjQ,yBAAyB,EAAE,0OAA0O;IACrQ,wBAAwB,EAAE,w6GAAw6G;IACl8G,2BAA2B,EAAE,oQAAoQ;IACjS,gCAAgC,EAAE,q6IAAq6I;IACv8I,sBAAsB,EAAE,ssLAAssL;IAC9tL,qBAAqB,EAAE,8mGAA8mG;IACroG,2BAA2B,EAAE,kwDAAkwD;IAC/xD,yBAAyB,EAAE,uzEAAuzE;IACl1E,oBAAoB,EAAE,6hGAA6hG;IACnjG,qBAAqB,EAAE,+2EAA+2E;IACt4E,0BAA0B,EAAE,4nGAA4nG;CACzpG,CAAC;AAEF,MAAM,CAAC,MAAM,SAAS,GAAa,CAAC,yBAAyB,EAAC,kBAAkB,EAAC,6BAA6B,EAAC,uBAAuB,EAAC,uBAAuB,EAAC,gBAAgB,EAAC,iBAAiB,EAAC,qBAAqB,EAAC,mBAAmB,EAAC,YAAY,EAAC,eAAe,EAAC,oBAAoB,EAAC,mBAAmB,EAAC,0BAA0B,EAAC,2BAA2B,EAAC,4BAA4B,EAAC,uBAAuB,EAAC,sBAAsB,EAAC,2BAA2B,EAAC,gBAAgB,EAAC,kCAAkC,EAAC,qBAAqB,EAAC,+BAA+B,EAAC,iCAAiC,EAAC,mBAAmB,EAAC,mBAAmB,EAAC,yBAAyB,EAAC,kBAAkB,EAAC,kBAAkB,EAAC,sBAAsB,EAAC,uBAAuB,EAAC,oBAAoB,EAAC,qBAAqB,EAAC,uBAAuB,EAAC,uBAAuB,EAAC,0BAA0B,EAAC,uBAAuB,EAAC,oBAAoB,EAAC,yBAAyB,EAAC,wBAAwB,EAAC,2BAA2B,EAAC,gCAAgC,EAAC,sBAAsB,EAAC,qBAAqB,EAAC,2BAA2B,EAAC,yBAAyB,EAAC,oBAAoB,EAAC,qBAAqB,EAAC,0BAA0B,CAAC,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "eslint-plugin-llm-core-mcp",
-  "version": "0.29.8",
+  "version": "0.29.9",
   "description": "MCP server for just-in-time linting guidance from eslint-plugin-llm-core",
   "license": "MIT",
   "repository": {
@@ -42,15 +42,15 @@
   },
   "dependencies": {
     "@modelcontextprotocol/sdk": "^1.30.0",
-    "@typescript-eslint/parser": "^8.69.0",
+    "@typescript-eslint/parser": "^8.70.0",
     "eslint": "^10.10.0",
-    "eslint-plugin-llm-core": "0.36.2",
-    "zod": "^4.5.4"
+    "eslint-plugin-llm-core": "0.37.0",
+    "zod": "^4.6.5"
   },
   "devDependencies": {
-    "@types/node": "^26.4.1",
+    "@types/node": "^26.5.1",
     "tsx": "^4.23.13",
     "typescript": "^6.0.2",
-    "vitest": "^4.1.2"
+    "vitest": "^4.1.11"
   }
 }