OmniRoute/docs/i18n/mr/docs/compression/RTK_COMPRESSION.md

RTK Compression (मराठी)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇬🇪 ka · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 pa · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

---

RTK कॉम्प्रेशन हे टर्मिनल आणि टूल आउटपुटसाठी OmniRoute चे कमांड-जागरूक कॉम्प्रेशन इंजिन आहे. हे अशा कोडिंग-एजंट सत्रांसाठी डिझाइन केलेले आहे, ज्यामध्ये संदर्भाची बहुतांश वाढ चाचणी लॉग, बिल्ड आउटपुट, पॅकेज मॅनेजरमधील अनावश्यक मजकूर, शेल ट्रान्सक्रिप्ट, Docker आउटपुट, git आउटपुट आणि स्टॅक ट्रेसमधून होते.

RTK थेट defaultMode: "rtk" सह किंवा स्टॅक केलेल्या पाइपलाइनमधील पहिली पायरी म्हणून चालू शकते, सामान्यतः:

rtk -> caveman

हा क्रम प्रथम गोंगाटयुक्त मशीन आउटपुट कॉम्प्रेस करतो आणि त्यानंतर उर्वरित मजकूर संक्षिप्त करण्याचे काम Caveman ला करू देतो.

अपस्ट्रीम RTK नुसार कमांड आउटपुटमध्ये 60-90% बचत होते. त्याच्या README मधील नमुना सत्र ~118,000 मानक टोकन्सवरून ~23,900 RTK टोकन्सपर्यंत कमी होते, म्हणजे 79.7% बचत (~80%). Caveman इनपुट कॉम्प्रेशनसह स्टॅक केलेल्या बचतीची गणना करण्यासाठी OmniRoute ही अपस्ट्रीम सरासरी वापरते:

RTK सरासरी:    80% बचत
Caveman इनपुट: 46% बचत
स्टॅक केलेले:   1 - (1 - 0.80) * (1 - 0.46) = 89.2% बचत
श्रेणी:         1 - (1 - 0.60..0.90) * (1 - 0.46) = 78.4-94.6%

ते काय कॉम्प्रेस करते

अंगभूत कॅटलॉगमध्ये सध्या या श्रेणींमधील 49 फिल्टर्स समाविष्ट आहेत:

श्रेणी	उदाहरणे
git	git status, git branch, git diff, git log
test	Vitest, Jest, Pytest, Playwright, Go चाचण्या, Cargo चाचण्या
build	TypeScript, ESLint, Biome, Prettier, Vite, Webpack, Turbo, Nx
package	npm install, npm audit, pip, uv sync, Poetry, Bundler
shell	ls, find, grep, सर्वसाधारण शेल लॉग
docker	docker ps, Docker लॉग
infra	Terraform, OpenTofu, systemctl status
generic	JSON आउटपुट, स्टॅक ट्रेस, सर्वसाधारण आउटपुट फॉलबॅक

open-sse/services/compression/engines/rtk/commandDetector.ts मधील डिटेक्टर फिल्टर निवडीपूर्वी आउटपुटचे वर्गीकरण करतो. एखादा कमांड वर्ग पुरेसा नसल्यास फिल्टर्स कमांड पॅटर्न किंवा आउटपुट रेगेक्सनुसारही जुळू शकतात.

फिल्टर रिझोल्यूशन

RTK या क्रमाने फिल्टर्स लोड करते:

1. .rtk/filters.toml आणि .rtk/filters.json मधील प्रकल्प फिल्टर्स, फक्त ते विश्वसनीय असल्यास.
2. DATA_DIR/rtk/filters.toml आणि DATA_DIR/rtk/filters.json मधील ग्लोबल फिल्टर्स.
3. open-sse/services/compression/engines/rtk/filters/ मधील अंगभूत फिल्टर्स.

एकाच व्याप्तीमध्ये, RTK TOML स्कीमा v1 फिल्टर्सना OmniRoute JSON फिल्टर्सपेक्षा प्राधान्य दिले जाते. आयात केलेला कमांड-विशिष्ट फिल्टर त्या व्याप्तीतील अधिक व्यापक फिल्टरला अधिलिखित करू शकेल यासाठी TOML match_command एक्स्प्रेशन्स कमांड-प्रकार जुळणीपूर्वी तपासली जातात. फाइल स्वरूप काहीही असले, प्रकल्प व्याप्तीला तरीही ग्लोबल व्याप्तीपेक्षा प्राधान्य दिले जाते.

प्रकल्प फिल्टर्सना जाणीवपूर्वक विश्वास-आधारित मर्यादा लागू केली आहे, कारण रेगेक्स फिल्टर्स एजंटना टूल आउटपुट कसे दाखवले जाते ते बदलू शकतात. खालीलपैकी एक अट सत्य असल्यास प्रकल्प फिल्टर फाइल स्वीकारली जाते:

• rtkConfig.trustProjectFilters हे true आहे.
• OMNIROUTE_RTK_TRUST_PROJECT_FILTERS=1 सेट केलेले आहे.
• .rtk/trust.json मध्ये प्रकल्प फिल्टर फाइलसाठी जुळणारा SHA-256 हॅश आहे.

विश्वास फाइलचे उदाहरण:

{
  "filtersSha256": "0123456789abcdef...",
  "filtersTomlSha256": "fedcba9876543210..."
}

