Octofs: वह फ़ाइल सर्वर जो आपके AI को आपका कोड तोड़ने से रोकता है

आपके AI सहायक ने अभी तीन फ़ाइलें संपादित कीं। दो ठीक हैं। तीसरी में एक फ़ंक्शन डुप्लिकेट है, एक क्लोज़िंग ब्रेस गायब है, और इंडेंटेशन पूरी तरह गलत है। यह आत्मविश्वासी दिख रहा था। यह नहीं था।

यह जितना कोई स्वीकार करना चाहता है उससे कहीं अधिक होता है। AI एजेंट शक्तिशाली कोड एडिटर हैं — जब तक वे एक लाइन नंबर की कल्पना नहीं कर लेते, इंडेंटेशन को गलत याद नहीं करते, या किसी प्रतिस्थापन में आसपास का संदर्भ शामिल नहीं कर लेते जो वहां नहीं होना चाहिए। संपादन तकनीकी रूप से सफल होता है। फ़ाइल अब टूट गई है। आपने तब तक ध्यान नहीं दिया जब तक बिल्ड विफल नहीं हुआ।

Octofs एक MCP फ़ाइलसिस्टम सर्वर है जो ठीक इसी को रोकने के लिए बनाया गया है। यह आपके AI एजेंट को आँखें, हाथ और एक सुरक्षा जाल देता है — फ़ाइलों को पढ़ने, संपादित करने, बनाने और खोजने की क्षमता, AI मॉडल जब कोड को छूते हैं तो जो गलतियाँ करते हैं उनके खिलाफ सुरक्षा की कई परतों के साथ।

आज हम Octofs 0.4.0 का परिचय दे रहे हैं — एक परियोजना की वर्तमान स्थिति जो एक सरल फ़ाइल सर्वर के रूप में शुरू हुई और कुछ ऐसा बन गई जो हमें लगता है कि हर AI एजेंट को चाहिए।

हमने सबसे पहले एक फ़ाइलसिस्टम सर्वर क्यों बनाया

हमने यहाँ से शुरुआत नहीं की थी। हमने Octomind से शुरुआत की थी — विशेषज्ञ AI एजेंटों के लिए एक रनटाइम। आप octomind run developer:general चलाते हैं और पाँच सेकंड में पूरी तरह से उपकरण-संपन्न एक सीनियर डेवलपर मिल जाता है। एजेंट को कोड पढ़ने, फ़ाइलें संपादित करने, कमांड चलाने, आपकी परियोजना खोजने की आवश्यकता है। उसे फ़ाइलसिस्टम पहुँच चाहिए।

MCP इकोसिस्टम में पहले से ही एक संदर्भ फ़ाइलसिस्टम सर्वर था। तो हमने उसे आज़माया। यह काम करता था — जब तक नहीं करता था। AI उन लाइन नंबरों का संदर्भ देता जो पिछले संपादन के बाद बदल गए थे। यह स्ट्रिंग रिप्लेस में थोड़ा गलत व्हाइटस्पेस पास करता और एक मूक मिसमैच मिलता। यह प्रतिस्थापन रेंज के किनारों पर लाइनों को डुप्लिकेट कर देता। यह grep को शेल के माध्यम से चलाने की कोशिश करता जब एक समर्पित खोज उपकरण मौजूद था।

प्रत्येक विफलता छोटी थी। प्रत्येक को मानवीय हस्तक्षेप की आवश्यकता थी। एजेंट पैमाने पर — दर्जनों फ़ाइलों में सैकड़ों संपादन चलाते हुए — छोटी विफलताएँ कुछ ऐसी बन जाती हैं जो उपयोगी होना बंद कर देती हैं।

इसलिए हमने अपना खुद का लिखा। इसलिए नहीं कि फ़ाइलसिस्टम पहुँच दिलचस्प है। बल्कि इसलिए कि AI-संचालित फ़ाइल संपादन के विफलता मोड पूर्वानुमेय हैं, और एक अच्छा सर्वर उनमें से अधिकांश को आपकी समस्या बनने से पहले पकड़ सकता है।

फ़ाइल संपादन में AI कल्पना समस्या

यहाँ वही है जो वास्तव में टूटता है:

गलत लाइन नंबर। एजेंट एक फ़ाइल पढ़ता है, पाँच संपादनों की योजना बनाता है, उन्हें क्रमिक रूप से निष्पादित करता है। पहला संपादन तीन लाइनें जोड़ता है। अब प्रत्येक बाद के लाइन संदर्भ तीन से ऑफ है। एजेंट इसे नोटिस नहीं करता क्योंकि यह मूल मानसिक मॉडल से काम कर रहा है।

इंडेंटेशन कल्पना। एजेंट जानता है कि वह कौन सा कोड लिखना चाहता है। यह इंडेंटेशन थोड़ा गलत कर देता है — चार के बजाय दो स्पेस, या टैब जब फ़ाइल स्पेस का उपयोग करती है। सटीक मिलान विफल हो जाता है। संपादन चुपचाप कुछ नहीं करता, या इससे भी बदतर, एजेंट और भी अधिक भ्रमित संस्करण के साथ पुनः प्रयास करता है।

संदर्भ डुप्लीकेशन। एजेंट अपने प्रतिस्थापन पाठ में आसपास के संदर्भ की एक अतिरिक्त लाइन शामिल करता है। अब वह लाइन फ़ाइल में दो बार दिखाई देती है। यदि यह एक क्लोज़िंग ब्रेस है, तो कोड अभी भी पार्स हो सकता है। यदि यह एक सार्थक लाइन है, तो आपके पास एक सूक्ष्म बग है।

अस्पष्ट मिलान। एजेंट तीन-लाइन की एक स्ट्रिंग पास करता है जो फ़ाइल में चार स्थानों पर दिखाई देती है। कौन-सा प्रतिस्थापित होना चाहिए? असंदिग्धीकरण के बिना, संपादन या तो विफल हो जाता है या गलत स्थान पर पहुँच जाता है।

ये एज केस नहीं हैं। ये पैमाने पर AI एजेंट चलाने का डिफ़ॉल्ट अनुभव हैं। और ये सभी हल करने योग्य हैं — AI को होशियार बनाकर नहीं, बल्कि फ़ाइल सर्वर को उन गलतियों के बारे में होशियार बनाकर जो वह जानता है कि AI करेगा।

Octofs गलतियाँ कैसे पकड़ता है

तीन-चरण प्रगतिशील मिलान

जब AI str_replace को old_text के साथ कॉल करता है जिसे फ़ाइल में किसी चीज़ से मिलना चाहिए, Octofs केवल एक बार कोशिश करके विफल नहीं होता। यह तीन चरण चलाता है:

चरण 1: सटीक मिलान। old_text स्ट्रिंग फ़ाइल में ठीक एक बार मिलती है। उसे प्रतिस्थापित करें। हो गया। यह खुशहाल रास्ता है — यह अधिकांश संपादनों को सही ढंग से संभालता है।

चरण 2: व्हाइटस्पेस-नॉर्मलाइज़्ड फ़ज़ी मिलान। सटीक मिलान विफल हो जाता है, इसलिए Octofs प्रदान किए गए पाठ और फ़ाइल सामग्री दोनों में व्हाइटस्पेस को सामान्य करता है — स्पेस की श्रृंखलाओं को संक्षिप्त करना, लाइनों को ट्रिम करना — और फिर से कोशिश करता है। यदि ठीक एक सामान्यीकृत मिलान है, तो यह वास्तविक फ़ाइल से मेल खाने के लिए प्रतिस्थापन पाठ के इंडेंटेशन को स्वतः समायोजित करता है, संपादन लागू करता है, और एक संकेत के माध्यम से AI को बताता है कि क्या हुआ। AI सीखता है। संपादन सफल होता है।

चरण 3: समृद्ध डायग्नोस्टिक्स। न तो सटीक और न ही फ़ज़ी मिलान काम करता है। एक सामान्य "कोई मिलान नहीं मिला" त्रुटि के बजाय, Octofs पूरी फ़ाइल में स्लाइडिंग-विंडो समानता खोज चलाता है, तीन निकटतम मिलान ढूंढता है, और उन्हें समानता प्रतिशत, लाइन नंबर, क्यों वे अलग हैं इसका निदान (इंडेंटेशन मिसमैच, केवल व्हाइटस्पेस, या सामग्री अलग है), और उम्मीदवार पाठ का पूर्वावलोकन के साथ लौटाता है। फिर AI सटीक लाइन रेंज के साथ batch_edit का उपयोग कर सकता है — या अपने old_text को ठीक कर सकता है और पुनः प्रयास कर सकता है।

