TC$mC$ on poikkeuksellisen elegantti ja teollisuusstandardien mukainen
ratkaisu (kutsutaan nimellC$ *Asynchronous Request-Reply Pattern* tai *Webhook
Broker*). Se ratkaisee kertaheitolla single-threaded- tai loogisesti tiukkaan
aikasikliin sidottujen ympC$ristC6jen (kuten `heart_beat`) suurimman ongelman:
verkkolatenssin aiheuttaman blokkaantumisen.

Kun erotat suorituksen ja odottamisen tC$ysin toisistaan, `idiot.c`:n ei
tarvitse ikinC$ jC$C$dC$ "jumiin" odottamaan, milloin hidas tekoC$lymalli tai
lekseri vastaa HTTP-kutsuun. Se vain ampuu pyynnC6n jonoon ja jatkaa
elC$mC$C$nsC$.

### Arkkitehtuurikaavio: Miten putki toimii

1. **`idiot.c` (LXC-kontissa)** -> lC$hettC$C$ nopean synkronisen POST-kutsun
paikalliseen globaaliin jonoon.
2. **Globaali TehtC$vC$jono (Async Queue)** -> kuittaa heti vastaanoton
`{"status": "queued", "task_id": "xyz"}` -> `idiot.c` vapauttaa muistin ja
jatkaa seuraavaan minuuttisykliinsC$.
3. **TyC6lC$inen (Queue Worker)** -> poimii tehtC$vC$n taustalla, suorittaa
varsinaisen hitaan REST-kutsun kohteeseen (esim. `/lex`).
4. **Vastaus saadaan** -> TyC6lC$inen ottaa vastauksen ja tekee POST-kutsun
mC$C$ritettyyn callback-osoitteeseen (esim. `hlpc-api`:n pC$C$tepisteeseen
`/object/call/receive_lexed_message`).
5. **`hlpc-api`** -> herC$ttC$C$ kontin `receive()`-funktion, ja `idiot.c` saa
datan ikC$C$n kuin se olisi vain uusi ulkopuolelta tullut aistiC$rsyke.

---

### TehtC$vC$jonon tietorakenne (Payload Schema)

Jotta jC$rjestelmC$ pysyy mainitsemallasi tavalla "maailman yksinkertaisimpana"
, tehtC$vC$jonoon tallennettavan JSON-olion rakenne kannattaa speksata suoraan
tC$llaiseksi:

```json
{
  "task_id": "task_87074791",
  "target_url": "http://hauki-crm:8077/lex",
  "target_method": "POST",
  "target_payload": {
    "text": "list my tasks"
  },
  "callback_url": "http://hauki-crm:8077/object/call",
  "callback_payload_template": {
    "id": "idiot.c#api-1",
    "function": "receive_lexed_message"
  },
  "retry_policy": {
    "max_tries": 5,
    "wait_interval": 10,
    "current_try": 0
  }
}

```

### Miten TyC6lC$inen (Worker) kC$sittelee callbackin?

Kun hidas haku `target_url`-osoitteesta valmistuu ja palauttaa vaikkapa datan
`{"tokens": ["LIST", "TASKS"]}`, Worker yhdistC$C$ tC$mC$n tuloksen osaksi
`callback_payload_template`-rakennetta (esim. avaimella `"args"` tai `"data"`)
ja ampuu lopullisen paketin eteenpC$in callback-osoitteeseen:

```json
{
  "id": "idiot.c#api-1",
  "function": "receive_lexed_message",
  "args": {
    "tokens": ["LIST", "TASKS"]
  }
}

```

### Miksi tC$mC$ on poikkeuksellisen kova ratkaisu?

1. **Vikasietoisuus (Fault Tolerance):** Jos `/lex` API on alhaalla tai Ollama
lataa mallia muistiin, se ei kaada tai hidasta tekoC$lyagenttia. Jonon
tyC6lC$inen osaa `retry_policy`n mukaisesti odottaa 10 sekuntia ja yrittC$C$
uudelleen.
2. **Universaali silta (Any-to-Any Relay):** Kuten sanoit, tC$mC$ ei ole vain
botteja varten. TC$mC$ API-async-queue voi vC$littC$C$ viestejC$ minkC$
tahansa meshin palasen vC$lillC$ (CRM <-> Bash-skriptit <-> IRC <-> HLPC).
3. **Puhdas hiekkalaatikko:** Agentin (`idiot.c`) ei tarvitse tietC$C$
verkko-osoitteista, retry-luupeista tai timeout-rajoista mitC$C$n. Sen koodi
pysyy tC$ysin puhtaana deterministisenC$ logiikkana.

TC$mC$ on erittC$in fiksu ja toteutuskelpoinen suunnitelma. Haluatko, ettC$
pystytC$mme tC$mC$n globaalin asynkronisen jonon seuraavaksi? Voimme tehdC$
siitC$ erittC$in kevyen, RAM-pohjaisen FastAPIn tai litteC$n Python-daemonin
(kuten HMQ), joka kuuntelee pyyntC6jC$ ja hoitaa tuon asynkronisen odotuksen
ja callback-rallin puolestasi.