---
id: PLN-0026
ticket: studio-frontend-owned-semantic-editor-presentation
title: Propagate DEC-0012 into Studio and frontend normative specs
status: review
created: 2026-04-02
completed:
tags:
  - studio
  - editor
  - frontend
  - specs
  - semantic-highlighting
---

## Objective

Propagate `DEC-0012` into the normative documentation surfaces that define semantic editor presentation ownership, contract source, and runtime fallback behavior.

## Background

`DEC-0012` locks a new ownership model:

- frontend owns semantic vocabulary;
- frontend owns semantic presentation resources;
- `FrontendSpec` is the canonical source of the semantic presentation contract;
- LSP derives a descriptor from `FrontendSpec`;
- Studio consumes the descriptor without semantic reinterpretation;
- missing descriptor or resources degrade to no semantic highlight.

These rules must be reflected in the Studio and frontend-facing specs before implementation work proceeds.

## Scope

### Included
- Studio editor specification updates for frontend-owned semantic presentation.
- LSP semantic read phase specification updates for descriptor bridging behavior.
- Compiler/frontend specification updates that place semantic presentation contract ownership in `FrontendSpec`.
- Documentation of the runtime behavior `no contract/resource -> no highlight`.

### Excluded
- Java implementation changes.
- FE resource creation or stylesheet migration.
- Test implementation.

## Execution Steps

### Step 1 - Update Studio semantic editor ownership rules

**What:**
Update Studio specs so the editor is no longer the owner of a generic frontend semantic theme.

**How:**
Amend the Code Editor and related Studio specs to state that Studio hosts rendering only, consumes a frontend-owned descriptor, and applies no generic fallback theme.

**File(s):**
- `docs/specs/studio/5. Code Editor Workspace Specification.md`
- `docs/specs/studio/7. Integrated LSP Semantic Read Phase Specification.md`

### Step 2 - Update frontend contract ownership rules

**What:**
Document that frontend semantic presentation contract data lives in `FrontendSpec`.

**How:**
Amend compiler/frontend spec surfaces to describe `semanticKeys + resources` as frontend-owned static contract data published through `FrontendSpec`.

**File(s):**
- `docs/specs/compiler/23. Compiler Pipeline Entry Points Specification.md`
- `docs/specs/compiler-languages/pbs/README.md`
- any more specific frontend spec file that currently owns frontend metadata publication semantics

### Step 3 - Lock runtime degradation behavior in spec text

**What:**
Specify the runtime behavior when semantic presentation contract data or resources are absent.

**How:**
State normatively that Studio must continue without semantic highlight, must not surface a product-facing UI error, and may only emit normal development logs.

**File(s):**
- `docs/specs/studio/5. Code Editor Workspace Specification.md`
- `docs/specs/studio/7. Integrated LSP Semantic Read Phase Specification.md`

## Test Requirements

### Unit Tests
- No code tests in this plan.

### Integration Tests
- No runtime tests in this plan.

### Manual Verification
- Review updated spec text against every normative clause in `DEC-0012`.
- Verify no spec reintroduces a Studio-owned generic frontend theme.

## Acceptance Criteria

- [ ] Studio specs state that semantic presentation is frontend-owned.
- [ ] Specs name `FrontendSpec` as the canonical contract source.
- [ ] Specs describe the descriptor shape at a high level as `semanticKeys + resources`.
- [ ] Specs define `no contract/resource -> no highlight`.
- [ ] Specs define that no generic Studio fallback theme is allowed.

## Dependencies

- Depends on `DEC-0012`.
- Should complete before or in parallel with implementation plans so implementation follows normative text.

## Risks

- Existing spec text may still imply Studio ownership of generic frontend presentation.
- Compiler spec propagation may be underspecified if the exact frontend metadata sections are spread across multiple files.