diff --git a/README.md b/README.md index a3b6427a..748f1020 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ Prometeu Studio is the desktop development environment for the Prometeu toolchain. -This repository packages the Studio shell together with the embedded services it depends on: project VFS, language tooling, compiler pipeline integration, and asset packing. The current implementation is a Java/JavaFX multi-module Gradle build. +This repository packages the Studio shell together with the embedded services it depends on: compiler pipeline integration, asset packing, runtime/debug orchestration, and project-local Studio state. The current implementation is a Java/JavaFX multi-module Gradle build. ## What Lives Here @@ -10,8 +10,6 @@ The root project is a monorepo with these main areas: - `prometeu-app`: JavaFX application entry point (`p.studio.App`). - `prometeu-studio`: Studio UI, workspaces, project session lifecycle, play/stop flow, and debugger-facing surfaces. -- `prometeu-vfs`: project document access and save/open contracts. -- `prometeu-lsp`: language-service integration used by the editor workflow. - `prometeu-packer`: embedded packer APIs and implementation used by Studio. - `prometeu-compiler`: compiler core, build pipeline, frontend APIs, and the PBS frontend. - `prometeu-infra`: shared infrastructure used across modules. @@ -21,14 +19,13 @@ The root project is a monorepo with these main areas: ## Current Product Shape -The Studio shell currently organizes the product around four workspaces: +The Studio shell currently organizes the product around three workspaces: - Assets -- Code editor - Debug - Shipper -At runtime, the app boots an embedded packer, creates a project document VFS, wires LSP services, and opens the Studio launcher window. Project creation currently scaffolds a Prometeu workspace with `prometeu.json`, `src/`, `assets/`, `build/`, `cartridge/`, `.workspace/`, and local Studio metadata. +At runtime, the app boots an embedded packer, restores project-local Studio state, and opens the Studio launcher window. Project creation currently scaffolds a Prometeu workspace with `prometeu.json`, `src/`, `assets/`, `build/`, `cartridge/`, `.workspace/`, and local Studio metadata. ## Requirements @@ -68,7 +65,7 @@ If you are new to the codebase, this order is usually the fastest path: 1. Start at `prometeu-app` to see application bootstrap. 2. Read `prometeu-studio` for the shell, workspaces, and user-facing flows. -3. Read `prometeu-vfs`, `prometeu-lsp`, and `prometeu-packer` for service boundaries. +3. Read `prometeu-packer` for asset and packaging boundaries. 4. Read `prometeu-compiler` when you need compiler or PBS language behavior. ## Specs And Architecture diff --git a/discussion/index.ndjson b/discussion/index.ndjson index 0b06bb11..038eb391 100644 --- a/discussion/index.ndjson +++ b/discussion/index.ndjson @@ -1,5 +1,5 @@ {"type":"meta","next_id":{"DSC":32,"AGD":35,"DEC":32,"PLN":65,"LSN":47,"CLSN":1}} -{"type":"discussion","id":"DSC-0031","status":"in_progress","ticket":"studio-editor-workspace-cleanup","title":"Limpeza completa do Workspace Editor do Studio e remoção dos acoplamentos legados","created_at":"2026-05-05","updated_at":"2026-05-05","tags":["studio","editor","cleanup","vfs","lsp","migration"],"agendas":[{"id":"AGD-0034","file":"AGD-0034-vscode-editor-migration-feasibility.md","status":"accepted","created_at":"2026-05-05","updated_at":"2026-05-05"}],"decisions":[{"id":"DEC-0031","file":"DEC-0031-studio-editor-workspace-cleanup.md","status":"in_progress","created_at":"2026-05-05","updated_at":"2026-05-05","ref_agenda":"AGD-0034"}],"plans":[{"id":"PLN-0062","file":"PLN-0062-shell-session-and-state-cleanup-after-editor-removal.md","status":"done","created_at":"2026-05-05","updated_at":"2026-05-05","ref_decisions":["DEC-0031"]},{"id":"PLN-0063","file":"PLN-0063-legacy-lsp-and-vfs-module-removal-with-runtime-preservation.md","status":"done","created_at":"2026-05-05","updated_at":"2026-05-05","ref_decisions":["DEC-0031"]},{"id":"PLN-0064","file":"PLN-0064-normative-test-and-lesson-cleanup-for-editor-stack-removal.md","status":"open","created_at":"2026-05-05","updated_at":"2026-05-05","ref_decisions":["DEC-0031"]}],"lessons":[]} +{"type":"discussion","id":"DSC-0031","status":"in_progress","ticket":"studio-editor-workspace-cleanup","title":"Limpeza completa do Workspace Editor do Studio e remoção dos acoplamentos legados","created_at":"2026-05-05","updated_at":"2026-05-05","tags":["studio","editor","cleanup","vfs","lsp","migration"],"agendas":[{"id":"AGD-0034","file":"AGD-0034-vscode-editor-migration-feasibility.md","status":"accepted","created_at":"2026-05-05","updated_at":"2026-05-05"}],"decisions":[{"id":"DEC-0031","file":"DEC-0031-studio-editor-workspace-cleanup.md","status":"in_progress","created_at":"2026-05-05","updated_at":"2026-05-05","ref_agenda":"AGD-0034"}],"plans":[{"id":"PLN-0062","file":"PLN-0062-shell-session-and-state-cleanup-after-editor-removal.md","status":"done","created_at":"2026-05-05","updated_at":"2026-05-05","ref_decisions":["DEC-0031"]},{"id":"PLN-0063","file":"PLN-0063-legacy-lsp-and-vfs-module-removal-with-runtime-preservation.md","status":"done","created_at":"2026-05-05","updated_at":"2026-05-05","ref_decisions":["DEC-0031"]},{"id":"PLN-0064","file":"PLN-0064-normative-test-and-lesson-cleanup-for-editor-stack-removal.md","status":"done","created_at":"2026-05-05","updated_at":"2026-05-05","ref_decisions":["DEC-0031"]}],"lessons":[]} {"type":"discussion","id":"DSC-0030","status":"done","ticket":"studio-scene-pack-runtime-binary-contract","title":"Studio scene pack contract for runtime SCENE binary payload","created_at":"2026-04-24","updated_at":"2026-05-01","tags":["studio","packer","runtime","scene","asset-pack","binary-format","tiled"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0046","file":"discussion/lessons/DSC-0030-studio-scene-pack-runtime-binary-contract/LSN-0046-canonical-scene-owns-editorial-truth-while-pack-stays-request-driven.md","status":"done","created_at":"2026-05-01","updated_at":"2026-05-01"}]} {"type":"discussion","id":"DSC-0029","status":"done","ticket":"studio-frame-composer-syscall-and-sprite-alignment","title":"Studio Alignment with Runtime FrameComposer Syscalls and Sprite Composition","created_at":"2026-04-18","updated_at":"2026-04-18","tags":["studio","compiler","pbs","stdlib","runtime-alignment","abi","syscall","frame-composer","sprites"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0041","file":"discussion/lessons/DSC-0029-studio-frame-composer-syscall-and-sprite-alignment/LSN-0041-composer-must-own-public-sprite-composition.md","status":"done","created_at":"2026-04-18","updated_at":"2026-04-18"}]} {"type":"discussion","id":"DSC-0028","status":"done","ticket":"studio-tiled-parser-assets-scene-asset-type","title":"Tiled Parser and Scene Asset-Type Ownership in Assets Workspace","created_at":"2026-04-15","updated_at":"2026-04-23","tags":["studio","assets","scene","tiled","parser","asset-type"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0045","file":"discussion/lessons/DSC-0028-studio-tiled-parser-assets-scene-asset-type/LSN-0045-asset-owned-scene-bank-and-tiled-xml-workflow.md","status":"done","created_at":"2026-04-23","updated_at":"2026-04-23"}]} diff --git a/discussion/lessons/DSC-0010-studio-code-editor-workspace-foundations/LSN-0026-read-only-editor-foundations-and-semantic-deferral.md b/discussion/lessons/DSC-0010-studio-code-editor-workspace-foundations/LSN-0026-read-only-editor-foundations-and-semantic-deferral.md index 6fb7d673..59ff60de 100644 --- a/discussion/lessons/DSC-0010-studio-code-editor-workspace-foundations/LSN-0026-read-only-editor-foundations-and-semantic-deferral.md +++ b/discussion/lessons/DSC-0010-studio-code-editor-workspace-foundations/LSN-0026-read-only-editor-foundations-and-semantic-deferral.md @@ -6,6 +6,10 @@ created: 2026-03-31 tags: [studio, editor, workspace, read-only, navigator, tabs, lsp-deferred, ui-foundations] --- +## Historical Status + +This lesson documents the removed embedded Studio code editor. Keep it as historical context only; do not treat it as current product guidance after `DEC-0031`. + ## Context Studio needed a real `Code Editor` workspace, but the team explicitly did not want the first wave to collapse UI structure, file management, write behavior, and language semantics into one premature implementation. diff --git a/discussion/lessons/DSC-0012-studio-editor-document-vfs-boundary/LSN-0027-project-document-vfs-and-session-owned-editor-boundary.md b/discussion/lessons/DSC-0012-studio-editor-document-vfs-boundary/LSN-0027-project-document-vfs-and-session-owned-editor-boundary.md index 12253223..02548f45 100644 --- a/discussion/lessons/DSC-0012-studio-editor-document-vfs-boundary/LSN-0027-project-document-vfs-and-session-owned-editor-boundary.md +++ b/discussion/lessons/DSC-0012-studio-editor-document-vfs-boundary/LSN-0027-project-document-vfs-and-session-owned-editor-boundary.md @@ -6,6 +6,10 @@ created: 2026-03-31 tags: [studio, editor, vfs, project-session, filesystem, boundary, architecture] --- +## Historical Status + +This lesson documents the removed embedded Studio editor/VFS split. Keep it as historical context only; do not treat it as current product guidance after `DEC-0031`. + ## Context The first Studio `Code Editor` wave had already established a read-only editorial shell, but the concrete implementation still let the editor package own direct filesystem concerns for: diff --git a/discussion/lessons/DSC-0013-studio-editor-write-wave-supported-non-frontend-files/LSN-0028-controlled-editor-write-wave-and-read-only-frontend-semantic-phase.md b/discussion/lessons/DSC-0013-studio-editor-write-wave-supported-non-frontend-files/LSN-0028-controlled-editor-write-wave-and-read-only-frontend-semantic-phase.md index 5d1af977..fd1ac79b 100644 --- a/discussion/lessons/DSC-0013-studio-editor-write-wave-supported-non-frontend-files/LSN-0028-controlled-editor-write-wave-and-read-only-frontend-semantic-phase.md +++ b/discussion/lessons/DSC-0013-studio-editor-write-wave-supported-non-frontend-files/LSN-0028-controlled-editor-write-wave-and-read-only-frontend-semantic-phase.md @@ -6,6 +6,10 @@ created: 2026-04-02 tags: [studio, editor, vfs, lsp, access-policy, save, read-only, frontend-boundary] --- +## Historical Status + +This lesson documents the removed embedded Studio editor, VFS, and legacy LSP flow. Keep it as historical context only; do not treat it as current product guidance after `DEC-0031`. + ## Context The first Studio `Code Editor` implementation had already established a session-owned document boundary through `prometeu-vfs`, but it was still missing the next operational split: diff --git a/discussion/lessons/DSC-0014-studio-frontend-owned-semantic-editor-presentation/LSN-0029-frontend-owned-semantic-presentation-descriptor-and-host-consumption.md b/discussion/lessons/DSC-0014-studio-frontend-owned-semantic-editor-presentation/LSN-0029-frontend-owned-semantic-presentation-descriptor-and-host-consumption.md index 08b8eaaa..e696df55 100644 --- a/discussion/lessons/DSC-0014-studio-frontend-owned-semantic-editor-presentation/LSN-0029-frontend-owned-semantic-presentation-descriptor-and-host-consumption.md +++ b/discussion/lessons/DSC-0014-studio-frontend-owned-semantic-editor-presentation/LSN-0029-frontend-owned-semantic-presentation-descriptor-and-host-consumption.md @@ -6,6 +6,10 @@ created: 2026-04-02 tags: [studio, editor, frontend, semantic-highlighting, lsp, compiler, pbs, presentation] --- +## Historical Status + +This lesson documents the removed embedded Studio semantic editor presentation path. Keep it as historical context only; do not treat it as current product guidance after `DEC-0031`. + ## Context The first semantic highlight wave for frontend documents had already proved that Studio could consume semantic spans through the integrated LSP path. diff --git a/discussion/lessons/DSC-0016-studio-editor-scope-guides-and-brace-anchoring/LSN-0034-active-scope-gutter-and-frontend-owned-structural-anchors.md b/discussion/lessons/DSC-0016-studio-editor-scope-guides-and-brace-anchoring/LSN-0034-active-scope-gutter-and-frontend-owned-structural-anchors.md index 6fef5de8..3dc30133 100644 --- a/discussion/lessons/DSC-0016-studio-editor-scope-guides-and-brace-anchoring/LSN-0034-active-scope-gutter-and-frontend-owned-structural-anchors.md +++ b/discussion/lessons/DSC-0016-studio-editor-scope-guides-and-brace-anchoring/LSN-0034-active-scope-gutter-and-frontend-owned-structural-anchors.md @@ -6,6 +6,10 @@ created: 2026-04-06 tags: [studio, editor, scope-guides, structural-anchors, semantic-read, frontend-contract] --- +## Historical Status + +This lesson documents the removed embedded Studio editor gutter and structural-anchor flow. Keep it as historical context only; do not treat it as current product guidance after `DEC-0031`. + ## Context The Studio editor already exposed structural guides in the gutter, but the old behavior mixed two different concerns: diff --git a/discussion/lessons/DSC-0017-studio-editor-inline-type-hints-for-let-bindings/LSN-0035-frontend-owned-inline-hints-with-decorative-inline-rendering.md b/discussion/lessons/DSC-0017-studio-editor-inline-type-hints-for-let-bindings/LSN-0035-frontend-owned-inline-hints-with-decorative-inline-rendering.md index 6148aa40..28c9df00 100644 --- a/discussion/lessons/DSC-0017-studio-editor-inline-type-hints-for-let-bindings/LSN-0035-frontend-owned-inline-hints-with-decorative-inline-rendering.md +++ b/discussion/lessons/DSC-0017-studio-editor-inline-type-hints-for-let-bindings/LSN-0035-frontend-owned-inline-hints-with-decorative-inline-rendering.md @@ -6,6 +6,10 @@ created: 2026-04-06 tags: [studio, editor, inline-hints, lsp, compiler, pbs, type-inference, rendering] --- +## Historical Status + +This lesson documents the removed embedded Studio inline-hint path. Keep it as historical context only; do not treat it as current product guidance after `DEC-0031`. + ## Context The repository needed inline type hints for inferred PBS `let` bindings, but the real architectural issue was broader than one PBS feature. diff --git a/discussion/lessons/DSC-0020-studio-editor-indentation-policy-and-project-setup/LSN-0033-setup-owned-indentation-policy-and-project-bootstrap-defaults.md b/discussion/lessons/DSC-0020-studio-editor-indentation-policy-and-project-setup/LSN-0033-setup-owned-indentation-policy-and-project-bootstrap-defaults.md index faa8ecc2..0167ed5c 100644 --- a/discussion/lessons/DSC-0020-studio-editor-indentation-policy-and-project-setup/LSN-0033-setup-owned-indentation-policy-and-project-bootstrap-defaults.md +++ b/discussion/lessons/DSC-0020-studio-editor-indentation-policy-and-project-setup/LSN-0033-setup-owned-indentation-policy-and-project-bootstrap-defaults.md @@ -6,6 +6,10 @@ created: 2026-04-04 tags: [studio, editor, indentation, tabs, setup, dot-studio, project-creation, gitignore] --- +## Historical Status + +This lesson documents indentation policy choices made for the removed embedded Studio editor. Keep it as historical context only; do not treat it as current product guidance after `DEC-0031`. + ## Context The Studio editor exposed an indentation chip in the status bar, but that chip was driven by file-content heuristics rather than by a stable editor policy. diff --git a/discussion/lessons/DSC-0021-studio-frontend-editor-write-and-save-wave/LSN-0036-vfs-owned-frontend-edit-and-save-wave.md b/discussion/lessons/DSC-0021-studio-frontend-editor-write-and-save-wave/LSN-0036-vfs-owned-frontend-edit-and-save-wave.md index 15045bb1..10ae674c 100644 --- a/discussion/lessons/DSC-0021-studio-frontend-editor-write-and-save-wave/LSN-0036-vfs-owned-frontend-edit-and-save-wave.md +++ b/discussion/lessons/DSC-0021-studio-frontend-editor-write-and-save-wave/LSN-0036-vfs-owned-frontend-edit-and-save-wave.md @@ -6,6 +6,10 @@ created: 2026-04-06 tags: [studio, editor, frontend, write, save, vfs, lsp, access-policy, persistence] --- +## Historical Status + +This lesson documents the removed embedded Studio frontend edit/save wave. Keep it as historical context only; do not treat it as current product guidance after `DEC-0031`. + ## Context The first editor write wave had deliberately kept frontend files hard `read-only` while semantic-read support shipped through `prometeu-lsp`. diff --git a/discussion/workflow/plans/PLN-0064-normative-test-and-lesson-cleanup-for-editor-stack-removal.md b/discussion/workflow/plans/PLN-0064-normative-test-and-lesson-cleanup-for-editor-stack-removal.md index 1572f13a..bf0bdd81 100644 --- a/discussion/workflow/plans/PLN-0064-normative-test-and-lesson-cleanup-for-editor-stack-removal.md +++ b/discussion/workflow/plans/PLN-0064-normative-test-and-lesson-cleanup-for-editor-stack-removal.md @@ -2,9 +2,9 @@ id: PLN-0064 ticket: studio-editor-workspace-cleanup title: Normative Test and Lesson Cleanup for Editor Stack Removal -status: open +status: done created: 2026-05-05 -completed: +completed: 2026-05-05 tags: [studio, editor, cleanup, docs, tests, lessons] --- @@ -72,11 +72,11 @@ Remove or revise the normative documentation, tests, lessons, and user-facing re ## Acceptance Criteria -- [ ] Studio specs no longer define the embedded editor stack as an active surface. -- [ ] Studio README/index material no longer points to removed editor/VFS/LSP architecture as current. -- [ ] Editor-specific i18n keys are removed or no longer consumed. -- [ ] Obsolete tests are removed or rewritten. -- [ ] Historical lessons are clearly demoted from active operational guidance. +- [x] Studio specs no longer define the embedded editor stack as an active surface. +- [x] Studio README/index material no longer points to removed editor/VFS/LSP architecture as current. +- [x] Editor-specific i18n keys are removed or no longer consumed. +- [x] Obsolete tests are removed or rewritten. +- [x] Historical lessons are clearly demoted from active operational guidance. ## Dependencies @@ -88,4 +88,3 @@ Remove or revise the normative documentation, tests, lessons, and user-facing re - Removing normative docs too early may temporarily leave the repo without clear current guidance. - Historical lessons may still be valuable; deleting them outright could lose context that should instead be reclassified. - Partial cleanup can leave broken links or missing i18n keys that only appear at runtime. - diff --git a/docs/specs/studio/1. Studio Shell and Workspace Layout Specification.md b/docs/specs/studio/1. Studio Shell and Workspace Layout Specification.md index dcfa325c..5de9ba5a 100644 --- a/docs/specs/studio/1. Studio Shell and Workspace Layout Specification.md +++ b/docs/specs/studio/1. Studio Shell and Workspace Layout Specification.md @@ -44,15 +44,10 @@ The left workspace selector remains fixed in the baseline Studio shell. The baseline workspace set includes: -- Code Editor; - Asset Management; - Debugger/Profiler; - Shipper, temporarily represented by the current `BuilderWorkspace`. -Workspace-local behavior for the first `Code Editor` wave is defined in: - -- `5. Code Editor Workspace Specification.md` - `BuilderWorkspace` is transitional and must not be treated as a long-term architectural reference for the final shipping surface. ## Workspace Architecture Model @@ -71,7 +66,7 @@ Baseline workspace architecture rules are: The shell must not encourage a workspace model where every interaction falls back to whole-workspace refresh. Detailed local workspace composition remains workspace-owned. -For example, `Code Editor`-local layout, navigator behavior, tab rules, passive placeholder surfaces, document access-mode behavior, and editor-local save surfaces are not shell-global rules and must be defined by the workspace-local editor specification. +For example, `Assets`-local navigator behavior, detail-pane composition, and mutation flows are not shell-global rules and must be defined by the workspace-local specifications that still exist. Project-session boundaries may still exist above a workspace when the state must remain alive while the project window stays open. diff --git a/docs/specs/studio/5. Code Editor Workspace Specification.md b/docs/specs/studio/5. Code Editor Workspace Specification.md deleted file mode 100644 index b498d34d..00000000 --- a/docs/specs/studio/5. Code Editor Workspace Specification.md +++ /dev/null @@ -1,377 +0,0 @@ -# Code Editor Workspace Specification - -## Status - -Active - -## Applies To - -- `prometeu-studio` -- the Studio `Code Editor` workspace -- the first controlled editor write wave for supported documents including frontend sources - -## Purpose - -Define the normative Studio contract for the first `Code Editor` workspace wave. - -This specification stabilizes: - -- the baseline visual composition of the workspace, -- the `Project Navigator` role and scope, -- the controlled editable file-opening model, -- the responsive tab baseline, -- the editor-owned composition surfaces that host save and semantic-read UX, -- the gutter-based active-structure indicator model for semantic editor scopes, -- the editor-local save surfaces, -- and the workspace boundary with the integrated frontend semantic-read phase. - -## Authority and Precedence - -This specification extends: - -- [`1. Studio Shell and Workspace Layout Specification.md`](1.%20Studio%20Shell%20and%20Workspace%20Layout%20Specification.md) -- [`2. Studio UI Foundations Specification.md`](2.%20Studio%20UI%20Foundations%20Specification.md) -- [`3. Studio Components Module Specification.md`](3.%20Studio%20Components%20Module%20Specification.md) -- [`6. Project Document VFS Specification.md`](6.%20Project%20Document%20VFS%20Specification.md) -- [`7. Integrated LSP Semantic Read Phase Specification.md`](7.%20Integrated%20LSP%20Semantic%20Read%20Phase%20Specification.md) - -If this document conflicts with the global Studio shell specifications, the shell specifications control shell-wide behavior and this document controls workspace-local editor behavior. - -## Normative Inputs - -The `Code Editor` workspace must assume: - -- the Studio shell already mounts `Code Editor` as a baseline workspace, -- the current wave allows editing for the supported document classes classified by `prometeu-vfs` as editable, including frontend-scoped supported documents, -- all project files remain visible in the editor workspace even when only some are frontend-relevant, -- `prometeu.json` plus the selected frontend may identify source roots worth tagging, -- the integrated frontend semantic-read phase may add diagnostics, symbols, outline-facing structure, definition, and highlight for frontend documents, -- the integrated frontend semantic-read phase may later add dedicated structural-anchor metadata for exact scope-indicator anchoring, -- frontend semantic presentation contract data comes from frontend-owned metadata published through `FrontendSpec`, -- and the current wave must not depend on semantic behavior to remain coherent. - -This workspace may consume Studio project metadata and Studio-owned workspace framework primitives, but it must not infer a semantic-provider contract beyond the explicit frontend-owned descriptor surfaced by the integrated semantic-read phase. -This workspace must consume project tree and document data through `prometeu-vfs` rather than through editor-owned direct filesystem readers. -This workspace must consume document access policy and save capability from `prometeu-vfs` rather than rederiving editability locally. - -## Workspace Model - -The `Code Editor` workspace is: - -- project-aware, -- file-oriented, -- controlled-editable in this wave, with supported documents following the canonical access mode provided by `prometeu-vfs`, -- and not a full semantic IDE surface yet. - -The workspace must help the user: - -- see the full project tree, -- identify frontend-relevant source roots visually, -- open supported files into editor tabs, -- save editable supported documents through editor-local commands, -- consume frontend semantic-read UX provided through the integrated LSP phase when that phase is active, -- understand the active file context, -- and understand that broader IDE automation remains outside this wave. - -The workspace must not pretend to offer: - -- merge behavior, -- completion, -- rename, code actions, or formatting, -- or editor-owned semantic inference that bypasses the integrated LSP phase. - -## Baseline Layout - -The baseline workspace layout is: - -- a left editor column, -- a central editor work area, -- a lower helper region, -- and a bottom status bar. - -The left editor column must be a vertical stack containing: - -- a functional `Project Navigator` at the top, -- and a reserved `Outline` region below it. - -The central editor work area must contain: - -- a top command bar containing at least `Save` and `Save All`, -- a tab strip at the top, -- and the editor body below it. - -The lower helper region is present in this wave only as a passive placeholder. - -## Component Ownership Rules - -The `Code Editor` workspace must be implemented as a composition root plus child controls/panels rather than one monolithic render surface. - -Rules: - -- the workspace root should coordinate layout, workspace-level session state, and structural synchronization; -- the workspace root should consume project-session-owned document services such as `prometeu-vfs` rather than owning their lifecycle locally; -- the `Project Navigator`, tab strip, editor body, reserved `Outline`, helper region, and status bar should exist as explicit local surfaces; -- passive placeholder surfaces must remain visually real without implying unsupported functionality; -- and the first wave should preserve a clean path for later extraction of reusable Studio controls when the surfaces become stable enough to justify that move. - -## Project Navigator Rules - -### Primary Navigation Unit - -- The primary navigation unit is the project file or directory. -- The navigator must cover the whole project rather than only frontend-tagged roots. -- Frontend tagging is supplementary context, not an inclusion filter. - -### Structural Snapshot - -- The navigator must consume a structural project-tree entity provided by `prometeu-vfs`. -- That structural tree must not replace the filesystem as the source of truth. -- Content snapshots are separate and are only required for files that are actually opened in the editor through `prometeu-vfs`. -- The navigator may request more targeted tree refresh operations than a full-tree reload when the `prometeu-vfs` contract provides them. - -### Visibility and Ordering - -- All project files and directories must be visible in the navigator. -- Hidden files must be included by default. -- Folders must sort before files. -- Items within those groups must sort alphabetically. - -### Frontend-Aware Tagging - -- `prometeu.json` plus the selected frontend may be used to tag relevant source roots or source directories. -- That tagging must not hide non-source project files. -- That tagging must not imply semantic/editor-language ownership by the navigator itself. -- Rendering those tags remains a Studio UI concern even when the source data comes from `prometeu-vfs`. - -### Refresh Model - -- The navigator must perform one initial refresh when the project opens. -- The navigator must expose a manual refresh action directly on the navigator surface and route that request through `prometeu-vfs`. -- Watcher-driven automatic refresh is explicitly deferred from this wave. - -### Unsupported Files - -- Unsupported or non-text files may still appear in the navigator. -- File support and unsupported-file classification belong to `prometeu-vfs`. -- Attempting to open such a file must show a simple modal stating that the file is not supported in this wave. -- The workspace must not fake a partial preview to imply unsupported file-format coverage. - -## Tabs and File Opening Rules - -- Selecting a supported file that is not already open must open it in a new tab. -- File opening must resolve document content through `prometeu-vfs`. -- The editor must maintain opened-file content in memory for the active Studio session only. -- Frontend-scoped supported documents may coexist in tabs with other editable supported documents. -- The tab strip must be responsive rather than fixed to one hardcoded tab count. -- Overflow tabs must remain accessible through an IntelliJ-style overflow control. -- The active tab must remain visible. -- The tab label must use only the file name with extension. - -The first wave must not define: - -- tab pinning, -- drag-and-drop tab reordering, -- grouped tabs, -- split editors. - -Project-session-owned cross-session tab restoration is accepted for the project-local Studio state wave. - -Rules: - -- persisted editor restoration state must come from the project-session-owned `.studio/` state store rather than from an editor-owned ad hoc file; -- accepted restoration scope in this wave is limited to open tabs and active tab; -- editor layout restoration accepted in this wave may include divider-driven editor sizing, `Project Navigator` expansion state, and dock-panel configuration such as `Outline` and `Helper` open/closed state plus their restored size; -- restoration must degrade safely when a previously open file is missing or unsupported. - -## Access-Mode and Save Model - -The first `Code Editor` write wave is controlled rather than universally editable. - -Rules: - -- the workspace must treat `prometeu-vfs` as the canonical source of document access mode for supported files; -- the workspace must not infer frontend scope from path heuristics, local UI state, or ad hoc extension checks; -- supported frontend-scoped documents may be editable when `prometeu-vfs` classifies them as editable; -- editable scope is limited to the supported textual classes exposed by `prometeu-vfs` for this wave, including supported frontend sources; -- the workspace must expose save behavior only through an editor-local command bar containing at least `Save` and `Save All`; -- the global shell `Save` menu item must not be the save surface for this wave; -- save intent must route through `prometeu-vfs`, which remains the owner of persistence policy; -- the active indentation policy for editable documents MUST come from project-local setup rather than from file-content heuristics; -- the status-bar indentation chip MUST display the active configured policy, not inferred file contents; -- pressing `Tab` in an editable document MUST insert spaces according to the active configured indentation width; -- the active indentation policy MUST remain stable while the user edits document contents; -- opening a file whose existing indentation diverges from the configured policy MUST NOT trigger automatic reformatting; -- and the workspace must not define local merge/conflict behavior against disk changes. - -## Outline Rules - -- The `Outline` region must exist structurally in this wave. -- Before the integrated LSP semantic-read phase is implemented, it may show a discreet placeholder state. -- When the integrated LSP semantic-read phase is active, the `Outline` region may render frontend document-symbol structure and workspace-symbol-backed navigation owned by that phase. -- The workspace must not fake semantic outline structure before real semantic ownership exists. - -## Helper Region Rules - -- The helper region must exist structurally in this wave. -- Before the integrated LSP semantic-read phase is implemented, it may remain passive. -- It exists only to stabilize workspace composition and reserve future space. -- It may later host diagnostics or related semantic-read detail for frontend documents without changing workspace ownership. -- It must not become a substitute for the shell-level `Activity` surface. - -## Integrated Semantic-Read Boundary - -- Frontend documents may be editable when `prometeu-vfs` grants editable access mode. -- Diagnostics, document symbols, workspace symbols, outline-facing structure, definition, and frontend highlight must come through the integrated LSP semantic-read phase rather than from editor-local inference. -- Exact anchor positions for semantic scope indicators must come from frontend-owned structural metadata rather than Studio-local text scanning when that metadata is available. -- Opened frontend documents must be analyzed from the VFS-owned in-memory snapshot exposed through `prometeu-vfs`. -- Unopened frontend documents may be analyzed from filesystem-backed state exposed through the same `prometeu-vfs` boundary. -- Non-frontend highlight may remain Studio-local in this phase. -- Frontend highlight must come from the integrated LSP semantic-read phase and use frontend-owned semantic presentation contract data derived from `FrontendSpec`. -- Frontend semantic presentation resources must remain frontend-owned and must not be replaced by a Studio-owned generic fallback theme. -- When semantic presentation descriptor data or usable frontend resources are absent, the workspace must continue without semantic highlight for that frontend document. -- The workspace must not surface this condition as a product-facing editor error. -- The workspace must not treat semantic-read over editorial snapshots as authorization for build participation or for bypassing `prometeu-vfs` access policy. - -## Inline Hint Rules - -Inline hints must be treated as a host-generic editor capability rather than as a PBS-only feature. - -The Studio `Code Editor` must render inline hints only from frontend-owned semantic payloads transported through the integrated semantic-read phase. - -The editor must not invent: - -- hint existence policy, -- hint text, -- hint categories, -- or host-owned semantic fallback hints. - -If a frontend publishes valid inline hints through the accepted semantic-read contract, the editor must render them. - -If a frontend does not publish inline hints for a construct, the editor must not synthesize one. - -Inline hints are decorative only. - -Therefore the editor must ensure that inline hints: - -- do not modify document text; -- do not become part of persisted file content; -- do not participate as copied document text; -- do not redefine selection ranges; -- and do not redefine caret movement over the text model. - -The completed capability must render inline hints as real inline editor decorations attached to document positions inside the editor flow. - -An approximate visual implementation may exist only as an explicit transitional wave. - -Any transitional approximation: - -- must be documented as transitional; -- must not redefine the final editor contract; -- and must converge to real inline rendering in a later execution step. - -When only some inline hint spans remain valid under degraded semantic analysis, the editor must continue rendering those valid spans rather than disabling all inline hints for the document. - -## Scope Indicator Rules - -The default semantic scope-indicator surface in the Code Editor must remain the gutter. - -The first active-state wave must render at most two simultaneous semantic indicators: - -- `activeContainer` -- `activeScope` - -The editor must not restore the previous full ancestry stack as the default active-state presentation. - -`activeScope` must be selected as the smallest structural range that contains the caret. - -`activeContainer` must be selected as the immediate structural ancestor of `activeScope`. - -If no valid structural ancestor exists, the editor may omit `activeContainer`. - -The editor must not promote a higher semantic owner such as function, type, or module when a nearer structural ancestor exists. - -The concrete visual presentation of `activeContainer` and `activeScope` remains frontend-owned. This specification intentionally does not fix: - -- colors, -- stroke style, -- dashed versus solid treatment, -- opacity, -- thickness, -- or equivalent visual-emphasis details. - -The Studio editor must only preserve the semantic distinction between the two indicator roles. - -Exact guide start and end anchoring must consume the dedicated structural-anchor semantic surface defined by the integrated semantic-read specification. - -The editor must not treat local brace scanning heuristics as the final production contract for exact anchor placement. - -## Status Bar Rules - -The status bar must remain mostly passive in this wave. - -Its left side must show the breadcrumb path of the active file, such as `proj > src > file.pbs`. - -Its right side must show: - -- `L:C`, -- line separator, -- tabs/spaces mode, -- file extension or language, -- and access-mode state. - -For this wave: - -- `L:C` may remain a visual placeholder, -- editable non-frontend documents may show their current file-type state without implying build participation, -- hard `read-only` frontend documents must show an explicit `read-only` state, -- and the status-bar `read-only` surface should be shaped so it can evolve into a per-file toggle later without requiring a model rewrite. - -## Session State Rules - -Visual/editorial state in this wave is session-local only. - -That includes at minimum: - -- open tabs, -- active tab selection, -- tree expansion state, -- and similar visual editor state. - -The following remain outside editor-owned session state: - -- project-session ownership of `prometeu-vfs`, -- structural project-tree data returned by `prometeu-vfs`, -- support classification rules, -- document loading responsibilities, -- save persistence policy, -- and build-facing document ownership. - -Editable documents may have session-local editorial snapshots while the project session remains open. -Those snapshots are editorial only and must not be treated as canonical build input by implication. - -Persisting that state across Studio executions is deferred. - -## Non-Goals - -- merge/conflict resolution -- watcher-driven automatic refresh -- public `prometeu-vfs` event APIs -- helper panel functionality -- editor-owned semantic analysis that bypasses the integrated LSP phase -- frontend editing -- completion, rename, code actions, or formatting -- a normative editor event contract in this wave -- any implication that editor-owned in-memory snapshots participate in the build -- host-owned semantic inline hint policy - -## Exit Criteria - -This specification is complete enough when: - -- the controlled write-wave scope is unambiguous, -- the `Project Navigator` and tab responsibilities are explicit, -- editor-local `Save` and `Save All` are part of the normative workspace contract, -- hard frontend `read-only` behavior is explicit in both warning and status-bar surfaces, -- the workspace boundary with the integrated frontend semantic-read phase is explicit, -- placeholder versus functional regions are clearly separated, -- and excluded frontend editing and completion behavior are clearly outside the current contract. diff --git a/docs/specs/studio/6. Project Document VFS Specification.md b/docs/specs/studio/6. Project Document VFS Specification.md deleted file mode 100644 index 3efd9559..00000000 --- a/docs/specs/studio/6. Project Document VFS Specification.md +++ /dev/null @@ -1,235 +0,0 @@ -# Project Document VFS Specification - -## Status - -Active - -## Applies To - -- `prometeu-vfs` -- `prometeu-studio` -- the Studio project-document boundary for the first controlled Code Editor write wave - -## Purpose - -Define the normative Studio contract for `prometeu-vfs` as the project-document boundary consumed by Studio workspaces. - -This specification stabilizes: - -- `prometeu-vfs` module role, -- project-session ownership, -- the filesystem-backed first-wave contract, -- structural tree and document access responsibilities, -- canonical frontend scope and access policy ownership, -- editorial snapshot and save ownership for editable supported documents including frontend sources, -- the semantic-read consumer boundary used by the integrated LSP phase, -- the RPC-first public API baseline, -- and explicit first-wave exclusions such as public event publication and watchers. - -## Authority and Precedence - -This specification extends: - -- [`1. Studio Shell and Workspace Layout Specification.md`](1.%20Studio%20Shell%20and%20Workspace%20Layout%20Specification.md) -- [`5. Code Editor Workspace Specification.md`](5.%20Code%20Editor%20Workspace%20Specification.md) - -If this document conflicts with shell-wide Studio rules, the shell specification controls shell-wide behavior and this document controls the project-document boundary contract. - -## Normative Inputs - -`prometeu-vfs` must assume: - -- the current migration wave carries only the Code Editor capabilities that already exist today, -- the initial backend is filesystem-backed, -- the boundary is project-scoped rather than product-global, -- the boundary must outlive workspace focus changes for an opened project, -- Studio UI remains the owner of visual tree state and error presentation, -- and the integrated `prometeu-lsp` phase consumes this boundary as a semantic-read client rather than as a persistence owner. - -`prometeu-vfs` must not infer: - -- watcher-driven refresh in this wave, -- public event API exposure in this wave, -- build participation for editorial snapshots by implication, -- or ownership over non-Studio domains such as packer assets. - -## Module Role - -`prometeu-vfs` is: - -- the Studio project-document boundary, -- the owner of project structural tree data for the covered scope, -- the owner of project document resolution for the covered scope, -- the owner of file support and unsupported-file classification for the covered scope, -- the owner of document access policy for the covered scope, -- the owner of save persistence for editable documents in this wave, -- and the required path through which Studio accesses project-document filesystem state in this wave. - -`prometeu-vfs` is not: - -- a visual tree control, -- a Studio shell replacement, -- a product-wide universal filesystem layer, -- or a public event transport in this wave. - -## Project Session Ownership - -The primary `prometeu-vfs` instance must belong to the Studio project session. - -Rules: - -- a project-scoped `prometeu-vfs` instance must be created when a Studio project session is opened; -- that instance must remain alive while the project session remains open; -- switching workspace focus must not destroy or recreate the project-document state by default; -- the `Code Editor` workspace must consume the session-owned `prometeu-vfs` instance rather than owning the boundary lifecycle itself; -- the project-session scope must cover only the opened project. - -## Filesystem Access Rules - -For the scope covered by this specification, Studio must access the project filesystem through `prometeu-vfs`. - -Rules: - -- the first implementation must be filesystem-backed; -- direct filesystem reads for project tree and document loading must not remain a workspace-owned responsibility in the Code Editor; -- this rule does not grant `prometeu-vfs` ownership over unrelated domains or unrelated filesystem responsibilities elsewhere in the product. - -## Structural Tree Contract - -`prometeu-vfs` must expose a structural representation of the project tree. - -Rules: - -- the structural tree must cover project content only; -- the structural tree must contain structural and documentary data only; -- the structural tree must not contain visual presentation state; -- the structural tree must not contain navigator chrome decisions; -- the structural tree may include structural metadata useful to Studio consumers; -- consumers may request narrower refreshes than a full-tree reload when the request remains within the project boundary. - -The following concerns remain outside `prometeu-vfs`: - -- visual expansion state, -- selection state, -- focus state, -- reveal or scroll behavior, -- icon choice, -- and other view-model concerns of the navigator UI. - -## Document Access Contract - -`prometeu-vfs` must own document resolution for the covered Studio scope. - -Rules: - -- opening a supported file in the Code Editor must go through `prometeu-vfs`; -- the returned document content must describe only project-session document state for the opened project; -- `prometeu-vfs` must classify each supported document as at least editable or hard `read-only`; -- unsupported documents must remain distinguishable from supported `read-only` and supported editable documents; -- `prometeu-vfs` must own editable in-memory editorial snapshots for the current Studio session; -- save operations for editable documents in this wave must persist those editorial snapshots to disk through `prometeu-vfs`; -- Studio consumers must treat `prometeu-vfs` access policy as canonical rather than rederiving editability locally; -- and editorial snapshots must remain outside build-facing document state. - -## Frontend Scope Contract - -Frontend scope must be decided canonically inside `prometeu-vfs`. - -Rules: - -- `FrontendSpec.allowedExtensions` is the source of truth for frontend scope in this wave; -- the VFS document contract must expose a canonical frontend-compatible `typeId` or equivalent scope marker derived from that source of truth; -- consumers must not infer frontend scope from raw dynamic language identifiers, path heuristics, or local UI extension checks; -- frontend-scoped supported documents must be editable in this wave when they are supported by the current frontend; -- the initial editable set is limited to the currently supported textual classes represented as `text`, `json`, `ndjson`, `bash`, and supported frontend source documents resolved from `FrontendSpec.allowedExtensions`; -- and no additional editable class may be inferred by implementation convenience during this wave. - -## Document Access Context - -`prometeu-vfs` must reserve a single access-context entity for document-access-related values. - -Rules: - -- the access-context entity may remain session-local in this wave; -- it must already support lookup and mutation under current demand; -- future persistence may be added later without redesigning the access model; -- and the current reservation must not be treated as authorization for build participation or broader product-wide state ownership. - -## Semantic-Read Consumer Boundary - -`prometeu-vfs` must remain the source-of-truth document substrate consumed by the integrated LSP semantic-read phase. - -Rules: - -- opened frontend documents must be exposed to `prometeu-lsp` from the in-memory editorial snapshot held by `prometeu-vfs`, including dirty snapshots not yet saved to disk; -- unopened frontend documents may be exposed to `prometeu-lsp` from filesystem-backed state through the same boundary; -- `prometeu-lsp` must not bypass `prometeu-vfs` with ad hoc filesystem reads inside Studio UI code; -- `prometeu-lsp` must not become the owner of save, persistence, or access policy; -- semantic analysis over editorial snapshots must remain separate from build-facing document ownership; -- and this boundary must remain suitable for frontend diagnostics, symbols, definition, and highlight without implying frontend edit rights. - -## Support and Plugin Rules - -Support and unsupported-file decisions belong to `prometeu-vfs`. - -Rules: - -- file support classification must be decided inside `prometeu-vfs`; -- plugin or handler resolution for supported file access must be decided inside `prometeu-vfs`; -- Studio UI may render the resulting success or failure state, but it must not own the classification rule itself. - -## Communication Model - -The official first-wave `prometeu-vfs` API is RPC-oriented. - -Rules: - -- commands and queries are the public API baseline for this wave; -- internal runtime events may exist inside `prometeu-vfs`; -- those events must remain internal in this wave; -- internal events must not be promoted to public API by inference during planning or implementation. - -## Refresh and Watchers - -Refresh remains manual in this wave. - -Rules: - -- Studio consumers may request manual refresh through `prometeu-vfs`; -- watcher-driven automatic refresh is deferred; -- file watching must not be introduced implicitly while implementing this specification. - -## Cross-Domain Boundary - -`prometeu-vfs` belongs to the Studio domain. - -Rules: - -- `prometeu-vfs` serves `prometeu-lsp` as a consumer-facing substrate for the semantic-read phase; -- `prometeu-lsp` remains a separate layer and must not be renamed into `prometeu-vfs`; -- `prometeu-vfs` must not absorb packer responsibilities; -- `prometeu-vfs` must not redefine asset ownership; -- extending this boundary outside project-document concerns requires a new decision. - -## Non-Goals - -- public event publication -- watcher-driven refresh -- dirty tracking -- merge or conflict handling -- non-project content snapshots -- a generic product-wide filesystem abstraction -- treating editorial snapshots as canonical build input - -## Exit Criteria - -This specification is complete enough when: - -- `prometeu-vfs` ownership is clearly separated from shell and workspace UI ownership, -- the project-session lifecycle rule is unambiguous, -- the structural tree contract is explicitly non-visual, -- frontend scope and access policy ownership are explicit, -- editable supported-document snapshot and save ownership are explicit, -- the semantic-read consumer boundary with `prometeu-lsp` is explicit, -- the RPC-first public API rule is explicit, -- and deferred public events and watchers are clearly out of scope. diff --git a/docs/specs/studio/7. Integrated LSP Semantic Read Phase Specification.md b/docs/specs/studio/7. Integrated LSP Semantic Read Phase Specification.md deleted file mode 100644 index 61ca1f1b..00000000 --- a/docs/specs/studio/7. Integrated LSP Semantic Read Phase Specification.md +++ /dev/null @@ -1,183 +0,0 @@ -# Integrated LSP Semantic Read Phase Specification - -## Status - -Active - -## Applies To - -- `prometeu-studio` -- `prometeu-vfs` -- `prometeu-lsp` -- the integrated frontend semantic phase in the Studio `Code Editor` workspace - -## Purpose - -Define the normative Studio contract for the integrated frontend semantic-read phase that arrives before any frontend editing release. - -This specification stabilizes: - -- the phase boundary between semantic ownership and frontend editing ownership, -- the ownership relationship between `prometeu-vfs`, `prometeu-lsp`, and the Studio editor, -- the minimum semantic capability set for frontend documents, -- the dedicated semantic surface used for structural anchors and guide-aware editor structure, -- the packaging expectations for the public `prometeu-lsp` API surface, -- and the explicit exclusions that remain outside this phase. - -## Authority and Precedence - -This specification extends: - -- [`5. Code Editor Workspace Specification.md`](5.%20Code%20Editor%20Workspace%20Specification.md) -- [`6. Project Document VFS Specification.md`](6.%20Project%20Document%20VFS%20Specification.md) - -If this document conflicts with shell-wide Studio rules, shell rules control shell behavior, the Code Editor specification controls workspace-local editor UX, the VFS specification controls document-boundary ownership, and this document controls the integrated semantic-read phase itself. - -## Normative Inputs - -The integrated semantic-read phase must assume: - -- frontend-scoped documents may be editable under the controlled write wave exposed by `prometeu-vfs`, -- editable supported documents remain governed by the controlled write wave, -- `FrontendSpec.allowedExtensions` remains the source of truth for frontend scope, -- `FrontendSpec` is the canonical source of frontend semantic presentation contract data, -- `prometeu-vfs` owns document state, snapshots, persistence, and access policy, -- and semantic-read over editorial snapshots must remain separate from build-facing ownership. - -## Phase Boundary - -This phase is a semantic phase for frontend documents, not an ownership phase for frontend editing. - -Rules: - -- no capability in this phase may override `prometeu-vfs` access policy, save policy, or snapshot ownership; -- completion, rename, code actions, and formatting remain outside this phase. - -## Ownership Rules - -- `prometeu-vfs` owns document state, access policy, editorial snapshots, and persistence. -- `prometeu-lsp` is a semantic consumer above `prometeu-vfs`. -- the Studio `Code Editor` owns UX surfaces that render semantic-read output. -- each frontend owns its semantic vocabulary and semantic presentation resources. -- build-facing document ownership remains outside this phase. - -`prometeu-lsp` must not become the owner of: - -- save, -- persistence, -- document access policy, -- frontend semantic presentation assets, -- or frontend edit-right release. - -## Document Source-of-Truth Rules - -- opened frontend documents must be analyzed from the in-memory snapshot exposed by `prometeu-vfs`; -- unopened frontend documents may be analyzed from filesystem-backed state exposed through the same `prometeu-vfs` boundary; -- Studio UI code must not bypass `prometeu-vfs` with ad hoc file loading for semantic-read behavior; -- semantic-read over editorial snapshots must not be treated as canonical build input by implication. - -## Minimum Capability Set - -The minimum semantic capability set of this phase must include: - -- diagnostics for frontend documents; -- document symbols for frontend documents; -- workspace symbols for frontend documents; -- outline-facing structural symbol data; -- go-to-definition for frontend documents; -- frontend semantic highlight. - -The phase may ship the dedicated structural-anchor surface after the baseline capability set is stable, but Studio and frontend implementations must treat that surface as the canonical source of exact scope-indicator anchoring once it exists. - -The phase may also ship a dedicated inline-hint semantic surface. - -Once shipped, frontend and Studio implementations must treat that surface as the canonical source of decorative inline hint payloads. - -## Highlight Ownership Rules - -- frontend highlight must come from semantic information provided through `prometeu-lsp`; -- frontend highlight must use frontend-owned semantic presentation contract data derived from `FrontendSpec`; -- `prometeu-lsp` must expose a dedicated semantic presentation descriptor derived from the resolved `FrontendSpec`; -- that descriptor must remain simple and include frontend-owned `semanticKeys` plus frontend-owned `resources` in the same message surface; -- `prometeu-lsp` must not collapse frontend semantic keys into host-owned generic categories; -- Studio must project semantic keys mechanically to CSS classes without semantic translation; -- frontend semantic presentation resources must remain under frontend `resources/` and be resolved like ordinary Java resources; -- when semantic presentation descriptor data or usable resources are absent, Studio must continue without semantic highlight; -- this condition must not become a product-facing Studio error and may at most produce normal development logs; -- non-frontend highlight may remain on the existing Studio-local highlighting path in this phase. - -## Inline Hint Ownership Rules - -- frontend inline hints must come from semantic information provided through `prometeu-lsp`; -- frontend hint existence and hint payload semantics remain frontend-owned; -- `prometeu-lsp` must expose a dedicated transport contract for inline hints rather than relying on Studio-local inference; -- `prometeu-lsp` must preserve deterministic anchor information required for host rendering; -- `prometeu-lsp` must not invent host-owned hint policy when a frontend does not publish hints; -- Studio must render transported hints mechanically as host decorations rather than as document text; -- valid inline hint spans must survive partial degradation when the frontend can still produce them; -- invalid or missing hint spans may be omitted locally; -- Studio must not disable all inline hints for a document solely because some hint spans are unavailable. - -## Structural Anchor Semantic Surface - -Exact structural anchoring for editor scope indicators must not be overloaded into `documentSymbols`. - -`documentSymbols` remains the outline and navigation surface. - -Guide-oriented structure must be exposed through a dedicated semantic surface for structural anchors and related guide metadata. - -That dedicated surface must be frontend-owned and language-agnostic. - -The contract must describe generic structural positions rather than PBS-specific brace semantics. - -The surface must be able to represent structures whose boundaries are expressed by: - -- braces; -- keywords; -- indentation-derived blocks; -- or mixed delimiter schemes. - -At minimum, the dedicated structural-anchor surface must be able to communicate: - -- structural ranges that can participate in active-scope selection; -- immediate parentage or equivalent information needed to recover the nearest ancestor relationship; -- exact structural anchor positions used for guide start and end placement; -- enough structural identity to distinguish the active structural range from its immediate container. - -The semantic-read contract must not require Studio to scan source text in order to discover the final structural anchor positions. - -Temporary local heuristics may exist only as development aids. They must not become the canonical production contract. - -The exact serialized schema of this dedicated surface may evolve in implementation plans, but any accepted schema must preserve the invariants above. - -## Packaging Rules - -The public `prometeu-lsp` API should follow flat packaging similar to `prometeu-packer-api`. - -Rules: - -- public contract surfaces should remain shallow and explicit; -- packages such as `dtos`, `messages`, and `events` are the preferred shape for public API grouping where those surfaces exist; -- deep public packaging by internal implementation concern should be avoided; -- runtime or implementation layering may exist internally, but it must not leak into the public contract surface by default. - -## Non-Goals - -- frontend save policy -- completion -- rename -- code actions -- formatting -- build participation inferred from editorial snapshots -- external-editor compatibility requirements -- Studio-owned semantic hint generation - -## Exit Criteria - -This specification is complete enough when: - -- the semantic-read versus frontend-editing phase boundary is explicit, -- `prometeu-vfs` and `prometeu-lsp` ownership remains unambiguous, -- the minimum semantic capability set is explicit, -- frontend and non-frontend highlight ownership is clearly separated, -- and the excluded editing and completion capabilities remain unambiguous. diff --git a/docs/specs/studio/8. Project-Local Studio State Specification.md b/docs/specs/studio/8. Project-Local Studio State Specification.md index 70b9a703..3f50d8ff 100644 --- a/docs/specs/studio/8. Project-Local Studio State Specification.md +++ b/docs/specs/studio/8. Project-Local Studio State Specification.md @@ -22,7 +22,6 @@ This specification implements the accepted decision for project-local Studio sta It extends: - [`1. Studio Shell and Workspace Layout Specification.md`](1.%20Studio%20Shell%20and%20Workspace%20Layout%20Specification.md) -- [`5. Code Editor Workspace Specification.md`](5.%20Code%20Editor%20Workspace%20Specification.md) ## Core Rules @@ -31,7 +30,7 @@ It extends: 3. The main session-restoration store MUST remain a single file at `.studio/state.json`. 4. The main session-restoration store MUST be versioned. 5. The main session-restoration store MUST load when the project session opens. -6. Restorable shell and editor state accepted by this wave MUST restore when the project shell mounts. +6. Restorable shell state accepted by this wave MUST restore when the project shell mounts. 7. The main session-restoration store MUST save when the project shell or project session closes. 8. Missing, invalid, or schema-incompatible session-restoration state MUST fall back to safe default values and MUST NOT block project open. 9. Project-local setup configuration MUST live in a separate file at `.studio/setup.json`. @@ -44,13 +43,11 @@ The main session-restoration store MUST include: - `shellLayout` - `openShellState` -- `editorRestoration` Wave-1 accepted meaning is: -- `shellLayout`: restorable layout state already accepted by implementation, including divider positions and equivalent layout proportions for accepted workspaces such as `Assets` and `Code Editor`, `Project Navigator` expansion state, and editor dock-panel open/closed plus restored-size configuration; +- `shellLayout`: restorable layout state already accepted by implementation, including divider positions and equivalent layout proportions for accepted workspaces such as `Assets`; - `openShellState`: which workspace or equivalent shell-owned project view was open; -- `editorRestoration`: open editor tabs and active tab. ## Project-Local Setup Configuration @@ -61,8 +58,8 @@ Rules: - project-local setup MUST live in `.studio/setup.json`; - project-local setup MUST be treated as project configuration rather than session state; - project-local setup MAY contain runtime-oriented values such as the Prometeu runtime path; -- project-local setup MUST own the project-wide editor indentation policy; -- the editor indentation policy MUST define at least indentation mode and indentation width; +- project-local setup MAY continue carrying project-wide indentation policy defaults for future code-tooling integrations; +- the indentation policy MUST define at least indentation mode and indentation width; - when setup does not provide an explicit indentation policy, consumers MUST resolve it to `spaces` with width `4`; - project-local setup MAY grow with additional manual or automatic configuration keys over time; - consumers such as `Play` MUST read project-local setup from the dedicated setup file rather than from `.studio/state.json`; diff --git a/docs/specs/studio/README.md b/docs/specs/studio/README.md index 67aa024e..affec2d3 100644 --- a/docs/specs/studio/README.md +++ b/docs/specs/studio/README.md @@ -54,10 +54,7 @@ The current Studio core corpus is: 2. [`2. Studio UI Foundations Specification.md`](2.%20Studio%20UI%20Foundations%20Specification.md) 3. [`3. Studio Components Module Specification.md`](3.%20Studio%20Components%20Module%20Specification.md) 4. [`4. Assets Workspace Specification.md`](4.%20Assets%20Workspace%20Specification.md) -5. [`5. Code Editor Workspace Specification.md`](5.%20Code%20Editor%20Workspace%20Specification.md) -6. [`6. Project Document VFS Specification.md`](6.%20Project%20Document%20VFS%20Specification.md) -7. [`7. Integrated LSP Semantic Read Phase Specification.md`](7.%20Integrated%20LSP%20Semantic%20Read%20Phase%20Specification.md) -8. [`8. Project-Local Studio State Specification.md`](8.%20Project-Local%20Studio%20State%20Specification.md) +5. [`8. Project-Local Studio State Specification.md`](8.%20Project-Local%20Studio%20State%20Specification.md) ## Reading Order @@ -67,19 +64,14 @@ Recommended order: 2. shared UI foundations; 3. components module policy; 4. assets workspace behavior; -5. project document VFS boundary; -6. code editor workspace behavior; -7. integrated LSP semantic-read behavior; -8. project-local Studio state behavior. +5. project-local Studio state behavior. ## Current Wave Notes -The current `Code Editor` wave is not globally read-only anymore. +The embedded Studio code-editor stack was removed by `DEC-0031`. Normative reminders: -- editable scope is limited to supported non-frontend textual documents classified by `prometeu-vfs`; -- frontend-scoped supported documents remain hard `read-only`; -- the editor-local `Save` and `Save All` surfaces belong to the `Code Editor` workspace rather than the shell; -- editorial in-memory snapshots remain outside build-facing state; -- frontend semantic-read capability lands before any frontend editing release and is documented by the integrated LSP phase specification. +- the active Studio workspace corpus is `Assets`, `Debug`, and `Shipper`; +- project-local Studio session state remains normative and is owned by `StudioProjectSession`; +- any future external-editor backend or replacement language-service architecture requires a new accepted decision before new Studio specs are introduced. diff --git a/prometeu-studio/src/main/java/p/studio/utilities/i18n/I18n.java b/prometeu-studio/src/main/java/p/studio/utilities/i18n/I18n.java index 6eb889dc..b423f17b 100644 --- a/prometeu-studio/src/main/java/p/studio/utilities/i18n/I18n.java +++ b/prometeu-studio/src/main/java/p/studio/utilities/i18n/I18n.java @@ -78,38 +78,6 @@ public enum I18n { TOOLBAR_STOP("toolbar.stop"), TOOLBAR_EXPORT("toolbar.export"), - WORKSPACE_CODE("workspace.code"), - CODE_EDITOR_NAVIGATOR_TITLE("codeEditor.navigator.title"), - CODE_EDITOR_NAVIGATOR_REFRESH("codeEditor.navigator.refresh"), - CODE_EDITOR_NAVIGATOR_REVEAL_ACTIVE("codeEditor.navigator.revealActive"), - CODE_EDITOR_NAVIGATOR_PLACEHOLDER("codeEditor.navigator.placeholder"), - CODE_EDITOR_NAVIGATOR_DETAIL("codeEditor.navigator.detail"), - CODE_EDITOR_OUTLINE_TITLE("codeEditor.outline.title"), - CODE_EDITOR_OUTLINE_PLACEHOLDER("codeEditor.outline.placeholder"), - CODE_EDITOR_OUTLINE_SYMBOLS("codeEditor.outline.symbols"), - CODE_EDITOR_OUTLINE_EMPTY_SYMBOLS("codeEditor.outline.emptySymbols"), - CODE_EDITOR_HELPER_TITLE("codeEditor.helper.title"), - CODE_EDITOR_HELPER_PLACEHOLDER("codeEditor.helper.placeholder"), - CODE_EDITOR_HELPER_DIAGNOSTICS("codeEditor.helper.diagnostics"), - CODE_EDITOR_HELPER_EMPTY_DIAGNOSTICS("codeEditor.helper.emptyDiagnostics"), - CODE_EDITOR_TABS_PLACEHOLDER("codeEditor.tabs.placeholder"), - CODE_EDITOR_TABS_OVERFLOW("codeEditor.tabs.overflow"), - CODE_EDITOR_STATUS_BREADCRUMB("codeEditor.status.breadcrumb"), - CODE_EDITOR_STATUS_POSITION("codeEditor.status.position"), - CODE_EDITOR_STATUS_LINE_SEPARATOR("codeEditor.status.lineSeparator"), - CODE_EDITOR_STATUS_INDENTATION("codeEditor.status.indentation"), - CODE_EDITOR_STATUS_LANGUAGE("codeEditor.status.language"), - CODE_EDITOR_COMMAND_SAVE("codeEditor.command.save"), - CODE_EDITOR_COMMAND_SAVE_ALL("codeEditor.command.saveAll"), - CODE_EDITOR_CLOSE_DIRTY_TITLE("codeEditor.closeDirty.title"), - CODE_EDITOR_CLOSE_DIRTY_MESSAGE("codeEditor.closeDirty.message"), - CODE_EDITOR_CLOSE_DIRTY_SAVE("codeEditor.closeDirty.save"), - CODE_EDITOR_CLOSE_DIRTY_DISCARD("codeEditor.closeDirty.discard"), - CODE_EDITOR_CLOSE_DIRTY_CANCEL("codeEditor.closeDirty.cancel"), - CODE_EDITOR_WARNING_FRONTEND_READ_ONLY("codeEditor.warning.frontendReadOnly"), - CODE_EDITOR_UNSUPPORTED_FILE_TITLE("codeEditor.unsupportedFile.title"), - CODE_EDITOR_UNSUPPORTED_FILE_MESSAGE("codeEditor.unsupportedFile.message"), - WORKSPACE_SHIPPER("workspace.shipper"), WORKSPACE_SHIPPER_LOGS("workspace.shipper.logs"), WORKSPACE_SHIPPER_BUTTON_RUN("workspace.shipper.button.run"), diff --git a/prometeu-studio/src/main/resources/i18n/messages.properties b/prometeu-studio/src/main/resources/i18n/messages.properties index d0bb1aa4..0df5cfe4 100644 --- a/prometeu-studio/src/main/resources/i18n/messages.properties +++ b/prometeu-studio/src/main/resources/i18n/messages.properties @@ -3,7 +3,7 @@ app.projectTitle=Prometeu Studio - {0} shield.loadingProject=Loading project {0}... shield.version=Version {0} shield.status.indexing=Indexing sources and restoring services... -shield.status.restoring=Restoring workspace surfaces and editor state... +shield.status.restoring=Restoring workspace surfaces and project state... shield.phase.indexing=Indexing shield.phase.preparing=Preparing UI shield.phase.restoring=Restoring State @@ -69,37 +69,6 @@ wizard.error.indentationRequired=Indentation width must be selected. toolbar.play=Play toolbar.stop=Stop toolbar.export=Export -workspace.code=Code -codeEditor.navigator.title=Project Navigator -codeEditor.navigator.refresh=Refresh -codeEditor.navigator.revealActive=Reveal active file -codeEditor.navigator.placeholder=Project navigation lands in the next implementation slice. -codeEditor.navigator.detail=This first shell reserves the full navigator surface, its refresh action, and the left-column composition without wiring project-tree data yet. -codeEditor.outline.title=Outline -codeEditor.outline.placeholder=Open a frontend document to inspect semantic symbols. -codeEditor.outline.symbols=Symbols -codeEditor.outline.emptySymbols=No semantic symbols are currently available for the active frontend document. -codeEditor.helper.title=Editor Helper -codeEditor.helper.placeholder=Open a frontend document to inspect semantic diagnostics. -codeEditor.helper.diagnostics=Diagnostics -codeEditor.helper.emptyDiagnostics=No diagnostics for the active frontend document. -codeEditor.tabs.placeholder=no-file-open.txt -codeEditor.tabs.overflow=More -codeEditor.status.breadcrumb=proj > src > file.pbs -codeEditor.status.position=L:C -codeEditor.status.lineSeparator=LF -codeEditor.status.indentation=Spaces: 4 -codeEditor.status.language=Text -codeEditor.command.save=Save -codeEditor.command.saveAll=Save All -codeEditor.closeDirty.title=Unsaved changes -codeEditor.closeDirty.message=Save changes to {0} before closing? -codeEditor.closeDirty.save=Save -codeEditor.closeDirty.discard=Discard -codeEditor.closeDirty.cancel=Cancel -codeEditor.warning.frontendReadOnly=This frontend file is read-only in this wave. It cannot be edited or saved yet. -codeEditor.unsupportedFile.title=Unsupported file -codeEditor.unsupportedFile.message=This file is not supported in this wave: {0} workspace.shipper=Shipper workspace.shipper.logs=Logs workspace.shipper.button.run=Build diff --git a/prometeu-studio/src/main/resources/i18n/messages_pt_BR.properties b/prometeu-studio/src/main/resources/i18n/messages_pt_BR.properties index 71ec4f02..5e00b3ed 100644 --- a/prometeu-studio/src/main/resources/i18n/messages_pt_BR.properties +++ b/prometeu-studio/src/main/resources/i18n/messages_pt_BR.properties @@ -12,7 +12,6 @@ toolbar.play=Executar toolbar.stop=Parar toolbar.export=Exportar -workspace.code=Código workspace.shipper=Empacotador workspace.shipper.logs=Logs workspace.shipper.button.run=Construir diff --git a/prometeu-studio/src/main/resources/themes/default-prometeu.css b/prometeu-studio/src/main/resources/themes/default-prometeu.css index 3e5910ab..c98780ff 100644 --- a/prometeu-studio/src/main/resources/themes/default-prometeu.css +++ b/prometeu-studio/src/main/resources/themes/default-prometeu.css @@ -352,24 +352,6 @@ -fx-background-color: #17191d; } -.editor-workspace { - -fx-background-color: #15181d; -} - -.editor-workspace-layout { - -fx-padding: 16; - -fx-background-color: #15181d; -} - -.editor-workspace-split { - -fx-background-color: transparent; -} - -.editor-workspace-split > .split-pane-divider { - -fx-background-color: transparent; - -fx-padding: 0 8 0 8; -} - .workspace-dock-split { -fx-background-color: transparent; } @@ -386,544 +368,6 @@ -fx-padding: 0; } -.editor-workspace-left-column, -.editor-workspace-center-column { - -fx-spacing: 12; -} - -.editor-workspace-panel { - -fx-background-color: #1b1f25; - -fx-background-radius: 12; - -fx-border-radius: 12; - -fx-border-color: #2a313c; -} - -.editor-workspace-panel-header { - -fx-alignment: center-left; -} - -.editor-workspace-header-icon-button { - -fx-background-color: transparent; - -fx-border-color: transparent; - -fx-background-radius: 4; - -fx-border-radius: 4; - -fx-padding: 6; -} - -.editor-workspace-header-icon-button:hover { - -fx-background-color: #243243; - -fx-border-color: #556f8b; -} - -.editor-workspace-panel-content { - -fx-padding: 6 0 0 0; -} - -.editor-workspace-panel-title { - -fx-text-fill: #eff5fb; - -fx-font-size: 14px; - -fx-font-weight: bold; -} - -.editor-workspace-placeholder { - -fx-text-fill: #c3cfdb; - -fx-font-size: 12px; -} - -.editor-workspace-placeholder-detail { - -fx-text-fill: #8896a7; - -fx-font-size: 11px; -} - -.editor-workspace-navigator-panel { - -fx-min-height: 320px; -} - -.editor-workspace-tree { - -fx-background-color: transparent; - -fx-border-color: transparent; -} - -.editor-workspace-tree .tree-cell { - -fx-background-color: transparent; - -fx-text-fill: #d6e0ea; - -fx-font-size: 14px; - -fx-padding: 4 6 4 4; -} - -.editor-workspace-tree .tree-cell:selected { - -fx-background-color: #24415e; - -fx-text-fill: #ffffff; -} - -.editor-workspace-tree .tree-disclosure-node { - -fx-padding: 0 4 0 0; -} - -.editor-workspace-tree .tree-disclosure-node .arrow { - -fx-background-color: #8ea4ba; -} - -.editor-workspace-tree .tree-cell:selected .tree-disclosure-node .arrow { - -fx-background-color: #e8f3ff; -} - -.editor-workspace-tree-cell-tagged { - -fx-font-weight: bold; -} - -.editor-workspace-tree-cell-root { - -fx-font-weight: bold; - -fx-text-fill: #f4f8fc; -} - -.editor-workspace-icon { - -fx-min-width: 14; - -fx-min-height: 14; - -fx-pref-width: 14; - -fx-pref-height: 14; - -fx-max-width: 14; - -fx-max-height: 14; - -fx-alignment: center; -} - -.editor-workspace-icon-shape { - -fx-scale-x: 0.88; - -fx-scale-y: 0.88; -} - -.editor-workspace-icon-folder-default { - -fx-fill: #8792a1; -} - -.editor-workspace-icon-folder-source { - -fx-fill: #4ea0ef; -} - -.editor-workspace-icon-folder-build { - -fx-fill: #d88a3d; -} - -.editor-workspace-icon-file { - -fx-fill: #b0bac6; -} - -.editor-workspace-icon-cog { - -fx-fill: #c6d0da; -} - -.editor-workspace-icon-refresh { - -fx-fill: #eff5fb; -} - -.editor-workspace-icon-target { - -fx-fill: #eff5fb; -} - -.editor-workspace-icon-lock-closed { - -fx-fill: #f6d78f; -} - -.editor-workspace-icon-lock-open { - -fx-fill: #bde7c7; -} - -.editor-workspace-outline-panel { - -fx-min-height: 0; -} - -.editor-workspace-outline-scroll { - -fx-background-color: transparent; - -fx-background-insets: 0; -} - -.editor-workspace-outline-scroll > .viewport { - -fx-background-color: transparent; -} - -.editor-workspace-outline-summary { - -fx-text-fill: #dce6f0; -} - -.editor-workspace-outline-section-title { - -fx-font-size: 11px; - -fx-font-weight: 700; - -fx-text-fill: #8fb1d2; - -fx-padding: 4 0 0 0; -} - -.editor-workspace-outline-list { - -fx-spacing: 6; -} - -.editor-workspace-outline-item { - -fx-text-fill: #d7e2ec; - -fx-font-size: 12px; -} - -.editor-workspace-outline-diagnostic-error { - -fx-text-fill: #ff9a9a; -} - -.editor-workspace-outline-diagnostic-warning { - -fx-text-fill: #f6d78f; -} - -.editor-workspace-tab-strip { - -fx-padding: 8 12 8 12; - -fx-background-color: #1b1f25; - -fx-background-radius: 0; - -fx-border-radius: 0; - -fx-border-color: #2a313c; -} - -.editor-workspace-code-area { - -fx-background-color: #171c22; - -fx-font-size: 15px; - -fx-highlight-fill: #26405c; - -fx-highlight-text-fill: #eef4fb; -} - -.editor-workspace-tab-button { - -fx-background-radius: 0; - -fx-border-radius: 0; - -fx-padding: 0 8 0 12; - -fx-alignment: center-left; - -fx-font-size: 12px; - -fx-background-color: #20262f; - -fx-border-color: #343f4d; - -fx-border-width: 1; - -fx-text-fill: #d6dde6; -} - -.editor-workspace-tab-content { - -fx-spacing: 8; - -fx-alignment: center-left; -} - -.editor-workspace-tab-label { - -fx-alignment: center-left; - -fx-font-size: 12px; -} - -.editor-workspace-tab-dirty-indicator { - -fx-background-color: #d9e3ef; - -fx-background-radius: 999; - -fx-border-radius: 999; - -fx-opacity: 0.9; -} - -.editor-workspace-tab-close-chip { - -fx-alignment: center; - -fx-background-color: #131820; - -fx-background-radius: 999; - -fx-border-color: #485667; - -fx-border-radius: 999; - -fx-border-width: 1; - -fx-padding: 0; - -fx-cursor: hand; -} - -.editor-workspace-tab-close-icon { - -fx-fill: transparent; - -fx-stroke: #cfd8e2; - -fx-stroke-width: 1.1; -} - -.editor-workspace-tab-button-active { - -fx-background-color: #16283d; - -fx-border-color: #8fc4f2 #516579 #516579 #516579; - -fx-border-width: 3 1 1 1; - -fx-text-fill: #ffffff; - -fx-font-weight: bold; -} - -.editor-workspace-tab-button-read-only { - -fx-background-color: #252b34; - -fx-border-color: #47515d; - -fx-text-fill: #d9dee5; -} - -.editor-workspace-tab-button-read-only .editor-workspace-tab-label { - -fx-text-fill: #d9dee5; -} - -.editor-workspace-tab-button-read-only .editor-workspace-tab-dirty-indicator { - -fx-background-color: #d9dee5; -} - -.editor-workspace-tab-button-read-only .editor-workspace-tab-close-icon { - -fx-stroke: #d9dee5; -} - -.editor-workspace-tab-button-read-only .editor-workspace-tab-close-chip { - -fx-background-color: #171c23; - -fx-border-color: #4f5b68; -} - -.editor-workspace-tab-button-read-only:hover { - -fx-background-color: #2b323d; - -fx-border-color: #5b6878; - -fx-text-fill: #eff4fa; -} - -.editor-workspace-tab-button-read-only:hover .editor-workspace-tab-label { - -fx-text-fill: #eff4fa; -} - -.editor-workspace-tab-button-read-only:hover .editor-workspace-tab-dirty-indicator { - -fx-background-color: #eff4fa; -} - -.editor-workspace-tab-button-read-only:hover .editor-workspace-tab-close-chip { - -fx-background-color: #1c232c; - -fx-border-color: #6b7989; -} - -.editor-workspace-tab-button-read-only:hover .editor-workspace-tab-close-chip:hover { - -fx-background-color: #2a3440; - -fx-border-color: #90a2b5; -} - -.editor-workspace-tab-button-read-only:hover .editor-workspace-tab-close-chip:hover .editor-workspace-tab-close-icon { - -fx-stroke: #f7fbff; -} - -.editor-workspace-tab-button-read-only:hover .editor-workspace-tab-close-chip:pressed { - -fx-background-color: #364351; - -fx-border-color: #a8bbce; -} - -.editor-workspace-tab-button-read-only.editor-workspace-tab-button-active { - -fx-background-color: #16283d; - -fx-border-color: #8fc4f2 #516579 #516579 #516579; - -fx-border-width: 3 1 1 1; - -fx-text-fill: #ffffff; - -fx-font-weight: bold; -} - -.editor-workspace-tab-button-read-only.editor-workspace-tab-button-active:hover { - -fx-background-color: #1c3148; - -fx-border-color: #a7d7ff #5c738b #5c738b #5c738b; -} - -.editor-workspace-tab-button-editable { - -fx-background-color: #203226; - -fx-border-color: #4d6f58; - -fx-text-fill: #e8f6eb; -} - -.editor-workspace-tab-button-editable .editor-workspace-tab-label { - -fx-text-fill: #e8f6eb; -} - -.editor-workspace-tab-button-editable .editor-workspace-tab-dirty-indicator { - -fx-background-color: #b9f0c7; -} - -.editor-workspace-tab-button-editable .editor-workspace-tab-close-icon { - -fx-stroke: #e8f6eb; -} - -.editor-workspace-tab-button-editable .editor-workspace-tab-close-chip { - -fx-background-color: #15211a; - -fx-border-color: #557363; -} - -.editor-workspace-tab-button-editable:hover { - -fx-background-color: #29412f; - -fx-border-color: #6f957a; - -fx-text-fill: #f4fff5; -} - -.editor-workspace-tab-button-editable:hover .editor-workspace-tab-label { - -fx-text-fill: #f4fff5; -} - -.editor-workspace-tab-button-editable:hover .editor-workspace-tab-dirty-indicator { - -fx-background-color: #f4fff5; -} - -.editor-workspace-tab-button-editable:hover .editor-workspace-tab-close-chip { - -fx-background-color: #192720; - -fx-border-color: #789886; -} - -.editor-workspace-tab-button-editable:hover .editor-workspace-tab-close-chip:hover { - -fx-background-color: #27382d; - -fx-border-color: #9fc0ac; -} - -.editor-workspace-tab-button-editable:hover .editor-workspace-tab-close-chip:hover .editor-workspace-tab-close-icon { - -fx-stroke: #ffffff; -} - -.editor-workspace-tab-button-editable:hover .editor-workspace-tab-close-chip:pressed { - -fx-background-color: #314739; - -fx-border-color: #b2d2bf; -} - -.editor-workspace-tab-button-editable.editor-workspace-tab-button-active { - -fx-background-color: #1d3a2a; - -fx-border-color: #8ad3a2 #587464 #587464 #587464; - -fx-border-width: 3 1 1 1; - -fx-text-fill: #ffffff; - -fx-font-weight: bold; -} - -.editor-workspace-tab-button-active .editor-workspace-tab-label { - -fx-text-fill: #ffffff; - -fx-font-weight: bold; -} - -.editor-workspace-tab-button-active .editor-workspace-tab-dirty-indicator { - -fx-background-color: #ffffff; -} - -.editor-workspace-tab-button-active .editor-workspace-tab-close-icon { - -fx-stroke: #ffffff; -} - -.editor-workspace-tab-button-active .editor-workspace-tab-close-chip { - -fx-background-color: rgba(255, 255, 255, 0.08); - -fx-border-color: rgba(255, 255, 255, 0.22); -} - -.editor-workspace-tab-button-active:hover .editor-workspace-tab-close-chip:hover { - -fx-background-color: rgba(255, 255, 255, 0.18); - -fx-border-color: rgba(255, 255, 255, 0.42); -} - -.editor-workspace-tab-button-active:hover .editor-workspace-tab-close-chip:pressed { - -fx-background-color: rgba(255, 255, 255, 0.28); - -fx-border-color: rgba(255, 255, 255, 0.56); -} - -.editor-workspace-tab-button-editable.editor-workspace-tab-button-active:hover { - -fx-background-color: #234532; - -fx-border-color: #a5efbd #688676 #688676 #688676; -} - - -.editor-workspace-tab-overflow { - -fx-background-radius: 0; - -fx-border-radius: 0; - -fx-padding: 0 12 0 12; - -fx-min-width: 128; - -fx-pref-width: 128; - -fx-max-width: 128; - -fx-min-height: 34; - -fx-pref-height: 34; - -fx-max-height: 34; -} - -.editor-workspace-tab-overflow-item { - -fx-text-fill: #d9e2eb; - -fx-font-size: 12px; - -fx-padding: 0 10 0 10; - -fx-background-color: transparent; -} - -.editor-workspace-code-area .content { - -fx-background-color: #171c22; -} - -.editor-workspace-code-area .paragraph-box { - -fx-background-color: #171c22; -} - -.editor-workspace-code-area .lineno { - -fx-background-color: #12161c; - -fx-text-fill: #6f7a86; - -fx-padding: 0 12 0 12; - -fx-font-family: "JetBrains Mono Medium", "JetBrains Mono", "Iosevka", "Cascadia Mono", "IBM Plex Mono", monospace; - -fx-font-size: 14px; -} - -.editor-workspace-code-area .text { - -fx-fill: #f2f6fb; - -fx-font-family: "JetBrains Mono Medium", "JetBrains Mono", "Iosevka", "Cascadia Mono", "IBM Plex Mono", monospace; - -fx-font-size: 14px; -} - -.editor-workspace-code-area .caret { - -fx-stroke: #ffd27a; -} - -.editor-workspace-editor-surface { - -fx-background-color: #171c22; - -fx-border-color: #2a313c; - -fx-border-width: 1; -} - -.editor-workspace-editor-viewport { - -fx-background-color: transparent; -} - -.editor-workspace-code-area .text.editor-inline-hint { - -fx-fill: #707070; - -rtfx-background-color: #1f242f; - -fx-font-family: "JetBrains Mono Medium", "JetBrains Mono", "Iosevka", "Cascadia Mono", "IBM Plex Mono", monospace; - -fx-font-size: 13px; -} - -.editor-workspace-code-area .text.editor-inline-hint-type { - -fx-fill: #707070; - -rtfx-background-color: #1f242f; -} - -.editor-workspace-code-area-type-text .text { - -fx-fill: #eef3f8; -} - -.editor-workspace-command-bar { - -fx-padding: 10 12 0 12; - -fx-alignment: center-left; -} - -.editor-workspace-command-button { - -fx-alignment: center; - -fx-pref-width: 118px; - -fx-min-width: 118px; -} - -.editor-workspace-warning { - -fx-alignment: center-left; - -fx-spacing: 8; - -fx-padding: 8 12 8 12; - -fx-background-color: #3b2a10; - -fx-border-color: #8f6730; - -fx-border-width: 0 0 1 0; - -fx-text-fill: #f7ddb0; - -fx-font-size: 12px; -} - -.editor-workspace-warning-counter { - -fx-text-fill: #f3d8a7; - -fx-font-size: 11px; - -fx-font-weight: 700; -} - -.editor-workspace-warning-button { - -fx-min-width: 24; - -fx-pref-width: 24; - -fx-max-width: 24; - -fx-min-height: 24; - -fx-pref-height: 24; - -fx-max-height: 24; - -fx-padding: 0; - -fx-background-color: #4b3413; - -fx-border-color: #9a7440; - -fx-text-fill: #f7ddb0; - -fx-font-size: 11px; - -fx-background-radius: 4; - -fx-border-radius: 4; -} - -.editor-workspace-warning-button:hover { - -fx-background-color: #5a4018; - -fx-border-color: #b38749; -} .workspace-dock-pane { -fx-collapsible: true; @@ -960,13 +404,6 @@ -fx-border-insets: 0; } -.editor-workspace-helper-panel { - -fx-min-height: 0; -} - -.editor-workspace-helper-summary { - -fx-text-fill: #dce6f0; -} .workspace-dock-pane-collapsed { -fx-background-insets: 0; @@ -984,107 +421,6 @@ -fx-border-insets: 0; } -.editor-workspace-status-bar { - -fx-padding: 6 12 6 12; - -fx-background-color: #1b1f25; - -fx-background-radius: 12; - -fx-border-radius: 12; - -fx-border-color: #2a313c; - -fx-min-height: 40; - -fx-pref-height: 40; - -fx-max-height: 40; -} - -.editor-workspace-status-breadcrumb { - -fx-alignment: center-left; -} - -.editor-workspace-status-breadcrumb-segment { - -fx-alignment: center-left; - -fx-padding: 0 2 0 0; -} - -.editor-workspace-status-breadcrumb-segment-root { - -fx-font-weight: bold; -} - -.editor-workspace-status-breadcrumb-text { - -fx-text-fill: #d4dde7; - -fx-font-size: 12px; -} - -.editor-workspace-status-breadcrumb-segment-root .editor-workspace-status-breadcrumb-text { - -fx-text-fill: #f1f7fd; - -fx-font-weight: bold; -} - -.editor-workspace-status-breadcrumb-separator { - -fx-text-fill: #6f7e8e; - -fx-font-size: 12px; -} - -.editor-workspace-status-chip { - -fx-background-color: #11151b; - -fx-background-radius: 4; - -fx-border-radius: 4; - -fx-border-color: #2a313c; - -fx-padding: 0 8 0 8; - -fx-text-fill: #c5d2de; - -fx-font-size: 11px; - -fx-alignment: center; - -fx-min-height: 28; - -fx-pref-height: 28; - -fx-max-height: 28; -} - -.editor-workspace-status-chip-type-text { - -fx-background-color: #11151b; - -fx-border-color: #2a313c; - -fx-text-fill: #c5d2de; -} - -.editor-workspace-status-chip-position { - -fx-min-width: 44; - -fx-pref-width: 44; - -fx-max-width: 44; -} - -.editor-workspace-status-chip-line-separator { - -fx-min-width: 44; - -fx-pref-width: 44; - -fx-max-width: 44; -} - -.editor-workspace-status-chip-indentation { - -fx-min-width: 84; - -fx-pref-width: 84; - -fx-max-width: 84; -} - -.editor-workspace-status-chip-language { - -fx-min-width: 72; - -fx-pref-width: 72; - -fx-max-width: 72; -} - -.editor-workspace-status-chip-access-mode { - -fx-min-width: 36; - -fx-pref-width: 36; - -fx-max-width: 36; - -fx-padding: 0; -} - -.editor-workspace-status-chip-read-only { - -fx-background-color: #3b2a10; - -fx-border-color: #8f6730; - -fx-text-fill: #f7ddb0; -} - -.editor-workspace-status-chip-editable { - -fx-background-color: #203226; - -fx-border-color: #5a8567; - -fx-text-fill: #ebfff0; -} .assets-workspace-split { -fx-background-color: transparent; diff --git a/prometeu-studio/src/main/resources/themes/editor/presentations/bash.css b/prometeu-studio/src/main/resources/themes/editor/presentations/bash.css deleted file mode 100644 index a3e2c6a9..00000000 --- a/prometeu-studio/src/main/resources/themes/editor/presentations/bash.css +++ /dev/null @@ -1,39 +0,0 @@ -.editor-workspace-code-area-type-bash .text { - -fx-fill: #edf2f7; -} - -.editor-workspace-code-area-type-bash .lineno { - -fx-text-fill: #788595; -} - -.editor-workspace-code-area-type-bash .text.editor-syntax-bash-shebang { - -fx-fill: #f0ae63; -} - -.editor-workspace-code-area-type-bash .text.editor-syntax-bash-comment { - -fx-fill: #7d8a98; -} - -.editor-workspace-code-area-type-bash .text.editor-syntax-bash-string { - -fx-fill: #dcbf88; -} - -.editor-workspace-code-area-type-bash .text.editor-syntax-bash-variable { - -fx-fill: #8fd4ff; -} - -.editor-workspace-code-area-type-bash .text.editor-syntax-bash-keyword { - -fx-fill: #d7a6ff; -} - -.editor-workspace-code-area-type-bash .text.editor-syntax-bash-builtin { - -fx-fill: #9fe2a0; -} - -.editor-workspace-code-area-type-bash .text.editor-syntax-bash-command { - -fx-fill: #7fc1ff; -} - -.editor-workspace-code-area-type-bash .text.editor-syntax-bash-operator { - -fx-fill: #c7d3de; -} diff --git a/prometeu-studio/src/main/resources/themes/editor/presentations/json.css b/prometeu-studio/src/main/resources/themes/editor/presentations/json.css deleted file mode 100644 index fa180ac1..00000000 --- a/prometeu-studio/src/main/resources/themes/editor/presentations/json.css +++ /dev/null @@ -1,41 +0,0 @@ -.editor-workspace-code-area-type-json { - -fx-highlight-fill: #204766; -} - -.editor-workspace-code-area-type-json .text { - -fx-fill: #dff3ff; -} - -.editor-workspace-code-area-type-json .lineno { - -fx-text-fill: #7e92a6; -} - -.editor-workspace-code-area-type-json .text.editor-syntax-json-key { - -fx-fill: #8fd4ff; -} - -.editor-workspace-code-area-type-json .text.editor-syntax-json-string { - -fx-fill: #d9c48f; -} - -.editor-workspace-code-area-type-json .text.editor-syntax-json-number { - -fx-fill: #9ee39f; -} - -.editor-workspace-code-area-type-json .text.editor-syntax-json-boolean { - -fx-fill: #f3a6d6; -} - -.editor-workspace-code-area-type-json .text.editor-syntax-json-null { - -fx-fill: #c89cff; -} - -.editor-workspace-code-area-type-json .text.editor-syntax-json-punctuation { - -fx-fill: #c8d5e2; -} - -.editor-workspace-status-chip-type-json { - -fx-background-color: #132433; - -fx-border-color: #4e88b8; - -fx-text-fill: #e2f4ff; -}