Entbündelte Architektur: Vier Frontend-Module werden eigenständig verwendet + OSS-Spiegel gehärtet

R4: Aufteilung des Frontends in wirklich unabhängige Module

Das Frontend des Studios war so groß geworden, dass seine vier umfangreichsten Pakete – Chat, Workbench, Einstellungen, Dashboard – alle in das Haupt-Repo eingebettet, zusammen kompiliert und gemeinsam veröffentlicht wurden. Für Entwickler bedeutete das Ändern einer Zeile im Chat, darauf zu warten, dass das gesamte Frontend neu erstellt wurde; Architektonisch wurden die verworrenen Abhängigkeiten zwischen den vier Blöcken immer schwieriger zu entwirren. Der heutige R4-Plan registrierte jedes dieser vier Pakete als unabhängige Submodule, jedes mit seinem eigenen Repository, seiner eigenen Version, seinem eigenen CI. Der Vorteil war unmittelbar: Jedes Modul kann unabhängig iterieren und testen, und die Berührung des Chats erzwingt keinen Workbench-Neuaufbau. Auch der Nachteil liegt klar auf der Hand: Es müssen mehr Submodule verwaltet werden. Aber für ein Projekt, das vom „schnellen Prototyp“ zum „langfristig wartbaren“ Projekt übergeht, musste dieser Schritt früher oder später erfolgen, und früher ist besser.

Die CLI-Abhängigkeitsschließung funktioniert auch eigenständig

Nicht nur das Frontend. An diesem Tag wurde auch die Abhängigkeitsschließung der CLI – Verträge, Agent-Host, Plattform-Io, Kern – aus dem Haupt-Repository in eigenständige Submodul-Repositorys extrahiert. Zuvor lebten sie als Unterverzeichnisse des Haupt-Repos und teilten sich ein „node_modules“ und eine Build-Pipeline; Aber die CLI ist grundsätzlich ein unabhängiges Produkt, das über verschiedene Studio-Versionen hinweg kompatibel bleiben muss, und die Einbettung in das Monorepo schränkte seine Flexibilität ein. Nach dem Extrahieren kann die CLI unabhängig Versionen erstellen und testen, und der OSS-Spiegel muss diese Repositorys nur synchronisieren, um sie vollständig zu erstellen. Zuvor führten die fehlenden Abhängigkeiten dazu, dass die „Bun-Installation“ des öffentlichen Spiegels immer wieder fehlschlug.

Der OSS-Spiegel: von „durchsuchbar“ zu „baubar“

Dieser Tag gab dem öffentlichen OSS-Spiegel (ForgeaX-Games/forgeax-studio) eine gründliche Härtung. Die größte Änderung: Das Verschieben von Code in das öffentliche Repo geht nicht mehr direkt ins Main-Repository – es muss einen PR + Auto-Merge-Flow durchlaufen, was bedeutet, dass jede Synchronisierung eine CI-Prüfung, einen Überprüfungspfad und einen Rollback-Punkt erhält. Gleichzeitig erhielt das öffentliche Repo zum ersten Mal echte Build-CI: Typprüfung, „bun fx setup“, Rauchtests, End-to-End-Ausführung, um sicherzustellen, dass der Code, den Open-Source-Benutzer erhalten, tatsächlich kompiliert wird. Auch eine Sicherheitslücke wurde geschlossen: Bisher konnten Administratoren den Branch-Schutz umgehen und direkt pushen; Jetzt schließt „enforce_admins=true“ diesen Pfad. Das MIRROR_TOKEN-Leck wurde ebenfalls behoben und ein Trockenlauftor für den PR-Zeitspiegel hinzugefügt. In einem Satz: Der Spiegel ging von „Code, den Sie durchsuchen, aber möglicherweise nicht erstellen können“ zu „CI garantiert, dass er erstellt wird, Prozess garantiert, dass er nachvollziehbar ist.“

Neugestaltung des Ansichtsfensters 2×2: orthogonale Modi ausführen × anzeigen

An diesem Tag wurde auch eine wichtige Designspezifikation eingeführt: die Neugestaltung des Ansichtsfensters 2×2. Die Kernidee besteht darin, den „Laufmodus“ (Bearbeiten/Wiedergabe) vom „Anzeigemodus“ (Szene/Spiel) in zwei orthogonale Dimensionen zu entkoppeln und so eine 2×2-Matrix zu bilden. Zuvor waren „Bearbeiten“ und „Wiedergabe“ des Editors zwei sich gegenseitig ausschließende Zustände, wobei das gesamte Ansichtsfenster beim Umschalten neu erstellt wurde; Mit dem neuen Design können Sie sowohl die Szenenansicht als auch die Spielansicht gleichzeitig sehen, abhängig von verschiedenen Laufzuständen. Dies ist ein Schritt in Richtung einer Anpassung an die Editor-Erfahrung von UE5 – Bearbeiten und Vorschau auf einem Bildschirm, ohne hin und her zu wechseln.

v0.3.3 automatische nächtliche Veröffentlichung + eine Menge Build-Korrekturen

Die nächtliche Release-Pipeline hat v0.3.3 heute erfolgreich automatisch erstellt. Der Prozess hat aber auch eine ganze Reihe von Problemen aufgedeckt und behoben: Dem Desktop-Build fehlte die Bun-Sidecar-Binärdatei, das Auschecken rekursiver Submodule schlug zeitweise fehl und erforderte einen Wiederholungsmechanismus, Vite-Aliaspfade hatten mit der Umstrukturierung der Paketnamen nicht Schritt gehalten und der Tauri-Build konnte keine Typdefinitionen finden, die aus Verträgen verschoben wurden. Außerdem wurden ein Fehler bei der serverseitigen Workbench-GUID-Neuzuordnung und ein Plattform-IO-Asset-Root-Off-By-One behoben. Jeder Fix ist für sich genommen klein, aber zusammen sind sie der entscheidende Schritt von „die Auto-Release-Pipeline kann ausgeführt werden“ zu „die Auto-Release-Pipeline läuft zuverlässig“.

Was dieser Tag bedeutet

Das Schlüsselwort dieses Tages ist „Grenzen“. Wenn ein Projekt vom Rapid Prototyping zur Reife übergeht, ist es eines der wichtigsten Dinge, klare Grenzen im Code zu ziehen: Welche Teile sind unabhängige Module, wer hängt von wem ab und welche können selbstständig Releases durchführen. Die R4-Aufteilung und die CLI-Abhängigkeitsextraktion ziehen Grenzen innerhalb des Haupt-Repositorys; Durch das Härten des OSS-Spiegels wird eine Grenze zwischen den internen und öffentlichen Repositorys gezogen. Der Zweigschutz und der PR-Fluss ziehen eine Grenze zwischen „Menschen“ und „Codeänderungen“. Sobald die Grenzen klar sind, kann sich jeder Teil unabhängig weiterentwickeln, testen und veröffentlichen, und das Projekt kann von „einer Person, die einen großen Schlammball schiebt“ zu „einer Reihe klarer Module, die sich jeweils selbstständig weiterentwickeln“ übergehen.