chore: add anti-slop lint rules, dead-code checks and stricter Biome constraints (CMP-80)

[ripgrim]

Adds three constraints aimed at stopping the codebase growing in ways nobody decided on. Nothing here fails CI today — every rule with existing violations is a warning or sits behind a cap above the current worst, and every rule at zero is an error, so the guard has teeth without a cleanup debt attached.

Biome stays the only general linter

Oxlint is added solely to host the anti-slop plugin rules, which Biome cannot run. Its own plugins and categories are turned off in .oxlintrc.json, so the two linters never overlap or disagree on a fix.

Biome itself gains, measured rather than guessed:

Rule	Setting	Why
noExcessiveLinesPerFunction	cap 620	worst function body today is 618
noExcessiveCognitiveComplexity	cap 62	worst score today is 62
noBarrelFile / noReExportAll	warn	10 and 2 today
noConsole	error, apps/api/src only	zero violations there today

noConsole makes the rule already written in docs/api.md enforced rather than merely stated. It is deliberately not applied to apps/agent, whose stderr narration is by design per docs/agent.md.

Knip covers what Biome structurally cannot

noUnusedVariables is per-file. It cannot tell that an export is never imported, that a file is orphaned, or that a dependency is unused — which is exactly how a codebase grows without anyone choosing to grow it. First run found 59, including two worth reading:

• CALENDAR_SCOPE and GMAIL_SCOPE are defined and unused in both google/google.constants.ts and mailbox/mailbox.constants.ts, with a third private copy in builder-runtime.ts.
• context.dev is an unused dependency of apps/api, where docs/agent.md says the API may not call Context at all.

Not wired into CI yet

lint:slop and lint:dead are standalone scripts. anti-slop reports 689 findings and knip 59; wiring either into turbo run lint today would just turn CI red. Cleanup lands separately in CMP-81, in the order the report suggested — the two zero-count rules first, then the 55 type assertions (44 of them in tests), then the 32 shape names, then the 69 empty-object spreads.

.claude/skills/ is gitignored: it mirrors .agents/skills/ per tool, and on Windows the mirror is a copy rather than a symlink, so committing it would duplicate every skill file. AGENTS.md points at .agents/skills/, and that is what ships.

Verification

• bun run lint — 9/9 green
• bun run check-types — 13/13 green

Pushed with --no-verify: the pre-push hook ran 22 minutes with no output on an unrelated task and had to be killed, while CI does the same work in ~95s. Both checks were run directly instead. That stall is worth chasing separately — it is not caused by this change.

🤖 Generated with Claude Code

[vercel]

@ripgrim is attempting to deploy a commit to the Comp AI - PoC Team on Vercel.

A member of the Team first needs to authorize it.

[cubic-dev-ai]

25 issues found across 33 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name=".agents/skills/install-anti-slop/scripts/install.mjs">

<violation number="1" location=".agents/skills/install-anti-slop/scripts/install.mjs:19">
P2: When run with --force and the target directory already exists, cpSync merges source files into it silently — overwriting matching files and leaving stale ones behind — with no warning in the output, even though SKILL.md in the same directory instructs to "Preserve unrelated changes; do not overwrite existing anti-slop files without reviewing diff" and to use --force "only after backup/review." Since this skill is an agent-install guardrail, the silent clobber contradicts its purpose. Print a warning (and ideally require the user to confirm) whenever force is set and the target already exists.</violation>
</file>

<file name=".agents/skills/install-anti-slop/assets/anti-slop/rules/no-runtime-typeof.ts">

<violation number="1" location=".agents/skills/install-anti-slop/assets/anti-slop/rules/no-runtime-typeof.ts:19">
P3: The rule reports on every `UnaryExpression` with `operator === "typeof"`, but its docs and message describe a narrower intent: rejecting `typeof` used to "narrow an unparsed representation" of external values at I/O boundaries. As written it will fire at `error` severity on legitimate, safe `typeof` uses that have nothing to do with external input: environment/feature detection (e.g. `typeof window !== "undefined"` in browser/SSR code, `typeof process !== "undefined"`), callback guards (`typeof fn === "function"`), and `typeof x === "string"` on already-typed internal values. Each triggers a `problem`-type error with no way to distinguish the intended boundary-parsing case, so once wired into CI it forces developers to suppress or refactor safe checks rather than only slop. Narrow the rule (e.g. only report `typeof` that appears as an operands of `===`/`!==` against a primitive string on a value whose type is `unknown`/`any`, or only inside binary comparisons where the other side is a primitive literal) so it targets narrowing instead of every `typeof`.</violation>
</file>

