AOCI-CODE

AOCI-CODE

आपके पूरे कोडबेस का एक स्थायी, Git-संस्करणित नक्शा — जिसे आपका कोडिंग एजेंट लिखता है और एक स्थानीय MCP सर्वर द्वारा नियंत्रित किया जाता है। एजेंट इसे एक बार पढ़ते हैं और सिस्टम को जान जाते हैं, बजाय हर कार्य पर रेपो को दोबारा पढ़ने के।

🇺🇸 English | 🇨🇳 简体中文

यह क्या करता है

बड़े सिस्टम बनाएँ बिना सूत्र खोए। Codex, Claude Code, Cursor, OpenCode और इसी तरह के एजेंट्स में, आपका एजेंट हर कार्य शुरू करते समय पहले से ही पूरे सिस्टम को जानता है: प्रत्येक फ़ाइल किस लिए है, वह किस पर निर्भर है, और क्या टूटना नहीं चाहिए। यह हर अनुरोध के लिए कोडबेस को खोजना और दोबारा पढ़ना बंद कर देता है। जो लोग पेशेवर डेवलपर नहीं हैं, वे अपने सिस्टम पर निरंतर काम कर सकते हैं; पेशेवर डेवलपर पूरे सिस्टम को एजेंट को सौंप सकते हैं और अपना ध्यान आर्किटेक्चर और डिज़ाइन पर बनाए रख सकते हैं।

एक ही कदम में मौजूदा सिस्टम को संभालें। एजेंट को लगभग 500,000 पंक्तियों तक के मौजूदा कोडबेस की ओर इंगित करें और उसे इंडेक्स बनाने के लिए कहें। यह बताता है कि वह प्रत्येक क्षेत्र को कितनी अच्छी तरह जानता है, और फिर वहाँ से विकास शुरू करता है। व्यावहारिक सीमा इंडेक्स का आकार है, पंक्तियों की संख्या नहीं: आज इस तरह से एक 700,000-पंक्ति वाले व्यावसायिक सिस्टम का विकास किया जा रहा है, जिसका इंडेक्स लगभग 300K टोकन का है।

लोग, एजेंट या बातचीत बदलें बिना शुरू से शुरू किए। इंडेक्स कोड के साथ रेपो में रहता है और Git द्वारा संस्करणित होता है। जब कोई प्रोजेक्ट हाथ बदलता है, एजेंट बदलता है, या नई बातचीत खुलती है, तो इंडेक्स को एक बार पढ़ने से वहाँ से काम शुरू हो जाता है जहाँ छोड़ा गया था।

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

यह कैसा दिखता है

वास्तविक स्रोत से मॉडल द्वारा लिखी गई, प्रति फ़ाइल एक पंक्ति। यह इस रेपो के अपने इंडेक्स से एक वास्तविक प्रविष्टि है:

atomic.go[CG9L]: F:Provides durable replace CAS, create CAS, atomic writes, and no-clobber recovery moves | R:code:internal/fs/atomic_exchange_linux.go,code:internal/fs/atomic_exchange_windows.go,code:internal/fs/lock.go | A:AtomicWrite,AtomicWriteCAS,AtomicCreateCAS,AtomicMoveCAS | S:Native publication never degrades to an overwriting rename; on a race, unsafe type, or unverifiable bytes, preserve third-party state

F वह है जिसके लिए फ़ाइल ज़िम्मेदार है, R वह है जिसे आपको इसके साथ पढ़ना है, A वह है जिस पर कॉलर निर्भर करते हैं, और S वह है जिसे आप कोड से अनुमान नहीं लगा सकते लेकिन गलत नहीं होना चाहिए। टैग [CG9L] फ़ाइल को परत, डोमेन, महत्व और आकार के अनुसार रखता है। इस तरह की कुछ सौ पंक्तियाँ पूरे सिस्टम को कवर करती हैं, और एक एजेंट उन्हें एक ही पास में पढ़ सकता है। प्रविष्टि प्रारूप प्रत्येक फ़ील्ड की व्याख्या करता है।

यह CodeGraph से कैसे अलग है?

• CodeGraph आपके कोड को प्रतीकों और कॉलों के ग्राफ़ में पार्स करता है। जब एजेंट कोई प्रश्न पूछता है, तो यह सटीक स्रोत और कॉल पथ लौटाता है। यह वर्तमान कार्य के लिए एक सटीक लुकअप टूल है।
• AOCI-CODE में मॉडल प्रति फ़ाइल और तालिका एक पंक्ति लिखता है: वह किस लिए है, वह किससे जुड़ता है, और क्या टूटना नहीं चाहिए। एजेंट पहले पूरा इंडेक्स पढ़ता है, इसलिए कार्य शुरू होने से पहले वह सिस्टम को जान जाता है। इंडेक्स Git में रहता है और कोड के साथ तालमेल में रखा जाता है।
• दोनों का उपयोग करें: सिस्टम को जानने के लिए इंडेक्स, और काम करते समय सटीक कोड लाने के लिए CodeGraph।

पूरी तुलना में RAG, LSP और रेपो मैप्स भी शामिल हैं।

क्या अपेक्षा करें

पहला इंडेक्स कुछ समय लेता है। एजेंट प्रत्येक प्रबंधित फ़ाइल पढ़ता है और प्रति फ़ाइल एक प्रविष्टि लिखता है: लगभग 200,000 पंक्तियों के कोड के लिए एक घंटा, जो मॉडल और एजेंट की गति पर निर्भर करता है। यह बैचों में चलता है और बाधित होने पर जहाँ रुका था वहीं से फिर शुरू होता है।

डेटाबेस है? उसे भी इंडेक्स करें। MySQL और PostgreSQL समर्थित हैं, और बाधाओं के साथ openGauss 6.0.5। MySQL का अर्थ है 5.7.6 और उसके बाद; MariaDB समर्थित नहीं है। पहले कोड इंडेक्स बनाएँ, फिर डेटाबेस इंडेक्स। कोड और तालिका-स्तरीय ज्ञान एक साथ मिलने पर, एजेंट सिस्टम को अधिक पूर्ण रूप से समझता है।

केवल स्थानीय: आपके सिस्टम पर केवल-पढ़ने, कोई इंटरनेट नहीं, कोई संग्रहीत क्रेडेंशियल नहीं। AOCI-CODE आपके स्रोत कोड और डेटाबेस तालिका संरचनाओं को पढ़ता है, कभी भी व्यावसायिक डेटा नहीं। यह अपनी इंडेक्स फ़ाइलें और अपनी स्थिति प्रोजेक्ट निर्देशिका के भीतर लिखता है, साथ ही आपकी उपयोगकर्ता कैश निर्देशिका में स्टेटस पेज का पंजीकरण। यह कभी इंटरनेट तक नहीं पहुँचता और कुछ भी अपलोड नहीं करता: इसके द्वारा खोले जाने वाले एकमात्र कनेक्शन आपके द्वारा घोषित डेटाबेस से, कैटलॉग मेटाडेटा के लिए, और इसके अपने लूपबैक स्टेटस पेज से हैं। डेटाबेस क्रेडेंशियल पर्यावरण-चर नाम द्वारा संदर्भित होते हैं और कभी संग्रहीत नहीं होते। इंडेक्स टेक्स्ट आपके अपने एजेंट द्वारा स्थानीय रूप से उस मॉडल चैनल के माध्यम से लिखा जाता है जिसका आप पहले से उपयोग करते हैं; AOCI-CODE कोई नया डेटा निकास नहीं जोड़ता।

त्वरित शुरुआत

अपने एजेंट को AOCI-CODE डाउनलोड करने और इसे वायर करने के लिए निम्नलिखित निर्देश दें। एजेंट को पुनः आरंभ करने के बाद, इंडेक्स बनाने के लिए दूसरा निर्देश भेजें।

AOCI-CODE project: https://github.com/aoci-spec/aoci-code

Download the latest release package for this operating system and CPU architecture from
https://github.com/aoci-spec/aoci-code/releases, and follow the installation instructions
on the Release page to verify it. If no compatible release package exists, or if I
explicitly request the latest source, build it from the official repository.

After extracting the package, place aoci (aoci.exe on Windows) at a stable absolute path.
Then use that absolute path to do the following for my project:

1. Run init to initialize AOCI and integrate MCP for the current host; if this host does
   not write project configuration (Cursor, for example), give me the configuration I
   need to paste myself
2. Run scan

   scan takes its file inventory from Git, so do not add the cognition assets
   init writes (aoci.txt, aoci.meta.txt, aoci.code.txt, AGENTS.md) to .gitignore
   or .git/info/exclude — an ignored asset is silently skipped and the index
   cannot be built. Leave the host-config ignore init writes for itself as it is.

3. Tell me to restart the agent so the newly written MCP server takes effect

Stop after those three steps and do not build the index yet — I will tell you to continue
after the restart.

एजेंट को पुनः आरंभ करने के बाद, यह भेजें:

First confirm the AOCI MCP server is connected, then build the AOCI index for this project. When it is complete, give me the AOCI panel link.

एजेंट पैनल को पृष्ठभूमि में aoci ui --detach --json के साथ शुरू करता है और आपको लिंक देता है। AOCI पैनल बताता है कि यह क्या दिखाता है और इसके अन्य कमांड क्या हैं।

पुनः आरंभ क्यों: इंडेक्स AOCI के MCP टूल्स के माध्यम से लिखा जाता है, और जिस सत्र ने init चलाया, उसने वह MCP सर्वर लोड नहीं किया है जो init ने अभी लिखा है। एक होस्ट जो MCP सर्वर को गतिशील रूप से लोड करता है, उसे पुनः आरंभ की आवश्यकता नहीं हो सकती; होस्ट एकीकरण बताता है कि कैसे पता लगाएँ।

यदि आपके प्रोजेक्ट में डेटाबेस है (PostgreSQL और MySQL समर्थित हैं, साथ ही बाधाओं वाला openGauss 6.0.5), तो उसे भी इंडेक्स करें। डेटाबेस कॉग्निशन के अंतर्गत वर्णित अनुसार स्रोत घोषित करें, होस्ट पर्यावरण में कनेक्शन-स्ट्रिंग पर्यावरण चर प्रदान करें (AOCI कोई क्रेडेंशियल संग्रहीत नहीं करता), फिर भेजें:

Build the AOCI database index for this project.

यदि संदर्भ संक्षिप्त कर दिया गया है, या आप चाहते हैं कि एजेंट सिस्टम की अपनी तस्वीर फिर से बनाए, तो यह भेजें:

Using only AOCI, establish whole-framework cognition of this project, tell me your mastery of each area as a percentage, and whether you can take over development.

यह कैसे काम करता है

AOCI (AI-Oriented Cognition Infrastructure) विधि और प्रोटोकॉल है: कोडिंग एजेंट्स और सॉफ़्टवेयर सिस्टम के बीच एक परत। मॉडल तर्क करते हैं, एजेंट योजना बनाते और निष्पादित करते हैं, और AOCI सिस्टम का एक अद्यतन विवरण रखता है, जिसमें कोड, कॉन्फ़िगरेशन, परीक्षण और डेटाबेस संरचना शामिल है, ताकि एजेंट कार्य करने से पहले उसे पढ़ सकें। AOCI-CODE यह प्रोजेक्ट है: aoci CLI, MCP सर्वर, और वे इंडेक्स जिन्हें वे बनाए रखते हैं।

AOCI-CODE किसी सिस्टम को समझने और बदलने के लिए वास्तव में जो मायने रखता है, उसे एक सघन, सादे-पाठ इंडेक्स में आसवित करता है जो प्रतीकों और अर्थ को जोड़ता है। जब मॉडल संदर्भ सीमित होता है, तो एजेंट पहले इंडेक्स पढ़ता है, एक ही पास में प्रोजेक्ट की अधिकांश मुख्य जानकारी प्राप्त करता है, और फिर कार्य शुरू करता है। यह बार-बार खोजने और दोबारा सीखने को कम करता है, और यह समझ को कार्यों और सत्रों के पार ले जाता है।

