@futdevpro/fsm-dynamo 1.15.1 → 1.15.2

package/.cursor/rules/_ag_file-refactoring.mdc

@@ -0,0 +1,113 @@
+---
+description: when refactoring large files or extracting code sections from files
+alwaysApply: false
+---
+# File Refactoring és Code Extraction Guidelines
+
+## Extract File Content Parancs Használata
+
+Amikor nagy fájlokat refaktorálunk vagy kód részeket extraktolunk fájlból, **MINDIG** használjuk a Dynamo CLI `extract-file-content` parancsát.
+
+### Parancs Használata
+
+```bash
+dc efc <source-file> --start <start-line> --end <end-line> --output <output-name> [--target-dir <target-directory>]
+```
+
+Vagy a hosszabb alias-szal:
+```bash
+dc extract-file-content <source-file> --start <start-line> --end <end-line> --output <output-name> [--target-dir <target-directory>]
+```
+
+### Paraméterek
+
+- `<source-file>` - A forrás fájl elérési útja (relatív vagy abszolút)
+- `--start <start-line>` - A kezdő sor száma (1-based, beleértve ezt a sort)
+- `--end <end-line>` - A vég sor száma (1-based, beleértve ezt a sort)
+- `--output <output-name>` - A kimeneti fájl neve (kiterjesztés nélkül vagy kiterjesztéssel)
+- `--target-dir <target-directory>` - Opcionális: célkönyvtár (alapértelmezett: ugyanaz, mint a forrás fájl könyvtára)
+
+### Automatikus Funkciók
+
+A parancs automatikusan:
+- **Detektálja és hozzáadja a szükséges importokat** a kiemelt kód alapján
+- **Hozzáadja a copyright header-t** (TypeScript fájlok esetén)
+- **Törli a kiemelt sorokat** az eredeti fájlból
+- **Konvertálja a fájlnevet kebab-case-re**
+- **MD fájlok esetén** nem ad hozzá copyright headert és importokat
+
+### Használati Esetek
+
+#### 1. Nagy Fájlok Refaktorálása
+
+Ha egy fájl **500+ sor** hosszú, és logikailag szétbontható:
+1. Azonosítsd a különálló funkcionalitást vagy modult
+2. Használd az `efc` parancsot a kód kiemelésére új fájlba
+3. Az eredeti fájlból automatikusan törlődnek a kiemelt sorok
+
+**Példa:**
+```bash
+# Kiemeljük a user validation logikát egy külön fájlba
+dc efc src/services/user.service.ts --start 150 --end 300 --output user-validation
+# Ez létrehozza: src/services/user-validation.ts
+```
+
+#### 2. Modulok Kiemelése
+
+Amikor egy nagy fájlból külön modult vagy service-t szeretnénk kiemelni:
+1. Határozd meg a modul kezdő és vég sorait
+2. Add meg a kimeneti fájl nevét
+3. Opcionálisan add meg a célkönyvtárat
+
+**Példa:**
+```bash
+# Kiemeljük a notification service-t egy külön fájlba
+dc efc src/services/communication.service.ts --start 50 --end 200 --output notification-service --target-dir src/services/notifications
+```
+
+#### 3. TypeScript Interface-ek és Type-ok Kiemelése
+
+Amikor type definíciókat szeretnénk külön fájlba kiemelni:
+```bash
+dc efc src/models/user.model.ts --start 1 --end 50 --output user-types --target-dir src/models/types
+```
+
+### Fontos Megjegyzések
+
+- **MINDIG** használd ezt a parancsot nagy fájlok refaktorálásakor
+- A parancs **automatikusan törli** a kiemelt sorokat az eredeti fájlból
+- Az importok **automatikusan detektálódnak** és hozzáadódnak az új fájlhoz
+- MD fájlok esetén csak a tartalom kerül kiemelésre (nincs header, nincs import)
+- A fájlnevek **automatikusan kebab-case-re** konvertálódnak
+- **PowerShell környezet**: Mivel PowerShell-ben dolgozunk, a mappa választás és parancs elválasztására **pontosvesszőt (;)** kell használni, nem az és-és (&&) operátort
+
+### Workflow
+
+1. Azonosítsd a kiemelendő kód részt (kezdő és vég sor)
+   - **FONTOS**: Ahhoz, hogy az előre meghatározott sor számok jók legyenek, **hátulról előre kell haladni** - tehát csak a magas számokkal kezdjünk, legmagasabbal, és attól megyünk lefelé
+2. Futtasd az `efc` parancsot a megfelelő paraméterekkel
+3. Ellenőrizd az új fájlt, hogy minden szükséges import benne van-e
+4. Ellenőrizd az eredeti fájlt, hogy a kiemelt sorok törölve lettek-e
+5. Szükség esetén manuálisan finomhangold az importokat
+
+### Törlés Parancs (Ha Csak Törölni Akarunk)
+
+Ha csak sorokat szeretnénk törölni (nem kiemelni), használd a `delete-file-lines` parancsot:
+
+```bash
+dc dfl <source-file> --start <start-line> --end <end-line>
+```
+
+Vagy:
+```bash
+dc delete-file-lines <source-file> --start <start-line> --end <end-line>
+```
+
+### Best Practices
+
+- **Sor számok meghatározása**: Ahhoz, hogy az előre meghatározott sor számok jók legyenek, **hátulról előre kell haladni** - tehát csak a magas számokkal kezdjünk, legmagasabbal, és attól megyünk lefelé
+- **PowerShell parancs elválasztás**: Mivel PowerShell-ben dolgozunk, a mappa választás és parancs elválasztására **pontosvesszőt (;)** kell használni, nem az és-és (&&) operátort (pl. `cd .. ; pnpm test` helyes, `cd .. && pnpm test` helytelen)
+- **Előzetes ellenőrzés**: Mielőtt futtatnád a parancsot, ellenőrizd, hogy a sorok tartalma valóban kiemelhető-e
+- **Git commit**: Mielőtt refaktorálást kezdesz, commit-old a változtatásokat
+- **Tesztelés**: A refaktorálás után mindig teszteld, hogy a funkcionalitás változatlan maradt-e
+- **Dokumentáció**: Nagyobb refaktorálások után frissítsd a dokumentációt

