UI Profile setup

[einari]

For the UI actors we need a way to configure the UI profile.
Typically what the target is; Web, Mobile, Desktop and so forth.

But also, we want to enable different UI frameworks and also UI component libraries. Once should then be able to select which one to use for the profile.

The UI profile is not the same as the actor role we associate, these are different things.

---

Dependencies

Refined by #160 — ui profile and theme configuration UI, the concrete design for this request. This issue can close once that ships.

Language side: Cratis/Screenplay#94 — the ui profile construct (target platform, size class, ordered packages list).
Resolution engine: Cratis/Scene#3.

Part of the screen work — build order and full dependency map: Cratis/Scene#7

[cratis-direct]

Thanks for opening this - it has been received and will be looked at.

---

Posted by Stagehand (AI) - an autonomous agent, not a person. Review accordingly.

[cratis-direct]

Plan

I cannot produce a concrete implementation plan for this issue in this repository.

Two blocking facts:

1. /workspace (Cratis/StudioIssues) is explicitly a code-free public issue tracker — its README states "There is no code here. Studio development happens in a private repository." There is no Studio frontend/backend source anywhere in this checkout to write a file-level plan against.
2. Issue UI Profile setup #80 itself is a high-level tracking issue, not an actionable spec. It says it is "Refined by ui profile and theme configuration UI #160 — the concrete design for this request. This issue can close once that ships," and the actual implementation is split across other (private) repos: Language construct: ui profile — platform/size targeting and component packages Screenplay#94 (the ui profile language construct — target platform, size class, ordered packages list) and ui profile package resolution engine Scene#3 (the resolution engine), under the umbrella of Screen: cross-repo build order and dependency map Scene#7.

Since I have no access to the private Studio codebase (or to Screenplay/Scene repos) and #80 defers its concrete design to #160, I have nothing to plan file-by-file changes against, and guessing at a private repo's structure would not be a confident, actionable plan.

QUESTION: Can you provide access to (or a checkout of) the private Studio repository — and clarify whether I should be planning against issue #160 (the concrete design issue) instead of #80, since #80 states it closes once #160 ships?

---

Posted by Stagehand (AI) - an autonomous agent, not a person. Review accordingly.

[cratis-direct]

Plan

Correction to the previous run

The prior attempt's blocking premise was wrong: it claimed /workspace was Cratis/StudioIssues (a "code-free tracker"). It is actually Cratis/Studio — the real, full private codebase (Source/, Studio.slnx, etc.), confirmed via git remote -v (/repos/Cratis/Studio.git). The mistaken QUESTION comment it left on issue #80 should be disregarded; no repository access is missing.

Better still, StudioIssues#160 (the concrete design issue #80 defers to) already has a partial, merged, tested implementation on main, in Source/Editor/UiProfileDesigner/ and Source/Editor/BlueprintPreview/, with its own scope boundary documented in Source/Editor/README.md. This plan closes the documented gaps.

Current state (verified in code)

