@mthanh/vespercli 1.8.0 → 2.0.0

package/assets/instructions/java/java.instructions.md

@@ -1,81 +0,0 @@
----
-description: 'Guidelines for building Java base applications'
-applyTo: '**/*.java'
----
-
-# Java Development
-
-## General Instructions
-
-- First, prompt the user if they want to integrate static analysis tools (SonarQube, PMD, Checkstyle) into their project setup.
-  - If yes, document a recommended static-analysis setup. 
-    - Prefer SonarQube/SonarCloud (SonarLint in IDE + `sonar-scanner` in CI).
-    - Create a Sonar project key.
-    - Store the scanner token in CI secrets.
-    - Provide a sample CI job that runs the scanner.
-    - If the team declines Sonar, note this in the project README and continue.
-  - If Sonar is bound to the project:
-    - Use Sonar as the primary source of actionable issues.
-    - Reference Sonar rule keys in remediation guidance.
-  - If Sonar is unavailable:
-    - Perform up to 3 troubleshooting checks:
-      1. Verify project binding and token.
-      2. Ensure SonarScanner runs in CI.
-      3. Confirm SonarLint is installed and configured.
-    - If still failing after 3 attempts:
-      - Enable SpotBugs, PMD, or Checkstyle as CI fallbacks.
-      - Open a short tracker issue documenting the blocker and next steps.
-- If the user declines static analysis tools or wants to proceed without them, continue with implementing the Best practices, bug patterns and code smell prevention guidelines outlined below.
-- Address code smells proactively during development rather than accumulating technical debt.
-- Focus on readability, maintainability, and performance when refactoring identified issues.
-- Use IDE / Code editor reported warnings and suggestions to catch common patterns early in development.
-
-## Best practices
-
-- **Records**: For classes primarily intended to store data (e.g., DTOs, immutable data structures), **Java Records should be used instead of traditional classes**.
-- **Pattern Matching**: Utilize pattern matching for `instanceof` and `switch` expression to simplify conditional logic and type casting.
-- **Type Inference**: Use `var` for local variable declarations to improve readability, but only when the type is explicitly clear from the right-hand side of the expression.
-- **Immutability**: Favor immutable objects. Make classes and fields `final` where possible. Use collections from `List.of()`/`Map.of()` for fixed data. Use `Stream.toList()` to create immutable lists.
-- **Streams and Lambdas**: Use the Streams API and lambda expressions for collection processing. Employ method references (e.g., `stream.map(Foo::toBar)`).
-- **Null Handling**: Avoid returning or accepting `null`. Use `Optional<T>` for possibly-absent values and `Objects` utility methods like `equals()` and `requireNonNull()`.
-
-### Naming Conventions
-
-- Follow Google's Java style guide:
-  - `UpperCamelCase` for class and interface names.
-  - `lowerCamelCase` for method and variable names.
-  - `UPPER_SNAKE_CASE` for constants.
-  - `lowercase` for package names.
-- Use nouns for classes (`UserService`) and verbs for methods (`getUserById`).
-- Avoid abbreviations and Hungarian notation.
-
-### Common Bug Patterns
-
-Below are concise, human-readable rules you can apply regardless of which static analysis tool you use. If you run Sonar/SonarLint, the IDE will show the matching rule and location — direct Sonar connections are preferred and should override this ruleset.
-
-- Resource management — Always close resources (files, sockets, streams). Use try-with-resources where possible so resources are closed automatically.
-- Equality checks — Compare object equality with `.equals()` or `Objects.equals(...)` rather than `==` for non-primitives; this avoids reference-equality bugs.
-- Redundant casts — Remove unnecessary casts; prefer correct generic typing and let the compiler infer types where possible.
-- Reachable conditions — Avoid conditional expressions that are always true or false; they indicate bugs or dead code and should be corrected.
-
-For contributors who *do* use Sonar or SonarLint: the IDE/scan will show the specific rule key (for example, S2095 for resource leaks) and the affected file/line. Use that information to navigate to the exact location, then apply the recommended remediation.
-
-### Common Code Smells
-
-These patterns are phrased for humans; they map cleanly to checks in Sonar, SpotBugs, PMD, or Checkstyle but do not require those tools to be useful.
-
-- Parameter count — Keep method parameter lists short. If a method needs many params, consider grouping into a value object or using the builder pattern.
-- Method size — Keep methods focused and small. Extract helper methods to improve readability and testability.
-- Cognitive complexity — Reduce nested conditionals and heavy branching by extracting methods, using polymorphism, or applying the Strategy pattern.
-- Duplicated literals — Extract repeated strings and numbers into named constants or enums to reduce errors and ease changes.
-- Dead code — Remove unused variables and assignments. They confuse readers and can hide bugs.
-- Magic numbers — Replace numeric literals with named constants that explain intent (e.g., MAX_RETRIES).
-
-If you run a static analyzer like Sonar or SonarLint — direct Sonar connections are preferred and should override this ruleset. Sonar rule keys are useful for automation and suppression, but they are not required in day-to-day developer guidance.
-
-## Build and Verification
-
-- After adding or modifying code, verify the project continues to build successfully.
-- If the project uses Maven, run `mvn clean install`.
-- If the project uses Gradle, run `./gradlew build` (or `gradlew.bat build` on Windows).
-- Ensure all tests pass as part of the build.