यह हर बार होता है जब कोई संपादन विफल होता है, और यह विफल संपादन पुनः प्रयासों में सबसे बड़ी एकल कमी है जो हमने देखी है।

हैश-आधारित लाइन पहचान

लाइन नंबर AI-संचालित संपादन के लिए एक भयानक पहचानकर्ता हैं। वे शिफ्ट होते हैं। AI 500-लाइन की फ़ाइल पढ़ता है, लाइन 142-156 को संपादित करने की योजना बनाता है, लेकिन पिछले संपादन ने लाइन 80 पर चार लाइनें डालीं। अब लक्ष्य 146-160 पर है। AI यह नहीं जानता जब तक कि वह फ़ाइल को फिर से नहीं पढ़ता — जो वह नहीं कर सकता है।

Octofs एक विकल्प प्रदान करता है: हैश-आधारित लाइन पहचानकर्ता। प्रत्येक लाइन को उसकी स्थिति और सामग्री से प्राप्त 4-अक्षर का हेक्स हैश मिलता है। लाइन नंबरों के विपरीत, हैश संपादन के दौरान स्थिर रहते हैं — एक लाइन का हैश इसलिए नहीं बदलता क्योंकि उसके ऊपर एक और लाइन डाली गई थी। AI लाइनों को हैश द्वारा संदर्भित कर सकता है, और कई संपादनों के बाद भी, वे संदर्भ मान्य रहते हैं।

हैश एल्गोरिथम FNV-1a का उपयोग करता है जो 16 बिट्स में मोड़ा गया है, "<position>:<content>" पर कुंजीबद्ध है। डुप्लिकेट लाइनों को संभालने के लिए विशेष रूप से स्थिति शामिल है — विभिन्न स्थानों पर दो समान लाइनें हमेशा अलग हैश प्राप्त करती हैं, बिना किसी टकराव समाधान की आवश्यकता के।

--line-mode hash के साथ इसे सक्षम करें और प्रत्येक टूल प्रतिक्रिया संख्याओं के बजाय हैश लौटाती है। AI उन्हें batch_edit रेंज, view रेंज और डायग्नोस्टिक्स के लिए उपयोग करता है। लाइन-नंबर ड्रिफ्ट एक समस्या बनना बंद हो जाती है।

प्रतिस्थापन सीमाओं पर डुप्लिकेट पहचान

यहाँ एक सूक्ष्म बात है। AI लाइन 100-105 के लिए प्रतिस्थापन की योजना बनाता है। यह अपनी प्रतिस्थापन सामग्री में लाइन 99 (रेंज से पहले की लाइन) को शामिल करता है — इसलिए नहीं कि वह इसे बदलना चाहता है, बल्कि इसलिए कि वह "संदर्भ प्रदान कर रहा है।" अब लाइन 99 दो बार दिखाई देती है। यदि यह एक क्लोज़िंग ब्रेस या खाली लाइन है, तो शायद कोई नुकसान नहीं। यदि यह वास्तविक कोड है, तो आपके पास एक बग है।

Octofs सीमा डुप्लीकेशन के लिए प्रत्येक प्रतिस्थापन की जाँच करता है। यह प्रतिस्थापन की पहली लाइन की तुलना लक्ष्य रेंज से ठीक पहले की लाइन से करता है, और अंतिम लाइन की तुलना बाद की लाइन से। यदि कोई मेल खाता है, तो यह संपादन को एक विशिष्ट संदेश के साथ अस्वीकार कर देता है: "ऑपरेशन 2 में डुप्लिकेट लाइन का पता चला: सामग्री की पहली लाइन लाइन 99 (प्रतिस्थापन रेंज [100-105] से ठीक पहले) से मेल खाती है। आसपास की अपरिवर्तित लाइनों को शामिल न करें।"

