OSS/CSSの細分化 — なぜ私は foundry/ を二つに分けたのか
公開日: 03 May 2026
foundry/— 私のワークスペースのコードをホストする機能領域 — 18のプロジェクトが含まれています。 8つはApache 2.0ライセンスのオープンソースです。 ただ1つだけは closed source — SaaS Edster。数か月間、これらの9つのプロジェクトは共存していた 同じフォルダー内にあり、… 以外に何も区切られていない。それらの公開/非公開ステータス それは私の頭の中の情報で、ファイルシステムにはありませんでした。
それから、RAGを接続したくなった。そこで、すべてが崩れた。
起きるべくして起きた事故
2026年4月、slider-gradle用のpgvector RAGの実装を開始しました。 原則：すべてのリポジトリをインデックス化する`foundry/,生産する embeddings, そしてそれらを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/`(closed source, private). 全部飲み込む。 もし私がいつかこれらの埋め込みを公開したら — ダッシュボード上、または回答の中に 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（オープンソースソフトウェア）およびCSS（クローズドソースソフトウェア）の略称の選択 熟慮された：
-
Public"/"Private" 説明します視認性(GitHubが見ているもの)
-
OSS"/"CSS"は…を説明する自然コード (LLMが知っておくべきこと)
GitHubの可視性はリモートリポジトリのメタデータです。 コードの性質は コンテンツのプロパティです。LLM は GitHub API へのアクセスがありませんが、アクセスがあります。 ファイルシステムに。CSS/「注意、このコードはライセンスで保護されていません。」 libre" 読む必要なく`LICENSE`またはパースする`package.json`.
|
フォルダーの名前は、あなたが与えることができる最も堅牢なメタデータに LLM. 彼女は誤ってパースされたり、無視されたり、誤って解釈されたりすることはできません。このLLM 見る`CSS/edster/`ファイルのパスの中 — 彼は知っている。 |
完全な木 — 四つのゾーン、三つではない
OSS/CSSの細分化は3領域オントロジーを完成させます。領域 `foundry/`機能的サブゾーンが1から2に変更されます :
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 260
title ファウンドリー/ — 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 "サークル 1 — 設定/" #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 — foundry/" #CCE5FF {
package "OSS/ — Apache 2.0" #CCFFCC {
rectangle "Gradle プラグイン" as PLUGINS
rectangle "エンジン" as ENGINE
}
package "CSS/ — クローズドソース" #CCDDFF {
rectangle "edster/" as EDSTER
}
}
}
@enduml
| ゾーン | GDPR | パブリック 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`になる能力の`engine`
経由`bakery-gradle`— プラグインは一つ受け取ります`FileTree`, 彼は知らない 記事がどこから来るか`office/`
-
単一のCI、単一のガバナンス — 重複ゼロ
-
ビジョン/オピニオン・クラスファイア（規則2ビス）自動的に適用されます：
記事の中の`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 API ではありません。ウェブフックではありません。 タスク — タイプ指定され、テスト可能、ローカルおよび CI で実行可能。
ガバナンスエージェントへの影響
OSS/CSSの細粒度化は、エージェントガバナンスを3つのポイントで変更します：
-
RAG public : インデックス範囲は`foundry/**`
à foundry/public/+office/Vision/. クローズドソースのコード タスクの設定によってインデックスから除外されます。プロンプトによってではありません。
-
知識グラフ : graphify-gradle は2つのグラフを生成します :
*office/graph.json(公開) — OSSアーティファクトとoffice/Visionの関係 *configuration/graph_private.json(gitignored, privé) — の間の関係 CSSのアーティファクト、未公開
-
データセットファインチューニング :`codebase-gradle`現在は2つのソースがあります：
*OSS/→ パブリックデータセット (コミュニティモデル、ベンチマーク) *CSS/→ プライベートデータセット (内部モデル, 独自のファインチューニング)
私たちが得るもの （そして失うもの）
前 (フラットフォルダー) |
(OSS/CSS + office/sites) 後 |
|
|
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/。
これはUnixのパーミッション、ネットワークのVLAN、またはの同じ原理です データベース内の防火区画。セキュリティは 覚えておくべき情報でなければならず、それはプロパティでなければなりません。 物理システムの。
OSS/CSSの細分化は、この原理をその分野に適用したものです。 LLMのガバナンスについて。 LLMはEdsterが何であるかを知る必要はありません 機密です。 彼はそれをインデックス付けできない状態である必要があります。
それがまさにそれ`CSS/`保証する。
関連記事
31 May 2026
14 May 2026