ओएसएस/सीएसएस ग्रैन्युलेशन — मैंने फाउंड्री/ को दो हिस्सों में क्यों विभाजित किया।

विषय-सूची

वह दुर्घटना जो होने वाली थी
- सच्चा प्रश्न
समाधान : OSS/ और CSS/
क्यों "OSS" और "CSS" और नहीं "Public" और "Private
- पूर्ण वृक्ष — चार क्षेत्र, नहीं तीन
विशेष मामला : cheroliv.com
- bakery-gradle परवाह नहीं
गवर्नेंस एजेंट पर प्रभाव
हम क्या कमाते हैं (और क्या हम खो देते हैं)
निष्कर्ष: भौतिक संकेत सॉफ़्टवेयर संकेत को हराता है
संदर्भ

पढ़ने का समय : 10 minutes

foundry/— वह कार्यात्मक क्षेत्र जो मेरे वर्कस्पेस के कोड को होस्ट करता है — इसमें 18 परियोजनाएँ हैं। आठ खुला स्रोत Apache 2.0 के तहत हैं। केवल एक बंद स्रोत — SaaS एडस्टर. कई महीनों तक, ये नौ परियोजनाएं साथ रही हैं एक ही फ़ोल्डर में, केवल … द्वारा कुछ भी नहीं से अलग। उनकी सार्वजनिक/निजी स्थिति यह मेरे दिमाग में जानकारी थी, फ़ाइल सिस्टम में नहीं।

और फिर मैंने एक RAG को जोड़ना चाहा। और फिर, सब कुछ गिर गया।

वह दुर्घटना जो होने वाली थी

अप्रैल 2026 में, मैंने slider-gradle के लिए pgvector RAG को लागू करना शुरू कर दिया। सिद्धांत: सभी भंडारों को इंडेक्स करना`foundry/, उत्पादन करना एम्बेडिंग्स, और उन्हें LLM के संदर्भ में इंजेक्ट करें ताकि इसके पास एक फ़ाइल की "perception`foundry/.

पाइपलाइन सरल थी :

val repos = fileTree(rootDir) {
    include("**/*.adoc", "**/*.kts", "**/*.kt", "**/*.json", "**/*.yml")
}
val chunks = repos.map { chunk(it) }
val embeddings = chunks.map { embed(it) }
pgvector.insert(embeddings)

सरल। प्रभावी। औरखतरनाक.

क्योंकि यह`fileTree`भेद नहीं करता`plantuml-gradle/` (Apache 2.0, public) और`edster/`(बंद स्रोत, निजी). वह सब कुछ निगल जाता है. और अगर एक दिन मैं ये एम्बेडिंग्स प्रकाशित करता हूँ — एक डैशबोर्ड पर, एक उत्तर में LLM, एक प्रशिक्षण डेटासेट में — Edster का मालिकाना कोड लीक हो रहा है।

समस्या यह नहीं है कि एक LLM बंद स्रोत कोड पढ़े। समस्या, यह है कि यह कोड एक सार्वजनिक वेक्टर एम्बेडिंग में समाप्त हो जाए — अपरिवर्तनीय, हटाया नहीं जा सकता, ऑडिट नहीं किया जा सकता।

सच्चा प्रश्न

यह "LLM द्वारा कोड लीक होने से कैसे रोकें?" नहीं है। यह "कैसे" है। भागने को संरचनात्मक रूप से असंभव बनाया जा सकता है?

जवाब एक प्रॉम्प्ट नहीं है। जवाब यह है कि फोल्डर को दो भागों में काटना।

समाधान : OSS/ और CSS/

पहले :

foundry/
├── plantuml-gradle/       ← public
├── bakery-gradle/         ← public
├── magic-stick/           ← public
├── edster/                ← PRIVÉ
├── slider-gradle/         ← public
└── ...                    ← mélange invisible

बाद :

