TL;DR. Szczegółowa analiza generatora stron w Rust: bezpieczeństwo w czasie kompilacji, bramki WCAG, lokalna AI, luki wersji 0.0.41 i mapa drogowa do 1.0.

Kluczowe wnioski

Obecne mocne strony. Baza kodu static-site-generator prezentuje kilka wyróżniających się decyzji inżynierskich, które odróżniają ją od starszych silników w JavaScript i Go:.
Luki i realia praktyczne. Mimo tych wyjątkowych mocnych stron rygorystyczna inspekcja bazy kodu wersji 0.0.41 ujawnia kilka luk architektonicznych, funkcjonalnych i dotyczących doświadczenia deweloperskiego pomiędzy deklaracjami dokumentacji…
Brakujące luki architektoniczne (nowe odkrycia). Poza lukami wersji 0.0.41 ocena projektu wobec profilu ryzyka klasy finansowej ujawnia kilka funkcji, których jeszcze nie zapewnia, a których wymagałby nabywca korporacyjny:.
Strategiczna mapa drogowa do 1.0. Poniższa mapa drogowa integruje zarówno rozwiązane luki, jak i nowo odkryte funkcje klasy enterprise w ustrukturyzowane, chronologiczne ramy wydań.

Static Site Generator (SSG): strategiczna analiza klasy enterprise i mapa drogowa architektury

Data badania: 2026-06-22. Na podstawie inspekcji kodu static-site-generator w wersji 0.0.41 oraz analizy sieciowej krajobrazu SSG w 2026 roku.

Dla regulowanego wydawcy generator stron statycznych nie jest już narzędziem projektowym; stanowi część perymetru ryzyka operacyjnego. Otwartoźródłowy static-site-generator napisany w Rust opiera się na tym założeniu, przenosząc bezpieczeństwo, dostępność, internacjonalizację i potoki treści AI na etap kompilacji, tak aby nieudana kontrola zatrzymała kompilację, zamiast trafić na produkcję. Niniejsza analiza oddziela to, co wersja 0.0.41 faktycznie dostarcza, od tego, co jej dokumentacja wciąż jedynie obiecuje, wskazuje pięć funkcji klasy enterprise, których jeszcze nie posiada, oraz proponuje etapową drogę do wydania 1.0 zgodnego z DORA, europejskim aktem o dostępności i nowoczesnymi standardami łańcucha dostaw.

Streszczenie dla kierownictwa

Publikowanie jest dziś perymetrem ryzyka operacyjnego. W świetle DORA, europejskiego aktu o dostępności i RODO każdy publicznie dostępny zasób jest potencjalnym punktem wejścia dla naruszenia łańcucha dostaw, podmiany treści i ekspozycji regulacyjnej. Model działający w czasie kompilacji zawęża ten perymetr, odrzucając niezgodne wyniki, zanim trafią na produkcję.

Cechy wyróżniające silnik są egzekwowane przez kompilator, a nie tylko udokumentowanymi aspiracjami. Obejmujący całą przestrzeń roboczą forbid(unsafe_code), prawdziwe SRI SHA-256/384, automatyczna ekstrakcja CSP oraz bramka WCAG 2.2 AA w czasie kompilacji zamieniają bezpieczeństwo i dostępność z audytów przeprowadzanych po fakcie w twarde błędy kompilacji.

Wersja 0.0.41 ma rozbieżność między dokumentacją a kodem. Natywna minifikacja, kompilacje przyrostowe oparte na grafie zależności oraz obsługa AVIF są opisane, lecz niefunkcjonalne; artykuł wskazuje każdą lukę wraz z dokładnym miejscem w kodzie źródłowym.

Droga do 1.0 to sekwencja, a nie lista życzeń. Najpierw odporność (0.0.42), następnie poprawność przyrostowa (0.1.0), a na końcu funkcje klasy enterprise — piaskownica WASM, lokalne wyszukiwanie semantyczne i weryfikowalna proweniencja SLSA — których wymaga regulowany nabywca (1.0.0).

Obecne mocne strony

Baza kodu static-site-generator prezentuje kilka wyróżniających się decyzji inżynierskich, które odróżniają ją od starszych silników w JavaScript i Go:

Postawa bezpieczeństwa w czasie kompilacji: Obejmujący całą przestrzeń roboczą #![forbid(unsafe_code)] zapewnia gwarancje bezpieczeństwa pamięci w czasie kompilacji. Potok kompilacji generuje prawdziwe skróty Subresource Integrity (SRI) SHA-256/SHA-384 (src/plugins/assets.rs) oraz przeprowadza automatyczną ekstrakcję Content Security Policy (CSP), która usuwa skrypty i style unsafe-inline. Wydania są podpisane, opatrzone atestacją Sigstore i przy każdej kompilacji tworzą plik SBOM w formacie CycloneDX 1.5.
Bramka dostępności egzekwowana przez kompilator: Kontrole zgodności z wytycznymi Web Content Accessibility Guidelines (WCAG) 2.2 na poziomie AA działają wewnątrz potoku kompilacji za pośrednictwem parsera axe-core uruchamianego w czasie kompilacji przez Playwright. Dostępność staje się twardą bramką kompilacji, a nie audytem po publikacji: jeśli strona nie przejdzie kontroli, kompilacja zatrzymuje się z błędami wskazującymi dokładne numery wierszy.
Potok AI z suwerennością danych: Lokalny potok tłumaczenia i ekstrakcji metadanych oparty na LLM (poprzez lokalne punkty końcowe Ollama lub llama.cpp) pozwala instytucji automatyzować streszczanie treści, generowanie schematów JSON-LD i tłumaczenie wielojęzyczne bez wysyłania informacji poprzedzających publikację wyników finansowych ani wrażliwej własności intelektualnej do publicznych API AI w chmurze.
Zrównoleglona kompilacja: Gwarancje bezpieczeństwa pamięci w Rust stanowią podstawę zrównoleglonego, napędzanego przez Rayon potoku HTML i zasobów (src/core/pipeline.rs). Potok wtyczek wykonuje połączone transformacje, przy czym SearchPlugin, SeoPlugin, CanonicalPlugin i JsonLdPlugin działają na par_iter(), tak że każda strona jest odczytywana i zapisywana na dysk tylko raz.
Higiena łańcucha dostaw i zależności: Migracja silnika szablonów z Tera na MiniJinja (v0.0.37) zmniejszyła rozmiar pliku binarnego, usunęła zależności przechodnie takie jak rand w czasie kompilacji i wytworzyła zwięzły ślad zależności, który obniża ekspozycję łańcucha dostaw oprogramowania.

Luki i realia praktyczne

Mimo tych wyjątkowych mocnych stron rygorystyczna inspekcja bazy kodu wersji 0.0.41 ujawnia kilka luk architektonicznych, funkcjonalnych i dotyczących doświadczenia deweloperskiego pomiędzy deklaracjami dokumentacji a rzeczywistym kodem w Rust:

Luki architektoniczne

Zwijanie białych znaków a natywna minifikacja: Choć plik README obiecuje „natywną minifikację JS/CSS", MinifyPlugin (src/plugins/plugins.rs:96-116) działa jedynie jako naiwny mechanizm zwijania białych znaków. Pomija elementy <pre> i zwija ciągi białych znaków w HTML, lecz nie przeprowadza świadomej składniowo natywnej minifikacji CSS ani JS. Ponadto przetwarza tylko strony najwyższego poziomu i nie przechodzi rekurencyjnie przez podkatalogi (takie jak /blog/ czy /tags/), pozostawiając zagnieżdżone strony bez minifikacji.
Martwa infrastruktura przyrostowa: Graf śledzenia zależności (DepGraph w src/core/depgraph.rs) jest kompilowany i ładowany do PluginContext.dep_graph, lecz nigdy nie jest faktycznie wypełniany w kodzie produkcyjnym. Metoda add_dep() jest wywoływana wyłącznie w testach jednostkowych, przez co deklaracja README o „kompilacjach przyrostowych opartych na grafach zależności" pozostaje obecnie jedynie planem.
Kompilacja wsadowa a kompilacja strumieniowa: Moduł streaming::compile_batch (src/core/streaming.rs) nie działa naprawdę strumieniowo. Zamiast tego kompiluje strony partiami do katalogu tymczasowego, wykonuje staticdatagen::compile od zera dla każdej partii i scala wyniki. Skutkuje to znacznym narzutem wejścia/wyjścia dysku i nadmiarowym parsowaniem, odbiegając od prawdziwej architektury strumieniowej.
Naruszenia faz cyklu życia wtyczek: Wtyczki generujące nowe strony HTML podczas kompilacji, takie jak TaxonomyPlugin, PaginationPlugin i I18nPlugin, zapisują dane bezpośrednio na dysk w fazie after_compile, zamiast korzystać z cyklu życia transform_html. W konsekwencji strony generowane przez te wtyczki omijają kluczowe wtyczki przetwarzania końcowego (takie jak CanonicalPlugin, JsonLdPlugin, RobotsPlugin i AccessibilityPlugin), jeśli zostały one zarejestrowane wcześniej. Pozostawia to strony tagów, kategorii i stronicowane bez poprawnych odnośników kanonicznych, schematów JSON-LD czy walidacji dostępności.
Wywoływanie curl w powłoce w LlmPlugin: Lokalny potok treści LLM (src/plugins/llm.rs) wywołuje bezpośrednio w powłoce systemowy plik binarny curl, aby odpytywać lokalne punkty końcowe. Wprowadza to poważne błędy międzyplatformowe (np. na hostach Windows bez curl w zmiennej PATH), stwarza zagrożenie bezpieczeństwa (wektory wstrzykiwania poleceń powłoki) i zawodzi w zablokowanych lub odizolowanych od sieci środowiskach CI.
Naiwna manipulacja łańcuchami znaków przy przepisywaniu HTML: Ekstraktory image_plugin.rs i search.rs przepisują łańcuchy HTML za pomocą kruchych operacji str::find i str::rfind. Podejście to jest wysoce podatne na uszkodzone znaczniki HTML, znaczniki <img> wewnątrz komentarzy, encje znakowe w tekście alternatywnym lub istniejące już właściwości srcset, co może prowadzić do uszkodzonego wyniku.
Niezaimplementowana obsługa AVIF: Choć kodowanie obrazów AVIF jest obszernie udokumentowane, implementacja w image_plugin.rs to zaślepka, w której avif_variants po prostu zwraca Vec::new(), pozostawiając funkcję niedziałającą.
Obserwator oparty na odpytywaniu: Obserwator lokalnego serwera deweloperskiego (src/server/watch.rs) korzysta z odpytywania zamiast z interfejsów zdarzeń systemu plików, co prowadzi do nadmiernego zużycia procesora w stanie bezczynności i podsekundowego opóźnienia wykrywania zmian.

Luki funkcjonalne i w doświadczeniu deweloperskim

Brak śledzenia zależności przechodnich: Graf zależności nie potrafi śledzić zależności zagnieżdżonych (np. zmian w podszablonie, które wpływają na układ, który wpływa na stronę), co potwierdza test jednostkowy transitive_not_tracked.
Brak flagi CLI kompilacji przyrostowej: Do kompilatora wykonawczego nie jest podłączona żadna flaga CLI --incremental, co uniemożliwia deweloperom korzystanie z buforowanych kompilacji.
HMR ograniczone do CSS: Hot Module Replacement (HMR) obsługuje wyłącznie CSS; każda modyfikacja plików HTML, układów lub Markdown wyzwala pełne przeładowanie strony, obniżając tempo pracy deweloperów.
Niedobór podpoleceń: Deweloperzy muszą ręcznie przekazywać rozwlekłe flagi (ssg -s public -w), ponieważ standardowe podpolecenia takie jak ssg dev, ssg build, ssg check i ssg lint nie istnieją.

Brakujące luki architektoniczne (nowe odkrycia)

Poza lukami wersji 0.0.41 ocena projektu wobec profilu ryzyka klasy finansowej ujawnia kilka funkcji, których jeszcze nie zapewnia, a których wymagałby nabywca korporacyjny:

1. Piaskownica wtyczek WebAssembly (rozszerzalność w modelu zero-trust)

Choć sam plik binarny kompilatora jest napisany w bezpiecznym Rust, umożliwienie dowolnym wtyczkom stron trzecich natywnego wykonywania na systemach hosta wprowadza poważną podatność łańcucha dostaw. Skompromitowana wtyczka strony trzeciej mogłaby z łatwością uzyskać dostęp do systemu plików hosta, odczytać zastrzeżone pliki Markdown lub wykraść prywatne poświadczenia.

Brakująca funkcja: Środowisko wykonawcze w piaskownicy. Aby osiągnąć kompilację w modelu zero-trust, kompilator powinien wykonywać wtyczki stron trzecich wewnątrz wbudowanego środowiska uruchomieniowego WebAssembly (takiego jak wasmtime). Wtyczki powinny wchodzić w interakcję z hostem wyłącznie poprzez ograniczony interfejs WebAssembly System Interface (WASI), zawężając ich dostęp ściśle do przekształcanej strony.

2. Parsowanie HTML bez kopiowania z użyciem strumieniowego AST (`lol_html`)

Migracja warstwy parsowania HTML do pełnej biblioteki DOM działającej w pamięci (takiej jak Kuchiki czy html5ever) wprowadza znaczny narzut pamięci i przerwy w przetwarzaniu przy obsłudze witryn liczących ponad 100 000 stron.

Brakująca funkcja: Strumieniowy mechanizm przepisywania HTML bez kopiowania. Wykorzystanie lol_html firmy Cloudflare (mechanizmu przepisywania HTML o niskim opóźnieniu wyjścia) pozwala kompilatorowi parsować, badać i modyfikować elementy HTML w jednym przebiegu strumieniowym przy niemal zerowej alokacji pamięci, zgodnie z celem równoległego kompilatora strumieniowego, jakim są podsekundowe kompilacje.

3. Lokalne semantyczne wyszukiwanie wektorowe (lokalny RAG)

Obecny indeks wyszukiwania (SearchPlugin) generuje ciężki, płaski indeks JSON, który wykonuje proste dopasowania łańcuchów po stronie klienta, bez obsługi wyszukiwania rozmytego, stemmingu ani zapytań semantycznych. Pagefind stanowi ulepszenie, lecz nadal opiera się na pobieraniu dużego indeksu.

Brakująca funkcja: Wbudowane wyszukiwanie semantyczne. Kompilator powinien w czasie kompilacji wykorzystywać lokalny, lekki, natywny dla Rust model osadzeń wektorowych (taki jak model MiniLM-L6 uruchamiany przez candle lub ort / ONNX Runtime). Powinien generować gęste osadzenia wektorowe dla każdego akapitu strony i wytwarzać zwięzły indeks wektorowy. Widżet wyszukiwania po stronie klienta, skompilowany do WASM, może następnie przeprowadzać prawdziwe wyszukiwanie semantyczne offline bezpośrednio w przeglądarce.

4. Deterministyczne buforowanie tłumaczeń i wnioskowania

Ponieważ lokalne wnioskowanie LLM (np. poprzez Ollama lub Llama.cpp) jest wysoce obciążające dla procesora/karty graficznej, tłumaczenie lub generowanie metadanych dla tysięcy stron przy każdej kompilacji jest obliczeniowo nieopłacalne.

Brakująca funkcja: Buforowanie wnioskowania oparte na skrótach treści. Kompilator musi utrzymywać deterministyczny bufor wszystkich operacji LLM. Jeśli skrót SHA-256 treści pliku Markdown i jego parametrów tłumaczenia odpowiada wpisowi w buforze, kompilator powinien ponownie użyć zbuforowanego tłumaczenia i metadanych, pomijając nadmiarowe lokalne wnioskowanie.

5. Asynchroniczne wejście/wyjście plików dla skalowania równoległego

Choć potok wtyczek jest zrównoleglony za pomocą Rayon, standardowe synchroniczne zapisy na dysk blokują wątki systemowe Rayon, tworząc wąskie gardło wejścia/wyjścia przy zapisie dziesiątek tysięcy stron.

Brakująca funkcja: Asynchroniczne, nieblokujące wejście/wyjście dysku. Kompilator powinien oddzielić zadania obciążające procesor (parsowanie Markdown, minifikacja) od zapisów ograniczonych dyskiem, wykorzystując asynchroniczne pule wątków wejścia/wyjścia lub linuksowe wiązania io_uring (poprzez rio lub tokio) do równoległego zapisu skompilowanych stron bez blokowania równoległych wykonawców procesora.

Strategiczna mapa drogowa do 1.0

Poniższa mapa drogowa integruje zarówno rozwiązane luki, jak i nowo odkryte funkcje klasy enterprise w ustrukturyzowane, chronologiczne ramy wydań.

Faza 1: 0.0.42 (poprawka odporności i poprawności, od 1 do 2 tygodni)

Przebudowa MinifyPlugin: Integracja minify-html, oxc_minifier i lightningcss na potrzeby natywnej, świadomej składniowo minifikacji HTML, JS i CSS. Zapewnienie, że wtyczka przechodzi rekurencyjnie przez wszystkie zagnieżdżone katalogi w obrębie site_dir.
Zabezpieczenie potoku AI: Przeniesienie LlmPlugin z natywnych wywołań curl w powłoce na ureq (lekki, synchroniczny, bezpieczny klient HTTP w Rust) w celu zapewnienia zgodności międzyplatformowej i wyeliminowania podatności na wstrzykiwanie poleceń powłoki.
Dokończenie implementacji AVIF: Bezpośrednie wpięcie ravif w potok zasobów graficznych, umożliwiające wydajne kodowanie AVIF obok WebP i PNG.
Automatyzacja mapowania HrefLang i wielu lokalizacji: Automatyczne wykrywanie równoległych przetłumaczonych stron w kompilacjach wielojęzycznych i wstrzykiwanie standardowych, zgodnych z Google znaczników <link rel="alternate" hreflang="..." /> do sekcji head każdego skompilowanego pliku HTML.
Obsługa JSON Feed 1.1: Dostarczenie dedykowanego emitera JSON Feed 1.1 obok standardowych kanałów syndykacji RSS 2.0 i Atom 1.0.

Faza 2: 0.1.0 (wydanie pomniejsze wiarygodności i przyrostowości, od 2 do 3 miesięcy)

Wypełnienie DepGraph i włączenie --incremental: Pełne podłączenie DepGraph do śledzenia zależności szablon-strona i Markdown-strona. Zaimplementowanie warstwy unieważniania bufora i podłączenie flagi CLI --incremental, z celem podsekundowych kompilacji poniżej 200 ms dla środowisk z rozgrzanym buforem.
Strumieniowe przepisywanie AST za pomocą lol_html: Zastąpienie kruchego przepisywania łańcuchów znaków w image_plugin.rs, search.rs oraz wstrzyknięć CSP strumieniowym mechanizmem przepisywania HTML bez kopiowania, napędzanym przez lol_html.
Obserwator sterowany zdarzeniami i HMR komponentów: Przeniesienie modułu obserwatora z odpytywania na sterowaną zdarzeniami skrzynkę notify oraz zaimplementowanie przeładowania na gorąco tylko dla CSS i częściowego HTML z aktualizacjami przeglądarki poniżej 100 ms.
Ujednolicony interfejs poleceń CLI: Przeprojektowanie interfejsu kompilatora tak, aby obsługiwał standardowe podpolecenia: ssg dev, ssg build, ssg check (audyt dostępności/SEO) oraz ssg deploy.
Deterministyczny bufor wnioskowania: Zaimplementowanie warstwy buforowania opartej na skrótach treści dla wszystkich lokalnych zadań LLM: tłumaczenia, streszczania i ekstrakcji metadanych.

Faza 3: 1.0.0 (wydanie główne, produkcyjne i klasy enterprise, od 6 do 12 miesięcy)

Piaskownica wtyczek WASM w modelu zero-trust: Wbudowanie środowiska uruchomieniowego WebAssembly (wasmtime lub wasmer) do wykonywania wtyczek stron trzecich w pełni izolowanym środowisku z dostępem do systemu plików i sieci opartym na uprawnieniach.
Lokalne semantyczne wyszukiwanie wektorowe (lokalny RAG): Wbudowanie lokalnego, natywnego dla Rust modelu osadzeń (poprzez candle lub ort) w celu kompilowania gęstych osadzeń akapitów w zwięzły indeks, umożliwiając prywatne wyszukiwanie semantyczne po stronie klienta.
Wyspy serwerowe i cel brzegowy WASM: Zaimplementowanie wykonywania komponentów <ssg-island> w środowiskach brzegowych (takich jak Cloudflare Workers, Vercel Edge czy Netlify Edge) zbudowanych na skompilowanym rdzeniu ssg-wasm.
Asynchroniczny silnik równoległego wejścia/wyjścia: Przeprojektowanie modułu zapisu systemu plików tak, aby korzystał z asynchronicznych pul wątków wejścia/wyjścia i wiązań io_uring, eliminując blokowanie wątków roboczych procesora podczas zapisów równoległych.
Proweniencja kompilacji SLSA v1.1 i zgodność ze SPDX 3.0: Zapewnienie matematycznie weryfikowalnej proweniencji kompilacji SLSA na poziomie 3 oraz generowanie plików SBOM zgodnych ze SPDX 3.0, w pełni spełniając nowoczesne standardy bezpieczeństwa łańcucha dostaw oprogramowania.

Macierz konkurencji (krajobraz 2026)

Poniższa macierz porównuje static-site-generator (cel wersji 1.0) z wiodącymi silnikami publikacji internetowej 2026 roku:

Funkcja	static-site-generator v1.0	Hugo v0.155+	Zola v0.19+	Astro 5	Eleventy 3
Język / środowisko uruchomieniowe	Rust (zero unsafe)	Go	Rust	JS (Node/V8)	JS (Node/V8)
Bramka dostępności w kompilacji	Walidacja AST w czasie kompilacji	Brak	Brak	Linter po kompilacji	Linter po kompilacji
Utwardzanie bezpieczeństwa	SHA-384 SRI i wstrzykiwanie CSP	Ręczne	Ręczne	Ręczne	Ręczne
Bezpieczeństwo łańcucha dostaw	SLSA L3 + SPDX 3.0 + piaskownica WASM	Minimalne	Minimalne	Rozbudowane drzewo NPM	Rozbudowane drzewo NPM
Potok treści AI	Prywatny, lokalny (lokalny LLM)	Brak	Brak	Tylko publiczne API	Tylko publiczne API
Szybkość przyrostowa	<200 ms (rozgrzany bufor)	<100 ms	<150 ms	~1,5 s	~140 ms
Dynamiczna interaktywność	Wyspy serwerowe (cele WASM)	Brak	Brak	Wyspy serwerowe (JS)	Wyspy (JS)
Wyszukiwarka	Lokalne semantyczne wyszukiwanie WASM	Proste dopasowanie łańcuchów	Proste dopasowanie łańcuchów	Pagefind (JS)	Pagefind (JS)

Pozycjonowanie w wersji 1.0

W wersji 1.0 zamierzone pozycjonowanie to generator stron statycznych zaprojektowany jako domyślnie bezpieczna infrastruktura oprogramowania: tworzenie treści wspierane lokalnymi potokami AI; kompilacja ponad 100 000 stron przez równoległy potok strumieniowy; WCAG 2.2 AA oraz rygorystyczne CSP i SRI egzekwowane jako bramki kompilacji; a także izolowane w piaskownicy dynamiczne wyspy — wszystko w obrębie jednego, bezpiecznego pamięciowo pliku binarnego w Rust. Każdy człon tego stwierdzenia odpowiada konkretnej pozycji z powyższej mapy drogowej, a nie marketingowej aspiracji.

Integracja regulacyjna i zgodność

W sektorach korporacyjnych i finansowych o wysokiej stawce oprogramowanie ocenia się przez pryzmat zgodności i kapitału na ryzyko. Mapa drogowa architektury static-site-generator jest bezpośrednio zgodna z głównymi mandatami regulacyjnymi:

DORA, artykuł 6 (zarządzanie ryzykiem ICT): Obliczanie i wstrzykiwanie w czasie kompilacji skrótów SRI SHA-384 oraz rygorystycznych zasad Content Security Policy spełnia wymóg ochrony cyfrowych kanałów publikacji przed wstrzyknięciem przez łańcuch dostaw, podmianą treści witryny i wektorami cross-site scripting (XSS).
DORA, artykuł 7 (odporność systemów ICT): Przechodząc na niezmienne, zweryfikowane w czasie kompilacji zasoby statyczne, instytucje finansowe eliminują podatności baz danych i serwerów uruchomieniowych, obniżając mnożnik ryzyka operacyjnego i zmniejszając wymagane rezerwy kapitału na ryzyko w ramach Bazylei III.
Europejski akt o dostępności (EAA), dyrektywa (UE) 2019/882: Przesunięcie audytu dostępności w lewo, do potoku kompilacji jako twardej bramki kompilatora, gwarantuje 100% zgodności przed wdrożeniem, eliminując ryzyko szkód wizerunkowych i postępowań cywilnych w ramach EAA oraz Title III ustawy ADA.
RODO, artykuł 25 (ochrona danych w fazie projektowania): Uruchamianie potoku tłumaczeń i metadanych na lokalnym, odizolowanym od sieci sprzęcie utrzymuje zastrzeżone wersje robocze, wskaźniki finansowe i dane osobowe z dala od publicznych, zewnętrznych dostawców LLM w chmurze, wspierając zgodność z zasadami suwerenności danych.

Najczęściej zadawane pytania

Co wersja 0.0.41 faktycznie dostarcza dziś w porównaniu z tym, co deklaruje README? Model bezpieczeństwa i dostępności jest realny i egzekwowany w kodzie: obejmujący całą przestrzeń roboczą forbid(unsafe_code), generowanie SRI SHA-256/384, ekstrakcja CSP, podpisane wydania z atestacją Sigstore i plik SBOM w formacie CycloneDX oraz zatrzymująca kompilację bramka WCAG 2.2 AA. Trzy udokumentowane funkcje nie są funkcjonalne w wersji 0.0.41. MinifyPlugin jedynie zwija białe znaki, zamiast być świadomym składni minifikatorem; DepGraph, który miałby napędzać kompilacje przyrostowe, jest kompilowany, lecz nigdy wypełniany w kodzie produkcyjnym; a kodowanie AVIF to zaślepka, której avif_variants zwraca pusty wektor.

Czy bramka dostępności to prawdziwa bramka kompilatora, czy linter uruchamiany po kompilacji? To bramka kompilacji. Kontrole WCAG 2.2 AA działają wewnątrz potoku kompilacji za pośrednictwem parsera axe-core uruchamianego w czasie kompilacji przez Playwright, a strona, która nie przejdzie kontroli, zatrzymuje kompilację z błędami wskazującymi dokładne numery wierszy, zamiast emitować ostrzeżenie po fakcie. Właśnie tej właściwości wymaga obowiązek wynikający z europejskiego aktu o dostępności: niezgodny wynik nie może trafić na wdrożenie.

Dlaczego wywoływanie curl w powłoce w ramach wtyczki LLM ma znaczenie? Lokalny potok LLM (src/plugins/llm.rs) wywołuje systemowy plik binarny curl, aby dotrzeć do lokalnych punktów końcowych. Wiąże to kompilację z plikiem wykonywalnym hosta, zawodzi w systemach bez curl w zmiennej PATH, wprowadza powierzchnię ataku typu wstrzyknięcie poleceń powłoki i psuje się w odizolowanym od sieci CI. Przeniesienie tego wywołania na klienta HTTP w Rust, taki jak ureq, usuwa zewnętrzną zależność i wektor wstrzyknięcia, dlatego stanowi drugą pozycję poprawki 0.0.42.

Która pojedyncza pozycja jest najważniejsza na drodze do 1.0? Wypełnienie DepGraph i podłączenie flagi --incremental. Kompilacje przyrostowe stanowią lukę wiarygodności między udokumentowanym a rzeczywistym silnikiem, a każda dalsza deklaracja o podsekundowych kompilacjach przy ponad 100 000 stron zależy od tego, czy graf zależności śledzi krawędzie szablon-strona i Markdown-strona, zamiast pozostawać infrastrukturą wyłącznie testową.

Źródła

Cloudflare, lol-html: strumieniowy mechanizm przepisywania HTML o niskim opóźnieniu wyjścia ⧉. [Strumieniowy mechanizm przepisywania HTML bez kopiowania, proponowany jako zamiennik kruchej manipulacji łańcuchami znaków w fazie 0.1.0.]
W3C, Web Content Accessibility Guidelines (WCAG) 2.2 ⧉. [Kryteria sukcesu poziomu AA egzekwowane przez bramkę dostępności w czasie kompilacji.]
Unia Europejska, Rozporządzenie (UE) 2022/2554 (DORA) ⧉. [Artykuły dotyczące zarządzania ryzykiem ICT i odporności, którym odpowiada postawa bezpieczeństwa.]
OpenSSF, Supply-chain Levels for Software Artifacts (SLSA) v1.0 ⧉. [Ramy proweniencji kompilacji, których celem jest weryfikowalna atestacja poziomu 3 w wersji 1.0.]
Armin Ronacher, Silnik szablonów MiniJinja ⧉. [Ubogi w zależności silnik, który zastąpił Tera i ograniczył drzewo zależności przechodnich.]
CycloneDX, Specyfikacja Software Bill of Materials v1.5 ⧉. [Format SBOM emitowany przy każdej kompilacji na potrzeby audytu łańcucha dostaw.]
Unia Europejska, Dyrektywa (UE) 2019/882 (europejski akt o dostępności) ⧉. [Obowiązek w zakresie dostępności, który ma spełniać bramka WCAG działająca w czasie kompilacji.]

Ostatni przegląd: lipiec 2026. Pierwotna analiza oparta na inspekcji bazy kodu static-site-generator w wersji 0.0.41; źródła są cytowane, a nie powielane. Numery wersji i status funkcji zmieniają się szybko — przed ponowną publikacją należy zweryfikować je względem repozytorium. Licencja CC-BY-4.0.

Ostatnia weryfikacja 2026-07-24.

Opublikuj ponownie ten artykuł

SSG: strategiczna analiza i mapa drogowa architektury klasy enterprise — Sebastien Rousseau

Szczegółowa analiza generatora stron w Rust: bezpieczeństwo w czasie kompilacji, bramki WCAG, lokalna AI, luki wersji 0.0.41 i mapa drogowa do 1.0.

Ten artykuł jest objęty licencją Creative Commons Attribution 4.0 International. Ponowna publikacja wymaga przypisania do kanonicznego adresu URL.

SSG: strategiczna analiza i mapa drogowa architektury klasy enterprise — Sebastien Rousseau

Szczegółowa analiza generatora stron w Rust: bezpieczeństwo w czasie kompilacji, bramki WCAG, lokalna AI, luki wersji 0.0.41 i mapa drogowa do 1.0.

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

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER