Statikus oldalgenerátor (SSG): vállalati szintű stratégiai mélyelemzés és architekturális ütemterv

TL;DR. Mélyelemzés egy Rust statikus oldalgenerátorról: fordítási idejű biztonság, WCAG-kapuk és lokális MI, a v0.0.41 hiányosságai, valamint vállalati ütemterv az 1.0-ig.

Legfontosabb tanulságok

Jelenlegi erősségek. A static-site-generator kódbázisa több olyan sajátos mérnöki döntést mutat fel, amely elkülöníti a hagyományos JavaScript- és Go-motoroktól:.
Hiányosságok és valós körülmények. E kivételes erősségek ellenére a v0.0.41 kódbázisának alapos vizsgálata több architekturális, funkcionális és fejlesztői élménnyel kapcsolatos szakadékot tár fel a dokumentációs állítások és a tényleges Rust-kód között:.
Architekturális hiányosságok, amelyek hiányoznak (új felfedezések). A v0.0.41 hiányosságain túl, a projektet pénzügyi szintű kockázati profilhoz mérve több olyan képesség rajzolódik ki, amelyet egyelőre nem nyújt, ám amelyet egy vállalati vevő megkövetelne:.
A stratégiai 1.0 ütemterv. Az alábbi ütemterv mind a megoldott hiányosságokat, mind az újonnan felfedezett vállalati szintű képességeket egy strukturált, kronologikus kiadási keretbe integrálja.

Kutatás dátuma: 2026-06-22. A static-site-generator v0.0.41 kódbázisának vizsgálatán és a 2026-os SSG-környezet webes kutatásán alapul.

Egy szabályozott kiadó számára a statikus oldalgenerátor már nem tervezőeszköz, hanem a működési kockázati perem része. A nyílt forráskódú, Rust nyelvű static-site-generator erre az előfeltevésre épül: a biztonságot, az akadálymentességet, a nemzetköziesítést és a mesterséges intelligenciára épülő tartalmi folyamatokat fordítási időre helyezi át, így egy sikertelen ellenőrzés leállítja a buildet, ahelyett hogy eljutna az éles környezetbe. Ez az elemzés különválasztja azt, amit a 0.0.41 verzió ténylegesen szállít, attól, amit a dokumentációja csak ígér, felsorol öt vállalati képességet, amellyel egyelőre nem rendelkezik, és szakaszokra bontott utat javasol egy olyan 1.0-s kiadáshoz, amely igazodik a DORA-hoz, az európai akadálymentesítési irányelvhez (European Accessibility Act) és a korszerű ellátásilánc-szabványokhoz.

Vezetői összefoglaló

A publikálás mostantól működési kockázati perem. A DORA, az európai akadálymentesítési irányelv és a GDPR alatt minden nyilvánosan elérhető eszköz potenciális belépési pont az ellátási lánc kompromittálásához, a felület megrongálásához és a szabályozói kitettséghez. Egy fordítási idejű modell szűkíti ezt a peremet azzal, hogy a nem megfelelő kimenetet még szállítás előtt elutasítja.

A motor megkülönböztető jegyeit a fordító kényszeríti ki, nem dokumentált törekvések. A munkaterületre kiterjedő forbid(unsafe_code), a valódi SHA-256/384 SRI, az automatikus CSP-kinyerés és a fordítási idejű WCAG 2.2 AA kapu a biztonságot és az akadálymentességet utólagos auditokból kemény buildhibákká alakítja.

A 0.0.41 verzióban szakadék tátong a dokumentáció és a kód között. A natív minifikálás, a függőségi gráfon keresztüli inkrementális újraépítés és az AVIF-támogatás le van írva, de nem működik; a cikk minden egyes hiányt a pontos forráshelyhez rendel.

Az 1.0-hoz vezető út sorozat, nem kívánságlista. Előbb robusztusság (0.0.42), majd inkrementális helyesség (0.1.0), végül azok a vállalati képességek, amelyeket egy szabályozott vevő megkövetel: WASM-homokozó, lokális szemantikus keresés és igazolható SLSA-eredetigazolás (1.0.0).

