A desktop Műhelyt újra kellett kezdeni: Rust/Tauri helyett natív SwiftUI

A helyzet

A KampányMűvek generátora, deployja és QA-ja már erős volt, a napi használat viszont túl terminálközpontú maradt. A cél ezért nem CMS építése volt, hanem egy mérnöki kezelőfelület: olyan desktop Műhely, ahonnan a site-ok, build-ek, műveletek és tartalmi feladatok biztonságosan elérhetők. A meglévő Tauri/Rust irány gyorsan adott működő prototípust, de előbb egy blokkoló Rust `Command::output()` hívás fagyasztotta a felületet, később pedig a kis ablakos navigáció, a menü, a responsive CSS és az összhatás mutatta meg, hogy továbbra is egy webalkalmazást próbálunk desktopnak öltöztetni.

A megoldási út

Először nem dobtuk el az irányt: Job Manager készült streaming stdout/stderr-rel, progresszel és cancel lehetőséggel, különválasztottuk az Engine- és Site-műveleteket, majd macOS-szerű sidebar, görgethető menü és világos/sötét/automatikus téma került a kliensbe. Amikor ezek után is a shell korlátait javítgattuk az üzleti feladat helyett, meghoztuk a döntést: a Tauri/Rust klienst elengedjük, és natív SwiftUI-ra váltunk. A fontos architekturális szabály viszont megmaradt: zéró üzleti vagy control-plane logika kerülhet a desktop kliensbe. Az Engine egy headless JSONL interfészen adja az állapotot és a műveleteket; a Swift kliens csak parancsot indít, eseményt olvas és natív UI-vá alakítja. Erre épült rá a workspace-, Node-, nyelv- és témabeállítás, a portkezelés, bootstrap/dependency flow, legacy/generator/artifact dev módok, Content CRUD, Engine dashboard, Operations nézet és az élő log.

Mi lett belőle

A nap végére nem egy becsomagolt weboldalunk volt, hanem működő natív macOS alkalmazásalapunk. A debug és release build, valamint a macOS codesign ellenőrzés átment, a fleet smoke mind az öt site-on zöld volt, miközben az Engine maradt az egyetlen forrásigazság. A legfontosabb eredmény mégsem a Swift-kód mennyisége volt, hanem hogy a desktop réteg lecserélhetővé vált anélkül, hogy a platformlogikát újra kellett volna írni.