prometeu-studio/discussion/workflow/plans/PLN-0019-propagate-dec-0010-into-studio-and-vfs-specs.md

id	ticket	title	status	created	completed	tags
PLN-0019	studio-editor-write-wave-supported-non-frontend-files	Propagate DEC-0010 into Studio editor and VFS specs	review	2026-03-31		studio editor vfs specs write-wave

Objective

Make the controlled non-frontend write wave normative across the Studio and VFS spec corpus before code changes begin.

Background

DEC-0010 locks a new first write wave for non-frontend textual documents, keeps frontend files hard read-only, moves access policy and save ownership into prometeu-vfs, and requires a local editor command bar rather than the global shell save surface.

The current Studio/VFS specs still describe the first editor wave as read-only and do not yet express:

• canonical frontend classification through FrontendSpec.allowedExtensions,
• VFS-owned access policy,
• hard frontend read-only,
• editor-local Save and Save All,
• or the non-build editorial boundary for in-memory write snapshots.

Scope

Included

• update Studio specs to reflect the controlled write wave
• update VFS specification text for canonical frontend scope and access policy
• update spec index/read order if document ordering changes

Excluded

• code implementation
• LSP semantic-read phase wording from DEC-0011
• any frontend edit-right release

Execution Steps

Step 1 - Update the Code Editor Workspace Specification

What: Replace the current read-only-first-wave wording with the DEC-0010 controlled write-wave contract.

How: Amend the editor spec so it states:

• non-frontend supported text classes may be editable,
• frontend files remain hard read-only,
• save actions live in an editor-local command bar,
• mixed editable and read-only tabs are allowed,
• frontend warnings and status-bar presentation are explicit.

File(s):

• docs/specs/studio/5. Code Editor Workspace Specification.md

Step 2 - Update the Project Document VFS Specification

What: Make the VFS spec the normative home for access policy and canonical frontend scope.

How: Amend the VFS spec to state:

• FrontendSpec.allowedExtensions is the source of truth,
• VFS must expose a canonical frontend-compatible typeId or equivalent scope marker,
• VFS owns access policy and save for editable non-frontend documents,
• editorial snapshots stay out of build-facing state.

File(s):

• docs/specs/studio/6. Project Document VFS Specification.md

Step 3 - Update Shell-Level and Index Documentation

What: Keep the Studio spec corpus navigable after the write-wave decision lands.

How: Update any shell-level wording and read-order/index docs that still imply the editor is fully read-only.

File(s):

• docs/specs/studio/1. Studio Shell and Workspace Layout Specification.md
• docs/specs/studio/README.md

Test Requirements

Unit Tests

• none

Integration Tests

• none

Manual Verification

• verify the spec set no longer contradicts DEC-0010 on read-only versus editable scope
• verify frontend hard read-only and editor-local save surfaces are both explicit
• verify build separation for editorial snapshots is stated unambiguously

Acceptance Criteria

• Studio specs reflect the controlled non-frontend write wave
• VFS specs state FrontendSpec.allowedExtensions as source of truth for frontend scope
• editor-local Save and Save All are normatively placed in the editor, not the shell menu
• hard frontend read-only is stated consistently across Studio and VFS specs
• editorial in-memory snapshots are explicitly separated from build-facing state

Dependencies

• DEC-0010 accepted

Risks

• stale read-only wording may remain in sibling specs and confuse implementation
• weak wording around canonical frontend scope could reintroduce contract ambiguity
• editor-local save surfaces may be described inconsistently if shell docs are not updated