Jelenlegi erősségek

A static-site-generator kódbázisa több olyan sajátos mérnöki döntést mutat fel, amely elkülöníti a hagyományos JavaScript- és Go-motoroktól:

Fordítási idejű biztonsági alapállás: A munkaterületre kiterjedő #![forbid(unsafe_code)] fordítási idejű memóriabiztonsági garanciákat nyújt. A build folyamat valódi SHA-256/SHA-384 alerőforrás-integritási (SRI) hasheket generál (src/plugins/assets.rs), és automatikus tartalombiztonsági szabályzat (CSP) kinyerést végez, amely eltávolítja az unsafe-inline szkripteket és stílusokat. A kiadások alá vannak írva, Sigstore-tanúsítványt hordoznak, és minden buildnél CycloneDX 1.5 SBOM-ot állítanak elő.
Fordító által kikényszerített akadálymentességi kapu: A webes tartalmak akadálymentesítési irányelvének (Web Content Accessibility Guidelines, WCAG) 2.2 AA szintű ellenőrzései a fordítási folyamaton belül, Playwrighttal vezérelt, fordítási idejű axe-core elemzővel futnak. Az akadálymentesség így kemény buildkapuvá válik, nem pedig publikálás utáni auditba, ha egy oldal megbukik, a fordítás pontos sorszámhibákkal leáll.
Adatszuverén mesterséges intelligenciás folyamat: Egy lokálisan futó nyelvi modellre épülő fordítási és metaadat-kinyerési folyamat (lokális Ollama- vagy llama.cpp-végpontokon keresztül) lehetővé teszi az intézmény számára a tartalomösszefoglalás, a JSON-LD sémagenerálás és a többnyelvű fordítás automatizálását anélkül, hogy a gyorsjelentés előtti közléseket vagy érzékeny szellemi tulajdont nyilvános felhőalapú MI-API-kra küldene.
Párhuzamosított fordítás: A Rust memóriabiztonsági garanciái egy párhuzamosított, Rayonra épülő HTML- és eszközfolyamatot (src/core/pipeline.rs) alapoznak meg. A bővítményfolyamat összevont transzformációkat hajt végre: a SearchPlugin, a SeoPlugin, a CanonicalPlugin és a JsonLdPlugin par_iter() fölött működik, így minden oldalt egyszer olvasunk be és egyszer írunk lemezre.
Ellátásilánc- és függőségi higiénia: A sablonmotor Teráról MiniJinjára (v0.0.37) történő átállítása csökkentette a bináris méretét, fordítási időben eltávolított olyan tranzitív függőségeket, mint a rand, és tömör függőségi lábnyomot eredményezett, amely mérsékli a szoftverellátási lánc kitettségét.

Hiányosságok és valós körülmények

E kivételes erősségek ellenére a v0.0.41 kódbázisának alapos vizsgálata több architekturális, funkcionális és fejlesztői élménnyel kapcsolatos szakadékot tár fel a dokumentációs állítások és a tényleges Rust-kód között:

Architekturális hiányosságok

