Repository navigation
Screens release: prototype in Studio, author in Screenplay, run and render through Stage #7
Description
Screens release scope
Release plan derived from StudioReleaseScreens.md at the Cratis organization root. Screenplay is the source of truth for the complete application UI, not merely intent. Scene remains the rendering authority. Studio Play, cratis run, and a generated React application must realize the same modeled application.
Audited upstream main, not just the local checkouts (several were stale): Scene b6643fc, Studio 2c0f910c1, Screenplay 52a5ccb9, Stage 5a412fe, cli c3d799f, AI 6bdc80cc, Components f6efb3ac.
Already shipped foundations: Scene package resolution, layouts, contribution points, themes, recursive fitsSlot templates, descriptors/exposure/edit operations (#1–#6, #51), icon packages (#52); Studio floating editor/query binding/template selection/icons (Cratis/StudioIssues#393–#397); Screenplay forms/profiles/templates/arrangements and folder workspaces; Stage Scene translation and standalone frontend composition (Cratis/Stage#37, Cratis/Stage#100, Cratis/Stage#122); CLI file/folder run/render. These must be extended, not recreated. Closed issues are historical evidence, not new release blockers.
The old build-order section below is historical. This release section supersedes its obsolete open-decision and dependency claims. Source inspection is not a passing end-to-end test: the release closes only against the executable evidence below.
Acceptance criteria
- A master/detail business application binds a slice query to a table, binds selection to details, and authors an auto/manual multi-column CommandForm.
- Application shell → module → feature → nested feature/slice composition is recursive; optional templates, exposed inherited settings, toolbar-driven dialogs/outlets and authored URLs survive save/export/import.
- Components, styling, blueprints and icons resolve through one coherent package contract in Studio, embedded Event Models/VS Code, Stage runtime and generated React.
- An AI agent can create and modify that same multi-file application through Screenplay MCP; corpus examples compile and run.
- Studio Play uses the full surface below announcements, only the upper-right Stop/Frontend/API/Chronicle toolbar, and restores authoring chrome on Stop.
- The canonical release vector proves runtime/render behavior and CLI/Studio plan parity using the exact released package/image set; no silent fallback or dropped modeled UI.
References and dependencies
Blocked by
- Cratis/Scene#27
- Cratis/Scene#69
- Cratis/Scene#70
- Cratis/Scene#71
- Cratis/Scene#72
- Cratis/Scene#73
- Cratis/Scene#74
- Cratis/Scene#75
- Cratis/Screenplay#536
- Cratis/Screenplay#537
- Cratis/Stage#236
- Cratis/Stage#237
- Cratis/StudioIssues#156
- Cratis/StudioIssues#555
- Cratis/StudioIssues#556
- Cratis/StudioIssues#557
- Cratis/StudioIssues#558
- Cratis/StudioIssues#165
- Cratis/StudioIssues#470
- Cratis/StudioIssues#275
- Cratis/StudioIssues#502
- Cratis/StudioIssues#559
- Cratis/cli#284
- Cratis/Screenplay#168
- Cratis/Screenplay#173
- Cratis/AI#536
Release work index
| Repository | Issue | Work |
|---|---|---|
| Scene | Cratis/Scene#27 | Decide and document the component-library manifest authority across Scene and Components |
| Scene | Cratis/Scene#69 | Support typed data-context and named-component property bindings |
| Scene | Cratis/Scene#70 | Formalize package-provided component designers, property editors and design-time actions |
| Scene | Cratis/Scene#71 | Render auto and authored multi-column CommandForms through the same native form runtime |
| Scene | Cratis/Scene#72 | Add extensible template types and categories with scope-aware applicability |
| Scene | Cratis/Scene#73 | Research and ship business-application blueprints with categorized live examples |
| Scene | Cratis/Scene#74 | Resolve hierarchical navigation, authored URLs and toolbar actions into named outlets or dialogs |
| Scene | Cratis/Scene#75 | Expose a consistent frontend package-host configuration for embedded and standalone rendering |
| Screenplay | Cratis/Screenplay#536 | Express the complete screens-release UI contract across single-file and folder applications |
| Screenplay | Cratis/Screenplay#537 | Prove screen creation and editing through the existing revision-checked MCP authoring tools |
| Stage | Cratis/Stage#236 | Use one complete screen application plan for generated React and live Stage |
| Stage | Cratis/Stage#237 | Run the full modeled application through the same Scene composition as generated React |
| StudioIssues | Cratis/StudioIssues#156 | Complete the Scene-based editor with package designers and design-time actions |
| StudioIssues | Cratis/StudioIssues#555 | Author data-context and component-property bindings in the prototype inspector |
| StudioIssues | Cratis/StudioIssues#556 | Design CommandForms with auto/manual mode, generated fields and resizable columns |
| StudioIssues | Cratis/StudioIssues#557 | Replace the blueprint button dump with a categorized, scope-aware template browser |
| StudioIssues | Cratis/StudioIssues#558 | Author hierarchical navigation and toolbar slice actions with outlet/dialog destinations |
| StudioIssues | Cratis/StudioIssues#165 | Preserve the complete authored UI in Screenplay export, import and Play |
| StudioIssues | Cratis/StudioIssues#470 | Move saved screens to screen documents with an explicit data migration, not conversion on open |
| StudioIssues | Cratis/StudioIssues#275 | Use Stage's renderer instead of Studio's own |
| StudioIssues | Cratis/StudioIssues#502 | Static code generation provider: render through Stage on top of the Screenplay output |
| StudioIssues | Cratis/StudioIssues#559 | Make Play fill the workspace and move Stop/Frontend/API/Chronicle to the upper right |
| cli | Cratis/cli#284 | Pass full screen application and package configuration through run and render |
| Screenplay | Cratis/Screenplay#168 | Publish a Screenplay-owned canonical end-to-end conformance corpus |
| Screenplay | Cratis/Screenplay#173 | Prove CLI and Studio Stage-plan parity with the canonical corpus |
| AI | Cratis/AI#536 | Teach and verify end-to-end screen authoring, MCP editing and Stage runtime/render parity |
Audited source revisions
- Scene b6643fc
- Studio 2c0f910c1
- Screenplay 52a5ccb9
- Stage 5a412fe
- cli c3d799f
- AI 6bdc80cc
- Components f6efb3ac
Previous scope and historical context
The release scope above updates this issue without deleting its prior context. Completed foundations and superseded product questions are not new blockers. Existing non-screen requirements remain in scope.
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,themeorui profilecan 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 perui 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
formconstruct 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
stringswith 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
layoutuseflowfor most slots andfreeformfor one? Decided in Language construct: layout arrangement — responsiveflowvs.freeformScreenplay#95; the engine (Layout engine:flowandfreeformarrangement 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 profileselection 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 profileat 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 profilestates 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 — responsiveflowvs.freeformScreenplay#95). Affects where size-class computation lives in Layout engine:flowandfreeformarrangement rendering #4. - Design-mode affordances — injected by Studio's editing chrome around an untouched render, or a documented "design mode" in
Scene.React(Complete the Scene-based editor with package designers and design-time actions 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.
Activity
einari commentedon Aug 16, 2026
Status — 2026-08-16
Scene is published. All eight packages are on npm at
1.0.0:@cratis/scene.model,.engine,.react,.tailwind,.primereact,.components,.blueprint.default,.blueprint.components. The registry trust-policy blocker that held every publish since Scene#8 is resolved.Landed
layout, module-levelscreen templatewithfits slot,dialog template, the arrangement tree folded underarrangement, screen bodies referencingtemplate <Name>, andui profileselecting a layout beside its theme. Package validation restored at the 4.0.0 baseline in Add the application structure reference and index (part of #97) #118.ScenePackage, kindsComponentLibrary/Styling/Blueprint, declared dependencies), dependency resolution with ordering that is override priority,ScreenTemplate/DialogTemplateand the resolver that turnsfitsSlotnames into a nesting tree, plus six packages: PrimeReact (87 components, 25 credited themes), Cratis Components, Tailwind, the default blueprint (2 layouts, 8 menu modes, 23 screen + 3 dialog templates) and the Cratis Components blueprint.The vocabulary this settled on
fitsSlotnames the parent slot it fills.fitsSlot— an overlay occupies no slot.Still open
Cratis.Screenplay 2.6.0,Cratis.Scene.Model 0.7.0); both are real now, and the converters are being reworked for the 4.0.0 grammar. Stage#39 follows it.cratis-direct commentedon Aug 27, 2026
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.
einari commentedon Sep 2, 2026
One more decision for the list, surfaced by Components 4: #27 — whether a
ui profile'sComponentLibrarypackage and a ComponentsUiLibraryare one concept or two.Components 4 made the UI library a swappable runtime choice — nine primitive slots behind a versioned ABI, with
@cratis/components.primereactand@cratis/components.muiboth shipping at 4.1.1 and filling the same nine. Scene'sScenePackage/UiProfilealready models the design-time half, and the two overlap closely enough to be worth reconciling deliberately: both make package order the override priority, and both havecoreas the final fallback.It gates how Cratis/StudioIssues#160 and the resolution engine from #3 converge, rather than whether either proceeds — neither is blocked today.
woksin commentedon Sep 6, 2026
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.
woksin commentedon Sep 16, 2026
Narrow frontend progress: #38 is merged and its release is in progress; explicit queryArguments now reach registered collection queries, with affected builds, 125 component tests, lint and full JavaScript/Storybook CI verified. This is not optional-single result support or a standalone generated frontend. The next concrete gaps are #39 (keyed optional-single lookup/input behavior) and Cratis/Stage#100 (pure artifact-plan composition of existing Scene/Arc/Components/frontend-host pieces). Existing engine/translation work remains completed; do not recreate it. #27 remains the explicit presentation-library mapping decision. The old Storybook build-failure report #26 was closed against current successful CI.
woksin commentedon Sep 16, 2026
Scene v3.4.0 is now published and registry-verified. All eight npm package records report gitHead 1368cea; Cratis.Scene.Model and Cratis.Scene.Engine NuGet packages contain the same repository commit and net8/net9/net10 assemblies. The published scene.components bundle contains the explicit queryArguments forwarding/rejection implementation. This completes the narrow release from #38, not #39 optional-single lookup or Cratis/Stage#100 standalone application composition.
woksin commentedon Sep 16, 2026
v3.5.0 now publishes the host-controlled optional-single view and typed native adapters from #41, with verified package provenance and green full JavaScript/Storybook CI. #39 still owns editable parameter/commit wiring and the actual keyed-query vertical; Cratis/Stage#100 owns deterministic standalone frontend composition. Existing Scene model/engine/renderers are being reused, not replaced.
[-]Screen: cross-repo build order and dependency map[/-][+]Screens release: prototype in Studio, author in Screenplay, run and render through Stage[/+]einari commentedon Oct 8, 2026
Implementation plan
Prerequisites: Cratis/Scene#27, Cratis/Scene#69, Cratis/Scene#70, Cratis/Scene#71, Cratis/Scene#72, Cratis/Scene#73, Cratis/Scene#74, Cratis/Scene#75, Cratis/Screenplay#536, Cratis/Screenplay#537, Cratis/Stage#236, Cratis/Stage#237, Cratis/StudioIssues#156, Cratis/StudioIssues#555, Cratis/StudioIssues#556, Cratis/StudioIssues#557, Cratis/StudioIssues#558, Cratis/StudioIssues#165, Cratis/StudioIssues#470, Cratis/StudioIssues#275, Cratis/StudioIssues#502, Cratis/StudioIssues#559, Cratis/cli#284, Cratis/Screenplay#168, Cratis/Screenplay#173, Cratis/AI#536.
Use this issue as the release index. Confirm the capability matrix against StudioReleaseScreens.md and retain closed foundation links as evidence, not unfinished tasks.
Deliver in dependency order: Scene contracts/manifest decision → language and shared runtime contracts → Stage consumers and Studio authoring → MCP/AI and end-to-end parity. Independent Play chrome work can land in parallel.
Keep the linked issue table and native blocking relationships current. Validate every capability using the Screenplay-owned multi-file fixture, then run the exact released package/image matrix before marking the release complete.
Completion evidence: link implementation PRs and the tests/results for every checkbox under
## Acceptance criteria; keep release dependency links current. This is a proposed implementation plan, not a claim that the work or tests have already run.13 remaining items
einari commentedon Oct 13, 2026
Screens release - closing summary (2026-10-13)
Shipped and proven on public releases: Scene 4.22.1 (npm + NuGet), Screenplay 4.153.0 (+
Cratis.Screenplay.CanonicalCorpus4.153.0), Stage 4.93.0 (GitHub/NuGet/Docker; the CLI default image is 4.92.0), CLI 3.59.0 (GitHub + Homebrew), AI 7.46.0, Studio 0.170.1 deployed to production.Epic criteria
Screen.path/navigation hierarchy/toolbar placement -> StudioIssues#631.cratis run).screens-smokein AI CI.Final public acceptance
run-public-acceptance.shon CLI 3.59.0 +cratis/stage:4.92.0+ corpus 4.153.0 + production Studio 0.170.1: browser passed (81 assertions / 0 blockers), render-audit passed, MCP transcript passed (41 tools), Studio production vector passed (14 steps; export vs corpus 0 absent). Evidence:agents/wave2/closer2-evidence/public-acceptance-cli-3.59.0/in the screens-release worktree. Also proven on production in this pass: package-qualified component names keep a placed commandForm's place through Studio export -> Stage Play (Studio#1727, Stage #363), hostedstudio_screenplay_applywrites screens/events/observable queries (#1726, #1731), and StudioIssues#470: the production dry run found 0 items to migrate (all 144 items skip), so nothing was written.Closed with a proof comment
Scene #69, #70, #71, #73, #74, #75 (and #72) - Screenplay #168, #173, #536, #537 - Stage #236, #237 - cli #284 - AI #536 - StudioIssues #156, #275, #470, #555, #556, #557, #558, #559.
New follow-ups (labels
release+screens)