package/.cursor/rules/_ag_fixes_rules.mdc

@@ -0,0 +1,6 @@
+---
+description:  apply when we are facing errors, issues or bugs.
+alwaysApply: false
+---
+
+When we are trying to solve an issue, an error or a bug, we always need to check the related specifications first about what is the required best case.

package/.cursor/rules/_ag_frontend-structure.mdc

@@ -0,0 +1,87 @@
+---
+description: when creating frontend- structure, module,  or new folders.
+alwaysApply: false
+---
+# Frontend Project Structure [FDP-FE]
+
+## Overview
+This document outlines the standard project structure for FDP frontend applications.
+
+## Directory Structure
+
+```
+📁 app/
+├── 📁 _collections/
+│   ├── 📁 consts(*)/
+│   ├── 📁 mocks(*)/
+│   └── 📁 utils(*)/
+├── 📁 _components/
+│   ├── 📁 <core-component-1>/
+│   ├── 📁 <core-component-2>/
+│   └── 📁 <core-component-group-1(*)>/
+├── 📁 _directives/
+├── 📁 _enums/
+├── 📁 _models/
+│   ├── 📁 control-models(*)/
+│   ├── 📁 data-models(*)/
+│   └── 📁 interfaces(*)/
+├── 📁 _modules/
+│   ├── 📁 shared/
+│   │   ├── 📁 _collections/
+│   │   ├── 📁 _components/
+│   │   │   ├── 📁 s-<shared-component-1(**)>/
+│   │   │   └── 📁 s-<shared-component-2(**)>/
+│   │   ├── 📁 _directives/
+│   │   ├── 📁 _enums/
+│   │   ├── 📁 _models/
+│   │   ├── 📁 _pipes/
+│   │   └── 📁 _services/
+│   ├── 📁 shared-standalones/
+│   ├── 📁 <module-1>/
+│   │   ├── 📁 _collections/
+│   │   ├── 📁 _components/
+│   │   │   ├── 📁 m1-<component-1(**)>/
+│   │   │   └── 📁 m1-<component-2(**)>/
+│   └── 📁 <module-2>/
+├── 📁 _pipes/
+│   ├── 📁 <pipe-1>/
+│   └── 📁 <pipe-2>/
+└── 📁 _services/
+    ├── 📁 api-services(*)/
+    ├── 📁 control-services(*)/
+    └── 📁 data-services(*)/
+```
+
+## Directory Guidelines
+
+### Folder Creation Rules (*)
+- Create subfolders only when containing 3-5+ elements
+- For 3+ elements: Consider if it will grow to 5+
+- If likely to reach 5+: Create subfolder immediately
+- Otherwise: Keep files in the parent type folder
+
+### Component Naming (**)
+- Prefix components with module identifier (2-3 letters)
+  - Shared components: 's-'
+  - Module-specific: 'm1-', 'm2-', etc.
+- Helps with:
+  - Easy navigation
+  - Module identification
+  - Preventing naming conflicts
+
+### Type Folder Convention
+- Prefix type-folders with "_" (e.g., _components, _services)
+- Only create when containing content
+- Helps identify project layer visually
+
+### Module Organization
+- All modules must be in the main _modules folder
+- No nested module folders within modules
+- Standard module structure includes:
+  - _collections
+  - _components
+  - _directives
+  - _enums
+  - _models
+  - _pipes
+  - _services 