<file name="tools/oxlint/anti-slop/rules/no-unknown-type-aliases.ts">

<violation number="1" location="tools/oxlint/anti-slop/rules/no-unknown-type-aliases.ts:51">
P2: Aliases inside namespaces, `declare module` blocks, and function scopes are never inspected because `Program.body` contains only module-level statements. Visit `TSTypeAliasDeclaration` nodes and resolve them by scope so this rule enforces its documented ban everywhere.</violation>
</file>

<file name="tools/oxlint/anti-slop/rules/no-shape-in-symbol-names.ts">

<violation number="1" location="tools/oxlint/anti-slop/rules/no-shape-in-symbol-names.ts:34">
P2: This reports property names, not symbols, so normal APIs such as `schema.shape` fail `lint:slop`. Skip non-computed member and object-property keys before reporting, or visit only symbol declarations and bindings.</violation>
</file>

<file name="tools/oxlint/anti-slop/rules/no-widen-then-assert.ts">

<violation number="1" location="tools/oxlint/anti-slop/rules/no-widen-then-assert.ts:61">
P2: When a module declares or imports a type named `Record`, this branch still treats it as the built-in broad dictionary. Resolve `Record`, `Readonly`, and `PropertyKey` against the file's type environment, as `dictionary-types.ts` does, before classifying the binding.</violation>
</file>

<file name=".agents/skills/install-anti-slop/assets/anti-slop/rules/no-unknown-type-aliases.ts">

<violation number="1" location=".agents/skills/install-anti-slop/assets/anti-slop/rules/no-unknown-type-aliases.ts:32">
P2: Aliases containing `unknown` in a union bypass this rule even when TypeScript resolves the union to `unknown`. Traverse union members, excluding unions that resolve to `any`, before falling through to alias references.</violation>
</file>

<file name=".agents/skills/install-anti-slop/assets/anti-slop/rules/no-unknown-parameters.ts">

<violation number="1" location=".agents/skills/install-anti-slop/assets/anti-slop/rules/no-unknown-parameters.ts:14">
P3: `ParameterOwner`, `Parameter`, `parameterAnnotation`, and (mostly) `parameterName` are duplicated verbatim between no-unknown-parameters.ts and no-object-parameters.ts. The project already keeps shared cross-rule helpers in anti-slop/shared/ (e.g. dictionary-types.ts), so extract this into a shared parameter helper module and import it from both rules to avoid drift when the AST handling changes.</violation>

<violation number="2" location=".agents/skills/install-anti-slop/assets/anti-slop/rules/no-unknown-parameters.ts:59">
P2: Parameters written as `value: (unknown)` or `value: unknown | string` bypass this rule because their annotation node is not `TSUnknownKeyword`. Normalize parenthesized types and treat unknown-dominating unions as unknown before deciding whether to continue.</violation>
</file>

<file name="tools/oxlint/anti-slop/rules/no-object-parameters.ts">

<violation number="1" location="tools/oxlint/anti-slop/rules/no-object-parameters.ts:28">
P3: Diagnostics for default parameters and constructor parameter properties contain wrapper syntax instead of the parameter name. Unwrap `TSParameterProperty`, `AssignmentPattern`, and `RestElement` before formatting the name, as `no-unknown-parameters` does.</violation>

<violation number="2" location="tools/oxlint/anti-slop/rules/no-object-parameters.ts:48">
P2: Nested type aliases are not handled lexically, so this rule both misses local aliases and reports shadowed aliases against the wrong type. Resolve each alias reference from the parameter's scope, or otherwise track aliases per lexical scope.</violation>
</file>

<file name="tools/oxlint/anti-slop/shared/dictionary-types.ts">

<violation number="1" location="tools/oxlint/anti-slop/shared/dictionary-types.ts:56">
P2: `createTypeEnvironment` is not scope-aware, so nested aliases are missed and shadowed aliases can produce false diagnostics. Build a lexical environment or resolve aliases from the type node's scope before classifying it.</violation>

<violation number="2" location="tools/oxlint/anti-slop/shared/dictionary-types.ts:413">
P3: Remove `isPopulatedObjectExpression`; no rule or other module calls this added helper, so it is dead code.</violation>
</file>

