التقسيم الدقيق لـ OSS/CSS — لماذا قمت بتقسيم foundry/ إلى جزأين

Publié le 03 May 2026

وقت القراءة: 10 minutes

foundry/— المنطقة الوظيفية التي تستضيف كود مساحة العمل الخاصة بي — يحتوي على 18 مشروعًا. ثمانية منها مفتوحة المصدر تحت رخصة Apache 2.0. واحد فقط هو مصدر مغلق — SaaS Edster. طوال أشهر، تعايشت هذه المشاريع التسعة في نفس المجلد، مفصولين فقط بـ…​ لا شيء. وضعهم العام/خاص كانت معلومة في رأسي، وليس في نظام الملفات.

ثم أردت توصيل RAG. ثم انهار كل شيء.

الحادث الذي كان ينتظر أن يحدث

في أبريل 2026، بدأت في تنفيذ راغ pgvector لـ slider-gradle. المبدأ: فهرسة جميع المستودعات`foundry/إنتاج بعض الضمامات، وحقنها في سياق LLM ليكون له الإدراك" من الملف`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، في مجموعة بيانات للتدريب — كود إيدستر الخاص يتسرب.

المشكلة ليست أن يقرأ نموذج لغوي كبير كودًا مغلق المصدر. المشكلة، أن هذا الكود ينتهي في تضمين متجهي عام — غير قابل للعكس, غير قابل للحذف, غير قابل للتدقيق.

السؤال الحقيقي

ليس "كيف منع 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" وليس "عام" و "خاصة

اختيار الأحرف المختصرة OSS (Open Source Software) وCSS (Closed Source Software) تمّ التداول :

  • \"Public\"/\"Private\" يصفالرؤية(ما يراه GitHub)

  • OSS"/"CSS" يصف الطبيعةالكود (ما يجب على النموذج اللغوي معرفته)

رؤية GitHub هي بيانات وصفية للمستودع البعيد. طبيعة الكود هي ملكية المحتوى. لا يمتلك نموذج لغة كبير (LLM) الوصول إلى واجهة برمجة تطبيقات جيتهب — لكنه لديه وصول إلى نظام الملفات`CSS/قال: "احذر، هذا الكود غير مرخص مجاني" بدون الحاجة لقراءة واحد`LICENSE`أو لتحليل`package.json.

اسم المجلد هو أقوى بيانات وصفية يمكنك إعطاؤه إلى نموذج لغوي كبير. لا يمكن تحليلها بشكل خاطئ، أو إهمالها، أو تفسيرها بشكل خاطئ. النموذج اللغوي الكبير يرى`CSS/edster/`في مسار الملف — هو يعرف

الشجرة الكاملة — أربع مناطق، ليست ثلاث

التقسيم الدقيق OSS/CSS يكمل الأنطولوجية المكونة من ثلاث مناطق. المنطقة `foundry/`ينتقل من 1 إلى 2 مناطق فرعية وظيفية :

L’organisation de foundry/ en deux sous-zones OSS et CSS

منطقة | النظام العام لحماية البيانات | الفهرسة RAG العامة | ضبط دقيق لمجموعة البيانات | جذر | مستوى 0 — حميمي | ✗ | ✗ | | configuration/| المستوى 1 — محدود | ✗ | ✗ | |office/| المستوى 2 — التعاوني | ✓ المصفّى | ✓ المصفّى | | foundry/private/| المستوى 3 — مفتوح بشروط | ✗ | ✓ خاص | | foundry/public/| المستوى 4 — الجمهور الأصلي | ✓ مجاني | ✓ عام |

الحالة الخاصة : cheroliv.com

بينما كنت هناك، صححت تناقضًا آخر. موقعي cheroliv.com`كان يعيش في`foundry/`مثل مشروع برمجي كاملة الصلاحية — مع بناء Gradle خاص بها، وCI خاص بها، وخاصتها حوكمة.agents/`.

لكن مقالات المدونة ليست كودًا. إنها بيانات التحريريّات** من Cercle 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 واحدة، حوكمة واحدة — لا تكرار

  • يُطبق مصنف الرؤية/الرأي (القاعدة 2 bis) تلقائيًا :

المقالات في`office/`يتم تصفية قبل النشر

الباكري-جرادل لا يهتم

