You are an expert in Typescript and Node.js. You are building a web server in opponiated framework.

Tool usage
- When in doubt - use web tool to get answers from the web.
- Search web when you have some failures.

Code Style and Structure
- Write concise, technical TypeScript code with accurate examples.
- Use functional and declarative programming patterns; avoid classes.
- Prefer iteration and modularization over code duplication.
- Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).
- All sources must be imported using "@/" prefix. `import "@/utils/log"` means `import "/sources/utils/log.ts"`.
- Always use absolute imports.

Folder structure
- Root of the sources is "/sources"
- Non-application logic files are in "/sources/modules"
- Low level or too abstract utilities are in "/sources/utils"
- Recipes, ie scripts that you want to run outside of the server are in "/sources/recipes"
- Applications are in /sources/apps
- API server is in /sources/apps/api with routes in /sources/apps/api/routes
- Modules are in /sources/modules

Naming Conventions
- Use lowercase with dashes for directories (e.g., components/auth-wizard).

TypeScript Usage
- Use TypeScript for all code; prefer interfaces over types.
- Avoid enums; use maps instead.
- Use functional components with TypeScript interfaces.
- Use strict mode in TypeScript for better type safety.

Tests
- Write tests using Vitest.
- Always name test files in the same way as the source file, but with ".spec.ts" suffix.

Utilities
- When writing utility function always name file and function in the same way, so it is easy to find it.
- Utility functions should be modular and not too complex.
- When writing utility functions, always write tests for them BEFORE writing the code.
- Iterate your implementation and tests until you are sure that the function works as expected.
- When writing utility functions, always write documentation for them.

Modules
- Modules are bigger than utility functions and their goal is to abstract away complexity
- Each module should have dedicated directory.
- Modules usually don't have application specific logic, they are more general and could be copied to other projects.
- Modules can depend on other modules, but should not depend on application specific logic.
- Prefer to write code as modules instead of application specific code.
- When using a module is a good idea:
  - When you need to integrate with external services
  - When you need to abstract away complexity of some library
  - When you want to implement some group of functions that are related to each other, like math, date, etc.
- Some known modules are:
  - ai: AI wrappers to interact with AI services
  - eventbus: event bus to send and receive events between modules and applications
  - lock: simple lock to synchronize access to resources in the whole cluster
  - media: tools to work with media files

Applications
- Applications has some application specific logic
- Applications have the most of the complexity and other parts of the code should assist by reducing complexity here.
- When using prompts, write them to "_prompts.ts" file relative to the application.

Database
- Prisma is used as ORM.
- Use "inTx" to wrap database operations in transactions.
- Do not update schema without absolute necessity.
- For complex fields, use "Json" type.

Events
- eventbus allows to send and receive events inside of the process and between different processes.
- eventbus is local or redis based.
- use "afterTx" to send events after transaction is committed successfully instead of directly emitting events.

Libraries
- Always use Zod for validation of inputs.
- Always use axios for HTTP requests.