3.2 KiB
3.2 KiB
| id | ticket | title | status | created | tags | |||||
|---|---|---|---|---|---|---|---|---|---|---|
| LSN-0022 | studio-play-stop-cartridge-flow | Studio Play/Stop and Debugger Workspace Integration | done | 2026-04-07 |
|
Summary
This lesson covers the implementation of the first wave of the Play/Stop flow in Studio and its integration with a native DebugWorkspace.
The feature enables developers to:
- Press
Playto build, pack, and run the current project in the configured runtime. - Automatically navigate to a
DebugWorkspacethat shows merged preparation and runtime logs. - Press
Stopto kill the active runtime process.
Key Decisions
Based on DEC-0020, DEC-0021, and DEC-0022:
- Preparation Pipeline: The
Playflow orchestrates existing domain operations:build->validate pack->pack->manifest generation. All artifacts are kept inbuild/, avoiding a redundantcartridge/directory for this wave. - Runtime Command: The runtime is executed externally as
"<runtimePath>" run buildwith the project root as its working directory. - Process Ownership: Studio owns exactly one active runtime process handle per project shell.
- Merged Logs: Preparation logs (build, pack validation, pack) and runtime logs (stdout/stderr) are merged into a single execution-session stream.
- Native Debugger Workspace: A native
DebugWorkspacehosts the execution session and acts as the primary log sink. It is not an external launcher but a real Studio workspace. - Shared Session State: The execution state (
idle,preparing,connecting,running, etc.) lives outside the visual workspace lifecycle in a sharedStudioExecutionSessionService.
Implementation Details
StudioPlayStopCoordinator
The main orchestrator for the Play and Stop actions. It:
- Manages the
preparing->connecting->runningstate machine. - Invokes the
StudioShipperServicefor preparation. - Spawns the external runtime process using
StudioExternalRuntimeProcessLauncher. - Merges log streams from both preparation and runtime into the
StudioExecutionSessionService.
DebugWorkspace
A Studio Workspace implementation that reflects the StudioExecutionSnapshot. It uses DebugWorkspaceProjection to transform the session logs into a display-ready format.
StudioShipperService
Aggregates the domain-specific tasks (compiler build, packer pack) and generates the mandatory manifest.json in the build/ directory.
Common Pitfalls & Anti-Patterns
- Redundant Checks: Do not add manual
manifest.jsonexistence checks before spawning. The success of the preparation pipeline already guarantees its presence according to the contract. - State Duplication: Avoid tracking execution state in both the shell and the workspace. The shared
StudioExecutionSessionServiceis the single source of truth. - Technical Linkage: Do not hard-link the Studio codebase with the legacy
../debuggerrepository. Selective migration of protocol/session logic is preferred.
References
DEC-0020: Build and pack preparation.DEC-0021: External runtime execution.DEC-0022: NativeDebugWorkspaceintegration.PLN-0045: End-to-end execution flow.