foundry/
├── OSS/                   ← tout est Apache 2.0
│   ├── plantuml-gradle/
│   ├── bakery-gradle/
│   ├── magic-stick/
│   ├── slider-gradle/
│   └── ...
└── CSS/                   ← tout est closed source / private
    └── edster/

Le `fileTree`बन जाता है :

val ossRepos = fileTree(File(rootDir, "OSS")) {
    include("**/*.adoc", "**/*.kts", "**/*.kt", "**/*.json", "**/*.yml")
}
val cssRepos = fileTree(File(rootDir, "CSS")) {
    include("**/*.adoc", "**/*.kts", "**/*.kt", "**/*.json", "**/*.yml")
}

// Embeddings publics — OSS seulement
pgvectorPublic.insert(ossRepos.map { chunk(it) }.map { embed(it) })

// Dataset fine-tuning privé — CSS seulement
fineTuningDataset.insert(cssRepos.map { chunk(it) })  // jamais publié

सार्वजनिक RAG कभी नहीं देखता`CSS/`. बंद स्रोत कोड एक डेटासेट प्रदान करता है फ़ाइन-ट्यूनिंग से वंचित — एक आंतरिक मॉडल जो मेरे घर से कभी बाहर नहीं जाता। La विच्छेद यांत्रिक है, घोषणात्मक नहीं।

क्यों "OSS" और "CSS" और नहीं "Public" और "Private

OSS (Open Source Software) और CSS (Closed Source Software) के संक्षेप का चयन इरादतन है :

Public"/"Private" का वर्णन करता हैदृश्यता(GitHub क्या देखता है)
OSS"/"CSS" वर्णन करता हैप्रकृतिकोड (जिसे LLM को जानना चाहिए)

GitHub की दृश्यता दूरस्थ रिपॉजिटरी का एक मेटाडेटा है। कोड की प्रकृति सामग्री की एक संपत्ति। LLM के पास GitHub API तक पहुँच नहीं है — लेकिन उसके पास पहुँच है फ़ाइल सिस्टम को.CSS/`उस्हा कहा "सावधान, यह कोड लाइसेंस के तहत नहीं है मुक्त" बिना पढ़े एक`LICENSE`ou को पार्स करने का`package.json.

फ़ोल्डर का नाम वह सबसे मजबूत मेटाडेटा है जो आप दे सकते हैं एक LLM. इसे गलत तरीके से पार्स नहीं किया जा सकता, अनदेखा नहीं किया जा सकता, या गलत तरीके से नहीं समझा जा सकता। यह LLM. देखता है`CSS/edster/`फ़ाइल के पथ में — वह जानता है

पूर्ण वृक्ष — चार क्षेत्र, नहीं तीन

OSS/CSS ग्रैन्युलराइजेशन तीन क्षेत्र ontोलॉジー पूरा करता है। क्षेत्र `foundry/`1 से 2 तक कार्यात्मक उप-क्षेत्र:

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 260

title Organisation de foundry/ — Granularisation OSS/CSS

package "foundry/" {

  package "वृत्त 0 — मूल" #FFCCCC {
    rectangle "PICTURE_ME_ROLLIN_*.adoc" as STIM
    rectangle "WORKSPACE_*.adoc" as VISION_DOC
    note right of STIM
ब्रेन डम्प मुक्त
कभी संस्करणित नहीं
[LLM : interdit d'indexer]
    end note
  }

  package "Cercle 1 — configuration/" #FFD9CC {
    rectangle "Secrets, tokens" as SECRETS
    rectangle "Spring Cloud Config" as SCC
    note right of SECRETS
निजी-CVS, एकल एक्सेस [LLM : INTERDIT]
    end note
  }

  package "Cercle 2 — office/" #FFFFCC {
    rectangle "Articles, cadrages" as DATA
    rectangle "Formations, SPG/SPD" as FORM
    note right of DATA