हॅश स्वतंत्र आहेत: filtersSha256 हे .rtk/filters.json वर विश्वास ठेवते, तर filtersTomlSha256 हे .rtk/filters.toml वर विश्वास ठेवते. कोणतीही फाइल संपादित केल्यास केवळ तिची स्वतःची विश्वास नोंद अवैध होते. ग्लोबल फाइल्स प्रशासकाद्वारे स्थापित केल्या जातात आणि विद्यमान ग्लोबल-फिल्टर विश्वास वर्तन वापरतात.

सानुकूल फिल्टर्स एक फिल्टर ऑब्जेक्ट किंवा फिल्टर ऑब्जेक्ट्सची अॅरे असू शकतात. अवैध सानुकूल फिल्टर्स वगळले जातात आणि /api/context/rtk/filters डायग्नोस्टिक्सद्वारे नोंदवले जातात. अवैध अंगभूत फिल्टर्समुळे प्रक्रिया त्वरित अयशस्वी होते.

RTK TOML स्कीमा v1 सुसंगतता

OmniRoute हे RTK TOML स्कीमा v1 वापरणाऱ्या घोषणात्मक फिल्टर फाइल्सचे पार्सिंग, प्रमाणीकरण, परीक्षण आणि इन्स्टॉलेशन करू शकते. समर्थित फील्ड्समध्ये description, match_command, strip_ansi, filter_stderr, strip_lines_matching, keep_lines_matching, replace, match_output, truncate_lines_at, head_lines, tail_lines, max_lines, on_empty, आणि [[tests.<filter>]] इनलाइन चाचण्यांचा समावेश होतो. अज्ञात फील्ड्स, अवैध किंवा असुरक्षित रेग्युलर एक्स्प्रेशन्स, एकाच वेळी वापरलेले strip/keep नियम, 1 MiB पेक्षा मोठ्या फाइल्स आणि अज्ञात फिल्टर्सचे संदर्भ नाकारले जातात. ज्या फाइलच्या इनलाइन चाचण्या अयशस्वी होतात, तिचे निरीक्षणासाठी प्रमाणीकरण करता येते; परंतु ती इन्स्टॉल किंवा लोड करता येत नाही. सानुकूल फाइल लोड करण्यात आलेले अपयश fail-open राहते: अवैध फाइल वगळली जाते आणि उर्वरित फिल्टर्स कार्यरत राहतात.

क्लायंटने टूलचे आउटपुट आधीच कॅप्चर केल्यानंतर OmniRoute ला ते मिळते, त्यामुळे filter_stderr = true हे प्रोसेस कॅप्चर बदलू शकत नाही. हे फील्ड no-op म्हणून स्वीकारले जाते आणि प्रमाणीकरणादरम्यान इशारा दिला जातो. याचे वर्णन हेतुपूर्वक RTK TOML स्कीमा v1 सुसंगतता असे केले आहे; RTK एक्झिक्युटेबल, shell hooks, Rust कमांड अंमलबजावणी किंवा त्याच्या trust-store मांडणीशी पूर्ण सुसंगतता असे नाही.

डॅशबोर्डचे प्रगत RTK दृश्य पेस्ट केलेले किंवा अपलोड केलेले TOML स्वीकारते. प्रमाणीकरण केवळ-वाचन स्वरूपाचे आहे. इन्स्टॉलेशन DATA_DIR/rtk/filters.toml ही फाइल प्रतिबंधात्मक परवानग्यांसह अणुरूप पद्धतीने लिहिते आणि रीस्टार्ट न करता सक्रिय फिल्टर कॅटलॉग रीफ्रेश करते. अस्तित्वात असलेली फाइल बदलण्यासाठी स्पष्ट overwrite पुष्टीकरण आवश्यक असते आणि त्यापूर्वी DATA_DIR/rtk/filters.toml.bak तयार केली जाते.

फिल्टर DSL

फिल्टर्स Compression Rules Format मध्ये वर्णन केलेली JSON स्कीमा वापरतात. रनटाइम हे टप्पे पुढील क्रमाने लागू करते:

stripAnsi -> filterStderr -> replace -> matchOutput -> ओळी वगळणे/समाविष्ट करणे
  -> truncateLineAt -> head/tail/maxLines -> onEmpty

महत्त्वाची फील्ड्स:

फील्ड	उद्देश
rules.stripAnsi	जुळवणीपूर्वी टर्मिनल रंग/नियंत्रण अनुक्रम काढून टाकणे
rules.filterStderr	जुळवणी/फिल्टरिंगपूर्वी सामान्य stderr उपसर्ग प्रमाणित करणे
rules.replace	क्रमवार regex प्रतिस्थापने लागू करणे
rules.matchOutput	आउटपुट ज्ञात स्थितीशी जुळल्यास संक्षिप्त सारांश परत करणे
rules.matchOutput[].unless	त्रुटी/अपयश नमुना उपस्थित असल्यास शॉर्टकट वगळणे
rules.dropPatterns	अनावश्यक गोंगाट करणाऱ्या ओळी काढून टाकणे
rules.includePatterns	कृती करण्यायोग्य ओळींना प्राधान्य देणे
rules.collapsePatterns	वारंवार येणाऱ्या जुळणाऱ्या ओळी संक्षिप्त करणे
rules.deduplicate	प्रत्येक फिल्टरसाठी पर्यायी निवड: सलग पुनरावृत्त ओळी संक्षिप्त करणे
rules.truncateLineAt	प्रत्येक ओळीचे Unicode-सुरक्षित संक्षिप्तीकरण
rules.onEmpty	सर्व ओळी फिल्टर झाल्यास पर्यायी संदेश
tests[]	पडताळणी गेटद्वारे वापरले जाणारे इनलाइन नमुने

