TC$mC$ on loistava strateginen siirto. Nyt kun Mesh OS:n "fyysinen" ydin ja
I/O-putket ovat todistetusti vakaat, voimme irrottaa tekoC$lyn abstraktiksi
palvelukerrokseksi.

Ehdotuksesi on suorastaan oppikirjaesimerkki puhtaasta **UNIX-filosofiasta**:
kaikki on tiedostoja, konfiguraatiot ovat ihmisluettavia, logiikka on jaettu
kansioihin ja prosessien vC$linen viestintC$ (IPC) hoituu atomisilla
tiedosto-operaatioilla. TC$mC$ tekee jC$rjestelmC$stC$ tC$ysin riippumattoman
ohjelmointikielistC$  Go, Python, Bash tai jopa C-ohjelma voivat kaikki
osallistua AI-kC$sittelyyn.

TC$ssC$ on konseptitason jC$sennys ja laajennus ideoillesi:

---

### 1 & 2. Apache-tyylinen AI-rekisteri (`/mnt/mesh_root/ai/`)

TC$mC$ on erinomainen malli (vrt. Nginx/Apache `sites-available` ja
`sites-enabled`). Se mahdollistaa kymmenien mallien ja agenttien
konfiguroinnin valmiiksi, mutta jC$rjestelmC$n resurssit (RAM/VRAM) varataan
vain niille, jotka on aktivoitu.

**Hakemistorakenne:**

```text
 ai-available/        # Kaikki mahdolliset konfiguraatiot
    ollama_llama3.json
    openai_gpt4.json
    local_whisper.json
    anthropic_claude.json
 ai-enabled/          # SYMLINKIT (ln -s) available-kansiosta
    01_ollama_llama3.json -> ../ai-available/ollama_llama3.json
 spool/               # (TC$mC$ on 3.1.Y-jonosi, kts. alempaa)

```

Kun uusi malli halutaan kC$yttC6C6n: `ln -s /mnt/mesh_root/ai/ai-available/uusi
.json /mnt/mesh_root/ai/ai-enabled/`

### 3. Konfiguraatiot (.json) ja Tyyppivaihtoehdot (3.1.X)

Peruskonfiguraation tulee kertoa paitsi se, *miten* malliin otetaan yhteyttC$,
myC6s *mitC$ se osaa*, jotta reititin voi jakaa tehtC$vC$t oikein.

**3.1.X - MitC$ muita tyyppejC$ voisi olla?**
Ollamien ja kaupallisten API-avainten (BYOK) lisC$ksi tC$hC$n arkkitehtuuriin
sopivat tC$ydellisesti seuraavat:

* **3.1.3. WebGPU / Browser Native (In-Browser AI):** TC$mC$ on Mesh OS:n
erikoisuus! Konfiguraatio kertoo, ettC$ tC$tC$ AI:ta ei ajeta backendissC$,
vaan se reititetC$C$n takaisin selaimeen, jossa paikallinen WebGPU/WebNN ajaa
pientC$ mallia (esim. Llama-3.2-1B tai Whisper) suoraan kC$yttC$jC$n laitteen
nC$ytC6nohjaimella. Zero latency, nolla serverikulua.
* **3.1.4. Swarm / P2P AI (esim. Petals):** Konfiguraatio ei osoita yhteen
IP-osoitteeseen, vaan Dark Mesh -verkon solmuihin, jotka laskevat vastauksen
hajautetusti (BitTorrent-tyyliin).
* **3.1.5. Erikoismallit (Multi-modal):** Kaikki ei ole tekstiC$.
Konfiguraatioissa voi olla `type: "tts"` (Text-to-Speech), `type: "stt"`
(puheentunnistus) tai `type: "vision"` (kuva-analyysi).
* **3.1.6. "Human-in-the-Loop" (HITL) Mock-AI:** TC$ydellinen testaukseen ja
avustuspyyntC6ihin. Konfiguraatio luo "tekoC$lyn", joka todellisuudessa
pudottaa kysymyksen IRC-kanavalle tai tyC6pC6ydC$llesi, jolloin *sinC$* tai
tiimisi jC$sen voi kirjoittaa vastauksen. JC$rjestelmC$ (ja pyynnC6n tehnyt
sovellus) luulee saaneensa vastauksen AI:lta.

