Die Granularisierung OSS/CSS — Warum habe ich foundry/ in zwei Teile geschnitten
Publié le 03 May 2026
- Der Unfall, der darauf wartete, sich zu ereignen
- Die Lösung: OSS/ und CSS/
- Warum "OSS" und "CSS" und nicht "Public" und "Private
- Der Sonderfall : cheroliv.com
- Auswirkung auf den Governance-Agent
- Was wir gewinnen (und was wir verlieren)
- Fazit: das physische Signal schlägt das logische Signal
- Referenzen
foundry/— der funktionale Bereich, der den Code meines Arbeitsbereichs hostet — enthält 18 Projekte. Acht sind Open Source unter Apache 2.0. Nur einer ist closed source — der SaaS Edster. Über Monate hinweg haben diese neun Projekte koexistiert. im gleichen Ordner, getrennt nur durch… nichts. Ihr öffentlicher/privater Status Es war eine Information in meinem Kopf, nicht im Dateisystem.
Dann wollte ich ein RAG anschließen. Und dann ist alles zusammengebrochen.
Der Unfall, der darauf wartete, sich zu ereignen
Im April 2026 habe ich begonnen, das RAG pgvector für slider-gradle zu implementieren. Das Prinzip : alle Repositorys indexieren von`foundry/, produzieren Embeddings, sie in den Kontext des LLM einzufügen, damit es eine hat Perception" der Akte`foundry/`.
Die Pipeline war einfach:
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)Einfach. Effizient. Und.gefährlich.
Weil das`fileTree`macht keinen Unterschied zwischen`plantuml-gradle/` (Apache 2.0, public) und`edster/`(closed source, private). Er isst alles. Und wenn ich eines Tages diese Embeddings veröffentliche — auf einem Dashboard, in einer Antwort LLM, in einem Trainingsdatensatz — Edsters proprietärer Code läuft aus.
|
Das Problem ist nicht, dass ein LLM geschlossenen Quellcode liest. Das Problem, dass dieser Code in einem Vektor-Embedding öffentlich endet — irreversibel, nicht löschbar, nicht prüfbar. |
Die wahre Frage
Es ist nicht "wie verhindert man, dass der LLM Code verliert?". Es ist "wie die Flucht strukturell unmöglich machen?
Die Antwort ist kein Prompt. Die Antwort ist, den Ordner in zwei Teile zu teilen.
Die Lösung: OSS/ und CSS/
Vorher:
foundry/
├── plantuml-gradle/ ← public
├── bakery-gradle/ ← public
├── magic-stick/ ← public
├── edster/ ← PRIVÉ
├── slider-gradle/ ← public
└── ... ← mélange invisibleDanach:
foundry/
├── OSS/ ← tout est Apache 2.0
│ ├── plantuml-gradle/
│ ├── bakery-gradle/
│ ├── magic-stick/
│ ├── slider-gradle/
│ └── ...
└── CSS/ ← tout est closed source / private
└── edster/Le `fileTree`wird :
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é|
Der öffentliche RAG sieht nie`CSS/`. Der Closed-Source-Code speist einen Datensatz ohne Fine-Tuning — ein internes Modell, das mein Zuhause niemals verlässt. Die Trennung ist mechanisch, nicht deklarativ. |
Warum "OSS" und "CSS" und nicht "Public" und "Private
Die Auswahl der Akronyme OSS (Open Source Software) und CSS (Closed Source Software) ist deliberiert :
-
Public"/"Private" beschreibt dieSichtbarkeit(was GitHub sieht)
-
OSS"/"CSS" beschreibt dasNaturdes Codes (was das LLM wissen muss)
Die GitHub-Sichtbarkeit ist eine Metadaten des entfernten Repos. Die Natur des Codes ist eine Eigenschaft des Inhalts. Der LLM hat keinen Zugriff auf die GitHub-API — aber er hat Zugriff dem Dateisystem.CSS/`Er sagt ihm: "Achtung, dieser Code steht nicht unter einer Lizenz. frei" ohne etwas lesen zu müssen ein`LICENSE`oder zum Parsen eines`package.json.
|
Der Name des Ordners ist das robusteste Metadatum, das Sie geben können zu ein LLM. Sie kann nicht falsch geparsed, ignoriert oder falsch interpretiert werden. Das LLM sieht`CSS/edster/`im Dateipfad — es weiß. |
Der vollständige Baum — Vier Zonen, nicht drei
Die OSS/CSS-Granularisierung ergänzt die dreizonige Ontologie. Die Zone `foundry/`geht von 1 zu 2 funktionellen Unterzonen:
| Zone | DSGVO | Indexierung RAG öffentlich | Datensatz-Feinabstimmung | | Wurzel | Ebene 0 — intim | ✗ | ✗ | | configuration/| Stufe 1 — Eingeschränkt | ✗ | ✗ | | office/| Level 2 — Kollaborativ | ✓ Gefiltert | ✓ Gefiltert | |foundry/private/| Stufe 3 — Bedingt geöffnet | ✗ | ✓ Privat | Veuillez fournir le texte français à traduire.foundry/public/| Stufe 4 — Einheimisches Publikum | ✓ Kostenfrei | ✓ Öffentlich |
Der Sonderfall : cheroliv.com
Während ich dort war, habe ich eine andere Inkonsistenz korrigiert. Meine Seite cheroliv.com`lebte in`foundry/`wie ein Softwareprojekt vollwertig — mit seinem eigenen Gradle-Build, seiner eigenen CI, seiner eigenen Governance.agents/`.
Aber Blog-Beiträge sind kein Code. Sie sind Daten. Editorial** von Cercle 2 — ebenso wie die Einrahmungen von`office/pilotage/` oder die Ausbildungen von`office/formations/`.
AVANT APRÈS
foundry/ office/
cheroliv.com/ sites/
site/jbake/content/blog/ cheroliv.com/
2026/0117_....adoc 2026/0117_....adocWas sich ändert:
-
Die Artikel sind in`office/`→ Vertraulichkeit des Kreises 2
-
Die Aufgabe`publishSite`wird eine Fähigkeit von`engine`
via`bakery-gradle`— das Plugin erhält ein`FileTree`, er weiß es nicht dass die Artikel von`office/`
-
Eine einzige CI, eine einzige Governance — null Duplikation
-
Der Vision/Opinion-Klassifikator (Regel 2bis) wird automatisch angewendet:
die Artikel in`office/`werden vor der Veröffentlichung gefiltert
bakery-gradle ist mir egal
Und das ist schön. Das Plugin`bakery-gradle`wurde nicht geändert. Er empfängt ein Verzeichnis mit AsciiDoc-Inhalt, er erzeugt HTML, er pusht Auf GitHub Pages. Dass dieses Verzeichnis heißt`site/jbake/content/` ou `office/sites/cheroliv/`Der Plugin scheißt darauf
// 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
}
}Der Schnittstellenvertrag ist eine Gradle-Aufgabe. Keine REST-API. Kein Webhook. Eine Aufgabe — typisiert, testbar, lokal und in der CI ausführbar.
Auswirkung auf den Governance-Agent
Die OSS/CSS-Granularisierung ändert die Agenten-Governance an drei Punkten:
-
RAG public : der Perimeter der Indexierung geht von`foundry/**`
à foundry/public/+office/Vision/. Der Closed-Source-Code wird aus dem Index durch die Aufgabenkonfiguration ausgeschlossen, nicht durch den Prompt.
-
Knowledge Graph : graphify-gradle produziert zwei Graphen :
*office/graph.json(public) — Beziehungen zwischen OSS-Artefakten und office/Vision *configuration/graph_private.json(gitignored, privat) — Beziehungen zwischen CSS-Artefakte, nie veröffentlicht
-
Datensatz-Feinabstimmung :`codebase-gradle`hat jetzt zwei Quellen:
*OSS/→ öffentliche Datensätze (Community-Modelle, Benchmarks) *CSS/→ private Datasets (internes Modell, proprietäres Fine-Tuning)
Was wir gewinnen (und was wir verlieren)
Vor (flacher Ordner) |
Nach (OSS/CSS + office/sites) |
|
`ls foundry/public/`Alles ist veröffentlichbar |
RAG indiziert alles ohne Diskriminierung |
RAG indiziert`OSS/`+`office/Vision`ausschließlich |
Es ist unmöglich zu wissen, ob ein Projekt Open Source ist. |
Der Weg`OSS/` ou `CSS/`der genannte |
cheroliv.com hat seine eigene CI, seine eigene Governance |
Die CI und die Governance werden im Engine gemeinsam genutzt. |
Die Blogartikel befinden sich in einem Repository "code". |
Die Blogbeiträge sind in`office/sites/`— Daten, kein Code |
Risiko eines Lecks von closed-source-Code in öffentlichen Embeddings |
Strukturell unmöglich —`CSS/`außerhalb des Geltungsbereichs von RAG |
Die einzige Kosten: ein`git mv`global über die 17 OSS-Repositorien + ein Refactoring des build.gradle.kts de engine. Es ist eine Kaltmigration— Keine Daten im Flug, keine betroffenen Benutzer.
Fazit: das physische Signal schlägt das logische Signal
Was ich diesen Nachmittag gemacht habe, ist, eine unsichtbare Konvention zu ersetzen. durch eine sichtbare Trennung in der Zone`foundry/. Früher mussten Sie wissen dass`edster/`war Closed Source. Jetzt sehen Sie es — Der Ordner heißt`CSS/.
Es ist das gleiche Prinzip wie die Unix-Berechtigungen, die Netzwerk-VLANs, oder die Brandschutzwände in einer Datenbank. Die Sicherheit muss nicht Es muss eine Information sein, die Sie behalten müssen. Sie muss eine Eigenschaft sein. physikalischdes Systems.
Die Granularisierung OSS/CSS ist die Übersetzung dieses Prinzips im Bereich der LLM-Governance. Das LLM muss nicht wissen, dass Edster ist vertraulich. Er muss unfähig sein, es zu indexieren.
Und das ist genau was`CSS/`garantiert.
Referenzen
-
Artikel 0116 — Die automatisierte epistemische Kompartimentierung