---
id: PLN-0019
ticket: studio-editor-write-wave-supported-non-frontend-files
title: Propagate DEC-0010 into Studio editor and VFS specs
status: done
created: 2026-03-31
completed: 2026-03-31
tags: [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