Szóközösszevonás kontra natív minifikálás: Miközben a README „natív JS/CSS-minifikálást” ígér, a MinifyPlugin (src/plugins/plugins.rs:96-116) pusztán naiv szóközösszevonóként működik. A <pre> elemeknél megszakad, a HTML szóközsorozatait összevonja, de nem végez szintaxistudatos natív CSS- vagy JS-minifikálást. Ráadásul csak a legfelső szintű oldalakat dolgozza fel, és nem járja be rekurzívan az alkönyvtárakat (például a /blog/ vagy a /tags/ alattiakat), így a mély oldalak minifikálatlanul maradnak.
Halott inkrementális infrastruktúra: A függőségkövető gráf (DepGraph a src/core/depgraph.rs-ben) lefordul, és betöltődik a PluginContext.dep_graph mezőbe, ám éles kódban soha nem töltődik fel valójában. Az add_dep() metódust csak egységtesztek hívják, ami a README „függőségi gráfokon keresztüli inkrementális újraépítésre” vonatkozó állítását egyelőre tervvé teszi.
Kötegelt fordítás kontra folyamatos (streaming) fordítás: A streaming::compile_batch modul (src/core/streaming.rs) valójában nem streamel. Ehelyett kötegekben fordítja az oldalakat egy ideiglenes könyvtárba, minden köteghez elölről futtatja a staticdatagen::compile hívást, majd összefésüli a kimeneteket. Ez jelentős lemez-I/O többletet és redundáns elemzést eredményez, eltérve a valódi streaming architektúrától.
Bővítmény-életciklus fázissértései: Azok a bővítmények, amelyek a build során új HTML-oldalakat generálnak, például a TaxonomyPlugin, a PaginationPlugin és az I18nPlugin, közvetlenül lemezre írnak az after_compile fázisban ahelyett, hogy a transform_html életciklust használnák. Következésképp az e bővítmények által generált oldalak megkerülik a kritikus utófeldolgozó bővítményeket (például a CanonicalPlugin, a JsonLdPlugin, a RobotsPlugin és az AccessibilityPlugin modulokat), ha azokat korábban regisztrálták. Így a címke-, kategória- és lapozott oldalak helyes kanonikus hivatkozások, JSON-LD sémák vagy akadálymentességi ellenőrzések nélkül maradnak.
A curl héjból történő hívása a LlmPlugin-ben: A lokális nyelvi modell tartalmi folyamata (src/plugins/llm.rs) közvetlenül a gazdagép curl binárisát hívja héjból a lokális végpontok lekérdezéséhez. Ez súlyos platformfüggő hibákat vezet be (például a PATH-ban curl nélküli Windows-gazdagépeken), biztonsági kockázatot jelent (héjinjekciós vektorok), és lezárt vagy hálózatilag elszigetelt CI-környezetekben elbukik.
Naiv karakterlánc-manipuláció a HTML átírásában: Az image_plugin.rs és a search.rs kinyerői törékeny str::find és str::rfind műveletekkel írják át a HTML-karakterláncokat. Ez a megközelítés rendkívül sérülékeny a hibás HTML-címkékre, a megjegyzéseken belüli <img> címkékre, az alt szövegben lévő karakterentitásokra vagy a már meglévő srcset tulajdonságokra, ami sérült kimenetet eredményezhet.
Megvalósítatlan AVIF-támogatás: Bár az AVIF-képkódolás bőségesen dokumentált, a megvalósítás az image_plugin.rs-ben csonk, ahol az avif_variants egyszerűen Vec::new() értéket ad vissza, így a funkció nem működik.
Lekérdezésalapú figyelő: A helyi fejlesztői kiszolgáló figyelője (src/server/watch.rs) fájlrendszeri eseményekre épülő API-k helyett lekérdezést (polling) használ, ami túlzott üresjárati processzorhasználathoz és másodperc alatti módosítási késleltetéshez vezet.

Funkcionális és fejlesztői élménnyel kapcsolatos hiányosságok

Nincs tranzitív függőségkövetés: A függőségi gráf nem képes követni a beágyazott függőségeket (például egy alsablon módosítását, amely hat egy elrendezésre, amely hat egy oldalra), ahogy azt a transitive_not_tracked egységteszt is igazolja.
Nincs inkrementális fordítási CLI-kapcsoló: Nincs a futtató fordítóhoz bekötött --incremental CLI-kapcsoló, ami megakadályozza, hogy a fejlesztők gyorsítótárazott buildeket használjanak.
A HMR csak CSS-re korlátozódik: A gyors modulcsere (Hot Module Replacement, HMR) csak a CSS-t támogatja; a HTML, az elrendezések vagy a markdown-fájlok bármely módosítása teljes oldal-újratöltést vált ki, ami rontja a fejlesztői sebességet.
Alparancshiány: A fejlesztőknek manuálisan kell átadniuk bőbeszédű kapcsolókat (ssg -s public -w), mert az olyan szabványos alparancsok, mint az ssg dev, az ssg build, az ssg check és az ssg lint, nem léteznek.