وهذا ما هو جميل. المكوّن الإضافي`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. ولا هو ويب هوك. مهمة — محددة النوع، قابلة للاختبار، قابلة للتنفيذ محليًا وفي CI.

التأثير على حوكمة الوكيل

يعدل التفصيل OSS/CSS حوكمة الوكيل على ثلاث نقاط:

  1. RAG public : يتغير نطاق الفهرسة من`foundry/**`

à foundry/public/+office/Vision/. الكود مغلق المصدر مستبعد من الفهرس بسبب تكوين المهمة، وليس بسبب المطالبة.

  1. Knowledge Graph : graphify-gradle ينتج رسيمان بيانيان :

*office/graph.json(عام) — العلاقات بين القطع الأثرية OSS + office/Vision * configuration/graph_private.json(gitignored, خاص) — العلاقات بين قطع أثرية CSS، لم تُنشر أبدًا

  1. ضبط دقيق لمجموعة البيانات :`codebase-gradle`له الآن مصدران :

*OSS/→ مجموعات بيانات عامة (نماذج مجتمعية، مقاييس) * CSS/→atasets privés (modèle interne, fine-tuning propriétaire)

ما نكسبه (وما نفقده)

الأمام (ملف مسطح)

بعد (OSS/CSS + office/sites)

ls foundry/→ خليط عام/خاص

ls foundry/public/→ الكل قابل للنشر

RAG يفهرس كل شيء دون تمييز

RAG يفهرس`OSS/`+`office/Vision`حصرياً

من المستحيل معرفة ما إذا كان المشروع مفتوح المصدر

الطريق`OSS/` ou `CSS/`المذكور

cheroliv.com لديه CI خاص به، حوكمة خاصة به

تم مشاركة CI والحكم في engine

مقالات المدونة موجودة في مستودع "code

مقالات المدونة موجودة في`office/sites/`— البيانات، ليس كود

خطر تسريب كود المصدر المغلق في التضمينات العامة

غير ممكن هيكلياً —`CSS/`خارج نطاق RAG

التكلفة الوحيدة:`git mv`عالمي على 17 مستودعات OSS + إعادة هيكلة لل build.gradle.kts de `engine`هذه هجرة باردة — لا توجد بيانات أثناء النقل، ولا مستخدمين متأثرين.

الاستنتاج : الإشارة الفيزيائية تهزم الإشارة البرمجية

ما قمت به هذا بعد الظهر هو استبدال اتفاقية غير مرئية بفاصل مرئي في المنطقة`foundry/. قبل, كنتم ملزمون تعرف أن`edster/`كان المصدر مغلقًا. الآن أنت تراه — الملف يُسمى`CSS/.

هذا هو نفس المبدأ كما في أذونات يونكس، أو شبكات VLAN، أو أقسام مقاومة الحريق في قاعدة بيانات. الأمان لا يجب أن أن تكون معلومة عليك الاحتفاظ بها. يجب أن تكون خاصية فيزياءمن النظام.

التفصيل OSS/CSS هو تطبيق هذا المبدأ في المجال من حوكمة LLM. لا يحتاج LLM إلى معرفة أن إدستر هو سرّي. إنه يحتاج إلى أن يكون غير قادر على فهرسته.

وهذا exatamente ما

Wait Arabic: "وهذا بالضبط ما". Should be exactly. Let’s output: "وهذا بالضبط ما". No extra spaces.

</think>

وهذا exactement ما

Oops I typed French word. Need Arabic: "وهذا exactement ما"? No, correct Arabic: "وهذا بالضبط ما". Let’s output that.

</think>

وهذا بالضبط ما`CSS/`يضمن.

المراجع

Articles connexes

HyperFrames-Gradle : تحويل AsciiDoc إلى فيديو MP4
31 May 2026
تدقيق استهلاكي ل LLM: SQLite, OpenCode, Ollama Cloud, ولماذا اشتراطي الاحترافي يُكسِر السوق العالمي
18 May 2026
هندسة « المكوّن المستقل + جذر المستهلك » : لماذا تتكرر بناءات Gradle الخاصة بي؟
14 May 2026
الرسم البياني للمعرفة كمحرك للتوصية: كيف قتلت المقالات « ذات الصلة » الزمنية
12 May 2026