डेवलपर का गुप्त बगीचा: स्थानिक ऑन्टोलॉजी LLMs को प्रॉम्प्ट इंजीनियरिंग के बिना कैसे संरेखित करती है

विषय-सूची

अवलोकन : प्रॉम्प्ट इंजीनियरिंग एक रेत का महल है
विश्वास के चार गोले: एक स्थानिक ओन्टोलॉजी
Pro/Contra : स्थानिक संरेखण बनाम प्रॉम्प्ट द्वारा संरेखण
- क्लासिकल दृष्टिकोण : प्री-प्रॉम्प्ट द्वारा संरेखण
- यह दृष्टिकोण: स्थानिक ऑन्टोलॉजी द्वारा संरेखण
Workspace की संबंधी बीजगणित और डेल्टा अवलोकनीय
संदर्भिक संयुक्त वेक्टर : RAG + pgvector + Graphify
स्वचालित जीडीपीआर वर्गीकरण: LLM को राउटर के रूप में
रोडमैप: एसकिईडॉक से लैंगग्राफ4ज तक
जो यह आर्किटेक्चर हल करता है (और जो यह हल नहीं करता है)
निष्कर्ष : वास्तुशास्त्र के रूप में विचारधारा
संदर्भ

pढ़ने का समय : 20 minutes

प्रॉम्प्ट इंजीनियरिंग नाजुक है। 80,000 टोकन पर, आपके संरेखण नियम शोर में खो जाते हैं, और LLM बातचीत की शुरुआत में आपने उससे क्या पूछा, वह भूल जाता है। मेरा समाधान? टेक्स्ट द्वारा संरेखित न करके, बल्कि l' द्वारा।स्थान. मैंने अपने विकास कार्यक्षेत्र को चार संकेन्द्रिक विश्वास के घेरे में संरचित किया — गुप्त íntिम बगीचे से सार्वजनिक भट्टियों तक — और प्रत्येक圈 फ़ाइल सिस्टम का एक भौतिक क्षेत्र है। LLM को नियमों की याद दिलाने की आवश्यकता नहीं है: फ़ाइल का पथ उन्हें समाहित करता है। यहाँ बताया गया है कि यह कैसे काम करता है, और यह स्थान-आधारित संरेखण वास्तुशिल्प एक से अधिक लचीला है`system prompt`500 लाइनों का.

यह एक लंबा लेख है।
आराम से बैठें।

अवलोकन : प्रॉम्प्ट इंजीनियरिंग एक रेत का महल है

तीन सप्ताहों के दौरान, मैंने Opencode के साथ Gradle प्लगइन विकसित किए, तीन अलग‑अलग LLMs का उपयोग करके — Kimi K2.6, GLM-5.1, और DeepSeek-V4-Pro (केवल एक जीवित, लेकिन यह एक और कहानीइसे पहले ही कवर कर लिया गया है।) मेरी एजेंट गवर्नेंस पद्धतiमैंने इसे एक पिछले लेख में विस्तार सेdocument किया है। AsciiDoc फ़ाइलों पर आधारित है —AGENT.adoc, INDEX.adoc, PROMPT_REPRISE.adoc— जो हर सेशन की शुरुआत में लगभग 30,000 नियमों, बैकलॉग और इतिहास के टोकन लोड करते हैं

और इस दस्तावेज़ी बुनियादी ढाँचे के बावजूद, दो बातें मुझे प्रभावित कीं :

LLM भूल जाता है। हर EAGER फ़ाइल के शीर्ष पर अटल नियम होने के बावजूद, 60,000 संचित टोकन से आगे (प्रारंभिक संदर्भ + बातचीत), Kimi K2.6 ने प्रस्ताव देना शुरू कर दिया`Write`भारी पड़ने वाले। GLM-5.1 ने एक Firebase टोकन को बदलने वाले प्लेसहोल्डर के साथ भ्रमित कर दिया। नियम लिखे गए थे — LLM अब उन्हें देख नहीं रहा था।
शासन स्वयं ही एक समस्या बन गया है。 हॉट/वॉर्म/कोल्ड तंत्र को लागू करने के बाद Article sur la rotation de backup. संदर्भ के विस्फोट से बचने के लिए, मेरी EAGER फ़ाइलें अभी भी 1414 पंक्तियों का वजन रखती थीं J’ai documenté cet audit ici.। शासन — LLM के संतृप्ति से बचाने के लिए डिज़ाइन किया गया — LLM को संतृप्त कर रहा था।