संरचनात्मक शोर — अकेले क्लोज़िंग ब्रेस, खाली लाइनें — इस जाँच से मुक्त हैं। वे वैध रूप से सीमाओं पर दिखाई देते हैं। }); जैसे यौगिक क्लोज़र मुक्त नहीं हैं। वे वास्तविक अर्थपूर्ण अर्थ रखते हैं।

बैच संचालन के लिए संघर्ष पहचान

batch_edit AI को एक फ़ाइल पर परमाणु रूप से कई इंसर्ट और रिप्लेस ऑपरेशन करने देता है। लेकिन क्या होगा यदि दो प्रतिस्थापन ओवरलैप होते हैं? क्या होगा यदि दो इंसर्ट एक ही एंकर लाइन को लक्षित करते हैं?

Octofs फ़ाइल को छूने से पहले प्रत्येक ऑपरेशन को हर दूसरे ऑपरेशन के विरुद्ध मान्य करता है। प्रतिस्थापन-बनाम-प्रतिस्थापन रेंज जो ओवरलैप होती हैं, अस्वीकार कर दी जाती हैं। एक ही एंकर पर इंसर्ट-बनाम-इंसर्ट अस्वीकार कर दिया जाता है (अस्पष्ट क्रम)। इंसर्ट-बनाम-रिप्लेस कभी टकराते नहीं — वे संकल्पनात्मक रूप से अलग स्थानों पर काम करते हैं (एक लाइन के बाद का अंतर बनाम लाइन की सामग्री)।

यदि कोई संघर्ष है, तो त्रुटि संदेश में ऑपरेशन इंडेक्स और शामिल विशिष्ट लाइन रेंज शामिल होती है। AI अपनी योजना को ठीक कर सकता है और पुनः प्रयास कर सकता है। कोई आंशिक भ्रष्टाचार नहीं।

अनडू इतिहास के साथ परमाणु लेखन

प्रत्येक संपादन atomic_write के माध्यम से जाता है: एक ही निर्देशिका में एक अस्थायी फ़ाइल पर लिखें, फिर लक्ष्य पर नाम बदलें। फ़ाइल कभी आंशिक स्थिति में नहीं होती। यदि प्रक्रिया लेखन के बीच में क्रैश हो जाती है, तो मूल बरकरार रहता है। नाम बदलना एकमात्र विनाशकारी चरण है, और यह फ़ाइलसिस्टम स्तर पर परमाणु है।

प्रत्येक लेखन से पहले, Octofs पिछला संस्करण सहेजता है। प्रति फ़ाइल दस अनडू स्तर तक। यदि कोई संपादन गलत हो जाता है, तो AI undo_edit को कॉल कर सकता है और फ़ाइल वापस हो जाती है। कोई मैनुअल git restore नहीं। कोई "उफ़, मुझे ठीक करना होगा जो AI ने अभी किया है।"

शेल दुरुपयोग पहचान

AI के पास शेल पहुँच है। यह आवश्यक है — उसे बिल्ड, टेस्ट, लिंटर चलाने की आवश्यकता है। लेकिन यह कभी-कभी एक फ़ाइल पढ़ने के लिए cat, या टेक्स्ट खोजने के लिए grep, या एक लाइन को संपादित करने के लिए sed का उपयोग करने की भी कोशिश करता है। इन सभी के पास Octofs में समर्पित, बेहतर उपकरण हैं।

जब AI एक शेल कमांड चलाता है जो एक ज्ञात दुरुपयोग पैटर्न से मेल खाता है, Octofs इसका पता लगाता है और अगली टूल प्रतिक्रिया में एक संकेत इंजेक्ट करता है: "फ़ाइलें पढ़ने के लिए view को प्राथमिकता दें (लाइन-नंबर्ड, रेंज का समर्थन करता है)।" AI संकेत देखता है, अपने व्यवहार को समायोजित करता है, और अगली बार सही उपकरण का उपयोग करता है।

गैर-इंटरैक्टिव शेल प्रवर्तन