निजी-CVS
[LLM : filtré Vision/Opinion]
    end note
  }

  package "Cercle 3 — foundry/" #CCE5FF {
    package "OSS/ — Apache 2.0" #CCFFCC {
      rectangle "Plugins Gradle" as PLUGINS
      rectangle "engine" as ENGINE
    }
    package "CSS/ — Closed Source" #CCDDFF {
      rectangle "edster/" as EDSTER
    }
  }
}

@enduml

विशेष मामला : cheroliv.com

मैं वहाँ था, तब मैंने एक और असंगति को ठीक किया। मेरी साइट cheroliv.com`वह रहता था`foundry/`जैसे एक सॉफ्टवेयर परियोजना पूरी तरह से — अपने स्वयं के Gradle बिल्ड के साथ, अपनी स्वयं की CI, अपनी स्वयं की शासन.agents/`.

लेकिन ब्लॉग पोस्ट कोड नहीं हैं। ये डेटा सम्पादकीय सर्कल 2 का — के समान फ्रेमिंग का`office/pilotage/` या समूहों का`office/formations/`.

AVANT                            APRÈS
foundry/                office/
  cheroliv.com/                    sites/
    site/jbake/content/blog/         cheroliv.com/
      2026/0117_....adoc               2026/0117_....adoc

जो बदलता है :

वस्तुएं हैं में`office/`→ Cercle 2 की गोपनीयता
कार्य`publishSite`बन जाता है एक capability का`engine`

के माध्यम से`bakery-gradle`— प्लगइन एक प्राप्त करता है`FileTree`, वह नहीं जानता कि वस्तुएँ … से आती हैं`office/`

एक ही CI, एक ही शासन — शून्य डुप्लिकेशन
विज़न/ओपिनियन वर्गीक्षक (नियम 2bis) स्वचालित रूप से लागू होता है:

लेखों में`office/`प्रकाशन से पहले फ़िल्टर किए जाते हैं

bakery-gradle परवाह नहीं

और यही सुंदर है। प्लगइन`bakery-gradle`यह संशोधित नहीं किया गया। वह AsciiDoc सामग्री निर्देशिका प्राप्त करता है, यह HTML उत्पन्न करता है, यह पुश करता है GitHub Pages पर। कि इस निर्देशिका का नाम`site/jbake/content/` ou office/sites/cheroliv/— प्लगिन को परवाह नहीं है।

// engine/build.gradle.kts
task("publishBlog") {
    doLast {
        val articles = fileTree("../../office/sites/cheroliv/2026/")
        bakery.generate(articles)  // ← bakery ne sait pas d'où ça vient
    }
}

इंटरफ़ेस अनुबंध एक Gradle कार्य है। यह एक REST API नहीं है। यह एक वेबहुक नहीं है। एक कार्य — टाइप्ड, टेस्टेबल, स्थानीय रूप से और CI में निष्पादन योग्य।

गवर्नेंस एजेंट पर प्रभाव

OSS/CSS ग्रैन्युलरीकरण एजेंट गवर्नेंस को तीन बिंदुओं पर बदलता है:

RAG public : इंडेक्सिंग परिधि से गुजरता है`foundry/**`

à foundry/public/+office/Vision/. बंद स्रोत कोड इसे कार्य कॉन्फ़िगरेशन द्वारा सूचकांक से बाहर रखा जाता है, प्रॉम्प्ट द्वारा नहीं।

Knowledge Graph : graphify-gradle दो ग्राफ़ उत्पन्न करता है :

*office/graph.json(सार्वजनिक) — कल्पित वस्तुएं OSS + office/Vision के बीच संबंध *configuration/graph_private.json(gitignored, निजी) — संबंधों के बीच CSS कलाकृतियाँ, कभी प्रकाशित नहीं

डेटासेट फाइन-ट्यूनिंग :`codebase-gradle`अब इसके दो स्रोत हैं :

*OSS/→ सार्वजनिक डेटासेट (समुदाय मॉडल, बेंचमार्क) *CSS/→ निजी डेटासेट (आंतरिक मॉडल, स्वामित्व वाला फाइन-ट्यूनING)