मुझे प्रॉम्प्ट में टोकन की संख्या पर निर्भर न करने वाला संरेखण तंत्र आवश्यक था।

जवाब: पाठ द्वारा संरेखित करना बंद करें, और l' के अनुसार संरेखित करना शुरू करेंस्थान.

विश्वास के चार गोले: एक स्थानिक ओन्टोलॉजी

मेरा फ़ाइल`workspace/(में~/workspace/`) नहीं pas एक गिट रिपॉज़िटरी है। यह मेरे सभी कार्य की जड़ है — कोड, दस्तावेज़ीकरण, प्रशिक्षण, बुनियादी संरचना। और इसे चार क्षेत्रों में संरचित किया गया है जो रखरखाव की परंपराएँ नहीं हैं, बल्किविश्वास के सकेन्द्रित वृत्त:

स्तर

लेबल

भौतिक क्षेत्र

CVS

दृश्यता

गुप्त बगीचा

`workspace/`जड़

कोई नहीं

निजी — स्वतंत्र विचार, कोई प्रतिबद्धता नहीं, कोई प्रकाशन नहीं

सेफ

configuration/

निजी Git (एकल)

गुप्त रहस्य, टोकन, दृष्टि आर्काइव। केवल एक व्यक्ति।

पुस्तकालय

office/

निजी गिट (विस्तारित)

शिक्षण डेटा, SPG/SPD, JSON स्कीमा. पहचाना गया विश्वास मंडल.

सार्वजनिक धातुकर्म

foundry/

सार्वजनिक Git (Apache 2.0)

स्रोत कोड, प्लगइन्स, परीक्षण, तकनीकी दस्तावेज़।

नोट: तालिका में स्तर 3 नहीं है। स्तर 3 एक अस्थायी स्तर है : यह सामग्री का है`office/`जिसका नाम नहीं दिया गया है और इसे ओपन डेटा के रूप में प्रकाशित करने के लिए तैयार है। इसका कोई भौतिक क्षेत्र नहीं है — यह डेटा की एक स्थिति है, कोई स्थान नहीं।

हर स्तर एक सटीक प्रश्न का उत्तर देता है:

कहाँ रखें एक विचार जो अभी साझा करने के लिए तैयार नहीं है, यहां तक कि एक छोटे समूह के साथ भी? → गुप्त बगीचा. कोई गिट नहीं. कोई दबाव नहीं.
API टोकन कहाँ रखें ताकि यह लीक न हो? → सुरक्षित तिजोरी (configuration/). भौतिक रूप से अलग. कोई अन्य रिपॉजिटरी इसे त्रुटिपूर्ण रूप से संदर्भित नहीं कर सकती।
OF पायलट के साथ प्रशिक्षण कैटलॉग सह-निर्माण कहाँ करें? → पुस्तकालय (office/). संस्करणित, सहयोगी, लेकिन निजी।
कहाँ एक खुला स्रोत Gradle प्लगइन को औद्योगीकृत करें? → धातुशालाएँ`foundry/`). सार्वजनिक, forkable, परीक्षित में CI.

यह ऑन्टोलॉजी हैLLM द्वारा उपभोग्य. जब वह एक फ़ाइल में पढ़ता है`foundry/plantuml-gradle/src/`, वहimplicit रूप से जानता है: "मैं सर्कल 4 में हूँ — सार्वजनिक कोड, अनिवार्य परीक्षण, कोई रहस्य नहीं, कोई शैक्षणिक डेटा नहीं।" उसे इस बात को याद दिलाने वाले प्रॉम्प्ट की आवश्यकता नहीं है।

गुप्त बगीचा: सीवीएस के बाहर का स्थान

यह सबसे महत्वपूर्ण अवधारणा है — और सबसे अधिक विपरीत अनुभव.

जड़`workspace/नहीं.git/. वहाँ रहने वाले दस्तावेज़ (`WORKSPACE_VISION.adoc, WORKSPACE_AS_PRODUCT.adoc, WORKSPACE_ORGANIZATION.adoc— और जो आप अभी पढ़ रहे हैं, जो उससे उत्पन्न है, उसे संस्करणित करने, साझा करने या फिर मेरे अलावा किसी और द्वारा पढ़ने के लिए नहीं बनाया गया है। ये हैंअंकुरित हो रहे विचार.

