@lenne.tech/cli 1.0.0 → 1.0.1

package/build/templates/claude-skills/nest-server-generator/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: nest-server-generator
-version: 1.0.0
+version: 1.0.3
 description: PRIMARY expert for ALL NestJS and @lenne.tech/nest-server tasks. ALWAYS use this skill when working in projects with @lenne.tech/nest-server in package.json dependencies (supports monorepos with projects/*, packages/*, apps/* structure), or when asked about NestJS modules, services, controllers, resolvers, models, objects, tests, server creation, debugging, or any NestJS/nest-server development task. Handles lt server commands, security analysis, test creation, and all backend development. ALWAYS reads CrudService base class before working with Services.
 ---
 
@@ -55,39 +55,68 @@ You are the **PRIMARY expert** for NestJS backend development and the @lenne.tec
 
 ## 🚨 CRITICAL SECURITY RULES - READ FIRST
 
-Before you start ANY work with this skill, understand these NON-NEGOTIABLE rules:
+**Before you start ANY work, understand these NON-NEGOTIABLE rules:**
 
 ### ⛔ NEVER Do This:
-1. **NEVER remove or weaken `@Restricted()` decorators** to make tests pass
-2. **NEVER change `@Roles()` decorators** to more permissive roles for test convenience
-3. **NEVER modify `securityCheck()` logic** to bypass security in tests
-4. **NEVER remove class-level `@Restricted(RoleEnum.ADMIN)`** - it's a security fallback
+1. **NEVER remove or weaken `@Restricted()` decorators**
+2. **NEVER change `@Roles()` decorators** to more permissive roles
+3. **NEVER modify `securityCheck()` logic** to bypass security
+4. **NEVER remove class-level `@Restricted(RoleEnum.ADMIN)`**
 
 ### ✅ ALWAYS Do This:
-1. **ALWAYS analyze permissions BEFORE writing tests** (Controller, Model, Service layers)
+1. **ALWAYS analyze permissions BEFORE writing tests**
 2. **ALWAYS test with the LEAST privileged user** who is authorized
-3. **ALWAYS create appropriate test users** for each permission level
-4. **ALWAYS adapt tests to security requirements**, never the other way around
-5. **ALWAYS ask developer for approval** before changing ANY security decorator
-6. **ALWAYS aim for maximum test coverage** (80-100% depending on criticality)
+3. **ALWAYS adapt tests to security requirements**, never vice versa
+4. **ALWAYS ask developer for approval** before changing ANY security decorator
+
+**📖 For complete security rules, testing guidelines, and examples, see: `security-rules.md`**
+
+## 🚨 CRITICAL: NEVER USE `declare` KEYWORD FOR PROPERTIES
+
+**⚠️ DO NOT use the `declare` keyword when defining properties in classes!**
+
+### Quick Rule
 
-### 🔑 Permission Hierarchy (Specific Overrides General):
 ```typescript
-@Restricted(RoleEnum.ADMIN)  // ← FALLBACK: DO NOT REMOVE
-export class ProductController {
-  @Roles(RoleEnum.S_USER)    // ← SPECIFIC: This method is more open
-  async createProduct() { }   // ← S_USER can access (specific wins)
+// ❌ WRONG
+export class ProductCreateInput extends ProductInput {
+  declare name: string;  // Decorator won't work!
+}
 
-  async secretMethod() { }    // ← ADMIN only (fallback applies)
+// ✅ CORRECT
+export class ProductCreateInput extends ProductInput {
+  @UnifiedField({ description: 'Product name' })
+  name: string;  // Decorator works properly
 }
 ```
 
-**Why class-level `@Restricted(ADMIN)` MUST stay:**
-- If someone forgets `@Roles()` on a new method → it's secure by default
-- Shows the class is security-sensitive
-- Fail-safe protection
+**Why**: `declare` prevents decorators from being applied, breaking the decorator system.
+
+**📖 For detailed explanation and correct patterns, see: `declare-keyword-warning.md`**
+
+## 🚨 CRITICAL: DESCRIPTION MANAGEMENT
+
+**⚠️ COMMON MISTAKE:** Descriptions are often applied inconsistently. You MUST follow this process for EVERY component.
 
-**See "CRITICAL: Security & Test Coverage Rules" section for complete details.**
+### 3-Step Process
+
+**1. Extract descriptions** from user's `// comments`
+
+**2. Format correctly:**
+- English input → `'Product name'`
+- German input → `'Product name (Produktname)'`
+- **⚠️ Fix typos ONLY, NEVER change wording!**
+
+**3. Apply EVERYWHERE:**
+- Model file
+- Create Input file
+- Update Input file
+- Object files (if SubObject)
+- Class-level @ObjectType() decorators
+
+**📖 For detailed formatting rules, examples, and verification checklist, see: `description-management.md`**
+
+---
 
 ## Core Responsibilities
 
@@ -190,38 +219,22 @@ export class ProductService extends CrudService<Product> {
 
 ## Configuration File (lt.config.json)
 
-The lenne.tech CLI supports project-level configuration via `lt.config.json` files. This allows you to set default values for commands, eliminating the need for repeated CLI parameters or interactive prompts.
+The lenne.tech CLI supports project-level configuration via `lt.config.json` files to set default values for commands.
 
-### File Location and Hierarchy
+**📖 For complete configuration guide including structure, options, and examples, see: `configuration.md`**
 
-- **Location**: Place `lt.config.json` in your project root or any parent directory
-- **Hierarchy**: The CLI searches from the current directory up to the root, merging configurations
-- **Priority** (lowest to highest):
-  1. Default values (hardcoded in CLI)
-  2. Config from parent directories (higher up = lower priority)
-  3. Config from current directory
-  4. CLI parameters (`--flag value`)
-  5. Interactive user input
-
-### Configuration Structure
+**Quick reference:**
+- **Location**: Project root or parent directories
+- **Priority**: CLI parameters > Interactive input > Config file > Defaults
+- **Key option**: `commands.server.module.controller` - Sets default controller type ("Rest" | "GraphQL" | "Both" | "auto")
 
+**Example config:**
 ```json
 {
-  "meta": {
-    "version": "1.0.0",
-    "name": "My Project",
-    "description": "Optional project description"
-  },
   "commands": {
     "server": {
       "module": {
-        "controller": "Both",
-        "skipLint": false
-      },
-      "object": {
-        "skipLint": false
-      },
-      "addProp": {
+        "controller": "Rest",
         "skipLint": false
       }
     }
@@ -229,238 +242,8 @@ The lenne.tech CLI supports project-level configuration via `lt.config.json` fil
 }
 ```
 
-### Available Configuration Options
-
-**Server Module Configuration (`commands.server.module`)**:
-- `controller`: Default controller type (`"Rest"` | `"GraphQL"` | `"Both"` | `"auto"`)
-- `skipLint`: Skip lint prompt after module creation (boolean)
-
-**Server Object Configuration (`commands.server.object`)**:
-- `skipLint`: Skip lint prompt after object creation (boolean)
-
-**Server AddProp Configuration (`commands.server.addProp`)**:
-- `skipLint`: Skip lint prompt after adding property (boolean)
-
-### Using Configuration in Commands
-
-**Example 1: Configure controller type globally**
-```json
-{
-  "commands": {
-    "server": {
-      "module": {
-        "controller": "Rest"
-      }
-    }
-  }
-}
-```
-
-Now all `lt server module` commands will default to REST controllers:
-```bash
-# Uses "Rest" from config (no prompt)
-lt server module --name Product --prop-name-0 name --prop-type-0 string
-```
-
-**Example 2: Override config with CLI parameter**
-```bash
-# Ignores config, uses GraphQL
-lt server module --name Product --controller GraphQL
-```
-
-**Example 3: Auto-detect from config**
-```json
-{
-  "commands": {
-    "server": {
-      "module": {
-        "controller": "auto"
-      }
-    }
-  }
-}
-```
-
-Now the CLI will auto-detect controller type from existing modules without prompting.
-
-### Managing Configuration
-
-**Initialize configuration**:
-```bash
-lt config init
-```
-
-**Show current configuration** (merged from all hierarchy levels):
-```bash
-lt config show
-```
-
-**Get help**:
-```bash
-lt config help
-```
-
-### When to Use Configuration
-
-**✅ Use configuration when:**
-- Creating multiple modules with the same controller type
-- Working in a team with agreed-upon conventions
-- Automating module generation in CI/CD
-- You want to skip repetitive prompts
-
-**❌ Don't use configuration when:**
-- Creating a single module with specific requirements
-- Each module needs a different controller type
-- You're just testing or experimenting
-
-### Best Practices
-
-1. **Project Root**: Place `lt.config.json` in your project root
-2. **Version Control**: Commit the config file to share with your team
-3. **Documentation**: Add a README note explaining the config choices
-4. **Override When Needed**: Use CLI parameters to override for special cases
-
-### 🎯 IMPORTANT: Configuration After Server Creation
-
-**CRITICAL WORKFLOW**: After creating a new server with `lt server create`, you **MUST** initialize the configuration file to set project conventions.
-
-#### Automatic Post-Creation Setup
-
-When you create a new NestJS server, immediately follow these steps:
-
-1. **Navigate to the API directory**:
-   ```bash
-   cd projects/api
-   ```
-
-2. **Create the configuration file manually**:
-   ```bash
-   # Create lt.config.json with controller preference
-   ```
-
-3. **Ask the developer for their preference** (if not already specified):
-   ```
-   What controller type do you prefer for new modules in this project?
-   1. Rest - REST controllers only
-   2. GraphQL - GraphQL resolvers only
-   3. Both - Both REST and GraphQL
-   4. auto - Auto-detect from existing modules
-   ```
-
-4. **Write the configuration** based on the answer:
-   ```json
-   {
-     "meta": {
-       "version": "1.0.0"
-     },
-     "commands": {
-       "server": {
-         "module": {
-           "controller": "Rest"
-         }
-       }
-     }
-   }
-   ```
-
-#### Why This Is Important
-
-- ✅ **Consistency**: All modules will follow the same pattern
-- ✅ **No Prompts**: Developers won't be asked for controller type repeatedly
-- ✅ **Team Alignment**: Everyone uses the same conventions
-- ✅ **Automation**: Scripts and CI/CD can create modules without interaction
-
-#### Example Workflow
-
-```bash
-# User creates new server
-lt server create --name MyAPI
-
-# You (Claude) navigate to API directory
-cd projects/api
-
-# You ask the user
-"I've created the server. What controller type would you like to use for modules?"
-"1. Rest (REST only)"
-"2. GraphQL (GraphQL only)"
-"3. Both (REST + GraphQL)"
-"4. auto (Auto-detect)"
-
-# User answers: "Rest"
-
-# You create lt.config.json
-{
-  "meta": {
-    "version": "1.0.0"
-  },
-  "commands": {
-    "server": {
-      "module": {
-        "controller": "Rest"
-      }
-    }
-  }
-}
-
-# Confirm to user
-"✅ Configuration saved! All new modules will default to REST controllers."
-"You can change this anytime by editing lt.config.json or running 'lt config init'."
-```
-
-#### Configuration Options Explained
-
-**"Rest"**:
-- ✅ Creates REST controllers (`@Controller()`)
-- ❌ No GraphQL resolvers
-- ❌ No PubSub integration
-- **Best for**: Traditional REST APIs, microservices
-
-**"GraphQL"**:
-- ❌ No REST controllers
-- ✅ Creates GraphQL resolvers (`@Resolver()`)
-- ✅ Includes PubSub for subscriptions
-- **Best for**: GraphQL-first APIs, real-time apps
-
-**"Both"**:
-- ✅ Creates REST controllers
-- ✅ Creates GraphQL resolvers
-- ✅ Includes PubSub
-- **Best for**: Hybrid APIs, gradual migration
-
-**"auto"**:
-- 🤖 Analyzes existing modules
-- 🤖 Detects pattern automatically
-- 🤖 No user prompt
-- **Best for**: Following existing conventions
-
-#### When NOT to Create Config
-
-Skip config creation if:
-- ❌ User is just testing/experimenting
-- ❌ User explicitly says "no configuration"
-- ❌ Project already has lt.config.json
-
-### Integration with Commands
-
-When generating code, **ALWAYS check for configuration**:
-1. Load config via `lt config show` or check for `lt.config.json`
-2. Use configured values in command construction
-3. Only pass CLI parameters when overriding config
-
-**Example: Generating module with config**
-```bash
-# Check if config exists and what controller type is configured
-# If config has "controller": "Rest", use it
-lt server module --name Product --prop-name-0 name --prop-type-0 string
-
-# If config has "controller": "auto", let CLI detect
-lt server module --name Order --prop-name-0 total --prop-type-0 number
-
-# Override config when needed
-lt server module --name User --controller Both
-```
-
-## Command Syntax Reference
+**Initialize config**: `lt config init`
+**Show current config**: `lt config show`
 
 ### lt server module
 Creates a complete NestJS module with model, service, controller/resolver, and DTOs.
@@ -876,29 +659,177 @@ export class BuyerProfile extends Profile { ... }
 
 ### Phase 5: Description Management
 
-**Rule**: All descriptions follow format: `"ENGLISH_DESCRIPTION (DEUTSCHE_BESCHREIBUNG)"`
+**⚠️ CRITICAL PHASE - Refer to "CRITICAL: DESCRIPTION MANAGEMENT" section at the top of this document!**
+
+This phase is often done incorrectly. Follow these steps EXACTLY:
+
+#### Step 5.1: Extract Descriptions from User Input
+
+**BEFORE applying any descriptions, review the original specification:**
+
+Go back to the user's original specification and extract ALL comments that appear after `//`:
+
+```
+Module: Product
+- name: string // Product name
+- price: number // Produktpreis
+- description?: string // Produktbeschreibung
+- stock: number // Current inventory
+
+SubObject: Address
+- street: string // Straße
+- city: string // City name
+- zipCode: string // Postleitzahl
+```
+
+**Create a mapping**:
+```
+Product.name → "Product name" (English)
+Product.price → "Produktpreis" (German)
+Product.description → "Produktbeschreibung" (German)
+Product.stock → "Current inventory" (English)
+Address.street → "Straße" (German)
+Address.city → "City name" (English)
+Address.zipCode → "Postleitzahl" (German)
+```
+
+#### Step 5.2: Format Descriptions
+
+**Rule**: `"ENGLISH_DESCRIPTION (DEUTSCHE_BESCHREIBUNG)"`
 
-**Process for each property**:
+Apply formatting rules:
 
 1. **If comment is in English**:
    ```
-   // Street name
+   // Product name
    ```
-   → Use as: `description: 'Street name'`
+   → Use as: `description: 'Product name'`
+
+   Fix typos if needed:
+   ```
+   // Prodcut name  (typo)
+   ```
+   → Use as: `description: 'Product name'` (typo corrected)
 
 2. **If comment is in German**:
+   ```
+   // Produktpreis
+   ```
+   → Translate and add original: `description: 'Product price (Produktpreis)'`
+
    ```
    // Straße
    ```
    → Translate and add original: `description: 'Street (Straße)'`
 
-3. **If no comment**:
-   → Create meaningful description: `description: 'User email address'`
+   Fix typos in original:
+   ```
+   // Postleizahl  (typo: missing 't')
+   ```
+   → Translate and add corrected: `description: 'Postal code (Postleitzahl)'`
+
+3. **If no comment provided**:
+   → Create meaningful English description: `description: 'User email address'`
+
+**⚠️ CRITICAL - Preserve Original Wording**:
+
+- ✅ **DO:** Fix spelling/typos only
+- ❌ **DON'T:** Rephrase, expand, or improve wording
+- ❌ **DON'T:** Change terms (they may be predefined/referenced by external systems)
+
+**Examples**:
+```
+✅ CORRECT:
+// Straße → 'Street (Straße)'  (preserve word)
+// Produkt → 'Product (Produkt)'  (don't add "name")
+// Status → 'Status (Status)'  (same in both languages)
+
+❌ WRONG:
+// Straße → 'Street name (Straßenname)'  (changed word!)
+// Produkt → 'Product name (Produktname)'  (added word!)
+// Status → 'Current status (Aktueller Status)'  (added word!)
+```
+
+#### Step 5.3: Apply Descriptions EVERYWHERE
+
+**🚨 MOST IMPORTANT: Apply SAME description to ALL files!**
+
+For **EVERY property in EVERY Module**:
+
+1. Open `<module>.model.ts` → Add description to property
+2. Open `inputs/<module>-create.input.ts` → Add SAME description to property
+3. Open `inputs/<module>.input.ts` → Add SAME description to property
+
+For **EVERY property in EVERY SubObject**:
+
+1. Open `objects/<object>/<object>.object.ts` → Add description to property
+2. Open `objects/<object>/<object>-create.input.ts` → Add SAME description to property
+3. Open `objects/<object>/<object>.input.ts` → Add SAME description to property
+
+**Example for Module "Product" with property "price"**:
+
+```typescript
+// File: src/server/modules/product/product.model.ts
+@UnifiedField({ description: 'Product price (Produktpreis)' })
+price: number;
+
+// File: src/server/modules/product/inputs/product-create.input.ts
+@UnifiedField({ description: 'Product price (Produktpreis)' })
+price: number;
+
+// File: src/server/modules/product/inputs/product.input.ts
+@UnifiedField({ description: 'Product price (Produktpreis)' })
+price?: number;
+```
+
+**Example for SubObject "Address" with property "street"**:
+
+```typescript
+// File: src/server/common/objects/address/address.object.ts
+@UnifiedField({ description: 'Street (Straße)' })
+street: string;
+
+// File: src/server/common/objects/address/address-create.input.ts
+@UnifiedField({ description: 'Street (Straße)' })
+street: string;
+
+// File: src/server/common/objects/address/address.input.ts
+@UnifiedField({ description: 'Street (Straße)' })
+street?: string;
+```
+
+#### Step 5.4: Add Class-Level Descriptions
+
+Also add descriptions to the `@ObjectType()` and `@InputType()` decorators:
+
+```typescript
+@ObjectType({ description: 'Product entity (Produkt-Entität)' })
+export class Product extends CoreModel { ... }
+
+@InputType({ description: 'Product creation data (Produkt-Erstellungsdaten)' })
+export class ProductCreateInput { ... }
+
+@InputType({ description: 'Product update data (Produkt-Aktualisierungsdaten)' })
+export class ProductInput { ... }
+```
+
+#### Step 5.5: Verify Consistency
+
+After applying all descriptions, verify:
+
+- [ ] All user-provided comments extracted and processed
+- [ ] All German descriptions translated to format: `ENGLISH (DEUTSCH)`
+- [ ] All English descriptions kept as-is
+- [ ] Module Model has descriptions on all properties
+- [ ] Module CreateInput has SAME descriptions on all properties
+- [ ] Module UpdateInput has SAME descriptions on all properties
+- [ ] SubObject has descriptions on all properties
+- [ ] SubObject CreateInput has SAME descriptions on all properties
+- [ ] SubObject UpdateInput has SAME descriptions on all properties
+- [ ] Class-level decorators have descriptions
+- [ ] NO inconsistencies (same property, different descriptions)
 
-4. **Apply same description to**:
-   - Model property
-   - Input property (both create and update)
-   - Output property
+**If ANY checkbox is unchecked, STOP and fix before continuing to Phase 6!**
 
 ### Phase 6: Enum File Creation
 
@@ -920,6 +851,99 @@ export enum StatusEnum {
 
 ### Phase 7: API Test Creation
 
+**⚠️ CRITICAL: Test Type Requirement**
+
+**ONLY create API tests using TestHelper - NEVER create direct Service tests!**
+
+- ✅ **DO:** Create tests that call REST endpoints or GraphQL queries/mutations using `TestHelper`
+- ✅ **DO:** Test through the API layer (Controller/Resolver → Service → Database)
+- ❌ **DON'T:** Create tests that directly instantiate or call Service methods
+- ❌ **DON'T:** Create unit tests for Services (e.g., `user.service.spec.ts`)
+- ❌ **DON'T:** Mock dependencies or bypass the API layer
+
+**Why API tests only?**
+- API tests validate the complete security model (decorators, guards, permissions)
+- Direct Service tests bypass authentication and authorization checks
+- TestHelper provides all necessary tools for comprehensive API testing
+
+**Exception: Direct database/service access for test setup/cleanup ONLY**
+
+Direct database or service access is ONLY allowed for:
+
+- ✅ **Test Setup (beforeAll/beforeEach)**:
+  - Setting user roles in database: `await db.collection('users').updateOne({ _id: userId }, { $set: { roles: ['admin'] } })`
+  - Setting verified flag: `await db.collection('users').updateOne({ _id: userId }, { $set: { verified: true } })`
+  - Creating prerequisite test data that can't be created via API
+
+- ✅ **Test Cleanup (afterAll/afterEach)**:
+  - Deleting test objects: `await db.collection('products').deleteMany({ createdBy: testUserId })`
+  - Cleaning up test data: `await db.collection('users').deleteOne({ email: 'test@example.com' })`
+
+- ❌ **NEVER for testing functionality**:
+  - Don't call `userService.create()` to test user creation - use API endpoint!
+  - Don't call `productService.update()` to test updates - use API endpoint!
+  - Don't access database to verify results - query via API instead!
+
+**Example of correct usage:**
+
+```typescript
+describe('Product Tests', () => {
+  let adminToken: string;
+  let userId: string;
+
+  beforeAll(async () => {
+    // ✅ ALLOWED: Direct DB access for setup
+    const user = await testHelper.rest('/auth/signup', {
+      method: 'POST',
+      payload: { email: 'admin@test.com', password: 'password' }
+    });
+    userId = user.id;
+
+    // ✅ ALLOWED: Direct DB manipulation for test setup
+    await db.collection('users').updateOne(
+      { _id: new ObjectId(userId) },
+      { $set: { roles: ['admin'], verified: true } }
+    );
+
+    // Get token via API
+    const auth = await testHelper.rest('/auth/signin', {
+      method: 'POST',
+      payload: { email: 'admin@test.com', password: 'password' }
+    });
+    adminToken = auth.token;
+  });
+
+  it('should create product', async () => {
+    // ✅ CORRECT: Test via API
+    const result = await testHelper.rest('/api/products', {
+      method: 'POST',
+      payload: { name: 'Test Product' },
+      token: adminToken
+    });
+
+    expect(result.name).toBe('Test Product');
+
+    // ❌ WRONG: Don't verify via DB
+    // const dbProduct = await db.collection('products').findOne({ _id: result.id });
+
+    // ✅ CORRECT: Verify via API
+    const fetched = await testHelper.rest(`/api/products/${result.id}`, {
+      method: 'GET',
+      token: adminToken
+    });
+    expect(fetched.name).toBe('Test Product');
+  });
+
+  afterAll(async () => {
+    // ✅ ALLOWED: Direct DB access for cleanup
+    await db.collection('products').deleteMany({ createdBy: userId });
+    await db.collection('users').deleteOne({ _id: new ObjectId(userId) });
+  });
+});
+```
+
+---
+
 **⚠️ CRITICAL: Test Creation Process**
 
 Creating API tests is NOT just about testing functionality - it's about **validating the security model**. You MUST follow this exact process:
@@ -1594,7 +1618,20 @@ After generation, verify:
 - [ ] All Objects created
 - [ ] All Modules created
 - [ ] All properties in alphabetical order
-- [ ] All descriptions follow format: "ENGLISH (DEUTSCH)"
+- [ ] **DESCRIPTIONS (Critical - check thoroughly):**
+  - [ ] All user-provided comments (after `//`) extracted from specification
+  - [ ] All German descriptions translated to format: `ENGLISH (DEUTSCH)`
+  - [ ] All English descriptions kept as-is (spelling corrected)
+  - [ ] ALL Module Models have descriptions on all properties
+  - [ ] ALL Module CreateInputs have SAME descriptions
+  - [ ] ALL Module UpdateInputs have SAME descriptions
+  - [ ] ALL SubObjects have descriptions on all properties
+  - [ ] ALL SubObject CreateInputs have SAME descriptions
+  - [ ] ALL SubObject UpdateInputs have SAME descriptions
+  - [ ] ALL `@ObjectType()` decorators have descriptions
+  - [ ] ALL `@InputType()` decorators have descriptions
+  - [ ] NO inconsistencies (same property, different descriptions in different files)
+  - [ ] NO German-only descriptions (must be translated)
 - [ ] Inheritance properly implemented
 - [ ] Required fields correctly set in CreateInputs
 - [ ] Enum files created in `src/server/common/enums/`
@@ -1747,1036 +1784,57 @@ import { User } from '../../user/user.model';
 
 ## ⚠️ CRITICAL: Security & Test Coverage Rules
 
-### Rule 1: NEVER Weaken Security for Test Convenience
-
-**❌ ABSOLUTELY FORBIDDEN:**
-```typescript
-// BEFORE (secure):
-@Restricted(RoleEnum.ADMIN)
-export class ProductController {
-  @Roles(RoleEnum.S_USER)
-  async createProduct() { ... }
-}
-
-// AFTER (FORBIDDEN - security weakened!):
-// @Restricted(RoleEnum.ADMIN)  ← NEVER remove this!
-export class ProductController {
-  @Roles(RoleEnum.S_USER)
-  async createProduct() { ... }
-}
-```
-
-**🚨 CRITICAL RULE:**
-- **NEVER remove or weaken `@Restricted()` decorators** on Controllers, Resolvers, Models, or Objects
-- **NEVER change `@Roles()` decorators** to more permissive roles just to make tests pass
-- **NEVER modify `securityCheck()` logic** to bypass security for testing
-
-**If tests fail due to permissions:**
-1. ✅ **CORRECT**: Adjust the test to use the appropriate user/token
-2. ✅ **CORRECT**: Create test users with the required roles
-3. ❌ **WRONG**: Weaken security to make tests pass
-
-**Any security changes MUST:**
-- Be discussed with the developer FIRST
-- Have a solid business justification
-- Be explicitly approved by the developer
-- Be documented with the reason
-
-### Rule 2: Understanding Permission Hierarchy
-
-**⭐ Key Concept: Specific Overrides General**
-
-The `@Restricted()` decorator on a class acts as a **security fallback** - if a method/property doesn't specify permissions, it inherits the class-level restriction. This is a **security-by-default** pattern.
-
-**Example - Controller/Resolver:**
-```typescript
-@Restricted(RoleEnum.ADMIN)  // ← FALLBACK: Protects everything by default
-export class ProductController {
-
-  @Roles(RoleEnum.S_EVERYONE)  // ← SPECIFIC: This method is MORE open
-  async getPublicProducts() {
-    // Anyone can access this
-  }
-
-  @Roles(RoleEnum.S_USER)      // ← SPECIFIC: This method is MORE open
-  async getMyProducts() {
-    // Any signed-in user can access this
-  }
-
-  async adminOnlyMethod() {     // ← NO DECORATOR: Falls back to @Restricted(ADMIN)
-    // Only admins can access this
-  }
-}
-```
-
-**Why `@Restricted(RoleEnum.ADMIN)` MUST stay:**
-- **Fail-safe**: If someone forgets `@Roles()` on a new method, it's protected by default
-- **Security**: Without it, a method without `@Roles()` would be open to everyone
-- **Intent**: Shows the class is security-sensitive
-
-**Example - Model/Object:**
-```typescript
-@Restricted(RoleEnum.ADMIN)  // ← FALLBACK: Protects all properties by default
-export class Product extends CoreModel {
-
-  @Restricted(RoleEnum.S_EVERYONE)  // ← SPECIFIC: This field is MORE open
-  name: string;
-
-  @Restricted(RoleEnum.S_USER)      // ← SPECIFIC: This field is MORE open
-  description: string;
-
-  secretInternalNotes: string;      // ← NO DECORATOR: Falls back to ADMIN only
-
-  securityCheck(user: User) {
-    // Controls who can see the entire object
-    if (user?.hasRole(RoleEnum.ADMIN)) return this;
-    if (this.isPublic) return this;
-    return undefined;
-  }
-}
-```
-
-### Rule 3: Test Coverage Strategy
+**This section provides detailed rules for security and testing. It's duplicated at the beginning of this file for visibility.**
 
-**🎯 Goal: Maximum Coverage WITHOUT Compromising Security**
-
-**Approach:**
-1. **Analyze permissions thoroughly** (as described in Phase 7)
-2. **Create appropriate test users** for each permission level:
-   ```typescript
-   const adminUser = await testHelper.createUser({ roles: [RoleEnum.ADMIN] });
-   const regularUser = await testHelper.createUser({ roles: [RoleEnum.S_USER] });
-   const creatorUser = await testHelper.createUser({ roles: [RoleEnum.S_USER] });
-   ```
-3. **Test with the LEAST privileged user** who should have access
-4. **Also test with UNAUTHORIZED users** to verify security
-5. **Document why certain operations require certain roles**
-
-**Coverage Priorities:**
-1. **100% coverage** for all security-critical code (securityCheck, guards)
-2. **100% coverage** for all endpoints (both success and failure cases)
-3. **100% coverage** for all permission combinations
-4. **90%+ coverage** for business logic
-5. **Complete coverage** of error paths and edge cases
-
-**Testing Strategy:**
-```typescript
-describe('ProductController', () => {
-  describe('createProduct', () => {
-    // Test with minimum required privilege
-    it('should create product as S_USER', async () => {
-      // ✅ Tests with least privileged user who should succeed
-    });
+**📖 For the complete content with all rules, examples, and testing strategies, see: `security-rules.md`**
 
-    // Test security failure
-    it('should FAIL to create product without auth', async () => {
-      // ✅ Verifies security works
-    });
-  });
+**Quick reminder - Core rules:**
+1. **NEVER weaken @Restricted or @Roles decorators** to make tests pass
+2. **NEVER modify securityCheck() logic** to bypass security
+3. **ALWAYS test with least privileged user** who is authorized
+4. **ALWAYS create appropriate test users** for each permission level
+5. **ALWAYS ask developer** before changing ANY security decorator
+6. **Aim for 80-100% test coverage** without compromising security
 
-  describe('adminOnlyMethod', () => {
-    it('should execute as admin', async () => {
-      // ✅ Uses admin token (required for this method)
-    });
+**Testing approach:**
+- Analyze permissions first
+- Create test users for each role
+- Test happy path with appropriate user
+- Test security failures (403 responses)
+- Document why certain roles are required
 
-    it('should FAIL for regular user', async () => {
-      // ✅ Verifies fallback to @Restricted(ADMIN) works
-    });
+## Phase 8: Pre-Report Quality Review
 
-    it('should FAIL without auth', async () => {
-      // ✅ Verifies security
-    });
-  });
-});
-```
-
-### Rule 4: When Security Changes Are Necessary
-
-**If you genuinely believe a security restriction is too strict:**
-
-1. **STOP** - Do NOT make the change
-2. **Analyze** - Why is the restriction failing the test?
-3. **Document** - Prepare a clear explanation:
-   - What restriction exists?
-   - Why does it block the test?
-   - What business case requires opening it?
-   - What security risks does opening it introduce?
-   - What mitigation strategies exist?
-4. **Ask the developer**:
-   ```
-   "I've analyzed the permissions for [Method/Property] and found:
-   - Current restriction: @Restricted(RoleEnum.ADMIN)
-   - Test requirement: S_USER needs access to [do X]
-   - Business justification: [explain why]
-   - Security impact: [explain risks]
-   - Mitigation: [how to minimize risk]
-
-   Should I:
-   A) Keep security as-is and adjust the test
-   B) Change to @Restricted(RoleEnum.S_USER) with your approval
-   C) Something else?"
-   ```
-5. **Wait for explicit approval** before changing ANY security decorator
-6. **Document the decision** in code comments:
-   ```typescript
-   // Changed from ADMIN to S_USER on 2024-01-15
-   // Reason: Users need to create their own products
-   // Approved by: [Developer Name]
-   @Restricted(RoleEnum.S_USER)
-   ```
-
-**Remember:**
-- Security is NOT negotiable for test convenience
-- Tests must adapt to security requirements, not vice versa
-- When in doubt, keep it secure and ask
-
-## Phase 8: Pre-Report Quality Review
-
-**CRITICAL**: Before creating the final report, you MUST perform a comprehensive quality review:
-
-### Step 1: Identify All Changes
-
-Use git to identify all created and modified files:
-
-```bash
-git status --short
-git diff --name-only
-```
-
-For each file, review:
-- All newly created files
-- All modified files
-- File structure and organization
-
-### Step 2: Test Management
-
-**CRITICAL**: Ensure tests are created/updated for all changes:
-
-#### Step 2.1: Analyze Existing Tests FIRST
-
-**BEFORE creating or modifying ANY tests, you MUST thoroughly analyze existing tests**:
-
-1. **Identify all existing test files**:
-   ```bash
-   # List all test directories and files
-   ls -la tests/
-   ls -la tests/modules/
-   find tests -name "*.e2e-spec.ts" -type f
-   ```
-
-2. **Read multiple existing test files completely**:
-   ```bash
-   # Read at least 2-3 different module tests to understand patterns
-   cat tests/modules/user.e2e-spec.ts
-   cat tests/modules/<another-module>.e2e-spec.ts
-
-   # Also check the common and project test files
-   cat tests/common.e2e-spec.ts
-   cat tests/project.e2e-spec.ts
-   ```
-
-3. **CRITICAL: Understand the TestHelper thoroughly**:
-
-   **Before creating any tests, you MUST understand the TestHelper from @lenne.tech/nest-server**:
-
-   ```bash
-   # Read the TestHelper source code to understand its capabilities
-   cat node_modules/@lenne.tech/nest-server/src/test/test.helper.ts
-   ```
-
-   **Analyze the TestHelper to understand**:
-   - **Available methods**: What methods does TestHelper provide?
-   - **Configuration options**: How can TestHelper be configured?
-   - **GraphQL support**: How to use `graphQl()` method? What parameters does it accept?
-   - **REST support**: How to use `rest()` method? What parameters does it accept?
-   - **Authentication**: How does TestHelper handle tokens and authentication?
-   - **Request building**: How are requests constructed? What options are available?
-   - **Response handling**: How are responses processed? What format is returned?
-   - **Error handling**: How does TestHelper handle errors and failures?
-   - **Helper utilities**: What additional utilities are available?
-
-   **Document your findings**:
-   ```typescript
-   // Example: Understanding TestHelper.graphQl()
-   // Method signature: graphQl(options: GraphQLOptions, config?: RequestConfig)
-   // GraphQLOptions: { name, type (QUERY/MUTATION), arguments, fields }
-   // RequestConfig: { token, statusCode, headers }
-   // Returns: Parsed response data or error
-
-   // Example: Understanding TestHelper.rest()
-   // Method signature: rest(method: HttpMethod, path: string, options?: RestOptions)
-   // HttpMethod: 'GET' | 'POST' | 'PUT' | 'PATCH' | 'DELETE'
-   // RestOptions: { body, token, statusCode, headers }
-   // Returns: Response data or error
-   ```
-
-   **Common TestHelper patterns to understand**:
-   - How to execute GraphQL queries/mutations with `graphQl()`
-   - How to execute REST requests with `rest()`
-   - How to pass authentication tokens (same for both methods)
-   - How to handle expected errors (statusCode parameter)
-   - How to work with response data
-   - How to structure test data
-   - When to use GraphQL vs REST methods
-
-   **Only after fully understanding TestHelper, proceed to next step.**
-
-4. **Understand the testing approach used**:
-   - Which test framework? (Jest, Mocha, etc.)
-   - Which testing utilities? (@lenne.tech/nest-server testHelper, custom helpers)
-   - How is the test app initialized? (beforeAll setup)
-   - How are test users/auth handled?
-   - How is test data created and cleaned up?
-   - What assertion library? (expect, should, etc.)
-   - Are there custom matchers?
-
-5. **Document the patterns you observe**:
-   - **Import patterns**: Which modules are imported? In what order?
-   - **Setup patterns**: How is beforeAll/beforeEach structured?
-   - **Auth patterns**: How do tests authenticate? Token handling?
-   - **Test structure**: Describe blocks organization? Test naming conventions?
-   - **CRUD patterns**: How are create/read/update/delete tested?
-   - **Assertion patterns**: What assertions are used? How detailed?
-   - **Cleanup patterns**: How is afterAll/afterEach structured?
-   - **Error testing**: How are failures/validations tested?
-
-6. **Verify existing tests run successfully**:
-   ```bash
-   # Run existing tests to ensure they pass
-   npm run test:e2e
-
-   # If any fail, understand why before proceeding
-   # Your new/modified tests MUST NOT break existing tests
-   ```
-
-7. **Create a mental checklist**:
-   - [ ] I have read and understand the TestHelper source code
-   - [ ] I understand TestHelper methods and configuration
-   - [ ] I understand how to use graphQl() method (GraphQL queries/mutations)
-   - [ ] I understand how to use rest() method (REST endpoints)
-   - [ ] I understand when to use graphQl() vs rest()
-   - [ ] I understand TestHelper authentication and error handling
-   - [ ] I understand which test helpers/utilities are used
-   - [ ] I understand the authentication/authorization pattern
-   - [ ] I understand the test data lifecycle (create/cleanup)
-   - [ ] I understand the assertion patterns
-   - [ ] I understand the error testing approach
-   - [ ] All existing tests pass before I make changes
-
-**Only after completing this analysis, proceed to create or modify tests.**
-
-#### Step 2.1.1: Understanding Permissions and User Rights in Tests
-
-**CRITICAL**: Before creating tests, you MUST understand the 3-layer permission system:
-
-**Important Definitions**:
-
-- **Admin User**: A user whose `roles` array contains `'admin'`
-  ```typescript
-  // Example admin user
-  {
-    id: '123',
-    email: 'admin@test.com',
-    roles: ['admin', 'user'] // ← Contains 'admin'
-  }
-  ```
-
-- **Creator**: The user who created an object, identified by matching IDs
-  ```typescript
-  // User who created the object
-  const user = { id: 'user-123', email: 'creator@test.com' };
-
-  // Object created by this user
-  const product = {
-    id: 'product-456',
-    name: 'Test Product',
-    createdBy: 'user-123' // ← Matches user.id → This user is the CREATOR
-  };
-
-  // Different user (NOT the creator)
-  const otherUser = { id: 'user-789', email: 'other@test.com' };
-  // otherUser.id !== product.createdBy → NOT the creator!
-  ```
-
-**The Three Permission Layers**:
-
-1. **Controller/Resolver Layer** (`@Roles()` decorator):
-   - Controls WHO can call the endpoint
-   - Example: `@Roles(RoleEnum.ADMIN)` → Only admins can call this endpoint
-   - Example: `@Roles(RoleEnum.S_USER)` → All signed-in users can call
-
-2. **Service Layer** (`serviceOptions.roles` parameter):
-   - Controls what permissions are checked during service processing
-   - Example: Update/Delete often require `[RoleEnum.ADMIN, RoleEnum.S_CREATOR]`
-   - The creator can update/delete their own items
-
-3. **Model Layer** (`securityCheck()` method):
-   - Controls WHAT data is returned to the user
-   - Standard implementation:
-     ```typescript
-     securityCheck(user: User, force?: boolean) {
-       // Admins see everything (user.roles contains 'admin')
-       if (force || user?.hasRole(RoleEnum.ADMIN)) {
-         return this;
-       }
-       // Only creator can see their own data (user.id === this.createdBy)
-       if (!equalIds(user, this.createdBy)) {
-         return undefined; // Non-creator gets nothing!
-       }
-       return this;
-     }
-     ```
-   - **Key checks**:
-     - `user?.hasRole(RoleEnum.ADMIN)` → Returns `true` if `user.roles.includes('admin')`
-     - `equalIds(user, this.createdBy)` → Returns `true` if `user.id === this.createdBy`
-
-**Default Permission Behavior**:
-- **Create**: Usually accessible to signed-in users (`RoleEnum.S_USER`)
-- **Read/List**: Usually accessible to signed-in users, but securityCheck filters results
-- **Update**: Only ADMIN or CREATOR (via `serviceOptions.roles` check)
-- **Delete**: Only ADMIN or CREATOR (via `serviceOptions.roles` check)
-
-**Analyzing Permissions Before Creating Tests**:
-
-Before writing tests, check these 3 locations:
-
-1. **Check Controller/Resolver decorators**:
-   ```typescript
-   // In product.resolver.ts
-   @Roles(RoleEnum.ADMIN) // ← WHO can call this?
-   @Query(() => Product)
-   async getProduct(@Args('id') id: string) { ... }
-
-   @Roles(RoleEnum.S_USER) // ← All signed-in users
-   @Mutation(() => Product)
-   async createProduct(@Args('input') input: ProductCreateInput) { ... }
-   ```
-
-2. **Check Model/Object `@Restricted` decorators**:
-   ```typescript
-   // In product.model.ts
-   @Restricted(RoleEnum.ADMIN) // ← Model-level restriction
-   export class Product extends CoreModel {
-
-     @Restricted(RoleEnum.ADMIN) // ← Property-level restriction
-     @UnifiedField()
-     internalNotes?: string;
-   }
-   ```
-
-3. **Check Model `securityCheck()` logic**:
-   ```typescript
-   // In product.model.ts
-   securityCheck(user: User, force?: boolean) {
-     // Admin check: user.roles contains 'admin'
-     if (force || user?.hasRole(RoleEnum.ADMIN)) {
-       return this; // Admin sees all
-     }
-
-     // Custom logic: Allow public products for everyone
-     if (this.isPublic) {
-       return this;
-     }
-
-     // Creator check: user.id === this.createdBy
-     if (!equalIds(user, this.createdBy)) {
-       return undefined; // Non-creator gets nothing
-     }
-     return this; // Creator sees their own product
-   }
-   ```
-
-**Creating Appropriate Test Users**:
-
-Based on permission analysis, create appropriate test users:
-
-```typescript
-describe('Product Module', () => {
-  let testHelper: TestHelper;
-  let adminToken: string;
-  let userToken: string;
-  let otherUserToken: string;
-  let createdProductId: string;
-
-  beforeAll(async () => {
-    testHelper = new TestHelper(app);
-
-    // Admin user (user.roles contains 'admin')
-    const adminAuth = await testHelper.graphQl({
-      name: 'signIn',
-      type: TestGraphQLType.MUTATION,
-      arguments: { email: 'admin@test.com', password: 'admin' },
-      fields: ['token', 'user { id email roles }']
-    });
-    adminToken = adminAuth.token;
-    // adminAuth.user.roles = ['admin', 'user'] ← Contains 'admin'
-
-    // Regular user (will be the creator of test objects)
-    const userAuth = await testHelper.graphQl({
-      name: 'signIn',
-      type: TestGraphQLType.MUTATION,
-      arguments: { email: 'user@test.com', password: 'user' },
-      fields: ['token', 'user { id email roles }']
-    });
-    userToken = userAuth.token;
-    // When this user creates an object → object.createdBy = userAuth.user.id
-
-    // Another regular user (will NOT be the creator)
-    const otherUserAuth = await testHelper.graphQl({
-      name: 'signIn',
-      type: TestGraphQLType.MUTATION,
-      arguments: { email: 'other@test.com', password: 'other' },
-      fields: ['token', 'user { id email roles }']
-    });
-    otherUserToken = otherUserAuth.token;
-    // otherUserAuth.user.id !== object.createdBy → NOT the creator
-  });
-});
-```
-
-**Test Structure Based on Permissions**:
-
-```typescript
-describe('Product Module', () => {
-  // ... setup with adminToken, userToken, otherUserToken
-
-  describe('Create Product', () => {
-    it('should create product as regular user', async () => {
-      const result = await testHelper.graphQl({
-        name: 'createProduct',
-        type: TestGraphQLType.MUTATION,
-        arguments: { input: { name: 'Test Product', price: 99.99 } },
-        fields: ['id', 'name', 'createdBy { id }']
-      }, { token: userToken }); // ← Created by userToken
-
-      expect(result.name).toBe('Test Product');
-      // result.createdBy.id now equals userAuth.user.id
-      // → userToken is the CREATOR of this product
-      createdProductId = result.id;
-    });
-  });
-
-  describe('Update Product', () => {
-    it('should update product as creator', async () => {
-      const result = await testHelper.graphQl({
-        name: 'updateProduct',
-        type: TestGraphQLType.MUTATION,
-        arguments: {
-          id: createdProductId,
-          input: { price: 89.99 }
-        },
-        fields: ['id', 'price']
-      }, { token: userToken }); // ← Creator: userAuth.user.id === product.createdBy
-
-      expect(result.price).toBe(89.99);
-    });
-
-    it('should update product as admin', async () => {
-      const result = await testHelper.graphQl({
-        name: 'updateProduct',
-        type: TestGraphQLType.MUTATION,
-        arguments: {
-          id: createdProductId,
-          input: { price: 79.99 }
-        },
-        fields: ['id', 'price']
-      }, { token: adminToken }); // ← Admin: adminAuth.user.roles contains 'admin'
-
-      expect(result.price).toBe(79.99);
-    });
-
-    it('should fail to update product as non-creator', async () => {
-      const result = await testHelper.graphQl({
-        name: 'updateProduct',
-        type: TestGraphQLType.MUTATION,
-        arguments: {
-          id: createdProductId,
-          input: { price: 69.99 }
-        },
-        fields: ['id']
-      }, { token: otherUserToken, statusCode: 403 }); // ← Not creator: otherUserAuth.user.id !== product.createdBy
-
-      expect(result.errors).toBeDefined();
-    });
-  });
-
-  describe('Delete Product', () => {
-    it('should delete product as creator', async () => {
-      // First create a new product to delete
-      const created = await testHelper.graphQl({
-        name: 'createProduct',
-        type: TestGraphQLType.MUTATION,
-        arguments: { input: { name: 'To Delete', price: 50 } },
-        fields: ['id']
-      }, { token: userToken });
-
-      // Delete as creator
-      const result = await testHelper.graphQl({
-        name: 'deleteProduct',
-        type: TestGraphQLType.MUTATION,
-        arguments: { id: created.id },
-        fields: ['id']
-      }, { token: userToken }); // ← Creator: userAuth.user.id === created.createdBy
-
-      expect(result.id).toBe(created.id);
-    });
-
-    it('should fail to delete product as non-creator', async () => {
-      const result = await testHelper.graphQl({
-        name: 'deleteProduct',
-        type: TestGraphQLType.MUTATION,
-        arguments: { id: createdProductId },
-        fields: ['id']
-      }, { token: otherUserToken, statusCode: 403 }); // ← Not creator: otherUserAuth.user.id !== product.createdBy
-
-      expect(result.errors).toBeDefined();
-    });
-
-    it('should delete any product as admin', async () => {
-      const result = await testHelper.graphQl({
-        name: 'deleteProduct',
-        type: TestGraphQLType.MUTATION,
-        arguments: { id: createdProductId },
-        fields: ['id']
-      }, { token: adminToken }); // ← Admin: adminAuth.user.roles contains 'admin'
-
-      expect(result.id).toBe(createdProductId);
-    });
-  });
-});
-```
-
-**Permission Testing Checklist**:
-
-Before creating tests, verify:
-
-- [ ] I have checked the `@Roles()` decorators in controllers/resolvers
-- [ ] I have checked the `@Restricted()` decorators in models/objects
-- [ ] I have reviewed the `securityCheck()` logic in models
-- [ ] I understand who can CREATE items (usually S_USER)
-- [ ] I understand who can READ items (S_USER + securityCheck filtering)
-- [ ] I understand who can UPDATE items (usually ADMIN + S_CREATOR)
-- [ ] I understand who can DELETE items (usually ADMIN + S_CREATOR)
-- [ ] I have created appropriate test users (admin, creator, non-creator)
-- [ ] My tests use the CREATOR token (user.id === object.createdBy) for update/delete operations
-- [ ] My tests verify that non-creators (user.id !== object.createdBy) CANNOT update/delete
-- [ ] My tests verify that admins (user.roles contains 'admin') CAN update/delete everything
-
-**Common Permission Test Patterns**:
-
-1. **Test with creator** (user.id === object.createdBy) → Should succeed
-2. **Test with admin** (user.roles contains 'admin') → Should succeed
-3. **Test with other user** (user.id !== object.createdBy) → Should fail (403)
-
-**Only after understanding permissions, proceed to create tests.**
-
-#### Step 2.2: For Newly Created Modules
-
-**CRITICAL: Follow the correct test folder structure**:
-
-The project uses a specific test organization:
-
-1. **Module tests** (for modules in `src/server/modules/`):
-   ```
-   tests/modules/<module-name>.e2e-spec.ts
-   ```
-   - Each module gets its own test file directly in `tests/modules/`
-   - Examples: `tests/modules/user.e2e-spec.ts`, `tests/modules/book.e2e-spec.ts`
-
-2. **Common tests** (for common functionality in `src/server/common/`):
-   ```
-   tests/common.e2e-spec.ts
-   ```
-   - All common functionality (enums, objects, helpers) tested here
-   - Single file for all common-related tests
-
-3. **Project tests** (for everything else - root level, config, etc.):
-   ```
-   tests/project.e2e-spec.ts
-   ```
-   - General project-level tests
-   - Configuration tests
-   - Integration tests
-
-**Determine correct test location**:
-
-```bash
-# BEFORE creating a test, ask yourself:
-# - Is this a module in src/server/modules/? → tests/modules/<name>.e2e-spec.ts
-# - Is this common functionality? → Add to tests/common.e2e-spec.ts
-# - Is this project-level? → Add to tests/project.e2e-spec.ts
-
-# Check existing test structure to confirm:
-ls -la tests/
-ls tests/modules/
-```
-
-**Create new test files** for modules following the patterns you identified:
-
-```bash
-# For a new module (e.g., Book)
-tests/modules/book.e2e-spec.ts
-```
-
-**IMPORTANT**: Your new test file MUST:
-1. **Match the exact structure** of existing test files
-2. **Use the same imports** as existing tests
-3. **Follow the same setup/cleanup pattern** (beforeAll, afterAll)
-4. **Use the same test helpers/utilities** you observed
-5. **Follow the same authentication pattern**
-6. **Use the same assertion style**
-7. **Follow the same naming conventions** for describe/it blocks
-
-**Each new test file must include**:
-1. All CRUD operations (create, find all, find by ID, update, delete)
-2. Authorization tests (unauthorized should fail, authorized should succeed)
-3. Required field validation (missing required fields should fail)
-4. Proper test data setup and cleanup (beforeAll, afterAll)
-5. Tests for any custom methods or relationships
-
-**Ensure all prerequisites are met by analyzing existing tests**:
-
-Before writing test code, identify ALL prerequisites from existing test files:
-
-```bash
-# Read an existing module test to understand prerequisites
-cat tests/modules/user.e2e-spec.ts
-```
-
-**Common prerequisites to check**:
-1. **Test data dependencies**:
-   - Does the module reference other modules? (e.g., Book → User for borrowedBy)
-   - Do you need to create related test data first?
-   - Example: To test Book with borrowedBy: User, create test User first
-
-2. **Authentication requirements**:
-   - What roles/permissions are needed?
-   - Do test users need to be created with specific roles?
-   - Example: Admin user for create operations, regular user for read operations
-
-3. **Database setup**:
-   - Are there database constraints or required collections?
-   - Do embedded objects or enums need to exist?
-
-4. **Configuration**:
-   - Are environment variables or config values needed?
-   - Example: JWT secrets, database connections
-
-**Pattern from existing tests**:
-```typescript
-// Example structure you should follow:
-beforeAll(async () => {
-  // 1. Initialize test app/module
-  // 2. Set up database connection
-  // 3. Create prerequisite test data (users, roles, etc.)
-  // 4. Authenticate and get tokens
-});
-
-describe('Module Tests', () => {
-  // Tests here
-});
-
-afterAll(async () => {
-  // 1. Delete created test data (in reverse order)
-  // 2. Clean up connections
-  // 3. Close app
-});
-```
-
-**CRITICAL**: Look at how existing tests handle prerequisites and replicate the exact same approach.
-
-#### Step 2.3: For Modified Existing Modules
-
-**Update existing test files** when you modify modules:
-
-1. **FIRST: Read the existing test file completely**:
-   ```bash
-   # Find and read the test file for the module you modified
-   find tests -name "*<module-name>*.e2e-spec.ts"
-   cat tests/modules/<module-name>.e2e-spec.ts
-   ```
-
-2. **Understand what the existing tests cover**:
-   - Which operations are tested?
-   - Which properties are validated?
-   - What edge cases are covered?
-   - How is test data structured?
-
-3. **Run existing tests to ensure they pass BEFORE your changes**:
-   ```bash
-   npm run test:e2e
-   ```
-
-4. **Review and update tests**:
-   - **Added properties**: Add tests verifying new properties work correctly
-   - **Changed validation**: Update tests to reflect new validation rules
-   - **Added relationships**: Add tests for new references/embedded objects
-   - **Changed required fields**: Update CreateInput tests accordingly
-   - **Removed properties**: Remove related test assertions
-
-5. **Verify test coverage**:
-   - All new properties are tested
-   - Changed behavior is verified
-   - Edge cases are covered
-   - Authorization still works correctly
-
-6. **Run tests again to ensure your changes don't break anything**:
-   ```bash
-   npm run test:e2e
-   ```
-
-### Step 3: Compare with Existing Code
-
-**Compare generated code with existing project code**:
-
-1. **Read existing similar modules** to understand project patterns:
-   ```bash
-   # Example: If you created a User module, check existing modules
-   ls src/server/modules/
-   ```
-
-2. **Check for consistency**:
-   - Code style (indentation, spacing, formatting)
-   - Import ordering and organization
-   - Naming conventions (camelCase, PascalCase, kebab-case)
-   - File structure and directory organization
-   - Comment style and documentation
-   - Decorator usage (@Field, @Prop, etc.)
-   - Error handling patterns
-   - Validation patterns
-
-3. **Review property ordering**:
-   - Verify alphabetical order in models
-   - Verify alphabetical order in inputs
-   - Verify alphabetical order in outputs
-   - Check decorator consistency
-
-### Step 4: Critical Analysis
-
-**Analyze each file critically**:
-
-1. **Style consistency**:
-   - Does the code match the project's existing style?
-   - Are imports grouped and ordered correctly?
-   - Is indentation consistent with the project?
-   - Are naming conventions followed?
-
-2. **Structural consistency**:
-   - Are decorators in the same order as existing code?
-   - Is the file structure identical to existing modules?
-   - Are descriptions formatted the same way?
-   - Are relationships implemented consistently?
-
-3. **Code quality**:
-   - Are there any redundant imports?
-   - Are there any missing imports?
-   - Are descriptions meaningful and complete?
-   - Are TypeScript types correctly used?
-
-4. **Best practices**:
-   - Are required fields properly marked?
-   - Are nullable fields correctly configured?
-   - Are references properly typed?
-   - Are arrays correctly configured?
-
-### Step 5: Automated Optimizations
-
-**Apply automatic improvements**:
-
-1. **Fix import ordering**:
-   - External imports first (alphabetically)
-   - @lenne.tech/nest-server imports next
-   - Local imports last (alphabetically by path depth)
-
-2. **Fix property ordering**:
-   - Reorder all properties alphabetically in models
-   - Reorder all properties alphabetically in inputs
-   - Reorder all properties alphabetically in outputs
-
-3. **Fix formatting**:
-   - Ensure consistent indentation
-   - Remove extra blank lines
-   - Add missing blank lines between sections
-
-4. **Fix descriptions**:
-   - Ensure all follow "ENGLISH (DEUTSCH)" format
-   - Add missing descriptions
-   - Improve unclear descriptions
-
-5. **Fix common patterns**:
-   - Standardize decorator usage
-   - Standardize validation patterns
-   - Standardize error handling
-
-### Step 6: Pre-Report Testing
-
-**MANDATORY**: Run all tests before reporting:
-
-```bash
-# Run TypeScript compilation
-npm run build
-
-# Run linting
-npm run lint
-
-# Run all tests
-npm run test:e2e
-
-# If any fail, fix issues and repeat
-```
-
-**If tests fail**:
-1. Analyze the error
-2. Fix the issue
-3. Re-run tests
-4. Repeat until all tests pass
-
-#### Debugging Failed Tests - Important Guidelines
-
-**When tests fail, use systematic debugging with console.log statements:**
-
-1. **Add debug messages in Controllers/Resolvers**:
-   ```typescript
-   // In controller/resolver - BEFORE service call
-   console.log('🔵 [Controller] createProduct - Input:', input);
-   console.log('🔵 [Controller] createProduct - User:', serviceOptions?.user);
-
-   const result = await this.productService.create(input, serviceOptions);
-
-   // AFTER service call
-   console.log('🔵 [Controller] createProduct - Result:', result);
-   ```
-
-2. **Add debug messages in Services**:
-   ```typescript
-   // In service method
-   console.log('🟢 [Service] create - Input:', input);
-   console.log('🟢 [Service] create - ServiceOptions:', serviceOptions);
-
-   const created = await super.create(input, serviceOptions);
-
-   console.log('🟢 [Service] create - Created:', created);
-   ```
-
-3. **Understand the permissions system**:
-   - **Controllers/Resolvers**: `@Roles()` decorator controls WHO can call the endpoint
-   - **Services**: `serviceOptions.roles` controls what the service checks during processing
-   - **Models**: `securityCheck()` method determines what data is returned to the user
-
-4. **Default permission behavior**:
-   - Only **Admin users** (user.roles contains 'admin') OR the **creator** (user.id === object.createdBy) of an element can access it
-   - This is enforced in the `securityCheck()` method in models:
-   ```typescript
-   securityCheck(user: User, force?: boolean) {
-     // Admin: user.roles contains 'admin'
-     if (force || user?.hasRole(RoleEnum.ADMIN)) {
-       return this; // Admin sees everything
-     }
-     // Creator: user.id === this.createdBy
-     if (!equalIds(user, this.createdBy)) {
-       return undefined; // Non-creator (user.id !== this.createdBy) gets nothing
-     }
-     return this; // Creator sees their own data
-   }
-   ```
-
-5. **Debugging strategy for permission issues**:
-
-   **Step 1**: Run failing test with Admin user first
-   ```typescript
-   // In test setup
-   const adminToken = await testHelper.signIn('admin@test.com', 'admin-password');
-
-   // Use admin token in test
-   const result = await testHelper.graphQl({...}, { token: adminToken });
-   ```
-
-   **Step 2**: Analyze results
-   - ✅ **Works with Admin, fails with normal user** → Permission issue (check Roles, securityCheck)
-   - ❌ **Fails with Admin too** → Different issue (check logic, data, validation)
-
-6. **Common permission issues and solutions**:
-
-   | Problem | Cause | Solution |
-   |---------|-------|----------|
-   | 401/403 on endpoint | `@Roles()` too restrictive | Adjust decorator in controller/resolver |
-   | Empty result despite data existing | `securityCheck()` returns undefined | Modify securityCheck logic or use Admin |
-   | Service throws permission error | `serviceOptions.roles` check fails | Pass correct roles in serviceOptions |
-
-7. **Remove debug messages after fixing**:
-   ```bash
-   # After tests pass, remove all console.log statements
-   # Search for debug patterns
-   grep -r "console.log" src/server/modules/your-module/
-
-   # Remove them manually or with sed
-   # Then verify tests still pass
-   npm run test:e2e
-   ```
-
-**Debugging workflow example**:
-```typescript
-// 1. Test fails - add debugging
-@Mutation(() => Product)
-async createProduct(@Args('input') input: ProductCreateInput, @GraphQLServiceOptions() opts) {
-  console.log('🔵 START createProduct', { input, user: opts?.user?.email });
-
-  const result = await this.productService.create(input, opts);
-
-  console.log('🔵 END createProduct', { result: result?.id });
-  return result;
-}
-
-// In service
-async create(input: ProductCreateInput, serviceOptions?: ServiceOptions) {
-  console.log('🟢 Service create', { input, user: serviceOptions?.user?.email });
-
-  const created = await super.create(input, serviceOptions);
-
-  console.log('🟢 Service created', { id: created?.id, createdBy: created?.createdBy });
-  return created;
-}
-
-// 2. Run test - observe output:
-// 🔵 START createProduct { input: {...}, user: 'test@test.com' }
-// 🟢 Service create { input: {...}, user: 'test@test.com' }
-// 🟢 Service created { id: '123', createdBy: '456' }
-// 🔵 END createProduct { result: undefined }  ← AHA! Result is undefined!
-
-// 3. Check model securityCheck() - likely returns undefined for non-creator (user.id !== object.createdBy)
-// 4. Fix: Either use Admin user (user.roles contains 'admin') or adjust securityCheck logic
-// 5. Test passes → Remove console.log statements
-// 6. Verify tests still pass
-```
-
-**Do not proceed to final report if**:
-- TypeScript compilation fails
-- Linting fails
-- Any tests fail
-- Console shows errors or warnings
-
-### Step 7: Final Verification
-
-Before reporting, verify:
-
-- [ ] All files compared with existing code
-- [ ] Code style matches project patterns
-- [ ] All imports properly ordered
-- [ ] All properties in alphabetical order
-- [ ] All descriptions follow format
-- [ ] **TestHelper source code read and understood**
-- [ ] **TestHelper methods and configuration understood**
-- [ ] **Existing tests analyzed BEFORE creating/modifying tests**
-- [ ] **Existing tests passed BEFORE making changes**
-- [ ] **Tests in correct location (tests/modules/<name>.e2e-spec.ts, tests/common.e2e-spec.ts, or tests/project.e2e-spec.ts)**
-- [ ] **New test files created for all new modules**
-- [ ] **Existing test files updated for all modified modules**
-- [ ] **All prerequisites identified and handled (test data dependencies, auth, etc.)**
-- [ ] **All new/modified tests follow exact patterns from existing tests**
-- [ ] TypeScript compiles without errors
-- [ ] Linter passes without warnings
-- [ ] **All tests pass AFTER changes**
-- [ ] No console errors or warnings
+**CRITICAL**: Before creating the final report, you MUST perform a comprehensive quality review.
+
+**📖 For the complete quality review process with all steps, checklists, and examples, see: `quality-review.md`**
+
+**Quick overview - 7 steps:**
+
+1. **Identify All Changes**: Use git to identify all created/modified files
+2. **Test Management**: 
+   - Analyze existing tests FIRST (understand TestHelper, patterns, permissions)
+   - Create new test files for newly created modules (in `tests/modules/`)
+   - Update existing test files for modified modules
+   - Follow exact patterns from existing tests
+3. **Compare with Existing Code**: Check consistency (style, structure, naming)
+4. **Critical Analysis**: Verify style, structure, code quality, best practices
+5. **Automated Optimizations**: Fix import ordering, property ordering, formatting, descriptions
+6. **Pre-Report Testing**: Run build, lint, and all tests (must all pass!)
+7. **Final Verification**: Complete checklist before proceeding to Final Report
+
+**Critical reminders:**
+- [ ] **TestHelper thoroughly understood** (read source code, understand graphQl() and rest() methods)
+- [ ] **Existing tests analyzed** BEFORE creating new tests
+- [ ] **Permission system understood** (3 layers: Controller @Roles, Service options, Model securityCheck)
+- [ ] **Tests in correct location** (tests/modules/, tests/common.e2e-spec.ts, or tests/project.e2e-spec.ts)
+- [ ] **All tests pass** before reporting
+
+**Permission testing approach:**
+- Admin users: `user.roles.includes('admin')`
+- Creators: `user.id === object.createdBy`
+- Always test with appropriate user (creator for update/delete, admin for everything)
+- Test security failures (403 responses)
 
 **Only after ALL checks pass, proceed to Final Report.**