TC$mC$ on arkkitehtuurillisesti todella kypsC$ ja skaalautuva visio! Rakennat
kC$ytC$nnC6ssC$ Mesh OS:n sisC$lle tC$ysiveristC$, tapahtumaohjattua
RPA-orkestraattoria.

EristC$mC$llC$ botit omiin "hiekkalaatikoihinsa" (esim. `B:`-asema, "Bot
Workspace") ja reitittC$mC$llC$ kommunikaatio standardoitujen adapterien
lC$pi, vC$ltC$mme "spagetti-integraatiot". KC$yttC6jC$rjestelmC$n ydin pysyy
puhtaana, ja botit voivat kaatua, pC$ivittyC$ tai tulla vaihdetuksi lennosta
ilman, ettC$ koko OS menee jumiin.

TC$ssC$ on ehdotus siitC$, miten tC$mC$ **Bot Adapter -arkkitehtuuri** saadaan
istumaan tC$ydellisesti nykyiseen Mesh OS -ekosysteemiin:

### 1. Bot Manager -taustaprosessi (Daemon)

Tarvitsemme jC$rjestelmC$C$n uuden taustaprosessin (esim. `system/bot_manager.j
s`), joka kC$ynnistetC$C$n OS:n bootissa. Sen tehtC$vC$ on:

* Ladata rekisterC6idyt botit VFS:stC$ (esim. kansiosta `/sys_data/bots/`).
* Hallinnoida niiden elinkaarta (Start, Stop, Suspend).
* Kuunnella globaalia `system_intent_bus` -vC$ylC$C$ (esim. se ehdottamasi
`VFS_UPDATED` -tapahtuma) ja **suodattaa** ne botin sC$C$ntC6jen mukaan.
* ReitittC$C$ suodatetut tapahtumat botin kC$yttC$mC$C$n in/out -vC$ylC$C$n
(JS-rutiini, REST, WSS).

### 2. Botin konfiguraatio (Adapterin mC$C$rittely)

Jokainen botti voisi olla yksinkertainen JSON-mC$C$rittely. TC$mC$ abstraktio
sallii rajapintojen vaihtamisen lennosta:

```json
{
  "id": "bot_ocr_worker_1",
  "name": "Receipt OCR Processor",
  "status": "running",
  "workspace": "B:/ocr_inbox/",
  "triggers": [
    {
      "event": "VFS_UPDATED",
      "condition": { "path_contains": "B:/ocr_inbox/", "extension": ".png" }
    }
  ],
  "transport": {
    "type": "wss",
    "endpoint": "wss://rpa.omega-mesh.fi/ocr_worker"
  }
}

```

*Huom: Kun Manager huomaa yllC$ olevan ehdon tC$yttyvC$n, se nappaa
PNG-tiedoston sisC$llC6n ja lC$hettC$C$ sen WSS-vC$ylC$n yli ulkoiselle
Python-botille.*

### 3. Abstraktit In/Out -vC$ylC$t (Transports)

Bot Manager toimisi tulkkina OS:n sisC$isen `Mesh.emit()` -maailman ja
ulkomaailman vC$lillC$.

* **REST (Webhook):** Manager tekee `fetch()` POST-pyynnC6n, kun ehto
tC$yttyy, ja odottaa vastausta (jonka se voi esim. kirjoittaa takaisin
VFS:C$C$n botin tyC6tilaan).
* **WSS (WebSocket):** Reaaliaikainen, kaksisuuntainen putki.
* **Local JS (Sandboxed Routine):** Jos kyseessC$ on kevyt selainpohjainen
botti, Manager ajaa `Mesh.runRoutine()` -komennolla koodinpC$tkC$n antamalla
sille rajoitetun kontekstin.

### 4. B-asema: Bot Workspace (`B:`)

Kuten teimme `S:`-asemalle, pC$ivitC$mme parserin ja `core_utils.js`
-tiedoston ymmC$rtC$mC$C$n `B:`-asemaa, joka ohjaa lennosta polkuun
`/.system_mounts/B_DRIVE/`.

* Bottien logiikka (tai ulkoinen AI) ohjelmoidaan asettamaan tuotoksensa aina
`B:`-asemalle.
* KC$yttC$jC$ voi terminaalista katsoa bottien tyC6tiloja suoraan: `$ tree
B:/ocr_inbox/` tai `$ cat B:/ocr_inbox/result.json`.

### 5. Bot Control Panel (GUI)

Koska olet jo luonut loistavan UI-moottorin (`ui_engine.js`) ja abstraktoinut
ikkunamanagerin, Botien hallintapaneeli on vain yksi JSON AST -tiedosto (esim.
`apps/bot_control.json`).

* Se lukee `bot_manager.js`:n tilaa (esim. lC$hettC$mC$llC$ `BOT_LIST_REQ`
-intentin).
* PiirtC$C$ taulukon aktiivisista boteista (Play / Pause / Stop -nappulat).
* Nappulan painallus lC$hettC$C$ intentin `BOT_SUSPEND { id: 'bot_ocr_worker_1'
 }`, johon Manager reagoi katkaisemalla kyseisen adapterin dataliikenteen.

---

### Miten haluat edetC$?

TC$mC$n rakentaminen kannattaa jakaa selkeisiin paloihin. MikC$ nC$istC$
tuntuu luonnollisimmalta aloituspisteeltC$?

1. **Laajennetaan levykirjaimet (B:)** ensin kuntoon `core_utils.js` ja
`parser_3.js` -tiedostoihin, jotta arkkitehtuuri on valmiina uusia tyC6tiloja
varten.
2. **Koodataan `bot_manager.js` (Daemon)**, joka mC$C$rittelee ensimmC$isen
testibotin rakenteen ja osaa ottaa vastaan suspend/resume -komentoja
terminaalista.
3. **Rakennetaan `apps/bot_control.json` (GUI)** ja kytketC$C$n se simuloituun
taustaprosessiin, jotta nC$et visuaalisen hallintapaneelin vC$littC6mC$sti.