Granularisasi OSS/CSS — Mengapa Saya Memotong foundry/ menjadi Dua

Diterbitkan 03 May 2026

waktu membaca : 10 minutes

foundry/— zona fungsional yang menampung kode dari ruang kerja saya — Mengandung 18 proyek. Delapan bersifat open source di bawah lisensi Apache 2.0. Hanya satu sumber tertutup — SaaS Edster. Selama berbulan-bulan, sembilan proyek ini telah berdampingan. dalam folder yang sama, dipisahkan hanya oleh…​ tidak ada. Status publik/privat mereka adalah sebuah informasi dalam kepalaku, bukan di sistem file.

Dan kemudian saya ingin menghubungkan sebuah RAG. Dan di situ, semuanya runtuh.

Kejadian yang menunggu untuk terjadi

Pada April 2026, saya mulai mengimplementasikan pgvector RAG untuk slider-gradle. Prinsip: mengindeksi semua repositori`foundry/, menghasilkan beberapa embeddings, dan suntikan ke dalam konteks LLM agar ia memiliki sebuah persepsi" kasus`foundry/.

Pipeline tersebut sederhana:

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)

Sederhana. Efektif. Danberbahaya.

Karena ini`fileTree`tidak membedakan antara`plantuml-gradle/` (Apache 2.0, publik) dan`edster/`(closed source, private). Dia menelan semuanya. Dan jika suatu hari saya mempublikasikan embedding ini — di dashboard, dalam satu respons LLM, dalam dataset pelatihan — kode Edster yang proprietary sedang bocor.

Masalahnya bukan bahwa LLM membaca kode sumber tertutup. Masalahnya, bahwa kode ini harus berakhir dalam embedding vektor publik — tidak dapat dibalik, tidak dapat dihapus, tidak dapat diaudit.

Pertanyaan sebenarnya

Bukan "bagaimana mencegah LLM bocor kode?". Adalah "bagaimana membuat pelarian secara struktural menjadi mustahil?

Jawaban bukan prompt. Jawaban, itu memotong folder menjadi dua.

Solusi : OSS/ dan CSS/

Sebelum :

foundry/
├── plantuml-gradle/       ← public
├── bakery-gradle/         ← public
├── magic-stick/           ← public
├── edster/                ← PRIVÉ
├── slider-gradle/         ← public
└── ...                    ← mélange invisible

Setelah :

foundry/
├── OSS/                   ← tout est Apache 2.0
│   ├── plantuml-gradle/
│   ├── bakery-gradle/
│   ├── magic-stick/
│   ├── slider-gradle/
│   └── ...
└── CSS/                   ← tout est closed source / private
    └── edster/

Le `fileTree`menjadi :

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 umum tidak pernah melihat`CSS/`. Kode closed source memberi dataset tanpa fine-tuning — sebuah model internal yang tidak pernah keluar dari rumahku. La pemisahan adalah mekanik, bukan deklaratif.

Mengapa "OSS" dan "CSS" dan Bukan "Public" dan "Private

Pemilihan akronim OSS (Open Source Software) dan CSS (Closed Source Software) adalah disengaja:

  • Public"/"Private" menjelaskankejelasan(apa yang GitHub lihat)

  • OSS"/"CSS" menggambarkanalamkode (yang harus diketahui oleh LLM)

Keterlihatan GitHub adalah metadata dari repositori jarak jauh. Sifat kode adalah sifat dari konten. LLM tidak memiliki akses ke API GitHub — tetapi ia memiliki akses ke sistem file.CSS/`dia berkata kepadanya "perhatian, kode ini tidak berada di bawah lisensi free" tanpa perlu membaca satu`LICENSE`atau untuk mengurai sebuah`package.json.

Nama folder adalah metadata paling kuat yang dapat Anda berikan kepada sebuah LLM. Dia tidak dapat diparsing dengan salah, diabaikan, atau diinterpretasikan dengan salah. LLM tersebut melihat`CSS/edster/`Dalam jalur file — dia tahu

Pohon Lengkap — Empat Zona, Bukan Tiga

Granularisasi OSS/CSS menyelesaikan ontologi tiga zona. Zona `foundry/`beralih dari 1 ke 2 subzona fungsional:

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 260

title Organisasi foundry/ — Granularisasi OSS/CSS
package "pabrik pengecoran/" {

  package "Lingkaran 0 — Akar" #FFCCCC {
    rectangle "PICTURE_ME_ROLLIN_*.adoc" as STIM
    rectangle "WORKSPACE_*.adoc" as VISION_DOC
    note right of STIM
      Brain dump libre
      Jamais versionné
      [LLM : interdit d'indexer]
    end note
  }

  package "Lingkaran 1 — konfigurasi/" #FFD9CC {
    rectangle "Rahasia, token" as SECRETS
    rectangle "Spring Cloud Config" as SCC
    note right of SECRETS
      Privé-CVS, solo access
      [LLM : INTERDIT]
    end note
  }

  package "Lingkaran 2 — kantor/" #FFFFCC {
    rectangle "artikel, pengkawangan" as DATA
    rectangle "Pelatihan, SPG/SPD" as FORM
    note right of DATA
      Privé-CVS
      [LLM : filtré Vision/Opinion]
    end note
  }

  package "Lingkaran 3 — pabrik cetak/" #CCE5FF {
    package "OSS/ — Apache 2.0" #CCFFCC {
      rectangle "Plugin Gradle" as PLUGINS
      rectangle "mesin" as ENGINE
    }
    package "CSS/ — Sumber tertutup" #CCDDFF {
      rectangle "edster/" as EDSTER
    }
  }
}

@enduml