अंगभूत फिल्टर्समध्ये इनलाइन tests[] नमुने असणे अपेक्षित आहे. सानुकूल फिल्टर्समध्येही ते समाविष्ट करावेत, विशेषतः ते विविध प्रकल्पांमध्ये सामायिक केले जात असतील तेव्हा.

ओळींचे डुप्लिकेशन काढणे (दोन स्तर)

RTK दोन स्वतंत्र स्तरांवर डुप्लिकेट ओळी एकत्र करतो:

1. प्रत्येक फिल्टरसाठी deduplicate (निवडाधारित, डीफॉल्ट false). एखादा फिल्टर rules.deduplicate: true सेट करून, त्या फिल्टरच्या जुळलेल्या आउटपुटमधील सलग डुप्लिकेट ओळी ट्रंकेशनपूर्वी एकत्र करू शकतो. ही प्रक्रिया lineFilter.ts मध्ये चालते. जुन्या फिल्टर्ससाठी, फिल्टरने collapsePatterns परिभाषित केले असल्यास ती स्वयंचलितपणे सक्षम केली जाते. स्कीमा: open-sse/services/compression/engines/rtk/filterSchema.ts मधील deduplicate: z.boolean().default(false).
2. संपूर्ण इंजिनसाठी deduplicateThreshold (डीफॉल्ट 3). सर्व फिल्टर्स चालल्यानंतर, इंजिन संपूर्ण परिणामामधील एकसारख्या सलग ओळींचा >= deduplicateThreshold इतका कोणताही क्रम एकत्र करते (deduplicateRepeatedLines, जे engines/rtk/index.ts मध्ये लागू केले जाते). नॉर्मलायझेशनदरम्यान हे मूल्य 2–100 च्या मर्यादेत ठेवले जाते.

प्रत्येक फिल्टरची प्रक्रिया आधी (फिल्टरच्या आत) चालते आणि संपूर्ण इंजिनची प्रक्रिया शेवटी (जोडलेल्या आउटपुटवर) चालते, त्यामुळे दुहेरी मोजणी न होता दोन्ही प्रक्रिया एकत्रितपणे कार्य करतात.

ओळींचे गटबद्धीकरण (enableGrouping)

जेव्हा rtkConfig.enableGrouping हे true (डीफॉल्ट false) असते, तेव्हा RTK डुप्लिकेशन काढल्यानंतरच्या परिणामावर अतिरिक्त groupSimilarLines प्रक्रिया चालवतो, जी जवळपास समतुल्य (बाइट-स्तरावर तंतोतंत एकसारख्या नसलेल्या) सलग ओळींचे क्रम एकत्र करते. rtkConfig.groupingThreshold (डीफॉल्ट 3) ही गटबद्धीकरण सुरू करणारी किमान क्रम-लांबी आहे. हे deduplicateThreshold चे संरचनात्मक समकक्ष आहे: डिडुप्लिकेशन तंतोतंत पुनरावृत्ती हाताळते, तर गटबद्धीकरण "किरकोळ फरकांसह समान रचना" हाताळते. दोन्ही फ्लॅग key_value टेबलमध्ये कायमस्वरूपी साठवलेल्या rtkConfig JSON चा भाग आहेत (वरील कॉन्फिगरेशन पाहा), त्यामुळे रीस्टार्टनंतरही सेटिंग कायम राहते.

कोडमधील टिप्पण्या काढणे (stripCodeComments / preserveDocstrings)

rtkConfig.applyToCodeBlocks सक्षम असताना, RTK फेन्स्ड कोड ब्लॉक्समधील टिप्पण्याही काढू शकतो:

• stripCodeComments (डीफॉल्ट false) — निवडाधारित. हे true असताना, RTK JavaScript आणि TypeScript फेन्स्ड ब्लॉक्समधून टिप्पण्या काढतो. ऐतिहासिकदृष्ट्या हा फ्लॅग वाचला जात असे, पण प्रत्यक्षात कधीही लागू केला जात नव्हता; त्यामुळे प्रॉडक्शनमध्ये नकळत बदल होऊ नये म्हणून डीफॉल्ट "जतन करा" असा ठेवला आहे.
• preserveDocstrings (डीफॉल्ट true) — टिप्पण्या काढताना JSDoc//** … */ ब्लॉक टिप्पण्या जतन केल्या जातात (त्यांच्यासाठी लागणाऱ्या बाइट्सपेक्षा अधिक मौल्यवान API दस्तऐवजीकरण त्यात असते). त्याही काढण्यासाठी हे false वर सेट करा.

टिप्पण्या काढण्याची अंमलबजावणी open-sse/services/compression/engines/rtk/codeStripper.ts मध्ये केली आहे. ती TypeScript पार्सर वापरते (regex नाही), त्यामुळे स्ट्रिंग, टेम्पलेट आणि regex लिटरल्सना चुकून टिप्पण्या समजले जात नाही; तसेच JSX आढळल्यास ती संपूर्ण प्रक्रिया थांबवते (जेणेकरून JSX एक्सप्रेशन-कंटेनरमधील टिप्पण्या कधीही खराब होणार नाहीत). सध्या टिप्पण्या काढण्याची प्रक्रिया फक्त JavaScript आणि TypeScript साठी लागू होते — स्ट्रिपरच्या CodeLanguage संचातील इतर भाषांमध्ये (Python, Rust, Go, Ruby, Java) रिकाम्या ओळी आणि व्हाइटस्पेस एकत्र केले जातात, पण टिप्पण्या काढल्या जात नाहीत. स्ट्रिप केलेल्या ब्लॉकची प्रक्रिया rulesApplied मध्ये rtk:code-strip म्हणून टॅग केली जाते.

टीप — GCF / टॅब्युलर एन्कोडिंग हे स्वतंत्र इंजिन आहे. RTK मध्ये "GCF" (Graph Compact Format) टॅब्युलर/कॉलमनर JSON एन्कोडर नाही. जुन्या omni-tabular एन्कोडरची जागा घेणारा हा एन्कोडर headroom इंजिनमध्ये आहे (open-sse/services/compression/engines/headroom/, आणि व्हेंडर केलेला कोडेक headroom/gcf/ अंतर्गत आहे). येथे दस्तऐवजीकरण केलेल्या RTK फिल्टर पाइपलाइनशी त्याचा संबंध नाही.

कॉन्फिगरेशन

जागतिक सेटिंग्ज /api/settings/compression द्वारे उपलब्ध आहेत. RTK-विशिष्ट सेटिंग्जदेखील /api/context/rtk/config द्वारे उपलब्ध आहेत.

{
  "defaultMode": "stacked",
  "autoTriggerMode": "stacked",
  "autoTriggerTokens": 32000,
  "stackedPipeline": [
    { "engine": "rtk", "intensity": "standard" },
    { "engine": "caveman", "intensity": "full" }
  ],
  "rtkConfig": {
    "enabled": true,
    "intensity": "standard",
    "applyToToolResults": true,
    "applyToCodeBlocks": false,
    "applyToAssistantMessages": false,
    "enabledFilters": [],
    "disabledFilters": [],
    "maxLinesPerResult": 120,
    "maxCharsPerResult": 12000,
    "deduplicateThreshold": 3,
    "customFiltersEnabled": true,
    "trustProjectFilters": false,
    "rawOutputRetention": "never",
    "rawOutputMaxBytes": 1048576,
    "enableGrouping": false,
    "groupingThreshold": 3,
    "stripCodeComments": false,
    "preserveDocstrings": true
  }
}

enabledFilters आणि disabledFilters फिल्टर आयडी वापरतात, उदाहरणार्थ test-vitest किंवा git-diff.

rtkConfig ची संपूर्ण रचना open-sse/services/compression/types.ts मधील RtkConfig / DEFAULT_RTK_CONFIG द्वारे परिभाषित केली आहे. संपूर्ण ऑब्जेक्ट SQLite मधील key_value तक्त्यात namespace = "compression", key = "rtkConfig" अंतर्गत एकच JSON मूल्य म्हणून कायमस्वरूपी साठवला जातो (src/lib/db/compression.ts) आणि वाचताना normalizeRtkConfig द्वारे सामान्यीकृत केला जातो. त्यामुळे खालील प्रत्येक फील्ड — enableGrouping, groupingThreshold, stripCodeComments आणि preserveDocstrings यांसह — त्याच स्टोअरमधून दोन्ही दिशांनी जतन होते आणि रीस्टार्टनंतरही टिकून राहते.

की	डीफॉल्ट	उद्देश
deduplicateThreshold	3	संपूर्ण इंजिनसाठी: संक्षिप्त करण्यासाठी सलग समान ओळींची किमान संख्या (2–100 पर्यंत मर्यादित)
enableGrouping	false	पर्यायी: जवळपास समतुल्य सलग ओळींचे समूह संक्षिप्त करा
groupingThreshold	3	समूह बनवण्यास चालना देणाऱ्या सलग समान ओळींच्या संचाची किमान संख्या
stripCodeComments	false	पर्यायी: कुंपणबद्ध कोड ब्लॉक्समधील टिप्पण्या काढा (applyToCodeBlocks आवश्यक)
preserveDocstrings	true	टिप्पण्या काढताना JSDoc//** … */ ब्लॉक्स कायम ठेवा

API

मार्ग	पद्धत	उद्देश
/api/context/rtk/config	GET	RTK कॉन्फिग वाचा
/api/context/rtk/config	PUT	RTK कॉन्फिग अद्ययावत करा
/api/context/rtk/filters	GET	फिल्टर कॅटलॉग आणि लोड निदानांची सूची दाखवा
/api/context/rtk/import	POST	RTK TOML स्कीमा v1 फाइल्स सत्यापित करा किंवा स्थापित करा
/api/context/rtk/test	POST	एका मजकूर पेलोडसाठी RTK संक्षेपणाचे पूर्वावलोकन करा
/api/context/rtk/raw-output/[id]	GET	राखून ठेवलेले संपादित रॉ आउटपुट वाचा
/api/compression/preview	POST	कोणत्याही संक्षेपण मोडचे पूर्वावलोकन करा

RTK चाचणी पेलोड:

{
  "command": "npm test",
  "text": "FAIL tests/example.test.ts\nAssertionError: expected true\nTest Files 1 failed",
  "config": {
    "intensity": "standard"
  }
}

संक्षेपण पूर्वावलोकन पेलोड:

{
  "mode": "stacked",
  "messages": [
    {
      "role": "tool",
      "content": "FAIL tests/example.test.ts\nAssertionError: expected true\nTest Files 1 failed"
    }
  ],
  "config": {
    "rtkConfig": {
      "rawOutputRetention": "failures"
    }
  }
}