• एकबारगी सारांश नहीं। इंडेक्स सिस्टम के साथ विकसित होता है और प्रोजेक्ट में रहता है, जहाँ आप Git के साथ diff, समीक्षा, संस्करण और रोलबैक कर सकते हैं।
• "फ़ाइलें कहाँ हैं" से अधिक। यह ज़िम्मेदारियाँ, मजबूत संबंध, सार्वजनिक अनुबंध, लेनदेन सीमाएँ, संगतता बाधाएँ, और अन्य चीज़ें रिकॉर्ड करता है जिन्हें कोड संरचना से अनुमान लगाना कठिन है।
• पोर्टेबल। इंडेक्स प्रोजेक्ट के साथ संग्रहीत होता है, किसी मॉडल, एजेंट या सत्र से बंधा नहीं होता। जब तक यह कोड के साथ संरेखित रहता है, कोई भी एजेंट और कोई भी बाद का सत्र इसे बिना शुरू से समझ फिर से बनाए पुनः उपयोग कर सकता है।
• कोड और डेटाबेस एक साथ। मॉडल डेटाबेस तालिकाओं के लिए एक अलग तालिका-स्तरीय इंडेक्स बना सकता है। एक साथ दिए जाने पर, दोनों एजेंट को सिस्टम की अधिक पूर्ण तस्वीर देते हैं।

इंडेक्स प्रोजेक्ट के साथ संग्रहीत शासित सादे-पाठ फ़ाइलों का एक समूह है:

• रूट (aoci.txt) घोषित करता है कि वर्तमान इंडेक्स किससे बना है और यह इसका सक्रियण प्रवेश बिंदु है।
• मेटा (aoci.meta.txt) टैग शब्दकोश, FRAS नियम और लेखन बाधाएँ रखता है।
• कोड (aoci.code.txt) कोड और अन्य रेपो संपत्तियों के लिए मॉडल-लिखित प्रविष्टियाँ रखता है।
• डेटाबेस (aoci.database.txt) डेटाबेस कॉग्निशन सक्षम होने पर वैकल्पिक तालिका-स्तरीय प्रविष्टियाँ रखता है।

रूट, मेटा और भाग लेने वाले ऑब्जेक्ट वॉल्यूम मिलकर Whole-Index बनाते हैं। उनके ऊपर का वर्कफ़्लो तीन चरणों का है:

1. शासन के अंतर्गत इंडेक्स बनाएँ। मॉडल स्रोत कोड और स्वीकृत साक्ष्य पढ़ता है। AOCI-CODE Managed Scope और index भूमिका वाले प्रत्येक प्रबंधित ऑब्जेक्ट के लिए मॉडल द्वारा लिखी गई प्रविष्टियों को नियंत्रित करता है।
2. कार्य करने से पहले पढ़ें। एजेंट प्रोजेक्ट नियम, लाइव गाइड और वर्तमान Whole-Index पढ़ता है, फिर हाथ में मौजूद कार्य के लिए स्रोत और अन्य साक्ष्य जाँचता है।
3. सत्यापित परिवर्तन के बाद रखरखाव। एक बार कोड और परीक्षण स्थिर हो जाने पर, प्रोजेक्ट नियम और MCP वर्कफ़्लो एजेंट से प्रभावित प्रविष्टियों को अद्यतन करवाते हैं और इंडेक्स को aligned पर वापस लाते हैं।

चूँकि ये फ़ाइलें रेपो में सादा पाठ हैं, Git उन्हें संस्करणित करता है। जब तक इंडेक्स वर्तमान सिस्टम संस्करण के साथ संरेखित रहता है, कोई भी एजेंट और कोई भी बाद का सत्र उसी Whole-Index को पढ़ और पुनः उपयोग कर सकता है।

मैन्युअल एकीकरण

AOCI-CODE को कैनोनिकल स्रोत से प्राप्त करें या GitHub Releases से हस्ताक्षरित पैकेज का उपयोग करें। पहले से बने बाइनरी का उपयोग करने से पहले, इंस्टॉलेशन गाइड में बुनियादी, अनुशंसित या पूर्ण सत्यापन स्तर का पालन करें, और बताएँ कि कौन सा स्तर पूरा हुआ। यह README और सत्यापित बाइनरी का स्थिर निरपेक्ष पथ किसी विश्वसनीय कोडिंग एजेंट को दें, जैसे Codex, Claude Code, Cursor या OpenCode। एजेंट AOCI को आरंभ करने, MCP को एकीकृत करने और पहला इंडेक्स बनाने के लिए प्रोजेक्ट-में-निर्देशों का पालन कर सकता है।

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

आवश्यकताएँ

• एक सत्यापित रिलीज़ पैकेज या कैनोनिकल AOCI-CODE स्रोत रेपो का चेकआउट।
• केवल स्रोत बिल्ड के लिए: go.mod, make द्वारा घोषित Go टूलचेन, और रेपो द्वारा आवश्यक अन्य टूल।
• एक समर्थित MCP होस्ट, जैसे Codex, Claude Code, Cursor या OpenCode।
• लक्ष्य रेपो तक सामान्य पढ़ने और लिखने की पहुँच।

AOCI-CODE MCP होस्ट के साथ एकीकृत होता है, किसी मॉडल-प्रदाता API के साथ नहीं। DeepSeek और अन्य मॉडल AOCI-CODE का उपयोग तब कर सकते हैं जब उन्हें चलाने वाला एजेंट या होस्ट मानक stdio MCP का समर्थन करता हो और टूल अनुबंध का पालन कर सके; केवल मॉडल का नाम संगतता स्थापित नहीं करता।

हस्ताक्षरित-पैकेज मार्ग और निष्पादन योग्य सत्यापन कमांड इंस्टॉलेशन गाइड में हैं। स्रोत-बिल्ड मार्ग नीचे है।

वर्तमान RC: सत्यापित पैकेज का उपयोग करें या स्रोत से बिल्ड करें

[!IMPORTANT] AOCI-CODE v0.1.0-rc22 वर्तमान रिलीज़ कैंडिडेट है। यह FSL-1.1-MIT के अंतर्गत Fair Source/source-available सॉफ़्टवेयर है; देखें LICENSE। रिलीज़ सत्यापन प्रक्रिया का पालन करने के बाद कैनोनिकल स्रोत से बिल्ड करें या v0.1.0-rc22 GitHub Release से हस्ताक्षरित पैकेज का उपयोग करें।

हस्ताक्षरित Release बाइनरी स्वयं को aoci version 0.1.0-rc22 के रूप में पहचानती है। एक स्रोत बिल्ड इसके बजाय सटीक चेकआउट की पहचान करता है और v0.1.0-rc22-1-g<short-commit> जैसा विकास संस्करण (लागू होने पर -dirty के साथ) रिपोर्ट कर सकता है, साथ ही अपना Git कमिट। ये अलग-अलग बिल्ड इनपुट हैं, संस्करण विरोध नहीं।

GitHub CLI के साथ डाउनलोड करने के लिए, पहले प्रमाणित करें, फिर टैग किए गए Release संपत्तियाँ डाउनलोड करें:

gh auth login
gh release download v0.1.0-rc22 --repo aoci-spec/aoci-code

अनाम डाउनलोड के लिए, ब्राउज़र में v0.1.0-rc22 Release पृष्ठ खोलें और आपके द्वारा आवश्यक आर्काइव और सत्यापन संपत्तियाँ डाउनलोड करें।

स्रोत से बिल्ड करने के लिए, कैनोनिकल रेपो को क्लोन करें, बाइनरी बिल्ड करें, और परिणामी पथ को स्थिर रखें:

git clone https://github.com/aoci-spec/aoci-code.git
cd aoci-code
mkdir -p build
make build
./build/aoci --version

Windows पर, PowerShell में वही स्रोत बिल्ड करें:

git clone https://github.com/aoci-spec/aoci-code.git
Set-Location .\aoci-code
New-Item -ItemType Directory -Force .\build | Out-Null
make build
.\build\aoci.exe --version

फिर यह README उस एजेंट को दें जिस पर आप पहले से प्रोजेक्ट के लिए भरोसा करते हैं और पूछें:

Read this AOCI-CODE README and use the built aoci binary at its stable absolute path
to initialize AOCI for the current project, integrate MCP, and run scan. Stop there and
tell me to restart the agent; I will ask you to build the index afterwards.

एजेंट को प्रोजेक्ट रूट की पहचान करनी चाहिए, बिल्ट बाइनरी के लिए एक स्थिर निरपेक्ष पथ का उपयोग करना चाहिए, वर्तमान होस्ट के अनुरूप इनिशियलाइज़ेशन चलाना चाहिए, और स्पष्ट रूप से बताना चाहिए कि होस्ट रीस्टार्ट या वास्तविक मानवीय स्वीकृति कब आवश्यक है। बाइनरी AOCI-CODE चेकआउट में रह सकती है या किसी साझा टूल्स डायरेक्टरी में स्थानांतरित की जा सकती है, बशर्ते MCP कॉन्फ़िगरेशन सही निरपेक्ष पथ की ओर इंगित करे।

मैन्युअल इनिशियलाइज़ेशन

AOCI को स्वयं इनिशियलाइज़ करने के लिए, लक्ष्य रिपॉज़िटरी रूट से निम्नलिखित चलाएँ, या --repo के माध्यम से एक स्पष्ट पथ पास करें:

AOCI=/absolute/path/to/aoci-code/build/aoci
"$AOCI" --repo . init --locale en-US --agent codex
"$AOCI" --repo . scan

init लोकेल कॉन्फ़िगरेशन, प्रबंधित AGENTS.md नियम ब्लॉक, Git सीमाएँ, और एक खाली इंडेक्स स्केलेटन लिखता है। कॉन्फ़िगरेशन और प्रॉम्प्टिंग होस्ट के अनुसार भिन्न होते हैं; देखें होस्ट एकीकरण। यह फ़ाइलनामों, डायरेक्टरियों, या किसी AST से व्यावसायिक अर्थ का आविष्कार नहीं करता।

एक नए रिपॉज़िटरी के लिए, पहला scan प्रबंधित Baseline स्थापित करता है। ऐसे प्रोजेक्ट के लिए जिसमें पहले से ही एक शासित Baseline है, प्रबंधित स्कोप को जोड़ना, हटाना, या बदलना औपचारिक Scope Change वर्कफ़्लो के माध्यम से होता है; scan --force शासन तथ्यों को पुनर्परिभाषित करने का शॉर्टकट नहीं है। --force अनसुलझे ड्रिफ्ट, रसीदें, या रिकवरी सीमाओं को भी मिटा नहीं सकता।

$Aoci = (Resolve-Path "C:\path\to\aoci-code\build\aoci.exe").Path
& $Aoci --repo . init --locale en-US --agent codex
& $Aoci --repo . scan

एजेंट से पहला इंडेक्स बनवाएँ (महत्वपूर्ण)

एक बार इनिशियलाइज़ेशन और scan पूरा हो जाने के बाद, जाँचें कि एजेंट सत्र पहले से ही AOCI टूल्स को उजागर करता है या नहीं; यदि नहीं, तो उसे रीफ़्रेश या रीस्टार्ट करें। फिर लक्ष्य प्रोजेक्ट के लिए एजेंट में निम्नलिखित दर्ज करें:

First confirm the AOCI MCP server is connected, then build the AOCI index for this project. When it is complete, give me the AOCI panel link.