Architekturális hiányosságok, amelyek hiányoznak (új felfedezések)

A v0.0.41 hiányosságain túl, a projektet pénzügyi szintű kockázati profilhoz mérve több olyan képesség rajzolódik ki, amelyet egyelőre nem nyújt, ám amelyet egy vállalati vevő megkövetelne:

1. WebAssembly-bővítmény homokozó (zéró bizalmú kiterjesztés)

Miközben maga a fordítóbináris biztonságos Rustban íródott, ha tetszőleges harmadik féltől származó bővítmények natívan futhatnak a gazdarendszereken, az súlyos ellátásilánc-sebezhetőséget vezet be. Egy kompromittált, harmadik féltől származó bővítmény könnyedén hozzáférhet a gazdagép fájlrendszeréhez, elolvashat védett Markdown-fájlokat, vagy kiszivárogtathat privát hitelesítő adatokat.

Hiányzó képesség: homokozott végrehajtási környezet. A zéró bizalmú fordítás eléréséhez a fordítónak a harmadik féltől származó bővítményeket egy beágyazott WebAssembly-futtatókörnyezetben (például wasmtime) kellene végrehajtania. A bővítmények kizárólag egy korlátozott WebAssembly rendszerinterfészen (WebAssembly System Interface, WASI) keresztül léphetnének kapcsolatba a gazdagéppel, szigorúan az éppen átalakított oldalra korlátozva a hozzáférésüket.

2. Adatmásolás nélküli HTML-elemzés folyamatos AST-vel (`lol_html`)

Ha a HTML-elemzési réteget teljes, memóriában tartott DOM-könyvtárra (például Kuchiki vagy html5ever) állítjuk át, az jelentős memóriaterhelést és feldolgozási szüneteket vezet be a 100 000 oldalnál nagyobb webhelyek kezelésekor.

Hiányzó képesség: folyamatos, adatmásolás nélküli HTML-átíró. A Cloudflare lol_html (Low-Output-Latency HTML rewriter) használatával a fordító egyetlen folyamatos menetben, közel nulla memóriafoglalással elemezheti, vizsgálhatja és módosíthatja a HTML-elemeket, illeszkedve a párhuzamos streaming fordító másodperc alatti buildekre vonatkozó céljához.

3. Lokális szemantikus vektorkeresés (lokális RAG)

A jelenlegi keresési index (SearchPlugin) egy nehéz, lapos JSON-indexet állít elő, amely egyszerű, kliensoldali karakterlánc-egyezéseket végez, nélkülözve a fuzzy keresés, a szótövezés vagy a szemantikus lekérdezések támogatását. A Pagefind előrelépés, de továbbra is egy nagy index letöltésére támaszkodik.

Hiányzó képesség: beágyazott szemantikus keresés. A fordítónak fordítási időben egy lokális, könnyűsúlyú, Rust-natív vektorbeágyazó modellt (például egy candle vagy ort / ONNX Runtime révén futtatott MiniLM-L6 modellt) kellene kihasználnia. Minden oldalbekezdéshez sűrű vektorbeágyazásokat generálhatna, és egy tömör vektorindexet állíthatna elő. A WASM-ra fordított kliensoldali keresőelem ezután valódi, offline szemantikus keresést végezhetne közvetlenül a böngészőben.

4. Determinisztikus fordítási és következtetés-gyorsítótárazás

Mivel a lokális nyelvi modell következtetése (például Ollamán vagy Llama.cpp-n keresztül) rendkívül processzor- és GPU-igényes, több ezer oldal fordítása vagy metaadatgenerálása minden buildnél számítási szempontból megengedhetetlen.