व्यवस्थापन मार्गांसाठी डॅशबोर्ड व्यवस्थापन प्रमाणीकरण किंवा जुळणारे API-की धोरण आवश्यक आहे.

RTK TOML सत्यापन पेलोड:

{
  "action": "validate",
  "content": "schema_version = 1\n\n[filters.my-tool]\nmatch_command = \"^my-tool\\\\b\"\nmax_lines = 20\n"
}

सत्यापित फाइल जागतिक स्तरावर स्थापित करण्यासाठी "action": "install" वापरा. अस्तित्वात असलेली जागतिक फाइल बदलण्याचे पुनरावलोकन आणि पुष्टी केल्यानंतरच "overwrite": true जोडा.

कच्चे आउटपुट पुनर्प्राप्त करणे

RTK सामान्यतः फक्त संकुचित मजकूर परत करते. डीबगिंगसाठी, rawOutputRetention संपादित केलेले कच्चे आउटपुट राखून ठेवू शकते:

मूल्य	वर्तन
never	कच्चे आउटपुट राखून ठेवू नका
failures	फक्त संभाव्य अपयशाचे आउटपुट राखून ठेवा
always	संपादनानंतर प्रत्येक संकुचित RTK कच्चे आउटपुट राखून ठेवा

राखून ठेवलेल्या फाइल्स येथे लिहिल्या जातात:

DATA_DIR/rtk/raw-output/

संचयित करण्यापूर्वी गुपिते संपादित केली जातात, ज्यामध्ये सामान्य bearer tokens, API keys, Slack tokens, AWS access keys आणि assignment-style token=..., secret=..., password=... मूल्यांचा समावेश होतो. विश्लेषणामध्ये फक्त pointer id, आकार आणि hash metadata साठवले जाते.

पडताळणी गेट

लक्ष्यित पडताळणी गेट बाह्य कमांड्ससाठी shell वापरल्याशिवाय अंगभूत inline filter चाचण्या चालवते:

node --import tsx/esm --test tests/unit/compression/rtk-verify.test.ts

व्यापक RTK गेट असे आहे:

node --import tsx/esm --test \
  tests/unit/compression/rtk-*.test.ts \
  tests/unit/compression/pipeline-integration.test.ts \
  tests/unit/compression/context-compression-api.test.ts

रिलीजपूर्वी व्यापक compression गेट चालवा:

node --import tsx/esm --test \
  tests/unit/compression/*.test.ts \
  tests/golden-set/*.test.ts \
  tests/integration/compression-pipeline.test.ts \
  tests/unit/api/compression/compression-api.test.ts

RTK चा विस्तार करणे

1. filter JSON फाइल जोडा किंवा अद्ययावत करा.
2. महत्त्वाचे वर्तन सिद्ध करणारा किमान एक tests[] नमुना समाविष्ट करा.
3. नवीन command families साठी tests/unit/compression/fixtures/rtk/ अंतर्गत fixture जोडा.
4. नवीन output class सादर करताना command detection coverage जोडा.
5. पडताळणी आणि व्यापक RTK गेट्स चालवा.
6. filter प्रकल्प-स्थानिक असल्यास, .rtk/filters.json commit करा आणि केवळ पुनरावलोकनानंतर .rtk/trust.json रीफ्रेश करा.

---

तीव्रता पातळ्या (v3.8.16+)

RTK 3 तीव्रता पातळ्यांना समर्थन देते, ज्या compression aggressiveness आणि safety यांच्यात संतुलन साधतात. ही पातळी engine config मधील config.intensity द्वारे सेट केली जाते.

3 पातळ्या

पातळी	छाटणी मर्यादा	टोकन बचत	जोखीम	यासाठी सर्वोत्तम
minimal	प्रत्येक विभागात 24 ओळी	~20-40%	अत्यंत कमी	महत्त्वपूर्ण संदर्भ असलेले production
standard (डीफॉल्ट)	प्रत्येक विभागात 24 ओळी	~50-70%	कमी	दैनंदिन coding sessions
aggressive	प्रत्येक विभागात 16 ओळी	~70-90%	मध्यम	दीर्घ sessions, कमाल बचत

छाटणी कुठे होते

छाटणी मर्यादा lineFilter.ts वर परिणाम करते:

// open-sse/services/compression/engines/rtk/index.ts:329-330 मधून
config.intensity === "aggressive" ? 16 : 24,
config.intensity === "aggressive" ? 16 : 24,

प्रत्येक विभागाचा आरंभ आणि शेवट दोन्ही जतन केले जातात; छाटणी सुरू झाल्यावर मधील मजकूर वगळला जातो.

काय टिकून राहते आणि काय कापले जाते

सामग्री	minimal	standard	aggressive
त्रुटी / stack traces	✅ जतन केलेले	✅ जतन केलेले	✅ जतन केलेले
चाचणी अपयश	✅ जतन केलेले	✅ जतन केलेले	✅ जतन केलेले
Build त्रुटी	✅ जतन केलेले	✅ जतन केलेले	✅ जतन केलेले
चाचणी यश (verbose)	✅ जतन केलेले	🟡 संक्षिप्त केलेले	🟡 संक्षिप्त केलेले
नियमित आउटपुट (info logs)	🟡 संक्षिप्त केलेले	🟡 संक्षिप्त केलेले	❌ वगळलेले
प्रगती पट्ट्या	🟡 संक्षिप्त केलेले	❌ वगळलेल्या	❌ वगळलेल्या
Banner / ASCII art	🟡 संक्षिप्त केलेले	❌ वगळलेले	❌ वगळलेले

योग्य तीव्रता निवडणे

                  संदर्भ गमावणे विनाशकारी आहे का?
                  │
      ┌───────────┼───────────┐
      │           │           │
     होय         नाही       खात्री नाही
      │           │           │
      ▼           │           │
   minimal        │           │
      │           │           │
      │           ▼           ▼
      │      throughput किती  प्रथम `standard` वापरून पाहा
      │      महत्त्वपूर्ण आहे? (80% प्रकरणांमध्ये
      │           │           कार्य करते)
      │      ┌────┴────┐
      │      │         │
      │     कमी       जास्त
      │      │         │
      │      ▼         ▼
      │   standard   aggressive
      │      │         │
      └──────┴─────────┘

तीव्रता कॉन्फिगर करणे

प्रत्येक combo साठी (combo config मध्ये):

{
  "combo": "my-coding-combo",
  "routing": {/* ... */},
  "compression": {
    "engine": "rtk",
    "intensity": "aggressive"
  }
}