एजेंट aoci ui --detach --json के साथ पैनल को बैकग्राउंड में शुरू करता है और आपको लिंक देता है। AOCI पैनल बताता है कि यह क्या दिखाता है और इसके अन्य कमांड क्या हैं।

होस्ट प्रोजेक्ट के AOCI नियमों और लाइव गाइड को पढ़ता है, स्रोत कोड, परीक्षण, कॉन्फ़िगरेशन, और प्रासंगिक साक्ष्य का निरीक्षण करता है, और फिर प्रत्येक प्रबंधित ऑब्जेक्ट के लिए FRAS उम्मीदवार लिखता है जिसकी भूमिका index है। आपको स्वयं Plan, Stage, Check, Diff, CAS, या Apply को व्यवस्थित करने की आवश्यकता नहीं है।

एक बार पहला इंडेक्स पूरा हो जाने के बाद, सामान्य विकास कार्य सामान्य रूप से भेजें, उदाहरण के लिए:

Add priorities to tasks, including the frontend, backend, database, and test changes.

आपको "अंत में AOCI इंडेक्स बनाए रखें" जोड़ने की आवश्यकता नहीं है। प्रोजेक्ट नियम और MCP एजेंट से कोड और परीक्षण स्थिर हो जाने के बाद एक बार इंडेक्स परिवर्तनों की जाँच करवाते हैं, फिर औपचारिक वर्कफ़्लो के माध्यम से प्रभावित प्रविष्टियों को अपडेट करवाते हैं। जब प्रोजेक्ट automation.mode=auto का उपयोग करता है, तो AOCI-CODE आपको केवल तब बाधित करता है जब वास्तविक मानवीय स्वीकृति आवश्यक हो, कोई बाहरी क्रिया करनी हो, रिकवरी सिद्ध न की जा सके, कोई सुरक्षा जाँच विफल हो, या कोई तृतीय-पक्ष समवर्ती विरोध पाया जाए। अन्य ऑटोमेशन मोड अपने स्वयं के रनटाइम अनुबंधों का पालन करते हैं।

संरेखण सत्यापित करें

ऑनबोर्डिंग पूरी होने के बाद, चलाएँ:

"$AOCI" --repo . verify
"$AOCI" --repo . check

इंडेक्स और वर्तमान प्रबंधित स्रोत को वापस aligned पर अभिसरित होना चाहिए। यदि नहीं होते, तो पहले लाइव गाइड देखें; आंतरिक स्टेट मशीन को रैपर स्क्रिप्ट में दोहराएँ नहीं:

"$AOCI" --repo . index agent guide --agent codex --json

बुनियादी डायग्नोस्टिक्स चलाएँ

"$AOCI" --repo . capabilities
"$AOCI" --repo . doctor

यह पुष्टि करने के लिए कि होस्ट वास्तव में किस AOCI से जुड़ा है, डिस्क पर जो है उसके बजाय सर्वर जो स्वयं के बारे में रिपोर्ट करता है उसे पढ़ें। किसी भी aoci_overview check_only प्रतिक्रिया या किसी भी aoci_maintain प्रतिक्रिया में, cognition_receipt.mcp_service_version चल रहा संस्करण है और runtime_repository_root वह रिपॉज़िटरी है जिसे यह शासित करता है। मेल खाता बाइनरी पथ प्रोजेक्ट के .mcp.json में command है या समतुल्य होस्ट कॉन्फ़िगरेशन में: .codex/config.toml, opencode.json, या .cursor/mcp.json। डिस्क पर बाइट्स बदलने से चल रही MCP प्रक्रिया नहीं बदलती, इसलिए अपग्रेड या रोलबैक के बाद उन तथ्यों के विरुद्ध पुनः जाँच करें।

एक बार के वॉकथ्रू के लिए, रिपॉज़िटरी में examples/minimal-repository का उपयोग करें।

make fast

make full
./build/aoci --version

mkdir -p build
CGO_ENABLED=0 go build -o build/aoci ./cmd/aoci

इनिशियलाइज़ेशन के बाद क्या दिखाई देता है

एक विशिष्ट रिपॉज़िटरी में ये इंडेक्स फ़ाइलें होती हैं:

aoci.txt                    Root: declares the current CognitionSet and participating Volumes
aoci.meta.txt               Meta: tag dictionary, FRAS rules, and authoring constraints
aoci.code.txt               Code: model-authored entries for code and repository assets
aoci.database.txt           Database: optional table-level entries; absent by default
.aoci/
├── config.json             Team policy, Locale, Scope, and budgets
├── baseline.json           Governed Baseline for source, index, and database bindings
├── curation.json           Optional file-level include/exclude decisions
└── ...                     Drafts, Ledger, transactions, and recovery evidence; normally not committed to Git

एक नया प्रोजेक्ट इनिशियलाइज़ करने से Root, Meta, और एक खाली Code Volume बनता है; Database डिफ़ॉल्ट रूप से अनुपस्थित रहता है। AOCI-CODE रिपॉज़िटरी या डेटाबेस के लिए स्वयं व्यावसायिक अर्थ उत्पन्न नहीं करता।

aoci init --agent <name> अतिरिक्त रूप से होस्ट एकीकरण कॉन्फ़िगरेशन लिखता है (.mcp.json, .claude/settings.json, .codex/config.toml, या opencode.json) जिसके कमांड और रिपॉज़िटरी पथ मशीन-बद्ध निरपेक्ष पथ होते हैं। उन फ़ाइलों को रिपॉज़िटरी के .gitignore में जोड़ें और उन्हें कमिट न करें: एक कमिट की गई प्रति हर अन्य मशीन पर टूट जाती है, और चूँकि इंस्टॉलर कुंजी की उपस्थिति से मौजूदा प्रविष्टि का पता लगाते हैं, वहाँ init को फिर से चलाने पर टूटे हुए पथ चुपचाप बने रहते हैं।

एक विकास कार्य कैसे चलता है

नीचे दिए गए दो आरेख वर्कफ़्लो को वैसे दिखाते हैं जैसे आप इसे अनुभव करते हैं, AOCI के आंतरिक कार्यान्वयन के रूप में नहीं।

नया प्रोजेक्ट: पहले एक सरल सिस्टम बनाएँ, फिर AOCI लाएँ

flowchart TD
    I["The user proposes a product idea and requirements"] --> S["Use the agent's existing capabilities to build a simple new system"]
    S --> Q["Integrate AOCI MCP"]
    Q --> V["The agent builds the Whole-Index and verifies aligned"]
    V --> N["The user continues with ordinary development requests"]
    N --> M["The agent completes code, tests, and incremental index maintenance"]
    M --> N

एक नए सिस्टम को कोड की पहली पंक्ति से ही AOCI-CODE की आवश्यकता नहीं होती। पहले एजेंट की मौजूदा क्षमताओं के साथ एक प्रोटोटाइप बनाएँ; लगभग 10,000–30,000 पंक्तियाँ इसे शामिल करने का अच्छा बिंदु है (कोई कठोर सीमा नहीं)। जो टीमें पहले क्रॉस-सेशन निरंतरता चाहती हैं, वे जल्दी एकीकृत कर सकती हैं।

मौजूदा प्रोजेक्ट: रिपॉज़िटरी को इंडेक्स करें, फिर पुनरावृत्ति करें

flowchart TD
    R["Existing repository, tests, configuration, and optional Schema"] --> B["Build AOCI-CODE from canonical source<br/>Request index generation"]
    B --> E["The agent inspects the existing system and writes the first index"]
    E --> V["Verify, Check, and Guide converge to aligned"]
    V --> T["The user submits an ordinary development task"]
    T --> C["The agent modifies code and runs quality checks"]
    C --> U["MCP guides the agent through index maintenance"]
    U --> G["The index and the current system return to aligned"]
    G --> T

पहला इंडेक्स पूरा हो जाने के बाद, दोनों प्रवाह दिन-प्रतिदिन एक ही तरह से काम करते हैं: आप व्यावसायिक या इंजीनियरिंग आवश्यकता का वर्णन करते हैं; एजेंट Whole-Index को वर्तमान साक्ष्य के साथ जोड़ता है, विकास और सत्यापन करता है, और कार्य समाप्त करते समय MCP के माध्यम से बदले गए ऑब्जेक्ट्स को अपडेट करता है। आपको आंतरिक Plan, Stage, Diff, CAS, या Baseline कमांड सीखने की, या हर प्रॉम्प्ट में रखरखाव आवश्यकता दोहराने की आवश्यकता नहीं है।

यदि कोई पूरा बैच किसी भी औपचारिक लेखन के शुरू होने से पहले अस्वीकार कर दिया जाता है, तो इंडेक्स अपरिवर्तित रहता है। यदि औपचारिक लेखन शुरू होने के बाद वर्कफ़्लो बाधित हो जाता है, तो सिस्टम अपरिवर्तनीय इरादे, लेखन साक्ष्य, और रिकवरी स्थिति को बनाए रखता है, फिर या तो सिद्ध पोस्टइमेज से फिर से शुरू करता है या सटीक प्रीइमेज पर रोलबैक करता है। तृतीय-पक्ष बाइट विरोध विफल-बंद होता है; AOCI-CODE "लेखन पूरा करने" के लिए किसी बाहरी संशोधन को कभी अधिलेखित नहीं करता।

अंतिम स्थिति सदैव applied, repair_required, या stopped में से एक होती है। stopped सफलता नहीं है, और इसका यह अर्थ भी नहीं कि कुछ भी नहीं लिखा गया; failed_step, औपचारिक-लेखन साक्ष्य, और गाइड द्वारा लौटाई गई रिकवरी क्रिया का निरीक्षण करें।

कौन क्या करता है: मॉडल और AOCI-CODE

अर्थ का स्वामित्व मॉडल के पास है

होस्ट मॉडल स्रोत कोड, परीक्षण, कॉन्फ़िगरेशन, दस्तावेज़ीकरण, और जो भी साक्ष्य आवश्यक हो उसे पढ़ता है, फिर निर्णय लेता है:

• कोई ऑब्जेक्ट वास्तव में किसके लिए उत्तरदायी है;
• कौन सी फ़ाइलें, मॉड्यूल, या डेटाबेस ऑब्जेक्ट मजबूत संबंध हैं जिन्हें इसे सुरक्षित रूप से बदलने के लिए विचार करना चाहिए;
• यह कौन से API, कमांड, प्रारूप, या प्रेक्षणीय अनुबंध उजागर करता है;
• कौन सी लेनदेन, प्राधिकरण, समवर्तीता, कैशिंग, परिनियोजन, संगतता, या ऐतिहासिक बाधाएँ केवल सामान्य संरचना से अनुमानित नहीं की जा सकतीं।

AOCI-CODE फ़ाइलनामों, पथों, एक्सटेंशनों, ASTs, या टेम्पलेट्स से FRAS को नहीं जोड़ता, और यह मॉडल द्वारा लिखे गए को चुपचाप पुनः नहीं लिखता।

शासन का स्वामित्व AOCI-CODE के पास है

AOCI-CODE निम्नलिखित के लिए उत्तरदायी है:

1. Safe Inventory, Managed Scope, और वर्तमान Baseline स्थापित करना;
2. वर्तमान Whole-Index प्रदान करना और उसकी पहचान की पुष्टि करना;
3. एक नियतात्मक योजना, लक्ष्य सेट, और स्रोत SHA-256 मान उत्पन्न करना;
4. उम्मीदवार संरचना, टैग शब्दकोश, संबंध पहचान, स्कोप, स्वामित्व, बजट, और प्रभावित सीमा को मान्य करना;
5. जाँच, diff, और समीक्षा सामग्री के बीच बंधन को संरक्षित करना;
6. क्रॉस-प्रोसेस लॉक, CAS, और परमाणु लेखन के साथ एक पूरा बैच कमिट करना;
7. Baseline को आगे बढ़ाना, लेजर जोड़ना, और लेखन-पश्चात विफलता के बाद रिकवरी साक्ष्य संरक्षित करना;
8. Verify, Check, और गाइड के माध्यम से वर्तमान शासन स्थिति को फिर से सिद्ध करना;
9. दूसरा सत्य-स्रोत बनाए बिना आधिकारिक संपत्तियों से Lineage, Relations, Impact, Snapshot, और Evolution अवलोकन प्राप्त करना।

