La Granularizzazione OSS/CSS — Perché ho tagliato foundry/ in due

----
tasks.register<JavaExec>("bake") {
    mainClass.set("org.jbake.launcher.Main")
    classpath = configurations["jbake"]
    args = listOf(projectDir.absolutePath, "$buildDir/jbake")
}
----

— il plugin non se ne frega.

[source,kotlin]
----
// 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
    }
}
----

Il contratto di interfaccia è una attività Gradle. Non è un'API REST. Non è un webhook. Un compito — tipizzato, testabile, eseguibile in locale e nella CI.

== Impatto sulla governance dell'agente

La granularizzazione OSS/CSS modifica la governance degli agenti su tre punti:

1. *RAG public* : il perimetro di indicizzazione passa da`foundry/**`

à `foundry/public/**`+`office/Vision/**`Il codice sorgente chiuso è escluso dall'indice per configurazione dell'attività, non per prompt.

1. *Knowledge Graph* : graphify-gradle produce due grafi :

*`office/graph.json`(public) — relazioni tra artefatti OSS + office/Vision *`configuration/graph_private.json`(gitignored, privato) — relazioni tra artefatti CSS, mai pubblicato

1. *Fine-tuning del dataset* :`codebase-gradle`ha ora due fonti:

*`OSS/`→ datasets pubblici (modelli comunitari, benchmarks) *`CSS/`→ datasets privati (modello interno, fine-tuning proprietario)

== Cosa si guadagna (e cosa si perde)

|===
|Fronte (cartella piatta) |Dopo (OSS/CSS + office/sites) |`ls foundry/`→ misto pubblico/privato |`ls foundry/public/`tutto è pubblicabile |RAG indicizza tutto senza discriminazione |RAG indicizza`OSS/`+`office/Vision`esclusivamente |Impossibile sapere se un progetto è open source |Il percorso`OSS/` ou `CSS/`il detto |cheroliv.com ha la propria CI, la propria governance |La CI e la governance sono condivise nel motore |Gli articoli del blog sono in un repository 'code' |Gli articoli del blog sono in`office/sites/`— dati, non codice |Rischio di fuga di codice sorgente chiuso in embeddings pubblici |Strutturalmente impossibile —`CSS/` hors scope RAG
|===

L'unico costo: uno`git mv`globale sui 17 depositi OSS + un refactoring del `build.gradle.kts` de `engine`. È una migrazione a freddo — nessun dato in volo, nessun utente interessato

== Conclusione: il Segnale Fisico batte il Segnale Logico

Ciò che ho fatto questo pomeriggio è stato sostituire una convenzione invisibile da una separazione visibile nella zona`foundry/`. Prima, dovevi *sapere* che`edster/`era closed source. Ora, tu lo *vedi* — la cartella si chiama`CSS/`.

È lo stesso principio delle autorizzazioni Unix, delle VLAN di rete, o le compartimenti tagliafuoco in un database. La sicurezza non deve essere un'informazione che devi ricordare. Deve essere una proprietà **fisica**del sistema.

La granularizzazione OSS/CSS è la traduzione di questo principio nel settore della governance LLM. Il LLM non ha bisogno di sapere che Edster è confidenziale. Ha bisogno di essere incapace di indicizzarlo.

E questo è esattamente quello che`CSS/`garantisce.

== Riferimenti

* xref:0118_matrice_gouvernance_llm_zone_acces_workspace_post.adoc[Articolo 0117 — La matrice di governance LLM]
* xref:0114_gouvernance_cercles_confiance_ontologie_spatiale_alignement_llm_post.adoc[Articolo 0114 — I Cerchi di Fiducia]
* xref:0116_compartimentage_epistemique_automatise_llm_post.adoc[Articolo 0116 — Il Compartimentaggio Epistemico Automatizzato]
* xref:0108_gouvernance_agent_opencode_eager_lazy_post.adoc[Articolo 0108 — Gestire un agente IA con AsciiDoc]