प्रोग्रामद्वारे:

rtkEngine (@omniroute/open-sse/services/compression/engines/rtk) हे CompressionEngine आहे आणि त्यात updateConfig method नाही. त्याऐवजी registry helper द्वारे engine चे config अद्ययावत करा:

import { updateEngineConfig } from "@omniroute/open-sse/services/compression/engines/registry";

updateEngineConfig("rtk", { intensity: "aggressive" });

परिणामाची पडताळणी करणे

तुमचा filter तुम्ही निवडलेल्या तीव्रतेवर सुरक्षित आहे याची पुष्टी करण्यासाठी पडताळणी गेट (खाली पहा) वापरा:

import { runRtkFilterTests } from "omniroute/compression/engines/rtk/verify";

const result = runRtkFilterTests({ intensity: "aggressive" });
if (!result.passed) {
  console.error("आक्रमक तीव्रतेवर filters अयशस्वी झाले");
}

---

सानुकूल फिल्टर विकास (v3.8.16+)

engines/rtk/filters/ निर्देशिकेमध्ये 49+ अंगभूत फिल्टर JSON फाइल्स आहेत. डीफॉल्टमध्ये समाविष्ट नसलेल्या सानुकूल साधनांमधील आउटपुट संक्षिप्त करण्यासाठी तुम्ही स्वतःचे फिल्टर्स जोडू शकता.

फिल्टर स्कीमा (Zod)

{
  "id": "string",                      // आवश्यक. फिल्टर ओळखकर्ता (kebab-case, उदा., "python-traceback")
  "label": "string",                   // आवश्यक. मानवाला वाचता येण्याजोगे फिल्टरचे नाव
  "description": "string",             // पर्यायी (डीफॉल्ट: ""). फिल्टर काय करतो याचे संक्षिप्त वर्णन
  "category": "git|test|build|shell|docker|package|infra|cloud|generic",
  "priority": number,                  // पर्यायी (0-100, डीफॉल्ट: 50). अंमलबजावणीचा क्रम (जास्त = प्रथम)
  "match": {
    "commands": ["string"],            // जुळवण्यासाठी कमांडची नावे (उदा., "python", "pytest")
    "patterns": ["string"],            // आउटपुटशी जुळवण्यासाठी Regex पॅटर्न
    "outputTypes": ["string"]          // शोधलेले आउटपुट वर्ग (उदा., "test-failure")
  },
  "rules": {
    "stripAnsi": boolean,              // पर्यायी (डीफॉल्ट: false). ANSI रंग कोड काढून टाका
    "replace": [                       // शोधा-आणि-बदला नियम (डीफॉल्ट: [])
      { "pattern": "regex", "replacement": "..." }
    ],
    "matchOutput": [                   // पॅटर्न जुळल्यावर शॉर्ट-सर्किट करा (डीफॉल्ट: [])
      {
        "pattern": "regex",
        "message": "short summary",
        "unless": "regex"              // हा पॅटर्न जुळल्यास वगळा
      }
    ],
    "includePatterns": ["string"],     // ठेवायच्या ओळी (Regex पॅटर्न, डीफॉल्ट: [])
    "dropPatterns": ["string"],        // वगळायच्या ओळी (Regex पॅटर्न, डीफॉल्ट: [])
    "collapsePatterns": ["string"],    // एकाच आवृत्तीमध्ये संकुचित करायच्या ओळी (डीफॉल्ट: [])
    "deduplicate": boolean,            // पर्यायी (डीफॉल्ट: false). डुप्लिकेट ओळी काढून टाका
    "truncateLineAt": number,          // पर्यायी (डीफॉल्ट: 0). ओळी कमाल वर्णसंख्येपर्यंत कापा
    "maxLines": number,                // पर्यायी (डीफॉल्ट: 0). एकूण ओळींवर कठोर मर्यादा
    "headLines": number,               // पर्यायी (डीफॉल्ट: 20). जुळलेल्या आउटपुटमधील पहिल्या N ओळी ठेवा
    "tailLines": number,               // पर्यायी (डीफॉल्ट: 20). जुळलेल्या आउटपुटमधील शेवटच्या N ओळी ठेवा
    "onEmpty": "string",               // पर्यायी (डीफॉल्ट: ""). सर्व ओळी फिल्टर झाल्यास पर्यायी संदेश
    "filterStderr": boolean            // पर्यायी (डीफॉल्ट: false). stderr आउटपुटही फिल्टर करा
  },
  "preserve": {
    "errorPatterns": ["string"],       // नेहमी जतन करणे आवश्यक असलेले पॅटर्न (डीफॉल्ट: [])
    "summaryPatterns": ["string"]      // अंतिम सारांश ओळीसाठी पॅटर्न (डीफॉल्ट: [])
  },
  "tests": [                           // पडताळणीसाठी इनलाइन चाचण्या (डीफॉल्ट: [])
    {
      "name": "string",               // आवश्यक. चाचणीचे नाव
      "input": "sample output",        // आवश्यक. नमुना इनपुट मजकूर
      "expected": "expected output",   // आवश्यक. अपेक्षित संक्षिप्त आउटपुट
      "command": "optional command"    // पर्यायी. कमांड संदर्भ
    }
  ]
}