सभी-हरा मशीन परिणाम केवल यह अर्थ देते हैं कि एन्कोडेड संरचनात्मक और शासन अनुबंध लागू हैं; इनका यह अर्थ नहीं कि मॉडल द्वारा लिखा गया प्रत्येक कथन सही है।

इंडेक्स कैसे संगठित होता है

एक AOCI इंडेक्स की दो परतें होती हैं: इंडेक्स नियम और इंडेक्स प्रविष्टियाँ। उत्पाद दो भौतिक लेआउट का समर्थन करता है, और वे एक फ़ाइल प्रारूप नहीं हैं।

Volumes v1 लेआउट

एक Volumes प्रोजेक्ट उत्तरदायित्वों को अलग करता है:

• aoci.txt केवल Root है। यह उन Volumes की घोषणा करता है जो वर्तमान CognitionSet में भाग लेते हैं।
• aoci.meta.txt में Meta होता है: टैग शब्दकोश, FRAS नियम, बजट, और लेखन अनुबंध।
• aoci.code.txt में कोड ऑब्जेक्ट्स की प्रविष्टियाँ होती हैं।
• aoci.database.txt में डेटाबेस ऑब्जेक्ट्स की प्रविष्टियाँ होती हैं जब Database Cognition सक्षम होता है।

Code और Database Volumes समान FRAS पंक्ति संरचना साझा करते हैं, लेकिन उनकी स्वतंत्र ऑब्जेक्ट पहचान, साक्ष्य बंधन, स्वामित्व, और जीवनचक्र होते हैं। Root, Meta, और ऑब्जेक्ट Volumes मिलकर Whole-Index बनाते हैं; केवल aoci.txt Root पढ़ना यह दावा करने के लिए पर्याप्त नहीं है कि आपने पूरा सिस्टम पढ़ लिया है।

इसे एक मानचित्र की तरह सोचें:

• इंडेक्स नियम मानचित्र के लेजेंड और समन्वय प्रणाली हैं।
• इंडेक्स प्रविष्टियाँ वे मार्कर हैं जो प्रत्येक स्थान का वर्णन करते हैं।
• Root वर्तमान मानचित्र सेट के लिए कैटलॉग और संस्करण प्रवेश बिंदु है।
• एक Volume एक अलग शीट है जो उसी प्रोटोकॉल द्वारा शासित है लेकिन उसका अपना साक्ष्य स्रोत और जीवनचक्र है।

इंडेक्स हेडर कैसा दिखता है

Root और Meta प्रत्येक मशीन-पठित हेडर पंक्तियों के साथ खुलते हैं। यह वही है जो aoci init एक नए en-US प्रोजेक्ट के लिए लिखता है जिसका नाम my-service है, Root से शुरू करते हुए, जो सक्रियण प्रवेश बिंदु है:

#AOCI-ROOT-MANIFEST: 1
#Format-Version: cognition-volumes/v1
#Locale: en-US
#Project: my-service
#Global-Invariants: -
#Volume: id=meta kind=meta path=aoci.meta.txt format=meta-v1 depends=- state=enabled
#Volume: id=code kind=code path=aoci.code.txt format=object-fras-v2 depends=meta state=enabled

प्रत्येक #Volume: पंक्ति एक भाग लेने वाले Volume को उसकी पहचान, प्रकार, पथ, प्रारूप, निर्भरता, और सक्रियण स्थिति के साथ घोषित करती है। यहाँ घोषित न किया गया Volume वर्तमान CognitionSet का भाग नहीं है, चाहे कार्यशील ट्री में और कुछ भी हो। Database Cognition सक्षम करने से एक और पंक्ति जुड़ती है, #Volume: id=database kind=database path=aoci.database.txt format=table-fras-v2 depends=meta state=enabled।

फिर Meta उन नियमों के साथ खुलता है जो प्रत्येक प्रविष्टि को नियंत्रित करते हैं:

#AOCI-META-VOLUME: 1
#Object-Protocol: repository-cognition-object/v2
#FRAS-Discipline: 2
#FRAS-v2-Limits-Authority: machine-contract
#S-Admission: non-inferable-and-error-preventing
#S quota: C9-8≤600 C7-4≤200 C3-1≤50
#Object-Kinds: code=file database=table

#FRAS-v2-Limits-Authority: machine-contract भार-वहन करने वाली पंक्ति है: फ़ील्ड सीमाएँ बाइनरी की हैं, इस पाठ की नहीं, इसलिए कोई प्रोजेक्ट अपने स्वयं के Meta को संपादित करके उन्हें नहीं बढ़ा सकता। #S-Admission और #S quota विशेष रूप से S फ़ील्ड को नियंत्रित करते हैं: वहाँ आख़िर क्या दर्ज किया जा सकता है, और प्रत्येक महत्व बैंड कितने अक्षर खर्च कर सकता है। टैग शब्दकोश इन पंक्तियों के ठीक बाद आता है; इसे नीचे पूर्ण रूप में दिखाया गया है।

Code Volume एकल पंक्ति #AOCI-CODE-VOLUME: 1 के साथ खुलता है, और उसके बाद सब कुछ डायरेक्टरी अनुभाग और प्रविष्टियाँ हैं।

ये वे मान हैं जिनसे एक नया प्रोजेक्ट शुरू होता है, न कि निश्चित प्रोटोकॉल स्थिरांक। इसके बाद प्रत्येक रिपॉज़िटरी का अपना Root और Meta आधिकारिक होता है: एक पुराना प्रोजेक्ट कस्टम टैग शब्दकोश रख सकता है, और --locale zh-CN के साथ इनिशियलाइज़ किया गया प्रोजेक्ट #Locale: zh-CN लिखता है और तदनुसार #S quota: कुंजी को स्थानीयकृत करता है।

इंडेक्स नियम क्या परिभाषित करते हैं

Volumes v1 में, प्रोजेक्ट का Meta Volume इन नियमों को संग्रहीत करता है; Legacy लेआउट में, ये मोनोलिथिक हेडर में रहते हैं। प्रोजेक्ट भिन्न टैग शब्दकोशों का उपयोग कर सकते हैं, जबकि मूल FRAS संरचना वही रहती है।

यह README केवल यह समझाता है कि इन नियमों को कैसे पढ़ा जाए। ठोस, निष्पादन योग्य नियमों के लिए, वर्तमान प्रोजेक्ट के Meta या Legacy हेडर, AOCI गाइड और औपचारिक विनिर्देश पर निर्भर रहें।

एक प्रविष्टि क्या दर्ज करती है (FRAS)

नियम स्थापित होने के बाद, मॉडल index भूमिका वाले प्रत्येक प्रबंधित ऑब्जेक्ट के लिए एक प्रविष्टि लिखता है। observe भूमिका केवल परिवर्तन अवलोकन में भाग लेती है, और exclude भूमिका उन चीज़ों को चिह्नित करती है जिन्हें जानबूझकर छोड़ा गया है; इनमें से कोई भी औपचारिक प्रविष्टि का स्वामी नहीं है। AOCI एक प्रविष्टि में सबसे महत्वपूर्ण चार प्रकार की सूचनाओं को व्यवस्थित करने के लिए FRAS का उपयोग करता है:

• F — Function: ऑब्जेक्ट किसके लिए जिम्मेदार है।
• R — Relations: किन अन्य ऑब्जेक्ट्स पर भी विचार करना आवश्यक है ताकि इसे समझा या सुरक्षित रूप से बदला जा सके।
• A — API: यह कौन से इंटरफ़ेस, कमांड, प्रारूप या अवलोकनीय अनुबंध उजागर करता है।
• S — Non-obvious constraints: महत्वपूर्ण जानकारी जो F, R और A कवर नहीं करते, लेकिन ऑब्जेक्ट को सुरक्षित रूप से समझने या बदलने के लिए आवश्यक है, जैसे प्रमुख बाधाएँ, अपवाद, सीमाएँ और विशेष अर्थशास्त्र। S को पहले तीन फ़ील्ड को दोहराना नहीं चाहिए।

उदाहरण के लिए, ===.../internal/fs/=== निर्देशिका अनुभाग के अंदर, एक प्रविष्टि बेसनेम का उपयोग करती है:

atomic.go[CG9L]: F:Provides durable replace CAS, create CAS, atomic writes, and no-clobber recovery moves | R:code:internal/fs/atomic_exchange_linux.go,code:internal/fs/atomic_exchange_windows.go,code:internal/fs/lock.go | A:AtomicWrite,AtomicWriteCAS,AtomicCreateCAS,AtomicMoveCAS | S:Native publication never degrades to an overwriting rename; on a race, unsafe type, or unverifiable bytes, preserve third-party state 

निर्देशिका अनुभाग और बेसनेम एक कोड ऑब्जेक्ट पहचान में हल होते हैं। क्रॉस-Volume या सिस्टम प्रोजेक्शन के लिए, यह code:internal/fs/atomic.go जैसी विहित पहचान में विस्तारित होता है। एक डेटाबेस ऑब्जेक्ट अपनी स्वयं की विहित पहचान का उपयोग करता है, जैसे database://primary/public/orders।

प्रविष्टि के दो भाग होते हैं:

atomic.go [CG9L]
└─ object ─┘ └ tags ┘

F: Core responsibility
R: Strong relationships that must be understood together
A: External interface or contract
S: Important additional information beyond F, R, and A

संक्षिप्त टैग प्रत्येक ऑब्जेक्ट को आर्किटेक्चरल परत, कार्यात्मक डोमेन, महत्व, वैकल्पिक तकनीकी विशेषताओं और आकार के लिए निर्देशांक देते हैं। टैग शब्दकोश प्रोजेक्ट के Meta Volume या Legacy हेडर द्वारा परिभाषित किया जाता है। प्रोग्राम शब्दकोश और संरचना को मान्य करता है; यह व्यावसायिक अर्थ का निर्णय नहीं करता।

S कोई सारांश, सामान्य सारांश या F, R और A की पुनरावृत्ति नहीं है। यह पहले तीन फ़ील्ड द्वारा कवर न की गई महत्वपूर्ण जानकारी जोड़ता है जो समझ या इंजीनियरिंग शुद्धता को प्रभावित करती है, उदाहरण के लिए:

• Redis एक्सेस विफलता को डेटाबेस पर फ़ॉलबैक होना चाहिए;
• एक विशेष तालिका को AutoMigrate में प्रवेश नहीं करना चाहिए;
• एक लीगेसी संगतता शाखा को सामान्य सफ़ाई द्वारा हटाया नहीं जाना चाहिए;
• लेखन विफलता के बाद मूल फ़ाइल को संरक्षित रखना चाहिए।

मॉडल इसे वास्तविक स्रोत कोड और साक्ष्य से लिखता है। AOCI-CODE प्रविष्टि की संरचना को मान्य करता है, इसे स्रोत फ़ाइल से बांधता है, और यह नियंत्रित करता है कि यह औपचारिक इंडेक्स में कैसे प्रवेश करती है।

स्टार्टर टैग शब्दकोश पढ़ना