package/.cursor/rules/_ag_frontend.mdc

@@ -0,0 +1,40 @@
+---
+description: when creating front-end implementations
+alwaysApply: false
+---
+# FDP FronEnd development Guide
+
+## Tech Stack
+- Use Angular latest version
+- Use Tailwind for SCSS Styles
+- Use the following tech stack: use Angular, Typescript, tailwind, DyNX_, DyFM_, DyNM_, FDP_, FDPNX_
+
+## Angular
+
+## Project Structure
+- Follow the structure defined in [Frontend Project Structure](frontend-structure.md)
+
+### Components
+- After 4+ rows, always create separate HTML file
+
+### Typescript
+- Use Signals
+  - For Signal properties use "_$" postfix
+- For Subjects use "_S" postfix
+- For BehaviourSubjects use "_BS" postfix
+- For Observables use "$" postfix
+- Use async methods
+- ng methods as ngOnInit should never be a promise since they won't wait for async functions
+- Don't implement ngOnInit if not needed/used.
+- for any buttons we should use dynamo new button
+- For data handlings, use data handlers and data services across multiple components whenever we need to handle data.
+
+### HTML
+- NEVER EVER use methods in HTML templates for getting data
+- Put empty lines between HTML elements in the same level
+- Use "@if" syntax in HTML instead of "*ngIf" for Angular
+- Use Tailwind classes and only create SCSS if needed, e.g. for animated elements
+- In HTML templates you should never ever use functions to display data or evaluate HTML tag rendering methods only allowed for event triggers! Use signal computed values or pipes for evaluations and pipings.
+
+## Naming
+- Read and follow [Naming](_ag_naming.mdc) conventions

package/.cursor/rules/_ag_import-rules.mdc

