OSS/CSS 细粒化 — 为什么我把 foundry/ 切成两半
发布于 03 May 2026
foundry/— 托管我工作区代码的功能区域 — 包含18个项目。其中八个是以Apache 2.0许可证的开源项目。仅有一个是 闭源 — Edster SaaS。在这几个月里，这九个项目一直共存。 在同一文件夹中，仅由……什么都没有分隔。 它们的公共/私有状态 它曾是我脑中的信息，而不是文件系统中的信息。
然后我想要连接一个 RAG。然后，一切都崩溃了。
等待发生的事故
2026年4月，我开始为 slider-gradle 实现了 pgvector 的 RAG。 原则：索引所有存储库的`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, 公共) 和`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/`. 闭源代码驱动一个数据集 未经过微调的 — 一个永不会离开我这里的内部模型。 拉 分离是机械的，不是声明的。 |
为什么"OSS"和"CSS"而不是"Public"和"Private
选择 OSS（开源软件）和 CSS（闭源软件）的缩写 已审议：
-
Public"/"Private" 描述可见性(GitHub 看到的内容)
-
OSS"/"CSS" 描述了自然代码（LLM必须知道的）
GitHub可见性是远程仓库的元数据。代码的性质是 内容的一个属性。LLM 没有访问 GitHub API 的权限 — 但它有访问 到文件系统。CSS/`他告诉他说：“注意，这段代码未获得许可。” 免费" 无需阅读一个`LICENSE`或是解析一个`package.json。
|
文件夹名称是您可以给予的最强大的元数据 一个LLM。它不能被错误地解析、忽略或误解。该LLM 看到`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 — configuration/" #FFD9CC {
rectangle "密钥，令牌" as SECRETS
rectangle "Spring Cloud Config" as SCC
note right of SECRETS
私密-CVS，单独访问
[LLM : INTERDIT]
end note
}
package "圈 2 — office/" #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 "引擎" 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`成为一种 capability 的`engine`
通过`bakery-gradle`— 插件收到一个`FileTree`，他不知道 这些文章来自`office/`
-
一套 CI，一套治理 — 零重复
-
Vision/Opinion 分类器（规则 2bis）自动适用：
文章中的`office/`在出版前被过滤
bakery-gradle S’En Fiche
那就是美好的所在。插件`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。不是一个 webhook。 一个任务 — 类型化、可测试、可在本地和 CI 中执行。
对治理智能体的影响
OSS/CSS 的细粒度修改了代理治理的三个方面：
-
RAG public : 索引范围从`foundry/**`
à foundry/public/+office/Vision/. 闭源代码 通过任务配置被排除在索引之外，而非通过提示。
-
知识图谱 : graphify-gradle 生成两个图 :
*office/graph.json(public) — OSS工件与office/Vision之间的关系 *configuration/graph_private.json(gitignored, 私有) — 关系在 CSS 工件，从未发布
-
数据集微调 :`codebase-gradle`现在有两个来源：
*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
12 May 2026