निम्नलिखित अंश वर्तमान en-US Volume Meta टेम्पलेट (textassets/en-US/templates/volume-meta.txt.tmpl) से शब्दशः कॉपी किया गया है। यह एक स्टार्टर शब्दकोश है, सार्वभौमिक शब्दावली नहीं: प्रत्येक रिपॉज़िटरी का औपचारिक Meta ही अधिकारिक रहता है। स्टार्टर कोई D शब्दकोश घोषित नहीं करता; D एक वैकल्पिक अक्ष बना रहता है और इसका उपयोग केवल तब किया जा सकता है जब वर्तमान औपचारिक Meta इसे घोषित करे।

#Canonical-Tag-Authoring: compact A+B+C+[D]+E; dotted form is read compatibility only
#Code canonical identity example: code:path/to/file.go
#Code Entry example: file.go[EG7T]: F:Runs the example application | R:code:config/load.go | A:main | S:Exits non-zero when the config file is missing; it never falls back to built-in defaults
#[Tag dictionary: code]
#A Layer: C-SharedFoundation E-EntryBoundary A-ApplicationOrchestration D-DomainLogic K-AlgorithmComputation M-Middleware P-Persistence I-IntegrationAdapter R-RuntimeFoundation L-LibrarySDK F-DeclarativeConfiguration O-OperationsDelivery T-TestValidation S-DocumentationSpecification X-DevelopmentTooling Z-Other
#B Module: G-CrossDomain U-UserInteraction B-CoreBusiness D-DataState I-IdentityAccess N-NetworkProtocol M-MessageEvent S-SecurityPrivacy C-ConfigurationPolicy O-Observability R-ReliabilityRecovery P-PerformanceResource W-WorkflowScheduling A-AnalyticsIntelligence H-HardwareDevice L-Localization V-BuildRelease Q-QualityAssurance E-ExtensionPlugin Z-Other
#C Importance: 9-highest 8-very-high 7-high 6-above-average 5-medium 4-below-average 3-low 2-very-low 1-lowest
#E Scale: L-large>400 M-medium200-400 S-small100-200 T-tiny<100
#[Tag dictionary: database]
#A Layer: E-EntityMaster T-TransactionFact R-RelationMapping M-DetailDependent C-ReferenceDictionary S-StateStorage H-HistoryVersion L-LogAudit Q-QueueOutbox A-AggregateProjection K-KeyValueConfiguration B-DocumentLargeObject Z-Other
#B Module: G-CrossDomain B-CoreBusiness I-IdentityAccess T-OrganizationTenant U-UserExperience F-FinanceBilling K-ContentKnowledge C-ConfigurationPolicy W-WorkflowTask M-MessageEvent N-ExternalIntegration S-SecurityPrivacy O-ObservabilityAudit R-ReliabilityRecovery P-PerformanceResource A-AnalyticsIntelligence H-HardwareDevice L-Localization V-BuildRelease Q-QualityTesting E-ExtensionPlugin Z-Other
#C Importance: 9-highest 8-very-high 7-high 6-above-average 5-medium 4-below-average 3-low 2-very-low 1-lowest
#E Scale: L-large>400 M-medium200-400 S-small100-200 T-tiny<100

स्टार्टर कोड शब्दकोश के अंतर्गत, [CG9L] का अर्थ है C SharedFoundation, G CrossDomain, 9 उच्चतम महत्व, और L बड़े पैमाने; कोई D मान मौजूद नहीं है। यह बताता है कि मौजूदा प्रविष्टि को कैसे पढ़ा जाए, यह नहीं कि मॉडल को टैग कैसे असाइन करने चाहिए। मॉडल अभी भी स्रोत और स्वीकृत साक्ष्य के आधार पर वर्तमान प्रोजेक्ट Meta से टैग चुनता है।

Cognition Volumes

AOCI-CODE एक तार्किक Whole-Index बनाए रखता है, जबकि प्रत्येक प्रकार के इंडेक्स का अपना फ़ाइल, स्वामित्व और जीवनचक्र होता है।

प्रत्येक ऑब्जेक्ट का ठीक एक वैध स्वामी होता है। किसी ऑब्जेक्ट को गलत Volume में रखने से स्वामित्व विरोध उत्पन्न होता है। AOCI-CODE इसे केवल तब ठीक करता है जब मशीन गलत स्वामी, सही स्वामी और वर्तमान ऑब्जेक्ट तथ्यों को सिद्ध कर सके; यह समान नामों से स्वामित्व का अनुमान नहीं लगाता।

Code Volume, Database Volume और दायरा एक साथ विकसित हो सकते हैं, लेकिन वे एक शासित कमिट सीमा साझा करते हैं। एक डोमेन को लागू करने से दूसरे डोमेन के मौजूदा Baseline प्रोजेक्शन को खारिज नहीं करना चाहिए। एक Volume apply, Baseline अपडेट और संबंधित दायरा प्रोजेक्शन एक सुसंगत लेनदेन परिणाम के रूप में प्रकाशित होते हैं या सिद्ध रिकवरी में प्रवेश करते हैं। वे कभी भी आधी-अधूरी स्थिति नहीं छोड़ते जिसमें "फ़ाइल सफल हुई लेकिन दूसरे Volume का कोई बेसलाइन नहीं है।"

होस्ट एकीकरण

aoci init हमेशा प्रबंधित एजेंट नियम लिखता है, लेकिन होस्ट एकीकरण भिन्न होता है:

• Codex को प्रोजेक्ट-स्तरीय MCP कॉन्फ़िगरेशन मिलता है और, --hooks के साथ, एक संदर्भ-संपीड़न प्रॉम्प्ट और SessionStart(compact)। यह अभी भी कोई फ़ाइल-संपादन हुक स्थापित नहीं करता।
• Claude Code एक PreToolUse हुक स्थापित कर सकता है।
• OpenCode V1 को एक सख्त प्रोजेक्ट-स्तरीय opencode.json मिलता है।
• Cursor केवल एक संदर्भ कॉन्फ़िगरेशन स्निपेट लौटाता है; प्रोजेक्ट में कुछ भी नहीं लिखा जाता।

कॉन्फ़िगरेशन के बाद, जाँचें कि क्या वर्तमान होस्ट सत्र पहले से ही AOCI टूल उजागर करता है। उस प्रोजेक्ट सत्र को केवल तब रीफ़्रेश या पुनः खोलें जब उसने नया सर्वर लोड न किया हो। एक नया सत्र सामान्यतः नियमों और Whole-Index को एक बार पढ़ता है। जब तक इंडेक्स पहचान वैध रहती है और कोई ज्ञात होस्ट संपीड़न नहीं हुआ है, बाद के कार्य मॉडल के पास पहले से मौजूद जानकारी का पुनः उपयोग करते हैं; पूरा इंडेक्स यांत्रिक रूप से दोबारा इंजेक्ट नहीं किया जाता।

aoci --repo /absolute/path/to/repository init --agent codex
aoci --repo /absolute/path/to/repository init --agent codex --hooks
aoci --repo /absolute/path/to/repository init --agent claude --hooks
aoci --repo /absolute/path/to/repository init --agent opencode
aoci --repo /absolute/path/to/repository init --agent cursor

Codex --hooks एक संपीड़न हैंडऑफ़ को रसीद पहचान, अपूर्ण लेखन या रिकवरी स्थिति, और तत्काल पुनः लोड निर्देश तक सीमित करता है; इसे Whole-Index या Overview/Attestation निकायों को बनाए नहीं रखना चाहिए या सारांशित नहीं करना चाहिए। एक PreCompact हुक होस्ट संपीड़न इनपुट में इंजेक्ट या उससे इतिहास हटा नहीं सकता, इसलिए यह अकेले इसे लागू नहीं कर सकता। इस पर निर्भर होने से पहले Codex /hooks के माध्यम से स्थापित प्रोजेक्ट हुक की समीक्षा और विश्वास करें।

Legacy आउटपुट मौजूदा होस्ट और रिपोर्ट के साथ संगतता के लिए Levels 0–4 बनाए रखता है। वर्तमान cognition-state/v2 यह व्यक्त करता है कि सिस्टम की मॉडल की तस्वीर कितनी उपयोगी है, Levels 0–3 के रूप में, और सख्त प्रमाण तथा शासन तथ्यों को स्वतंत्र आयामों में अलग करता है:

ये आयाम एक-दूसरे का स्थान नहीं लेते। Attestation केवल वर्तमान सामग्री के लिए डिलीवरी कवरेज और पहचान संगति सिद्ध करता है; इसका अर्थ यह नहीं है कि एजेंट ने प्रत्येक संभावित भविष्य के कार्य को पूरी तरह समझ लिया है। केवल current_system_cognition_reliable=true पूर्ण वर्तमान-सिस्टम समझ के बिना योग्यता दावे की अनुमति देता है।

AOCI पैनल

aoci ui इस मशीन पर एक रीड-ओनली पैनल प्रदान करता है, ताकि आप एजेंट से पूछे बिना इंडेक्स की स्थिति देख सकें:

• इंडेक्स हेडर और Code / Database Volumes शब्दशः (=== अनुभाग पंक्तियाँ जैसी हैं वैसी ही रखी गई, फ़िल्टर करने योग्य, पूरी तरह कॉपी करने योग्य); "All" टैब पूरा इंडेक्स है ठीक वैसे ही जैसे एजेंट Overview के माध्यम से प्राप्त करता है
• बजट के विरुद्ध इंडेक्स टोकन, और Overview चंक योजना
• इंडेक्स कितने कोड को कवर करता है: फ़ाइलें, पंक्तियाँ, टोकन और संपीड़न अनुपात; कितनी डेटाबेस तालिकाएँ
• शासन स्थिति और ड्रिफ्ट, Managed Scope, होस्ट एकीकरण, और चल रही aoci mcp प्रक्रियाएँ
• एजेंट को आगे देने के लिए कमांड और प्रॉम्प्ट, कॉपी बटन के साथ

पेज चीनी और अंग्रेज़ी के बीच स्विच होता है; रीफ़्रेश अंतराल चयन योग्य है (डिफ़ॉल्ट 30 सेकंड)।

एक WSL में कई aoci mcp सर्वर? Linux और WSL पर पैनल वर्तमान उपयोगकर्ता की प्रत्येक aoci mcp प्रक्रिया और उसकी रिपॉज़िटरी का पता लगाता है, शीर्ष पर टैब के साथ उनके बीच स्विच करता है, और उस सर्वर को चिह्नित करता है जिसकी बाइनरी डिस्क पर बदल दी गई है। सीमाएँ: यह केवल लूपबैक पतों को बाइंड करता है (कोई अन्य बाइंड अस्वीकार कर दिया जाता है), केवल GET और HEAD का उत्तर देता है, कोई लॉक नहीं लेता, लेजर में कुछ नहीं जोड़ता, और रिपॉज़िटरी का एक भी बाइट नहीं बदलता। यह aoci mcp से असंबंधित एक अलग प्रक्रिया है; MCP सर्वर अभी भी कोई सॉकेट नहीं खोलता। किसी बैकग्राउंड पैनल का पंजीकरण उपयोगकर्ता की कैश निर्देशिका में रहता है, कभी भी रिपॉज़िटरी में नहीं।

सामान्य CLI कमांड

सामान्य संयोजन:

# Initialization and first Baseline
aoci --repo . init --locale en-US --agent codex
aoci --repo . scan

# Verification and governance gates for Cognition Volumes
aoci --repo . verify --json
aoci --repo . check --json

# Live Guide; do not duplicate the state machine in a wrapper
aoci --repo . index agent guide --agent codex --json

# Capabilities and diagnostics
aoci --repo . capabilities
aoci --repo . doctor

# Database Evidence, Access, and Cognition lifecycle
aoci --repo . database --help
aoci --repo . database source access --source primary --json
aoci --repo . database cognition status
aoci --repo . cognition plan --help