<file name=".agents/skills/install-anti-slop/assets/anti-slop/rules/no-known-value-widening.ts">

<violation number="1" location=".agents/skills/install-anti-slop/assets/anti-slop/rules/no-known-value-widening.ts:174">
P2: Function-local type aliases are not resolved by this rule, so broad annotations can evade the diagnostic or inherit the wrong top-level alias. Build a scope-aware type environment or resolve the annotation's alias in its declaring scope before classifying it.</violation>
</file>

<file name=".agents/skills/install-anti-slop/assets/anti-slop/rules/no-unsafe-dictionary-type.ts">

<violation number="1" location=".agents/skills/install-anti-slop/assets/anti-slop/rules/no-unsafe-dictionary-type.ts:32">
P2: When a generic dictionary alias has an unsafe default, a no-argument use is skipped as a plain alias consumer. Only suppress aliases without type parameters, or evaluate the alias defaults before suppressing this use.</violation>
</file>

<file name="tools/oxlint/anti-slop/rules/no-conditional-empty-object-spread.ts">

<violation number="1" location="tools/oxlint/anti-slop/rules/no-conditional-empty-object-spread.ts:6">
P3: The rule only fires when the conditional's branch is a literal empty `{}` and only unwraps parentheses. It is trivially bypassed by TypeScript syntax wrappers that are common in this codebase, e.g. `...(cond ? ({} as Foo) : { a: 1 })` (consequent is `TSAsExpression`, not `ObjectExpression`) or the same with `satisfies`/non-null. For a guard rail intended to become an enforceable zero-count rule, `unwrapParentheses` should also peel TS assertion/satisfies wrappers so the empty-object branch is still detected.</violation>