शेल कमांड stdin=null, एक समर्पित प्रोसेस ग्रुप, और GIT_TERMINAL_PROMPT=0 और PAGER=cat जैसे पर्यावरण चर के साथ चलते हैं। AI दुर्घटनावश एक इंटरैक्टिव प्रॉम्प्ट नहीं बना सकता जो सत्र को लटका दे। Git क्रेडेंशियल नहीं माँगेगा। sudo पासवर्ड नहीं माँगेगा। less आह्वान नहीं होगा। कमांड या तो सफल होती है या विफल होती है — कोई तीसरी स्थिति नहीं।

बंद होने पर, प्रत्येक चालू शेल चाइल्ड के प्रोसेस ग्रुप को SIGKILL के साथ मारा जाता है। कोई अनाथ प्रक्रिया नहीं। कोई ज़ोंबी शेल मेमोरी खाते हुए नहीं।

वर्तमान स्थिति: 0.4.0

Octofs 0.4.0 एक रिलीज़ घोषणा नहीं है — यह वही है जहाँ परियोजना अभी है, और यह भरोसा करने के लिए पर्याप्त स्थिर है। वर्तमान संस्करण क्या प्रदान करता है:

मल्टी-रेंज फ़ाइल दृश्य। एक ही कॉल में किसी फ़ाइल के गैर-निकटवर्ती खंडों को पढ़ें — [[1, 50], [200, 250], [400, 430]] — तीन अलग-अलग अनुरोधों के बजाय। कम राउंड ट्रिप। कम संदर्भ बर्बादी।

संरचित लाइन रेंज प्रकार। लाइन रेंज अब उचित सत्यापन के साथ प्रथम-श्रेणी के प्रकार हैं — कच्चे JSON सरणी नहीं जिन्हें AI को सही ढंग से प्रारूपित करना है। सर्वर कुछ भी करने से पहले आकार, सीमाओं और गिनती को मान्य करता है।

गैर-इंटरैक्टिव शेल प्रवर्तन। शेल कमांड गारंटीकृत गैर-इंटरैक्टिव हैं। अब कोई हैंगिंग प्रॉम्प्ट नहीं, कोई क्रेडेंशियल डायलॉग नहीं, कोई पेजर-आह्वानित कचरा आउटपुट नहीं।

सीमा से बाहर क्लैम्पिंग। फ़ाइल लंबाई से अधिक लाइन रेंज क्लैम्प किए जाते हैं, अस्वीकार नहीं किए जाते। AI 200-लाइन की फ़ाइल में लाइन 1-1000 माँगता है? उसे लाइन 1-200 मिलती हैं। कोई त्रुटि नहीं। कोई पुनः प्रयास नहीं।

मल्टी-फ़ाइल दृश्यों में प्रति-फ़ाइल लाइन रेंज। एक साथ कई फ़ाइलें देखते समय, प्रत्येक फ़ाइल की अपनी लाइन रेंज हो सकती है। paths: ["a.rs", "b.rs", "c.rs"] के साथ lines: [[1,50], null, [10,30]] — पहली फ़ाइल 1-50 दिखाती है, दूसरी सब कुछ दिखाती है, तीसरी 10-30 दिखाती है।

कैनोनिकलाइज़्ड फ़ाइल लॉकिंग। फ़ाइल लॉक कैनोनिकलाइज़्ड पथों का उपयोग करते हैं, इसलिए ./src/main.rs, src/main.rs, और /absolute/path/to/src/main.rs सभी एक ही लॉक में हल होते हैं। पथ अलियासिंग से कोई समवर्ती-लेखन भ्रष्टाचार नहीं।

शुद्ध-Rust खोज। सामग्री खोज अब ripgrep को शेल आउट नहीं करती है। यह एक शुद्ध-Rust कार्यान्वयन है जो पर्याप्त तेज़ है, इसकी शून्य बाहरी निर्भरताएँ हैं, और हर प्लेटफ़ॉर्म पर समान रूप से काम करती है।

उपकरण

Octofs सात MCP उपकरण उजागर करता है:

