102 lines
4.5 KiB
Markdown
102 lines
4.5 KiB
Markdown
---
|
|
id: PLN-0070
|
|
ticket: frontend-visual-theme-spec-and-css-retirement
|
|
title: Studio Visual Theme Adapter and CSS Retirement
|
|
status: open
|
|
created: 2026-05-06
|
|
completed:
|
|
tags: [studio, editor, presentation, theming, adapter, css-retirement]
|
|
---
|
|
|
|
## Objective
|
|
|
|
Make Studio consume the structured frontend visual contract as an adapter, remove any remaining dependency on authored frontend semantic CSS as the canonical source, and keep any host rendering mechanism clearly derivative.
|
|
|
|
## Background
|
|
|
|
`DEC-0033` locks that Studio is a rendering adapter over frontend-owned visual themes and that generated CSS is acceptable only as an adapter mechanism, not as the canonical frontend artifact.
|
|
|
|
This plan applies that rule to the Studio side of the stack.
|
|
|
|
## Scope
|
|
|
|
### Included
|
|
- Update Studio-side presentation registries or rendering services to consume structured frontend visual contract data.
|
|
- Generate or map host rendering artifacts from the structured contract if Studio still needs CSS or equivalent host render descriptors.
|
|
- Remove reliance on authored frontend semantic CSS as a direct semantic presentation contract.
|
|
- Add Studio tests proving the adapter path is derivative and deterministic.
|
|
|
|
### Excluded
|
|
- Compiler-side contract design.
|
|
- LSP transport contract design.
|
|
- VS Code adapter behavior.
|
|
|
|
## Non-Goals
|
|
|
|
- Rebuilding the deleted legacy Studio editor stack.
|
|
- Introducing Studio-owned frontend themes.
|
|
- Preserving authored semantic CSS as a parallel truth source.
|
|
|
|
## Execution Steps
|
|
|
|
### Step 1 - Update Studio presentation consumption to use the structured contract
|
|
|
|
**What:** Make Studio consume frontend-owned visual theme data instead of resource-only semantic presentation.
|
|
**How:** Update presentation registries, semantic highlighting services, or other editor-related rendering seams so they resolve structured visual theme data from the frontend description path.
|
|
**File(s):** `prometeu-studio/src/main/java/**`, any remaining editor/presentation adapter surfaces still active after cleanup.
|
|
|
|
### Step 2 - Derive host rendering artifacts from the contract
|
|
|
|
**What:** Keep Studio rendering mechanical.
|
|
**How:** If Studio still requires CSS or CSS-like structures, generate or map them from the structured frontend visual contract. The host-generated artifact MUST be clearly derivative and MUST NOT be treated as authored frontend truth.
|
|
**File(s):** `prometeu-studio/src/main/java/**`, possible theme/presentation helper modules, generated resource paths if adopted.
|
|
|
|
### Step 3 - Remove direct canonical dependence on frontend semantic CSS
|
|
|
|
**What:** Retire the old consumption model.
|
|
**How:** Remove or rewrite any code path that treats frontend semantic CSS resources as the canonical semantic presentation input. Leave only temporary compatibility or generated-output behavior if strictly needed during rollout.
|
|
**File(s):** `prometeu-studio/**`, related frontend resource loading code.
|
|
|
|
### Step 4 - Add Studio adapter conformance tests
|
|
|
|
**What:** Lock the adapter boundary.
|
|
**How:** Add tests that verify:
|
|
|
|
1. Studio consumes structured frontend visual themes,
|
|
2. token style rendering inputs are contract-derived,
|
|
3. any generated CSS is derivative,
|
|
4. Studio does not silently fall back to host-authored frontend theme logic.
|
|
|
|
**File(s):** `prometeu-studio/src/test/java/**` and any relevant integration test modules.
|
|
|
|
## Test Requirements
|
|
|
|
### Unit Tests
|
|
- Validate contract-to-rendering translation logic.
|
|
- Validate theme selection consumption on the Studio side.
|
|
|
|
### Integration Tests
|
|
- Run targeted Studio-side tests proving frontend presentation resolves from structured contract data and not from authored semantic CSS.
|
|
|
|
### Manual Verification
|
|
- Inspect the Studio path and confirm remaining CSS, if any, is generated or compatibility-only.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- [ ] Studio consumes structured frontend visual contract data.
|
|
- [ ] Any Studio-side CSS or equivalent rendering descriptor is derivative, not canonical.
|
|
- [ ] Direct canonical dependence on authored frontend semantic CSS is removed.
|
|
- [ ] Studio does not reauthor frontend visual identity locally.
|
|
|
|
## Dependencies
|
|
|
|
- `DEC-0033` accepted and normatively locked.
|
|
- `PLN-0068` for the canonical compiler/frontend contract.
|
|
- `PLN-0069` for transport of visual contract data into the host boundary.
|
|
|
|
## Risks
|
|
|
|
- Studio may still hide old CSS assumptions in helper layers unless the migration is exhaustive.
|
|
- Generated CSS can accidentally become the new silent truth source if ownership boundaries are not explicit in code and tests.
|
|
- Residual editor cleanup from earlier refactors may obscure the remaining active consumption path.
|