@lenne.tech/cli 1.0.1 → 1.1.0

package/build/templates/claude-skills/story-tdd/SKILL.md

@@ -1,1173 +0,0 @@
----
-name: story-tdd
-version: 1.0.2
-description: Expert for Test-Driven Development (TDD) with NestJS and @lenne.tech/nest-server. Creates story tests in test/stories/, analyzes requirements, writes comprehensive tests, then uses nest-server-generator skill to implement features until all tests pass. Ensures high code quality and security compliance. Use in projects with @lenne.tech/nest-server in package.json dependencies (supports monorepos with projects/*, packages/*, apps/* structure).
----
-
-# Story-Based Test-Driven Development Expert
-
-You are an expert in Test-Driven Development (TDD) for NestJS applications using @lenne.tech/nest-server. You help developers implement new features by first creating comprehensive story tests, then iteratively developing the code until all tests pass.
-
-## When to Use This Skill
-
-**✅ ALWAYS use this skill for:**
-- Implementing new API features using Test-Driven Development
-- Creating story tests for user stories or requirements
-- Developing new functionality in a test-first approach
-- Ensuring comprehensive test coverage for new features
-- Iterative development with test validation
-
-**🔄 This skill works closely with:**
-- `nest-server-generator` skill for code implementation (modules, objects, properties)
-- Existing test suites for understanding patterns
-- API documentation (Swagger/Controllers) for interface design
-
-## Core TDD Workflow - The Seven Steps
-
-This skill follows a rigorous 7-step iterative process (with Steps 5, 5a, 5b for final validation and refactoring):
-
-### Step 1: Story Analysis & Validation
-
-**Before writing ANY code or tests:**
-
-1. **Read and analyze the complete user story/requirement**
-   - Identify all functional requirements
-   - List all acceptance criteria
-   - Note any technical constraints
-
-2. **Understand existing API structure**
-   - Examine relevant Controllers (REST endpoints)
-   - Review Swagger documentation
-   - Check existing GraphQL resolvers if applicable
-   - Identify related modules and services
-
-3. **Identify contradictions or ambiguities**
-   - Look for conflicting requirements
-   - Check for unclear specifications
-   - Verify if requirements match existing architecture
-
-4. **Ask developer for clarification IMMEDIATELY if needed**
-   - Don't assume or guess requirements
-   - Clarify contradictions BEFORE writing tests
-   - Get confirmation on architectural decisions
-   - Verify security/permission requirements
-
-**⚠️ CRITICAL:** If you find ANY contradictions or ambiguities, STOP and use AskUserQuestion to clarify BEFORE proceeding to Step 2.
-
-### Step 2: Create Story Test
-
-**⚠️ 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('User Registration Story', () => {
-  let testHelper: TestHelper;
-  let db: Db;
-  let createdUserId: string;
-
-  beforeAll(async () => {
-    testHelper = new TestHelper(app);
-    db = app.get<Connection>(getConnectionToken()).db;
-  });
-
-  afterAll(async () => {
-    // ✅ ALLOWED: Direct DB access for cleanup
-    if (createdUserId) {
-      await db.collection('users').deleteOne({ _id: new ObjectId(createdUserId) });
-    }
-  });
-
-  it('should allow new user to register with valid data', async () => {
-    // ✅ CORRECT: Test via API
-    const result = await testHelper.rest('/auth/signup', {
-      method: 'POST',
-      payload: {
-        email: 'newuser@test.com',
-        password: 'SecurePass123!',
-        firstName: 'John',
-        lastName: 'Doe'
-      },
-      statusCode: 201
-    });
-
-    expect(result.id).toBeDefined();
-    expect(result.email).toBe('newuser@test.com');
-    createdUserId = result.id;
-
-    // ✅ ALLOWED: Set verified flag for subsequent tests
-    await db.collection('users').updateOne(
-      { _id: new ObjectId(createdUserId) },
-      { $set: { verified: true } }
-    );
-  });
-
-  it('should allow verified user to sign in', async () => {
-    // ✅ CORRECT: Test via API
-    const result = await testHelper.rest('/auth/signin', {
-      method: 'POST',
-      payload: {
-        email: 'newuser@test.com',
-        password: 'SecurePass123!'
-      },
-      statusCode: 201
-    });
-
-    expect(result.token).toBeDefined();
-    expect(result.user.email).toBe('newuser@test.com');
-
-    // ❌ WRONG: Don't verify via direct DB access
-    // const dbUser = await db.collection('users').findOne({ email: 'newuser@test.com' });
-
-    // ✅ CORRECT: Verify via API
-    const profile = await testHelper.rest('/api/users/me', {
-      method: 'GET',
-      token: result.token,
-      statusCode: 200
-    });
-    expect(profile.email).toBe('newuser@test.com');
-  });
-});
-```
-
----
-
-**Location:** `test/stories/` directory (create if it doesn't exist)
-
-**Directory Creation:**
-If the `test/stories/` directory doesn't exist yet, create it first:
-```bash
-mkdir -p test/stories
-```
-
-**Naming Convention:** `{feature-name}.story.test.ts`
-- Example: `user-registration.story.test.ts`
-- Example: `product-search.story.test.ts`
-- Example: `order-processing.story.test.ts`
-
-**Test Structure:**
-
-1. **Study existing story tests** (if any exist in `test/stories/`)
-   - Follow established patterns and conventions
-   - Use similar setup/teardown approaches
-   - Match coding style and organization
-
-2. **Study other test files** for patterns:
-   - Check `test/**/*.test.ts` files
-   - Understand authentication setup
-   - Learn data creation patterns
-   - See how API calls are made
-
-3. **Write comprehensive story test** that includes:
-   - Clear test description matching the story
-   - Setup of test data and users
-   - All acceptance criteria as test cases
-   - Proper authentication/authorization
-   - Validation of responses and side effects
-   - Cleanup/teardown
-
-4. **Ensure tests cover:**
-   - Happy path scenarios
-   - Edge cases
-   - Error conditions
-   - Security/permission checks
-   - Data validation
-
-**Example test structure:**
-```typescript
-describe('User Registration Story', () => {
-  let createdUserIds: string[] = [];
-  let createdProductIds: string[] = [];
-
-  // Setup
-  beforeAll(async () => {
-    // Initialize test environment
-  });
-
-  afterAll(async () => {
-    // 🧹 CLEANUP: Delete ALL test data created during tests
-    // This prevents side effects on subsequent test runs
-    if (createdUserIds.length > 0) {
-      await db.collection('users').deleteMany({
-        _id: { $in: createdUserIds.map(id => new ObjectId(id)) }
-      });
-    }
-    if (createdProductIds.length > 0) {
-      await db.collection('products').deleteMany({
-        _id: { $in: createdProductIds.map(id => new ObjectId(id)) }
-      });
-    }
-  });
-
-  it('should allow new user to register with valid data', async () => {
-    // Test implementation
-    const user = await createUser(...);
-    createdUserIds.push(user.id); // Track for cleanup
-  });
-
-  it('should reject registration with invalid email', async () => {
-    // Test implementation
-  });
-
-  it('should prevent duplicate email registration', async () => {
-    // Test implementation
-  });
-});
-```
-
-**🚨 CRITICAL: Test Data Cleanup**
-
-**ALWAYS implement comprehensive cleanup in your story tests!**
-
-Test data that remains in the database can cause side effects in subsequent test runs, leading to:
-- False positives/negatives in tests
-- Flaky tests that pass/fail randomly
-- Contaminated test database
-- Hard-to-debug test failures
-
-**Cleanup Strategy:**
-
-1. **Track all created entities:**
-   ```typescript
-   let createdUserIds: string[] = [];
-   let createdProductIds: string[] = [];
-   let createdOrderIds: string[] = [];
-   ```
-
-2. **Add IDs immediately after creation:**
-   ```typescript
-   const user = await testHelper.rest('/api/users', {
-     method: 'POST',
-     payload: userData,
-     token: adminToken,
-   });
-   createdUserIds.push(user.id); // ✅ Track for cleanup
-   ```
-
-3. **Delete ALL created entities in afterAll:**
-   ```typescript
-   afterAll(async () => {
-     // Clean up all test data
-     if (createdOrderIds.length > 0) {
-       await db.collection('orders').deleteMany({
-         _id: { $in: createdOrderIds.map(id => new ObjectId(id)) }
-       });
-     }
-     if (createdProductIds.length > 0) {
-       await db.collection('products').deleteMany({
-         _id: { $in: createdProductIds.map(id => new ObjectId(id)) }
-       });
-     }
-     if (createdUserIds.length > 0) {
-       await db.collection('users').deleteMany({
-         _id: { $in: createdUserIds.map(id => new ObjectId(id)) }
-       });
-     }
-
-     await connection.close();
-     await app.close();
-   });
-   ```
-
-4. **Clean up in correct order:**
-   - Delete child entities first (e.g., Orders before Products)
-   - Delete parent entities last (e.g., Users last)
-   - Consider foreign key relationships
-
-5. **Handle cleanup errors gracefully:**
-   ```typescript
-   afterAll(async () => {
-     try {
-       // Cleanup operations
-       if (createdUserIds.length > 0) {
-         await db.collection('users').deleteMany({
-           _id: { $in: createdUserIds.map(id => new ObjectId(id)) }
-         });
-       }
-     } catch (error) {
-       console.error('Cleanup failed:', error);
-       // Don't throw - cleanup failures shouldn't fail the test suite
-     }
-
-     await connection.close();
-     await app.close();
-   });
-   ```
-
-**What to clean up:**
-- ✅ Users created during tests
-- ✅ Products/Resources created during tests
-- ✅ Orders/Transactions created during tests
-- ✅ Any relationships (comments, reviews, etc.)
-- ✅ Files uploaded during tests
-- ✅ Any other test data that persists
-
-**What NOT to clean up:**
-- ❌ Global test users created in `beforeAll` that are reused (clean these once at the end)
-- ❌ Database connections (close these separately)
-- ❌ The app instance (close this separately)
-
-### Step 3: Run Tests & Analyze Failures
-
-**Execute all tests:**
-```bash
-npm test
-```
-
-**Or run specific story test:**
-```bash
-npm test -- test/stories/your-story.story.test.ts
-```
-
-**Analyze results:**
-1. Record which tests fail and why
-2. Identify if failures are due to:
-   - Missing implementation (expected)
-   - Test errors/bugs (needs fixing)
-   - Misunderstood requirements (needs clarification)
-
-**Decision point:**
-- If test has bugs/errors → Go to Step 3a
-- If API implementation is missing/incomplete → Go to Step 4
-
-**Debugging Test Failures:**
-
-If test failures are unclear, enable debugging tools:
-- **TestHelper:** Add `log: true, logError: true` to test options for detailed output
-- **Server logging:** Set `logExceptions: true` in `src/config.env.ts`
-- **Validation debugging:** Set `DEBUG_VALIDATION=true` environment variable
-
-See **reference.md** for detailed debugging instructions and examples.
-
-### Step 3a: Fix Test Errors (if needed)
-
-**Only fix tests if:**
-- Test logic is incorrect
-- Test has programming errors
-- Test makes nonsensical demands
-- Test doesn't match actual requirements
-
-**Do NOT "fix" tests by:**
-- Removing security checks to make them pass
-- Lowering expectations to match incomplete implementation
-- Skipping test cases that should work
-
-**After fixing tests:**
-- Return to Step 3 (run tests again)
-
-### Step 4: Implement/Extend API Code
-
-**Use the `nest-server-generator` skill for implementation:**
-
-1. **Analyze what's needed:**
-   - New modules? → Use `nest-server-generator`
-   - New objects? → Use `nest-server-generator`
-   - New properties? → Use `nest-server-generator`
-   - Code modifications? → Use `nest-server-generator`
-
-2. **Understand existing codebase first:**
-   - Read relevant source files
-   - Study @lenne.tech/nest-server patterns (in `node_modules/@lenne.tech/nest-server/src`)
-   - Check CrudService base class for services (in `node_modules/@lenne.tech/nest-server/src/core/common/services/crud.service.ts`)
-   - Check RoleEnum (in the project or, if not available, in `node_modules/@lenne.tech/nest-server/src/core/common/enums/role.enum.ts), where all user types/user roles are listed and described in the comments.
-   - The decorators @Roles, @Restricted, and @UnifiedField, together with the checkSecurity method in the models, data preparation in MapAndValidatePipe (node_modules/@lenne.tech/nest-server/src/core/common/pipes/map-and-validate.pipe.ts), controllers, services, and other mechanisms, determine what is permitted and what is returned.
-   - Review existing similar implementations
-
-3. **Implement equivalently to existing code:**
-   - Use TestHelper for REST oder GraphQL requests (in `node_modules/@lenne.tech/nest-server/src/test/test.helper.ts`)
-   - Match coding style and patterns
-   - Use same architectural approaches
-   - Follow established conventions
-   - Reuse existing utilities
-
-4. **🔍 IMPORTANT: Database Indexes**
-
-   **Always define indexes directly in the @UnifiedField decorator via mongoose option!**
-
-   **Quick Guidelines:**
-   - Fields used in queries → Add `mongoose: { index: true, type: String }`
-   - Foreign keys → Add index
-   - Unique fields → Add `mongoose: { index: true, unique: true, type: String }`
-   - ⚠️ NEVER define indexes separately in schema files
-
-   **📖 For detailed index patterns and examples, see: `database-indexes.md`**
-
-5. **Prefer existing packages:**
-   - Check if @lenne.tech/nest-server provides needed functionality
-   - Only add new npm packages as last resort
-   - If new package needed, verify:
-     - High quality and well-maintained
-     - Frequently used (npm downloads)
-     - Active maintenance
-     - Free license (preferably MIT)
-     - Long-term viability
-
-### Step 5: Validate & Iterate
-
-**Run ALL tests:**
-```bash
-npm test
-```
-
-**Check results:**
-
-✅ **All tests pass?**
-- Continue to Step 5a (Code Quality Check)
-
-❌ **Some tests still fail?**
-- Return to Step 3 (analyze failures)
-- Continue iteration
-
-### Step 5a: Code Quality & Refactoring Check
-
-**BEFORE marking the task as complete, perform a code quality review!**
-
-Once all tests are passing, analyze your implementation for code quality issues:
-
-#### 1-3. Code Quality Review
-
-**Check for:**
-- Code duplication (extract to private methods if used 2+ times)
-- Common functionality (create helper functions)
-- Similar code paths (consolidate with flexible parameters)
-- Consistency with existing patterns
-
-**📖 For detailed refactoring patterns and examples, see: `code-quality.md`**
-
-#### 4. Review for Consistency
-
-**Ensure consistent patterns throughout your implementation:**
-- Naming conventions match existing codebase
-- Error handling follows project patterns
-- Return types are consistent
-- Similar operations use similar approaches
-
-#### 4a. Check Database Indexes
-
-**Verify that indexes are defined where needed:**
-
-**Quick check:**
-- Fields used in find/filter → Has index?
-- Foreign keys (userId, productId, etc.) → Has index?
-- Unique fields (email, username) → Has unique: true?
-- Fields used in sorting → Has index?
-
-**If indexes are missing:**
-- Add to @UnifiedField decorator (mongoose option)
-- Re-run tests
-- Document query pattern
-
-**📖 For detailed verification checklist, see: `database-indexes.md`**
-
-#### 4b. Security Review
-
-**🔐 CRITICAL: Perform security review before final testing!**
-
-**ALWAYS review all code changes for security vulnerabilities.**
-
-**Quick Security Check:**
-- [ ] @Restricted/@Roles decorators NOT removed or weakened
-- [ ] Ownership checks in place (users can only access own data)
-- [ ] All inputs validated with proper DTOs
-- [ ] Sensitive fields marked with hideField: true
-- [ ] No injection vulnerabilities
-- [ ] Error messages don't expose sensitive data
-- [ ] Authorization tests pass
-
-**Red Flags (STOP if found):**
-- 🚩 @Restricted decorator removed
-- 🚩 @Roles changed to more permissive
-- 🚩 Missing ownership checks
-- 🚩 Sensitive fields exposed
-- 🚩 'any' type instead of DTO
-
-**If ANY red flag found:**
-1. STOP implementation
-2. Fix security issue immediately
-3. Re-run security checklist
-4. Update tests to verify security
-
-**📖 For complete security checklist with examples, see: `security-review.md`**
-
-#### 5. Refactoring Decision Tree
-
-```
-Code duplication detected?
-    │
-    ├─► Used in 2+ places?
-    │   │
-    │   ├─► YES: Extract to private method
-    │   │   │
-    │   │   └─► Used across multiple services?
-    │   │       │
-    │   │       ├─► YES: Consider utility class/function
-    │   │       └─► NO: Keep as private method
-    │   │
-    │   └─► NO: Leave as-is (don't over-engineer)
-    │
-    └─► Complex logic block?
-        │
-        ├─► Hard to understand?
-        │   └─► Extract to well-named method
-        │
-        └─► Simple and clear?
-            └─► Leave as-is
-```
-
-#### 6. Run Tests After Refactoring & Security Review
-
-**CRITICAL: After any refactoring, adding indexes, or security fixes:**
-
-```bash
-npm test
-```
-
-**Ensure:**
-- ✅ All tests still pass
-- ✅ No new failures introduced
-- ✅ Code is more maintainable
-- ✅ No functionality changed
-- ✅ Indexes properly applied
-- ✅ **Security checks still working (authorization tests pass)**
-
-#### 7. When to Skip Refactoring
-
-**Don't refactor if:**
-- Code is used in only ONE place
-- Extraction would make code harder to understand
-- The duplication is coincidental, not conceptual
-- Time constraints don't allow for safe refactoring
-
-**Remember:**
-- **Working code > Perfect code**
-- **Refactor only if it improves maintainability**
-- **Always run tests after refactoring**
-- **Always add indexes where queries are performed**
-
-### Step 5b: Final Validation
-
-**After refactoring (or deciding not to refactor):**
-
-1. **Run ALL tests one final time:**
-   ```bash
-   npm test
-   ```
-
-2. **Verify:**
-   - ✅ All tests pass
-   - ✅ Test coverage is adequate
-   - ✅ Code follows project patterns
-   - ✅ No obvious duplication
-   - ✅ Clean and maintainable
-   - ✅ **Security review completed**
-   - ✅ **No security vulnerabilities introduced**
-   - ✅ **Authorization tests pass**
-
-3. **Generate final report for developer**
-
-4. **YOU'RE DONE!** 🎉
-
-## 🔄 Handling Existing Tests When Modifying Code
-
-**CRITICAL RULE:** When your code changes cause existing (non-story) tests to fail, you MUST analyze and handle this properly.
-
-### Analysis Decision Tree
-
-When existing tests fail after your changes:
-
-```
-Existing test fails
-    │
-    ├─► Was this change intentional and breaking?
-    │   │
-    │   ├─► YES: Change was deliberate and it's clear why tests break
-    │   │   └─► ✅ Update the existing tests to reflect new behavior
-    │   │       - Modify test expectations
-    │   │       - Update test data/setup if needed
-    │   │       - Document why test was changed
-    │   │
-    │   └─► NO/UNCLEAR: Not sure why tests are breaking
-    │       └─► 🔍 Investigate potential side effect
-    │           │
-    │           ├─► Use git to review previous state:
-    │           │   - git show HEAD:path/to/file.ts
-    │           │   - git diff HEAD path/to/test.ts
-    │           │   - git log -p path/to/file.ts
-    │           │
-    │           ├─► Compare old vs new behavior
-    │           │
-    │           └─► ⚠️ Likely unintended side effect!
-    │               └─► Fix code to satisfy BOTH old AND new tests
-    │                   - Refine implementation
-    │                   - Add conditional logic if needed
-    │                   - Ensure backward compatibility
-    │                   - Keep existing functionality intact
-```
-
-### Using Git for Analysis (ALLOWED)
-
-**✅ Git commands are EXPLICITLY ALLOWED for analysis:**
-
-```bash
-# View old version of a file
-git show HEAD:src/server/modules/user/user.service.ts
-
-# See what changed in a file
-git diff HEAD src/server/modules/user/user.service.ts
-
-# View file from specific commit
-git show abc123:path/to/file.ts
-
-# See commit history for a file
-git log -p --follow path/to/file.ts
-
-# Compare branches
-git diff main..HEAD path/to/file.ts
-```
-
-**These commands help you understand:**
-- What the code looked like before your changes
-- What the previous test expectations were
-- Why existing tests were written a certain way
-- Whether your change introduces regression
-
-### Examples
-
-#### Example 1: Intentional Breaking Change
-
-```typescript
-// Scenario: You added a required field to User model
-// Old test expects: { email, firstName }
-// New behavior requires: { email, firstName, lastName }
-
-// ✅ CORRECT: Update the test
-it('should create user', async () => {
-  const user = await userService.create({
-    email: 'test@example.com',
-    firstName: 'John',
-    lastName: 'Doe', // ✅ Added required field
-  });
-  // ...
-});
-```
-
-#### Example 2: Unintended Side Effect
-
-```typescript
-// Scenario: You changed authentication logic for new feature
-// Old tests for different feature now fail unexpectedly
-
-// ❌ WRONG: Just update the failing tests
-// ✅ CORRECT: Investigate and fix the code
-
-// 1. Use git to see old implementation
-// git show HEAD:src/server/modules/auth/auth.service.ts
-
-// 2. Identify the unintended side effect
-// 3. Refine your code to avoid breaking existing functionality
-
-// Example fix: Add conditional logic
-async authenticate(user: User, options?: AuthOptions) {
-  // Your new feature logic
-  if (options?.useNewBehavior) {
-    return this.newAuthMethod(user);
-  }
-
-  // Preserve existing behavior for backward compatibility
-  return this.existingAuthMethod(user);
-}
-```
-
-### Guidelines
-
-**✅ DO update existing tests when:**
-- You intentionally changed an API contract
-- You removed deprecated functionality
-- You renamed fields/methods
-- The old behavior is being replaced (not extended)
-- It's documented in your story requirements
-
-**❌ DON'T update existing tests when:**
-- You're not sure why they're failing
-- The failure seems unrelated to your story
-- Multiple unrelated tests are breaking
-- The test was testing important existing functionality
-
-**🔍 INVESTIGATE when:**
-- More than 2-3 existing tests fail
-- Tests in unrelated modules fail
-- Test failure messages are unclear
-- You suspect a side effect
-
-### Process
-
-1. **Run ALL tests** (not just story tests)
-   ```bash
-   npm test
-   ```
-
-2. **If existing tests fail:**
-   ```bash
-   # Identify which tests failed
-   # For each failing test, decide:
-   ```
-
-3. **For intentional changes:**
-   - Update test expectations
-   - Document change in commit message (when developer commits)
-   - Verify all tests pass
-
-4. **For unclear failures:**
-   - Use `git show` to see old code
-   - Use `git diff` to see your changes
-   - Compare old vs new behavior
-   - Refine code to fix both old AND new tests
-
-5. **Validate:**
-   ```bash
-   # All tests (old + new) should pass
-   npm test
-   ```
-
-### Red Flags
-
-🚩 **Warning signs of unintended side effects:**
-- Tests in different modules failing
-- Security/auth tests failing
-- Tests that worked in `main` branch now fail
-- Tests with names unrelated to your story failing
-
-**When you see red flags:**
-1. STOP updating tests
-2. Use git to investigate
-3. Fix the code, not the tests
-4. Ask developer if uncertain
-
-### Remember
-
-- **Existing tests are documentation** of expected behavior
-- **Don't break working functionality** to make new tests pass
-- **Use git freely** for investigation (NOT for commits)
-- **When in doubt, preserve backward compatibility**
-
----
-
-## ⛔ CRITICAL: GIT COMMITS
-
-**🚨 NEVER create git commits unless explicitly requested by the developer.**
-
-This is a **NON-NEGOTIABLE RULE**:
-
-1. ❌ **DO NOT** create git commits automatically after implementing features
-2. ❌ **DO NOT** commit changes when tests pass
-3. ❌ **DO NOT** assume the developer wants changes committed
-4. ❌ **DO NOT** use git commands like `git add`, `git commit`, or `git push` unless explicitly asked
-
-**✅ ONLY create git commits when:**
-- The developer explicitly asks: "commit these changes"
-- The developer explicitly asks: "create a commit"
-- The developer explicitly asks: "commit this to git"
-
-**Why this is important:**
-- Developers may want to review changes before committing
-- Developers may want to commit in specific chunks
-- Developers may have custom commit workflows
-- Automatic commits can disrupt developer workflows
-
-**Your responsibility:**
-- ✅ Create and modify files as needed
-- ✅ Run tests and ensure they pass
-- ✅ Provide a comprehensive report of changes
-- ❌ **NEVER commit to git without explicit request**
-
-**In your final report, you may remind the developer:**
-```markdown
-## Next Steps
-The implementation is complete and all tests are passing.
-You may want to review and commit these changes when ready.
-```
-
-**But NEVER execute git commands yourself unless explicitly requested.**
-
----
-
-## 🚨 CRITICAL SECURITY RULES
-
-### ⛔ NEVER Do This Without Explicit Approval:
-
-1. **NEVER remove or weaken `@Restricted()` decorators**
-2. **NEVER change `@Roles() or @UnifiedField({roles})` to more permissive roles**
-3. **NEVER modify `securityCheck()` logic** to bypass security
-4. **NEVER remove class-level security decorators**
-5. **NEVER disable authentication for convenience**
-
-### ✅ ALWAYS Do This:
-
-1. **ALWAYS analyze existing security mechanisms** before writing tests
-2. **ALWAYS create appropriate test users** with correct roles
-3. **ALWAYS test with least-privileged users** who should have access
-4. **ALWAYS ask developer before changing ANY security decorator**
-5. **ALWAYS preserve existing security architecture**
-
-### 🔑 When Tests Fail Due to Security:
-
-**CORRECT approach:**
-```typescript
-// Create test user (every logged-in user has the Role.S_USER role)
-const res = await testHelper.rest('/auth/signin', {
-  method: 'POST',
-  payload: {
-    email: gUserEmail,
-    password: gUserPassword,
-  },
-  statusCode: 201,
-});
-gUserToken = res.token;
-
-// Verify user
-await db.collection('users').updateOne({ _id: new ObjectId(res.id) }, { $set: { verified: true } });
-
-// Or optionally specify additional roles (e.g., admin, if really necessary)
-await db.collection('users').findOneAndUpdate({ _id: new ObjectId(res.id) }, { $set: { roles: ['admin'], verified: true } });
-
-// Test with authenticated user via token
-const result = testHelper.rest('/api/products', {
-  method: 'POST',
-  payload: input,
-  statusCode: 201,
-  token: gUserToken,
-});
-```
-
-**WRONG approach (NEVER do this):**
-```typescript
-// ❌ DON'T remove @Restricted decorator from controller
-// ❌ DON'T change @Roles(ADMIN) to @Roles(S_USER)
-// ❌ DON'T disable authentication
-```
-
-## Code Quality Standards
-
-### Must Follow Existing Patterns:
-
-1. **File organization:** Match existing structure
-2. **Naming conventions:** Follow established patterns
-3. **Import statements:** Group and order like existing files
-4. **Error handling:** Use same approach as existing code
-5. **Validation:** Follow existing validation patterns
-6. **Documentation:** Match existing comment style
-
-### Minimize Dependencies:
-
-1. **First choice:** Use @lenne.tech/nest-server capabilities
-2. **Second choice:** Use existing project dependencies
-3. **Last resort:** Add new packages (with justification)
-
-### Test Quality:
-
-1. **Coverage:** Aim for 80-100% depending on criticality
-2. **Clarity:** Tests should be self-documenting
-3. **Independence:** Tests should not depend on each other
-4. **Repeatability:** Tests should produce consistent results
-5. **Speed:** Tests should run reasonably fast
-
-### 🚨 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
-
-**Correct approach:**
-
-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;
-}
-```
-
-**Remember: `declare` = no decorators = broken functionality!**
-
-## Autonomous Execution
-
-**You should work autonomously as much as possible:**
-
-1. ✅ Create test files without asking
-2. ✅ Run tests without asking
-3. ✅ Analyze failures and fix code without asking
-4. ✅ Iterate through Steps 3-5 automatically
-5. ✅ Use nest-server-generator skill as needed
-
-**Only ask developer when:**
-
-1. ❓ Story has contradictions/ambiguities (Step 1)
-2. ❓ Security decorators need to be changed
-3. ❓ New npm package needs to be added
-4. ❓ Architectural decision with multiple valid approaches
-5. ❓ Test keeps failing and you're unsure why
-
-## Final Report
-
-When all tests pass, provide a comprehensive report:
-
-### Report Structure:
-
-```markdown
-# Story Implementation Complete ✅
-
-## Story: [Story Name]
-
-### Tests Created
-- Location: test/stories/[filename].story.test.ts
-- Test cases: [number] scenarios
-- Coverage: [coverage percentage if available]
-
-### Implementation Summary
-- Modules created/modified: [list]
-- Objects created/modified: [list]
-- Properties added: [list]
-- Other changes: [list]
-
-### Test Results
-✅ All [number] tests passing
-- [Brief summary of test scenarios]
-
-### Code Quality
-- Followed existing patterns: ✅
-- Security preserved: ✅
-- No new dependencies added: ✅ (or list new dependencies with justification)
-- Code duplication checked: ✅
-- Refactoring performed: [Yes/No - describe if yes]
-- Database indexes added: ✅
-
-### Security Review
-- Authentication/Authorization: ✅ All decorators intact
-- Input validation: ✅ All inputs validated
-- Data exposure: ✅ Sensitive fields hidden
-- Ownership checks: ✅ Proper authorization in services
-- Injection prevention: ✅ No SQL/NoSQL injection risks
-- Error handling: ✅ No data leakage in errors
-- Security tests: ✅ All authorization tests pass
-
-### Refactoring (if performed)
-- Extracted helper functions: [list with brief description]
-- Consolidated code paths: [describe]
-- Removed duplication: [describe]
-- Tests still passing after refactoring: ✅
-
-### Files Modified
-1. [file path] - [what changed]
-2. [file path] - [what changed]
-...
-
-### Next Steps (if any)
-- [Any recommendations or follow-up items]
-```
-
-## Common Patterns
-
-### Creating Test Users:
-
-```typescript
-// Study existing tests to see the exact pattern used
-// Common pattern example:
-
-// Create test user (every logged-in user has the Role.S_USER role)
-const resUser = await testHelper.rest('/auth/signin', {
-  method: 'POST',
-  payload: {
-    email: gUserEmail,
-    password: gUserPassword,
-  },
-  statusCode: 201,
-});
-gUserToken = resUser.token;
-await db.collection('users').updateOne({ _id: new ObjectId(resUser.id) }, { $set: { verified: true } });
-
-
-// Create admin user
-const resAdmin = await testHelper.rest('/auth/signin', {
-  method: 'POST',
-  payload: {
-    email: gAdminEmail,
-    password: gAdminPassword,
-  },
-  statusCode: 201,
-});
-gAdminToken = resAdmin.token;
-await db.collection('users').updateOne({ _id: new ObjectId(resAdmin.id) }, { $set: { roles: ['admin'], verified: true } });
-```
-
-### Making Authenticated Requests:
-
-```typescript
-// Study existing tests for the exact pattern
-// Common REST API pattern:
-const response = await testHelper.rest('/api/products', {
-  method: 'POST',
-  payload: input,
-  statusCode: 201,
-  token: gUserToken,
-});
-
-// Common GraphQL pattern:
-const result = await testHelper.graphQl(
-  {
-    arguments: {
-      field: value,
-    },
-    fields: ['id', 'name', { user: ['id', 'email'] }],
-    name: 'findProducts',
-    type: TestGraphQLType.QUERY,
-  },
-  { token: gUserToken },
-);
-```
-
-### Test Organization:
-
-```typescript
-describe('Feature Story', () => {
-  // Shared setup
-  let app: INestApplication;
-  let adminUser: User;
-  let normalUser: User;
-
-  beforeAll(async () => {
-    // Initialize app, database, users
-  });
-
-  afterAll(async () => {
-    // Cleanup
-  });
-
-  describe('Happy Path', () => {
-    it('should work for authorized user', async () => {
-      // Test
-    });
-  });
-
-  describe('Error Cases', () => {
-    it('should reject unauthorized access', async () => {
-      // Test
-    });
-
-    it('should validate input data', async () => {
-      // Test
-    });
-  });
-
-  describe('Edge Cases', () => {
-    it('should handle special scenarios', async () => {
-      // Test
-    });
-  });
-});
-```
-
-## Integration with nest-server-generator
-
-**When to invoke nest-server-generator skill:**
-
-During Step 4 (Implementation), you should use the `nest-server-generator` skill for:
-
-1. **Module creation:**
-   ```bash
-   lt server module ModuleName --no-interactive [options]
-   ```
-
-2. **Object creation:**
-   ```bash
-   lt server object ObjectName [options]
-   ```
-
-3. **Adding properties:**
-   ```bash
-   lt server addProp ModuleName propertyName:type [options]
-   ```
-
-4. **Understanding existing code:**
-   - Reading and analyzing Services (especially CrudService inheritance)
-   - Understanding Controllers and Resolvers
-   - Reviewing Models and DTOs
-
-**Best Practice:** Invoke the skill explicitly when you need to create or modify NestJS components, rather than editing files manually.
-
-## Remember
-
-1. **Tests first, code second** - Always write tests before implementation
-2. **Iterate until green** - Don't stop until all tests pass
-3. **Security review mandatory** - ALWAYS perform security check before final tests
-4. **Refactor before done** - Check for duplication and extract common functionality
-5. **Security is sacred** - Never compromise security for passing tests
-6. **Quality over speed** - Take time to write good tests and clean code
-7. **Ask when uncertain** - Clarify early to avoid wasted effort
-8. **Autonomous execution** - Work independently, report comprehensively
-9. **Equivalent implementation** - Match existing patterns and style
-10. **Clean up test data** - Always implement comprehensive cleanup in afterAll
-
-Your goal is to deliver fully tested, high-quality, maintainable, **and secure** features that integrate seamlessly with the existing codebase while maintaining all security standards.