TC$mC$ on aivan nerokas veto! Asynkroninen IN/OUT-kansiomalli (drop-directory
tai spooler pattern) on ohjelmistoarkkitehtuurin todellinen "ilmalukko". Se
irrottaa ohjauslogiikan tC$ysin verkkorajapinnoista ja takaa sen, ettC$
`node-base` pysyy tC$ydellisessC$ tietotyhjiC6ssC$. Se vain lukee tiedoston,
tekee tyC6n ja jC$ttC$C$ vastauksen  ehdottoman turvallinen, ulkokaistan
(out-of-band) kommunikaatiokanava.

KC$ymC$si 21 kohdan lista on erittC$in kattava ja kertoo, ettC$ olet miettinyt
orkestroinnin todella pitkC$lle. Ryhmittelin ideasi loogisiin kokonaisuuksiin,
lisC$sin niihin tekniset toteutustavat (miten ne oikeasti kytkeytyvC$t juuri
rakentamaamme Cgroups/V8-moottoriin) ja tC$ydensin listaa muutamalla
kriittisellC$ ominaisuudella, jotka sitovat kokonaisuuden yhteen.

### 1. Elinkaari ja Resurssit (Vastaa kohtia 1, 8-12, 17, 20-21)

TC$mC$ osio on suoraviivainen, mutta mukana on pari hienoutta:

* **Suspend/Resume (8, 12):** Voimme toteuttaa tC$mC$n todella kevyesti
suoraan Linuxin ydinominaisuuksilla lC$hettC$mC$llC$ prosessille `SIGSTOP`
(jC$C$dyttC$C$ suorituksen tC$ysin) ja `SIGCONT` (jatkaa suoritusta)
-signaalit. CPU-aikaa ei kulu sekuntiakaan suspend-tilassa.
* **Safe Mode (17):** Kuten aiemmin rakensimme, tC$mC$ vaatii instanssin
kC$ynnistC$misen uudelleen, jotta `--inspect-brk` -lippu saadaan aktivoitua
ennen V8-moottorin kC$ynnistymistC$.
* **JC$rjestelmC$n tila ja virranhallinta (20-21):** Autonomisille
OMEGA-agenteille elintC$rkeC$ ominaisuus. NC$iden avulla agentti voi
monitoroida Cgroups-karsinoiden kokonaiskulutusta (`uptime`, `free`) ja
tarvittaessa suorittaa kontille "hard resetin".

### 2. Koodinhallinta ja V8-syvC$luotaus (Vastaa kohtia 13-16, 18-19)

TC$ssC$ piilee API:n suurin taika:

* **LC$hdekoodin operointi (13-16):** Instanssin lC$hdekoodin lukeminen,
asettaminen ja sed-tyyppinen korvaus puskurista.
* **Inject-Eval ja Batch-ajo (18-19):** NC$mC$ kohdat ovat loistavia. Emme
tarvitse hiekkalaatikon sisC$lle mitC$C$n vaarallista `eval()`-funktiota.
Voimme toteuttaa nC$mC$ **suoraan V8 Debugger -protokollan (CDP)** kautta!
Orkestraattori voi muodostaa yhteyden lokaaliin socketiin ja komentaa
V8-moottoria injektoimaan koodia suoraan kC$ynnissC$ olevaan kontekstiin
ilman, ettC$ vieras koodi voi estC$C$ sitC$ tai edes tietC$C$ siitC$.

### 3. Metatiedot ja Tilan hallinta (Vastaa kohtia 2-7)

Koska arkkitehtuuri ei nojaa tietokantoihin, JSON-pohjainen metatiedon
hallinta (avaimen asetus, merge, replace, listaus) on tC$ydellinen tapa
sC$ilyttC$C$ instanssien kontekstia. TC$nne voidaan tallentaa esimerkiksi
simulaation iteraatiokierrokset, aliakset, tagit tai karsinalle allokoidut
resurssirajat.

---

### 3. Metatiedot ja Tilan hallinta (Vastaa kohtia 2-7)( MitC$ puuttuu?
(TC$ydennykset OMEGA-paketteihin)

Lista on erinomainen, mutta siitC$ uupuu kaksi elintC$rkeC$C$ mekanismia,
jotta asynkroninen automaatio voi toimia ja jotta simulaatiodata saadaan
liikkumaan:

**A. Muistipankkien (memfd) I/O-operaatiot**
Hiekkalaatikon koko juju on siinC$, ettC$ se on sidottu jaettuun muistiin.
Orkestraattorin tC$ytyy pystyC$ lukemaan ja kirjoittamaan tC$tC$ muistia
ulkopuolelta, muuten esim. solualutomaattien tai muiden simulaatioiden
tilapC$ivityksiC$ ei voida siirtC$C$ sisC$C$n tai lukea ulos.

* *LisC$ys 22:* Luo uusi muistipankki (koko V).
* *LisC$ys 23:* Lue muistipankin X sisC$ltC6 (offset O, pituus L) -> palauttaa
datan (esim. Base64 tai Hex).
* *LisC$ys 24:* Kirjoita muistipankkiin X (offset O, data V).
* *LisC$ys 25:* LiitC$ muistipankki X hiekkalaatikkoon Y.

**B. Lokien tilaus (Log Tailing)**

* *LisC$ys 26:* PyydC$ hiekkalaatikon X `stdout`/`stderr` -puskurin viimeiset
N riviC$, jotta IN/OUT-kansion kautta toimiva agentti voi analysoida
ajonaikaisia tulosteita.

**C. Asynkroninen Kirjekuori (Correlation ID)**
Koska kansioihin tippuu tiedostoja satunnaisessa jC$rjestyksessC$,
`node-base`-daemonin on pakotettava jokaiseen pyyntC6C6n yksilC6llinen
tunniste (`transactionId` tai `reqId`).

### Hahmotelma OMEGA-paketin (JSON) formaatiksi

IN-kansioon tiputettava tiedosto (esim. `cmd_8f72a.json`) voisi nC$yttC$C$
rakenteellisesti tC$ltC$:

```json
{
  "transactionId": "8f72a9b3-...",
  "timestamp": "2026-08-08T11:48:45Z",
  "command": "INSTANCE_INJECT_EVAL",
  "targetId": "hiekkalaatikko-x-tai-uuid",
  "payload": {
    "buffer": "c2hhcmVkTWVtWzBdID0gOTk5OTs=", 
    "encoding": "base64"
  }
}

```

Kun `node-base`-daemon on kC$sitellyt tC$mC$n, se luo OUT-kansioon
vastaustiedoston (esim. `res_8f72a.json`):

```json
{
  "transactionId": "8f72a9b3-...",
  "timestamp": "2026-08-08T11:48:46Z",
  "status": "SUCCESS",
  "data": {
    "evalResult": "true",
    "executionTimeMs": 14
  }
}

```

TC$llC$ tavalla kuka tahansa OMEGA-verkoston asukas voi tiputtaa pyyntC6jC$
kansioon ja poimia vastaukset varmasti oikeaan kontekstiin korreloituna, ilman
ettC$ jC$rjestelmien tarvitsee tuntea toisiaan.

MiltC$ tC$llainen pakettirakenne ja komentojen tC$ydennys kuulostaa; alammeko
seuraavaksi koodaamaan itse daemonia, joka kuuntelee nC$itC$ IN/OUT -kansioita
tiedostojC$rjestelmC$n tasolla (esim. `inotify`:n tai `fs.watch`:n avulla)?