121 lines
5.3 KiB
Markdown
121 lines
5.3 KiB
Markdown
---
|
|
id: AGD-0022
|
|
discussion: DSC-0021
|
|
ticket: studio-frontend-editor-write-and-save-wave
|
|
title: Enable Frontend Editing and Save in the Studio Code Editor
|
|
status: accepted
|
|
created: 2026-04-04
|
|
updated: 2026-04-04
|
|
owner: studio
|
|
tags: [studio, editor, frontend, write, save, vfs, lsp, pbs, access-policy]
|
|
---
|
|
|
|
## Problem
|
|
|
|
The Studio Code Editor already delivers frontend semantic-read value through `prometeu-lsp`, but frontend documents are still hard `read-only`.
|
|
|
|
That leaves the FE editing wave unfinished:
|
|
|
|
- frontend files can be opened, analyzed, highlighted, and navigated;
|
|
- but they cannot be edited or saved;
|
|
- and the current contract explicitly says that FE editing requires a separate decision.
|
|
|
|
The next step is to define how FE mutation and save rights should be released without breaking the VFS/LSP/editor ownership split that the repository has already stabilized.
|
|
|
|
## Context
|
|
|
|
Domain owner: `studio`.
|
|
|
|
The current durable constraints are already clear:
|
|
|
|
1. `prometeu-vfs` owns document classification, access mode, snapshots, and save behavior;
|
|
2. `prometeu-lsp` is a semantic consumer of VFS-backed snapshots and must not absorb save or access-policy ownership;
|
|
3. Studio UI is a consumer of both boundaries and must not re-derive document rights locally;
|
|
4. frontend semantic-read was intentionally released before frontend edit rights;
|
|
5. FE edit rights now require a new explicit discussion and decision.
|
|
|
|
This means the new wave cannot be framed as “let the editor mutate text and figure out persistence later”.
|
|
If FE editing is released, it must be released through the same document-runtime owner that already controls access and save semantics.
|
|
|
|
## Open Questions
|
|
|
|
1. Should FE editing be released only together with FE save in the same wave?
|
|
2. Must FE editable snapshots remain owned by `prometeu-vfs`, exactly like non-frontend editable documents?
|
|
3. How should `prometeu-lsp` consume dirty FE snapshots after mutation: on-demand analyze only, background refresh, or both?
|
|
4. Are FE edit rights universal for all frontend-scoped supported files, or do they need an additional narrowing rule in this first FE write wave?
|
|
5. What explicit safeguards are needed so FE editing does not accidentally turn `prometeu-lsp` into the document owner?
|
|
|
|
## Options
|
|
|
|
### Option 1: Allow FE editing in the editor before FE save exists
|
|
|
|
The editor would accept FE text mutation locally, and LSP could consume that dirty text, but FE save would remain unavailable or deferred.
|
|
|
|
Tradeoffs:
|
|
|
|
- appears to unlock FE editing quickly;
|
|
- creates a half-owned document state with unclear persistence semantics;
|
|
- weakens the current VFS ownership model;
|
|
- encourages exactly the “editor mutates first, persistence later” drift the repository has avoided so far.
|
|
|
|
This option is weak and should be rejected.
|
|
|
|
### Option 2: Release FE editing and FE save together through `prometeu-vfs`
|
|
|
|
FE documents become editable only when `prometeu-vfs` can own their writable snapshots, dirty tracking, and save behavior.
|
|
The editor consumes that access mode, and `prometeu-lsp` continues to analyze VFS-backed FE snapshots as a consumer.
|
|
|
|
Tradeoffs:
|
|
|
|
- preserves the current architecture cleanly;
|
|
- avoids split-brain ownership between editor, VFS, and LSP;
|
|
- makes FE write behavior coherent on day one;
|
|
- requires a broader implementation wave than a UI-only unlock.
|
|
|
|
This is the strongest option.
|
|
|
|
### Option 3: Let `prometeu-lsp` become the temporary owner of editable FE session text
|
|
|
|
LSP would hold the live FE text state because it already consumes FE semantics, and save integration would come later.
|
|
|
|
Tradeoffs:
|
|
|
|
- seems convenient because FE semantics already live there;
|
|
- collapses semantic ownership into document ownership;
|
|
- directly conflicts with the established VFS boundary;
|
|
- would make the previous editor/VFS/LSP split editorially and architecturally inconsistent.
|
|
|
|
This option should be rejected.
|
|
|
|
## Recommendation
|
|
|
|
Adopt Option 2.
|
|
|
|
Recommended direction:
|
|
|
|
1. FE editing and FE save should be released in the same wave.
|
|
2. `prometeu-vfs` should remain the sole owner of FE writable snapshots, access mode, dirty tracking, and persistence.
|
|
3. `prometeu-lsp` should continue as a semantic consumer of VFS-backed FE snapshots, including dirty in-memory FE state.
|
|
4. Studio UI should remain a policy consumer and must not introduce FE-local save or access heuristics outside the VFS contract.
|
|
5. The first FE write wave should explicitly define scope, save semantics, user-visible access changes, and any resulting LSP refresh model.
|
|
|
|
## Next Step
|
|
|
|
If this agenda is accepted, convert it into a decision that normatively locks:
|
|
|
|
- whether FE edit and FE save release together;
|
|
- VFS ownership of FE writable snapshots and save behavior;
|
|
- LSP consumption rules for dirty FE snapshots;
|
|
- and the exact scope of the first FE write wave.
|
|
|
|
## Resolution
|
|
|
|
Accepted on 2026-04-04.
|
|
|
|
The discussion is closed with the following resolution:
|
|
|
|
1. FE editing and FE save release together in the same wave.
|
|
2. `prometeu-vfs` remains the sole owner of FE writable snapshots, access mode, dirty tracking, and persistence.
|
|
3. `prometeu-lsp` continues as a semantic consumer of VFS-backed FE snapshots, including dirty in-memory FE state, but no new LSP implementation work is part of the immediate execution wave.
|
|
4. The first FE write wave applies to all frontend-scoped supported files rather than introducing an additional narrowing rule.
|