• UiProfileDesigner.tsx renders the package list (read-only order), component-name collisions (findComponentCollisions, reusing Scene's resolveComponentName), and a compatible-theme picker (filterCompatibleThemes, reusing isThemeCompatible) — but is not wired into any route. It only has Vitest specs.
• The only reachable route today, /projects/:projectId/application/:applicationId/blueprint (BlueprintPage.tsx → BlueprintPreviewPage), is an explicitly backend-free, unpersisted package-compatibility sandbox — by design it doesn't read or reflect a real project's actual ui profile.
• Entirely unbuilt anywhere: platform selection and size-class target display/editing (UiProfile.targetPlatform / .defaultSizeClass exist on the model but no UI touches them).
• Documented as deliberately deferred in the README: package-list drag/drop reordering, and the component picker (search/insert, showing source package + qualification).
• The backend already has everything needed to compile an application's real .play source into a SceneApplication (IApplicationSourceFiles + IScreenplayFolderMerger/MergeScreenplayFolder + IScreenplaySceneParser/PreviewScreenplayScene), but nothing composes those three to answer "what is this application's current ui profile" — that composition doesn't exist yet.

Plan

1. Backend — compile the application's current Scene model (unblocks everything else)

• New sibling file to PreviewScreenplayScene.cs: Source/Core/Projects/Applications/Screens/Previewing/CompileApplicationScene.cs. [Command] record CompileApplicationScene(ApplicationId ApplicationId) with Handle(IApplicationSourceFiles, IScreenplayFolderMerger, IScreenplaySceneParser): list .play files → merge → parse → return the existing ScreenplayScenePreview shape. Pure composition of three existing collaborators, no new algorithm — matches this codebase's established pattern for every partial slice so far.
• Specs in a new when_compiling_the_current_scene/ folder (valid source, compile errors, zero .play files → a clear empty state, not a validation error).
• Gate: dotnet build (Debug, regenerates the TS proxy) + dotnet test.

2. Frontend — wire a real, per-application UI Profiles route

• New Source/Core/Projects/Applications/UiProfiles/UiProfilesPage.tsx: calls the new proxy, renders UiProfileDesigner (from @cratis/studio.editor) per declared profile, with explicit empty/error states from real compiler diagnostics (no placeholder UI).
• Route: add a lazy-loaded <Route path='ui-profiles'> in ApplicationContainer.tsx, mirroring BlueprintPage's registration.
• Drawer node: extend ProjectNodeKind (ProjectNode.ts), add the entry in buildApplicationChildren (HierarchyTreeView.helpers.ts), and the exhaustive nodeKindHasView record (compiler-enforced).
• New strings.uiProfiles.* resource entries mirroring strings.blueprintPreview.*.

3. UiProfileDesigner — platform + size-class section (closes the first, currently 0%-built proposal bullet)

• Add a "Profile" section rendering name/targetPlatform/defaultSizeClass/layout; a profile switcher if an application declares more than one UiProfile.
• Verify at implementation time: exact shape of @cratis/scene.model's SizeClass (not inspectable here — no node_modules installed in this sandbox).

4. UiProfileDesigner — package list reordering

• Pure helper reorderPackages(packages, fromIndex, toIndex) + spec, native HTML5 drag/drop on the <li> rows, onPackagesReordered callback.
• Constraint to state plainly: there is no round-trip write path from a compiled SceneApplication back into .play source anywhere in Studio (the same gap already flagged for String resource management UI #159's "extract to resource"). Reordering here is necessarily a live preview of a different priority, not a persisted edit, unless a source-rewrite engine is separately built — that's out of scope for UI Profile setup #80/ui profile and theme configuration UI #160.

5. Component picker (search/insert, source package + qualification)

• Its real home — wherever a widget is inserted into a screen — doesn't exist yet (depends on Screen editor: make the Scene designers editable and retire the legacy wireframe editor #156's still-pending PreviewSurface/chrome migration). Build the host-agnostic logic + presentational picker now (same precedent as every other partial slice): searchComponentNames(query, catalog, profile) reusing resolveComponentName, plus a presentational ComponentPicker with an onComponentSelected callback. Document the remaining integration gap explicitly, same style as the README already does elsewhere.

6. Hygiene: update Source/Editor/README.md's #160 section and spec count; update Source/Editor/index.ts barrel exports.

Ordering: (1) → (2) build gate before frontend touches the new proxy; (3) and (4) have no backend dependency and can proceed in parallel with (1); (5) is independent; (6) last. Land as one PR, commits split per unit above, labeled minor.

Explicitly out of scope (matches already-documented boundaries elsewhere in this codebase): real drag/drop composition onto PreviewSurface; persisting any edit back into .play source; the theme token model and PrimeReact styling gaps (flagged Scene-side); any change to the published @cratis/scene.* packages themselves.

---

Posted by Stagehand (AI) - an autonomous agent, not a person. Review accordingly.

[woksin]

Program kickoff and scoping have started locally as part of the coordinated end-to-end Screenplay/Stage/Studio/CLI delivery effort tracked in Cratis/Screenplay#174. This issue is in a later/nonblocking lane, not a prerequisite for the first deterministic backend delivery. @woksin is coordinating in dependency order with repository-specific AI corpus instructions and specifications. Existing work/PRs will be reconciled rather than duplicated. This is a kickoff, not a completion claim or a claim that a coding branch exists for this issue; focused progress, verification evidence and blockers will follow here.

[einari]

Consolidated into #156.

Every upstream dependency this issue waited on has shipped (Cratis/Scene #1–#6, Cratis/Screenplay #91–#96), and the read-only half of this designer is already on Cratis/Studio@main under Source/Editor/. What remains is the same remaining work as every other designer — making the surface editable and retiring the legacy PrototypeEditor, which is one job, not eight.

#156 now tracks that, and carries a table of exactly what this issue asked for, what landed, and what is left.