TC$mC$ on arkkitehtuurillisesti aivan loistava ja erittC$in kypsC$ ajatus.
MUD-pelien (erityisesti LPMudien) `sscanf`-toteutukset ja vanhojen
tekstiseikkailujen jC$sennysmoottorit ovat legendaarisia juuri siksi, ettC$ ne
onnistuivat purkamaan kaoottista tekstiC$ puhtaaksi dataksi ilman nykykielten
sC$C$nnC6llisten lausekkeiden (RegEx) vaatimaa kryptistC$ siansaksaa.

MeillC$ on kuitenkin yksi vC$litC6n haaste perinteisen C-tyylisen `sscanf`:n
kanssa: **prosenttimerkki (`%`)**. Koska rakensimme The Mesh -verkkoon
turvallisen hex-enkoodauksen myrkyllisille merkeille muodossa `%(0xNN)`,
perinteisten `%s`, `%d` tai `%[a-z]` -operaattoreiden tuominen kieleen
aiheuttaisi vC$littC6mC$sti parserien yhteentC6rmC$yksen ja uuden
escape-helvetin.

Siksi ehdottamasi yhdistelmC$  **sscanf:n ideologia yhdistettynC$ moderniin
tokenisointiin**  on ehdottomasti oikea tie.

Voimme jC$ttC$C$ RegEx-hirviC6t Node.js-moottorin konepellin alle piiloon ja
tuoda BASIC-tasolle tC$ysin selkokielisen, WebUI-turvallisen mallisovittimen
(Template Matcher).

TC$ssC$ on kaksi konseptia siitC$, miltC$ tC$mC$ voisi nC$yttC$C$
`x-mesh-basic` -kielessC$ tC$ysin ilman escape-merkkejC$:

### Konsepti 1: Semanttinen metsC$stC$jC$ (Semantic Tokenizer)

Joskus emme tiedC$ tarkkaan, missC$ kohtaa sotkuista sivudataa sC$hkC6posti
tai puhelinnumero on. TC$llC6in voisimme vain kC$skeC$ moottoria
"metsC$stC$mC$C$n" tietyt tokenit tekstin seasta ja palauttamaan ne
taulukkona.

Moottoriin rakennettaisiin sisC$C$nrakennettu ymmC$rrys tokeneista kuten
`[EMAIL]`, `[PHONE]`, `[URL]` ja `[IBAN]`.

```basic
REM EtsitC$C$n kaikki sC$hkC6postit ja puhelinnumerot leikepC6ytC$datasta
SCAN PAGE_TEXT$ FOR "[EMAIL]" INTO FOUND_EMAILS
SCAN PAGE_TEXT$ FOR "[PHONE]" INTO FOUND_PHONES

```

### Konsepti 2: Rakenteellinen purkaja (Template Matcher)

Kun data on jC$sennellympC$C$ (esim. luemme taulukkoa tai tiettyC$
tietorakennetta), tekisimme sscanf-tyylisen templaatin, jossa mC$C$rittelemme
halutut avaimet suoraan tokenin sisC$C$n tyyliin `[TYYPPI:avaimen_nimi]`.

Moottori lukee merkkijonon, sovittaa sen templaattiin ja luo automaattisesti
`MAPPING` (JSON) -objektin!

```basic
LET TEMPLATE$ = "Toimitusjohtaja: [STRING:tj_nimi] Puhelin: [PHONE:tj_puh]"
EXTRACT TEMPLATE$ FROM PAGE_TEXT$ INTO LEAD_MAP

REM Nyt meillC$ on suoraan kC$ytC6ssC$ puhdas JSON-objekti:
PRINT "LC6ydettiin TJ: " + LEAD_MAP->tj_nimi

```

### Miksi tC$mC$ on ylivoimainen tapa?

1. **Ei sC$C$nnC6llisiC$ lausekkeita BASIC-tasolla:** VC$ltC$mme
heittomerkkien ja kenoviivojen (`\b`, `\d+`) tC$ydellisen sekoittumisen ja
rikkoutumisen.
2. **Deterministinen:** TiedC$mme aina, ettC$ `[PHONE]` palauttaa
puhelinnumeron, ja jos se ei tC$smC$C$, muuttujaan asettuu kiltisti `NULL`.
3. **Itsedokumentoiva:** Kuka tahansa tiimistC$si voi katsoa koodia `EXTRACT
"Nimi: [STRING:nimi]" ...` ja ymmC$rtC$C$ vC$littC6mC$sti, mitC$ siinC$
tapahtuu.

Kun mietitC$C$n nC$itC$ 18 kerC$C$mC$C$mme yritysten raakatekstitiedostoa ja
niiden louhimista puhtaaksi liididataksi, kumpaan suuntaan haluaisit viedC$
tC$tC$: rakennetaanko moottoriin ensin vapaa semanttinen metsC$stC$jC$ (`SCAN
FOR [EMAIL]`), vai tiukempi sscanf-tyylinen templaattipurkaja (`EXTRACT
TEMPLATE FROM`)?