تجزیه OSS/CSS — چرا من foundry/ را به دو بخش تقسیم کردم

منتشر شده در 03 May 2026

زمان مطالعه : 10 minutes

foundry/— منطقهٔ عملکردی که کد فضای کاری من را میزبانی می‌کند — شامل 18 پروژه است. هشت از آن‌ها تحت Apache 2.0 به‌صورت Open Source هستند. تنها یکی closed source — سرویس ابری Edster. به مدت ماه‌ها، این نه پروژه به صورت همزمان موجود بوده‌اند در همان پوشه، فقط توسط…​ هیچ چیزی جدا نشده‌اند. وضعیت عمومی/خصوصی‌شان این یک اطلاعات در ذهن من بود، نه در سیستم فایل‌ها.

و بعد می‌خواستم یک RAG وصل کنم. و در آن لحظه، همه چیز منچک شد.

حادثه‌ای که صبر می‌کرد تا رخ دهد

در آوریل 2026، من شروع به پیاده‌سازی RAG 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، در یک دیتاست آموزش — کد مالکیتی Edster نشت می‌کند.

مشکل این نیست که یک LLM کد closed source بخواند. مشکل، این است که این کد در یک embedding برداری public — غیرقابل برگشت، غیرقابل حذف، غیرقابل حسابرسی

سوال واقعی

این نیست "چگونه از نشت کد توسط 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/`. کد بسته-source یک دیتاست را تغذیه می‌کند بدون تنظیم دقیق — یک مدل داخلی که هرگز از خانه‌ام خارج نمی‌شود. La تقسیم مکانیکی است، نه اعلان‌آمیز.

چرا "OSS" و "CSS" و نه "Public" و "Private

انتخاب مخفف‌های OSS (Open Source Software) و CSS (Closed Source Software) بحث شده:

  • Public"/"Private" توضیح می‌دهددیدپذیری(چه چیزی که گیت‌هاب می‌بیند)

  • OSS"/"CSS" توصیف می‌کندطبیعتاز کد (که LLM باید بداند)

نمایشگیت‌هاب یک متاداده از مخزن دور است. طبیعهٔ کد است یک ویژگی محتوا. LLM به API گیت‌هاب دسترسی ندارد — اما دسترسی دارد. به سیستم فایل`CSS/او گفت: "احتیاط، این کد تحت لایسنس نیست آزاد" بدون نیاز به خواندن یک`LICENSE`یا برای پارس کردن یک`package.json.

نام پوشه، متادیتای قوی‌ترین است که می‌توانید به آن بدهید یک LLM. این نمی‌تواند به‌صورت نادرست تجزیه شود، نادیده گرفته شود یا به‌صورت نادرست تفسیر شود. LLM می‌بیند`CSS/edster/`در مسیر فایل — او می‌داند.

درخت کامل — چهار منطقه، نه سه

تجزیه OSS/CSS’ontologie سه ناحیه را کامل می‌سازد. ناحیه `foundry/`از 1 به 2 زیرزمینه‌های عملکردی :

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

title سازمان foundry/ — تجزیه OSS/CSS
package "کاریخانه فلزات/" {

  package "دایره 0 — ریشه" #FFCCCC {
    rectangle "PICTURE_ME_ROLLIN_*.adoc" as STIM
    rectangle "WORKSPACE_*.adoc" as VISION_DOC
    note right of STIM
      Brain dump libre
      Jamais versionné
      [LLM : interdit d'indexer]
    end note
  }

  package "دایره ۱ — تنظیمات/" #FFD9CC {
    rectangle "رازها، توکن‌ها" as SECRETS
    rectangle "Spring Cloud Config" as SCC
    note right of SECRETS
      Privé-CVS, solo access
      [LLM : INTERDIT]
    end note
  }

  package "دایره 2 — دفتر/" #FFFFCC {
    rectangle "مقالات، قاب‌بندی" as DATA
    rectangle "دورات آموزشی، SPG/SPD" as FORM
    note right of DATA
      Privé-CVS
      [LLM : filtré Vision/Opinion]
    end note
  }

  package "دایره 3 — فاندری/" #CCE5FF {
    package "OSS/ — آپاچی ۲.۰" #CCFFCC {
      rectangle "پلاگین‌های Gradle" as PLUGINS
      rectangle "موتور" as ENGINE
    }
    package "CSS/ — منبع بسته" #CCDDFF {
      rectangle "edster/" as EDSTER
    }
  }
}

@enduml

| منطقه | قانون حفاظت داده‌های عمومی | ایندکس‌سازی RAG عمومی | تنظیم دقیق دیتاست | | ریشه | سطح 0 — خصوصی | ✗ | ✗ | (Empty)configuration/| سطح 1 — محدود | ✗ | ✗ | | office/| سطح 2 — همکاری | ✓ فیلتر شده | ✓ فیلتر شده | |foundry/private/| سطح 3 — باز مشروط | ✗ | ✓ خاصة | | foundry/public/| سطح ۴ — عمومی بومی | ✓ آزاد | ✓ عمومی |