हम क्या कमाते हैं (और क्या हम खो देते हैं)

पहले (सतही फ़ाइल) (OSS/CSS + office/sites) के बाद

पहले (सतही फ़ाइल)	(OSS/CSS + office/sites) के बाद
`ls foundry/`→ सार्वजनिक/निजी मिश्रण	`ls foundry/public/`सब कुछ प्रकाशनीय है
RAG सब कुछ भेदभाव के बिना इंडेक्स करता है	RAG अनुक्रमित करता`OSS/`+`office/Vision`केवल
जानना असंभव है कि क्या कोई प्रोजेक्ट ओपन सोर्स है	पथ`OSS/` ou `CSS/`कहा गया
cheroliv.com की अपनी CI, अपनी शासन	CI और governance को engine में साझा किया गया
ब्लॉग पोस्ट कोड भंडार में हैं	ब्लॉग पोस्ट में हैं`office/sites/`— डेटा, कोड नहीं
सार्वजनिक एम्बेडिंग में बंद स्रोत कोड के रिसाव का जोखिम	संरचनात्मक रूप से असंभव —`CSS/`RAG के दायरे से बाहर

ls foundry/→ सार्वजनिक/निजी मिश्रण

`ls foundry/public/`सब कुछ प्रकाशनीय है

RAG सब कुछ भेदभाव के बिना इंडेक्स करता है

RAG अनुक्रमित करता`OSS/`+`office/Vision`केवल

जानना असंभव है कि क्या कोई प्रोजेक्ट ओपन सोर्स है

पथ`OSS/` ou `CSS/`कहा गया

cheroliv.com की अपनी CI, अपनी शासन

CI और governance को engine में साझा किया गया

ब्लॉग पोस्ट कोड भंडार में हैं

ब्लॉग पोस्ट में हैं`office/sites/`— डेटा, कोड नहीं

सार्वजनिक एम्बेडिंग में बंद स्रोत कोड के रिसाव का जोखिम

संरचनात्मक रूप से असंभव —`CSS/`RAG के दायरे से बाहर

एकमात्र लागत: एक`git mv`17 OSS भंडारों पर वैश्विक + एक रिफ़ैक्टर का build.gradle.kts de engine. यह एक ठंडा माइग्रेशन है — कोई डेटा उड़ान में नहीं, कोई प्रभावित उपयोगकर्ता नहीं.

निष्कर्ष: भौतिक संकेत सॉफ़्टवेयर संकेत को हराता है

मैंने इस दोपहर जो किया, वह एक अदृश्य परम्परा को बदलना था। क्षेत्र में एक दृश्यमान अलगाव से`foundry/. पहले, आपको करना पड़ता था जानना कि`edster/`était closed source था। अब आप इसे देख रहे हैं — फ़ाइल का नाम`CSS/.

यह वही सिद्धांत है कि यूनिक्स अनुमतियाँ, नेटवर्क VLAN, या की फ़ायरवॉल कम्पार्टमेंट एक डेटाबेस में। सुरक्षा नहीं होनी चाहिए यह एक जानकारी होनी चाहिए जो आपको याद रखनी चाहिए। इसे एक संपत्ति होनी चाहिए। भौतिकप्रणाली का।

OSS/CSS ग्रैन्युलराइज़ेशन इस सिद्धांत का क्षेत्र में अनुवाद है। LLM की शासन के बारे में, LLM को जानने की आवश्यकता नहीं है कि Edster है। गोपनीय। उसे इसे अनुक्रमित करने में असमर्थ होने की आवश्यकता है।

और यह ठीक वही है जो`CSS/`गारंटी.

संदर्भ

लेख 0117 — LLM शासन मेट्रिक्स
अनुच्छेद 0114 — विश्वास के सर्कल
अनुच्छेद 0116 — स्वचालित ज्ञान संबंधी विभाजन
लेख 0108 — एआई एजेंट को AsciiDoc के साथ शासित करना