`ui profile` and theme configuration UI

[einari]

Context

Depends on Screenplay's ui profile and theme constructs, and Scene's
package/theme resolution and compatibility engines.

Proposal

• Profile editor: platform selection, size-class target, and an ordered,
  drag-reorderable package list (order = override priority, matching the
  language semantics directly — reordering in the UI is reordering the
  packages list).
• Component name collision surfacing: when two active packages define the
  same component name, show which one currently wins (by priority) and
  flag it, rather than only warning at build time.
• Theme picker filtered by the active profile's package list — only
  themes declared compatible with all (or a sufficient subset of) the
  profile's packages appear as selectable, reusing the exact compiler
  compatibility check as the filter logic rather than duplicating it.
• Component picker (wherever a widget is inserted into a screen) should
  show which package a given component resolves from, and offer
  qualification (Internal.Widgets.TrendChart) when a bare name would be
  ambiguous.

Open questions

• None currently blocking — depends on Scene's package resolution engine
  and theme engine shipping first.

---

Dependencies

Depends on

• ui profile package resolution engine Scene#3 — package resolution; the collision surfacing and component picker read from it
• Theme engine: applying and validating theme/package compatibility Scene#5 — theme engine; the theme picker filter reuses its compatibility check rather than duplicating it
• Language construct: ui profile — platform/size targeting and component packages Screenplay#94 — ui profile construct
• Language construct: theme, with declared package compatibility Screenplay#96 — theme construct
• Screen editor: make the Scene designers editable and retire the legacy wireframe editor #156 — the editor surface this configuration UI lives in

Refines #80 — the original "UI Profile setup" request. This issue is the concrete design for it; #80 can close once this ships.

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]

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.

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

State check after the upstream deps landed (Scene#3/#5, Screenplay#94/#96 all shipped 2026-08-15): the read-only half of this already exists on main — Source/Editor/UiProfileDesigner renders the priority-ordered package list, the collision surfacing (which package wins and what it shadows, via resolveComponentName), and the theme picker filtered with Scene's own isThemeCompatible; the routed Blueprint page composes the same engines into a selectable, previewable flow. What remains needs one product decision first: who owns the stored profile — Studio persisting profile/theme edits back into the repo's .play document (Screenplay's printer supports the round trip) versus Studio holding the profile in its own model. That decision decides the shape of the State Change + State View slices; the drag-reorderable list, platform/size-class inputs and the component picker build on whichever persistence lands, and the component picker additionally wants an insertion surface (#156's editor migration).

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