आपकी README आर्किटेक्चर समझाती है। docs फ़ोल्डर बताता है कि फ़ैसले क्यों लिए गए। लेकिन आज तक, Octocode के नॉलेज ग्राफ में इनमें से कुछ भी मौजूद नहीं था।

0.20.0 इस कमी को दूर करता है: Markdown फ़ाइलें अब GraphRAG नॉलेज ग्राफ में नोड हैं, और दस्तावेज़ों के बीच के लिंक typed references relationships बनते हैं, जिन पर AI सहायक सचमुच चल सकता है।

यह बात मुझे काफ़ी समय से खटक रही थी। Octocode हमेशा से आपके दस्तावेज़ ढूँढ सकता था — semantic search ने शुरुआत से ही Markdown को index किया है। लेकिन किसी दस्तावेज़ को keyword से ढूँढना और प्रोजेक्ट की बनावट का पीछा करते हुए उसे खोज निकालना दो अलग बातें हैं। “payment module पर क्या निर्भर करता है?” पूछने वाला सहायक code graph पर आसानी से चल सकता था, फिर भी तीन directories दूर रखे उस architecture note से पूरी तरह अनजान रह जाता था जो बताता है कि module इस तरह क्यों बना है।

कोड आधी कहानी बताता था। अब ग्राफ दूसरी आधी भी जानता है।

असल में क्या बदला

संक्षेप में: indexing के दौरान Markdown दस्तावेज़ अब source code की तरह उसी GraphRAG pipeline से गुज़रते हैं। Graph queries, relationship expansion और graphrag MCP tool अब documentation को code के साथ सामने ला सकते हैं — अलग खोज के रूप में नहीं, बल्कि उसी traversal के हिस्से के रूप में।

ये तकनीकी व्यवस्थाएँ इसे उपयोगी बनाती हैं, शोर नहीं:

दस्तावेज़ों के बीच के लिंक references relationships बन जाते हैं। जब एक Markdown फ़ाइल दूसरी फ़ाइल को लिंक करती है — [see the guide](guide.md) — तो Octocode उनके बीच एक typed edge दर्ज करता है। Relative links उस फ़ाइल की जगह से resolve होते हैं जिसमें लिंक लिखा है, anchor fragments (#section) हटा दिए जाते हैं और बाहरी http:///https:// URL को अनदेखा किया जाता है। आपके दस्तावेज़ों की link structure हमेशा से एक नक्शा थी। अब ग्राफ उसे पढ़ सकता है।

Weighting जानबूझकर तय की गई है। Graph traversal में references का importance weight 0.6 है — imports और calls जैसी structural code relationships (0.7) से कम, लेकिन same-directory grouping जैसी organizational relationships (0.3) से ज़्यादा। इस तरह दस्तावेज़ों के लिंक, code structure को दबाए बिना expansion की दिशा तय करते हैं। दो दस्तावेज़ों के बीच का लिंक किसी इंसान का यह कहना है कि “ये दोनों साथ हैं।” यह एक असली संकेत है, पर actual call edge के बराबर नहीं; weights इसी अंतर को दिखाते हैं।

.markdown फ़ाइलें अब हर उस जगह काम करती हैं जहाँ .md करती हैं। Semantic search और नए graph integration, दोनों में। बात छोटी है, लेकिन इस असंगति से पुराने repositories में दिक़्क़त आती थी।

और upgrade का सबसे अच्छा हिस्सा यह है: आपको शुरुआत से दोबारा index करने की ज़रूरत नहीं है। Markdown content पहले से ही index के document blocks में सहेजा हुआ है, इसलिए graph को rebuild करते समय वह मौजूदा database से मिल जाता है। octocode index चलाएँ या graph rebuild करें — आपके दस्तावेज़ उसमें दिखाई देने लगेंगे।

वह bug जो बिना बताए relationships छिपा रहा था

कुछ लोगों के लिए यह सुधार नई सुविधा से भी ज़्यादा अहम है।

LanceDB से relationships वापस पढ़ते समय, सहेजे गए result set का केवल एक हिस्सा मिलता था — बाद के batches साथ जुड़ने के बजाय छोड़ दिए जाते थे। छोटे प्रोजेक्ट्स पर इसका पता भी नहीं चलता। बड़े प्रोजेक्ट्स में graph queries बिना किसी चेतावनी के ऐसी connections छोड़ सकती थीं जो वहाँ होनी चाहिए थीं।

“बिना चेतावनी” यहाँ सबसे अहम है। न कोई error, न warning — बस एक अधूरा graph जो पूरा दिखता था। अगर आपने कभी किसी बड़े repository पर graph query चलाकर सोचा हो, “यहाँ तो और edges होने चाहिए,” तो शायद यही वजह थी। अब graph को rebuild या reload करने पर पूरी relationship set लौटती है।

इसके साथ दो और संबंधित सुधार आए:

  • Markdown headings अब code symbol index को दूषित नहीं करतीं। Document headings को “symbols” की तरह index किया जा रहा था और import resolution उनसे match कर रही थी, जिससे ग़लत relationship candidates बनते थे। अब Markdown nodes symbol indexing से बाहर हैं, लेकिन path-based links के ज़रिए graph में शामिल रहते हैं।
  • Markdown nodes अब symbol से नहीं, path से resolve होते हैं। बेहतर relationship-discovery pass में दस्तावेज़ path-based resolution से गुज़रते हैं — क्योंकि दस्तावेज़ों के लिंक वास्तव में ऐसे ही काम करते हैं — न कि code के लिए बने symbol-matching रास्ते से। अब document-to-document edges संयोग से नहीं, सही तरीके से बनते हैं।

Relationships लोड करने में आधी मेमोरी

Incremental indexing के दौरान एक ही relationship अलग-अलग batches में एक से ज़्यादा बार लिखी जा सकती थी। एक वास्तविक बड़े प्रोजेक्ट में loader 288K unique relationships दिखाने के लिए 575K rows पढ़ रहा था — यानी लगभग आधा set duplicate था।

Graph load होते समय relationships अब (source, target, type) की तिकड़ी के आधार पर deduplicate होती हैं। इससे मेमोरी की खपत लगभग आधी हो जाती है और पूरे set पर चलने वाली हर graph operation तेज़ होती है। Duplicates हटाते समय loader उनकी संख्या भी बताता है, ताकि नतीजा साफ़ दिखे।

Config में कोई बदलाव नहीं। Graph बस कम मेमोरी में लोड होता है।

बाकी सब कुछ

MCP server को rmcp 3.0.0 पर upgrade किया गया है। Model Context Protocol का underlying SDK नए major version पर आ गया है, जिससे Octocode MCP ecosystem और उसके streamable-HTTP transport के साथ up to date रहता है। Stdin और HTTP server modes पहले की तरह काम करते हैं — configuration बदलने की ज़रूरत नहीं है।

Config handling अब octolib में है। Config file management और एक version से दूसरे version में migration की साझा logic — version walk, guards और table merging — अब octolib library में रहती है। Octocode में केवल उसके अपने v1→v2 migration steps बचे हैं। आपके लिए यह बदलाव पारदर्शी है: मौजूदा configs पहले की तरह ही migrate होती हैं। फायदा यह है कि config handling के सुधार अब octolib में एक बार लागू होते हैं और उस पर बने हर tool को मिल जाते हैं; उन्हें हर repository में अलग से ले जाने की ज़रूरत नहीं पड़ती।

Documentation पर भी काम हुआ है। README अब सभी MCP tools को दर्ज करता है — इनमें LSP पर आधारित tools (lsp_goto_definition, lsp_find_references, lsp_hover, lsp_document_symbols, lsp_workspace_symbols, lsp_completion) और उन्हें --with-lsp से चालू करने का तरीका भी शामिल है। Octocode को किसी भी OpenAI-compatible LLM या embedding endpoint से जोड़ने के लिए नए vendor-neutral guides भी हैं — चाहे वह local model server हो या कोई वैकल्पिक hosted provider।

अपग्रेड

# Homebrew
brew upgrade muvon/tap/octocode

# Universal installer
curl -fsSL https://raw.githubusercontent.com/Muvon/octocode/master/install.sh | sh

# Cargo
cargo install octocode --version 0.20.0

यह एक drop-in upgrade है — config बदलने की ज़रूरत नहीं और मौजूदा configuration files अपने आप migrate हो जाती हैं। Upgrade के बाद बस एक काम करें:

Graph को rebuild करें (या केवल octocode index चलाएँ) किसी ऐसे प्रोजेक्ट पर जिसमें वास्तविक documentation हो। फिर अपने सहायक से वह सवाल पूछें जिसका जवाब देने के लिए पहले किसी इंसान को code और documentation की कड़ियाँ जोड़नी पड़ती थीं — “authentication कहाँ संभाली जाती है और security guide उसके बारे में क्या कहती है?” — और देखें कि वह दोनों पर कैसे चलता है।

Octocode, Apache 2.0 लाइसेंस के तहत github.com/Muvon/octocode पर उपलब्ध ओपन-सोर्स प्रोजेक्ट है और Octomind के पीछे का code-search engine भी। ग्राफ पहले से जानता था कि आपका code कैसे जुड़ा है। अब वह यह भी जानता है कि आपने उसके बारे में क्या लिखा है।