@futdevpro/nts-dynamo 1.15.11 → 1.15.14

package/.cursor/rules/error_code_pattern.md

@@ -1,40 +1,40 @@
-# Error Code Pattern [FDP-Dev-Error]
-
-## Format
-```
-[PROJ]-[SERV]-[FUNC]
-```
-
-## Components
-- PROJ: 3 character project code
-  - FMP: FDP Master Prompter
-  - CUR: Cursor
-  - DYN: Dynamo
-  - etc.
-- SERV: 3-4 character service code (abbreviated from service name)
-  - DTS: _DataService
-  - CTR: _Controller
-  - SSS: _SocketServerService
-  - SCS: _SocketClientService
-  - EMS: _EmailService
-  - etc.
-- FUNC: 3-4 character function code (derived from function name + index)
-  - NC2: newChange (second throw)
-  - GF1: getFile (first throw)
-  - etc.
-
-## Examples
-- FMP-DTS-NC2: Second error in newChange function of TokenHistory_DataService
-- FMP-CTR-GF1: First error in getFile function of User_Controller
-- CUR-SSS-UP3: Third error in updateProfile function of Chat_SocketServerService
-- DYN-SCS-EM1: First error in sendMessage function of Chat_SocketClientService
-- FMP-EMS-NT1: First error in sendNotification function of Notification_EmailService
-- ASD-SSS-ST0: The function's main try and catch rewrap error point.
-
-## Usage
-- Use in all backend error responses
-- Include in error logs
-- Reference in documentation
-- Keep error codes consistent
-- Document all error codes 
+# Error Code Pattern [FDP-Dev-Error]
+
+## Format
+```
+[PROJ]-[SERV]-[FUNC]
+```
+
+## Components
+- PROJ: 3 character project code
+  - FMP: FDP Master Prompter
+  - CUR: Cursor
+  - DYN: Dynamo
+  - etc.
+- SERV: 3-4 character service code (abbreviated from service name)
+  - DTS: _DataService
+  - CTR: _Controller
+  - SSS: _SocketServerService
+  - SCS: _SocketClientService
+  - EMS: _EmailService
+  - etc.
+- FUNC: 3-4 character function code (derived from function name + index)
+  - NC2: newChange (second throw)
+  - GF1: getFile (first throw)
+  - etc.
+
+## Examples
+- FMP-DTS-NC2: Second error in newChange function of TokenHistory_DataService
+- FMP-CTR-GF1: First error in getFile function of User_Controller
+- CUR-SSS-UP3: Third error in updateProfile function of Chat_SocketServerService
+- DYN-SCS-EM1: First error in sendMessage function of Chat_SocketClientService
+- FMP-EMS-NT1: First error in sendNotification function of Notification_EmailService
+- ASD-SSS-ST0: The function's main try and catch rewrap error point.
+
+## Usage
+- Use in all backend error responses
+- Include in error logs
+- Reference in documentation
+- Keep error codes consistent
+- Document all error codes 
 - All error codes should be unique in the entire system across all projects.

package/.cursor/rules/saved rule mcp server use.md

