TC$mC$ on C$C$rimmC$isen viisas pC$C$tC6s. Pilvi-infrastruktuurin (GCP) voi
aina kytkeC$ pC$C$lle myC6hemmin. Kun rakennamme ensin paikallisen
ydinmoottorin (VM) ja sen muistinhallinnan absoluuttisen vikasietoiseksi,
ulkoisista palveluista tulee vain "tyhmiC$ putkia", joita pitkin
Mesh-verkkomme siirtC$C$ dataa.

NC$mC$ kolme ehdottamaasi konseptia (C$lykC$s automaattitallennus,
signaalikeskeytykset ja kaatumisvedokset) ovat tC$smC$lleen niitC$
ominaisuuksia, joita korkean luotettavuuden jC$rjestelmissC$ (kuten Erlang/OTP
-telekom-palvelimissa) kC$ytetC$C$n. Niiden avulla ohjelmisto voi "kaatua
turvallisesti" ja palata henkiin sekunneissa.

Puretaan nC$mC$ ideat arkkitehtuuritasolla The Dark Meshin ytimeen:

### 1. ClykC$s tilannekuva (Smart State Dump)

MeillC$ on jo olemassa alkeellinen `CHECKPOINT`-komento, mutta se vaatii
koodarilta tC$ydellisen tiedostopolun. Ehdottamasi malli siirtC$C$ tC$mC$n
vastuun VM:lle.

Voimme luoda uuden komennon `DUMP STATE "tunniste"`. Kun tC$mC$ ajetaan,
Node.js-moottorimme tekee taustalla seuraavaa:

1. Hakee isC$ntC$koneen nimen (`os.hostname()`).
2. Hakee ajetun tiedoston nimen ja sen kC$ynnistysargumentit (`process.argv`
-taulukosta).


3. Laskee nC$istC$ lyhyen tiivisteen (esim. SHA-1 hashin tai selkeC$kielisen
siivotun merkkijonon).
4. Luo automaattisesti hakemiston: `/mnt/mesh_root/state/mesh-basic/hauki-obs_d
emo_api_bas_a1b2c3/`
5. Tallentaa koko VM:n tilan sinne nimellC$ `tunniste.bas_dump`.

NC$in The Mesh hoitaa versiohallinnan ja klusterin eri koneiden dumpit
automaattisesti omiin lokeroihinsa tC$ysin ilman, ettC$ BASIC-koodari
kirjoittaa riviC$kC$C$n polunhallintaa!

### 2. Laitteistotason signaalit (ON SIGNAL)

TC$mC$ on loistava tapa hallita VM:C$C$ ulkopuolelta. Node.js tukee natiivisti
POSIX-signaaleja. Voimme rakentaa laajennuksen, joka rekisterC6i
kC$yttC6jC$rjestelmC$tason kuuntelijan (`process.on('SIGUSR1', ...)`).

Syntaksi voisi olla nC$in kaunis:
`ON SIGNAL "SIGUSR1" DUMP "manuaalinen_vedos"`

Kun Antti (tai ulkoinen Bash-skripti) ajaa terminaalissa komennon `kill
-SIGUSR1 <pid>`, The Mesh pysC$yttC$C$ suorituksen vC$littC6mC$sti seuraavan
rivin kohdalla, kirjoittaa yllC$ mainitun C$lykkC$C$n dumpin levylle ja jatkaa
sitten ohjelman suoritusta aivan kuin mitC$C$n ei olisi tapahtunut.

### 3. Kuolinkamppailun tallennus (ON CRASH DUMP)

MeillC$ on `core.js` -tiedostossa jo olemassa `handleError`-funktio, joka
nappaa ajonaikaiset virheet. TC$llC$ hetkellC$ se osaa joko reitittC$C$
virheen `ON ERROR GOTO` -ansaan tai kaataa ohjelman tulostaen
virheilmoituksen.

Laajennamme tC$tC$ funktiota uudella kyvyllC$:
`ON CRASH DUMP INTO "/mnt/mesh_root/tmp/CRM-CRASH/"`

Jos tC$mC$ asetus on aktivoitu ja ohjelma kohtaa virheen jota ei ole
kC$sitelty `ON ERROR` -rutiinilla, VM:n viimeinen elintoiminto ennen
`process.exit(1)` -kutsua on kirjoittaa koko muistinsa, aktiivinen koodinsa ja
pino-tietonsa (call stack) JSON-muotoisena dumpina tuohon kansioon. TC$mC$n
avulla voimme kC$C$riC$ kaatuneen palvelimen muistivedoksen myC6hemmin
debuggaus-tyC6kaluun ja nC$hdC$ tarkalleen, missC$ tilassa muuttujat olivat
sekunnin murto-osa ennen tuhoa!

---

### Miten tC$mC$ nC$yttC$ytyisi koodarille?

Tulevaisuudessa Antin ja Jannen CRM-mikropalvelun alku nC$yttC$isi
yksinkertaisesti tC$ltC$:

```basic
10 REM === CRM BACKEND INIT ===
20 ON CRASH DUMP INTO "/mnt/mesh_root/tmp/CRM-CRASH/"
30 ON SIGNAL "SIGUSR1" DUMP "snapshot_hot"
40 DUMP STATE "boot_valmis"
50 REM ... normaali ohjelma jatkuu ...

```

NC$mC$ kolme konseptia ovat riittC$vC$n kompakteja toteutettavaksi kerralla,
sillC$ ne kaikki nojaavat samaan JSON-vedoksen kirjoittamiseen, jota
`checkpoint.js` jo hyC6dyntC$C$.

Haluatko, ettC$ laadimme seuraavaksi `GEM-EDITBOT` -kirurgisen
leikkaussuunnitelman, jolla pC$ivitC$mme `core.js` -ytimen tukemaan nC$itC$
globaaleja signaaleja ja kaatumisvedoksia, ja samalla luomme `ext/dump.js`
-laajennuksen tC$lle uudelle syntaksille?