| Zona | GDPR | Indeksasi RAG publik | Dataset penyetelan halus | | Akar | Tingkat 0 — Pribadi | ✗ | ✗ | (empty)configuration/| Level 1 — Terbatas | ✗ | ✗ | | office/| Tingkat 2 — Kolaboratif | ✓ Disaring | ✓ Disaring | | foundry/private/| Tingkat 3 — Terbuka Bersyarat | ✗ | ✓ Pribadi | | foundry/public/| Tingkat 4 — Masyarakat Asli | ✓ Gratis | ✓ Publik |

Kasus Khusus : cheroliv.com

Sementara saya berada di sana, saya memperbaiki ketidaksesuaian lain. Situs saya cheroliv.com`hidup di`foundry/`seperti sebuah proyek perangkat lunak sepenuhnya — dengan build Gradle sendiri, CI sendiri, sendiri tata kelola.agents/`.

Tetapi artikel blog bukan kode. Ini adalah data. redaksi** Lingkaran 2 — sama seperti kerangka`office/pilotage/` atau formasi dari`office/formations/`.

AVANT                            APRÈS
foundry/                office/
  cheroliv.com/                    sites/
    site/jbake/content/blog/         cheroliv.com/
      2026/0117_....adoc               2026/0117_....adoc

Yang berubah:

  • Artikel ada di`office/`→ kerahasiaan Cercle 2

  • Tugas`publishSite`menjadi sebuah capability dari`engine`

melalui`bakery-gradle`— plugin menerima satu`FileTree`, dia tidak tahu bahwa artikel-artikel berasal dari`office/`

  • Satu saja CI, satu saja tata kelola — duplikasi nol

  • Klasifikasi Vision/Opinion (Aturan 2bis) berlaku secara otomatis :

artikel di`office/`disaring sebelum publikasi

bakery-gradle tidak peduli

Dan itulah yang indah. Plugin tersebut`bakery-gradle`tidak telah diubah. Menerima direktori konten AsciiDoc, ia menghasilkan HTML, ia push on GitHub Pages. bahwa direktori ini dinamakan`site/jbake/content/` ou office/sites/cheroliv/— plugin tidak peduli.

// 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
    }
}

Kontrak interface adalah tugas Gradle. Bukan API REST. Bukan webhook. Tugas — bertipe, dapat diuji, dapat dieksekusi secara lokal dan dalam CI.

Dampak pada Agen Tata Kelola

Granularisasi OSS/CSS mengubah tata kelola agen pada tiga poin:

  1. RAG public : lingkup indeksasi beralih dari`foundry/**`

à foundry/public/+office/Vision/. Kode sumber tertutup dikeluarkan dari indeks oleh konfigurasi tugas, bukan oleh prompt.

  1. Knowledge Graph : graphify-gradle menghasilkan dua graf :

*office/graph.json(publik) — hubungan antara artefak OSS + office/Vision *configuration/graph_private.json(gitignored, pribadi) — hubungan antara artefak CSS, tidak pernah dipublikasikan

  1. penyetelan halus dataset :`codebase-gradle`sekarang memiliki sumber :

*OSS/→ datasets publik (model komunitas, benchmarks) *CSS/→ kumpulan data pribadi (model internal, fine-tuning proprietary)

Apa yang Kita Dapatkan (Dan Apa yang Kita Hilangkan)

Sebelum (folder datar)

Setelah (OSS/CSS + office/sites)

ls foundry/→ kampuran publik/privat

ls foundry/public/→ semua dapat dipublikasikan

RAG mengindeks semua tanpa diskriminasi

RAG mengindeks`OSS/`+`office/Vision`hanya

Tidak dapat mengetahui apakah proyek itu open source

jalan`OSS/` ou `CSS/`yang dikatakan

cheroliv.com memiliki CI sendiri, tata kelola sendiri

CI dan tata kelola dibagikan bersama dalam engine

Artikel blog berada di repositori 'code'

Artikel blog ada di`office/sites/`— data, bukan kode

Risiko kebocoran kode sumber tertutup dalam embeddings publik

Mustahil secara struktural —`CSS/`di luar lingkup RAG

Biaya tunggal : satu`git mv`global pada 17 repositori OSS + sebuah refactor dari build.gradle.kts de engine. Ini adalah migrasi dingin — Tidak ada data selama penerbangan, tidak ada pengguna yang terpengaruh.

Kesimpulan: Sinyal Fisik mengalahkan Sinyal Perangkat Lunak

Yang saya lakukan siang ini adalah mengganti sebuah konvensi tak terlihat. dengan pemisahan yang terlihat di zona`foundry/. Sebelum, Anda harus mengetahui bahwa`edster/`was sumber tertutup. Sekarang, Anda lihat — nama folder adalah`CSS/.

Ini adalah prinsip yang sama seperti izin Unix, VLAN jaringan, atau kompartemen tahan api dalam basis data. Keamanan tidak boleh Ini harus menjadi informasi yang harus Anda ingat. Ini harus menjadi sebuah properti. fisiksistem.

Granularisasi OSS/CSS adalah penerapan prinsip ini dalam bidang. dari tata kelola LLM. LLM tidak perlu tahu bahwa Edster adalah rahasia. Dia perlu tidak mampu mengindeksnya.

Dan itu persis apa`CSS/`menjamin.

Referensi

Artikel terkait

HyperFrames-Gradle : Mengubah AsciiDoc menjadi Video MP4
31 May 2026
Audit dari Konsumsi LLM saya: SQLite, OpenCode, Ollama Cloud, dan Mengapa Abonnement Pro saya Meledak Pasar Global
18 May 2026
Arsitektur « Plugin Independen + Akar Konsumen » : Mengapa Build Gradle Saya Menduplikat?
14 May 2026
Knowledge Graph sebagai mesin rekomendasi: bagaimana saya membunuh artikel terkait berurutan
12 May 2026