prometeu-studio/discussion/workflow/plans/PLN-0019-propagate-dec-0010-into-studio-and-vfs-specs.md
2026-03-31 16:40:51 +01:00

116 lines
3.8 KiB
Markdown

---
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