package/assets/instructions/nestjs/nestjs.instructions.md

@@ -1,424 +0,0 @@
----
-description: 'NestJS development standards and best practices for building scalable Node.js server-side applications'
----
-
-# NestJS Development Best Practices
-
-## Your Mission
-
-As GitHub Copilot, you are an expert in NestJS development with deep knowledge of TypeScript, decorators, dependency injection, and modern Node.js patterns. Your goal is to guide developers in building scalable, maintainable, and well-architected server-side applications using NestJS framework principles and best practices.
-
-## Core NestJS Principles
-
-### **1. Dependency Injection (DI)**
-
-- **Principle:** NestJS uses a powerful DI container that manages the instantiation and lifetime of providers.
-- **Guidance for Copilot:**
-  - Use `@Injectable()` decorator for services, repositories, and other providers
-  - Inject dependencies through constructor parameters with proper typing
-  - Prefer interface-based dependency injection for better testability
-  - Use custom providers when you need specific instantiation logic
-
-### **2. Modular Architecture**
-
-- **Principle:** Organize code into feature modules that encapsulate related functionality.
-- **Guidance for Copilot:**
-  - Create feature modules with `@Module()` decorator
-  - Import only necessary modules and avoid circular dependencies
-  - Use `forRoot()` and `forFeature()` patterns for configurable modules
-  - Implement shared modules for common functionality
-
-### **3. Decorators and Metadata**
-
-- **Principle:** Leverage decorators to define routes, middleware, guards, and other framework features.
-- **Guidance for Copilot:**
-  - Use appropriate decorators: `@Controller()`, `@Get()`, `@Post()`, `@Injectable()`
-  - Apply validation decorators from `class-validator` library
-  - Use custom decorators for cross-cutting concerns
-  - Implement metadata reflection for advanced scenarios
-
-## Project Structure Best Practices
-
-### **Recommended Directory Structure**
-
-```
-src/
-├── app.module.ts
-├── main.ts
-├── common/
-│   ├── decorators/
-│   ├── filters/
-│   ├── guards/
-│   ├── interceptors/
-│   ├── pipes/
-│   └── interfaces/
-├── config/
-├── modules/
-│   ├── auth/
-│   ├── users/
-│   └── products/
-└── shared/
-    ├── services/
-    └── constants/
-```
-
-### **File Naming Conventions**
-
-- **Controllers:** `*.controller.ts` (e.g., `users.controller.ts`)
-- **Services:** `*.service.ts` (e.g., `users.service.ts`)
-- **Modules:** `*.module.ts` (e.g., `users.module.ts`)
-- **DTOs:** `*.dto.ts` (e.g., `create-user.dto.ts`)
-- **Entities:** `*.entity.ts` (e.g., `user.entity.ts`)
-- **Guards:** `*.guard.ts` (e.g., `auth.guard.ts`)
-- **Interceptors:** `*.interceptor.ts` (e.g., `logging.interceptor.ts`)
-- **Pipes:** `*.pipe.ts` (e.g., `validation.pipe.ts`)
-- **Filters:** `*.filter.ts` (e.g., `http-exception.filter.ts`)
-
-## API Development Patterns
-
-### **1. Controllers**
-
-- Keep controllers thin - delegate business logic to services
-- Use proper HTTP methods and status codes
-- Implement comprehensive input validation with DTOs
-- Apply guards and interceptors at the appropriate level
-
-```typescript
-@Controller('users')
-@UseGuards(AuthGuard)
-export class UsersController {
-	constructor(private readonly usersService: UsersService) {}
-
-	@Get()
-	@UseInterceptors(TransformInterceptor)
-	async findAll(@Query() query: GetUsersDto): Promise<User[]> {
-		return this.usersService.findAll(query);
-	}
-
-	@Post()
-	@UsePipes(ValidationPipe)
-	async create(@Body() createUserDto: CreateUserDto): Promise<User> {
-		return this.usersService.create(createUserDto);
-	}
-}
-```
-
-### **2. Services**
-
-- Implement business logic in services, not controllers
-- Use constructor-based dependency injection
-- Create focused, single-responsibility services
-- Handle errors appropriately and let filters catch them
-
-```typescript
-@Injectable()
-export class UsersService {
-	constructor(
-		@InjectRepository(User)
-		private readonly userRepository: Repository<User>,
-		private readonly emailService: EmailService,
-	) {}
-
-	async create(createUserDto: CreateUserDto): Promise<User> {
-		const user = this.userRepository.create(createUserDto);
-		const savedUser = await this.userRepository.save(user);
-		await this.emailService.sendWelcomeEmail(savedUser.email);
-		return savedUser;
-	}
-}
-```
-
-### **3. DTOs and Validation**
-
-- Use class-validator decorators for input validation
-- Create separate DTOs for different operations (create, update, query)
-- Implement proper transformation with class-transformer
-
-```typescript
-export class CreateUserDto {
-	@IsString()
-	@IsNotEmpty()
-	@Length(2, 50)
-	name: string;
-
-	@IsEmail()
-	email: string;
-
-	@IsString()
-	@MinLength(8)
-	@Matches(/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)/, {
-		message: 'Password must contain uppercase, lowercase and number',
-	})
-	password: string;
-}
-```
-
-## Database Integration
-
-### **TypeORM Integration**
-
-- Use TypeORM as the primary ORM for database operations
-- Define entities with proper decorators and relationships
-- Implement repository pattern for data access
-- Use migrations for database schema changes
-
-```typescript
-@Entity('users')
-export class User {
-	@PrimaryGeneratedColumn('uuid')
-	id: string;
-
-	@Column({ unique: true })
-	email: string;
-
-	@Column()
-	name: string;
-
-	@Column({ select: false })
-	password: string;
-
-	@OneToMany(() => Post, (post) => post.author)
-	posts: Post[];
-
-	@CreateDateColumn()
-	createdAt: Date;
-
-	@UpdateDateColumn()
-	updatedAt: Date;
-}
-```
-
-### **Custom Repositories**
-
-- Extend base repository functionality when needed
-- Implement complex queries in repository methods
-- Use query builders for dynamic queries
-
-## Authentication and Authorization
-
-### **JWT Authentication**
-
-- Implement JWT-based authentication with Passport
-- Use guards to protect routes
-- Create custom decorators for user context
-
-```typescript
-@Injectable()
-export class JwtAuthGuard extends AuthGuard('jwt') {
-	canActivate(context: ExecutionContext): boolean | Promise<boolean> {
-		return super.canActivate(context);
-	}
-
-	handleRequest(err: any, user: any, info: any) {
-		if (err || !user) {
-			throw err || new UnauthorizedException();
-		}
-		return user;
-	}
-}
-```
-
-### **Role-Based Access Control**
-
-- Implement RBAC using custom guards and decorators
-- Use metadata to define required roles
-- Create flexible permission systems
-
-```typescript
-@SetMetadata('roles', ['admin'])
-@UseGuards(JwtAuthGuard, RolesGuard)
-@Delete(':id')
-async remove(@Param('id') id: string): Promise<void> {
-  return this.usersService.remove(id);
-}
-```
-
-## Error Handling and Logging
-
-### **Exception Filters**
-
-- Create global exception filters for consistent error responses
-- Handle different types of exceptions appropriately
-- Log errors with proper context
-
-```typescript
-@Catch()
-export class AllExceptionsFilter implements ExceptionFilter {
-	private readonly logger = new Logger(AllExceptionsFilter.name);
-
-	catch(exception: unknown, host: ArgumentsHost): void {
-		const ctx = host.switchToHttp();
-		const response = ctx.getResponse<Response>();
-		const request = ctx.getRequest<Request>();
-
-		const status =
-			exception instanceof HttpException ? exception.getStatus() : HttpStatus.INTERNAL_SERVER_ERROR;
-
-		this.logger.error(`${request.method} ${request.url}`, exception);
-
-		response.status(status).json({
-			statusCode: status,
-			timestamp: new Date().toISOString(),
-			path: request.url,
-			message: exception instanceof HttpException ? exception.message : 'Internal server error',
-		});
-	}
-}
-```
-
-### **Logging**
-
-- Use built-in Logger class for consistent logging
-- Implement proper log levels (error, warn, log, debug, verbose)
-- Add contextual information to logs
-
-## Testing Strategies
-
-### **Unit Testing**
-
-- Test services independently using mocks
-- Use Jest as the testing framework
-- Create comprehensive test suites for business logic
-
-```typescript
-describe('UsersService', () => {
-	let service: UsersService;
-	let repository: Repository<User>;
-
-	beforeEach(async () => {
-		const module: TestingModule = await Test.createTestingModule({
-			providers: [
-				UsersService,
-				{
-					provide: getRepositoryToken(User),
-					useValue: {
-						create: jest.fn(),
-						save: jest.fn(),
-						find: jest.fn(),
-					},
-				},
-			],
-		}).compile();
-
-		service = module.get<UsersService>(UsersService);
-		repository = module.get<Repository<User>>(getRepositoryToken(User));
-	});
-
-	it('should create a user', async () => {
-		const createUserDto = { name: 'John', email: 'john@example.com' };
-		const user = { id: '1', ...createUserDto };
-
-		jest.spyOn(repository, 'create').mockReturnValue(user as User);
-		jest.spyOn(repository, 'save').mockResolvedValue(user as User);
-
-		expect(await service.create(createUserDto)).toEqual(user);
-	});
-});
-```
-
-### **Integration Testing**
-
-- Use TestingModule for integration tests
-- Test complete request/response cycles
-- Mock external dependencies appropriately
-
-### **E2E Testing**
-
-- Test complete application flows
-- Use supertest for HTTP testing
-- Test authentication and authorization flows
-
-## Performance and Security
-
-### **Performance Optimization**
-
-- Implement caching strategies with Redis
-- Use interceptors for response transformation
-- Optimize database queries with proper indexing
-- Implement pagination for large datasets
-
-### **Security Best Practices**
-
-- Validate all inputs using class-validator
-- Implement rate limiting to prevent abuse
-- Use CORS appropriately for cross-origin requests
-- Sanitize outputs to prevent XSS attacks
-- Use environment variables for sensitive configuration
-
-```typescript
-// Rate limiting example
-@Controller('auth')
-@UseGuards(ThrottlerGuard)
-export class AuthController {
-	@Post('login')
-	@Throttle(5, 60) // 5 requests per minute
-	async login(@Body() loginDto: LoginDto) {
-		return this.authService.login(loginDto);
-	}
-}
-```
-
-## Configuration Management
-
-### **Environment Configuration**
-
-- Use @nestjs/config for configuration management
-- Validate configuration at startup
-- Use different configs for different environments
-
-```typescript
-@Injectable()
-export class ConfigService {
-	constructor(
-		@Inject(CONFIGURATION_TOKEN)
-		private readonly config: Configuration,
-	) {}
-
-	get databaseUrl(): string {
-		return this.config.database.url;
-	}
-
-	get jwtSecret(): string {
-		return this.config.jwt.secret;
-	}
-}
-```
-
-## Common Pitfalls to Avoid
-
-- **Circular Dependencies:** Avoid importing modules that create circular references
-- **Heavy Controllers:** Don't put business logic in controllers
-- **Missing Error Handling:** Always handle errors appropriately
-- **Improper DI Usage:** Don't create instances manually when DI can handle it
-- **Missing Validation:** Always validate input data
-- **Synchronous Operations:** Use async/await for database and external API calls
-- **Memory Leaks:** Properly dispose of subscriptions and event listeners
-
-## Development Workflow
-
-### **Development Setup**
-
-1. Use NestJS CLI for scaffolding: `nest generate module users`
-2. Follow consistent file organization
-3. Use TypeScript strict mode
-4. Implement comprehensive linting with ESLint
-5. Use Prettier for code formatting
-
-### **Code Review Checklist**
-
-- [ ] Proper use of decorators and dependency injection
-- [ ] Input validation with DTOs and class-validator
-- [ ] Appropriate error handling and exception filters
-- [ ] Consistent naming conventions
-- [ ] Proper module organization and imports
-- [ ] Security considerations (authentication, authorization, input sanitization)
-- [ ] Performance considerations (caching, database optimization)
-- [ ] Comprehensive testing coverage
-
-## Conclusion
-
-NestJS provides a powerful, opinionated framework for building scalable Node.js applications. By following these best practices, you can create maintainable, testable, and efficient server-side applications that leverage the full power of TypeScript and modern development patterns.
-
----
-
-<!-- End of NestJS Instructions -->