उपकरण	यह क्या करता है
view	फ़ाइलें पढ़ता है, निर्देशिकाओं को सूचीबद्ध करता है, सामग्री खोजता है। मल्टी-फ़ाइल, मल्टी-रेंज, हैश-आधारित लाइन ID, संदर्भ लाइनों के साथ सामग्री खोज का समर्थन करता है
text_editor	फ़ाइलें बनाता है, प्रगतिशील मिलान के साथ पाठ बदलता है, संपादन पूर्ववत करता है
batch_edit	एक ही फ़ाइल पर कई परमाणु इंसर्ट/रिप्लेस ऑपरेशन, संघर्ष पहचान के साथ
extract_lines	एक फ़ाइल से दूसरी फ़ाइल में लाइन रेंज कॉपी करता है
shell	पृष्ठभूमि समर्थन, दुरुपयोग पहचान, गैर-इंटरैक्टिव प्रवर्तन के साथ कमांड निष्पादित करता है
workdir	कार्यशील निर्देशिका संदर्भ का प्रबंधन करता है

सभी उपकरण STDIO और Streamable HTTP ट्रांसपोर्ट दोनों का समर्थन करते हैं। सभी उपकरण निर्देशिका ट्रैवर्सल के दौरान gitignore-जागरूक हैं। सभी उपकरण लाइन-नंबर्ड (या हैश-पहचानित) आउटपुट के साथ प्रतिक्रिया देते हैं ताकि AI के पास बाद के संचालन के लिए स्थिर संदर्भ हों।

यह कैसे फिट होता है: Octomind + Octofs

Octofs किसी भी MCP-संगत क्लाइंट के साथ काम करता है — Claude Desktop, Cursor, Windsurf, Zed। लेकिन यह Octomind के लिए डिज़ाइन किया गया है।

Octomind के एजेंट आपके कोडबेस को पढ़ते हैं, परिवर्तनों की योजना बनाते हैं, और Octofs के माध्यम से संपादन निष्पादित करते हैं। Octobrain — हमारा मेमोरी सर्वर — एजेंट सत्र के दौरान जो सीखता है उसे संग्रहीत करता है। Octolib हर LLM कॉल को संभालता है। साथ में वे AI-संचालित विकास के लिए एक पूर्ण स्टैक हैं:

• Octolib AI मॉडल से बात करता है
• Octobrain सत्रों के बीच याद रखता है
• Octofs आपकी फ़ाइलों को सुरक्षित रूप से छूता है
• Octomind सब कुछ ऑर्केस्ट्रेट करता है

प्रत्येक टुकड़ा ओपन सोर्स है। प्रत्येक टुकड़ा अकेले काम करता है। साथ में वे एक AI एजेंट को कोडबेस तक विश्वसनीय, सुरक्षित पहुँच देने की समस्या को हल करते हैं।

ओपन सोर्स, Rust-नेटिव

Octofs Apache-2.0 के तहत GitHub पर है। यह Rust में बनाया गया है — इसलिए नहीं कि हम प्रदर्शन को फेटिशाइज़ करते हैं, बल्कि इसलिए कि फ़ाइल संचालन कंपाइल-टाइम शुद्धता, ज़ीरो-कॉस्ट async, और कोई गारबेज कलेक्शन पॉज़ नहीं से लाभान्वित होते हैं। बाइनरी छोटी, तेज़ है, और OS के अलावा शून्य रनटाइम निर्भरताएँ हैं।

# स्रोत से बनाएँ (Rust 1.95+ की आवश्यकता है)
git clone https://github.com/muvon/octofs
cd octofs && cargo build --release

# या GitHub Releases से प्री-बिल्ट बाइनरी डाउनलोड करें

अपने Claude Desktop कॉन्फ़िग में जोड़ें:

{
	"mcpServers": {
		"octofs": {
			"command": "/path/to/octofs",
			"args": ["--line-mode", "hash"]
		}
	}
}

किसी भी एजेंट के लिए हैश मोड का उपयोग करें जो मल्टी-स्टेप संपादन करता है। स्थिर लाइन संदर्भ विफलताओं की एक पूरी श्रेणी को समाप्त कर देते हैं।

FAQ

Octofs क्या है?