उदाहरण: Python Traceback फिल्टर

{
  "id": "python-traceback",
  "label": "Python Traceback Filter",
  "description": "Compresses Python tracebacks to essential file/line locations and error type",
  "category": "test",
  "priority": 60,
  "match": {
    "commands": ["python", "python3", "pytest", "uv", "poetry"],
    "patterns": ["Traceback \\(most recent call last\\)", "Error", "Exception"],
    "outputTypes": ["error-traceback"]
  },
  "rules": {
    "stripAnsi": true,
    "includePatterns": [
      "Traceback \\(most recent call last\\)",
      "^\\s*File \".+\", line \\d+",
      "^\\s*[A-Z][a-zA-Z]+Error:",
      "^\\s*[A-Z][a-zA-Z]+Exception"
    ],
    "dropPatterns": ["site-packages/", "^\\s+[a-z_]+\\([^)]*\\)$"],
    "headLines": 5,
    "tailLines": 3,
    "maxLines": 25,
    "filterStderr": true
  },
  "preserve": {
    "errorPatterns": ["Error:", "Exception:", "Traceback"],
    "summaryPatterns": ["^[A-Z][a-zA-Z]+(?:Error|Exception):"]
  },
  "tests": [
    {
      "name": "preserves-error-type-and-location",
      "input": "Traceback (most recent call last):\n  File \"app.py\", line 42, in main\n    do_thing()\n  File \"lib/utils.py\", line 17, in helper\n    return 1 / 0\nZeroDivisionError: division by zero",
      "expected": "Traceback (most recent call last):\n  File \"app.py\", line 42, in main\n  File \"lib/utils.py\", line 17, in helper\nZeroDivisionError: division by zero",
      "command": "python app.py"
    }
  ]
}

सानुकूल फिल्टर्स लोड करणे

फाइल मान्यताप्राप्त ठिकाणी ठेवा:

~/.omniroute/rtk/filters/my-filter.json     # वापरकर्ता-स्तरीय
<project>/.rtk/filters/my-filter.json      # प्रकल्प-स्तरीय

सुरू होताना open-sse/services/compression/engines/rtk/filterLoader.ts मधील loadRtkFilters() द्वारे फिल्टर्स स्वयंचलितपणे लोड केले जातात. लोडर पुढील ठिकाणांवरून फिल्टर्स शोधतो:

• अंगभूत कॅटलॉग: open-sse/services/compression/engines/rtk/filters/
• वापरकर्ता निर्देशिका: ~/.omniroute/rtk/filters/
• प्रकल्प निर्देशिका: <project>/.rtk/filters/

प्रोग्रामद्वारे फिल्टर्स लोड करण्यासाठी:

import { loadRtkFilters } from "@omniroute/open-sse/services/compression/engines/rtk/filterLoader";

// पर्याय: customFiltersEnabled (वापरकर्ता/प्रकल्प फिल्टर्स लोड करा, डीफॉल्टनुसार सुरू),
// trustProjectFilters, refresh.
const filters = loadRtkFilters({ customFiltersEnabled: true });

प्रमाणीकरण

लोड करताना फिल्टर्सचे Zod स्कीमाविरुद्ध प्रमाणीकरण केले जाते. चुकीची संरचना असलेला फिल्टर लोड होण्यात अयशस्वी होईल आणि त्रुटी लॉग करेल:

RTK_FILTER_LOADER: filter "my-filter" failed validation:
  - rules.replace.0.pattern: Invalid regex
  - match.commands: must not be empty

स्थापित केलेल्या सर्व फिल्टर्सचे प्रमाणीकरण करण्यासाठी, open-sse/services/compression/engines/rtk/verify.ts मधून एक्सपोर्ट केलेले runRtkFilterTests() कॉल करा.

सर्वोत्तम पद्धती

1. नेहमी tests[] समाविष्ट करा — ते तुमचा फिल्टर कार्यरत असल्याचे सिद्ध करतात आणि रिग्रेशन्स टाळतात
2. शॉर्ट-सर्किट्ससाठी matchOutput वापरा — जर एकाच ओळीत संपूर्ण आशय स्पष्ट होत असेल, तर पूर्ण ब्लॉक बदला
3. strip ऐवजी keep ला प्राधान्य द्या — स्पष्ट "नेहमी जतन करा" नियम हे "नेहमी काढून टाका" नियमांपेक्षा अधिक सुरक्षित असतात
4. सर्व 3 तीव्रता पातळ्यांवर चाचणी करा — minimal ने कोणताही बदल करू नये आणि aggressive ने तरीही त्रुटी जतन कराव्यात
5. unless फील्ड वापरा — "X उपस्थित असल्यास ट्रिगर करू नका" या अटीने शॉर्ट-सर्किट्स सुरक्षित करा

