@lenne.tech/cli 1.2.0 → 1.3.0

package/build/templates/claude-skills/generating-nest-servers/security-rules.md

@@ -1,371 +0,0 @@
----
-name: nest-server-generator-security-rules
-version: 1.0.0
-description: Critical security and test coverage rules for NestJS development
----
-
-# 🚨 CRITICAL SECURITY RULES
-
-## Table of Contents
-- [NEVER Do This](#-never-do-this)
-- [ALWAYS Do This](#-always-do-this)
-- [Permission Hierarchy (Specific Overrides General)](#-permission-hierarchy-specific-overrides-general)
-- [Rule 1: NEVER Weaken Security for Test Convenience](#rule-1-never-weaken-security-for-test-convenience)
-- [Rule 2: Understanding Permission Hierarchy](#rule-2-understanding-permission-hierarchy)
-- [Rule 3: Adapt Tests to Security, Not Vice Versa](#rule-3-adapt-tests-to-security-not-vice-versa)
-- [Rule 4: Test with Least Privileged User](#rule-4-test-with-least-privileged-user)
-- [Rule 5: Create Appropriate Test Users](#rule-5-create-appropriate-test-users)
-- [Rule 6: Comprehensive Test Coverage](#rule-6-comprehensive-test-coverage)
-- [Quick Security Checklist](#quick-security-checklist)
-- [Security Decision Protocol](#security-decision-protocol)
-
-**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
-
----
-
-## ✅ ALWAYS Do This
-
-1. **ALWAYS analyze permissions BEFORE writing tests** (Controller, Model, Service layers)
-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)
-
----
-
-## 🔑 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)
-
-  async secretMethod() { }    // ← ADMIN only (fallback applies)
-}
-```
-
-**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
-
----
-
-## 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 (specific @Roles wins)
-  }
-
-  @Roles(RoleEnum.S_USER)  // ← SPECIFIC: Logged-in users
-  async createProduct() {
-    // S_USER can access (specific wins over fallback)
-  }
-
-  async deleteProduct() {
-    // ADMIN ONLY (no specific decorator, fallback applies)
-  }
-}
-```
-
-### Example - Model
-
-```typescript
-@Restricted(RoleEnum.ADMIN)  // ← FALLBACK
-export class Product {
-
-  @Roles(RoleEnum.S_EVERYONE)  // ← SPECIFIC
-  @UnifiedField({ description: 'Product name' })
-  name: string;  // Everyone can read this
-
-  @UnifiedField({ description: 'Internal cost' })
-  cost: number;  // ADMIN ONLY (fallback applies)
-}
-```
-
----
-
-## Rule 3: Adapt Tests to Security, Not Vice Versa
-
-### ❌ WRONG Approach
-
-```typescript
-// Test fails because user isn't admin
-it('should create product', async () => {
-  const result = await request(app)
-    .post('/products')
-    .set('Authorization', regularUserToken)  // Not an admin!
-    .send(productData);
-
-  expect(result.status).toBe(201);  // Fails with 403
-});
-
-// ❌ WRONG FIX: Removing @Restricted from controller
-// @Restricted(RoleEnum.ADMIN)  ← NEVER DO THIS!
-```
-
-### ✅ CORRECT Approach
-
-```typescript
-// Analyze first: Who is allowed to create products?
-// Answer: ADMIN only (based on @Restricted on controller)
-
-// Create admin test user
-let adminToken: string;
-
-beforeAll(async () => {
-  const admin = await createTestUser({ roles: [RoleEnum.ADMIN] });
-  adminToken = admin.token;
-});
-
-it('should create product as admin', async () => {
-  const result = await request(app)
-    .post('/products')
-    .set('Authorization', adminToken)  // ✅ Use admin token
-    .send(productData);
-
-  expect(result.status).toBe(201);  // ✅ Passes
-});
-
-it('should reject product creation for regular user', async () => {
-  const result = await request(app)
-    .post('/products')
-    .set('Authorization', regularUserToken)
-    .send(productData);
-
-  expect(result.status).toBe(403);  // ✅ Test security works!
-});
-```
-
----
-
-## Rule 4: Test with Least Privileged User
-
-**Always test with the LEAST privileged user who is authorized to perform the action.**
-
-### ❌ WRONG
-
-```typescript
-// Method allows S_USER, but testing with ADMIN
-@Roles(RoleEnum.S_USER)
-async getProducts() { }
-
-it('should get products', async () => {
-  const result = await request(app)
-    .get('/products')
-    .set('Authorization', adminToken);  // ❌ Over-privileged!
-});
-```
-
-### ✅ CORRECT
-
-```typescript
-@Roles(RoleEnum.S_USER)
-async getProducts() { }
-
-it('should get products as regular user', async () => {
-  const result = await request(app)
-    .get('/products')
-    .set('Authorization', regularUserToken);  // ✅ Least privilege
-});
-```
-
-**Why this matters:**
-- Tests might pass with ADMIN but fail with S_USER
-- You won't catch permission bugs
-- False confidence in security
-
----
-
-## Rule 5: Create Appropriate Test Users
-
-**Create test users for EACH permission level you need to test.**
-
-### Example Test Setup
-
-```typescript
-describe('ProductController', () => {
-  let adminToken: string;
-  let userToken: string;
-  let everyoneToken: string;
-
-  beforeAll(async () => {
-    // Create admin user
-    const admin = await createTestUser({
-      roles: [RoleEnum.ADMIN]
-    });
-    adminToken = admin.token;
-
-    // Create regular user
-    const user = await createTestUser({
-      roles: [RoleEnum.S_USER]
-    });
-    userToken = user.token;
-
-    // Create unauthenticated scenario
-    const guest = await createTestUser({
-      roles: [RoleEnum.S_EVERYONE]
-    });
-    everyoneToken = guest.token;
-  });
-
-  it('admin can delete products', async () => {
-    // Use adminToken
-  });
-
-  it('regular user can create products', async () => {
-    // Use userToken
-  });
-
-  it('everyone can view products', async () => {
-    // Use everyoneToken or no token
-  });
-
-  it('regular user cannot delete products', async () => {
-    // Use userToken, expect 403
-  });
-});
-```
-
----
-
-## Rule 6: Comprehensive Test Coverage
-
-**Aim for 80-100% test coverage depending on criticality:**
-
-- **High criticality** (payments, user data, admin functions): 95-100%
-- **Medium criticality** (business logic, CRUD): 80-90%
-- **Low criticality** (utilities, formatters): 70-80%
-
-### What to Test
-
-**For each endpoint/method:**
-
-1. ✅ Happy path (authorized user, valid data)
-2. ✅ Permission denied (unauthorized user)
-3. ✅ Validation errors (invalid input)
-4. ✅ Edge cases (empty data, boundaries)
-5. ✅ Error handling (server errors, missing resources)
-
-### Example Comprehensive Tests
-
-```typescript
-describe('createProduct', () => {
-  it('should create product with admin user', async () => {
-    // Happy path
-  });
-
-  it('should reject creation by regular user', async () => {
-    // Permission test
-  });
-
-  it('should reject invalid product data', async () => {
-    // Validation test
-  });
-
-  it('should reject duplicate product name', async () => {
-    // Business rule test
-  });
-
-  it('should handle missing required fields', async () => {
-    // Edge case
-  });
-});
-```
-
----
-
-## Quick Security Checklist
-
-Before completing ANY task:
-
-- [ ] **All @Restricted decorators preserved**
-- [ ] **@Roles decorators NOT made more permissive**
-- [ ] **Tests use appropriate user roles**
-- [ ] **Test users created for each permission level**
-- [ ] **Least privileged user tested**
-- [ ] **Permission denial tested (403 responses)**
-- [ ] **No securityCheck() logic bypassed**
-- [ ] **Test coverage ≥ 80%**
-- [ ] **All edge cases covered**
-
----
-
-## Security Decision Protocol
-
-**When you encounter a security-related decision:**
-
-1. **STOP** - Don't make the change immediately
-2. **ANALYZE** - Why does the current security exist?
-3. **ASK** - Consult the developer before changing
-4. **DOCUMENT** - If approved, document the reason
-5. **TEST** - Ensure security still works after change
-
-**Remember:**
-- **Security > Convenience**
-- **Better to over-restrict than under-restrict**
-- **Always preserve existing security mechanisms**
-- **When in doubt, ask the developer**

package/build/templates/claude-skills/generating-nest-servers/verification-checklist.md

@@ -1,262 +0,0 @@
----
-name: nest-server-generator-verification
-version: 1.0.0
-description: Comprehensive verification checklist for generated NestJS modules and objects - covers code generation, descriptions, API tests with security-first approach, test coverage requirements, and security rules compliance
----
-
-# Verification Checklist
-
-## Table of Contents
-- [Code Generation](#code-generation)
-- [API Tests - Security First](#api-tests---security-first)
-- [Test Coverage - Comprehensive Testing](#test-coverage---comprehensive-testing)
-- [Security Rules Compliance](#security-rules-compliance)
-- [Test Organization Structure](#test-organization-structure)
-- [Quick Verification Workflow](#quick-verification-workflow)
-- [Common Verification Failures](#common-verification-failures)
-- [Success Criteria](#success-criteria)
-
-After generation, verify all items in this comprehensive checklist:
-
-## Code Generation
-
-- [ ] All SubObjects created
-- [ ] All Objects created
-- [ ] All Modules created
-- [ ] All properties in alphabetical order
-- [ ] **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/`
-
----
-
-## API Tests - Security First
-
-**🚨 CRITICAL: Security analysis MUST be completed BEFORE writing ANY test!**
-
-### Permission Analysis (BEFORE Writing Tests)
-- [ ] **Permission analysis completed BEFORE writing tests**
-- [ ] **Analyzed ALL `@Roles()` decorators in controllers/resolvers**
-- [ ] **Read complete `securityCheck()` method in models**
-- [ ] **Understood permission hierarchy (specific overrides general)**
-
-### Test User Matrix (Principle of Least Privilege)
-- [ ] **Tests use LEAST privileged user (never admin when less works)**
-- [ ] **S_EVERYONE endpoints tested WITHOUT token**
-- [ ] **S_USER endpoints tested with REGULAR user (not admin)**
-- [ ] **UPDATE/DELETE tested with CREATOR token (not admin)**
-
-### Security Validation Tests (MANDATORY)
-- [ ] **Tests verify unauthorized access FAILS (401/403)**
-- [ ] **Tests verify non-creators CANNOT update/delete**
-- [ ] **Tests verify required fields**
-- [ ] **Security validation tests exist (permission failures)**
-
-### General Test Requirements
-- [ ] API tests created for all modules
-- [ ] Tests cover all CRUD operations
-- [ ] All tests pass
-- [ ] No TypeScript errors
-- [ ] Lint passes
-
----
-
-## Test Coverage - Comprehensive Testing
-
-**🎯 GOAL: Achieve the HIGHEST possible test coverage**
-
-### Functional Coverage
-- [ ] **Every endpoint has at least one successful test**
-- [ ] **Every endpoint has at least one failure test (unauthorized/validation)**
-- [ ] **All query parameters tested (filters, sorting, pagination)**
-- [ ] **All validation rules tested (required fields, min/max, patterns)**
-- [ ] **All relationships tested (creating/updating/deleting with references)**
-- [ ] **Edge cases tested (empty results, non-existent IDs, duplicate values)**
-- [ ] **Error handling tested (400, 401, 403, 404, 409 status codes)**
-- [ ] **Data integrity tested (cascading deletes, orphan prevention)**
-- [ ] **Business logic tested (custom methods, computed properties)**
-- [ ] **Performance tested (large datasets, pagination limits)**
-
-### Coverage Requirements
-- Minimum 80% line coverage for services
-- Minimum 90% line coverage for resolvers/controllers
-- 100% coverage for critical security logic (securityCheck, permission guards)
-- 100% coverage for all endpoints (success AND failure cases)
-- 100% coverage for all permission combinations
-- All public methods tested
-- All error paths tested
-
----
-
-## Security Rules Compliance
-
-**🚨 CRITICAL: These MUST be checked before completing**
-
-### Security Decorator Rules
-- [ ] **NO `@Restricted()` decorators removed from Controllers/Resolvers/Models/Objects**
-- [ ] **NO `@Roles()` decorators weakened to make tests pass**
-- [ ] **NO `securityCheck()` logic modified to bypass security**
-- [ ] **Class-level `@Restricted(ADMIN)` kept as security fallback**
-
-### Security Change Management
-- [ ] **All security changes discussed and approved by developer**
-- [ ] **All security changes documented with approval and reason**
-- [ ] **Tests adapted to security requirements (not vice versa)**
-
-### Test User Management
-- [ ] **Appropriate test users created for each permission level**
-- [ ] **Permission hierarchy understood and respected (specific overrides general)**
-
----
-
-## Test Organization Structure
-
-Use this structure for comprehensive, organized tests:
-
-```typescript
-describe('ProductResolver', () => {
-  // Setup
-  describe('Setup', () => {
-    beforeAll(async () => {
-      // Initialize test environment
-      // Create test users with different roles
-    });
-
-    afterAll(async () => {
-      // Cleanup all test data
-    });
-  });
-
-  // Happy path tests
-  describe('CREATE operations', () => {
-    it('should create product as regular user', ...);
-    it('should create product with all optional fields', ...);
-    it('should create product with relationships', ...);
-  });
-
-  describe('READ operations', () => {
-    it('should get product by ID', ...);
-    it('should list all products with pagination', ...);
-    it('should filter products by criteria', ...);
-    it('should sort products by field', ...);
-  });
-
-  describe('UPDATE operations', () => {
-    it('should update product as creator', ...);
-    it('should update product as admin', ...);
-    it('should update with partial data', ...);
-  });
-
-  describe('DELETE operations', () => {
-    it('should delete product as creator', ...);
-    it('should delete product as admin', ...);
-    it('should handle cascading deletes', ...);
-  });
-
-  // Security tests (MANDATORY)
-  describe('Security Validation', () => {
-    it('should FAIL to create without auth', ...);
-    it('should FAIL to update as non-creator', ...);
-    it('should FAIL to delete as non-creator', ...);
-    it('should FAIL to access with invalid token', ...);
-    it('should FAIL to read private data as different user', ...);
-  });
-
-  // Validation tests
-  describe('Input Validation', () => {
-    it('should FAIL with missing required fields', ...);
-    it('should FAIL with invalid field values', ...);
-    it('should FAIL with duplicate values', ...);
-    it('should FAIL with invalid references', ...);
-  });
-
-  // Edge cases
-  describe('Edge Cases', () => {
-    it('should handle non-existent ID (404)', ...);
-    it('should handle empty list results', ...);
-    it('should handle concurrent updates', ...);
-    it('should handle circular references', ...);
-  });
-});
-```
-
----
-
-## Quick Verification Workflow
-
-1. **Code Generation:**
-   - Run through all Code Generation checkboxes
-   - Pay special attention to DESCRIPTIONS - most common error!
-
-2. **API Tests - Security First:**
-   - Complete Permission Analysis BEFORE writing tests
-   - Create appropriate test users
-   - Write security validation tests FIRST
-   - Then write functional tests
-
-3. **Test Coverage:**
-   - Review coverage report
-   - Add tests for any uncovered code
-   - Aim for 90%+ overall coverage
-
-4. **Security Rules:**
-   - Double-check no decorators were removed
-   - Verify all security changes documented
-   - Confirm tests adapted to security (not vice versa)
-
-5. **Final Validation:**
-   - Run all tests: `npm test`
-   - Check TypeScript: `npm run build`
-   - Run linter: `npm run lint`
-
----
-
-## Common Verification Failures
-
-### ❌ Missing Descriptions
-**Problem:** Forgot to add descriptions to CreateInput or UpdateInput
-**Fix:** Add SAME description from Model to ALL Input files
-
-### ❌ Wrong Test Privileges
-**Problem:** Using admin token when S_USER would work
-**Fix:** Review @Roles decorator, use least privileged user
-
-### ❌ Missing Security Tests
-**Problem:** No tests for unauthorized access
-**Fix:** Add describe('Security Validation') block with 401/403 tests
-
-### ❌ Inconsistent Descriptions
-**Problem:** Different descriptions for same property in different files
-**Fix:** Standardize to one description across Model + CreateInput + UpdateInput
-
-### ❌ Security Decorator Removed
-**Problem:** Removed @Restricted to make test pass
-**Fix:** Keep decorator, fix test to use proper authentication
-
----
-
-## Success Criteria
-
-✅ **All checkboxes checked**
-✅ **All tests pass**
-✅ **No TypeScript errors**
-✅ **Lint passes**
-✅ **Coverage > 90%**
-✅ **Security rules maintained**
-✅ **Descriptions consistent**
-
-**When all criteria met → Generation complete! 🎉**