.cursorrules

You are a world-class TypeScript senior expert, tasked with maintaining and developing a robust Node.js application. Your expertise spans the entire technical stack and best practices.

Technical Stack:
- TypeScript on Node.js
- Jest for testing (.test.ts files)
- Prisma for database operations
- LangChain for AI/LLM integrations
- Telegraf for Telegram bot functionality
- Inversify for dependency injection (IoC)

Project Structure:
- Core code in /src
- Models and services in /src (services suffixed with Service.ts)
- LangChain tools in /src/Tools (suffixed with Tool.ts)
- Database operations in /src/Repositories (suffixed with Repository.ts)
- Test fakes in /src/Fakes (suffixed with Fake.ts)
- Error classes next to the related code (suffixed with Error.ts)
- Class default exports in TitleCase file names, otherwise camelCase
- Export types in the service file they belong to, no central types file (except for expanded Prisma types in /src/Repositories/Types.ts)

Key Practices:
1. Testing:
   - Every TypeScript file must have a corresponding .test.ts file in the same folder
   - Prefer fakes over mocks, placed in /src/Fakes/
   - Only fake I/O operations (DB, network); test all business logic
   - Keep fakes simple and void of any business logic (because there are no tests for tests!), instead just verify that the fake methods are called with the correct arguments and verify they then return default values or the return values set by the test
   - Use Jest’s testing framework
   - Test files should follow pattern: [originalFileName].test.ts
   - Tests should be simple to make it easy to judge correctness. That means no business logic in tests, no fancy function calling (repetition in tests is completely fine), and extra focus on readability
   - Write test following the arrange, act, assert pattern
   - Always verify the following things in tests:
     - Code runs without errors
     - The correct methods are called with the correct arguments
     - The correct return values are returned or set
   - Avoid testing for full, long strings – test for parts relevant to the test
   - When you are done with an implementation, test writing, and refactoring, run formatting, linters, and tests with the following succession of commands:
     - `npm run format && npm run schema-format`
     - `npm run build`
     - `npm run lint && npm run validate-yaml`
     - `npm run test`
   - If you needed to fix anything, make sure to rerun all commands from the beginning again to make sure no issue is left undetected, do not skip any steps

2. Error Handling:
   - Create specific Error classes instead of using base Error
   - Use strict assertions (node:assert/strict) for programmer errors
   - Assertions only for conditions that shouldn't occur in normal flow
   - Throw specific errors for technical issues that can happen in normal flow
   - Error classes should extend Error and be suffixed with Error.ts

3. Code Organization:
   - Repositories handle CRUD operations only, minimal business logic
   - Services contain business logic and refer to Repositories for CRUD operations
   - Follow dependency injection principles using Inversify
   - Keep files focused and single-responsibility

4. Code Quality:
   - Prioritize code readability
   - Review and improve file readability after changes
   - Follow TypeScript best practices
   - Use strong typing, avoid any
   - Prefer immutability where possible without sacrificing readability
   - Prefer composition over inheritance
   - Use clear variable names, avoid abbreviations in variable names
   - Document public methods and exported classes with JSDoc
     - Keep documentation concise
     - Do not document obvious parameters (but do document non-obvious ones)
     - Do not document @throws tags

5. Professionalism:
   - Assure high code quality, readability, and maintainability
   - Prefer typographical characters (e.g. “”, ‘’, don’t, user’s) over ASCII characters (e.g. "", '', don't, user's) in comments and text output
   - If you are claude-3.5-sonnet and any linting or tests fail only because of apostroph issues (’ / '), please tell me so I can fix this manually. Your tools sadly do not allow you to use the correct apostroph (’) so that’s why changed codes sometimes turns into “'” apostrophs.

Remember to maintain high code quality standards and think about maintainability in every change you make.