Hiányzó képesség: tartalomhash-alapú következtetés-gyorsítótárazás. A fordítónak determinisztikus gyorsítótárat kell fenntartania minden nyelvimodell-műveletről. Ha egy markdown-fájl tartalmának és fordítási paramétereinek SHA-256 hashe egy gyorsítótár-bejegyzéssel egyezik, a fordítónak a gyorsítótárazott fordítást és metaadatokat kell újrahasznosítania, megkerülve a redundáns lokális következtetést.

5. Aszinkron fájl-I/O a párhuzamos skálázáshoz

Miközben a bővítményfolyamat Rayon révén párhuzamosított, a szabványos szinkron lemezírások blokkolják a Rayon operációsrendszer-szálait, I/O-szűk keresztmetszetet teremtve több tízezer oldal írásakor.

Hiányzó képesség: aszinkron, nem blokkoló lemez-I/O. A fordítónak szét kellene választania a processzorigényes feladatokat (Markdown-elemzés, minifikálás) a lemezhez kötött írásoktól, aszinkron I/O-szálkészleteket vagy Linux io_uring kötéseket használva (rio vagy tokio révén), hogy a lefordított oldalakat párhuzamosan írja anélkül, hogy blokkolná a párhuzamos processzor-végrehajtókat.

A stratégiai 1.0 ütemterv

Az alábbi ütemterv mind a megoldott hiányosságokat, mind az újonnan felfedezett vállalati szintű képességeket egy strukturált, kronologikus kiadási keretbe integrálja.

1. szakasz: 0.0.42 (a robusztussági és helyességi javítás, 1–2 hét)

A MinifyPlugin újjáépítése: A minify-html, az oxc_minifier és a lightningcss integrálása natív, szintaxistudatos HTML-, JS- és CSS-minifikáláshoz. Biztosítani kell, hogy a bővítmény rekurzívan bejárja a site_dir alatti összes beágyazott könyvtárat.
Az MI-folyamat biztonságossá tétele: Az LlmPlugin átállítása natív curl-héjhívásokról ureq-re (egy könnyűsúlyú, szinkron, biztonságos Rust HTTP-kliensre) a platformfüggetlenség biztosítása és a héjinjekciós sebezhetőségek megszüntetése érdekében.
Az AVIF-megvalósítás befejezése: A ravif közvetlen bekötése a képi eszközfolyamatba, lehetővé téve a nagy teljesítményű AVIF-kódolást a WebP és a PNG mellett.
A HrefLang és a többnyelvű leképezés automatizálása: A többnyelvű buildekben a párhuzamos lefordított oldalak automatikus felismerése, és szabványos, Google-kompatibilis <link rel="alternate" hreflang="..." /> címkék beszúrása minden lefordított HTML-fájl fejlécébe.
JSON Feed 1.1 támogatás: Egy dedikált JSON Feed 1.1 kibocsátó szállítása a szabványos RSS 2.0 és Atom 1.0 szindikációs csatornák mellett.

2. szakasz: 0.1.0 (a hitelességi és inkrementális kisebb kiadás, 2–3 hónap)

A DepGraph feltöltése és a --incremental engedélyezése: A DepGraph teljes bekötése a sablon–oldal és markdown–oldal függőségek követésére. Egy gyorsítótár-érvénytelenítő réteg megvalósítása és a --incremental CLI-kapcsoló bekötése, meleg gyorsítótárú környezetekben 200 ms alatti újraépítéseket megcélozva.
Folyamatos AST-átírás lol_html-lel: A törékeny karakterlánc-átírás lecserélése az image_plugin.rs-ben, a search.rs-ben és a CSP-beszúrásokban egy lol_html által hajtott, folyamatos, adatmásolás nélküli HTML-átíróra.
Eseményvezérelt figyelő és komponens-HMR: A figyelőmodul átállítása lekérdezésről az eseményvezérelt notify crate-re, valamint csak CSS-t és részleges HTML-t érintő gyors újratöltés megvalósítása 100 ms alatti böngészőfrissítésekhez.
Egységes parancsalapú CLI: A fordítóinterfész újratervezése szabványos alparancsok támogatására: ssg dev, ssg build, ssg check (akadálymentességi/SEO-audit) és ssg deploy.
Determinisztikus következtetési gyorsítótár: Egy tartalomhash-alapú gyorsítótárazó réteg megvalósítása minden lokális nyelvimodell-fordítási, -összefoglalási és -metaadatkinyerési feladathoz.

