@lenne.tech/cli 1.0.0 → 1.0.2

package/build/templates/claude-skills/generating-nest-servers/declare-keyword-warning.md

@@ -0,0 +1,133 @@
+---
+name: nest-server-generator-declare-keyword
+version: 1.0.0
+description: Critical warning about using the declare keyword in TypeScript classes
+---
+
+# 🚨 CRITICAL: NEVER USE `declare` KEYWORD FOR PROPERTIES
+
+## Table of Contents
+- [WRONG - Using `declare`](#-wrong---using-declare)
+- [CORRECT - Without `declare`](#-correct---without-declare)
+- [Why This Matters](#why-this-matters)
+- [When You Might Be Tempted to Use `declare`](#when-you-might-be-tempted-to-use-declare)
+- [Correct Approach Instead](#correct-approach-instead)
+- [Examples](#examples)
+- [Remember](#remember)
+
+**⚠️ IMPORTANT RULE: DO NOT use the `declare` keyword when defining properties in classes!**
+
+The `declare` keyword in TypeScript signals that a property is only a type declaration without a runtime value. This prevents decorators from being properly applied and overridden.
+
+---
+
+## ❌ WRONG - Using `declare`
+
+```typescript
+export class ProductCreateInput extends ProductInput {
+  declare name: string;  // ❌ WRONG - Decorator won't be applied!
+  declare price: number; // ❌ WRONG - Decorator won't be applied!
+}
+```
+
+---
+
+## ✅ CORRECT - Without `declare`
+
+```typescript
+export class ProductCreateInput extends ProductInput {
+  @UnifiedField({ description: 'Product name' })
+  name: string;  // ✅ CORRECT - Decorator works properly
+
+  @UnifiedField({ description: 'Product price' })
+  price: number; // ✅ CORRECT - Decorator works properly
+}
+```
+
+---
+
+## Why This Matters
+
+1. **Decorators require actual properties**: `@UnifiedField()`, `@Restricted()`, and other decorators need actual property declarations to attach metadata
+2. **Override behavior**: When extending classes, using `declare` prevents decorators from being properly overridden
+3. **Runtime behavior**: `declare` properties don't exist at runtime, breaking the decorator system
+
+---
+
+## When You Might Be Tempted to Use `declare`
+
+- ❌ When extending a class and wanting to change a decorator
+- ❌ When TypeScript shows "property is declared but never used"
+- ❌ When dealing with inheritance and property redefinition
+
+---
+
+## Correct Approach Instead
+
+Use the `override` keyword (when appropriate) but NEVER `declare`:
+
+```typescript
+export class ProductCreateInput extends ProductInput {
+  // ✅ Use override when useDefineForClassFields is enabled
+  override name: string;
+
+  // ✅ Apply decorators directly - they will override parent decorators
+  @UnifiedField({ description: 'Product name', isOptional: false })
+  override price: number;
+}
+```
+
+---
+
+## Examples
+
+### ❌ WRONG - Using declare
+
+```typescript
+// This will BREAK decorator functionality
+export class AddressInput extends Address {
+  declare street: string;
+  declare city: string;
+  declare zipCode: string;
+}
+```
+
+### ✅ CORRECT - Without declare
+
+```typescript
+// This works properly
+export class AddressInput extends Address {
+  @UnifiedField({ description: 'Street' })
+  street: string;
+
+  @UnifiedField({ description: 'City' })
+  city: string;
+
+  @UnifiedField({ description: 'Zip code' })
+  zipCode: string;
+}
+```
+
+### ✅ CORRECT - With override
+
+```typescript
+// This also works when extending decorated properties
+export class AddressInput extends Address {
+  @UnifiedField({ description: 'Street', isOptional: false })
+  override street: string;
+
+  @UnifiedField({ description: 'City', isOptional: false })
+  override city: string;
+
+  @UnifiedField({ description: 'Zip code', isOptional: true })
+  override zipCode?: string;
+}
+```
+
+---
+
+## Remember
+
+**`declare` = no decorators = broken functionality!**
+
+Always use actual property declarations with decorators, optionally with the `override` keyword when extending classes.

package/build/templates/claude-skills/generating-nest-servers/description-management.md

@@ -0,0 +1,226 @@
+---
+name: nest-server-generator-description-management
+version: 1.0.0
+description: Guidelines for consistent description management across all generated components
+---
+
+# 🚨 CRITICAL: Description Management
+
+## Table of Contents
+- [Step 1: ALWAYS Extract Descriptions from User Input](#-step-1-always-extract-descriptions-from-user-input)
+- [Step 2: Format Descriptions Correctly](#-step-2-format-descriptions-correctly)
+- [Step 3: Apply Descriptions EVERYWHERE (Most Critical!)](#-step-3-apply-descriptions-everywhere-most-critical)
+- [Common Mistakes to AVOID](#-common-mistakes-to-avoid)
+- [Verification Checklist](#-verification-checklist)
+- [If You Forget](#-if-you-forget)
+- [Quick Reference](#quick-reference)
+
+**⚠️ COMMON MISTAKE:** Descriptions are often applied inconsistently or only partially. You MUST follow this process for EVERY component.
+
+---
+
+## 🔍 Step 1: ALWAYS Extract Descriptions from User Input
+
+**BEFORE generating ANY code, scan the user's specification for description hints:**
+
+1. **Look for comments after `//`**:
+   ```
+   Module: Product
+   - name: string // Product name
+   - price: number // Produktpreis
+   - stock?: number // Current stock level
+   ```
+
+2. **Extract ALL comments** and store them for each property
+3. **Identify language** (English or German)
+
+---
+
+## 📝 Step 2: Format Descriptions Correctly
+
+**Rule**: `"ENGLISH_DESCRIPTION (DEUTSCHE_BESCHREIBUNG)"`
+
+### Processing Logic
+
+| User Input | Language | Formatted Description |
+|------------|----------|----------------------|
+| `// Product name` | English | `'Product name'` |
+| `// Produktname` | German | `'Product name (Produktname)'` |
+| `// Straße` | German | `'Street (Straße)'` |
+| `// Postleizahl` (typo) | German | `'Postal code (Postleitzahl)'` |
+| (no comment) | - | Create meaningful English description |
+
+### ⚠️ CRITICAL - Preserving Original Text
+
+**1. Fix spelling errors ONLY:**
+- ✅ Correct typos: `Postleizahl` → `Postleitzahl` (missing 't')
+- ✅ Fix character errors: `Starße` → `Straße` (wrong character)
+- ✅ Correct English typos: `Prodcut name` → `Product name`
+
+**2. DO NOT change the wording:**
+- ❌ NEVER rephrase: `Straße` → `Straßenname` (NO!)
+- ❌ NEVER expand: `Produkt` → `Produktbezeichnung` (NO!)
+- ❌ NEVER improve: `Name` → `Full name` (NO!)
+- ❌ NEVER translate differently: `Name` → `Title` (NO!)
+
+**3. Why this is critical:**
+- User comments may be **predefined terms** from requirements
+- External systems may **reference these exact terms**
+- Changing wording breaks **external integrations**
+
+### Examples
+
+```
+✅ CORRECT:
+// Straße → 'Street (Straße)'  (only translated)
+// Starße → 'Street (Straße)'  (typo fixed, then translated)
+// Produkt → 'Product (Produkt)'  (keep original word)
+// Strasse → 'Street (Straße)'  (ss→ß corrected, then translated)
+
+❌ WRONG:
+// Straße → 'Street name (Straßenname)'  (changed wording!)
+// Produkt → 'Product name (Produktname)'  (added word!)
+// Name → 'Full name (Vollständiger Name)'  (rephrased!)
+```
+
+**Rule Summary**: Fix typos, preserve wording, translate accurately.
+
+---
+
+## ✅ Step 3: Apply Descriptions EVERYWHERE (Most Critical!)
+
+**🚨 YOU MUST apply the SAME description to ALL of these locations:**
+
+### For Module Properties
+
+**1. Model file** (`<module>.model.ts`):
+```typescript
+@UnifiedField({ description: 'Product name (Produktname)' })
+name: string;
+```
+
+**2. Create Input** (`<module>-create.input.ts`):
+```typescript
+@UnifiedField({ description: 'Product name (Produktname)' })
+name: string;
+```
+
+**3. Update Input** (`<module>.input.ts`):
+```typescript
+@UnifiedField({ description: 'Product name (Produktname)' })
+name?: string;
+```
+
+### For SubObject Properties
+
+**1. Object file** (`<object>.object.ts`):
+```typescript
+@UnifiedField({ description: 'Street (Straße)' })
+street: string;
+```
+
+**2. Object Create Input** (`<object>-create.input.ts`):
+```typescript
+@UnifiedField({ description: 'Street (Straße)' })
+street: string;
+```
+
+**3. Object Update Input** (`<object>.input.ts`):
+```typescript
+@UnifiedField({ description: 'Street (Straße)' })
+street?: string;
+```
+
+### For Object/Module Type Decorators
+
+Apply descriptions to the class decorators as well:
+
+```typescript
+@ObjectType({ description: 'Address information (Adressinformationen)' })
+export class Address { ... }
+
+@InputType({ description: 'Address information (Adressinformationen)' })
+export class AddressInput { ... }
+
+@ObjectType({ description: 'Product entity (Produkt-Entität)' })
+export class Product extends CoreModel { ... }
+```
+
+---
+
+## ⛔ Common Mistakes to AVOID
+
+1. ❌ **Partial application**: Descriptions only in Models, not in Inputs
+2. ❌ **Inconsistent format**: German-only in some places, English-only in others
+3. ❌ **Missing descriptions**: No descriptions when user provided comments
+4. ❌ **Ignoring Object inputs**: Forgetting to add descriptions to SubObject Input files
+5. ❌ **Wrong format**: Using `(ENGLISH)` instead of `ENGLISH (DEUTSCH)`
+6. ❌ **Changing wording**: Rephrasing user's original terms
+7. ❌ **Adding words**: Expanding user's terminology
+
+---
+
+## ✅ Verification Checklist
+
+After generating code, ALWAYS verify:
+
+- [ ] All user comments/descriptions extracted from specification
+- [ ] All descriptions follow format: `"ENGLISH (DEUTSCH)"` or `"ENGLISH"`
+- [ ] Model properties have descriptions
+- [ ] Create Input properties have SAME descriptions
+- [ ] Update Input properties have SAME descriptions
+- [ ] Object properties have descriptions
+- [ ] Object Input properties have SAME descriptions
+- [ ] Class-level `@ObjectType()` and `@InputType()` have descriptions
+- [ ] NO German-only descriptions (must be translated)
+- [ ] NO inconsistencies between files
+- [ ] Original wording preserved (only typos fixed)
+
+---
+
+## 🔄 If You Forget
+
+**If you generate code and realize descriptions are missing or inconsistent:**
+
+1. **STOP** - Don't continue with other phases
+2. **Go back** and add/fix ALL descriptions
+3. **Verify** using the checklist above
+4. **Then continue** with remaining phases
+
+**Remember**: Descriptions are NOT optional "nice-to-have" - they are MANDATORY for:
+- API documentation (Swagger/GraphQL)
+- Code maintainability
+- Developer experience
+- Bilingual projects (German/English teams)
+
+---
+
+## Quick Reference
+
+### Format Rules
+
+```
+English input    → 'Product name'
+German input     → 'Product name (Produktname)'
+No input         → Create meaningful description
+Typo input       → Fix typo, then translate
+Mixed input      → Standardize to 'ENGLISH (DEUTSCH)'
+```
+
+### Application Checklist
+
+For **each property**:
+- [ ] Model file
+- [ ] Create Input file
+- [ ] Update Input file
+
+For **each class**:
+- [ ] @ObjectType() decorator
+- [ ] @InputType() decorator (if applicable)
+
+### Remember
+
+- **Consistency is critical** - Same description everywhere
+- **Preserve wording** - Only fix typos, never rephrase
+- **Bilingual format** - Always use "ENGLISH (DEUTSCH)" for German terms
+- **Verification** - Check all files before proceeding

package/build/templates/claude-skills/{nest-server-generator → generating-nest-servers}/examples.md

@@ -1,11 +1,18 @@
 ---
 name: nest-server-generator-examples
-version: 1.0.0
+version: 1.0.1
 description: Complete examples for generating NestJS server structures from specifications
 ---
 
 # NestJS Server Generator Examples
 
+## Table of Contents
+- [Example 1: Library Management System](#example-1-library-management-system)
+- [Example 2: Hotel Booking System (Minimal)](#example-2-hotel-booking-system-minimal)
+- [Key Patterns Demonstrated](#key-patterns-demonstrated)
+- [Best Practices from Examples](#best-practices-from-examples)
+- [Quality Review Workflow Example](#quality-review-workflow-example)
+
 ## Example 1: Library Management System
 
 This example demonstrates all features:
@@ -209,18 +216,144 @@ Manually update `book.input.ts` and `book-create.input.ts`:
 
 #### Step 5: Update Descriptions
 
-Update all generated files to follow pattern: `"ENGLISH (DEUTSCH)"`:
+**⚠️ CRITICAL STEP - Extract descriptions from original specification and apply EVERYWHERE!**
+
+**Step 5.1: Extract from specification**
+
+Go back to the original specification and identify ALL comments:
+
+```
+SubObject: Address
+- street: string // Straße
+- city: string // City name
+- zipCode: string // Postleitzahl
+
+Module: Book
+Model: Book
+Extends: BaseItem
+- isbn: string // ISBN-Nummer
+- author: string // Author name
+- publisher?: string // Verlag
+```
+
+**Extracted mapping:**
+- Address.street → "Straße" (German)
+- Address.city → "City name" (English)
+- Address.zipCode → "Postleitzahl" (German)
+- Book.isbn → "ISBN-Nummer" (German)
+- Book.author → "Author name" (English)
+- Book.publisher → "Verlag" (German)
+
+**Step 5.2: Format descriptions**
+
+Apply format rules:
+- German → Translate and add: `ENGLISH (DEUTSCH)`
+- English → Keep as-is
+- **Fix typos only, preserve original wording!**
+
+```
+Address.street → 'Street (Straße)'  (preserve word "Straße", don't change to "Straßenname")
+Address.city → 'City name'
+Address.zipCode → 'Postal code (Postleitzahl)'
+Book.isbn → 'ISBN number (ISBN-Nummer)'
+Book.author → 'Author name'
+Book.publisher → 'Publisher (Verlag)'  (preserve word "Verlag", don't expand)
+```
+
+**⚠️ CRITICAL - Preserve Original Wording:**
+
+User comments may be predefined terms or referenced by external systems.
+
+**Examples of correct handling**:
+```
+✅ CORRECT:
+// Straße → 'Street (Straße)'  (just translate)
+// Postleizahl → 'Postal code (Postleitzahl)'  (fix typo, preserve word)
+// Produkt → 'Product (Produkt)'  (don't add "name")
+// Status → 'Status (Status)'  (same word)
+
+❌ WRONG:
+// Straße → 'Street name (Straßenname)'  (changed word!)
+// Produkt → 'Product name (Produktname)'  (added word!)
+// Titel → 'Product title (Produkttitel)'  (changed "Titel"!)
+```
+
+**Step 5.3: Apply to ALL files**
+
+For Address SubObject (3 files):
 
 ```typescript
-// Before:
-@UnifiedField({ description: 'ISBN number' })
+// File: src/server/common/objects/address/address.object.ts
+@UnifiedField({ description: 'Street (Straße)' })
+street: string;
+
+@UnifiedField({ description: 'City name' })
+city: string;
+
+@UnifiedField({ description: 'Postal code (Postleitzahl)' })
+zipCode: string;
+
+// File: src/server/common/objects/address/address-create.input.ts
+@UnifiedField({ description: 'Street (Straße)' })
+street: string;
+
+@UnifiedField({ description: 'City name' })
+city: string;
+
+@UnifiedField({ description: 'Postal code (Postleitzahl)' })
+zipCode: string;
+
+// File: src/server/common/objects/address/address.input.ts
+@UnifiedField({ description: 'Street (Straße)' })
+street?: string;
+
+@UnifiedField({ description: 'City name' })
+city?: string;
+
+@UnifiedField({ description: 'Postal code (Postleitzahl)' })
+zipCode?: string;
+```
+
+For Book Module (3 files):
+
+```typescript
+// File: src/server/modules/book/book.model.ts
+@UnifiedField({ description: 'ISBN number (ISBN-Nummer)' })
 isbn: string;
 
-// After:
+@UnifiedField({ description: 'Author name' })
+author: string;
+
+@UnifiedField({ description: 'Publisher (Verlag)' })
+publisher?: string;
+
+// File: src/server/modules/book/inputs/book-create.input.ts
 @UnifiedField({ description: 'ISBN number (ISBN-Nummer)' })
 isbn: string;
+
+@UnifiedField({ description: 'Author name' })
+author: string;
+
+@UnifiedField({ description: 'Publisher (Verlag)' })
+publisher?: string;
+
+// File: src/server/modules/book/inputs/book.input.ts
+@UnifiedField({ description: 'ISBN number (ISBN-Nummer)' })
+isbn?: string;
+
+@UnifiedField({ description: 'Author name' })
+author?: string;
+
+@UnifiedField({ description: 'Publisher (Verlag)' })
+publisher?: string;
 ```
 
+**Verification:**
+- ✅ Same description in ALL 3 files for each property
+- ✅ All German descriptions translated
+- ✅ All user comments extracted and applied
+- ✅ No inconsistencies
+
 #### Step 6: Create Enum Files
 
 ```typescript