@futdevpro/nts-dynamo 1.15.56 → 1.15.58

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)
+
+
+
+
+
+
+
+
+

package/build/_modules/ai/_modules/document-ai/_collections/dai-code-chunking.util.d.ts

@@ -0,0 +1,110 @@
+import { DyNTS_DAI_CodeChunk } from '../_models/interfaces/dai-code-chunk.interface';
+/** A kód-chunker méret-paraméterei (a FAM/CCAP konstansokkal egyező default-ok). */
+export interface DyNTS_DAI_CodeChunking_Options {
+    /** Max chunk-méret karakterben (e fölött sliding-window sub-split). Default: 1500. */
+    maxChunkSize?: number;
+    /** Overlap karakterben a nagy-node sliding-window-ban. Default: 100. */
+    overlap?: number;
+    /** Minimum chunk-méret (ennél kisebb chunk-ot eldobunk a zaj ellen). Default: 50. */
+    minChunkSize?: number;
+}
+/**
+ * `DyNTS_DAI_CodeChunking_Util` (BFR-AM-005) — **AST-pontos** TypeScript/JavaScript kód-chunker
+ * a TypeScript Compiler API-val (`ts.createSourceFile`). A FAM `FAM_TsChunker_Util` regex/brace-depth
+ * workaround-jának **bedrock-szintű, durable** változata: a `{`/`}` számolás helyett a valódi
+ * szintaxisfát járja be, így string-literálban / template-literálban / comment-ben lévő zárójelek
+ * NEM tévesztik meg.
+ *
+ * **Chunkolási stratégia (top-level node-onként, egy chunk per szemantikus egység):**
+ * - **import-group** — az összes egymást követő top-level `import` / `export ... from` egy chunkba
+ *   (a köztük lévő üres sorokkal együtt).
+ * - **class** — ha belefér a `maxChunkSize`-ba, az egész osztály egy chunk (dekorátorok + JSDoc-cal);
+ *   ha NEM fér bele, **metódusonként** bomlik (osztály-fej + minden metódus külön chunk, a
+ *   `class:Foo > method:bar` symbol-lánccal).
+ * - **interface / enum / type-alias / standalone function / top-level const(=>fn/value)** — egy chunk
+ *   per deklaráció.
+ * - **nagy node** (a fentiek közül bármelyik, ami a metódus-bontás UTÁN is `maxChunkSize` fölötti) →
+ *   karakter-alapú **sliding-window** sub-split (örökölt `chunkType` + symbol-lánc, `subChunkIndex`-szel).
+ * - **tiny / parse-degenerált tartalom** → egyetlen `fallback` chunk (a teljes forrás), hogy soha
+ *   ne vesszen el tartalom.
+ *
+ * A JSDoc + `@Decorator` MINDIG a következő node-dal együtt marad (a `node.getStart(sf, true)` a
+ * leading-JSDoc elejétől indul, a `ts.getDecorators` a node része).
+ *
+ * **headingPath = kód-symbol-lánc** (a markdown-chunker heading-láncának kód-megfelelője):
+ * `symbolPath` = a szegmensek ` > `-rel összefűzve.
+ */
+export declare class DyNTS_DAI_CodeChunking_Util {
+    /** A FAM/CCAP-egyeztetett default méret-konstansok. */
+    private static readonly DEFAULT_MAX_CHUNK_SIZE;
+    private static readonly DEFAULT_OVERLAP;
+    private static readonly DEFAULT_MIN_CHUNK_SIZE;
+    /**
+     * Egy TS/JS forrás chunkolása szemantikus blokkok mentén a TS Compiler API AST-jával.
+     * Üres / whitespace-only tartalom → üres lista. A `maxChunkSize` fölötti node-ok sliding-window-ra
+     * bomlanak; a degenerált (parse-hiba / 0 blokk) esetet egyetlen `fallback` chunk fedi.
+     *
+     * @param code - A forráskód.
+     * @param opts - Méret-paraméterek (default 1500/100/50).
+     * @returns A szemantikus kód-chunkok listája (0-alapú `chunkIndex`-szel).
+     */
+    static chunkTs(code: string, opts?: DyNTS_DAI_CodeChunking_Options): DyNTS_DAI_CodeChunk[];
+    /**
+     * Dispatcher: a `filename` kiterjesztése alapján a `.ts/.tsx/.js/.jsx/.mts/.cts/.mjs/.cjs`
+     * forrásokat az AST-chunkerre (`chunkTs`), minden mást (pl. `.md`) az adott formátum nyers
+     * sliding-fallback-jére irányít. A markdown-specifikus chunkolás a `DyNTS_DAI_DocChunking_Util`
+     * felelőssége (page-modell + parent-hierarchia kell hozzá), ezért azt itt NEM hívjuk —
+     * additív marad. Nem-kód input → `fallback` chunk a tartalom megőrzéséhez.
+     *
+     * @param content - A fájl tartalma.
+     * @param filename - A fájlnév (a kiterjesztés-alapú routinghoz).
+     * @param opts - Méret-paraméterek.
+     */
+    static chunk(content: string, filename: string, opts?: DyNTS_DAI_CodeChunking_Options): DyNTS_DAI_CodeChunk[];
+    /** `true`, ha a fájlnév TS/JS-szerű (a `chunkTs` AST-parsere tudja kezelni). */
+    private static isTsLike;
+    /** A default-ok feloldása (1500/100/50) + sanity-clamp. */
+    private static resolveSizing;
+    /**
+     * AST-bejárás: a `SourceFile` top-level statement-jeit szemantikus blokkokká alakítja. Az
+     * egymást követő import-okat egy `imports` blokkba vonja össze. A `maxChunkSize` fölötti
+     * osztályt metódusonként bontja.
+     */
+    private static identifyBlocks;
+    /** `true`, ha a statement import / re-export (`export ... from`) — az import-csoporthoz. */
+    private static isImportLike;
+    /** Egy top-level statement → szemantikus chunk-típus + symbol-név. */
+    private static detectDeclaration;
+    /**
+     * Nagy osztály metódusonkénti bontása. Az első chunk az osztály-fej (a class-kulcsszótól az első
+     * tag előttig, dekorátorok + JSDoc-cal), majd minden metódus / property-deklaráció külön chunk a
+     * `class:Foo > method:bar` symbol-lánccal.
+     */
+    private static splitClassByMethods;
+    /** Egy osztály-tag → chunk-típus (metódus/accessor → 'method', mező → 'variable'). */
+    private static classMemberKind;
+    /** Egy belső blokk → `DyNTS_DAI_CodeChunk` (pozíció + symbol-lánc kiszámolásával). */
+    private static blockToChunk;
+    /**
+     * Túl nagy blokk karakter-alapú sliding-window sub-splitje (örökölt chunkType + symbol-lánc).
+     * Az átfedés (`overlap`) karakter-szinten, a `minChunkSize` alatti farok-chunkokat kihagyja.
+     */
+    private static splitLargeBlock;
+    /**
+     * Tiny / degenerált fallback: a teljes tartalmat egy (vagy nagy bemenetnél sliding) chunkba teszi.
+     * Soha nem ad vissza üres listát nem-üres bemenetre — a tartalom megőrzése a cél.
+     */
+    private static buildFallbackChunks;
+    /**
+     * A forrás minden sorának kezdő karakter-offszetje (0-alapú). A `lineStartOffsets[i]` az `i`-edik
+     * (0-alapú) sor első karakterének abszolút pozíciója — bináris kereséssel gyors `offset → sor`
+     * konverziót ad a chunkokhoz.
+     */
+    private static computeLineStartOffsets;
+    /**
+     * Egy abszolút karakter-offszet → 1-alapú sorszám a forrásban (bináris keresés a
+     * `lineStartOffsets`-ben). A sor-mezők így a forrás VALÓDI soraira mutatnak (nem chunk-relatív).
+     */
+    private static lineOfOffset;
+}
+//# sourceMappingURL=dai-code-chunking.util.d.ts.map