# Derived System Cognition observations
aoci --repo . cognition system lineage
aoci --repo . cognition system relations

# MCP stdio Server
aoci --repo . mcp

Plan, Stage, Check, Diff, Apply, Curation, Scope Change, Bootstrap, Migration, और पुनर्प्राप्ति कमांड अभी भी मौजूद हैं। चल रही बाइनरी द्वारा लौटाए गए गाइड का पालन करें; आंतरिक स्टेट मशीन को स्क्रिप्ट में न कॉपी करें।

"रीड-ओनली" कमांड के बारे में

verify, check, index score, और index inventory के लिए, "रीड-ओनली" का अर्थ है कि औपचारिक इंडेक्स और Baseline संशोधित नहीं होते; इसका अर्थ पूर्ण रूप से शून्य फ़ाइलसिस्टम राइट नहीं है। जब Ledger सक्षम होता है, तो सभी चार कमांड स्थानीय Ledger में जोड़ सकते हैं, और verify Verify History लिखने का भी प्रयास करता है। ऑडिट-राइट विफलता मौजूदा एग्ज़िट कोड या गवर्नेंस मानदंडों को नहीं बदलती।

यदि कठोर शून्य-फ़ाइल-राइट ऑपरेशन आवश्यक हो, तो एक पृथक प्रति का उपयोग करें; वर्तमान सार्वजनिक CLI ऐसा कोई व्यापक स्विच उजागर नहीं करता जो प्रत्येक Ledger और Verify History राइट को अक्षम कर दे। System Cognition कमांड दूसरा औपचारिक स्टेट नहीं बनाते, लेकिन सामान्य CLI कॉल अभी भी Ledger और स्थानीय इतिहास रिकॉर्ड के लिए वर्तमान संस्करण के रनटाइम अनुबंध का पालन करते हैं।

MCP सर्वर

aoci mcp को किसी निवासी डेमॉन की आवश्यकता नहीं है और यह stdio पर ठीक नौ टूल उजागर करता है:

MCP मोड में, stdout JSON-RPC के लिए आरक्षित है; लॉग और निदान stderr पर जाते हैं। चल रही बाइनरी द्वारा प्रदान किए गए टूल विवरण, JSON स्कीमा, और मशीन-स्टेट मान प्रामाणिक हैं; यह README केवल एक प्रारंभिक बिंदु है।

वर्तमान रिलीज़ System Cognition क्षमताएँ मौजूदा CLI और गवर्नेंस कर्नेल के माध्यम से प्रदान करती है। वे दसवाँ MCP टूल नहीं जोड़तीं और मौजूदा नौ के नाम, उद्देश्य, या stdio अनुबंध को नहीं बदलतीं।

दीर्घकालिक सत्र और Whole-Index डिलीवरी

एक नई बातचीत की शुरुआत में, एक एजेंट सामान्यतः सिस्टम की एक तस्वीर प्राप्त करने के लिए एक पूर्ण Overview लोड करता है जो वर्तमान रिपॉज़िटरी, इंडेक्स संस्करण, और AOCI सेवा पहचान से मेल खाती हो। जब तक मॉडल उस तस्वीर पर भरोसा कर सकता है, उसे प्रत्येक कार्य या टूल कॉल से पहले पुनः लोड करने की आवश्यकता नहीं है।

उसी बातचीत के भीतर, मॉडल अपने स्वयं के स्टेट के आधार पर तय करता है कि पुनः लोड करना है या नहीं, सिवाय किसी ज्ञात होस्ट कॉन्टेक्स्ट कम्पैक्शन के बाद। एक कम्पैक्टेड हैंडऑफ़ केवल रसीद पहचान, अपूर्ण राइट या पुनर्प्राप्ति स्टेट, और तत्काल पुनः लोड निर्देश को सुरक्षित रख सकता है; उसे Whole-Index या Overview हेडर, प्रविष्टि, चंक, चुनौती, या सत्यापन निकायों को सुरक्षित या सारांशित नहीं करना चाहिए। उस हैंडऑफ़ में कॉपी की गई इंडेक्स सामग्री या रसीद यह सिद्ध नहीं कर सकती कि मॉडल की वर्तमान तस्वीर विश्वसनीय है।

ज्ञात कम्पैक्शन के बाद व्यावसायिक कार्य जारी रखने से पहले, एजेंट नियमों को पुनः लोड करता है यदि वे अब विश्वसनीय रूप से उपस्थित नहीं हैं, एक नए इवेंट ID के साथ context_compaction घोषित करता है, और एक सामान्य पूर्ण Overview कर्सर, पुष्टि, और सत्यापन अनुक्रम पूरा करता है। check_only और cognition probe इसके विकल्प नहीं हैं। ताज़ा पूर्ण ट्रांसपोर्ट के बाद, मौजूदा आंशिक या विफल सत्यापन नियम अभी भी दूसरे स्वचालित Overview के बिना स्रोत-बद्ध निरंतरता की अनुमति देता है। ज्ञात कम्पैक्शन के बिना किसी अर्थपूर्ण परिवर्तन या प्रमुख चरण सीमा के लिए, AOCI रीफ़्रेश थ्रेशोल्ड, चेकपॉइंट, और पहचान तथ्य प्रदान करता है, और मॉडल तय करता है कि कार्य के लिए अपनी सिस्टम-स्तरीय तस्वीर को पुनः स्थापित करने की आवश्यकता है या नहीं।

प्रत्येक पूर्ण Overview का निकाय एक प्रारंभ मार्कर, वर्तमान औपचारिक इंडेक्स की सटीक सामग्री, और एक अंत मार्कर से मिलकर बनता है।

जब कोई Overview प्रोजेक्ट के चंक बजट से अधिक हो जाता है:

1. डिलीवरी चंक 1 के साथ तुरंत शुरू होती है;
2. एजेंट को अंतिम चंक तक स्वचालित रूप से next_cursor का पालन करना चाहिए;
3. एजेंट डिलीवर किए गए Whole-Index का उपयोग करके एक सत्यापन प्रस्तुत करता है;
4. स्थानीय खोज, पुरानी स्मृति, पूरक स्रोत पठन, या सीधे फ़ाइल पठन को पूर्ण डिलीवरी के रूप में प्रस्तुत नहीं किया जाना चाहिए;
5. लंबित पुनर्प्राप्ति या असंगत स्नैपशॉट सामग्री मिलाए बिना फेल-क्लोज़्ड विफल होता है।

overview_delivery.chunk_tokens एकमात्र डिलीवरी-आकार सेटिंग है। इसका डिफ़ॉल्ट 7000 है, जिसकी वैध सीमा 4000 से 24000 तक है। check_only=true चंक श्रृंखला के बिना एक कॉम्पैक्ट चेकपॉइंट है।

AOCI aoci_overview पर प्रति-टूल परिणाम-आकार भत्ता घोषित करता है। एक होस्ट जो अन्यथा एक बड़े टूल परिणाम को डिस्क पर सहेजता है, मॉडल के कॉन्टेक्स्ट में केवल एक पूर्वावलोकन रखता है (इंडेक्स डिलीवरी के लिए, एक मूक विफलता), केवल इस टूल के लिए उस थ्रेशोल्ड को बढ़ाता है। Claude Code पर यह पूर्ण 24000 को उपयोगी बनाता है, पाँच के बजाय तीन चंक में 480-ऑब्जेक्ट इंडेक्स डिलीवर करता है। कुछ भी प्रोब नहीं किया जाता: घोषणा स्थिर है, और एक होस्ट जो इसे नहीं पहचानता वह इसे अनदेखा कर देता है, जैसा MCP विनिर्देश आवश्यक करता है।

रीफ़्रेश थ्रेशोल्ड डिफ़ॉल्ट रूप से 30 विशिष्ट सिमेंटिक पथ है और इसे प्रति प्रोजेक्ट भी कॉन्फ़िगर किया जा सकता है। सटीक गणना नियमों के लिए, Cognition Refresh दस्तावेज़ और रनटाइम अनुबंध का पालन करें।

Database Cognition

AOCI-CODE डेटाबेस संरचना को उसी इंडेक्स और उसी गवर्नेंस के अंतर्गत ला सकता है, एक स्पष्ट और संकीर्ण एक्सेस सीमा के साथ:

Explicit database command
  → Read-only PostgreSQL/MySQL/openGauss system catalogs
  → Canonical schema evidence
  → Human acceptance of the evidence hash
  → The host model writes table-level FRAS from complete evidence
  → Entries are bound to the evidence and enter governed apply

• जब कोई डेटाबेस कॉन्फ़िगर नहीं है या कोई स्पष्ट डेटाबेस कमांड नहीं चलाया जाता, तो कोई डेटाबेस नेटवर्क एक्सेस नहीं होता।
• केवल बेस टेबल के लिए स्कीमा मेटाडेटा पढ़ा जाता है, व्यावसायिक पंक्तियाँ नहीं; व्यू, रूटीन, और टिप्पणियाँ वर्तमान संग्रह दायरे से बाहर हैं।
• कोई DDL या DML निष्पादित नहीं होता।
• होस्टनाम, उपयोगकर्ता नाम, DSN, और क्रेडेंशियल मान कभी भी इंडेक्स फ़ाइलों में नहीं लिखे जाते।
• Database Cognition apply ऑफ़लाइन चलता है और लिखते समय डेटाबेस से पुनः कनेक्ट नहीं होता।
• प्रोग्राम संरचनात्मक साक्ष्य को सुरक्षित और तुलना करता है, लेकिन मॉडल अभी भी टेबल जिम्मेदारियाँ, संबंध, और उच्च-मूल्य बाधाएँ लिखता है।

MySQL समर्थन 5.7.6 और उसके बाद के संस्करणों को कवर करता है। कलेक्टर सर्वर संस्करण पढ़ता है और केवल वे कैटलॉग क्वेरी चलाता है जिनका उत्तर वह रिलीज़ दे सकती है: CHECK बाधाएँ 8.0.16 से, इंडेक्स एक्सप्रेशन 8.0.13 से, इंडेक्स दृश्यता 8.0.0 से। एक 5.7 सर्वर एक खाली चेक सूची रिकॉर्ड करता है, क्योंकि 5.7 CHECK सिंटैक्स पार्स करता है और कुछ भी संग्रहीत नहीं करता; साक्ष्य का आकार प्रत्येक समर्थित रिलीज़ पर समान होता है। MariaDB समर्थित नहीं है और इसे MySQL के रूप में पढ़ने के बजाय अस्वीकार कर दिया जाता है।

प्रारंभिक openGauss प्रोफ़ाइल जानबूझकर A/PG संगतता मोड में openGauss 6.0.5 LTS और सामान्य गैर-विभाजित बेस टेबल तक सीमित है। असमर्थित कैटलॉग सुविधाएँ चुपचाप PostgreSQL तथ्यों में घटाए जाने के बजाय फेल-क्लोज़्ड विफल होती हैं; यह MogDB, GaussDB, Dolphin/B/MySQL मोड, विभाजन या उपविभाजन, कॉलम-स्टोर, MOT, विदेशी या अस्थायी टेबल, व्यू, रूटीन, या ट्रिगर के लिए समर्थन का दावा नहीं करता।

यहाँ, फेल-क्लोज़्ड डिटेक्शन असमर्थित सिमेंटिक्स वाले चयनित दृश्यमान टेबल-जैसे ऑब्जेक्ट्स पर लागू होता है। रूटीन और ट्रिगर v1 टेबल-ऑब्जेक्ट डोमेन से बाहर रहते हैं और कभी भी टेबल तथ्यों के रूप में प्रस्तुत नहीं किए जाते।