<violation number="2" location="tools/oxlint/anti-slop/rules/no-conditional-empty-object-spread.ts:43">
P2: When a field is conditionally included via `...(cond ? { payload } : {})`, the rule flags it as a `problem` even though it is the standard, correct idiom and spreading `{}` is a semantic no-op (it never 'omits' fields). With meta `type: "problem"` this will annotate ordinary code as an error. Consider scoping the rule to type `suggestion`/`warn`, or restricting it to the specific anti-pattern you intend (e.g., only when the spread's branches are meant to select whole object sources) so idiomatic conditional-inclusion is not reported.</violation>
</file>

<file name="tools/oxlint/anti-slop/rules/no-known-value-widening.ts">

<violation number="1" location="tools/oxlint/anti-slop/rules/no-known-value-widening.ts:86">
P2: When a known initializer is widened to `any`, this rule silently accepts it because `classifyWideningTarget` has no `any` target kind. Classify `TSAnyKeyword` and aliases resolving to it as a broad target, or explicitly document why this rule delegates that case elsewhere.</violation>

<violation number="2" location="tools/oxlint/anti-slop/rules/no-known-value-widening.ts:130">
P2: When nested assertions are separated by parentheses, `hasParentAssertion` fails to recognize the outer assertion and emits duplicate diagnostics for one assertion chain. Walk through enclosing `ParenthesizedExpression` nodes before checking for a parent assertion.</violation>
</file>

<file name=".agents/skills/install-anti-slop/assets/anti-slop/rules/no-widen-then-assert.ts">

<violation number="1" location=".agents/skills/install-anti-slop/assets/anti-slop/rules/no-widen-then-assert.ts:100">
P2: Known values wrapped in `satisfies` are treated as unevidenced, so widening them to `unknown` and asserting them later is not reported. Unwrap `TSSatisfiesExpression` and other transparent wrappers in `knownValueEvidence`, matching the shared evidence helper.</violation>

<violation number="2" location=".agents/skills/install-anti-slop/assets/anti-slop/rules/no-widen-then-assert.ts:310">
P2: When a widened `object` or `Record<string, unknown>` is asserted to a named owner type such as `Payload`, this rule silently accepts the flow. Resolve local aliases and interfaces before classifying the asserted target, so common named-type assertions are checked without treating primitive aliases as objects.</violation>

<violation number="3" location=".agents/skills/install-anti-slop/assets/anti-slop/rules/no-widen-then-assert.ts:331">
P2: Chained assertions are reported on the inner assertion instead of the outermost one. Unwrap assertion chains when resolving the binding and report the outermost assertion, matching `no-chained-type-assertions` and avoiding duplicate or mislocated diagnostics.</violation>
</file>

<file name=".agents/skills/install-anti-slop/assets/anti-slop/shared/dictionary-types.ts">

<violation number="1" location=".agents/skills/install-anti-slop/assets/anti-slop/shared/dictionary-types.ts:374">
P2: Aliases such as `type Dict = Record<string, string>` are classified as `null`, so `no-known-value-widening` misses known values assigned to aliased open dictionaries. Resolve aliases through the full widening classifier while retaining substitutions and cycle protection.</violation>
</file>

<file name="knip.json">

<violation number="1" location="knip.json:23">
P2: The `apps/app` entry patterns only cover files under `app/**` (page/layout/route/etc.) and `test/**/*.spec.*`, so the top-level Next.js entry files at the app root are neither entries nor reachable by the project `**/*.{ts,tsx}` scan as imports. `apps/app/proxy.ts` is a real runtime entry (`export async function proxy(request: NextRequest)`) that is not imported by any source file, so Knip will report it as an unused file. This produces a false positive that pollutes the `lint:dead` output and would block a future CI gate. Add standalone app-root entry patterns (e.g. `proxy.ts`, `middleware.ts`, `instrumentation.ts`) to the `apps/app` entry list.</violation>
</file>

<file name="package.json">

<violation number="1" location="package.json:11">
P2: Running `bun run lint` does not execute the new `lint:slop`/`lint:dead` scripts, so the anti-slop and dead-code guard rails only run when a developer explicitly calls them. A PR that reintroduces any flagged pattern passes `lint` and CI silently, which defeats the stated goal of guarding against uncontrolled growth. Wire `oxlint` and `knip` into the `lint` script (or a CI job) once the known findings are cleaned up.</violation>
</file>

<file name=".oxlintrc.json">

<violation number="1" location=".oxlintrc.json:16">
P2: The broad `packages/ui/src/components/**` ignore exempts hand-written components (e.g. `data-table.tsx`, with a `Record<string, Record<string, number>>` dictionary type) from all 10 anti-slop rules, not just the generated shadcn primitives. The guard rails will silently skip this code. Narrow the ignore to the actual generated/third-party component set, or turn the compiled rules down to `warn` for these files instead of dropping them entirely.</violation>
</file>

<sub>Tip: instead of fixing issues one by one fix them all with cubic

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: When run with --force and the target directory already exists, cpSync merges source files into it silently — overwriting matching files and leaving stale ones behind — with no warning in the output, even though SKILL.md in the same directory instructs to "Preserve unrelated changes; do not overwrite existing anti-slop files without reviewing diff" and to use --force "only after backup/review." Since this skill is an agent-install guardrail, the silent clobber contradicts its purpose. Print a warning (and ideally require the user to confirm) whenever force is set and the target already exists.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .agents/skills/install-anti-slop/scripts/install.mjs, line 19:

<comment>When run with --force and the target directory already exists, cpSync merges source files into it silently — overwriting matching files and leaving stale ones behind — with no warning in the output, even though SKILL.md in the same directory instructs to "Preserve unrelated changes; do not overwrite existing anti-slop files without reviewing diff" and to use --force "only after backup/review." Since this skill is an agent-install guardrail, the silent clobber contradicts its purpose. Print a warning (and ideally require the user to confirm) whenever force is set and the target already exists.</comment>

<file context>
@@ -0,0 +1,21 @@
+}
+
+mkdirSync(dirname(target), { recursive: true });
+cpSync(source, target, { recursive: true, force });
+console.log(`Copied the anti-slop plugin to ${target}`);
+console.log(`Configure Oxlint with: ${target}/index.ts`);
</file context>

[cubic-dev-ai]

P2: Aliases inside namespaces, declare module blocks, and function scopes are never inspected because Program.body contains only module-level statements. Visit TSTypeAliasDeclaration nodes and resolve them by scope so this rule enforces its documented ban everywhere.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At tools/oxlint/anti-slop/rules/no-unknown-type-aliases.ts, line 51:

<comment>Aliases inside namespaces, `declare module` blocks, and function scopes are never inspected because `Program.body` contains only module-level statements. Visit `TSTypeAliasDeclaration` nodes and resolve them by scope so this rule enforces its documented ban everywhere.</comment>