package/assets/instructions/nextjs/nextjs.instructions.md

@@ -1,178 +0,0 @@
----
-description: 'NextJS development standards and best practices' 
----
-# Next.js Best Practices for LLMs (2025)
-
-_Last updated: July 2025_
-
-This document summarizes the latest, authoritative best practices for building, structuring, and maintaining Next.js applications. It is intended for use by LLMs and developers to ensure code quality, maintainability, and scalability.
- 
-
-## 1. Project Structure & Organization
-
-- **Use the `app/` directory** (App Router) for all new projects. Prefer it over the legacy `pages/` directory.
-- **Top-level folders:**
-  - `app/` — Routing, layouts, pages, and route handlers
-  - `public/` — Static assets (images, fonts, etc.)
-  - `lib/` — Shared utilities, API clients, and logic
-  - `components/` — Reusable UI components
-  - `contexts/` — React context providers
-  - `styles/` — Global and modular stylesheets
-  - `hooks/` — Custom React hooks
-  - `types/` — TypeScript type definitions
-- **Colocation:** Place files (components, styles, tests) near where they are used, but avoid deeply nested structures.
-- **Route Groups:** Use parentheses (e.g., `(admin)`) to group routes without affecting the URL path.
-- **Private Folders:** Prefix with `_` (e.g., `_internal`) to opt out of routing and signal implementation details.
-
-- **Feature Folders:** For large apps, group by feature (e.g., `app/dashboard/`, `app/auth/`).
-- **Use `src/`** (optional): Place all source code in `src/` to separate from config files.
-
-## 2.1. Server and Client Component Integration (App Router)
-
-**Never use `next/dynamic` with `{ ssr: false }` inside a Server Component.** This is not supported and will cause a build/runtime error.
-
-**Correct Approach:**
-
-- If you need to use a Client Component (e.g., a component that uses hooks, browser APIs, or client-only libraries) inside a Server Component, you must:
-  1. Move all client-only logic/UI into a dedicated Client Component (with `'use client'` at the top).
-  2. Import and use that Client Component directly in the Server Component (no need for `next/dynamic`).
-  3. If you need to compose multiple client-only elements (e.g., a navbar with a profile dropdown), create a single Client Component that contains all of them.
-
-**Example:**
-
-```tsx
-// Server Component
-import DashboardNavbar from '@/components/DashboardNavbar'
-
-export default async function DashboardPage() {
-  // ...server logic...
-  return (
-    <>
-      <DashboardNavbar /> {/* This is a Client Component */}
-      {/* ...rest of server-rendered page... */}
-    </>
-  )
-}
-```
-
-**Why:**
-
-- Server Components cannot use client-only features or dynamic imports with SSR disabled.
-- Client Components can be rendered inside Server Components, but not the other way around.
-
-**Summary:**
-Always move client-only UI into a Client Component and import it directly in your Server Component. Never use `next/dynamic` with `{ ssr: false }` in a Server Component.
-
-## 2.2. Data Fetching Strategy
-
-- **Real-time Lists**: For dynamic lists (users, properties, devices), prefer **Client-side Subscriptions** (SWR + Jotai) over Server Components fetching.
-  - **Why**: Enables real-time updates without page refreshes.
-  - **Pattern**: `page.tsx` (Server) -> `LayoutWrapper` (Client) -> `DataSubscriber` -> `Jotai Atom` -> `UI Component`.
-
-- **Static/SEO Content**: For public pages or static content, use **Server Components** with `await fetch()` or direct DB calls.
-
-- **Hybrid Approach**:
-  - Use Server Components for initial shell/layout.
-  - Use Client Components for the data-rich, interactive parts of the page.
-
----
-
-## 2. Component Best Practices
-
-- **Component Types:**
-  - **Server Components** (default): For data fetching, heavy logic, and non-interactive UI.
-  - **Client Components:** Add `'use client'` at the top. Use for interactivity, state, or browser APIs.
-- **When to Create a Component:**
-  - If a UI pattern is reused more than once.
-  - If a section of a page is complex or self-contained.
-  - If it improves readability or testability.
-- **Naming Conventions:**
-  - Use `PascalCase` for component files and exports (e.g., `UserCard.tsx`).
-  - Use `camelCase` for hooks (e.g., `useUser.ts`).
-  - Use `snake_case` or `kebab-case` for static assets (e.g., `logo_dark.svg`).
-  - Name context providers as `XyzProvider` (e.g., `ThemeProvider`).
-- **File Naming:**
-  - Match the component name to the file name.
-  - For single-export files, default export the component.
-  - For multiple related components, use an `index.ts` barrel file.
-- **Component Location:**
-  - Place shared components in `components/`.
-  - Place route-specific components inside the relevant route folder.
-- **Props:**
-  - Use TypeScript interfaces for props.
-  - Prefer explicit prop types and default values.
-- **Testing:**
-  - Co-locate tests with components (e.g., `UserCard.test.tsx`).
-- **Icon Usage (Remix Icons):**
-  - Use **Remix Icons** (`ri-*` class prefix) for all action buttons and UI elements
-  - Do NOT use `tabler-*` icons in tables or action buttons (may not render correctly)
-  - Common patterns:
-    - Edit: `ri-edit-box-line`
-    - Delete: `ri-delete-bin-7-line`
-    - View: `ri-eye-line`
-    - Download: `ri-download-line`
-    - Add: `ri-add-line` or `tabler-plus` (tabler OK for non-table contexts)
-  - Apply `text-textSecondary` class for consistent styling in tables
-  - Example: `<i className='ri-edit-box-line text-textSecondary' />`
-
-## 3. Naming Conventions (General)
-
-- **Folders:** `kebab-case` (e.g., `user-profile/`)
-- **Files:** `PascalCase` for components, `camelCase` for utilities/hooks, `kebab-case` for static assets
-- **Variables/Functions:** `camelCase`
-- **Types/Interfaces:** `PascalCase`
-- **Constants:** `UPPER_SNAKE_CASE`
-
-## 4. API Routes (Route Handlers)
-
-- **Prefer API Routes over Edge Functions** unless you need ultra-low latency or geographic distribution.
-- **Location:** Place API routes in `app/api/` (e.g., `app/api/users/route.ts`).
-- **HTTP Methods:** Export async functions named after HTTP verbs (`GET`, `POST`, etc.).
-- **Request/Response:** Use the Web `Request` and `Response` APIs. Use `NextRequest`/`NextResponse` for advanced features.
-- **Dynamic Segments:** Use `[param]` for dynamic API routes (e.g., `app/api/users/[id]/route.ts`).
-- **Validation:** Always validate and sanitize input. Use libraries like `zod` or `yup`.
-- **Error Handling:** Return appropriate HTTP status codes and error messages.
-- **Authentication:** Protect sensitive routes using middleware or server-side session checks.
-
-## 5. General Best Practices
-
-- **TypeScript:** Use TypeScript for all code. Enable `strict` mode in `tsconfig.json`.
-- **ESLint & Prettier:** Enforce code style and linting. Use the official Next.js ESLint config.
-- **Environment Variables:** Store secrets in `.env.local`. Never commit secrets to version control.
-- **Testing:** Use Jest, React Testing Library, or Playwright. Write tests for all critical logic and components.
-- **Accessibility:** Use semantic HTML and ARIA attributes. Test with screen readers.
-- **Performance:**
-  - Use built-in Image and Font optimization.
-  - Use Suspense and loading states for async data.
-  - Avoid large client bundles; keep most logic in Server Components.
-- **Security:**
-  - Sanitize all user input.
-  - Use HTTPS in production.
-  - Set secure HTTP headers.
-- **Documentation:**
-  - Write clear README and code comments.
-  - Document public APIs and components.
-
-## 6. Type Definitions & Data Flow
-
-- **Single Type System:**
-  - Do NOT create separate "Serializable" types (e.g., `SerializableUser` vs `User`).
-  - Define base types with `string` for dates (ISO 8601 format) to ensure serializability across Server/Client boundaries.
-  - Example: `createdAt: string` instead of `createdAt: Date | Timestamp`.
-- **Data Transformation:**
-  - Transform database objects (e.g., Firestore Timestamps) to ISO strings immediately at the data fetching layer.
-  - Use helper functions (e.g., `transformFirestoreToUser`) to ensure consistent shaping.
-- **Strict Typing:**
-  - Avoid `any`. Use `unknown` if type is truly uncertain, then narrow.
-  - Share types between Server Actions and Client Components via `src/types/`.
-
-# Avoid Unnecessary Example Files
-
-Do not create example/demo files (like ModalExample.tsx) in the main codebase unless the user specifically requests a live example, Storybook story, or explicit documentation component. Keep the repository clean and production-focused by default.
-
-# Always use the latest documentation and guides
-
-- For every nextjs related request, begin by searching for the most current nextjs documentation, guides, and examples.
-- Use the following tools to fetch and search documentation if they are available:
-  - `resolve_library_id` to resolve the package/library name in the docs.
-  - `get_library_docs` for up to date documentation.