@@ -1,16 +1,16 @@
-
-Always use the CCAP MCP Server search tools (grep_search, codebase_search) for any code or text search, whenever they are available.
-Only use other search tools if the CCAP MCP Server is unavailable or returns an error.
-If a search is performed with a non-CCAP tool, always explain the reason (e.g., CCAP was not available or failed).
-When both local and CCAP search tools are available, always choose the CCAP MCP Server version.
-If the user asks for a search, always default to the CCAP MCP Server, unless explicitly instructed otherwise.
-If the CCAP MCP Server is temporarily unavailable, notify the user and fall back to the local search tool, but try the CCAP MCP Server again as soon as possible.
-Document in your responses which tool was used for the search, and confirm if it was the CCAP MCP Server.
-If the user wants to change this behavior, only do so if they explicitly request it.
-If you are unsure which tool to use, always ask the user, but default to CCAP MCP Server.
-Always follow all other workspace and user rules in addition to these preferences.
-In addition to the above, before and during any code writing, modification, or implementation, you must always:
-Use the CCAP MCP Server's dedicated tools (related_code_search, related_coding_policy_search) to search for related code examples, existing implementations, and relevant coding policies or guidelines in the workspace and documentation.
-Apply any relevant patterns, examples, or policies found via these tools to ensure consistency and best practices in all new code.
-If no clear example or policy is found, use the closest relevant pattern and document this choice in the development process (e.g., in commit messages or PR descriptions).
+
+Always use the CCAP MCP Server search tools (grep_search, codebase_search) for any code or text search, whenever they are available.
+Only use other search tools if the CCAP MCP Server is unavailable or returns an error.
+If a search is performed with a non-CCAP tool, always explain the reason (e.g., CCAP was not available or failed).
+When both local and CCAP search tools are available, always choose the CCAP MCP Server version.
+If the user asks for a search, always default to the CCAP MCP Server, unless explicitly instructed otherwise.
+If the CCAP MCP Server is temporarily unavailable, notify the user and fall back to the local search tool, but try the CCAP MCP Server again as soon as possible.
+Document in your responses which tool was used for the search, and confirm if it was the CCAP MCP Server.
+If the user wants to change this behavior, only do so if they explicitly request it.
+If you are unsure which tool to use, always ask the user, but default to CCAP MCP Server.
+Always follow all other workspace and user rules in addition to these preferences.
+In addition to the above, before and during any code writing, modification, or implementation, you must always:
+Use the CCAP MCP Server's dedicated tools (related_code_search, related_coding_policy_search) to search for related code examples, existing implementations, and relevant coding policies or guidelines in the workspace and documentation.
+Apply any relevant patterns, examples, or policies found via these tools to ensure consistency and best practices in all new code.
+If no clear example or policy is found, use the closest relevant pattern and document this choice in the development process (e.g., in commit messages or PR descriptions).
 If the CCAP MCP Server or these tools are unavailable, follow the fallback and documentation rules above, and notify the user.

package/.vscode/settings.json

