التفصيل الحبيبي `OSS/CSS` — لماذا قسمت foundry/ إلى جزأين
نُشر في 03 May 2026
foundry/— المنطقة الوظيفية التي تستضيف كود مساحة عملي — يحتوي على 18 مشروعًا. ثمانية منها مفتوحة المصدر تحت Apache 2.0. واحد فقط هو مصدر مغلق — برنامج SaaS Edster. خلال أشهر، تعايشت هذه التسع مشاريع في نفس المجلد، مفصولين فقط … لا شيء. وضعهم العام / الخاص كانت معلومة في رأسي، وليس في نظام الملفات.
ثم أردت توصيل RAG. وفجأة، انهار كل شيء.
الحادث الذي كان ينتظر حدوثه
في أبريل 2026، بدأت في تنفيذ RAG pgvector لـ slider-gradle. المبدأ: فهرس جميع المستودعات من`foundry/, إنتاج بعض التضمينات، ثم حقنهم في سياق نموذج اللغة الكبيرة بحيث يكون له الإدراك" من الملف`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، عام) و`edster/`(closed source, private). إنه يبتلع كل شيء وإذا نشرت هذه التضمينات — على لوحة المعلومات، في استجابة نموذج لغة كبير، في مجموعة بيانات التدريب — كود إيدستر المملوك يتسرب.
|
المشكلة ليست أن LLM يقرأ الكود المغلق المصدر. المشكلة، أن ينتهي هذا الكود في embedding المتجهي عام غير قابل للعكس، غير قابل للحذف، غير قابل للتدقيق. |
السؤال الحقيقي
ليس "كيف يمنع LLM من تسريب الشيفرة ؟" .'est "كيف جعل الهروب مستحيلًا من الناحية الهيكلية؟
الجواب ليس أمرًا. الجواب هو أن تقسم الملف إلى نصفين.
الحل: 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`devient :
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) هو متعمَّد :
-
عام"/"خاص" يصفظهور(ما يراه GitHub)
-
OSS"/"CSS" يصفطبيعةالكود (ما الذي يجب أن يعرفه نموذج اللغة الكبير)
رؤية جيت هاب هي بيانات تعريفية للمستودع البعيد. طبيعة الكود خاصية من المحتوى. النموذج اللغوي الضخم لا يملك وصولًا إلى واجهة برمجة تطبيقات جيت هاب — لكنه يملك وصولًا إلى نظام الملفات.CSS/`قال له "انتبه، هذا الكود ليس تحت رخصة مجان" بدون الحاجة لقراءة`LICENSE`أو تحليل واحد`package.json.
|
اسم المجلد هو البيانات الوصفية الأكثر متانة التي يمكنك إعطاؤها إلى نموذج لغة كبير. لا يمكن تحليله بشكل خاطئ، أو تجاهله، أو تفسيره بشكل غير صحيح. نموذج اللغة الكبير يرى`CSS/edster/`في مسار الملف — هو يعرف |
الشجرة الكاملة — أربع المناطق، ليست ثلاثًا
التقسيم الحبيبي OSS/CSS يكمل الأنطولوجيا ذات الثلاث المناطق. المنطقة `foundry/`يتغير من 1 إلى 2 مناطق فرعية وظيفية:
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 260
title تنظيم foundry/ — التفصيل 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 "الدائرة 1 — التكوين/" #FFD9CC {
rectangle "أسرار، الرموز" as SECRETS
rectangle "Spring Cloud Config" as SCC
note right of SECRETS
خاص-CVS, الوصول المنفرد [LLM : INTERDIT]
end note
}
package "الدائرة 2 — المكتب/" #FFFFCC {
rectangle "مقالات، أطر" as DATA
rectangle "التدريبات، SPG/SPD" as FORM
note right of DATA
خاص-CVS
[LLM : filtré Vision/Opinion]
end note
}
package "الدائرة 3 — foundry/" #CCE5FF {
package "OSS/ — Apache 2.0" #CCFFCC {
rectangle "الإضافات Gradle" as PLUGINS
rectangle "engine" as ENGINE
}
package "CSS/ — المصدر المغلق" #CCDDFF {
rectangle "edster/" as EDSTER
}
}
}
@enduml
| المنطقة | RGPD | الفهرسة العامة لـ RAG | ضبط دقيق للبيانات | | الجذر | المستوى 0 — شخصي | ✗ | ✗ | |configuration/`المستوى 1 — مقيد (Empty)`office/| المستوى 2 — تعاوني | ✓ مصفى | ✓ مصفى | (No output, as source text is empty)foundry/private/| المستوى 3 — مفتوح مشروط | ✗ | ✓ خاص | |foundry/public/| المستوى 4 — الجمهور الأصلي | ✓ مجاني | ✓ عام |
الحالة الخاصة : cheroliv.com
بينما كنت هناك، صحّيت عدم اتساق آخر. موقعي cheroliv.com`كان يعيش في`foundry/`مثل مشروع برمجي جزء لا يتجزأ — مع بناء Gradle الخاص به، CI الخاص به، خاص به حوكمة.agents/`.
لكن مقالات المدونة ليست شفرة. إنها بيانات الافتتاحية de Cercle 2 — على قدم المساواة مع الإطارات de`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`تصبح قدرةً على`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. ليس API REST. ليس ويب هوك. مهمة — ذات نوع ثابت، قابلة للاختبار، قابلة للتنفيذ محليًا وفي الـ CI.
التأثير على الوكيل للحوكمة
التقسيم الحبيبي OSS/CSS يغيّر حوكمة الوكيل على ثلاث نقاط :
-
RAG public : مساحة الفهرسة تتحول من`foundry/**`
à foundry/public/[No content]office/Vision/. الكود مغلق المصدر يتم استبعاده من الفهرس بإعدادات المهمة، وليس بواسطة المطالبة.
-
Knowledge Graph : graphify-gradle ينتج رسمين :
(No text)office/graph.json(public) — العلاقات بينartefacts OSS + office/Vision *configuration/graph_private.json( gitignored, خاص ) — علاقات بين الآثار CSS، لم تُنشر أبدًا
-
ضبط دقيق لمجموعة البيانات :`codebase-gradle`له الآن مصـدران :
*OSS/→ مجموعات البيانات العامة (نماذج مجتمعية, مقاييس) *CSS/→ مجموعات بيانات خاصة (نموذج داخلي، ضبط دقيق مملوك)
ما نربحه (وما نفقده)
| قبل (ملف مسطح) | بعد (OSS/CSS + مكتب/مواقع) |
|---|---|
|
|
RAG يفهرس كل شيء دون تمييز |
راغ يُفهرس`OSS/`+`office/Vision`حصريًا |
من المستحيل معرفة ما إذا كان المشروع مفتوح المصدر |
الطريق`OSS/` ou `CSS/`المذكور |
cheroliv.com يملك CI خاصاً به، وإدارة خاصّة به |
تُشارك CI والحوكمة في المحرك |
مقالات المدونة في مستودع \"code\ |
مقالات المدونة في`office/sites/`— data, لا كود |
خطر تسرب كود مصدر مغلق في تضمينات عامة |
مستحيل هيكليًا —`CSS/`خارج النطاق RAG |
التكلفة الوحيدة : واحد`git mv`عالمي على 17 مستودع OSS + إعادة هيكلة لل build.gradle.kts de engine. إنها هجرة باردة — لا توجد بيانات أثناء الطيران, لا يوجد مستخدمون متأثرون.
الخلاصة : الإشارة الفيزيائية تفوق الإشارة المنطقية
ما فعلته بعد الظهر هو استبدال اتفاقية غير مرئية. من خلال فصل مرئي في المنطقة`foundry/. في السابق، كان عليكم معرفة أن`edster/`كان مصدرًا مغلقًا. الآن، أنت ترون — الملف يُسمّى`CSS/.
هذا هو المبدأ نفسه مثل أذونات يونكس، أو شبكات VLAN، أو الأقسام المقاومة للحريق في قاعدة بيانات. الأمن لا يجب أن إنها معلومة يجب أن تحتفظ بها. يجب أن تكون خاصية. فيزياءمن النظام.
إن الحبيبية OSS/CSS هي ترجمة هذا المبدأ في المجال من حوكمة LLM. لا يحتاج LLM إلى معرفة أن Edster هو سري. يحتاج إلى أن يكون غير قادر على فهرسته.
وهذا بالضبط ما`CSS/`يضمن