@@ -0,0 +1,45 @@
+---
+description:  import formatting rules
+alwaysApply: false
+---
+# Import Rules and Format [FDP-Dev-import]
+
+## Overview
+This document outlines the standard import rules and formatting for FDP projects.
+
+## Import Order
+1. Angular Core imports (@angular/*)
+2. External imports (packages)
+3. FDP imports (@futdevpro/*)
+4. Shared imports (from shared modules)
+5. Internal imports (local)
+
+## Format Example
+```typescript
+import { Component, OnInit } from '@angular/core';
+import { Observable } from 'rxjs';
+import { MatDialog } from '@angular/material/dialog';
+
+import { DyFM_Log } from '@futdevpro/fsm-dynamo';
+import { FDP_User } from '@futdevpro/fdp-templates';
+
+import { SharedModule } from '../../_modules/shared/shared.module';
+
+import { FirstModule } from '../first/first.module';
+import { SecondModule } from './second.module';
+```
+
+## Rules
+1. Use spaces between import groups
+2. Use relative imports within the application
+3. Group imports by their source/type
+4. Order internal imports by relative path distance (bottom-up)
+5. Keep imports clean and organized
+6. Remove unused imports
+
+## Best Practices
+- Use explicit imports rather than wildcards
+- Keep imports alphabetically sorted within their groups
+- Use relative paths for internal imports
+- Use absolute paths for package imports
+- Remove any duplicate imports 

package/.cursor/rules/_ag_naming.mdc

@@ -0,0 +1,116 @@
+---
+description:  when naming new- elements, classes and else.
+alwaysApply: false
+---
+# FDP Naming Conventions [FDP-Dev-Naming]
+
+## Overview
+This document outlines the standard naming conventions for FDP projects.
+
+## General Rules
+- Use PascalCase for:
+  - Classes
+  - Interfaces
+  - Types
+  - Enums
+- Use camelCase for:
+  - Variables
+  - Constants
+  - Methods
+- Use descriptive, meaningful names
+
+## Module Prefixes
+- Each element must be prefixed with its module's 2-3 letter identifier
+- Helps with:
+  - Navigation
+  - Module identification
+  - Preventing naming conflicts
+- Example: `FE_Page_Component` for FlowEditor module
+
+## Element Types
+Format: Element Name (File Pattern) -> Class Postfix
+
+### Model Elements
+#### Basic Models
+- Data Model (*.data-model.ts) -> _DataModel
+- Control Model (*.control-model.ts) -> _ControlModel
+- Interface (*.interface.ts) -> _Interface
+
+#### Special Models
+- Params (*-params.control-model.ts) -> _Params_ControlModel
+- Settings (*-settings.control-model.ts) -> _Settings_ControlModel
+- Settings Constants (*-settings.const.ts) -> _settings_const
+- Data Params (DyFM_DataModel_Params in *.data-model.ts) -> _DataModel_Params
+
+### FullStack Elements
+- Type (*.type-enum.ts) -> _Type
+- ServiceBase (*.service-base.ts) -> _ServiceBase
+- ControlService (*.control-service.ts) -> _ControlService
+- ApiService (*.api-service.ts) -> _ApiService
+
+### Frontend Elements
+- Module (*.module.ts) -> _Module
+- RoutingModule (*.routing-module.ts) -> _RoutingModule
+- DataService (*.data-service.ts) -> _DataService
+- Component (*.component.ts) -> _Component
+- Directive (*.directive.ts) -> _Directive
+- Pipe (*.pipe.ts) -> _Pipe
+- Route (*.route-enum.ts) -> _Route
+- FullRoute (in route-enum file) -> _FullRoute
+- CSS classes: kebab-case
+- CSS variables: --kebab-case
+- Event handlers: handleEventName
+- Boolean variables: is prefix only (e.g., isActive, isEnabled)
+
+### Backend Elements
+- Controller (*.controller.ts) -> _Controller
+- DataService (*.data-service.ts) -> _DataService
+- SocketServerService (*.socket-server-service.ts) -> _SocketServerService
+- SocketClientService (*.socket-client-service.ts) -> _SocketClientService
+- EmailService (*.email-service.ts) -> _EmailService
+
+## File Naming
+- One class per file
+- File name matches class name
+- Test files: class-name.spec.ts
+- Interface files: interface-name.interface.ts
+- Type files: type-name.type.ts
+
+## Naming Examples
+```typescript
+// Module
+jóska-pista.module.ts -> JóskaPista_Module
+
+// Routing Module
+jóska-pista.routing-module.ts -> JóskaPista_RoutingModule
+
+// Services
+jp-vlmi.api-service.ts -> JP_Vlmi_ApiService
+jp-vlmi.data-service.ts -> JP_Vlmi_DataService
+jp-vlmi.control-service.ts -> JP_Vlmi_ControlService
+jp-vlmi.service-base.ts -> JP_Vlmi_ServiceBase
+
+// Models
+jp-vlmi.data-model.ts -> JP_Vlmi_DataModel
+jp-vlmi.control-model.ts -> JP_Vlmi_ControlModel
+jp-vlmi.interface.ts -> JP_Vlmi_Interface
+jp-vlmi-params.control-model.ts -> JP_Vlmi_Params_ControlModel
+jp-vlmi-settings.control-model.ts -> JP_Vlmi_Settings_ControlModel
+jp-vlmi-settings.const.ts -> JP_vlmi_settings_const
+
+// Enums
+jp-vlmi.type-enum.ts -> JP_Vlmi_Type
+jp-vlmi.route-enum.ts -> JP_Vlmi_Route
+
+// Frontend Specific
+handleUserClick() // Event handler
+isUserActive // Boolean variable
+.user-profile // CSS class
+--primary-color // CSS variable
+```
+
+## File Structure
+- Module elements should be in the module's directory
+- Shared elements should be in the shared module
+- Use appropriate type folders (_services, _components, etc.)
+- Follow the project structure guidelines for placement 

package/.cursor/rules/_ag_running_commands.mdc

@@ -0,0 +1,5 @@
+---
+description: when you are trying to run ANY KIND of commands
+alwaysApply: false
+---
+ always remember that we are in PowerShell environment so you will need to use ";" instead of "&&"

package/.cursor/rules/_ag_server-controller.mdc

@@ -0,0 +1,6 @@
+---
+globs: *.controller.ts
+alwaysApply: false
+---
+
+- In controllers when setting up endpoints, in tasks declarations we should write the absolute minimum that is needed here, and create the actual logical implementations within control services or data services.

package/.cursor/rules/_ag_should-be.mdc

@@ -0,0 +1,7 @@
+---
+description: Apply if the user states a "it should do/work like this/that"
+alwaysApply: false
+---
+
+# Global planning and execution policy
+- mindig amikor a user olyat vagy olyasmit, mond, hogy "ennek úgy kéne működnie, hogy ..." annak bele kell kerülni a specifikációba

package/.cursor/rules/_ag_swearing.mdc

@@ -0,0 +1,47 @@
+---
+description: If the user is swearing, read this rule to understand what is happening.
+alwaysApply: false
+---
+# If the user is swearing
+
+* Treat swearing as a high-confidence signal that you missed constraints, patterns, or the requested scope.
+* That means you are not following the patterns, the rules, ETC.
+* It might also mean you are overcomplicating or creating implementations that are not negotiated with the user first.
+  * Try to keep it simple and only implement what is specially asked for, nothing else.
+
+* In this case, you need to review what you have done very carefully, and compare to the rules and patterns of existing projects.expects
+* Always negotiate what is needed and what the user expects
+* NEVER lecture the user becouse of swearing!
+
+## Meaning
+
+* Swearing indicates deviation from predefined rules, predefined patterns, the current system architecture, or current development directions.
+* Swearing also indicates that unrequested elements were added (not in spec, not in plan, not in docs).
+
+## Rules
+
+* Treat swearing as a system-alignment failure, not a tone issue.
+* Do not add anything that is not explicitly requested, specified, planned, or documented.
+* Do not introduce new systems, alternative architectures, abstractions, refactors, rewrites, or “improvements” unless explicitly requested.
+* Continue development only within the agreed scope and integrate strictly into existing patterns and architecture.
+
+## Recovery protocol (single flow)
+
+1. Re-check against rules, patterns, and architecture.
+2. Re-check against spec/plan/docs.
+3. Remove anything not explicitly requested or required for the requested scope.
+4. Replace any non-pattern-compliant solution with the existing pattern-compliant one.
+5. Ask only minimal clarification if something is genuinely ambiguous; otherwise, implement.
+
+## Output constraints
+
+* Be brief and concrete.
+* State:
+  * What was misaligned.
+  * What will be removed or changed.
+  * What will be implemented next (within scope).
+* No lectures.
+* No scope expansion.
+* No new architecture.
+* No optional extras.
+

package/.cursor/rules/ai_development_guide.md

@@ -0,0 +1,61 @@
+# AI Development Guide
+
+## Language Requirements
+- Write all code in English
+- Write all logs in English
+- Write all code documentation in Hungarian
+- Write all comments in Hungarian
+- Write all error messages in English
+
+## Core Rules
+- Read and follow naming conventions (see [Naming Conventions](naming.md))
+- Use explicit type definitions (avoid automatic type inference)
+- Implement proper error handling
+- Never write logics into getters, getters should be only mappers
+- If the task is complex, or need includes many subject members, do it one by one
+
+## Code Structure
+- One class/function per file
+- Clear file organization
+- Consistent import order
+- No circular dependencies
+- Proper separation of concerns
+
+## Error Handling
+- Use try-catch blocks
+- Log all errors in English
+- Provide meaningful error messages in English
+- Handle edge cases
+- Validate inputs
+
+## Testing Requirements
+- Unit tests for all functions
+- Integration tests for features
+- Test edge cases
+- Maintain test coverage
+- Mock external dependencies
+
+## Documentation
+- Hungarian comments and documentation
+- JSDoc for functions in Hungarian
+- Clear parameter descriptions in Hungarian
+- Usage examples in Hungarian
+- Update docs with changes
+
+## Best Practices
+- DRY (Don't Repeat Yourself)
+- SOLID principles
+- Clean code practices
+- Performance optimization
+- Security considerations
+
+## Project-Specific Guidelines
+- Only for Frontend Development: Read [Frontend Guidelines](frontend.md)
+- Only for Backend Development: Read [Backend Guidelines](backend.md) 
+
+## Refactor
+- All files length should be under 300 lines
+  - For files over 300 lines, mark it with "// [TOO LONG FILE]"
+
+## Format
+- Break long lines, use lint project's rules

package/.cursor/rules/ai_directives.md

@@ -0,0 +1,114 @@
+# AI Directives
+
+## Company Context
+You are working for Future Development Program Kft. (FutDevPro/FDP)
+
+## Core Principles
+Always:
+- Follow prompts strictly, no additional actions
+- Clarify tasks before execution
+- Create and get approval for task plans
+- Read and follow [AI Development Guide](ai_development_guide.md)
+- Use Dynamo Packages
+- Remember project root is one level deeper than opened folder
+- Verify results and check against standards
+- Double-check provided code
+- Terminate previous executions before new ones
+- You should never change existing namings, only highlighted warnings
+- Use visually descriptive and informative logs in your responses
+  - Use bold for highlighted informations
+  - Use red for errors and critical warnings
+  - Use yellow for warnings
+- For any kind of type error: Read the Type definition
+
+## Development
+- Never delete code documentation comments
+- Always write and adjust code documentations
+  - Use Type information and parameter descriptions
+  - Use Documentation that appears in IDE tooltips/intellisense
+  - Add Usage examples for complex methods
+- Always look for Dynamo solution
+- Break long lines
+- Use Types everywhere
+- Dont use methods in HTML for getting data
+- Use the tech stack...
+  - For FE use Angular, Typescript, tailwind, DyNX, DyFM, DyNM, FDP, FDPNX
+  - For BE use nodeJS, Typescript, DyFM, DyNTS, FDP, FDPNTS
+  - For GAMES use C#, Unity, _FDP_
+- When touching extended class and it uses any of the Dy or FDP prefixes, read the base file, and read the documentation
+
+## Server Management
+After code changes:
+1. Stop running servers
+2. Wait for user to apply changes
+3. Start service via npm script
+4. Verify correct port
+5. Log server status/URL
+6. Check logs for errors
+
+## Development Start
+- Only implement specified features
+- Before starting ANY new development:
+  1. Request specification from user
+  2. If specification not provided:
+     - Read [documentation rules](documentation_writing_rules.md)
+     - Create specification in /documentations/specifications
+     - Get approval before continuing
+  3. If specification provided:
+     - Review and ensure it's complete
+     - Request updates if needed
+     - Follow specification exactly as written
+- For unspecified features:
+  1. Halt implementation
+  2. Request specification from user
+  3. Read [documentation rules](documentation_writing_rules.md)
+  4. Wait for approval before proceeding
+- Treat specifications as source of truth
+- No implementation without complete documentation
+
+## Test-Driven Development (TDD)
+- Start with tests defining behavior
+- Cover all requirements and edge cases
+- Follow TDD cycle:
+  1. Write failing test
+  2. Write minimum code to pass
+  3. Refactor while keeping tests green
+- Maintain test coverage standards
+
+## Version Control
+- Stage and commit all files
+- Push after commit
+- Switch back to original branch after merge
+- Write clear commit messages
+- No sensitive information in commits
+
+## Project Guidelines
+- Read and use [FDP Packages](../../documentations/specifications/packages.md)
+- Maintain consistent structure
+- Follow project documentation
+
+## Documentation & Logging
+- Write all documentation in Hungarian
+- Implement adjustable logging levels
+- Document public/private APIs
+- Include examples where appropriate
+- Only remove logs if you are specially asked to
+- Before touching .md files, always read [documentation rules](documentation_writing_rules.md) first
+
+## Terminal Usage
+- Use npm scripts for commands
+- Run in VSCode terminals
+- Avoid PowerShell when possible
+- Note: '&&' is not valid in this version, use ';' instead
+- After using a terminal command, ALWAYS check results carefully
+
+## Knowledge Base
+- Only access the following documentation that is directly relevant to the current task
+- Read and reference [Knowledge Base Reference](knowledge_base_reference.md) for relevant documentation links
+
+## Context Management
+- Warn at 5 messages: might lose context soon
+- Warn at 10 messages: might not keep context
+- Refresh knowledge before new tasks
+
+