openGauss पथ आधिकारिक Connector v1.0.8 स्रोत पर AOCI के समीक्षित स्थानीय पैच का उपयोग करता है। इसका सख्त पार्सर केवल समीक्षित कनेक्शन पैरामीटर स्वीकार करता है और परिवेशीय PG*, सेवा, पासवर्ड-फ़ाइल, होम-निर्देशिका, या लॉगर कॉन्फ़िगरेशन का उपभोग नहीं करता। किसी संख्यात्मक लूपबैक पते के बाहर TCP कनेक्शन को स्पष्ट रूप से sslmode=verify-full का उपयोग करना चाहिए (और जब प्रदान किया जाए तो sslrootcert में एक निरपेक्ष विश्वसनीय-रूट पथ), TLS 1.2 न्यूनतम के साथ; TLS डाउनग्रेड मोड अस्वीकार कर दिए जाते हैं। sslmode=disable केवल स्पष्ट Unix सॉकेट या स्थानीय/परीक्षण सीमा के रूप में उपयोग किए गए संख्यात्मक लूपबैक पते के लिए स्वीकार किया जाता है। डेटाबेस प्रशासक बातचीत के बाहर वह DSN प्रदान करने और न्यूनतम-विशेषाधिकार खाते का प्रावधान करने के लिए ज़िम्मेदार बने रहते हैं।

Database Volume डिफ़ॉल्ट रूप से अनुपस्थित है। यह Whole-Index में केवल तब प्रवेश करता है जब प्रोजेक्ट स्पष्ट रूप से Database Cognition सक्षम करता है और साक्ष्य, बाइंडिंग, और जीवनचक्र गवर्नेंस पूरा करता है।

डेटाबेस एक्सेस ऑनबोर्डिंग: आपको DSN विवरण समझने की आवश्यकता नहीं है

आप केवल किसी डेटाबेस स्रोत के लिए एक गैर-संवेदनशील पहचान घोषित करते हैं। यदि --credential-env छोड़ा जाता है, तो AOCI स्रोत ID से एक स्थिर पर्यावरण-चर संदर्भ प्राप्त करता है; उदाहरण के लिए, primary AOCI_DB_PRIMARY_DSN पर मैप होता है:

aoci --repo . database source add \
  --source-id primary \
  --engine postgresql \
  --database-name app \
  --namespace public

फिर यह देखने के लिए रीड-ओनली एक्सेस प्रीफ़्लाइट का उपयोग करें कि क्या बाहरी वातावरण ने वह संदर्भ प्रदान किया है:

aoci --repo . database source access --source primary --json

यह कमांड डेटाबेस से कनेक्ट नहीं होता, क्रेडेंशियल मान नहीं लौटाता, या आपसे किसी बातचीत में DSN पेस्ट करने के लिए नहीं कहता। एक डेटाबेस या अवसंरचना प्रशासक AOCI प्रक्रिया के बाहर पर्यावरण चर प्रदान करता है और सिस्टम कैटलॉग तक रीड-ओनली, न्यूनतम-विशेषाधिकार एक्सेस प्रदान करता है। स्रोत कॉन्फ़िगरेशन केवल क्रेडेंशियल संदर्भ नाम संग्रहीत करता है, गुप्त मान नहीं।

वर्तमान रिलीज़ कैंडिडेट केवल पर्यावरण क्रेडेंशियल प्रदाता प्रदान करता है। Vault, Kubernetes Secret, और AWS/GCP/Azure जैसे क्लाउड सीक्रेट मैनेजर बाद के संस्करणों में उसी प्रदाता सीमा के माध्यम से एकीकृत किए जा सकते हैं; वे आज उपलब्ध नहीं हैं, और यह README अन्यथा संकेत नहीं देता। यह विभाजन खाता प्रारूपों, DSN एन्कोडिंग, और गोपनीय जीवनचक्र प्रबंधन को सामान्य उपयोगकर्ताओं से दूर रखता है, जबकि प्राधिकरण को स्पष्ट रखता है: AOCI क्रेडेंशियल्स को स्वचालित रूप से खोजता नहीं है, .env को स्कैन नहीं करता है, गोपनीय फ़ाइलें नहीं पढ़ता है, या किसी डेटाबेस प्रशासक की प्राधिकरण सीमा को बायपास नहीं करता है।

सिस्टम कॉग्निशन फ़ाउंडेशन

कोड और डेटाबेस इंडेक्स के ऊपर, AOCI-CODE व्युत्पन्न सिस्टम कॉग्निशन अवलोकनों का एक सेट प्रदान करता है। वे ऐसे प्रश्नों का उत्तर देते हैं जैसे "यह ऑब्जेक्ट कहाँ से आया?", "डेटाबेस परिवर्तन किन कोड ऑब्जेक्ट्स को प्रभावित कर सकता है?", और "किसी ऐतिहासिक अवलोकन और अब के बीच क्या बदला?" वे प्रामाणिक तथ्यों की एक नई परत नहीं बनाते हैं।

# Where an index object came from, with its evidence and receipt bindings
aoci --repo . cognition system lineage

# Volume containment and dependencies plus resolved model-authored R relationships
aoci --repo . cognition system relations

# Find code impact from a database object along formal R relationships
aoci --repo . cognition system impact \
  --object database://primary/public/orders

# Save a historical observation on the caller side
aoci --repo . cognition system snapshot --json > previous.json

# Compare a caller-supplied historical observation with the current derived projection
aoci --repo . cognition system evolution \
  --snapshot-file previous.json

प्राधिकरण सीमा

प्रत्येक System Cognition परिणाम derived=true की रिपोर्ट करता है; संबंध प्रक्षेपण अतिरिक्त रूप से authoritative=false की रिपोर्ट करता है। Cognition Volumes, स्कीमा साक्ष्य बाइंडिंग, Baseline फ़िंगरप्रिंट, और रसीद-बद्ध पहचान अंतर्निहित प्राधिकरण बने रहते हैं। अहल किए गए R संबंध अपूर्ण परिणाम या निदान उत्पन्न करते हैं; प्रोग्राम अनुमान नहीं लगाता और उन्हें भरता नहीं है।

AOCI-CODE एक नॉलेज-ग्राफ़ सिस्टम नहीं है। संकीर्ण संबंध प्रक्षेपण एक सुविधाजनक संबंध दृश्य है, लेकिन यह कोई दूसरी स्टेट-मैनेजमेंट प्रणाली, कोई स्वतंत्र लेखन पथ, और कोई नया तथ्य भंडार नहीं रखता है। व्युत्पन्न आउटपुट को हटाया जा सकता है और वर्तमान प्रामाणिक संपत्तियों से पुनर्गणना किया जा सकता है। यदि कोई प्रक्षेपण प्रामाणिक संपत्तियों के साथ टकराता है, तो संपत्तियाँ जीतती हैं।

निष्पादन मोड, गोपनीयता, और डेटा सीमाएँ

• AOCI-CODE डिफ़ॉल्ट रूप से लोकल-फ़र्स्ट है, जिसमें कोई डिफ़ॉल्ट क्लाउड एंडपॉइंट, कोई होस्टेड स्रोत-अपलोड सेवा, और कोई आवश्यक बैकग्राउंड सर्वर नहीं है।
• Agent-native मोड में डेटा प्रबंधन आपके द्वारा चुने गए होस्ट और उसकी उत्पाद नीतियों पर निर्भर करता है; AOCI-CODE होस्ट की ओर से डेटा अपलोड नहीं करता है।
• डेटाबेस नेटवर्क एक्सेस स्पष्ट रूप से ट्रिगर किया जाना चाहिए और यह केवल-पढ़ने योग्य स्कीमा मेटाडेटा तक सीमित है।
• लेजर, मसौदे, लेनदेन, और पुनर्प्राप्ति साक्ष्य डिफ़ॉल्ट रूप से .aoci/ के अंतर्गत संग्रहीत होते हैं और सामान्यतः Git द्वारा अनदेखा किए जाते हैं; इंडेक्स फ़ाइलें और टीम-शासन संपत्तियाँ Git में कमिट की जा सकती हैं।
• System Cognition प्रक्षेपण मौजूदा प्रामाणिक संपत्तियों से स्थानीय रूप से गणना किए जाते हैं और इनके लिए किसी ग्राफ़ डेटाबेस, वेक्टर डेटाबेस, या रिमोट ग्राफ़ सेवा की आवश्यकता नहीं होती है।

यह रेपो मैप, RAG, LSP, या कोड ग्राफ़ से कैसे भिन्न है

खोज, AST, LSP, कोड ग्राफ़, और RAG संरचनात्मक और पुनर्प्राप्ति प्रश्नों में अच्छे हैं। AOCI-CODE एक अलग कार्य करता है: यह सिस्टम का एक संस्करणित विवरण बनाए रखता है जो प्रबंधित स्कोप को कवर करता है और सॉफ़्टवेयर के साथ क्रमिक रूप से विकसित होता है। आपको क्या मिलता है:

• एक Whole-Index। वर्तमान प्रबंधित स्कोप को कवर करने वाला एक सिस्टम मैप, न कि प्रत्येक कार्य के लिए तुरंत जोड़े गए टुकड़े।
• FRAS प्रविष्टियाँ। index भूमिका वाले प्रत्येक ऑब्जेक्ट के लिए जिम्मेदारियाँ, मजबूत संबंध, सार्वजनिक अनुबंध, और उच्च-मूल्य बाधाएँ।
• सत्रों में दृढ़ता। इंडेक्स फ़ाइलें रिपॉज़िटरी के साथ रहती हैं, इसलिए बाद के सत्र और अन्य एजेंट वही संस्करण पुनः उपयोग करते हैं।
• प्रबंधित स्कोप। एक स्पष्ट रिकॉर्ड कि कौन से ऑब्जेक्ट इंडेक्स में प्रवेश करते हैं, कौन से केवल परिवर्तन के लिए देखे जाते हैं, और कौन से जानबूझकर छोड़े गए हैं।
• ड्रिफ्ट पहचान। Missing, Orphan, Stale, Unbaselined, लाइन-एंडिंग परिवर्तन, क्यूरेशन अंतर, और लेखन से बाहर रखे गए स्रोतों (खाली, बाइनरी, अति-आकार) के बीच अंतर करता है।
• शासित अद्यतन। उम्मीदवार स्रोत बाइंडिंग, योजना, सत्यापन, समीक्षा, CAS, परमाणु लेखन, Baseline, और पुनर्प्राप्ति वर्कफ़्लो के माध्यम से औपचारिक फ़ाइलों में प्रवेश करते हैं।
• डिलीवरी प्रमाणन। Chunk, cursor, receipt, और challenge सिद्ध करते हैं कि Whole-Index पूर्ण रूप से वितरित किया गया था।
• Database Cognition। स्पष्ट रूप से स्वीकृत PostgreSQL/MySQL/openGauss स्कीमा साक्ष्य से निर्मित और शासित तालिका-स्तरीय प्रविष्टियाँ।
• सिस्टम प्रक्षेपण। Lineage, संकीर्ण Relations, डेटाबेस-से-कोड Impact, Snapshot, और Evolution अवलोकन प्रामाणिक इंडेक्स और उसकी बाइंडिंग से व्युत्पन्न, प्रामाणिक स्थिति की नकल किए बिना; Impact केवल स्पष्ट मॉडल-लिखित R संबंधों को पार करता है।

AOCI-CODE मौजूदा टूल्स का पूरक है, उन्हें प्रतिस्थापित नहीं करता।

