A Granularização OSS/CSS — Por que eu cortei foundry/ em dois
Publié le 03 May 2026
foundry/— a zona funcional que hospeda o código do meu workspace — contém 18 projetos. Oito são código aberto sob a licença Apache 2.0. Apenas um é closed source — o SaaS Edster. Durante meses, esses nove projetos coabitaram. na mesma pasta, separados apenas por… nada. O status público/privado deles era uma informação na minha cabeça, não no sistema de arquivos.
E então eu quis conectar um RAG. E aí, tudo desabou.
O acidente que esperava acontecer
Em abril de 2026, comecei a implementar o RAG pgvector para slider-gradle. O princípio: indexar todos os repositórios de`foundry/, produzir de embeddings, e injetá‑los no contexto do LLM para que ele tenha uma perception" do dossier`foundry/.
O pipeline era simples:
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)Simples. Eficaz. Eperigoso.
Porque este`fileTree`não distingue entre`plantuml-gradle/` (Apache 2.0, public) e`edster/`(closed source, private). Ele engole tudo. E se um dia eu publicar estes embeddings — num dashboard, numa resposta LLM, em um conjunto de dados de treinamento — o código proprietário da Edster está vazando.
|
O problema não é que um LLM leia código fechado. O problema, é que esse código termine em um embedding vetorial público — irreversível, não removível, não auditável. |
A Verdadeira Pergunta
Não é "como impedir que o LLM vazeie código?". É "como tornar a fuga estruturalmente impossível ?
A resposta não é um prompt. A resposta, é de cortar o dossier em dois.
A Solução: OSS/ e CSS/
Antes :
foundry/
├── plantuml-gradle/ ← public
├── bakery-gradle/ ← public
├── magic-stick/ ← public
├── edster/ ← PRIVÉ
├── slider-gradle/ ← public
└── ... ← mélange invisibleApós :
foundry/
├── OSS/ ← tout est Apache 2.0
│ ├── plantuml-gradle/
│ ├── bakery-gradle/
│ ├── magic-stick/
│ ├── slider-gradle/
│ └── ...
└── CSS/ ← tout est closed source / private
└── edster/Le `fileTree`torna-se :
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é|
O RAG público nunca vê`CSS/`. O código fechado alimenta um dataset privado de ajuste fino — um modelo interno que nunca sai da minha casa separação é mecânica, não declarativa. |
Por que "OSS" e "CSS" e não "Public" e "Private
A escolha dos acrônimos OSS (Open Source Software) e CSS (Closed Source Software) é deliberado:
-
Public"/"Private" descreve ovisibilidade(o que o GitHub vê)
-
OSS"/"CSS" descreve anaturezado código (o que o LLM deve saber)
A visibilidade do GitHub é um metadado do repositório remoto. A natureza do código é O LLM não tem acesso à API do GitHub — mas ele tem acesso ao sistema de arquivos.CSS/`ele disse "atenção, este código não está sob licença livre" sem precisar ler um`LICENSE`ou analisar um`package.json.
|
O nome da pasta é o metadado mais robusto que você pode dar a um LLM. Ela não pode ser mal analisada, ignorada, ou mal interpretada. O LLM vê`CSS/edster/`no caminho do arquivo — ele sabe |
A Árvore Completa — Quatro Zonas, Não Três
A granularização OSS/CSS complementa a ontologia de três zonas. A zona `foundry/`passa de 1 para 2 subzonas funcionais :
| Zone | RGPD | Indexação RAG pública | Ajuste fino do dataset | | Raiz | Nível 0 — Íntimo | ✗ | ✗ | | configuration/| Nível 1 — Restrito | ✗ | ✗ | | office/| Nível 2 — Colaborativo | ✓ Filtrado | ✓ Filtrado | |foundry/private/| Nível 3 — Abertura condicional | ✗ | ✓ Privado | (blank)`foundry/public/`Nível 4 — Público nativo | ✓ Livre | ✓ Público
O Caso Particular : cheroliv.com
Enquanto estava lá, corriji outra incoerência. Meu site cheroliv.com`morava em`foundry/`como um projeto de software de pleno direito — com seu próprio build Gradle, sua própria CI, sua própria governança.agents/`.
Mas os artigos de blog não são código. São dados editoriais** de Cercle 2 — da mesma forma que os enquadramentos de`office/pilotage/` ou as formações de`office/formations/`.
AVANT APRÈS
foundry/ office/
cheroliv.com/ sites/
site/jbake/content/blog/ cheroliv.com/
2026/0117_....adoc 2026/0117_....adocO que muda :
-
Os artigos estão em`office/`→ confidencialidade do Círculo 2
-
A tarefa`publishSite`torna-se uma capacidade de`engine`
via`bakery-gradle`— o plugin recebe um`FileTree`, ele não sabe que os artigos venham de`office/`
-
Um único CI, uma única governança — zero duplicação
-
O classificador Vision/Opinion (Regra 2bis) aplica-se automaticamente:
os artigos em`office/`são filtrados antes da publicação
bakery-gradle não liga
E é isso que é bonito. O plugin`bakery-gradle`não foi modificado. Ele recebe um diretório de conteúdo AsciiDoc, ele gera HTML, ele faz push no GitHub Pages. Que esse diretório se chame`site/jbake/content/` ou office/sites/cheroliv/— o plugin não se importa.
// 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
}
}O contrato de interface é uma tarefa Gradle. Não é uma API REST. Não é um webhook. Uma tarefa — tipada, testável, executável localmente e na CI.
Impacto sobre o Agente de Governança
A granularização OSS/CSS altera a governança do agente em três pontos:
-
RAG public : o perímetro de indexação passa de`foundry/**`
à foundry/public/+office/Vision/. O código closed source é excluído do índice por configuração de tarefa, não por prompt.
-
Knowledge Graph : o graphify-gradle produz dois grafos :
*office/graph.json(public) — relações entre artefatos OSS + office/Vision *configuration/graph_private.json(gitignored, privado) — relações entre artefatos CSS, nunca publicado
-
ajuste fino do conjunto de dados :`codebase-gradle`agora tem duas fontes :
*OSS/→ datasets públicos (modelos comunitários, benchmarks) *CSS/→ datasets privados (modelo interno, fine-tuning proprietário)
O Que Se Ganha (E O Que Se Perde)
Antes (pasta plana) |
Depois (OSS/CSS + office/sites) |
|
|
RAG indexa tudo sem discriminação |
RAG indexa`OSS/` + `office/Vision`exclusivamente |
Impossível saber se um projeto é open source |
O caminho`OSS/` ou `CSS/`o dito |
cheroliv.com tem sua própria CI, sua própria governança |
A CI e a governança são mutualizadas no engine |
Os artigos de blog estão em um repositório "code |
Os artigos do blog estão em`office/sites/`— dados, não código |
Risco de vazamento de código fechado em embeddings públicos |
Estruturalmente impossível —`CSS/`fora do escopo RAG |
O único custo : um`git mv`global sobre os 17 repositórios OSS + um refatoramento do build.gradle.kts de engine. É uma migração a frio Sem dados em voo, nenhum usuário impactado.
Conclusão: o sinal físico bate o sinal de software
O que eu fiz nesta tarde foi substituir uma convenção invisível por uma separação visível na zona`foundry/. Antes, você tinha que saber que`edster/`era closed source. Agora você vê — o dossiê se chama`CSS/.
É o mesmo princípio que as permissões Unix, os VLAN de rede, ou os compartimentos à prova de fogo em uma base de dados. A segurança não deve ser uma informação que você deve reter. Ela deve ser uma propriedade físicado sistema.
A granularização OSS/CSS é a tradução deste princípio no domínio da governança LLM. O LLM não precisa saber que o Edster é Confidencial. Ele precisa ser incapaz de indexá-lo.
E isso é exatamente o que`CSS/`garante.