TC$mC$ on konseptuaalisesti aivan timanttinen ja tC$ydellisesti linjassa sen
kanssa, mitC$ vikasietoinen ja hajautettu jC$rjestelmC$ vaatii. Kun paketti
kantaa mukanaan oman identiteettinsC$, allekirjoituksensa ja suoritusohjeensa,
ja se kirjoitetaan heti fyysiselle levylle (tai MeshFS-muistiin) turvaan ennen
mitC$C$n kC$sittelyC$, reitittimestC$ tulee tC$ysin kaatumaton.

KC$ydC$C$n tC$mC$ lC$pi konseptitasolla varmistaaksemme, ettC$ jokainen
palanen loksahtaa paikalleen.

---

### 1. OMEGA-paketin kapsulointi ja elinkaari (The Update Envelope)

Kuvailemasi rakenne on kC$ytC$nnC6ssC$ moderni versio sC$hkC6postin ja
hajautettujen transaktioverkkojen yhdistelmC$stC$ (vC$hC$n kuin
PGP-allekirjoitettu RPC-kutsu). Kun kohdereititin vastaanottaa paketin, se
puretaan seuraavien kenttien mukaan:

* **Identiteetti ja Reititys:** `target_omega_id` mC$C$rittC$C$, kenelle
paketti kuuluu, ja `sender_omega_id` kertoo, minne vastaukset tai lokit
palautetaan.
* **Kryptografinen turva:** `signature` varmistaa, ettC$ koodipC$ivityksen tai
rutiinin lC$hettC$jC$ on luotettu (Trusted-peers -lista). Jos allekirjoitus ei
tC$smC$C$, paketti hylC$tC$C$n heti ennen mitC$C$n ajo-yrityksiC$.
* **Payload-mC$C$ritelmC$t:**
* `mime_type`: `application/omega-js-extension` kertoo suoraan moottorille,
ettC$ kyseessC$ on dynaamisesti ajettava laajennus tai rutiini.
* `name`: Antaa rutiinille nimen (esim. `irc_connectivity`), jolla se
rekisterC6idC$C$n tai korvataan globaalissa mapissa.
* `instruction`: `try_run` kertoo moottorille, ettC$ suoritus on suojattava
`try/catch`-lohkolla ja mahdolliset kaatumiset tai poikkeukset on siepattava
hallitusti.
* `output_target` & `routing`: MC$C$rittC$vC$t, minne `stdout`/`stderr`-lokit
ja paluuarvot ohjataan (lC$hettC$jC$n osoitteeseen tai suoraan poistojonoon).



---

### 2. MeshFS-kansiorakenne ja levypuskurointi (Disk-Secured WAL)

Olet aivan asian ytimessC$: **Write-Ahead Log (WAL)** -tyylinen
levypuskurointi heti saapumishetkellC$ on ainoa tapa taata nollahC$vikki. Jos
reititin kaatuu kesken koodin evaluaation, uudelleenkC$ynnistyksen yhteydessC$
in-kansio luetaan automaattisesti uudelleen.

Esimerkitetty kansiorakenne reitittimen omalla tunnisteella (esim.
`omega-router-8830`) MeshFS:ssC$ voisi nC$yttC$C$ tC$ltC$:

```text
 in/              <-- Saapuvat uudet paketit kirjoitetaan HETI tC$nne
(Idempotenttinen ID-nimihC$ssC$kkC$)
 out/             <-- LC$htevC$t vasteet ja lokipaketit odottavat tC$C$llC$
verkkoon pC$C$syC$
 archive-in/      <-- Onnistuneesti kC$sitellyt saapuneet paketit siirretC$C$n
tC$nne auditointia varten
 archive-out/     <-- LC$hetetyt vasteet arkistoituvat tC$nne

```

**Idempotenssi kC$ytC$nnC6ssC$:**
Paketin tiedostonimenC$ kC$ytetC$C$n sen yksilC6llistC$ ID:tC$ (esim.
`msg_9f8a3b11.json`). Jos sama paketti saapuu uudelleen verkon
uudelleenlC$hetyksen vuoksi, reititin nC$kee, ettC$ tiedosto lC6ytyy jo `in/-`
tai `archive-in/`-kansiosta, ja se ohitetaan turvallisesti ilman turhaa
uudelleensuoritusta.

---

### 3. Suorituksen ja lokien palautusreitti (Try-Run & Feedback Loop)

Kun `try_run` kC$ynnistyy turvallisessa `vm`-hiekkalaatikossa:

1. Kaikki `console.log`-tulosteet ja virheet kaapataan muistiin.
2. Suorituksen jC$lkeen reititin pakkaa tuloksen uuteen OMEGA-vastepakettiin
(`application/omega-execution-result`).
3. Vaste kirjoitetaan reitittimen omaan `out/`-kansioon.
4. Reititin yrottC$C$ lC$hettC$C$ vastauksen takaisin lC$hettC$jC$n
ilmoittamaan paluureittiin. Jos yhteys ei ole auki, paketti jC$C$ odottamaan
`out/`-kansioon, kunnes kohde on tavoitettavissa.

TC$mC$ tekee jC$rjestelmC$stC$ tC$ysin epC$synkronisen ja hC$iriC6nsietoisen:
voit lC$hettC$C$ koodipC$ivityksen offline-tilassa olevalle reitittimelle, ja
se suorittaa sen heti kun herC$C$, palauttaen lokit takaisin.

Haluatko, ettC$ lC$hdetC$C$n seuraavaksi hahmottelemaan tC$tC$
tiedostopohjaista in/out-jonotuslogiikkaa ja sen integrointia tuohon C$sken
tehtyyn `omega_router_core.js` -referenssimoottoriin?