---

रॉ आउटपुट पुनर्प्राप्ती आणि पडताळणी गेट

RTK आउटपुटचे आक्रमकपणे संक्षिप्तीकरण करते तेव्हा, डीबगिंग, ऑडिट किंवा रीप्लेसाठी तुम्ही मूळ मजकूर पुनर्प्राप्त करू शकता.

रॉ आउटपुट पुनर्प्राप्ती कशी कार्य करते

मूळ आउटपुट (10K टोकन)
        │
        ▼
RTK संक्षिप्तीकरण (rawOutput.enabled=true सह)
        │
        ├─▶ संक्षिप्त आउटपुट (2K टोकन)  ──▶ LLM कडे
        │
        └─▶ मूळ आउटपुट (10K टोकन)       ──▶ DB मध्ये संग्रहित
                                                  (request_id द्वारे जोडलेले)

रॉ आउटपुट स्टोरेज सक्षम करणे

प्रत्येक विनंतीसाठी (कॉम्बो कॉन्फिगरेशनमध्ये):

{
  "compression": {
    "engine": "rtk",
    "intensity": "aggressive",
    "rawOutput": {
      "enabled": true,
      "maxBytes": 1048576 // 1MB मर्यादा
    }
  }
}

डीफॉल्ट: rawOutput.enabled: false (स्टोरेज वाचवते).

स्टोरेज खर्च

प्रत्येक विनंतीसाठी	1MB मर्यादा	10MB मर्यादा
सरासरी संक्षिप्त आउटपुट	~5KB	~5KB
संग्रहित रॉ आउटपुट	~50-500KB	~500KB-5MB
दररोज 1000 विनंत्यांसह	50-500MB/दिवस	500MB-5GB/दिवस

शिफारस: रॉ आउटपुट नेहमी सुरू ठेवण्याऐवजी केवळ डीबगिंग सत्रांसाठी किंवा नमुना-आधारित ऑडिटिंगसाठी सक्षम करा.

मूळ आउटपुट पुनर्प्राप्त करणे

import { readRtkRawOutput } from "omniroute/compression/engines/rtk/rawOutput";

const raw = readRtkRawOutput(pointerId); // कॉम्प्रेशन आकडेवारीतील pointerId
if (raw) {
  console.log("Original output:", raw);
}

कॉम्प्रेशननंतर pointerId, CompressionStats.rtkRawOutputPointers[] मध्ये परत केला जातो. फंक्शन सिग्नेचरसाठी open-sse/services/compression/engines/rtk/rawOutput.ts:102 पहा.

पडताळणी गेट

RTK फिल्टर पडताळणी (open-sse/services/compression/engines/rtk/verify.ts) सर्व फिल्टर्सची त्यांच्या tests[] विरुद्ध पडताळणी करते आणि सर्व 3 तीव्रता स्तरांवर वर्तन योग्य असल्याची खात्री करते.

पडताळणी चालवण्यासाठी runRtkFilterTests() कॉल करा:

import { runRtkFilterTests } from "open-sse/services/compression/engines/rtk/verify";

const result = runRtkFilterTests();
console.log(`Passed: ${result.outcomes.filter((o) => o.passed).length}`);
console.log(`Failed: ${result.outcomes.filter((o) => !o.passed).length}`);
if (!result.passed) {
  console.error("Filters failed verification");
  result.outcomes
    .filter((o) => !o.passed)
    .forEach((o) => {
      console.error(
        `  - ${o.filterId} / ${o.testName}: expected "${o.expected}", got "${o.actual}"`
      );
    });
}

ते कशाची पडताळणी करते:

1. प्रत्येक फिल्टर लोड होतो आणि स्कीमा पडताळणी उत्तीर्ण करतो
2. प्रत्येक tests[] नोंद अपेक्षित आउटपुट निर्माण करते
3. minimal तीव्रता कोणतीही क्रिया करत नाही (मूळ जतन करते, केवळ संरचनात्मक फिल्टर्स लागू करते)
4. aggressive तीव्रता त्रुटी, चाचणी अपयश आणि स्टॅक ट्रेसेस जतन करते
5. संक्षिप्त आउटपुट कधीही मूळ इनपुटपेक्षा मोठे नसते

• स्रोत: open-sse/services/compression/engines/rtk/ (63 फाइल्स, ~70KB)

• फिल्टरमधील बदल मर्ज करण्यापूर्वी — चाचण्या नेहमी उत्तीर्ण होत असल्याची खात्री करा

• RTK इंजिन अपग्रेड केल्यानंतर — स्कीमा बदललेली असू शकते

• नियमित निरीक्षणादरम्यान — चाचणी फिक्स्चर्समधील विचलनापासून संरक्षण करते

• नवीन टूल/कमांड फॅमिली जोडताना — नवीन फिल्टर कार्य करत असल्याचे सिद्ध करते

---

हे देखील पहा

• COMPRESSION_GUIDE.md — संपूर्ण कॉम्प्रेशन पाइपलाइनचा आढावा
• COMPRESSION_ENGINES.md — इंजिन रजिस्ट्री आणि अंगभूत इंजिन्स
• EXTENDING_COMPRESSION.md — सानुकूल इंजिन्स, भाषा पॅक्स, स्टॅक्ड पाइपलाइन्स
• स्रोत: open-sse/services/compression/engines/rtk/ (63 फाइल्स, ~70KB)