अनुशंसित संयोजन: AOCI-CODE वैश्विक सिमेंटिक प्रायर प्रदान करता है; कोड ग्राफ़, LSP, खोज, और स्रोत सटीक साक्ष्य प्रदान करते हैं; परीक्षण और रनटाइम परिणाम अंतिम स्वीकृति प्रदान करते हैं। AOCI का Relations प्रक्षेपण एक सटीक कॉल ग्राफ़ को प्रतिस्थापित नहीं करता: यह संरचनात्मक Volume containment और Root निर्भरता किनारों को उजागर करता है, जबकि इसके सिमेंटिक किनारे केवल उन मजबूत संबंधों तक सीमित हैं जिन्हें मॉडल ने स्पष्ट रूप से लिखा है।

प्रौद्योगिकी स्टैक

AOCI-CODE को Neo4j, वेक्टर डेटाबेस, लंबे समय तक चलने वाले डेमॉन, या AOCI क्लाउड सेवा की आवश्यकता नहीं है। जब Database Cognition सक्षम होता है, तो लक्ष्य डेटाबेस केवल स्कीमा साक्ष्य का एक स्पष्ट, केवल-पढ़ने योग्य स्रोत है, AOCI का अपना स्टेट स्टोर नहीं।

सामान्य प्रश्न

Legacy status --deep अभी भी ड्रिफ्ट क्यों दिखाता है?

status --deep, index score, और index agent plan केवल Legacy हैं। एक Cognition Volumes रिपॉज़िटरी के लिए, लाइव गाइड चलाएँ और होस्ट को सामान्य बिना-तर्क वाले aoci_maintain का उपयोग करने दें, पूर्ण वर्तमान बैच को aoci_update_entry के माध्यम से सबमिट करें, और Verify, Check, और गाइड के साथ समाप्त करें। Baseline को सीधे संशोधित न करें या स्रोत-बाइंडिंग और पुनर्प्राप्ति चरणों को न छोड़ें।

Legacy लेआउट स्वयं अप्रचलित है। Volumes v1 नए और माइग्रेट किए गए रिपॉज़िटरी के लिए समर्थित पथ है, और केवल-Legacy कमांड v0.2.0 में हटाने के लिए निर्धारित हैं; उससे पहले aoci cognition migration के साथ एक Legacy रिपॉज़िटरी को माइग्रेट करें।

aoci --repo . index agent guide --agent codex --json

होस्ट ने गलत AOCI क्यों शुरू किया?

प्रोजेक्ट-स्तरीय MCP कॉन्फ़िगरेशन में निष्पादन योग्य पथ का निरीक्षण करें और सुनिश्चित करें कि यह एक स्थिर निरपेक्ष पथ है, फिर चलाएँ:

/absolute/path/to/aoci --version
/absolute/path/to/aoci --repo . doctor

केवल डिस्क पर मौजूद फ़ाइल के बजाय लोड किए गए stdio सर्वर को सत्यापित करने के लिए, होस्ट प्रक्रिया के वास्तविक निष्पादन योग्य, उसकी कमांड-लाइन --repo, और पुनः आरंभ के बाद प्रक्रिया पहचान का भी निरीक्षण करें।

क्या मुझे स्वयं एक डेटाबेस खाता बनाना और DSN प्रदान करना होगा?

आपको DSN सिंटैक्स समझने की आवश्यकता नहीं है, और आपको चैट में गोपनीय जानकारी नहीं भेजनी चाहिए। आपके द्वारा एक गैर-संवेदनशील स्रोत पहचान घोषित करने के बाद, AOCI एक स्थिर पर्यावरण-चर संदर्भ प्रदान करता है। एक डेटाबेस प्रशासक को अभी भी केवल-पढ़ने योग्य सिस्टम-कैटलॉग एक्सेस वाला एक बाहरी, न्यूनतम-विशेषाधिकार खाता बनाना होगा और वह संदर्भ रनटाइम पर्यावरण को प्रदान करना होगा। वर्तमान संस्करण किसी संगठन की ओर से डेटाबेस खाता नहीं बनाता या गोपनीय भंडार को स्वचालित रूप से नहीं पढ़ता है।

क्या यह CI में चल सकता है?

हाँ। स्कैनिंग, सत्यापन, शासन गेट, और नियतात्मक जाँचें नई प्रविष्टियाँ लिखे बिना चलती हैं। सटीक कमांड, ऑडिट लेखन, और निकास कोड के लिए, वर्तमान बाइनरी के --help, JSON स्कीमा, और परियोजना के CI दस्तावेज़ पर भरोसा करें।

क्या सभी-हरे AOCI परिणाम सिद्ध करता है कि सिमेंटिक्स सही हैं?

नहीं। एक हरा परिणाम सिद्ध करता है कि एन्कोडेड संरचनात्मक और शासन शर्तें पूरी होती हैं। मॉडल ने जो लिखा है उसे अभी भी स्रोत कोड, स्कीमा, परीक्षण, रनटाइम परिणाम, और मानव समीक्षा के विरुद्ध जाँचा जाना चाहिए।

क्या System Cognition ग्राफ़ सत्य का एक नया स्रोत है?

नहीं। वर्तमान क्षमता एक संकीर्ण संबंध प्रक्षेपण है, स्वतंत्र ग्राफ़ प्लेटफ़ॉर्म नहीं। यह केवल औपचारिक इंडेक्स, साक्ष्य, रसीदों, और Baseline से परिणामों की गणना करता है, और नए प्रामाणिक तथ्यों को सहेजता नहीं है। प्रोग्राम आयात, SQL, फ़ाइलनाम, या समानता से सिमेंटिक संबंध भी स्वचालित रूप से उत्पन्न नहीं करता है।

दस्तावेज़

दस्तावेज़ीकरण और सार्वजनिक-अनुबंध लिंक v0.1.0-rc22 पर पिन किए गए हैं ताकि वे तब भी वैध रहें जब यह README किसी बाइनरी Release आर्काइव से पढ़ा जाए, जिसमें रिपॉज़िटरी की docs/ या spec/public/ निर्देशिकाएँ शामिल नहीं होतीं।

ब्लैक-बॉक्स सत्यापन सूट

रिपॉज़िटरी scripts/blackbox/ के अंतर्गत चार स्वतंत्र ब्लैक-बॉक्स सूट प्रदान करती है, जो किसी निर्मित aoci बाइनरी का परीक्षण प्रक्रिया के पूर्णतः बाहर से, केवल सार्वजनिक stdio MCP प्रोटोकॉल और CLI के माध्यम से करते हैं:

• प्रोटोकॉल अनुरूपता — MCP वायर सतह के 53 रीड-ओनली जाँच, जिनमें लोकेल-निर्भर वाक्य zh-CN के अंतर्गत दोहराए गए हैं;
• फ़ॉल्ट-इंजेक्शन परिदृश्य — 75 परिदृश्य जो कर्सर छेड़छाड़, क्रैश रिकवरी, प्रतिस्पर्धी राइटर, और डिस्पोज़ेबल फ़िक्सचर रिपॉज़िटरी पर प्री-राइट हुक को कवर करते हैं;
• स्थिर वास्तविक परियोजनाओं पर जीवनचक्र — तीन कमिट किए गए फ़िक्सचर प्रोजेक्ट: repo-a (TypeScript) और repo-b (Python + MySQL) पूर्ण init-से-रीअलाइनमेंट जीवनचक्र चलाते हैं, और repo-c (एक 453-फ़ाइल स्तरित सेवा) अतिरिक्त रूप से मशीन बैच सीमा पर मल्टी-बैच लेखन संचालित करता है। एक वैकल्पिक मॉडल ट्रैक एक वास्तविक AI एजेंट — आपके OpenCode इंस्टॉलेशन द्वारा उपलब्ध कराया गया कोई भी मॉडल — को दो छोटी रिपॉज़िटरी के माध्यम से चलाता है और सार्वजनिक सतहों से अंतिम स्थिति का स्कोर करता है।
• अपग्रेड अक्ष — प्रत्येक रिलीज़ किए गए संस्करण के लिए 80 जाँच, दस रिपॉज़िटरी आकृतियों पर: प्रत्येक प्रकाशित रिलीज़ अपनी बाइनरी से एक रिपॉज़िटरी बनाती और लिखती है, फिर परीक्षणाधीन बाइनरी को उसे किसी पहचान को स्थानांतरित किए बिना, Scope Change की माँग किए बिना, या किसी औपचारिक एसेट को पुनः लिखे बिना संचालित करना होता है, और जो कुछ वह फिर लिखती है उसे किसी अन्य पथ पर चेकआउट को संरेखित रखना होता है; दसवीं आकृति में भूमिकाएँ बदल जाती हैं, और प्रत्येक प्रकाशित रिलीज़ को परीक्षणाधीन बाइनरी द्वारा लिखी गई रिपॉज़िटरी को बिना क्रैश या पुनः लिखे पढ़ना होता है। अन्य तीन सूट प्रत्येक फ़िक्सचर को परीक्षणाधीन बाइनरी से बनाते हैं, इसलिए संस्करणों के बीच बदला गया कोई प्रीइमेज उनके लिए रचना से ही अदृश्य रहता है।

उन्हें निर्मित बाइनरी के ऊपर केवल Python 3 और git चाहिए (MySQL सूट के लिए Docker; मॉडल ट्रैक के लिए OpenCode और आपकी अपनी मॉडल सदस्यता), इसलिए एक रिपॉज़िटरी क्लोन अपने स्वयं के बिल्ड, किसी प्लेटफ़ॉर्म पोर्ट, या किसी फ़ोर्क को सत्यापित कर सकता है — और AOCI_BIN अनुरूपता और परिदृश्य सूट को किसी भी वैकल्पिक बाइनरी की ओर इंगित कर सकता है जो spec/public/ में सार्वजनिक अनुबंधों का दावा करती है। ये सूट रिपॉज़िटरी क्लोन में रहते हैं; बाइनरी Release आर्काइव उन्हें शामिल नहीं करते। कमांड और परिणाम व्याख्या के लिए scripts/blackbox/README.md देखें।

अनुसंधान, बौद्धिक संपदा, और लाइसेंस

AOCI-CODE शोध पत्र और आर्टिफ़ैक्ट सार्वजनिक रूप से जारी विधियों, प्रायोगिक प्रोटोकॉल, और परिणामों का वर्णन कर सकते हैं। पेटेंट आवेदन, प्रदत्त दायरा, कानूनी स्थिति, स्वामी, और क्षेत्रीय प्रभाव कानूनी तथ्य हैं, और उन्हें किसी आंतरिक README, किसी ऐतिहासिक संस्करण संख्या, या किसी असत्यापित पुनर्कथन के आधार पर उत्पाद विवरणों में नहीं जोड़ा जाना चाहिए।

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

समुदाय

AOCI प्रोजेक्ट समूह में शामिल होने और मेंटेनरों तथा अन्य उपयोगकर्ताओं से बात करने के लिए WeChat या WeCom (企业微信) से कोड स्कैन करें। बग रिपोर्ट और फ़ीचर अनुरोध GitHub issues के रूप में दर्ज करें ताकि वे खोजने योग्य बने रहें, और संदिग्ध कमज़ोरियों की रिपोर्ट निजी रूप से करें जैसा SECURITY.md में वर्णित है, कभी भी समूह में नहीं।

AOCI-CODE एजेंट को अधिक कोड दिखाने के बारे में नहीं है। यह एजेंट को प्रत्येक क्रिया से पहले सिस्टम की एक वर्तमान, संरचित, अनुरेखणीय, और शासित समझ प्रदान करता है। Git आपके कोड का संस्करण बनाता है, डेटाबेस माइग्रेशन आपके डेटा संरचनाओं का संस्करण बनाते हैं, और AOCI-CODE उस ज्ञान के विकसित होने की अनुरेखणीयता, शासन संगति, और पुनर्प्राप्ति सीमाओं सहित, एजेंट जो सिस्टम के बारे में जानते हैं उसका संस्करण बनाता है।