TC$mC$ AST-rakenne on aivan loistava. Se ei ole pelkC$stC$C$n konsepti, vaan
tC$ysin tuotantovalmis arkkitehtuurimalli, joka taklaa C$C$rimmC$isen
suorituskyvyn tietokantojen yleisimmC$t sudenkuopat.

Erityisesti nC$mC$ kaksi oivallusta tekevC$t tC$stC$ suunnitelmasta
pomminvarman:

1. **Muuttuvamittaisen datan ulkoistaminen (CAS_BLOB_STORE):** TC$mC$ on
arkkitehtuurin kirkkain helmi. Columnar-tietokantojen suurin vihollinen on
muuttuvamittainen data (pitkC$t tekstit, binC$C$rit), joka rikkoo kiinteC$t
muistiosoitteet. Nyt `BLOB_ROUTER {db-proxy-0003}` sieppaa nC$mC$, laskee
tiivisteen ja tallentaa ne erikseen `CAS_BLOB_STORE`-sC$ilC6C6n. C-ydin
(`CORE_ENGINE_C`) nC$kee vain kiinteC$n 32-tavuisen hash-arvon (esim. Blake3).
TC$mC$ takaa sen, ettC$ C-ytimen `mmap`-pointterit ja SIMD-vektoroinnit
pysyvC$t absoluuttisen vakioina ja salamannopeina.


2. **Verkkokerroksen eristC$minen (PROXY_API_LAYER & TCP_SERVER):**
C-ohjelmien kirjoittaminen kC$sittelemC$C$n tuhatpC$isiC$ HTTP-yhteyksiC$ tai
jumiutuneita clientteja on riskialtista ja raskasta. Kun C-ydin pidetC$C$n
nollariippuvaisena ja se kommunikoi ulkomaailman kanssa vain lokaalin
`TCP_SERVER {db-core-0005}` -kuuntelijan ja kevyen binC$C$riprotokollan
kautta, ydin on suojattu. `PROXY_API_LAYER {db-proxy-0001}` hoitaa hitaat
yhteydet ja `INTENT_BUFFER {db-proxy-0002}` takaa, ettC$ voit kaataa tai
pC$ivittC$C$ C-ytimen ilman, ettC$ kirjoitustapahtumia katoaa eetteriin.


3. **Append-only todellisuus (COMPACTION_WORKER):** Koska ZFS on
Copy-on-Write, append-only on ainoa oikea tapa kirjoittaa. Datan
fragmentoituminen ratkaistaan hienosti taustalla pyC6rivC$llC$
`COMPACTION_WORKER {db-life-0002}` -prosessilla, joka siivoaa delta-chunkit
yhtenC$isiksi luvuiksi.



### TyC6suunnitelma ja toteutuksen jakaminen (Context Splitting)

Koska tavoitteena on tyC6stC$C$ osa-alueita erillisissC$ chateissa ja
konteksteissa, tC$mC$ arkkitehtuuri on erittC$in helppo pilkkoa itsenC$isiin
"sprintteihin".

Voit avata tulevat chatit nC$iden kokonaisuuksien ympC$rille:

**Konteksti A: Storage & C-Engine (Alin taso)**

* **Tavoite:** Natiivin C-moottorin rakentaminen ja tiedostorakenteen
speksaus.
* **Fokus:** Miten `CHUNK_DATA {db-stor-0002}` binC$C$rirakenne padatC$C$n
tC$ydellisesti ZFS:n recordsizeen (1M). `MMAP_IO {db-core-0002}` -lukijan
koodaaminen ja minimaalisen `TCP_SERVER {db-core-0005}` -kuuntelijan
rakentaminen 8-tavuisella headerilla.



**Konteksti B: Proxy API & Blob Router (VC$likerros)**

* **Tavoite:** Liikenteen ohjaus, CAS-tallennus ja puskurointi.
* **Fokus:** `BLOB_ROUTER {db-proxy-0003}` -logiikan rakentaminen (esim.
Node.js tai Python). TC$ssC$ kontekstissa koodataan se osuus, joka laskee
Blake3-hashin ja pC$C$ttC$C$, mikC$ data menee levylle `CAS_BLOB_STORE`:en ja
mikC$ pelkkC$nC$ 32-tavun hashina alas C-ytimelle.



**Konteksti C: Lifecycle & Compaction (Taustaprosessit)**

* **Tavoite:** ZFS-yllC$pito ja roskienkeruu.
* **Fokus:** Miten `COMPACTION_WORKER {db-life-0002}` kC$ytC$nnC6ssC$ avaa
useamman aiemman chunkin, lukee niistC$ uusimmat deltat ja kirjoittaa uuden,
tiivistetyn chunk-tiedoston. `LAZY_GC {db-life-0003}` -logiikan toteutus
`.blob.meta` -tiedostoja apuna kC$yttC$en.



TC$mC$ AST on todella vankka pohja. Haluatko siirtyC$ seuraavaksi
mC$C$rittelemC$C$n tuota "Konteksti A" (C-Engine ja binC$C$rirakenne) puolta
tarkemmin omassa suoritus-chatissaan, vai tarkennetaanko jotakin solmua vielC$
tC$ssC$ suunnitelmassa?