Screen: cross-repo build order and dependency map

[einari]

Tracking issue for the screen work — the UI half of the Screenplay stack, spanning six repositories. Every issue below carries the screen label in its own repo.

The work splits by lifecycle, the same way Chronicle/Arc/Components/AuthProxy already do:

• Screenplay owns the language — what a screen, form, layout, theme or ui profile can say.
• Scene owns the object model and runtime — Scene.Model (platform-agnostic), Scene.Engine (binding/resolution), Scene.React (one renderer).
• Stage owns the seam and the build — translating parsed Screenplay into Scene.Model, and producing a shipped artifact per ui profile.
• Studio owns the design-time tooling — designers built on top of Scene's object model, previewing through the unmodified Scene engine.
• Arc / Components own the form runtime the form construct ultimately compiles down to.

Build order

Waves are dependency layers, not sprints — everything inside a wave can run in parallel.

Wave 1 — foundations, nothing blocking

Issue	What
Cratis/Screenplay#94	Language construct: ui profile — the vocabulary (target platform, target size, packages) everything else layers on
Cratis/Screenplay#92	Language construct: contribution points and navigation
Cratis/Screenplay#91	Language construct: form
#1	Scene object model, and the split into Model / Engine / React
Cratis/Arc#2549	CommandForm populated at startup

ui profile and the Scene object model are the two real roots — starting anywhere else risks rework.

Wave 2

Issue	Depends on
Cratis/Screenplay#95 — layout arrangement (flow / freeform)	#94, for the size-class vocabulary
Cratis/Screenplay#96 — theme construct	#94, for the package chain it declares compatibility against
Cratis/Screenplay#93 — string resources for UI text	#92 (nav labels) — also blocked on reconciliation with the existing Internationalization construct, Cratis/Screenplay#7
Cratis/Components#133 — initial values for CommandForm	Cratis/Arc#2549
Cratis/Components#104 — dynamically populate form content	Cratis/Arc#2549
Cratis/StudioIssues#156 — editor architecture: chrome vs. preview surface	#1

Wave 3 — Scene engines

Issue	Depends on
#3 — ui profile package resolution engine	Cratis/Screenplay#94, #1
#4 — layout engine	Cratis/Screenplay#95, #1
#2 — contribution point runtime and NavBar widget	Cratis/Screenplay#92, #1

Wave 4

Issue	Depends on
#5 — theme engine	Cratis/Screenplay#96, #3 (themes resolve against the profile's package list)

Wave 5

Issue	Depends on
#6 — UI starters (kits) and sample gallery	#3, #5, #2 — the gallery is a real mini-app driven by all three

Wave 6 — Stage

Issue	Depends on
Cratis/Stage#37 — hook Screenplay's constructs into Scene's object model	#1 and every Screenplay construct it translates: #91, #92, #94, #95, #96
Cratis/Stage#39 — runtime rendering per deployment target	Cratis/Stage#37, #3, #4, #5

Wave 7 — Studio designers

All of these sit on Cratis/StudioIssues#156, which establishes that the preview surface runs the real Scene.Engine + Scene.React rather than a Studio-specific reimplementation.

Issue	Depends on
Cratis/StudioIssues#157 — form designer	Cratis/Screenplay#91; runtime via Cratis/Arc#2549, Cratis/Components#133
Cratis/StudioIssues#158 — navigation / contribution designer	#2
Cratis/StudioIssues#159 — string resource management	Cratis/Screenplay#93 (itself blocked on Cratis/Screenplay#7)
Cratis/StudioIssues#160 — ui profile and theme configuration	#3, #5 — refines the original request in Cratis/StudioIssues#80
Cratis/StudioIssues#161 — layout designer	Cratis/Screenplay#95, #4
Cratis/StudioIssues#162 — new-project wizard and gallery preview	#6

Decisions that gate more than one issue

These are open questions whose answers change work in several repos at once, so they are worth settling before the wave that consumes them starts.

• Reconciling strings with the existing Internationalization construct (Internationalization for strings Screenplay#7). Blocks Language construct: string resources for UI text (labels, nav, etc.) Screenplay#93 and, downstream, the per-locale table UI in String resource management UI StudioIssues#159. Until it lands, don't build against a shape that will move.
• Mixed arrangement per slot — can one layout use flow for most slots and freeform for one? Decided in Language construct: layout arrangement — responsive flow vs. freeform Screenplay#95; the engine (Layout engine: flow and freeform arrangement rendering #4) must not assume a layout is uniformly one mode, and the designer (Layout designer UI: flow canvas and freeform artboards StudioIssues#161) needs slot-level mode switching only if it is allowed.
• Where ui profile selection happens in the pipeline — Stage given a target profile up front and translating only what's relevant, or translating everything and letting Scene pick at runtime. Decided in Hookup Screenplay with Scene Stage#37; determines whether multi-target builds share one translation pass (Runtime rendering per deployment target (ui profile at build/run time) Stage#39).
• Gallery retention after scaffolding — decided in UI starters (kits) and their sample gallery #6, directly blocks the scaffold step of New-project wizard: starter selection and gallery preview StudioIssues#162.
• Two-axis size classes — whether ui profile states only a default class and layout owns the width × height matrix (Language construct: ui profile — platform/size targeting and component packages Screenplay#94 vs. Language construct: layout arrangement — responsive flow vs. freeform Screenplay#95). Affects where size-class computation lives in Layout engine: flow and freeform arrangement rendering #4.
• Design-mode affordances — injected by Studio's editing chrome around an untouched render, or a documented "design mode" in Scene.React (Studio editor architecture: chrome vs. preview surface StudioIssues#156). Leaning toward the former; the latter would put a Studio concern inside Scene.

Not part of this

#6 (ui starter) is deliberately a packaged tooling artifact, not a .play construct — see the out-of-scope note in Cratis/Screenplay#96. Don't reuse theme or the earlier "template" wording for it.

---

Decisions taken 2026-08-14

Scene is dual-stack: C# Scene.Model as the source of truth, with a TypeScript mirror. Scene.Engine and Scene.React are TypeScript and consume the mirror; Stage references the C# model directly, so the Screenplay → Scene seam is typed rather than serialized. Arc's proxy generator does not cover a standalone object model, so the mirror is hand-maintained behind a parity spec unless #1 decides to build a generator. Full detail in #1.

Screenplay#93 drops the inline strings block. The compiler already ships companion .strings files per locale and $strings.<key> references covering label, title and validation message. The work narrows to extending $strings. to the operands Cratis/Screenplay#92 introduces — principally navigation-item's label. This closes the reconciliation question against Cratis/Screenplay#7, so Cratis/Screenplay#93 and Cratis/StudioIssues#159 are no longer blocked on it, and Wave 2 loses a dependency.