Architecture unbundled: four frontend modules go standalone + OSS mirror hardened

R4: splitting the frontend into truly independent modules

The studio's frontend had grown large enough that its four heaviest packages — chat, workbench, settings, dashboard — were all embedded in the main repo, compiled together and released together. For developers, changing one line in chat meant waiting for the entire frontend to rebuild; architecturally, the tangled dependencies between the four blocks grew harder and harder to untangle. This day's R4 plan registered each of these four packages as independent submodules, each with its own repository, its own version, its own CI. The benefit was immediate: each module can iterate and test independently, and touching chat doesn't force a workbench rebuild. The downside is also clear — more submodules to manage. But for a project moving from "rapid prototype" to "long-term maintainable," this step had to come sooner or later, and sooner is better.

The CLI dependency closure goes standalone too

Not just the frontend. This day also extracted the CLI's dependency closure — contracts, agent-host, platform-io, core — out of the main repo into standalone submodule repositories. Previously they lived as subdirectories of the main repo, sharing one node_modules and one build pipeline; but the CLI is fundamentally an independent product that needs to stay compatible across different Studio versions, and being embedded in the monorepo constrained its flexibility. Once extracted, the CLI can version and test independently, and the OSS mirror only needs to sync these repositories to build completely — before this, the missing dependencies caused the public mirror's bun install to keep failing.

The OSS mirror: from "browsable" to "buildable"

This day gave the public OSS mirror (ForgeaX-Games/forgeax-studio) a thorough hardening. The biggest change: pushing code to the public repo no longer goes straight to main — it must go through a PR + auto-merge flow, meaning every sync gets a CI check, a review trail and a rollback point. At the same time, the public repo got real build CI for the first time: type-checking, bun fx setup, smoke tests, running end to end to ensure the code open-source users receive actually compiles. A security hole was plugged too: admins previously could bypass branch protection and push directly; now enforce_admins=true closes that path. The MIRROR_TOKEN leak was also fixed, and a PR-time mirror dry-run gate was added. In one sentence: the mirror went from "code you can browse but might not build" to "CI guarantees it builds, process guarantees it's traceable."

Viewport 2×2 redesign: run × display orthogonal modes

This day also landed an important design spec: the viewport 2×2 redesign. The core idea is to decouple "run mode" (Edit / Play) from "display mode" (Scene / Game) into two orthogonal dimensions, forming a 2×2 matrix. Previously the editor's Edit and Play were two mutually exclusive states, with the entire viewport rebuilt on switch; the new design lets you see both the scene view and the game view simultaneously, driven by different run states. This is a step toward matching UE5's editor experience — editing and previewing on one screen without toggling back and forth.

v0.3.3 automatic nightly release + a pile of build fixes

The nightly release pipeline successfully produced v0.3.3 automatically this day. But the process also exposed and fixed a fair number of issues along the way: the desktop build was missing the Bun sidecar binary, recursive submodule checkout failed intermittently and needed a retry mechanism, Vite alias paths hadn't kept up with package name restructuring, and the Tauri build couldn't find type definitions that had moved from contracts. Also fixed were a server-side workbench GUID remapping bug and a platform-io asset-root off-by-one. Each fix is small on its own, but together they are the key step from "the auto-release pipeline can run" to "the auto-release pipeline runs reliably."

What this day means

The keyword of this day is "boundaries." When a project moves from rapid prototyping into maturity, one of the most important things to do is draw clear boundaries in the code: which pieces are independent modules, who depends on whom, which can release on their own. The R4 split and CLI dependency extraction draw boundaries inside the main repo; hardening the OSS mirror draws a boundary between the internal and public repositories; branch protection and the PR flow draw a boundary between "people" and "code changes." Once the boundaries are clear, each part can evolve, test and release independently, and the project can move from "one person pushing a big ball of mud" to "a set of clear modules each moving forward on their own."