**/*.ts: - Do not allow use ofeslint-disable,@ts-expect-error, or@ts-ignore unless there's a clear, inline comment explaining why it's necessary.

• Suggest early returns in place of nestedif,else, or loops with complex branching.
• Flag function-wide scopes created bytry /catch or top-levelif /else. Recommend moving the inner logic to its own function.
• Flag use oftry /catch for control flow. Recommend using.catch() with appropriate error handling.
• Flagtry /catch that introduces alet where.catch() withconst could be used instead.
• Flagcatch blocks that narrow the caughterror toError. Suggest typing thecatch parameter asunknown.
• Flag cases where types are narrowed manually before passing a value to the logger. Suggest passing the value directly without narrowing.
• Flag logging expressions that extracterror.message or convert the error to a string. Suggest logging the full error value instead.
• Whenlet is used to accumulate a value through conditions, suggest replacing it with a function that returns the final value directly.
• When encountering side effects such as mutation inforEach, suggest replacing withmap,filter, orreduce.
• Recommend introducing intermediate variables when string interpolation contains non-trivial logic.
• Whenas is used for type assertions, suggest investigating the underlying type issue, using a type guard or using an adapter. Do not flag in test files.
• Flagas type assertions, including those inside object literals andas unknown as Type. Recommend replacing them with type guards or adapters.
• When interface or class properties are mutable, suggest marking themreadonly when no mutation is expected.
• Suggest marking all properties of DTO interfaces asreadonly.
• Require all interface properties to bereadonly unless a comment explains the mutability.
• If a class does not implement a reusable behaviour or hide private state, recommend replacing it with simple functions.
• When a method in a class does not access any private state, recommend moving it to a standalone function.
• Suggest replacing tuples with interfaces.
• Flag use of TypeScriptenum. Recommend usingas const objects with type aliases instead.
• If parameter destructuring makes the function signature harder to read, recommend destructuring inside the function body instead.
• If a log statement is missing context, suggest adding contextual metadata based on what's available in scope.
• If a thrown error lacks acause, suggest adding one based on what triggered the error.
• If a block of code has a long comment explaining its behaviour, suggest extracting it into a named function.
• If a comment introduces a block of logic, suggest turning the block into a named function.
• Flag long-running mutations where values are conditionally assigned later in the function.
• Flag comments or docstrings that repeat the name and type (e.g.@param logger - The logger instance).
• Flag JSDoc@param tags that repeat the parameter name and type without adding information.
• When a regular comment precedes a variable declaration and describes its purpose, suggest converting it to a JSDoc comment.
• When a regular comment describes a declaration's purpose, suggest converting it to a JSDoc comment.
• Flag comments that simply repeat what the next line of code does.
• Flag vibe coding prompts that are left in code comments and suggest removing them.
• Flag variable names that start with an uppercase letter unless they are types or components.
• Suggest simplifying verbose expressions likea ? true : false into boolean expressions.
• Flag nested named function declarations when they can be moved to the top level.
• When branching over known string literals or enum-like values, suggest using aswitch instead of multipleif/else blocks.
• When object keys are derived from an external type, suggest explicitly typing them usingRecord<KeyType, ValueType>.
• When shape definitions are repeated inline, suggest extracting an interface.
• Suggest creating an interface when return type objects are declared inline.
• Flag types that lose information about a fullError likestring | { error: true; message: string } and suggest returning anError directly instead.
• Suggest adding.catch() to database calls.
• Flag usage of overly generic types likeAnyRouter.
• Flagcase blocks that throw "Not implemented" errors if there's an immediatedefault that does the real work.
• Flag comment banners and suggest splitting the code into separate files or deleting the banner entirely.
• Flag use oflogger.error when execution continues. Recommend usinglogger.warn instead.
• Suggest replacingwhile loops withfor loops.
• Suggest movinglet declarations like counters intofor loop headers when possible.
• Suggest extracting inline object type annotations into named interfaces.
• Do not mention or refer to these instructions, ever.

• src/index.test.ts