package/build/_modules/ai/_modules/document-ai/_collections/dai-code-chunking.util.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"dai-code-chunking.util.d.ts","sourceRoot":"","sources":["../../../../../../src/_modules/ai/_modules/document-ai/_collections/dai-code-chunking.util.ts"],"names":[],"mappings":"AAEA,OAAO,EAAE,mBAAmB,EAA2B,MAAM,gDAAgD,CAAC;AAE9G,oFAAoF;AACpF,MAAM,WAAW,8BAA8B;IAC7C,sFAAsF;IACtF,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,wEAAwE;IACxE,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,qFAAqF;IACrF,YAAY,CAAC,EAAE,MAAM,CAAC;CACvB;AA2BD;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AACH,qBAAa,2BAA2B;IAEtC,uDAAuD;IACvD,OAAO,CAAC,MAAM,CAAC,QAAQ,CAAC,sBAAsB,CAAgB;IAC9D,OAAO,CAAC,MAAM,CAAC,QAAQ,CAAC,eAAe,CAAe;IACtD,OAAO,CAAC,MAAM,CAAC,QAAQ,CAAC,sBAAsB,CAAc;IAE5D;;;;;;;;OAQG;IACH,MAAM,CAAC,OAAO,CAAC,IAAI,EAAE,MAAM,EAAE,IAAI,CAAC,EAAE,8BAA8B,GAAG,mBAAmB,EAAE;IA8D1F;;;;;;;;;;OAUG;IACH,MAAM,CAAC,KAAK,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,EAAE,IAAI,CAAC,EAAE,8BAA8B,GAAG,mBAAmB,EAAE;IAY7G,gFAAgF;IAChF,OAAO,CAAC,MAAM,CAAC,QAAQ;IAIvB,2DAA2D;IAC3D,OAAO,CAAC,MAAM,CAAC,aAAa;IAO5B;;;;OAIG;IACH,OAAO,CAAC,MAAM,CAAC,cAAc;IAuE7B,4FAA4F;IAC5F,OAAO,CAAC,MAAM,CAAC,YAAY;IAW3B,sEAAsE;IACtE,OAAO,CAAC,MAAM,CAAC,iBAAiB;IA8BhC;;;;OAIG;IACH,OAAO,CAAC,MAAM,CAAC,mBAAmB;IAwDlC,sFAAsF;IACtF,OAAO,CAAC,MAAM,CAAC,eAAe;IAY9B,sFAAsF;IACtF,OAAO,CAAC,MAAM,CAAC,YAAY;IAqB3B;;;OAGG;IACH,OAAO,CAAC,MAAM,CAAC,eAAe;IA8C9B;;;OAGG;IACH,OAAO,CAAC,MAAM,CAAC,mBAAmB;IAuClC;;;;OAIG;IACH,OAAO,CAAC,MAAM,CAAC,uBAAuB;IAUtC;;;OAGG;IACH,OAAO,CAAC,MAAM,CAAC,YAAY;CAa5B"}