गुप्त बगीचा out-of-CVS प्रकृति से है। संस्करण की अनुपस्थिति सोचने की स्वतंत्रता की शर्त है। वहाँ लिखा नहीं जाता ताकि पढ़ा जा सके — वहाँ लिखा जाता है ताकि अपनी स्वयं की दृष्टि को स्पष्ट किया जा सके।

लेकिन यह स्वतंत्रता की एक कीमत है : एक`rm`अकस्मात, और ये रणनीतिक चिंतन के महीने गायब हो जाते हैं। हल यह नहीं है कि बगीचे को वर्शन करना (ऐसा करने से इसे नष्ट कर दिया जाएगा) — यह इसेदर्पण करनासबसे संकीर्ण मंडल में

.gitignore` को शासन कॉन्फ़िगरेशन के रूप में

जड़ में`workspace/, एक फ़ाइल.gitignore`न्यूनतम घोषित करता हैइतिहासीकृत करने की नीतिफ़ाइलें गुप्त बगीचे की :

.goosehints
.goose

Ce .gitignore`क्लासिक Git फ़ंक्शन नहीं है (कोई नहीं.git/`जड़ पर)। यह एक के रूप में कार्य करता हैशासन कॉन्फ़िगरेशन फ़ाइलजो एक सटीक प्रश्न का उत्तर देता है: गुप्त बगीचे की कलाकृतियों में कौन-से इतिहास में दर्ज किए जाने के योग्य हैं, और कौन-से केवल अस्थायी हैं ?

सूचीबद्ध फ़ाइलों`.gitignore`—.goosehints, .goose— वे एजेंट द्वारा उत्पन्न अस्थायी कलाकृतियाँ हैं। कोई रणनीतिक मूल्य नहीं। कोई इतिहासन नहीं।
फ़ाइलें`.adoc`जड़ का —WORKSPACE_VISION.adoc, WORKSPACE_ORGANIZATION.adoc, WORKSPACE_AS_PRODUCT.adoc, WHAT_THE_GAMES_BEEN_MISSING.adoc, depots_implementes_strategie.adoc, synthese-LLMs-long-contexte.adoc— हैंनहींमें`.gitignore`. ये ऐतिहासिक करने के लिए कलाकृतियाँ हैं।

Le `.gitignore`हैशासन ढाँचा: जो इस में सूचीबद्ध नहीं है, वह स्नैपशॉट का उम्मीदवार है। और LLM, इस फ़ाइल को पढ़ते हुए, ठीक-ठीक जानता है कि क्या संग्रहीत किया जाना चाहिए और क्या अनदेखा किया जा सकता है — बिना किसी प्रॉम्प्ट में इसे याद दिलाने की आवश्यकता के।

स्नैपशॉट मैकेनिज़्म

मैं बनाया हूँ`configuration/vision-archive/: सभी के दिनांकित स्नैपशॉट.adoc`मूल की, कमिट निजी रिपॉजिटरी में`configuration/`. हर ब्रेनस्टॉर्मिंग सत्र एक स्नैपशॉट उत्पन्न करता है :

DATE=$(date +%Y-%m-%d)
mkdir -p /home/cheroliv/workspace/configuration/vision-archive/$DATE
cp /home/cheroliv/workspace/*.adoc /home/cheroliv/workspace/configuration/vision-archive/$DATE/
cd /home/cheroliv/workspace/configuration && git add vision-archive/ && \
  git commit -m "vision-archive: snapshot $DATE"

प्रक्रिया को सत्र के अंत में LLM द्वारा स्वयं ट्रिगर किया जाता है, जो यह वैश्विक रूटिंग कार्य को निष्पादित करता है। प्रत्येक स्नैपशॉट समय T पर रणनीतिक चिंतन की पूर्ण स्थिति को कैप्चर करता है।

Git का इतिहास`configuration/`बनेगीमेरी रणनीतिक सोच की जीवनी. मैं एक कर सकता हूँ`git log — vision-archive/`और अपनी दृष्टि के विकास को देखें, सत्र दर सत्र, तारीख़ दर तारीख़।

एक काम के दिन के बाद के इतिहास का वास्तविक उदाहरण :

$ git -C configuration log --oneline -- vision-archive/
1089d1b vision-archive: fin de session finale 2026-05-03
6b21eaf vision-archive: fin de session 2026-05-03-1300
1690f82 vision-archive: post-article 2026-05-03
28e6593 vision-archive: post-migration 2026-05-03
3707b78 vision-archive: snapshot 2026-05-03 — jardin secret initial

एक दिन में पाँच स्नैपशॉट। प्रत्येक एक पुनर्स्थापना बिंदु है। प्रत्येक रणनीति की उत्पत्ति में एक मील का पत्थर है।

फ़ाइल`configuration/vision-archive/latest/`हमेशा एक रखता हैकार्य प्रतिलिपिअंतिम स्नैपशॉट का, त्वरित संदर्भ के रूप में कार्य करता, गिट इतिहास में नेविगेट करने की आवश्यकता नहीं

LLM के लिए, यह एकसुसंगति का ओरेकल: जब वह वर्तमान कार्यान्वयन और एक पुरानी तारीख़ में संग्रहीत दृष्टि के बीच कोई विरोधाभास देखता है, तो वह इसे संकेत कर सकता है।

वॉल्ट: `configuration/` Spring Cloud Config की तरह

`configuration/`यह केवल दृष्टि के संग्रह को नहीं रखता है। इसका प्राथमिक — और भविष्य का — कार्य एक बनना है।Spring Cloud Config सर्वर. सभी रहस्य, टोकन, क्रेडेंशियल्स और इंफ़्रास्ट्रक्चर विवरण यहाँ रहते हैं, निजी Git रिपॉज़िटरी में, जो केवल मालिक द्वारा सुलभ है।

एक फ़ाइल के बजाय एक अलग रिपॉज़िटरी क्यों?`.env`हर परियोजना में ?

अकस्मात् सीक्रेट को पुश : असंभव। सीक्रेट एक निजी रिपॉजिटरी में हैं, जिन्हें सार्वजनिक प्रोजेक्ट त्रुटि से संदर्भ नहीं कर सकते।
ऑडिट : Git का इतिहास प्रत्येक कॉन्फ़िगरेशन परिवर्तन का रिकॉर्ड देता है। किसने क्या बदलाया, कब, किस SHA हैश के साथ।
पुनःस्थापना :`git revert`एक टूटी हुई कॉन्फ़िगरेशन पर। स्नैपशॉट, मैनुअल बैकअप के बिना।

लाइब्रेरी: `office/` उपभोग्य डेटा

`office/`यह विकास कार्य का दस्तावेज़ी पूरक है। इसमें ब्लॉग पोस्ट, तकनीकी विशिष्टताएँ, प्रशिक्षण सामग्री (FPA, SPG/SPD के 38 पाठ्यक्रम निर्देशिकाएँ, JSON स्कीमा, ब्लूम/हैरो/क्रैथवेल की वर्गीकरण) — सब कुछ जो इसका हिस्सा बनाता है।शिक्षण सामग्री.

लेकिन`office/`यह केवल दस्तावेज़ों का ड्रॉअर नहीं है। यह एकसंरचित डेटा स्रोतque ग्रैडल प्लगिन्स के`foundry/`वे उपभोग करते हैं. एक ब्लॉग पोस्ट में`office/`यह एक प्रविष्टि है जिसे एक प्लगइन HTML में परिवर्तित करेगा। SPG एएससीआईडॉक में`office/metiers/FPA/`यह एक कलाकृति है जिसे एक ऑर्केस्ट्रेटर पार्स करके स्लाइड्स, क्विज़ और वीडियो कैप्सूल उत्पन्न करेगा।

Et le `build.gradle.kts`की जड़ में`office/`यह व्यावसायिक कोड नहीं है — यह एकप्लगिन इकोसिस्टम की खपत स्क्रिप्ट. वह कहता है: \"ये वो Gradle प्लगइन हैं जिनका मैं उपयोग करता हूँ, यहाँ मेरे वर्कस्पेस का संदर्भ है।\

फ़ोर्ज़ : `foundry/` जैसा कार्यान्वयन

foundry/`शामिल हैऔद्योगिक कोड. 54 Git रिपॉज़िटरी, जिनमें से 7 वर्तमान में शासित हैं.agents/`. यहाँ दृष्टि कार्यान्वित होती है — Gradle प्लगइन, CI/CD, JUnit5 + Cucumber परीक्षण

संबंध के साथ`office/`द्विदिशात्मक है :

office/→foundry/: शैक्षिक डेटा कच्चा माल है जो प्लगइन्स उपभोग करते हैं।
foundry/→office/: प्लगइन्स डेटा उत्पन्न करते हैं जो समृद्ध बनाता है`office/` — le `graph.json`graphify-gradle के, संकलित स्लाइडर डेक, बिल्ड रिपोर्ट

Pro/Contra : स्थानिक संरेखण बनाम प्रॉम्प्ट द्वारा संरेखण

दोनों दृष्टिकोणों की तुलना करते हैं।

क्लासिकल दृष्टिकोण : प्री-प्रॉम्प्ट द्वारा संरेखण

✅ पेशेवर

❌ के खिलाफ

इसे लागू करना सरल है। सिस्टम प्रॉम्प्ट में एक टेक्स्ट ब्लॉक।

लंबे संदर्भ के प्रति नाजुक : नियम 80K टोकन के बाद डूब जाता है

सामान्य नियमों (टोन, प्रारूप) के लिए काम करता है।

असत्यापन योग्य : कुछ भी LLM को नियम का उल्लंघन करने से नहीं रोकता।

प्रोजेक्ट की आर्किटेक्चर को फिर से सोचने की आवश्यकता नहीं है।

Non transférable : प्रत्येक repo नियमों को फिर से घोषित करता है।

शुद्ध रूप से घोषणात्मक : LLM जानता है कि यह करना चाहिए, लेकिन कुछ भी इसे रोक नहीं सकता।

यह दृष्टिकोण: स्थानिक ऑन्टोलॉजी द्वारा संरेखण

पेशेवर

विरुद्ध

दीर्घ संदर्भ के लिए लचीला : नियम फ़ाइल के पथ में है, दूर के प्रॉम्प्ट में नहीं।

प्रारंभिक बुनियादी ढाँचा लागत : वर्कस्पेस को गोलों में संरचित करने में समय लगता है।

यांत्रिक रूप से सत्यापित : एक रहस्य में`foundry/का पता लगाया जा सकता है`git check-ignore.

आवश्यक अनुशासन : एक नया योगदानकर्ता को सर्किलों को समझना चाहिए।

हस्तांतरणीय : एक`AGENT.adoc`मानक किसी भी नए प्रोजेक्ट के लिए सर्कल को उजागर करता है।

केवल स्थानिक सीमाओं को कवर करता है — कोड शैली प्रॉम्प्ट में बनी रहती है

सुरक्षा डिज़ाइन द्वारा : एक`git push`से`foundry/प्रदर्शित नहीं कर सकता`configuration/.

गैर-LLM एजेंट्स द्वारा उपयोग करने योग्य : एक Gradle ऑर्केस्ट्रेटर सर्किल के अनुसार रूट कर सकता है।

मुख्य लाभ रक्षात्मक नहीं (सुरक्षा, दृश्यता) — यहरचनात्मक. जब LLM एक ontologie द्वारा संरचित स्थान में काम करता है, तो वह ऐसा कर सकता है जो कोई भी प्रॉम्प्ट उसे अनुमति नहीं देता: डेल्टा का अवलोकन

Workspace की संबंधी बीजगणित और डेल्टा अवलोकनीय

जब LLM घूमता है`foundry/, यह एकसंरचित डेटा ग्रिड: नोड (प्लगइन, फ़ाइलें, परीक्षण, निर्भरताएं), टाइप्ड किनारे (`import, depends_on, generates, tests), संघटन और क्रम के संबंध (`training-gradle`रेपॉज़िटरी निकालें →`slider-gradle`स्लाइड्स बनाता →`capsule-gradle`वीडियो अपलोड करो)

यह बीजगणित किसी भी स्थान पर स्पष्ट रूप से नहीं लिखा गया है — लेकिन यह प्रेक्षणीय है। प्रत्येक`build.gradle.kts`निर्भरताओं को उजागर करता है। प्रत्येक`INDEX.adoc`क्रोस-रेफ़रेंस प्रस्तुत करता है।

LLM इस बीजगणित को देखता है और इसका पता लगाता हैडेल्टा: प्रणाली द्वारा पहले से उत्पादन करने में सक्षम चीज़ और दृष्टि द्वारा वर्णित चीज़ के बीच का अंतर

इस डेल्टा से, वह कुछ परिभाषित कर सकता हैविशेषज्ञ व्यापार मानचित्र— CDA (एप्लिकेशन डिज़ाइनर डेवलपर, Kotlin/Gradle/JHipster) और FPA (व्यावसायिक वयस्क प्रशिक्षक, शिक्षाशास्त्र/Qualiopi/Bloom) — और प्रत्येक विशेषज्ञ के लिए कमी की पहचान करना

Expert CDA (Kotlin/Gradle/JHipster)
  ├── Plugins : jhipster-gradle-plugins, plantuml-gradle,
  │   codebase-gradle
  ├── Delta : pas encore de SPG CDA formalisé,
  │   pas de fine-tuning expert CDA

Expert FPA (Pédagogie/Qualiopi/Bloom)
  ├── Plugins : training-gradle, slider-gradle,
  │   school-backoffice/forms, capsule-gradle
  ├── Matériel : 38 modules cours, SPG/SPD, taxonomies
  └── Delta : parser AsciiDoc→JSON à créer,
      orchestrateur à coder

LLM को बताने की ज़रूरत नहीं है कि क्या करना है। डेल्टा संरचना से उभरता है।

संदर्भिक संयुक्त वेक्टर : RAG + pgvector + Graphify

संबंधी बीजगणित एक सैद्धांतिक अवधारणा नहीं है। यह तीन घटकों द्वारा साकार है जो एकसंयुक्त संदर्भ वेक्टरLLM के लिए

घटक 1 — RAG LangChain4j + PostgreSQL pgvector

मैंने पहले से ही दो प्लगइन्स में LangChain4j को उत्पादन में लागू कर दिया है :`slider-gradle`(4 providers LLM) और`plantuml-gradle`(7 प्रदाता)। एम्बेडिंग ONNX (AllMiniLmL6V2) डेटा को सूचकांकित करते हैं`office/`और स्रोत कोड का`foundry/`PostgreSQL + pgvector में.

यह RAG दो आयामों पर संचालित होता है :

Dimension data : दस्तावेज़`office/`(SPG, लेख, प्रशिक्षण, JSON स्कीमा)
Dimension कोड : कोडबेस`foundry/`(sources Kotlin, tests Cucumber, AGENT.adoc)

इंटरसेक्शन दोनों क्या (व्यवसाय डोमेन) और कैसे (कार्यान्वयन) को कवर करता है।

घटक 2 — ज्ञान ग्राफ़ ग्राफ़ाइ

Graphify में एकीकृत`plantuml-gradle`(109 परीक्षण, 380/380 PASS) और एक उत्पन्न करता है`graph.json`— एक संरचित knowledge graph जिसमें नोड्स, किनारे, और स्वचालित रूप से पहचाने गए समुदाय शामिल हैं।

RAG के विपरीत, जो वेक्टर समानता (फ़ुज़ी) द्वारा संचालित होता है, ज्ञान ग्राफ़ द्वारा संचालित होता हैसटीक संबंध(निर्धारित) :`graphify query`सार्थक प्रश्नों के लिए (~50 टोकन),`graphify path`नेविगेट करने के लिए`graphify explain`spiegations.

घटक 3 — Graphify इंक्रीमेंटल : वितरित, संचयनीय, उपभोग्य

यह मुख्य आर्किटेक्चरल निर्णय है।

Graphify को केवल एक भंडार में नहीं रहना चाहिए। इसे इस प्रकार रहना चाहिए।बिखराहर प्लगइन में:

हर प्लगिन में एक Gradle कार्य शामिल है`updateKnowledgeGraph`जो Graphify को बुलाता हैअपने दायरे परऔर एक उत्पन्न करता है`graph.json`स्थानीय.
*बिल्ड स्क्रिप्ट का`office/उपभोग करता है`graphify-gradle`के साथ`rootDir = /home/cheroliv/workspace`और बनाता है एक`graph.json वैश्विकजो स्थानीय ग्राफ़ों को एकत्र करता है।
हर प्लगइन का RAG इंजेक्ट करता है इसको`graph.json`वैश्विक जैसेसंदर्भ फ़िल्टरLLM क्वेरीज के लिए

TÂCHE GRADLE (dans chaque plugin)
    ↓
graphify → graph.json (scope local)
    ↓
office/build.gradle.kts → graph.json (scope global)
    ↓
RAG pgvector (dans slider, plantuml, codebase...)
    ↓  ← injection du graph.json comme filtre
LLM (deepseek-v4-pro)
    ↓  ← observation algèbre relationnelle
    ↓  ← détection delta vs cartographies experts
PRIORISATION → prochaine tâche

परिणाम: LLM खाली में नहीं खोज रहा — वह knowledge graph द्वारा संरचित एक स्थान में नेविगेट करता है। एक क्वेरी "génère un diagramme" संबंधित ग्राफ के नोड्स तक पहुँचने में सक्षम है।

स्वचालित जीडीपीआर वर्गीकरण: LLM को राउटर के रूप में

स्थानिक ओन्टोलॉजी केवल LLM को संरेखित नहीं करती — यह उसे एकRGPD वर्गीकरण ग्रिडहर डेटा को उसकी वैध ज़ोन में रूट करने के लिए

मानदंड

LLM का पता लगाना

क्रिया

अधिकतम स्तर

व्यक्तिगत डेटा (नाम, ईमेल, आईपी)

पैटर्न`@`, IP, विशेष संज्ञा

अनामिक बनाओ →`[OF_PILOTE]`या राउटर लेवल 2

टोकन / गुप्त / क्रेडेंशियल

पैटर्न`sk-…, `ghp_…, ya29…

राउटर →configuration/. द्वारा संदर्भित`${VAR}`कोड में.

आंतरिक URL

शामिल है`localhost`, IP निजी

अनामिक बनाना →${API_URL}

शैक्षिक डेटा (SPG, कोर्स)

Structure Bloom/Qualiopi

राउटर →office/(स्तर 2). दोहरा संस्करण यदि निर्यात।

स्रोत कोड / परीक्षण

विस्तार`.kt`, .kts`में`foundry/

राउटर →foundry/. रहस्य की अनुपस्थिति की जाँच करें

सत्र के अंत में, LLM एक निष्पादित करता हैवैश्विक कार्य:

पढ़ने का`.gitignore`अस्थायी कलाकृतियों की पहचान करने के लिए जड़ (स्नैपशॉट से बाहर रखने के लिए) बनाम रणनीतिक कलाकृतियों (इतिहास में रखने के लिए)
सभी फ़ाइलों का अन्वेषण`.adoc`जड़ की`workspace/`
फ़िल्टरिंग: सूचीबद्ध फ़ाइलों का अपवर्जन`.gitignore`, सभी अन्य लोगों का समावेश
कॉपी में`configuration/vision-archive/$DATE/et सिमलिंक का अपडेट`latest/
रिपॉजिटरी में कमिट`configuration/`एक संरचित संदेश के साथ
स्वचालित GDPR वर्गीकरण प्रत्येक संशोधित फ़ाइल का (सभी वृत)
रूटिंग : डेटा`office/→ निज़ी कमिट, कोड`foundry/→./gradlew check, कन्फ़िगरेशन → कमिट
संरचित रिपोर्ट GDPR अलर्ट और अभिलेखीकरण की पुष्टि के साथ

Le `.gitignore`रूट एक Git कॉन्फ़िगरेशन फ़ाइल नहीं है — यह एकइतिहासिकरण का प्रशासन फ़ाइल. यह वह स्कीमा परिभाषित करता है जो LLM द्वारा उपभोग की जाती है ताकि तय किया जा सके कि गुप्त बगीचे की कौन सी फ़ाइलें रणनीतिक जीवनी में शामिल की जाएँ और कौन सी फ़ाइलें त्याग दी जाएँ।

LLM अब केवल एक टेक्स्ट जनरेटर नहीं है। यह हैसूचना प्रबंधकइकोसिस्टम का — उत्पादक, वर्गीक्षक, राउटर.

रोडमैप: एसकिईडॉक से लैंगग्राफ4ज तक

आज, यह शासन निर्धारक : LLM एक प्रक्रिया लागू करता है AsciiDoc फाइलों में वर्णित है। यह हैफ़ेज़ 1— LLM स्मृति के साथ प्रॉम्प्ट इंजीनियरिंग.

La फ़ेज़ 2प्रक्रिया के प्रत्येक चरण में एक निकाल देगाटाइप्ड ग्रैडल टास्क:

./gradlew endSessionWorkspace    → snapshot vision-archive
./gradlew endSessionProject      → archive .agents/
./gradlew endSessionReport       → rapport multi-zones

La चरण 3सत्र समाप्ति प्रक्रिया को एक के रूप में मॉडल करेगास्थिति ग्राफके साथhttps://github.com/langgraph4j/langgraph4j[LangGraph4j]:

[Start] → [Inventaire fichiers modifiés]
       → [Classification RGPD] (nœud ONNX)
       → [Branchement par cercle]
            ├→ cercle 0 → snapshot → commit
            ├→ cercle 2 → anonymisation → commit
            ├→ cercle 4 → archive → commit
            └→ cercle 1 → commit configuration/
       → [Rapport] → [End]

यह ग्राफ़ CI/CD में version किया जाएगा, Gradle द्वारा निष्पादित होगा, प्लगइन के GitHub Secrets के माध्यम से सेट किया जाएगा। अब LLM को रूटिंग निर्णय लेने की ज़रूरत नहीं होगी — ग्राफ़ यह करेगा।

जो यह आर्किटेक्चर हल करता है (और जो यह हल नहीं करता है)

स्थानिक ऑन्टोलॉजी सब कुछ नहीं कवर करती। कोड स्टाइल कन्वेंशन, नामकरण, आर्किटेक्चरल डिज़ाइन के विकल्प — ये सब प्रॉम्प्ट में रहते हैं। जो स्थानिक ऑन्टोलॉजी हल करती है, वो हैसुरक्षा और दृश्यता की परत: जहाँ हर बाइट को रहना चाहिए, और जो इसे देख सकता है।

यहाँ वह क्या ठोस रूप से लाती है:

नहीं`git push`आकस्मिक रहस्य : रहस्य में हैं`configuration/(वृत्त 1). सार्वजनिक परियोजनाएँ में हैं`foundry/(वृत्त 4). कोई भी मार्ग दोनों को नहीं पार करता।
कोई व्यावसायिक कोड डेटा में नहीं :`office/कुछ रखता है.adoc`, कुछ YAML, कुछ JSON स्कीमा — लेकिन नहीं`.kt`. Le `build.gradle.kts`जो वहां रहता है, वह उपभोग स्क्रिप्ट है, व्यवसाय कोड नहीं।
कोई रणनीतिक सोच प्रकट नहीं : दृष्टि दस्तावेज़ गुप्त बगीचे में रहते हैं (CVS के बाहर जड़)। स्नैपशॉट्स में हैं`configuration/`(निजी तिजोरी). कोई भी, विस्तारित विश्वास के वृत्त में भी, रणनीति की उत्पत्ति नहीं पढ़ता।
Auto-priorisation : एलएलएम संबंधी बीजगणित (जो मौजूद है) और विशेषज्ञ मानचित्रों (जो आवश्यक है) के बीच के डेल्टा का अवलोकन करता है। अगला विकास कार्य इस डेल्टा से उभरता है।

निष्कर्ष : वास्तुशास्त्र के रूप में विचारधारा

मैं अपने साइट के फुटर में राजनीतिक घोषणापत्र नहीं रखता। मैं अपने प्रॉम्प्ट में नैतिक नियम नहीं रखता। संरेखण पाठ में नहीं है — यह इसमें हैफ़ाइल सिस्टम.

जब एक LLM इस स्थान में काम कर रहा है, तो वह किसी रहस्य को लीक नहीं कर सकता (रास्ता इसे रोकता है)। वह किसी शैक्षिक डेटा को स्रोत कोड के साथ गलत नहीं समझ सकता (भौतिक क्षेत्र अलग है)। वह 80,000 टोकन की एक सुरक्षा नियम को भूल नहीं सकता — क्योंकि नियम प्रॉम्प्ट में नहीं है, वह उसमें है`workspace/→`configuration/→office/→`foundry/`que प्रत्येक फ़ाइल पढ़ने पर यह सक्रिय हो जाता है।

यह secure by design का सिद्धांत एजेंट संरेखण पर लागू किया गया है: LLM से नियम याद रखने के लिए नहीं कहना। इस बात का ध्यान रखना कि आर्किटेक्चर त्रुटि को संरचनात्मक रूप से असंभव बना दे।

इसी के साथ, यह LLM को वह देता है जो कोई भी प्रॉम्प्ट उसे नहीं दे सकता: उसकी क्षमतापहचाननावह कहाँ है, क्या मौजूद है, क्या कमी है — और उससे यह निर्धारित करना कि उसे क्या करना चाहिए।

संदर्भ

एगर/लेस्ज़ी एजेंट गवर्नेंस पर लेख :एक AI एजेंट को AsciiDoc के साथ नियंत्रित करना
हॉट/वर्म/कोल्ड तंत्र पर लेख:Sliding Window और ठंडी लहर
संदर्भ ऑडिट पर लेख:जब आपका अपना शासन समस्या बन जाता है
तीन LLMs की तुलना पर लेख:DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1