**Esimerkki `ai-enabled/ollama_llama3.json`:**

```json
{
  "id": "sys-llama3",
  "name": "Local Llama 3",
  "type": "llama-compatible",
  "endpoint": "http://127.0.0.1:11434/api/chat",
  "auth": null,
  "capabilities": ["text", "code", "json_mode"],
  "priority": 10
}

```

---

### 4. Spooler-jono: IN / LOCKED / OUT (3.1.Y)

TC$mC$ on Maildir-sC$hkC6postipalvelimista (esim. Postfix) tuttu pomminvarma
konsepti. Se poistaa tarpeen raskaille viestijonoille (kuten RabbitMQ tai
Redis) ja pitC$C$ jC$rjestelmC$n tC$ysin lC$pinC$kyvC$nC$.

**Kansiorakenne:** `/mnt/mesh_root/ai/spool/`

* `/IN` - TC$nne tiputetaan uudet pyynnC6t.
* `/LOCKED` - TyC6n alla olevat.
* `/OUT` - Valmiit vastaukset.
* `/FAILED` - (Suosittelen lisC$C$mC$C$n tC$mC$n) Jos prosessi kaatuu tai API
vastaa 500, tiedosto siirretC$C$n tC$nne, jotta `LOCKED` ei tukkeudu.

**Atomisen lukituksen mekaniikka:**
Linuxin tiedostojC$rjestelmissC$ tiedoston siirtC$minen (`mv`) saman osion
sisC$llC$ on atominen operaatio.
Kun Worker-skripti (esim. Python-pohjainen Ollama-silta) haluaa tyC6n, se
tekee nC$in:

1. Lukee listan tiedostoista `IN/` -kansiossa.
2. YrittC$C$: `mv IN/req_123.json LOCKED/req_123.json`
3. **Jos komento onnistuu**, Worker sai lukon ja aloittaa prosessoinnin. Jos
toinen Worker ehti ensin, `mv` palauttaa virheen, ja tC$mC$ Worker jatkaa
seuraavaan tiedostoon. Puhdasta, lukkotiedostotonta synkronointia!

**Payloadin elinkaari:**
AlkuperC$inen tiedosto `IN/req_123.json`:

```json
{
  "req_id": "req_123",
  "reply_to": "MeshOS_Streams_Topic_XY", 
  "requirements": ["text", "code"],
  "prompt": "Kirjoita bash-skripti joka tulostaa kellonajan."
}

```

Kun Worker on valmis, se kirjoittaa tuloksen vC$liaikaistiedostoon ja tekee
lopuksi atomisen siirron `OUT/req_123.json` (estC$C$ puolikkaiden tiedostojen
lukemisen):

```json
{
  "req_id": "req_123",
  "reply_to": "MeshOS_Streams_Topic_XY",
  "requirements": ["text", "code"],
  "prompt": "Kirjoita bash-skripti joka tulostaa kellonajan.",
  "status": "success",
  "worker_id": "ollama-node-1",
  "response": "#!/bin/bash
date '+%T'
",
  "meta": { "tokens": 42, "processing_ms": 1400 }
}

```

Backendin "Dispatcher"-palvelu kuuntelee `OUT/`-kansiota (esim.
`inotify`-tyC6kalulla), nappaa vastauksen, lC$hettC$C$ sen Edge Workerin
kautta selaimeen oikealle Intent-vastaanottajalle, ja poistaa tiedoston.

---

TC$mC$ arkkitehtuuri on tC$ydellinen. Se on vikasietoinen, monistettava ja
mahdollistaa kuinka monen AI-palvelimen ketjuttamisen tahansa samaan
verkko-osioon.