مورد خاص: 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، یک مدیریت — بدون تکرار

  • طبقه‌بندی Vision/Opinion (قاعده ۲بیس) به‌طور خودکار اعمال می‌شود :

مقالات در`office/`قبل از انتشار فیلتر می‌شوند

bakery-gradle مشکلی ندارد

و همین است که زیباست. پلاگین`bakery-gradle`تغییر نشده است او یک دایرکتوری محتوای AsciiDoc دریافت می‌کند، HTML تولید می‌کند، push می‌کند در 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 نیست. نه، یک webhook نیست. یک وظیفهٔ — تایپ‌شده، قابل‌آزمون، قابل اجرا در محیط محلی و در CI.

تأثیر بر حکمرانی آژنت

تقسیب OSS/CSS حاكمية العامل را در سه نقطه تغییر می‌دهد:

  1. RAG public : حوزهٔ index می‌رود از`foundry/**`

à foundry/public/+office/Vision/. کد منبع بسته az فهرست به دلیل تنظیمات کار، نه به دلیل prompt، حذف می‌شود.

  1. Knowledge Graph : graphify-gradle دو گراف تولید می‌کند :

*office/graph.json(public) — ارتباطات بین artefact‌های OSS + office/Vision *configuration/graph_private.json(gitignored, خصوصی) — ارتباطات بین آرتیفاکت‌های CSS، هرگز منتشر نشد

  1. تنظیم دقیق دیتاست :`codebase-gradle`اکنون دو منبع دارد:

    • OSS/→ دادهٔ‌های عمومی (مدل‌های جامعه‌ای, ب‌نچ‌مارک) *CSS/→ دیتاست‌های خصوصی (مدل داخلی, تنظیم دقیق مالکانه)

چه برنده می‌شویم (و چه چیزی را از دست می‌دهیم)

جلو(فولدر تخت)

پس از (OSS/CSS + office/sites)

ls foundry/→ ترکیب عمومی/خصوصی

ls foundry/public/→ همه چیز قابل انتشار است

RAG همه چیز را بدون تبعیض ایندکس می‌کند

RAG ایندکس می‌کند`OSS/`+`office/Vision`به‌صورت انحصاری

امکان پذیر نیست که بدانید آیا یک پروژه اوپن‌سورس است

راه`OSS/` ou `CSS/`المذكور

cheroliv.com CI خود را دارد، حاکمتی خود را دارد

CI و مدیریت در engine به اشتراک گذاشته شده‌اند

Les articles de blog sont dans un dépôt "code

مقالات وبلاگ در`office/sites/`— data, نه کد

خطر نشت کد بسته‌منبع در امبدینگ‌های عمومی

ساختاریاً غیرممکن —`CSS/`خارج از Scope RAG

تنها هزینه: یک`git mv`سراسری روی 17 مخزن OSS + یک بازسازی از build.gradle.kts de engine. این یک مهاجرت سرد است — هیچ داده‌ای در حال انتقال نیست، هیچ کاربری تحت تأثیر نیست.

نتیجه: سیگنال فیزیک سیگنال نرم‌افزار را می‌زند

این بود که یک عرف نامرئی را جابه‌جایی کردم با جدایی مرئی در ناحیه`foundry/. قبلاً، باید بودید دانش داشتن که`edster/`منبع بسته بود. الان، شما آن را می‌بینید — پوشه به نام`CSS/.

این همان اصل است که مجوزهای یونیکس، VLANهای شبکه یا بخش‌های ضدآتش در یک پایگاه داده. امنیت نباید یک اطلاعاتی که باید به خاطر داشته باشید. باید یک ویژگی باشد فیزیکاز سیستم.

تجزئه‌گرایی OSS/CSS traductions این مبنا در این حوزه است از حوكومتی LLM. LLM نیازی ندارد بداند که Edster است مخفی. او نیاز دارد که نتواند آن را index کند.

و این دقیقاً همان چیزی است`CSS/`ضمان می‌دهد.

مراجع

مقالات مرتبط

HyperFrames-Gradle : تحويل AsciiDoc إلى فيديو MP4
31 May 2026
بررسی مصرف من LLM : SQLite, OpenCode, Ollama Cloud، و چرا اشتراک حرفه‌ای من بازار جهانی را شکسته است
18 May 2026
Architecture « افزونه مستقل + ریه مصرف‌کننده »: چرا ساخت‌های Gradle من تکرار می‌شوند؟
14 May 2026
گراف دانش به عنوان موتور توصیه: چگونه من «مقالات مرتبط» زمانی را حذف کردم
12 May 2026