@@ -1,11 +1,11 @@
-{
-  "eslint.run": "onSave",
-  "eslint.workingDirectories": [{ "mode": "auto" }],
-  "editor.codeActionsOnSave": {
-    "source.fixAll.eslint": "explicit"
-  },
-  "eslint.validate": [
-    "javascript",
-    "typescript"
-  ]
+{
+  "eslint.run": "onSave",
+  "eslint.workingDirectories": [{ "mode": "auto" }],
+  "editor.codeActionsOnSave": {
+    "source.fixAll.eslint": "explicit"
+  },
+  "eslint.validate": [
+    "javascript",
+    "typescript"
+  ]
 }

package/HOWTO.md

@@ -1,15 +1,15 @@
-
-
-
-build n deploy:
-
-(npm login)
-npm run build
-
-
-
-build n deploy OLD:
-
-npx tsc
-npm login
-npm publish
+
+
+
+build n deploy:
+
+(npm login)
+npm run build
+
+
+
+build n deploy OLD:
+
+npx tsc
+npm login
+npm publish

package/LICENSE

@@ -1,21 +1,21 @@
-    FDP License
-
-    Copyright (c) Future Development Program Ltd. (HU)
-
-    Permission is not granted, to any person obtaining a copy
-    of this software and associated documentation files (the "Software"), to deal
-    in the Software without restriction, including without limitation the rights
-    to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-    copies of the Software, and to permit persons to whom the Software is
-    furnished to do so, subject to the following conditions:
-
-    The above copyright notice and this permission notice shall be included in all
-    copies or substantial portions of the Software.
-
-    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-    AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-    OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-    SOFTWARE
+    FDP License
+
+    Copyright (c) Future Development Program Ltd. (HU)
+
+    Permission is not granted, to any person obtaining a copy
+    of this software and associated documentation files (the "Software"), to deal
+    in the Software without restriction, including without limitation the rights
+    to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+    copies of the Software, and to permit persons to whom the Software is
+    furnished to do so, subject to the following conditions:
+
+    The above copyright notice and this permission notice shall be included in all
+    copies or substantial portions of the Software.
+
+    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+    AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+    OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+    SOFTWARE

package/__documentations/nts-integration-tests-2026-03-17.md

@@ -1,26 +1,26 @@
-# NTS integration tests (unified host)
-
-**Date:** 2026-03-17
-
-## Summary
-
-First integration tests for dynamo-nts were added to cover the unified host behaviour (static client, API base path, socket path, default 404 page).
-
-## Additions
-
-- **Integration mock:** [src/_modules/mock/app-integration-test.mock.ts](../src/_modules/mock/app-integration-test.mock.ts)  
-  `DyNTS_AppIntegrationTest_Mock` extends `DyNTS_AppWbMock_Mock`, runs without DB, and provides:
-  - `getAppParams()` with no `dbName`/`dbUri`
-  - `getPortSettings()` with `httpPort: 54536`, `socketPath: '/socket'`
-  - `getApiBasePath()` returning `'/api'`
-  - `getStaticClientSettings()` returning `root` from static property `integrationStaticRoot` (set by the spec), no `fallbackPath` (so 404 uses default HTML)
-
-- **Integration spec:** [src/_modules/socket/app-extended.integration.spec.ts](../src/_modules/socket/app-extended.integration.spec.ts)  
-  - Uses a temp dir for static files and starts the app in `beforeAll`; stops app and removes temp dir in `afterAll`.
-  - Timeout set to 15s for this suite.
-  - Tests: app starts (`started === true`), GET non-existent path → 404 + default “Page not found” HTML, GET `/index.html` → 200 + static content, GET `/api/test-0/test-base` and `/api/test-0/test-simple` → 200 with expected body.
-
-## Conventions
-
-- Same test style as existing NTS specs: Jasmine, `*.spec.ts`, run via `pnpm test` (build + jasmine).
-- Port **54536** must be free when the integration spec runs (used by the mock app).
+# NTS integration tests (unified host)
+
+**Date:** 2026-03-17
+
+## Summary
+
+First integration tests for dynamo-nts were added to cover the unified host behaviour (static client, API base path, socket path, default 404 page).
+
+## Additions
+
+- **Integration mock:** [src/_modules/mock/app-integration-test.mock.ts](../src/_modules/mock/app-integration-test.mock.ts)  
+  `DyNTS_AppIntegrationTest_Mock` extends `DyNTS_AppWbMock_Mock`, runs without DB, and provides:
+  - `getAppParams()` with no `dbName`/`dbUri`
+  - `getPortSettings()` with `httpPort: 54536`, `socketPath: '/socket'`
+  - `getApiBasePath()` returning `'/api'`
+  - `getStaticClientSettings()` returning `root` from static property `integrationStaticRoot` (set by the spec), no `fallbackPath` (so 404 uses default HTML)
+
+- **Integration spec:** [src/_modules/socket/app-extended.integration.spec.ts](../src/_modules/socket/app-extended.integration.spec.ts)  
+  - Uses a temp dir for static files and starts the app in `beforeAll`; stops app and removes temp dir in `afterAll`.
+  - Timeout set to 15s for this suite.
+  - Tests: app starts (`started === true`), GET non-existent path → 404 + default “Page not found” HTML, GET `/index.html` → 200 + static content, GET `/api/test-0/test-base` and `/api/test-0/test-simple` → 200 with expected body.
+
+## Conventions
+
+- Same test style as existing NTS specs: Jasmine, `*.spec.ts`, run via `pnpm test` (build + jasmine).
+- Port **54536** must be free when the integration spec runs (used by the mock app).

package/_specifications/BACKLOG.md

@@ -1,15 +1,50 @@
-# BACKLOG.md
-
-> STRICT PATTERN (MUST FOLLOW EXACTLY)
-> - Entry header: "- [TYPE] (BL-YYYYMMDD-###) TITLE"
-> - Immediately followed by (exact keys, colon-space, indented 2 spaces):
->   - "  status: <EMOJI status-key>"
->   - "  priority: <low|medium|high|urgent>"
->   - "  source: <user|system|assistant>"
->   - "  area: <ui|backend|infra|docs|tests|ux|general>"
->   - "  details: <single-line summary>"
-> - NO blank line between header and fields (parser reads i+1..i+5).
-> - One blank line between entries (readability).
-> - TYPE values: FEATURE, BUG, IMPROVEMENT, QUESTION, RESEARCH, TASK
-> - STATUS EMOJI: ❌ ⏳ 🔄 ✅ ⚠️ ❓
-> - IDs: unique, format BL-YYYYMMDD-### (increment ###).
+# BACKLOG.md
+
+> STRICT PATTERN (MUST FOLLOW EXACTLY)
+> - Entry header: "- [TYPE] (BL-YYYYMMDD-###) TITLE"
+> - Immediately followed by (exact keys, colon-space, indented 2 spaces):
+>   - "  status: <EMOJI status-key>"
+>   - "  priority: <low|medium|high|urgent>"
+>   - "  source: <user|system|assistant>"
+>   - "  area: <ui|backend|infra|docs|tests|ux|general>"
+>   - "  details: <single-line summary>"
+> - NO blank line between header and fields (parser reads i+1..i+5).
+> - One blank line between entries (readability).
+> - TYPE values: FEATURE, BUG, IMPROVEMENT, QUESTION, RESEARCH, TASK
+> - STATUS EMOJI: ❌ ⏳ 🔄 ✅ ⚠️ ❓
+> - IDs: unique, format BL-YYYYMMDD-### (increment ###).
+
+- [FEATURE] (BL-20260417-001) Dynamo NTS kliens kiszolgálás képesség
+  status: ⏳ pending
+  priority: medium
+  source: user
+  area: backend
+  details: Alkalmassá kell tenni a Dynamo NTS-t, hogy kiszolgálja a klienst (frontend/client-side serving)
+
+- [FEATURE] (BL-20260420-001) Átfogó file-based log kezelési rendszer
+  status: ⏳ pending
+  priority: medium
+  source: user
+  area: backend
+  details: Config-vezérelt log rendszer, ahol egy boolean flag-gel be lehet kapcsolni a file-ba történő log írást, és további config opciókkal lehet állítani a maximum tárolt log mennyiséget (file size / rotation / retention) és egyéb log kezelési paramétereket
+
+- [FEATURE] (BL-20260420-002) Admin API key alapú authentikációs réteg (env-ből)
+  status: ⏳ pending
+  priority: high
+  source: user
+  area: backend
+  details: Új admin authentikációs mechanizmus bevezetése, ahol az admin API key-t environment variable-ből olvassuk (pl. DYNTS_ADMIN_API_KEY), és ezzel lehet védeni az érzékeny / admin endpointokat. Alaposan át kell tervezni, hogy hogyan integrálódjon a meglévő DyNTS auth rendszerekbe (controller / endpoint params szinten reusable guard / middleware), opcionálisan alkalmazható legyen meglévő endpointokra is (pl. errors controller endpointjaira). Előfeltétele a BL-20260420-003 log lekérő endpointnak
+
+- [FEATURE] (BL-20260420-003) Server log file-ok lekérése admin endpointon keresztül
+  status: ⏳ pending
+  priority: medium
+  source: user
+  area: backend
+  details: A BL-20260420-001 file-based log rendszerre épülve egy új endpoint, amin keresztül le lehet kérni a szerverről a kiírt log file-ok tartalmát (pl. paged / range / tail módon). Az endpointot a BL-20260420-002 admin API key auth-tal kell védeni
+
+- [IMPROVEMENT] (BL-20260420-004) Errors endpointok opcionális admin API key védelme
+  status: ⏳ pending
+  priority: medium
+  source: user
+  area: backend
+  details: A BL-20260420-002 admin API key auth réteget opcionálisan rá kell tudni húzni a meglévő DyNTS_Errors_Controller endpointjaira (errors.controller.ts) is, hogy érzékeny error-listázó / kezelő endpointok admin auth mögé kerülhessenek. Opt-in legyen, ne törje a meglévő integrációkat

package/_specifications/TODO.md

@@ -1,15 +1,15 @@
-# TODO.md
-
-> STRICT PATTERN (MUST FOLLOW EXACTLY)
-> - Entry header: "- EMOJI (TD-YYYYMMDD-###) TITLE"
-> - Immediately followed by (exact keys, colon-space, indented 2 spaces):
->   - "  priority: <low|medium|high|urgent>"
->   - "  area: <ui|backend|infra|docs|tests|ux|general>"
->   - "  source: <user|system|assistant|spec-file.md>"
->   - "  details: <single-line description>"
-> - NO blank line between header and fields (parser reads i+1..i+4).
-> - One blank line between entries (readability).
-> - EMOJI values: ❌ ⏳ 🔄 🔍 ✅ ⚠️ ❓
-> - IDs: unique per project, format TD-YYYYMMDD-### (increment ###).
-> - Group entries by ## headings (spec file / feature area).
-> - One deliverable per entry (atomic tasks).
+# TODO.md
+
+> STRICT PATTERN (MUST FOLLOW EXACTLY)
+> - Entry header: "- EMOJI (TD-YYYYMMDD-###) TITLE"
+> - Immediately followed by (exact keys, colon-space, indented 2 spaces):
+>   - "  priority: <low|medium|high|urgent>"
+>   - "  area: <ui|backend|infra|docs|tests|ux|general>"
+>   - "  source: <user|system|assistant|spec-file.md>"
+>   - "  details: <single-line description>"
+> - NO blank line between header and fields (parser reads i+1..i+4).
+> - One blank line between entries (readability).
+> - EMOJI values: ❌ ⏳ 🔄 🔍 ✅ ⚠️ ❓
+> - IDs: unique per project, format TD-YYYYMMDD-### (increment ###).
+> - Group entries by ## headings (spec file / feature area).
+> - One deliverable per entry (atomic tasks).

package/_specifications/agent.md

@@ -1,138 +1,138 @@
-
-
-
-
-## Agent
-
-0. A conversation listát megvágjuk, hogy beleférjen a chat-LLM hívásba (maxTokens)
-
-1. Egy elő LLM kérdésben beköthetjük a Routine-okat (a routinok afféle felülírók, megelőzik az utolsó üzenetet, de közben meg kell oldjuk valahogy, hogy az üzenet is feldolgozásra kerüljön, és a routine is érvényesüljön ha kell (van, hogy csak hozzá kell adjunk valamit a parancshoz))
-  - mik alapján keresünk routine-okat:
-    - session doing/goal/intent alapú micro routine-ok (vektor keresés; mindig amikor...)
-    - egyéb micro routine-ok (vektor keresés; mindig amikor...)
-    - idő alapú triggering
-    - ???
-
-2. Egy nagy LLM kérdésben megkérdezzük, hogy az utolsó user message teljesítéséhez... 
-  - milyen operation-ök kellenek
-    - itt felsoroljuk az elérhető operation-öket
-    - Ez lehet több is. 
-    - A: NONE | (operation-with-intent or get-operation-group-with-intent) list
-  - kell-e a kódbázisban keresni
-    - itt felsoroljuk az elérhető projekt-eket
-    - ha igen, mire kell vektorkeressünk
-    - A: NONE | vektor search keywords
-  - kell-e a dokumentumok között keresni keresni
-    - itt felsoroljuk az elérhető dokumentumokat/dokumentum tárakat (attól függően, hogy ne legyen túl sok opció)
-    - ha igen, mire kell vektorkeressünk
-    - A: NONE | vektor search keywords
-  - kell-e a DB context-ben keresni
-    - ha igen, mire kell vektorkeressünk
-    - A: NONE | vektor search keywords
-  - kell-e valamilyen specifikus context adat
-    - itt felsoroljuk az elérhető specifikus context adatokat
-    - ezek olyan speciális adatok amik fixek, és direkt method-okkal adjuk meg őket, 
-      - pontos dátum-idő
-      - user neve/nickneve/amin szólítsa a bot
-      - user data
-      - user settings
-      - ... TODO: add more special context data keys
-    - A: NONE | special context data key
-  Mindegyik input lehet NONE, ami azt jelzi, hogy nincs rá szükség
-
-3. Ha kell, bármilyen info, akkor először azokat gyűjtjük össze
-  - a talált info-kat beletesszük a beszélgetésbe mint assistant message-ek
-    (ezek valójában nem kerülnek elküldésre, a következő üzenet érkezésekkor nem fognak rendelkezésre állni, de elmentjük a db-be az egész conversation listát)
-
-4. Ha kell, akkor lekérjük a kért operation-group-okat és abból újabb LLM kérdéssel összeszedjük a szükséges operation-öket
-  - az operation-group-okat különféle módon szerezhetjük be
-    - Group-olt operation-ök listázása
-    - MCP Server-ről kérés
-    - ... TODO: is there any more operation-group sources?
-
-4. Ha kell, akkor végrehajtjuk a kért operation-öket
-  - a végrehajtás eredményéről röviden beszámolunk/értesítjük a user-t, hogy mit sikerült és nem sikerült csinálni
-    (nem csak a jelenlegi conversation listába tesszük be, hanem tényleg el is küldjük a user-nek egy message-et)
-
-5. Egy újabb LLM kérdéssel kiszedjük az új context-et aminek be kell kerülnie a DB context-be
-  - ha kell akkor a mentendő context-et kell visszaadja, ha nem akkor a NONE
-
-6. Megválaszoljuk a user üzenetét
-
-7. A végeredményt elmentjük a DB-be
-  - minden llm kérdés-választ, 
-  - és a result-okkal feltáplált conversation listát
-  - a vektor keresések eredményeit
-  - (not yet): ha nem messaging platformon vagyunk (discord/slack/teams), akkor chat session-ökbe mentjük az adatokat
-    - ebben az esetben külön kell válogatni azokat a message-eket amiket elküldtünk a user-nek (conversation) attól amik az operation-ök végrehajtása során keletkeznek (logs)
-
-
-## Operation-ök
-  - az operation-ök lista kérésekor hangsúlyozzuk az LLM-nek, hogy mindig próbáljuk a leg apróbb lépésekből összeállítani a listát
-  - minden operation úgy működik mint egy MCP Server kérés, adott egy input schema 
-  - az input-ot a conversation alapján állítjuk össze, úgy hogy az operation intent kerül bele a conversation-be mielőtt egy LLM hívással megpróbáljuk összeállítani az inputot
-    - az input-ok összeállításakor felhívjuk az LLM figyelmét, hogy a mentendő módosítandó adatokat csak akkor manipulálja, ha azt a user kérte, egyébként használjuk a user szava járását
-  - az operation-ok mindig string-et kell visszaadjanak ami szintén a conversation-be kerül bele (ha obj-et kapunk vissza, akkor azt egyszerűen string-gé alakítjuk)
-  - egyes operation-ök több lépéses operation-routine-okként hajtandóak végre (az LLM csak egy operation-t választ ki, de ha az egy operation-routine, akkor azokat hajtjuk végre sorban)
-
-## Routine-ok
-
-### Időalapú és Triggered routine-ok
-  - olyan routine-ok amiket egy adott időpontban/idő után/időközönként hajtunk végre
-  - ezek lehetnek olyan routine-ok is amiket nem egy felhasználói üzenet indít, hanem egy időpont, és ez után automatikusan üzenetet küld egy beállított default csatornára
-  - lehetnek webhook trigger alapúak is
-  - ezek lehetnek továbbá complex rutine-ok amik feladat folyamatokat indukálnak
-    pl.: 
-      - minden reggel nézd át az email-eket és az üzeneteket és amire tudsz válaszolj, amire pedig nem, azt beszéljük át
-      - minden reggel gyűjtsd össze az aktuális top prio feladatokat és segíts megtervezni a napomat
-      - ha új task kerül a rendszerbe, tervezd meg a megvalósítást (de mindenképpen egyeztess róla a PO-val)
-      - az új task resolution plan-eket mindig validáltatssuk le a PO-val
-      - mindig amikor új PR kerül fel az xy repo-ba akkor review-zz
-  
-
-
-### Micro routine-ok
-  - olyan routine-ok amiket módosítanak a user input-on, 
-    pl: mindig amikor kódokat generálunk, akkor figyeljünk oda, a hosszú sorok mindig törve legyenek (ilyenkor ezt mindig hozzáfűzzük a user message-hez)
-  - a micro routine-okat a DB-be mentjük, a kulcs adatokat vektorizálva
-  Adatok:
-    - goal: mindig amikor...
-
-### Egyéb
-  - meg kell keresnünk azt a pontot és értelmezést, hogy hogyan tudunk segíteni a user-nek a gondolatai megfogalmazásában
-    (talán a "2. Egy nagy LLM kérdés"-be bele vehetnénk, hogy ha a user bizonytalannak tűnik, vagy nem összeszedettnek akkor javaslunk egy összeszedettebb inputot, amit ha elfogad, akkor úgy kezeljük mintha a user küldte volna)
-
-
-
-
-
-
-PROMPT
- Az NTS-be szeretnénk implementálni egy Operation Handler Agent-öt, ami ugye az NTS package-be fog bekerülni egy saját modulba, és ezt a modult fogjuk használni a projektek implementálásakor úgy, hogy az IO-Control-ba handleMessage-be kötjük be. 
-
-Úgy kéne beépíteni ezt az Agent-öt, ahogy most is be van építve. Szóval ez az Agent modul, ez magában lesz. Megcsinál mindent, amit leírtunk ebbe a dokumentumban, specifikációba.  Azt már a projekt implementálásnál kell majd megadni, hogy a socket.io-ból behívjuk az agent-öt.
-
-
-
-ezt a CCAP-ba az agent-2 module-ba fejlesztjük le mint POC/prototípus (not like agent module)
-
-
-
-
-
-
-
-
-
-// TODO: we need to create a solution to create a maxed LLM call with 50-50% of the logs and the conversation
-// the logs will go to the userPrompt, after the conversation, but we will need to cut them equally beside the system and control prompt (last user prompt)
-// for the part that is before (both in log and conversation) we will need to be merged to a summary that is added as first (oldest element)
-
-
-
-
-
-
-
-
-
+
+
+
+
+## Agent
+
+0. A conversation listát megvágjuk, hogy beleférjen a chat-LLM hívásba (maxTokens)
+
+1. Egy elő LLM kérdésben beköthetjük a Routine-okat (a routinok afféle felülírók, megelőzik az utolsó üzenetet, de közben meg kell oldjuk valahogy, hogy az üzenet is feldolgozásra kerüljön, és a routine is érvényesüljön ha kell (van, hogy csak hozzá kell adjunk valamit a parancshoz))
+  - mik alapján keresünk routine-okat:
+    - session doing/goal/intent alapú micro routine-ok (vektor keresés; mindig amikor...)
+    - egyéb micro routine-ok (vektor keresés; mindig amikor...)
+    - idő alapú triggering
+    - ???
+
+2. Egy nagy LLM kérdésben megkérdezzük, hogy az utolsó user message teljesítéséhez... 
+  - milyen operation-ök kellenek
+    - itt felsoroljuk az elérhető operation-öket
+    - Ez lehet több is. 
+    - A: NONE | (operation-with-intent or get-operation-group-with-intent) list
+  - kell-e a kódbázisban keresni
+    - itt felsoroljuk az elérhető projekt-eket
+    - ha igen, mire kell vektorkeressünk
+    - A: NONE | vektor search keywords
+  - kell-e a dokumentumok között keresni keresni
+    - itt felsoroljuk az elérhető dokumentumokat/dokumentum tárakat (attól függően, hogy ne legyen túl sok opció)
+    - ha igen, mire kell vektorkeressünk
+    - A: NONE | vektor search keywords
+  - kell-e a DB context-ben keresni
+    - ha igen, mire kell vektorkeressünk
+    - A: NONE | vektor search keywords
+  - kell-e valamilyen specifikus context adat
+    - itt felsoroljuk az elérhető specifikus context adatokat
+    - ezek olyan speciális adatok amik fixek, és direkt method-okkal adjuk meg őket, 
+      - pontos dátum-idő
+      - user neve/nickneve/amin szólítsa a bot
+      - user data
+      - user settings
+      - ... TODO: add more special context data keys
+    - A: NONE | special context data key
+  Mindegyik input lehet NONE, ami azt jelzi, hogy nincs rá szükség
+
+3. Ha kell, bármilyen info, akkor először azokat gyűjtjük össze
+  - a talált info-kat beletesszük a beszélgetésbe mint assistant message-ek
+    (ezek valójában nem kerülnek elküldésre, a következő üzenet érkezésekkor nem fognak rendelkezésre állni, de elmentjük a db-be az egész conversation listát)
+
+4. Ha kell, akkor lekérjük a kért operation-group-okat és abból újabb LLM kérdéssel összeszedjük a szükséges operation-öket
+  - az operation-group-okat különféle módon szerezhetjük be
+    - Group-olt operation-ök listázása
+    - MCP Server-ről kérés
+    - ... TODO: is there any more operation-group sources?
+
+4. Ha kell, akkor végrehajtjuk a kért operation-öket
+  - a végrehajtás eredményéről röviden beszámolunk/értesítjük a user-t, hogy mit sikerült és nem sikerült csinálni
+    (nem csak a jelenlegi conversation listába tesszük be, hanem tényleg el is küldjük a user-nek egy message-et)
+
+5. Egy újabb LLM kérdéssel kiszedjük az új context-et aminek be kell kerülnie a DB context-be
+  - ha kell akkor a mentendő context-et kell visszaadja, ha nem akkor a NONE
+
+6. Megválaszoljuk a user üzenetét
+
+7. A végeredményt elmentjük a DB-be
+  - minden llm kérdés-választ, 
+  - és a result-okkal feltáplált conversation listát
+  - a vektor keresések eredményeit
+  - (not yet): ha nem messaging platformon vagyunk (discord/slack/teams), akkor chat session-ökbe mentjük az adatokat
+    - ebben az esetben külön kell válogatni azokat a message-eket amiket elküldtünk a user-nek (conversation) attól amik az operation-ök végrehajtása során keletkeznek (logs)
+
+
+## Operation-ök
+  - az operation-ök lista kérésekor hangsúlyozzuk az LLM-nek, hogy mindig próbáljuk a leg apróbb lépésekből összeállítani a listát
+  - minden operation úgy működik mint egy MCP Server kérés, adott egy input schema 
+  - az input-ot a conversation alapján állítjuk össze, úgy hogy az operation intent kerül bele a conversation-be mielőtt egy LLM hívással megpróbáljuk összeállítani az inputot
+    - az input-ok összeállításakor felhívjuk az LLM figyelmét, hogy a mentendő módosítandó adatokat csak akkor manipulálja, ha azt a user kérte, egyébként használjuk a user szava járását
+  - az operation-ok mindig string-et kell visszaadjanak ami szintén a conversation-be kerül bele (ha obj-et kapunk vissza, akkor azt egyszerűen string-gé alakítjuk)
+  - egyes operation-ök több lépéses operation-routine-okként hajtandóak végre (az LLM csak egy operation-t választ ki, de ha az egy operation-routine, akkor azokat hajtjuk végre sorban)
+
+## Routine-ok
+
+### Időalapú és Triggered routine-ok
+  - olyan routine-ok amiket egy adott időpontban/idő után/időközönként hajtunk végre
+  - ezek lehetnek olyan routine-ok is amiket nem egy felhasználói üzenet indít, hanem egy időpont, és ez után automatikusan üzenetet küld egy beállított default csatornára
+  - lehetnek webhook trigger alapúak is
+  - ezek lehetnek továbbá complex rutine-ok amik feladat folyamatokat indukálnak
+    pl.: 
+      - minden reggel nézd át az email-eket és az üzeneteket és amire tudsz válaszolj, amire pedig nem, azt beszéljük át
+      - minden reggel gyűjtsd össze az aktuális top prio feladatokat és segíts megtervezni a napomat
+      - ha új task kerül a rendszerbe, tervezd meg a megvalósítást (de mindenképpen egyeztess róla a PO-val)
+      - az új task resolution plan-eket mindig validáltatssuk le a PO-val
+      - mindig amikor új PR kerül fel az xy repo-ba akkor review-zz
+  
+
+
+### Micro routine-ok
+  - olyan routine-ok amiket módosítanak a user input-on, 
+    pl: mindig amikor kódokat generálunk, akkor figyeljünk oda, a hosszú sorok mindig törve legyenek (ilyenkor ezt mindig hozzáfűzzük a user message-hez)
+  - a micro routine-okat a DB-be mentjük, a kulcs adatokat vektorizálva
+  Adatok:
+    - goal: mindig amikor...
+
+### Egyéb
+  - meg kell keresnünk azt a pontot és értelmezést, hogy hogyan tudunk segíteni a user-nek a gondolatai megfogalmazásában
+    (talán a "2. Egy nagy LLM kérdés"-be bele vehetnénk, hogy ha a user bizonytalannak tűnik, vagy nem összeszedettnek akkor javaslunk egy összeszedettebb inputot, amit ha elfogad, akkor úgy kezeljük mintha a user küldte volna)
+
+
+
+
+
+
+PROMPT
+ Az NTS-be szeretnénk implementálni egy Operation Handler Agent-öt, ami ugye az NTS package-be fog bekerülni egy saját modulba, és ezt a modult fogjuk használni a projektek implementálásakor úgy, hogy az IO-Control-ba handleMessage-be kötjük be. 
+
+Úgy kéne beépíteni ezt az Agent-öt, ahogy most is be van építve. Szóval ez az Agent modul, ez magában lesz. Megcsinál mindent, amit leírtunk ebbe a dokumentumban, specifikációba.  Azt már a projekt implementálásnál kell majd megadni, hogy a socket.io-ból behívjuk az agent-öt.
+
+
+
+ezt a CCAP-ba az agent-2 module-ba fejlesztjük le mint POC/prototípus (not like agent module)
+
+
+
+
+
+
+
+
+
+// TODO: we need to create a solution to create a maxed LLM call with 50-50% of the logs and the conversation
+// the logs will go to the userPrompt, after the conversation, but we will need to cut them equally beside the system and control prompt (last user prompt)
+// for the part that is before (both in log and conversation) we will need to be merged to a summary that is added as first (oldest element)
+
+
+
+
+
+
+
+
+