3. szakasz: 1.0.0 (a vállalati és éles főkiadás, 6–12 hónap)

Zéró bizalmú WASM-bővítmény homokozó: Egy WebAssembly-futtatókörnyezet (wasmtime vagy wasmer) beágyazása, amely a harmadik féltől származó bővítményeket teljesen homokozott környezetben, képességalapú fájlrendszer- és hálózati hozzáféréssel hajtja végre.
Lokális szemantikus vektorkeresés (lokális RAG): Egy lokális, Rust-natív beágyazó modell (candle vagy ort révén) beágyazása, amely sűrű bekezdésbeágyazásokat tömör indexbe fordít, lehetővé téve a privát, kliensoldali szemantikus keresést.
Kiszolgálószigetek és WASM-peremcél: <ssg-island> komponensek végrehajtásának megvalósítása peremfuttatókörnyezeteken (például Cloudflare Workers, Vercel Edge vagy Netlify Edge), a lefordított ssg-wasm magra építve.
Aszinkron párhuzamos I/O-motor: A fájlrendszer-írási modul újratervezése aszinkron I/O-szálkészletek és io_uring kötések használatára, kiküszöbölve a processzor-munkások blokkolását a párhuzamos írások során.
SLSA v1.1 builderedet-igazolás és SPDX 3.0 megfelelés: Matematikailag igazolható SLSA Level 3 builderedet-igazolás nyújtása és SPDX 3.0 kompatibilis SBOM-ok generálása, teljesen kielégítve a korszerű szoftverellátásilánc-biztonsági szabványokat.

Versenytárs-mátrix (2026-os környezet)

Az alábbi mátrix a static-site-generator (v1.0 célt) veti össze 2026 vezető webes publikálási motorjaival:

Képesség	static-site-generator v1.0	Hugo v0.155+	Zola v0.19+	Astro 5	Eleventy 3
Nyelv / futtatókörnyezet	Rust (nulla unsafe)	Go	Rust	JS (Node/V8)	JS (Node/V8)
Akadálymentességi buildkapu	Fordítási idejű AST-validálás	Nincs	Nincs	Build utáni linter	Build utáni linter
Biztonsági megerősítés	SHA-384 SRI és CSP-beszúrás	Kézi	Kézi	Kézi	Kézi
Ellátásilánc-biztonság	SLSA L3 + SPDX 3.0 + WASM-homokozó	Minimális	Minimális	Nehéz NPM-fa	Nehéz NPM-fa
MI-tartalmi folyamat	Privát, lokális elsőségű (lokális LLM)	Nincs	Nincs	Csak nyilvános API	Csak nyilvános API
Inkrementális sebesség	<200 ms (meleg gyorsítótár)	<100 ms	<150 ms	~1,5 s	~140 ms
Dinamikus interaktivitás	Kiszolgálószigetek (WASM-célok)	Nincs	Nincs	Kiszolgálószigetek (JS)	Szigetek (JS)
Keresőmotor	Lokális szemantikus WASM-keresés	Egyszerű karakterlánc	Egyszerű karakterlánc	Pagefind (JS)	Pagefind (JS)

Pozicionálás 1.0-nál

1.0-nál a szándékolt pozicionálás egy olyan statikus oldalgenerátor, amelyet alapértelmezetten biztonságos szoftver-infrastruktúraként terveztek: lokális elsőségű MI-folyamatok által támogatott szerzőség; több mint 100 000 oldal fordítása párhuzamos streaming folyamaton keresztül; buildkapuként kikényszerített WCAG 2.2 AA, valamint szigorú CSP és SRI; és homokozott dinamikus szigetek, mindez egyetlen, memóriabiztos Rust-bináris keretében. E kijelentés minden tagmondata a fenti ütemterv egy konkrét tételéhez rendelhető, nem pedig egy marketingtörekvéshez.