Octofs Rust में एक ओपन-सोर्स MCP फ़ाइलसिस्टम सर्वर है। यह AI एजेंटों को फ़ाइलें पढ़ने, संपादित करने, खोजने और बनाने के लिए सुरक्षित, विश्वसनीय पहुँच देता है — कोड संपादित करते समय AI मॉडल जो विफलता मोड प्रदर्शित करते हैं उनके खिलाफ अंतर्निहित सुरक्षा के साथ।

Octofs के साथ कौन से AI क्लाइंट काम करते हैं?

कोई भी MCP-संगत क्लाइंट: Claude Desktop, Cursor, Windsurf, Zed, और ओपन-सोर्स Octomind एजेंट रनटाइम।

Octofs AI कल्पनाओं को फ़ाइलों को तोड़ने से कैसे रोकता है?

पाँच परतें: (1) str_replace के लिए तीन-चरण प्रगतिशील मिलान, (2) हैश-आधारित लाइन ID जो संपादन से बच जाते हैं, (3) प्रतिस्थापन सीमाओं पर डुप्लिकेट पहचान, (4) बैच संचालन के लिए संघर्ष पहचान, (5) प्रति फ़ाइल 10 अनडू स्तरों तक के साथ परमाणु लेखन।

हैश-आधारित लाइन ID क्या हैं?

प्रत्येक लाइन को उसकी सामग्री और स्थिति से प्राप्त 4-अक्षर का हेक्स हैश मिलता है (FNV-1a 16 बिट्स में मोड़ा गया)। लाइन नंबरों के विपरीत, हैश संपादन के दौरान स्थिर रहते हैं — एक लाइन का हैश शिफ्ट नहीं होता जब इसके ऊपर अन्य लाइनें डाली जाती हैं। --line-mode hash के साथ सक्षम करें।

Octofs संदर्भ MCP फ़ाइलसिस्टम सर्वर से कैसे अलग है?

संदर्भ सर्वर सीधा फ़ाइल I/O करता है। Octofs ऑटो-इंडेंटेशन के साथ फ़ज़ी मिलान, हैश ID, सीमा डुप्लिकेट पहचान, बैच संघर्ष जाँच, परमाणु लेखन, अनडू इतिहास, शेल दुरुपयोग पहचान, और गैर-इंटरैक्टिव शेल प्रवर्तन जोड़ता है। विशेष रूप से उन विफलता मोड के लिए बनाया गया है जो AI एजेंट पैमाने पर उत्पन्न करते हैं।

क्या Octofs प्रोडक्शन-रेडी है?

हाँ। 0.4.0 स्थिर है और Octomind के अंदर दैनिक उपयोग किया जाता है। Apache-2.0, एकल Rust बाइनरी, OS से परे शून्य रनटाइम निर्भरताएँ। परमाणु लेखन गारंटी देता है कि फ़ाइलें कभी आंशिक स्थिति में समाप्त नहीं होतीं।

क्या यह STDIO और HTTP दोनों का समर्थन करता है?

हाँ। डेस्कटॉप क्लाइंट (Claude, Cursor, आदि) के लिए STDIO ट्रांसपोर्ट और रिमोट एजेंटों के लिए Streamable HTTP।

आगे क्या है

हम स्मार्ट डायग्नोस्टिक्स पर काम कर रहे हैं — जब एक संपादन विफल होता है, Octofs को सिर्फ़ AI को बताना नहीं चाहिए कि क्या गलत हुआ। उसे फिक्स का सुझाव देना चाहिए। हम पैटर्न-आधारित संपादन सत्यापन का भी अन्वेषण कर रहे हैं: यदि AI एक Rust फ़ंक्शन संपादित कर रहा है, तो Octofs जाँच कर सकता है कि परिणाम लिखने से पहले अभी भी वैध Rust के रूप में पार्स होता है।

फ़ाइल सर्वर AI एजेंट स्टैक का रोमांचक हिस्सा नहीं है। यह वह हिस्सा है जिसे हर बार पूरी तरह से काम करना चाहिए, अन्यथा बाकी सब कुछ गिर जाता है। यही वह आवश्यकता है जिसके आसपास Octofs बनाया गया है — और यदि आप इसमें गहराई से जाना चाहते हैं तो यह Apache-2.0 के तहत GitHub पर ओपन सोर्स है।