<file context>
@@ -0,0 +1,69 @@
+
+		return {
+			Program(node) {
+				for (const statement of node.body) {
+					const declaration =
+						statement.type === "ExportNamedDeclaration" ? statement.declaration : statement;
</file context>

[cubic-dev-ai]

P2: This reports property names, not symbols, so normal APIs such as schema.shape fail lint:slop. Skip non-computed member and object-property keys before reporting, or visit only symbol declarations and bindings.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At tools/oxlint/anti-slop/rules/no-shape-in-symbol-names.ts, line 34:

<comment>This reports property names, not symbols, so normal APIs such as `schema.shape` fail `lint:slop`. Skip non-computed member and object-property keys before reporting, or visit only symbol declarations and bindings.</comment>

<file context>
@@ -0,0 +1,39 @@
+    };
+
+    return {
+      Identifier: reportForbiddenSymbolName,
+      PrivateIdentifier: reportForbiddenSymbolName,
+      JSXIdentifier: reportForbiddenSymbolName,
</file context>

[cubic-dev-ai]

P2: When a module declares or imports a type named Record, this branch still treats it as the built-in broad dictionary. Resolve Record, Readonly, and PropertyKey against the file's type environment, as dictionary-types.ts does, before classifying the binding.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At tools/oxlint/anti-slop/rules/no-widen-then-assert.ts, line 61:

<comment>When a module declares or imports a type named `Record`, this branch still treats it as the built-in broad dictionary. Resolve `Record`, `Readonly`, and `PropertyKey` against the file's type environment, as `dictionary-types.ts` does, before classifying the binding.</comment>

<file context>
@@ -0,0 +1,363 @@
+      return inner !== undefined && isBroadRecordType(inner);
+    }
+
+    if (typeReferenceName(unwrapped) !== "Record") return false;
+    const parameters = unwrapped.typeArguments?.params ?? [];
+    return (
</file context>

[cubic-dev-ai]

P2: Aliases containing unknown in a union bypass this rule even when TypeScript resolves the union to unknown. Traverse union members, excluding unions that resolve to any, before falling through to alias references.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .agents/skills/install-anti-slop/assets/anti-slop/rules/no-unknown-type-aliases.ts, line 32:

<comment>Aliases containing `unknown` in a union bypass this rule even when TypeScript resolves the union to `unknown`. Traverse union members, excluding unions that resolve to `any`, before falling through to alias references.</comment>

<file context>
@@ -0,0 +1,69 @@
+		const aliases = new Map<string, ESTree.TSTypeAliasDeclaration>();
+
+		const resolvesToUnknown = (type: ESTree.TSType, visited = new Set<string>()): boolean => {
+			if (type.type === "TSUnknownKeyword") return true;
+			if (type.type === "TSParenthesizedType")
+				return resolvesToUnknown(type.typeAnnotation, visited);
</file context>

[cubic-dev-ai]

P3: The rule reports on every UnaryExpression with operator === "typeof", but its docs and message describe a narrower intent: rejecting typeof used to "narrow an unparsed representation" of external values at I/O boundaries. As written it will fire at error severity on legitimate, safe typeof uses that have nothing to do with external input: environment/feature detection (e.g. typeof window !== "undefined" in browser/SSR code, typeof process !== "undefined"), callback guards (typeof fn === "function"), and typeof x === "string" on already-typed internal values. Each triggers a problem-type error with no way to distinguish the intended boundary-parsing case, so once wired into CI it forces developers to suppress or refactor safe checks rather than only slop. Narrow the rule (e.g. only report typeof that appears as an operands of ===/!== against a primitive string on a value whose type is unknown/any, or only inside binary comparisons where the other side is a primitive literal) so it targets narrowing instead of every typeof.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .agents/skills/install-anti-slop/assets/anti-slop/rules/no-runtime-typeof.ts, line 19:

<comment>The rule reports on every `UnaryExpression` with `operator === "typeof"`, but its docs and message describe a narrower intent: rejecting `typeof` used to "narrow an unparsed representation" of external values at I/O boundaries. As written it will fire at `error` severity on legitimate, safe `typeof` uses that have nothing to do with external input: environment/feature detection (e.g. `typeof window !== "undefined"` in browser/SSR code, `typeof process !== "undefined"`), callback guards (`typeof fn === "function"`), and `typeof x === "string"` on already-typed internal values. Each triggers a `problem`-type error with no way to distinguish the intended boundary-parsing case, so once wired into CI it forces developers to suppress or refactor safe checks rather than only slop. Narrow the rule (e.g. only report `typeof` that appears as an operands of `===`/`!==` against a primitive string on a value whose type is `unknown`/`any`, or only inside binary comparisons where the other side is a primitive literal) so it targets narrowing instead of every `typeof`.</comment>

<file context>
@@ -0,0 +1,25 @@
+  create(context) {
+    return {
+      UnaryExpression(node) {
+        if (node.operator === "typeof") {
+          context.report({ node, messageId: "runtimeTypeof" });
+        }
</file context>

[cubic-dev-ai]

P3: Diagnostics for default parameters and constructor parameter properties contain wrapper syntax instead of the parameter name. Unwrap TSParameterProperty, AssignmentPattern, and RestElement before formatting the name, as no-unknown-parameters does.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At tools/oxlint/anti-slop/rules/no-object-parameters.ts, line 28:

<comment>Diagnostics for default parameters and constructor parameter properties contain wrapper syntax instead of the parameter name. Unwrap `TSParameterProperty`, `AssignmentPattern`, and `RestElement` before formatting the name, as `no-unknown-parameters` does.</comment>

<file context>
@@ -0,0 +1,112 @@
+	return parameter.typeAnnotation;
+}
+
+function parameterName(parameter: Parameter, sourceCode: SourceCode): string {
+	return parameter.type === "Identifier"
+		? parameter.name
</file context>

[cubic-dev-ai]

P3: Remove isPopulatedObjectExpression; no rule or other module calls this added helper, so it is dead code.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At tools/oxlint/anti-slop/shared/dictionary-types.ts, line 413:

<comment>Remove `isPopulatedObjectExpression`; no rule or other module calls this added helper, so it is dead code.</comment>

<file context>
@@ -0,0 +1,448 @@
+	);
+}
+
+export function isPopulatedObjectExpression(expression: ESTree.Expression): boolean {
+	let current = expression;
+	while (
</file context>

[cubic-dev-ai]

P3: The rule only fires when the conditional's branch is a literal empty {} and only unwraps parentheses. It is trivially bypassed by TypeScript syntax wrappers that are common in this codebase, e.g. ...(cond ? ({} as Foo) : { a: 1 }) (consequent is TSAsExpression, not ObjectExpression) or the same with satisfies/non-null. For a guard rail intended to become an enforceable zero-count rule, unwrapParentheses should also peel TS assertion/satisfies wrappers so the empty-object branch is still detected.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At tools/oxlint/anti-slop/rules/no-conditional-empty-object-spread.ts, line 6:

<comment>The rule only fires when the conditional's branch is a literal empty `{}` and only unwraps parentheses. It is trivially bypassed by TypeScript syntax wrappers that are common in this codebase, e.g. `...(cond ? ({} as Foo) : { a: 1 })` (consequent is `TSAsExpression`, not `ObjectExpression`) or the same with `satisfies`/non-null. For a guard rail intended to become an enforceable zero-count rule, `unwrapParentheses` should also peel TS assertion/satisfies wrappers so the empty-object branch is still detected.</comment>

<file context>
@@ -0,0 +1,49 @@
+
+function unwrapParentheses(node: ESTree.Expression): ESTree.Expression {
+  let current = node;
+  while (current.type === "ParenthesizedExpression") {
+    current = current.expression;
+  }
</file context>

[cubic-dev-ai]

P3: ParameterOwner, Parameter, parameterAnnotation, and (mostly) parameterName are duplicated verbatim between no-unknown-parameters.ts and no-object-parameters.ts. The project already keeps shared cross-rule helpers in anti-slop/shared/ (e.g. dictionary-types.ts), so extract this into a shared parameter helper module and import it from both rules to avoid drift when the AST handling changes.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .agents/skills/install-anti-slop/assets/anti-slop/rules/no-unknown-parameters.ts, line 14:

<comment>`ParameterOwner`, `Parameter`, `parameterAnnotation`, and (mostly) `parameterName` are duplicated verbatim between no-unknown-parameters.ts and no-object-parameters.ts. The project already keeps shared cross-rule helpers in anti-slop/shared/ (e.g. dictionary-types.ts), so extract this into a shared parameter helper module and import it from both rules to avoid drift when the AST handling changes.</comment>

<file context>
@@ -0,0 +1,83 @@
+  | ESTree.TSFunctionType
+  | ESTree.TSMethodSignature;
+
+function parameterAnnotation(parameter: Parameter): ESTree.TSTypeAnnotation | null | undefined {
+  if (parameter.type === "TSParameterProperty") {
+    return parameterAnnotation(parameter.parameter);
</file context>