@lenne.tech/cli 1.0.0 → 1.0.1

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

@@ -0,0 +1,279 @@
+---
+name: nest-server-generator-configuration
+version: 1.0.0
+description: Complete guide to lt.config.json configuration file
+---
+
+## 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.
+
+### File Location and Hierarchy
+
+- **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
+
+```json
+{
+  "meta": {
+    "version": "1.0.0",
+    "name": "My Project",
+    "description": "Optional project description"
+  },
+  "commands": {
+    "server": {
+      "module": {
+        "controller": "Both",
+        "skipLint": false
+      },
+      "object": {
+        "skipLint": false
+      },
+      "addProp": {
+        "skipLint": false
+      }
+    }
+  }
+}
+```
+
+### 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

package/build/templates/claude-skills/nest-server-generator/declare-keyword-warning.md

@@ -0,0 +1,124 @@
+---
+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
+
+**⚠️ 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/nest-server-generator/description-management.md

@@ -0,0 +1,217 @@
+---
+name: nest-server-generator-description-management
+version: 1.0.0
+description: Guidelines for consistent description management across all generated components
+---
+
+# 🚨 CRITICAL: Description Management
+
+**⚠️ 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