TC$mC$ on ehdottomasti oikea marssijC$rjestys! KeskittymC$llC$ ensin
atomisten, luotettavien `mesh-basic` -tyC6lC$isten rakentamiseen varmistamme,
ettC$ kun LPC-kerroksen "pomo" myC6hemmin astuu remmiin, sillC$ on alaisinaan
joukko huippuunsa hiottuja tyC6kaluja, joihin se voi sokeasti luottaa.

Otetaan kC$sittelyyn tuo antamasi esimerkkitehtC$vC$: `20260629-1026_INFRA-OPS_
set-up-haukimail-lxc`.

Kuten linjasit, emme anna nykyisten rajoitteiden sitoa kC$siC$mme. Jos
purkaisimme tC$mC$n pelkillC$ raaoilla `REST` ja `EXEC` (bash) -komennoilla,
koodista tulisi nopeasti lukukelvotonta spagettia. Luodaan sen sijaan
`mesh-basic` -kieleen uusia, tC$smC$llisiC$ komentonimiavaruuksia (esim.
`TASK` ja `LXC`), jotka tekevC$t koodista niin eleganttia, ettC$ se lukee kuin
englanninkielinen ohjekirja.

TC$ssC$ on ehdotus siitC$, miltC$ tC$ydellisesti abstrahoitu `mesh-basic`
-tyC6lC$isskripti (`worker_infra_lxc.bas`) voisi nC$yttC$C$:

### Elegantti MeshBASIC-tyC6lC$inen: LXC Provisionointi

Oletetaan, ettC$ kun LPC-pomo luo tC$mC$n instanssin Worker API:n kautta, se
syC6ttC$C$ sille muuttujan `TASK_ID$` (esim. arvoksi `"20260629-1026_INFRA-OPS_
set-up-haukimail-lxc"`).

```basic
10 SYS LOG "Aloitetaan infrapalvelun tyC6lC$inen tehtC$vC$lle: " + TASK_ID$
20 ON ERROR GOTO 900

' --- 1. TehtC$vC$n nouto ja validointi ---
30 TASK CLAIM TASK_ID$ INTO STATUS$
40 IF STATUS$ != "SUCCESS" THEN GOTO 900
50 TASK READ TASK_ID$ "prompt" INTO INSTRUCTION$
60 SYS LOG "TehtC$vC$nanto: " + INSTRUCTION$

' --- 2. Varsinainen suoritus (Agentin C-tason stepit) ---
70 SYS LOG "Luodaan LXC-kontti 'hauki-mail'..."
80 LXC CREATE "ubuntu:22.04" AS "hauki-mail"
90 LXC START "hauki-mail"
100 YIELD "Odotetaan LXC-verkkorajapinnan nousemista" 

110 SYS LOG "Kopioidaan SMTP-kehitysympC$ristC6n template..."
120 LXC PUSH "/mnt/mesh_root/dev-workspaces/opt/smtp-mesh" TO
"hauki-mail:/opt/smtp-mesh"

' --- 3. Siivous ja raportointi ---
130 SYS LOG "Merkataan tehtC$vC$ suoritetuksi..."
140 TASK COMPLETE TASK_ID$
150 SYS LOG "TyC6lC$inen lopettaa onnistuneesti."
160 HALT

' --- Vikatilan kC$sittely ---
900 SYS LOG "Kriittinen virhe suorituksessa!"
910 TASK FAIL TASK_ID$ "TyC6lC$inen kaatui kesken suorituksen."
920 HALT

```

### Uudet syntaksiehdotukset moottoriin

Jotta yllC$ oleva koodi on mahdollista, meidC$n tulisi esittC$C$ `mesh-basic`
-moottorin kehittC$jille kaksi uutta natiivia moduulia:

* **`TASK` -nimiavaruus:** Tekee Mailbox API:n (Portti 8885) kanssa juttelusta
natiivia.
* `TASK CLAIM <id> INTO <var>`
* `TASK READ <id> <field> INTO <var>` (esim. hakee tiedot suoraan
`prompt.json` tai `META_PROMPT.TXT` -tiedostoista).
* `TASK COMPLETE <id>`
* `TASK FAIL <id> <reason>`


* **`LXC` -nimiavaruus:** Abstrahoi taustalla toimivat `lxc`-komentorivikutsut
turvallisiksi ja selkeiksi BASIC-operaatioiksi, mikC$ eliminoi riskin siitC$,
ettC$ kielimalli hallusinoi vaarallisia bash-putkituksia.
* `LXC CREATE <image> AS <name>`
* `LXC START/STOP <name>`
* `LXC PUSH <host_path> TO <container_name>:<path>`



### TyC6lC$isen ja Pomon dynamiikka

Kun nC$mC$ abstraktiot ovat olemassa, LPC-pomon logiikka pysyy C$C$rimmC$isen
ohuena. Pomon tarvitsee vain tarkkailla Mailbox API:n `/tasks?status=INCOMING`
-listausta. Kun se nC$kee "INFRA-OPS" -alkuisen tehtC$vC$n, se lC$hettC$C$
Worker API:lle yhden pyynnC6n:

```bash
curl -X POST http://localhost:9978/instances/create \
  -H 'Content-Type: application/json' \
  -d '{
    "script_name": "worker_infra_lxc.bas", 
    "instance_id": "worker_123", 
    "variables": {"TASK_ID$": "20260629-1026_INFRA-OPS_set-up-haukimail-lxc"}
  }'

```

MiltC$ nC$mC$ uudet syntaksiehdotukset (`TASK` ja `LXC`) vaikuttavat
silmC$C$si, ja haluaisitko seuraavaksi suunnitella, miten tekoC$lyagentti itse
lennosta generoi nuo rivit 70-120 lukemansa `prompt.json` -tiedoston pohjalta?