TC$mC$ on arkkitehtuurillinen napakymppi. SiirtC$mC$llC$ suorituslogiikka
lineaarisesta ja haavoittuvasta koodista levylle sarjallistettuun
tilakoneeseen luot jC$rjestelmC$stC$ aidosti hajautetun ja vikasietoisen.
TC$mC$ mukailee tC$ydellisesti tapahtumapohjaisen (event-sourced)
tilansynkronoinnin periaatteita: staattinen data mC$C$rC$C$ tahdin, eikC$
yksikC$C$n kaatuva keskusprosessi voi vetC$C$ koko orkestraatiota mukanaan.
TC$llainen arkkitehtuuri on erityisen tehokas, kun tyC6lC$iset (execution
nodes) pyC6rivC$t eri koneilla tai LXC-konteissa, jotka jakavat saman
verkkolevyn (esim. ZFS-datasetin).
NC$in tC$mC$ konsepti mallinnetaan kestC$vC$ksi tuotantojC$rjestelmC$ksi:
1. Tilakoneen (Process JSON) datarakenne
Kun uusi RPA-tehtC$vC$ alkaa, jC$rjestelmC$ luo state-machines/ -hakemistoon
uuden JSON-tiedoston. TC$mC$ tiedosto on rutiinin absoluuttinen totuus.
Esimerkki: proc_1789983451_whatsapp.json
{
  "process_id": "proc_1789983451_whatsapp",
  "playbook": "messaging/whatsapp/02_send_file",
  "current_step": 2,
  "status": "pending",
  "lock": {
    "node_id": null,
    "claimed_at": null,
    "expires_at": null
  },
  "context": {
    "target_contact": "Dev Triad",
    "file_path": "/tmp/ai_training_data.jsonl"
  },
  "history": [
    {
      "step": 1,
      "action": "00_init",
      "status": "success",
      "timestamp": 1789983445.5,
      "log": "WhatsApp-pC$C$valikko varmistettu."
    }
  ]
}

2. Atominen Claim-operaatio verkkolevyllC$
VerkkolevyillC$ (NFS, SMB) pelkkC$ tiedoston avaaminen kirjoitustilaan ei ole
luotettavan atominen toimenpide kilpatilanteissa (race conditions).
Luotettavin tapa varata suorituslukko POSIX-yhteensopivalla levyllC$ on
tiedoston uudelleennimeC$minen (mv).
TyC6lC$isen (Node) suoritusluuppi:
 * Skannaus: Node etsii state-machines/ -hakemistosta tiedostoja, jotka
pC$C$ttyvC$t .json (eivC$t .locked).
 * Validointi: Node lukee tiedoston. Jos status on pending (tai
lock.expires_at on menneisyydessC$), node pC$C$ttC$C$ yrittC$C$ napata sen.
 * Atominen lukko: Node suorittaa komennon mv proc_1789983451.json
proc_1789983451.locked.
   * Jos komento onnistuu, node sai yksinoikeuden.
   * Jos kaksi nodea yrittC$C$ tC$tC$ tC$smC$lleen samalla millisekunnilla,
vain toisen kC$yttC6jC$rjestelmC$tason rename() onnistuu. HC$viC$jC$ saa
virheen ja siirtyy etsimC$C$n seuraavaa tiedostoa.
 * Lukon rekisterC6inti: Node pC$ivittC$C$ .locked -tiedoston sisC$lle oman
node_id:nsC$ ja asettaa expires_at -arvon esimerkiksi 60 sekunnin pC$C$hC$n
tulevaisuuteen, ja tallentaa tiedoston.
3. Askeleen (Step) suorittaminen ja tilan pC$ivitys
Kun lukko on turvattu, tyC6lC$inen suorittaa vain yhden yksittC$isen vaiheen
(current_step):
 * Node lataa muistiin kyseisen Playbookin ja suorittaa sieltC$ askeleen 2
asiat (esim. ottaa ruutukaappauksen, kC$yttC$C$ OCR:C$C$, suorittaa
klikkauksen).
 * Node tekee tarvittavat Sanity Checkit (esim. kysyy Gemmalta luvan edetC$).
 * Onnistuminen: Node kasvattaa tilakoneen current_step:n arvoon 3, kirjaa
suorituksen history-taulukkoon, tyhjentC$C$ lock-objektin, tallentaa tiedoston
ja nimeC$C$ sen takaisin pC$C$tteelle .json.
 * EpC$onnistuminen: Node kirjaa virheen, asettaa statukseksi failed (jolloin
inhimillinen valvoja tai 00_init voi puuttua peliin) ja palauttaa tiedoston
.json -muotoon.
4. OOM-Killer ja automaattinen toipuminen (Self-Healing Fleet)
TC$mC$n mallin suurin etu on sen tC$ydellinen immuniteetti yksittC$isten
prosessien kaatumisille.
Jos tyC6lC$isenC$ toimiva Chrome villiintyy selaimen muistivuodon takia ja
Linuxin OOM-killer tappaa koko Noden kesken suorituksen:
 * Tiedosto jC$C$ verkkolevylle muotoon proc_1789983451.locked.
 * Tiedoston sisC$llC$ lukee "expires_at": 1789983511.0.
 * Muut elossa olevat Nodet skannaavat sC$C$nnC6llisesti myC6s .locked
-pC$C$tteisiC$ tiedostoja. Kun kello ylittC$C$ 1789983511.0, toinen vapaana
oleva Node huomaa, ettC$ alkuperC$inen suorittaja on kuollut.
 * Uusi Node "varastaa" lukon pC$ivittC$mC$llC$ sen omiin nimiinsC$ ja
yrittC$C$ suorittaa kyseisen current_step:n uudelleen puhtaalta pC6ydC$ltC$.
NC$in useamman Noden laivasto takaa sen, ettC$ prosessit etenevC$t
vC$C$jC$C$mC$ttC$ tilakoneen alusta loppuun, vaikka yksittC$iset
virtuaalikoneet, kontit tai verkkoyhteydet katkeilisivat suorituksen aikana.
Samalla sC$ilytC$t tC$ydellisen, sekunnilleen tarkan auditoitavan lokin
siitC$, mitC$ rutiinissa on missC$kin vaiheessa tapahtunut.