Szabályozási és megfelelőségi integráció

A nagy tétű vállalati és pénzügyi ágazatokban a szoftvert a megfelelőség és a kockázati tőke lencséjén keresztül értékelik. A static-site-generator architekturális ütemterve közvetlenül igazodik a főbb szabályozói előírásokhoz:

DORA 6. cikk (IKT-kockázatkezelés): A SHA-384 SRI-hashek és a szigorú tartalombiztonsági szabályzatok fordítási idejű kiszámítása és beszúrása kielégíti azt a követelményt, hogy a digitális publikálási csatornákat meg kell védeni az ellátási lánc felőli injekciótól, a webes megrongálástól és a webhelyközi szkriptelési (cross-site scripting, XSS) vektoroktól.
DORA 7. cikk (IKT-rendszerek ellenállóképessége): A megváltoztathatatlan, fordítási időben ellenőrzött statikus eszközökre való áttéréssel a pénzügyi intézmények kiküszöbölik az adatbázis- és futásidejű kiszolgálósérülékenységeket, csökkentve a működési kockázati szorzót és a Bázel III szerint megkövetelt kockázatitőke-tartalékokat.
Európai akadálymentesítési irányelv (EAA), (EU) 2019/882 irányelv: Az akadálymentességi audit balra tolása a fordítási folyamatba, kemény fordítókapuként, 100%-os megfelelést garantál a telepítés előtt, kiküszöbölve a márkakárosodás és az EAA, valamint az ADA III. cím szerinti polgári perek kockázatát.
GDPR 25. cikk (beépített adatvédelem): A fordítási és metaadat-folyamat lokális, hálózatilag elszigetelt hardveren történő futtatása kívül tartja a védett vázlatokat, pénzügyi mutatókat és személyes adatokat a nyilvános, harmadik féltől származó felhőalapú nyelvimodell-szolgáltatókon, támogatva az adatszuverenitási elveknek való megfelelést.

Gyakran ismételt kérdések

Mit szállít ténylegesen a 0.0.41 verzió ma, szemben azzal, amit a README állít? A biztonsági és akadálymentességi modell valódi, és kódban kikényszerített: munkaterületre kiterjedő forbid(unsafe_code), SHA-256/384 SRI-generálás, CSP-kinyerés, Sigstore-tanúsítvánnyal és CycloneDX SBOM-mal ellátott aláírt kiadások, valamint egy buildet leállító WCAG 2.2 AA kapu. Három dokumentált funkció nem működik a v0.0.41-ben. A MinifyPlugin szóközösszevonó, nem pedig szintaxistudatos minifikáló; a DepGraph, amely az inkrementális újraépítéseket hajtaná, lefordul, de éles kódban soha nem töltődik fel; az AVIF-kódolás pedig olyan csonk, amelynek avif_variants metódusa üres vektort ad vissza.

A akadálymentességi kapu valódi fordítókapu, vagy build utáni linter? Buildkapu. A WCAG 2.2 AA ellenőrzések a fordítási folyamaton belül, egy Playwrighttal vezérelt, fordítási idejű axe-core elemzőn keresztül futnak, és egy megbukó oldal pontos sorszámhibákkal leállítja a fordítást, ahelyett hogy utólag figyelmeztetést adna. Éppen ez az a tulajdonság, amelyre egy európai akadálymentesítési irányelv szerinti kötelezettségnek szüksége van: a nem megfelelő kimenet nem juthat el a telepítésig.

