prometeu-studio/discussion/workflow/agendas/AGD-0022-studio-frontend-editor-write-and-save-wave.md

id	discussion	ticket	title	status	created	updated	owner	tags
AGD-0022	DSC-0021	studio-frontend-editor-write-and-save-wave	Enable Frontend Editing and Save in the Studio Code Editor	accepted	2026-04-04	2026-04-04	studio	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.