De granulering OSS/CSS — Waarom heb ik foundry/ in tweeën gesplitst
Gepubliceerd op 03 May 2026
foundry/— de functionele zone die de code van mijn workspace huisvest — bevat 18 projecten. Acht zijn open source onder Apache 2.0. Slechts één is closed source — de SaaS Edster. Gedurende maanden hebben deze negen projecten samen bestaan in dezelfde map, gescheiden uitsluitend door… niets. Hun status openbaar/privé was informatie in mijn hoofd, niet in het bestandssysteem.
En toen wilde ik een RAG aansluiten. En daar stortte alles in elkaar.
Het ongeluk dat wachtte om te gebeuren
In april 2026 ben ik begonnen met het implementeren van RAG pgvector voor slider-gradle. Het principe : alle repositories indexeren van`foundry/, produceren van embeddings, en injecteer ze in de context van de LLM zodat het een perceptie van het dossier`foundry/`.
De pijplijn was eenvoudig :
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)Eenvoudig. Effectief. Engevaarlijk.
Omdat dit`fileTree`maakt geen onderscheid tussen`plantuml-gradle/` (Apache 2.0, public) en`edster/`(closed source, private). Hij slikt alles door. En als ik op een dag deze embeddings publiceer — op een dashboard, in een antwoord LLM, in een trainingsdataset — het proprietair code van Edster lekt.
|
Het probleem is niet dat een LLM gesloten broncode leest. Het probleem, zodat deze code eindigt in een openbaar vectoriële embedding— onherroepelijk, niet verwijderbaar, niet auditabel. |
De Echte Vraag
Het is niet "hoe voorkom je dat het LLM code lekt?". Het is "hoe de vlucht structureel onmogelijk maken ?
Het antwoord is geen prompt. Het antwoord is om het dossier in tweeën te snijden.
De oplossing: OSS/ en CSS/
Voor :
foundry/
├── plantuml-gradle/ ← public
├── bakery-gradle/ ← public
├── magic-stick/ ← public
├── edster/ ← PRIVÉ
├── slider-gradle/ ← public
└── ... ← mélange invisibleNa:
foundry/
├── OSS/ ← tout est Apache 2.0
│ ├── plantuml-gradle/
│ ├── bakery-gradle/
│ ├── magic-stick/
│ ├── slider-gradle/
│ └── ...
└── CSS/ ← tout est closed source / private
└── edster/Le `fileTree`wordt :
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é|
Het publieke RAG ziet nooit`CSS/`. De gesloten-broncode voedt een dataset zonder fine-tuning — een intern model dat nooit mijn huis verlaat. De de scheiding is mechanisch, niet declaratief. |
Waarom "OSS" en "CSS" en niet "Public" en "Private
De keuze van de acroniemen OSS (Open Source Software) en CSS (Closed Source Software) is beraadslagd :
-
Openbaar"/"Privé" beschrijft dezichtbaarheid(wat GitHub ziet)
-
OSS"/"CSS" beschrijft denatuurvan de code (wat de LLM moet weten)
GitHub-zichtbaarheid is een metadata van de externe repo. De aard van de code is een eigenschap van de inhoud. De LLM heeft geen toegang tot de GitHub API — maar hij heeft toegang aan het bestandssysteem.CSS/`hij zei "let op, deze code staat niet onder licentie vrij" zonder dat je hoeft te lezen een`LICENSE`of te parseren een`package.json.
|
De mapnaam is de meest robuuste metadata die je kunt geven aan een LLM. Het kan niet verkeerd worden geparsed, genegeerd, of verkeerd geïnterpreteerd. Het LLM ziet`CSS/edster/`in het bestandspad — hij weet. |
De Volledige Boom — Vier Zones, Niet Drie
De OSS/CSS-granularisatie maakt de drie zones-ontologie compleet. De zone `foundry/`gaat van 1 naar 2 functionele onderzones :
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 260
title Organisatie de foundry/ — Granulariteit OSS/CSS
package "foundry/" {
package "Cirkel 0 — De Wortel" #FFCCCC {
rectangle "PICTURE_ME_ROLLIN_*.adoc" as STIM
rectangle "WORKSPACE_*.adoc" as VISION_DOC
note right of STIM
Vrije breindump
Nooit versiebeheerd
[LLM : interdit d'indexer]
end note
}
package "Cirkel 1 — configuratie/" #FFD9CC {
rectangle "Geheimen, tokens" as SECRETS
rectangle "Spring Cloud Config" as SCC
note right of SECRETS
Privaat-CVS, solo access
[LLM : INTERDIT]
end note
}
package "Cirkel 2 — kantoor/" #FFFFCC {
rectangle "Artikelen, afbakeningen" as DATA
rectangle "Opleidingen, SPG/SPD" as FORM
note right of DATA
privaat-CVS [LLM : filtré Vision/Opinion]
end note
}
package "Cirkel 3 — foundry/" #CCE5FF {
package "OSS/ — Apache 2.0" #CCFFCC {
rectangle "Plugins Gradle" as PLUGINS
rectangle "engine" as ENGINE
}
package "CSS/ — Gesloten bron" #CCDDFF {
rectangle "edster/" as EDSTER
}
}
}
@enduml
| Zone | AVG | Publieke RAG-indexering | Fine-tuning dataset | | Racine | Niveau 0 — Intiem | ✗ | ✗ | |configuration/| Niveau 1 — Beperkt | ✗ | ✗ | |office/| Niveau 2 — Collaboratief | ✓ Gefilterd | ✓ Gefilterd | |foundry/private/| Niveau 3 — Voorwaardelijk open | ✗ | ✓ Privé | |foundry/public/| Niveau 4 — Native publiek | ✓ Vrij | ✓ Publiek |
Het bijzondere geval : cheroliv.com
Terwijl ik er toch was, heb ik een andere inconsistentie gecorrigeerd. Mijn site cheroliv.com`woonde in`foundry/`als een softwareproject volwaardig — met zijn eigen Gradle-build, zijn eigen CI, zijn eigen governance.agents/`.
Maar de blogartikelen zijn geen code. Ze zijn data editorial van Cercle 2 — eveneens zoals de kaders van`office/pilotage/` of de opleidingen van`office/formations/`.
AVANT APRÈS
foundry/ office/
cheroliv.com/ sites/
site/jbake/content/blog/ cheroliv.com/
2026/0117_....adoc 2026/0117_....adocWat verandert :
-
De artikelen zijn in`office/`→ privacy van Cirkel 2
-
De taak`publishSite`wordt een capaciteit van`engine`
via`bakery-gradle`— de plugin ontvangt een`FileTree`, hij weet het niet dat de artikelen uit`office/`
-
Een enkele CI, een enkele governance — geen duplicatie
-
De Vision/Opinion-classifier (Regel 2bis) wordt automatisch toegepast:
de artikelen in`office/`worden gefilterd voordat ze gepubliceerd worden
bakery-gradle geeft er niets om
En dat is mooi. De plugin`bakery-gradle`is niet gewijzigd. Het ontvangt een directory met AsciiDoc-inhoud, het genereert HTML, het pusht op GitHub Pages. Dat deze map heet`site/jbake/content/` ou office/sites/cheroliv/— de plugin geeft er geen zak om.
// 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
}
}De interfacecontract is een Gradle-taak. Geen REST API. Geen webhook. Een taak — getyped, testbaar, uitvoerbaar lokaal en in de CI.
Impact op de Agent Governance
De granularisatie OSS/CSS wijzigt de agent governance op drie punten :
-
RAG public : het indexeringsgebied gaat van`foundry/**`
à foundry/public/(Empty)office/Vision/. De gesloten broncode Wordt uitgesloten van de index door taakconfiguratie, niet door prompt.
-
Kennisgraf : graphify-gradle produceert twee grafen :
*office/graph.json(openbaar) — relaties tussen OSS-artefacten + office/Vision Since you didn’t provide a text to translate, please provide the French text you would like me to translate into Dutch.configuration/graph_private.json(gitignored, privé) — relaties tussen CSS-artefacten, nooit gepubliceerd
-
Dataset fijnafstelling :`codebase-gradle`heeft nu twee bronnen :
*OSS/→ publieke datasets (community-modellen, benchmarks) *CSS/→ privé-datasets (intern model, eigendom fine-tuning)
Wat We Winnen (En Wat We Verliezen)
| Voorheen (plat dossier) | Na (OSS/CSS + office/sites) |
|---|---|
|
|
RAG indexeert alles zonder onderscheid |
RAG-index`OSS/`+`office/Vision`uitsluitend |
Onmogelijk om te weten of een project open source is |
Het pad`OSS/` ou `CSS/`het genoemde |
cheroliv.com heeft zijn eigen CI, zijn eigen governance |
De CI en de governance zijn gemeenschappelijk in `engine |
De blogartikelen staan in een "code"-repository |
De blogartikelen staan in`office/sites/`— data, geen code |
Risico op lekken van closed source-code in publieke embeddings |
Structureel onmogelijk —`CSS/`buiten scope RAG |
De enige kost : een`git mv`globaal over de 17 OSS-repositories + een refactor van de build.gradle.kts de engine. Het is een koude migratie — geen data in de vlucht, geen getroffen gebruikers.
Conclusion: het fysieke signaal verslaat het software-signaal
Wat ik dit middag gedaan heb, is een onzichtbare conventie vervangen. door een zichtbare scheiding in de zone`foundry/. Voorheen, moest u weten dat`edster/`was gesloten bron. Nu zie je het — het dossier heet`CSS/.
Het is dezelfde principe als de Unix-rechten, netwerk-VLANs, of de brandwerende compartimenten in een database. De veiligheid mag niet informatie zijn die je moet onthouden. Het moet een eigenschap zijn. fysiekvan het systeem.
De OSS/CSS-granulariteit is de vertaling van dit principe in het domein van de LLM-governance. De LLM hoeft niet te weten dat Edster is Vertrouwelijk. Hij moet niet in staat zijn om het te indexeren.
En dit is precies wat`CSS/`garandeert.