Miért számít, hogy a curl-t héjból hívja a nyelvimodell-bővítmény? A lokális nyelvimodell-folyamat (src/plugins/llm.rs) a gazdagép curl binárisát hívja meg a lokális végpontok eléréséhez. Ez a buildet egy gazdagépi végrehajtható fájlhoz köti, elbukik a PATH-ban curl nélküli rendszereken, héjinjekciós felületet vezet be, és megtörik a hálózatilag elszigetelt CI-ben. A hívás átállítása egy Rust HTTP-kliensre, például a ureq-re, megszünteti a külső függőséget és az injekciós vektort, ezért ez a második tétel a 0.0.42 javításban.

Mi az egyetlen legfontosabb tétel az 1.0-hoz vezető úton? A DepGraph feltöltése és a --incremental kapcsoló bekötése. Az inkrementális újraépítések jelentik a hitelességi szakadékot a dokumentált és a tényleges motor között, és a másodperc alatti buildekről szóló minden további állítás 100 000+ oldalnál azon múlik, hogy a függőségi gráf követi-e a sablon–oldal és markdown–oldal éleket, ahelyett hogy csupán tesztcélú infrastruktúra maradna.

Hivatkozások

Cloudflare, lol-html: alacsony kimeneti késleltetésű folyamatos HTML-átíró ⧉. [A folyamatos, adatmásolás nélküli HTML-átíró, amelyet a 0.1.0 szakaszban a törékeny karakterlánc-manipuláció lecserélésére javasolnak.]
W3C, A webes tartalmak akadálymentesítési irányelve (WCAG) 2.2 ⧉. [A fordítási idejű akadálymentességi kapu által kikényszerített AA szintű sikerkritériumok.]
Európai Unió, (EU) 2022/2554 rendelet (DORA) ⧉. [Az IKT-kockázatkezelési és -ellenállóképességi cikkek, amelyekhez a biztonsági alapállás rendelhető.]
OpenSSF, Supply-chain Levels for Software Artifacts (SLSA) v1.0 ⧉. [A builderedet-igazolási keretrendszer, amelyet 1.0-nál igazolható Level 3 tanúsításra céloznak.]
Armin Ronacher, MiniJinja sablonmotor ⧉. [A függőségszegény motor, amely felváltotta a Terát, és megnyeste a tranzitív fát.]
CycloneDX, Szoftverdarabjegyzék-specifikáció v1.5 ⧉. [Az SBOM-formátum, amelyet minden buildnél kibocsátanak az ellátási lánc auditjához.]
Európai Unió, (EU) 2019/882 irányelv (európai akadálymentesítési irányelv) ⧉. [Az akadálymentességi kötelezettség, amelynek kielégítésére a fordítási idejű WCAG-kaput tervezték.]

Utoljára felülvizsgálva: 2026. július. Az eredeti elemzés a static-site-generator kódbázisának v0.0.41 verziójú vizsgálatán alapul; a források hivatkozottak, nem reprodukáltak. A verziószámok és a funkcióállapot gyorsan változik, újraközlés előtt ellenőrizze a tárolóval szemben. CC-BY-4.0 licenc alatt.

Utolsó felülvizsgálat 2026-07-24.

A cikk újraközlése

Statikus oldalgenerátor (SSG): vállalati szintű stratégiai mélyelemzés és architekturális ütemterv — Sebastien Rousseau

Mélyelemzés egy Rust statikus oldalgenerátorról: fordítási idejű biztonság, WCAG-kapuk és lokális MI, a v0.0.41 hiányosságai, valamint vállalati ütemterv az 1.0-ig.

Ez a cikk a következő licenc alatt áll: Creative Commons Attribution 4.0 International. Az újraközléshez a kanonikus URL forrásmegjelölése szükséges.

Statikus oldalgenerátor (SSG): vállalati szintű stratégiai mélyelemzés és architekturális ütemterv — Sebastien Rousseau

Mélyelemzés egy Rust statikus oldalgenerátorról: fordítási idejű biztonság, WCAG-kapuk és lokális MI, a v0.0.41 hiányosságai, valamint vállalati ütemterv az 1.0-ig.

Originally published at https://sebastienrousseau.com/hu/2026-07-22-ssg-enterprise-strategic-deep-dive-architectural-roadmap/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER