R4 frontend lands + viewport 2×2 redesign

R4 frontend: from standalone submodules to actually running

After splitting chat, workbench, settings and dashboard into standalone submodules on June 30, this day was about "turning them on." The interface package was slimmed to a pure AppKit layer (bus, broadcast, deep links, overlays); the four L2 apps each own agent preferences and file preview via the bus instead of crowding one big store. Studio's main.tsx now initializes initAgentPrefs, initFilePreview, bootBroadcast and daemon tick subscriptions at boot — the four modules are no longer "subdirectories sitting there" but formal parts of the editor. R4 went from plan to structure you can develop against daily.

Viewport 2×2: run mode × display mode

The editor viewport completed its 2×2 redesign this day. Before, Edit and Play were two mutually exclusive states — switching meant rebuilding the entire viewport. The new design splits "run mode" (Edit / Play) and "display mode" (Scene / Game) into two orthogonal dimensions forming a 2×2 matrix — you can see both the scene view and the game view at once, driven by different run states. AppMode became the single source of truth, with the interface and editor submodules aligned to this viewport semantics. It's a step toward a UE5-style editing experience: edit and preview on one screen without toggling back and forth.

Editor decouples game paths — Studio injects layout

The editor submodule shed its hard-coded dependency on game directories this day, becoming a layout-agnostic standalone package. Where game files live and what the URL prefix is no longer gets "baked" by the editor — the host (Studio) injects it: the main viewport iframe gets its path via EditSurfaceProps.gameRoot, localStorage keeps panel iframes pointed at the same game; launching the engine passes the disk scan dir and client URL prefix; desktop packaging also bakes the URL prefix so a frozen app serves game assets correctly. The editor can evolve independently while Studio owns project layout — clearer boundaries.

bun fx update: pull code and see everything at a glance

The first thing a developer does each morning is usually pull the latest code. Before, bun fx update would silently run git pull plus submodule sync — say nothing on success, and dump an opaque error on failure. This day added a structured update report: a color-coded table showing each submodule's pull result (success, skipped, conflict), its current branch, and the latest commit summary. If a submodule has local changes that needed stashing, it tells you explicitly. After one update you know what state the entire project is in — no more running git status in each submodule one by one.

Desktop packaging: cross-platform script + version baking

Desktop packaging was hardened this day too: build-desktop.ts became a cross-platform script with tests added; packaging vendors platform-io and agent-host into the sidecar, baking the version via lib/version.ts into the artifact instead of assembling it at runtime; and bun fx start gained a port-busy check that probes whether common ports are already in use before launch, so you don't end up with half a stack running and no idea why. None of these are flashy on their own, but they determine whether packaging and launching work smoothly on Windows and macOS.

What this day means

The theme of this day is "boundaries landing." Yesterday's R4 split set the direction; today the four modules actually wired into the boot chain. The viewport 2×2 turned editing and previewing from mutually exclusive into composable. The editor handed game-directory ownership back to Studio. Each piece answers the same question: in this editor, who owns what? Once boundaries are clear, modules can iterate independently — touch chat without rebuilding workbench, swap the editor without touching Studio's project layout. Studio is moving from one big ball of mud to a set of modules with clear responsibilities.