--- id: PLN-0013 ticket: studio-code-editor-workspace-foundations title: Implement the read-only Code Editor workspace shell and passive surfaces status: done created: 2026-03-30 completed: 2026-03-30 tags: - studio - editor - implementation - layout - ui --- ## Objective Replace the current hardcoded `EditorWorkspace` with the DEC-0008 read-only workspace shell: left navigator column with reserved `Outline` region, central tab/editor area, passive helper region, and passive status bar. ## Background The current `EditorWorkspace` is only a `CodeArea` mounted under a toolbar. DEC-0008 requires a stable read-only composition that reserves future surfaces without implementing semantic or writable behavior yet. ## Scope ### Included - Recompose `EditorWorkspace` into the DEC-0008 structural layout. - Introduce passive placeholder surfaces for `Outline`, helper, and status bar. - Replace write-oriented/editorially misleading controls with a first-wave read-only shell. - Keep the central editor body ready to host read-only opened file content. ### Excluded - Project-tree scanning and refresh logic. - Actual file opening/session state orchestration beyond the minimum shell integration points. - Save, dirty tracking, write controls, or semantic/LSP behavior. ## Execution Steps ### Step 1 - Replace the current EditorWorkspace composition root **What:** Turn `EditorWorkspace` into a composition root that mounts the DEC-0008 layout instead of a single hardcoded `CodeArea`. **How:** Refactor the current border-pane structure into explicit regions: 1. left column for navigator + reserved outline region, 2. central work area for tab strip + read-only editor body, 3. bottom helper placeholder, 4. bottom status bar. Prefer dedicated controls/panels over one large monolithic workspace class. **File(s):** - `prometeu-studio/src/main/java/p/studio/workspaces/editor/EditorWorkspace.java` - `prometeu-studio/src/main/java/p/studio/workspaces/editor/` ### Step 2 - Introduce passive placeholder controls **What:** Add concrete passive UI surfaces for the reserved regions required by DEC-0008. **How:** Create lightweight controls/panels for: 1. reserved `Outline` region, 2. passive helper region, 3. passive status bar, 4. and the tab-strip shell. These controls should be visually real, but functionally passive where DEC-0008 says behavior is deferred. **File(s):** - `prometeu-studio/src/main/java/p/studio/workspaces/editor/` ### Step 3 - Align editor chrome with read-only first-wave scope **What:** Remove or neutralize UI affordances that imply writable/editor-semantic behavior not present in this wave. **How:** Review the current toolbar and shell-level controls so the first-wave editor does not imply: 1. save, 2. run/build from inside the editor, 3. active outline, 4. or helper-driven functionality that does not exist yet. If a control must remain for layout reasons, make it visually passive and consistent with DEC-0008. **File(s):** - `prometeu-studio/src/main/java/p/studio/workspaces/editor/EditorToolbar.java` - `prometeu-studio/src/main/java/p/studio/workspaces/editor/` ## Test Requirements ### Unit Tests - Add focused tests for any pure layout/session-state model extracted from the workspace shell composition. - If dedicated status/tab placeholder models are introduced, cover their default state with unit tests. ### Integration Tests - No JavaFX full integration harness is required as a prerequisite for this plan. ### Manual Verification - Verify the workspace visually matches DEC-0008 layout. - Verify the left column contains navigator + reserved outline region. - Verify the helper and status bar are present but passive. - Verify no visible control implies save/write behavior in the first wave. ## Acceptance Criteria - [ ] `EditorWorkspace` is no longer a single hardcoded `CodeArea` view. - [ ] The workspace visibly contains navigator, reserved outline region, central tab/editor area, helper placeholder, and status bar. - [ ] The first-wave shell is visually coherent with DEC-0008 read-only scope. - [ ] Placeholder surfaces are present without implying semantic or writable functionality. ## Dependencies - DEC-0008 accepted. - PLN-0012 should land first or in parallel if the wording is stable. ## Risks - If the composition stays monolithic, later navigator/session work will be harder to integrate cleanly. - Leaving write-oriented controls visible would immediately contradict DEC-0008 and confuse later implementation waves.