Studio reimplements the Screenplay-to-Stage converter that Cratis.Stage.Contracts already ships

[woksin]

Cratis.Stage.Contracts — already a dependency, and shipping this since well before the Screenplay 2.x wave — contains a complete Screenplay-to-Stage converter under Cratis.Stage.Contracts.Screenplay:

ScreenplayEventModelVisitor  SliceConverter    CommandConverter       ReadModelConverter
ProjectionConverter          ProducesConverter EventConverter         SpecificationConverter
ValidationRuleConverter      SchemaSynthesizer ScreenplayExpression   DeterministicId

ScreenplayEventModelVisitor : IApplicationSyntaxVisitor<EventModel> — the exact signature of Studio's Source/Core/Screenplay/EventModelSyntaxVisitor.cs:14.

Studio never references it. It maintains roughly 530 lines doing the same job across nine files: EventModelSyntaxVisitor (26), ModuleSyntaxVisitor (27), FeatureSyntaxVisitor (26), SliceSyntaxVisitor (114), SpecificationSyntaxVisitor (71), SyntaxValidationExtensions (73), SyntaxSchemaExtensions (85), SyntaxEventReferenceExtensions (40), ScreenplayEventOwners (66).

Stage's version is ahead of Studio's

CommandConverter fills Produces and resolves the command's Identifier. EventConverter carries constraints. Studio passes Produces: [] at SliceSyntaxVisitor.cs:56 and raises a warning saying it dropped both — data the contract can already hold, dropped by code written before the contract grew the ability to hold it.

The cost is drift, and it has already happened once

Screenplay 2.x made SliceSyntax.Projections plural, so both implementations had to decide how to name a read model when a slice declares several. Stage's ReadModelConverter resolved it as projection?.ReadModel ?? query return type ?? projection?.Name ?? slice.Name. Studio's resolved it differently — meaning the same document could come back from a round trip named differently from how it went out.

Cratis/Studio#1108 aligned Studio to Stage by hand and left a comment at SliceSyntaxVisitor.ReadModelName saying "change both together or neither". A comment is the weakest available mechanism for keeping two implementations honest, and it only works for as long as someone reads it.

Suggested direction

Delete Studio's chain and call ScreenplayEventModelVisitor. This is not a pure refactor — there are two real behavioural differences to decide first:

1. Identity. Stage uses DeterministicId.From(path); Studio uses Guid.NewGuid(). Deterministic identity is arguably better, since re-importing the same document would yield the same graph rather than a new one — but it changes what an import produces.
2. Cross-slice event ownership. Studio's ScreenplayEventOwners assigns each State Change slice's events an identity up front, so a consuming slice references the producing slice's event rather than a fresh one. Stage has no equivalent and relies on path-derived determinism instead. Whether that preserves Studio's incoming arrows needs checking before anything is deleted.

Both belong in the same design conversation as Cratis/Stage#23. Worth settling before the contract widens rather than after — widening it twice, in two implementations, is how a round trip acquires its third disagreement.

[woksin]

Ran both chains over the same document to settle the two open questions before anything is deleted. The document is the language's own invoicing.play (Screenplay/Source/DotNET/Screenplay/for_ScreenplayCompiler/invoicing.play) — 17 slices, every construct the language has — put through Studio's EventModelSyntaxVisitor and Cratis.Stage.Contracts.Screenplay.ScreenplayEventModelVisitor in one process, against the Cratis.Stage.Contracts version Studio actually pins (2.0.0).

The headline: a straight swap regresses the import. Each side is ahead of the other, and the two sets do not overlap.

	Studio	Stage
slices	17	17
event definitions	48	19
…of those, carrying a SourceEventId	22	0
command Produces	0	17
command StateSchema	0	7
read models with a Schema	0	6
read models with a Projection	0	6
model name	(empty)	Invoicing
specifications	4	4
unique / unique-event-type constraints	1 / 1	1 / 1
command rules	11	15 — see below

Question 2, cross-slice event ownership, is answered: no

ScreenplayEventOwners is load-bearing, and Stage's path-derived determinism does not substitute for it. EventConverter.Convert is handed slice.Events only — the events a slice declares. A State View or Automation slice declares none; it consumes them. So every consumer slice comes out of Stage's chain with zero events, and EventConverter passes string.Empty for SourceEventId on every definition it does build.

Per slice, the arrows that disappear:

InvoiceList          StateView    studio 6 events / 6 refs  ->  stage 0 / 0
InvoiceDetails       StateView    studio 10 / 4             ->  stage 0 / 0
CancelledInvoices    StateView    studio 1 / 1              ->  stage 0 / 0
InvoiceDashboard     StateView    studio 6 / 6              ->  stage 0 / 0
NotifyCustomer…      Automation   studio 1 / 1              ->  stage 0 / 0
DetectOverdueInvoices Automation  studio 2 / 2              ->  stage 0 / 0
ReconcilePayments    Automation   studio 2 / 2              ->  stage 0 / 0

The shape the issue proposes at the end — Stage's converters plus Studio's reference pass — is the right one. The reference pass is not a detail to port afterwards; without it the canvas draws a read model with nothing flowing into it.

A third difference, not in the issue: Stage's rule conversion was inventing operands

The 15-vs-11 rule count is not Stage carrying four more rules. Two of the four were fabricated:

Source	Stage produced
dueDate > today	GreaterThan(Threshold = 0)
olderThan < today	LessThan(Threshold = 0)

today is not a literal, and ValidationRuleConverter's operand readers defaulted to 0 / "" rather than declining. Fixed in Cratis/Stage#31, which drops them instead — so after that lands the honest gap is 13 vs 11, not 15 vs 11.

The remaining two are lines.quantity all > 0 and lines.unitPrice all >= 0. Stage converts the element-wise quantifier to the scalar comparison; Studio drops it. Stage's reading looks right — the property path names the element — which means Studio is the one over-dropping here, and Studio's ScreenplayImportWarnings currently reports those two as not carried. That is a live disagreement between the two, and it is the same class of problem the issue describes: two implementations, one comment holding them together.

What this leaves for the design conversation

Question 1 (identity) is untouched by any of this and is still a real choice — deterministic identity would make re-importing the same document produce the same graph, which is a behavior change worth wanting on its own terms. Nothing measured here argues against it.

What the measurement does change is the framing of the work: this is a merge of two converters, each of which is ahead of the other, not a deletion of one. Reproduce with any Screenplay document — the two visitors have the same signature, so they can be run side by side in a few lines.

[woksin]

Follow-up on question 1 (identity), because the specification wiring turns out to answer part of it.

Deterministic identity does not subsume the owners map — it makes a wrong reference stable instead of absent.

SpecificationConverter resolves the event a given/then step names by deriving it from the specification's own slice path:

DeterministicId.From($"{slicePath}.event.{@event.EventType}")

EventConverter derives that same event's actual id from the producing slice's path. The two agree only when the event is declared by the slice the specification lives in. Measured on invoicing.play:

event definitions: 19, commands: 7
  DANGLING RegisterInvoice/RegisteringADraftInvoice given 'CustomerRegistered' -> ec04b40b-…
  when RegisterInvoice/RegisteringADraftInvoice 'RegisterInvoice'          -> resolved
  when RegisterInvoice/RejectingAnInvoiceWithNoLines 'RegisterInvoice'     -> resolved
  when RegisterInvoice/RejectingAnInvoiceWhoseNumberIsAlreadyTaken '…'     -> resolved
  when ChangeInvoiceStatus/SendingADraftInvoice 'ChangeInvoiceStatus'      -> resolved
event references: resolved=3 dangling=1

The three that resolve are same-slice then events. The one that dangles is CustomerRegistered — declared import Customers.CustomerRegistered, produced outside the slice. Commands resolve because a specification's when always names its own slice's command, and CommandConverter derives the id from the same path with the same formula.

This matters for the framing more than the count. ScreenplayEventOwners.IdentityFor(name) resolves by name across the whole application, and returns Guid.Empty when nothing produces the event — so an unresolvable reference arrives visibly empty. Stage's derivation returns a well-formed Guid that no event definition carries, which reads as a resolved reference and is not. Determinism is orthogonal to this: it makes the id reproducible, not correct.

So the answer to "whether that preserves Studio's incoming arrows" is no on two counts — the consumer-slice events are not emitted at all (previous comment), and cross-slice references inside specifications resolve to nothing. Both want the owners map, or something that resolves by name the way it does.

None of this is an argument against deterministic identity itself, which is still worth having on its own terms. It is an argument that adopting it does not let the resolution pass be deleted along with the rest.

Reproduced with a throwaway spec against Cratis.Stage.Contracts as Studio pins it (2.0.0); nothing was left behind in either repo.

[einari]

Investigated as part of Cratis/Studio#1144 and deliberately not done — Stage's converter cannot preserve cross-slice event identity, so adopting it would break the canvas.

EventConverter derives every event id from the slice's own path and hardcodes the one field that exists to solve this:

DeterministicId.From($"{slicePath}.event.{@event.Name}"),
@event.Name,
string.Empty,                    // SourceEventId, hardcoded

Three independent findings:

1. Ids are slice-local, so a producer and a consumer of the same event hash to different Guids.
2. EventDefinition.SourceEventId — the documented hook for exactly this — is written in zero places across all of Stage.
3. A consuming slice usually gets no EventDefinition at all, since EventConverter iterates only declared event blocks.

Stage's own runtime works around this by name (DistinctBy(e => e.Name) with the comment "A slice can reference an event another slice owns", and Id == eventId || Name == name). So event identity in Stage today is the name; the Guid is not a usable join key.

Studio's canvas depends on the opposite: EventModelPreviewMapper.Slices.cs branches on SourceEventId to decide reference-vs-external, and that is what draws incoming event arrows. Adopting Stage's chain would silently erase them — far worse than the duplication this issue is about. Studio's ScreenplayEventOwners is therefore load-bearing, not redundant.

Upstream unblock: Stage needs a pre-pass equivalent to ScreenplayEventOwners that assigns each event name one identity across the application and populates EventDefinition.SourceEventId on consuming slices. The field and its doc comment already exist; only the filling is missing. The sole spec pinning current behavior is SourceEventId.ShouldEqual(string.Empty) in for_EventModelLoader/when_inspecting_the_events.cs. This belongs with Cratis/Stage#23.

[woksin]

First increment landed: Cratis/Studio#1145. Leaving this open — it closes one column of the gap, not the issue.

What it adopts. Cratis.Stage.Contracts.Screenplay.ReadModelConverter, for the read model's name and synthesized schema. That also deletes Studio's hand-copied ReadModelName — the one #1108 added with the comment "change both together or neither", which is precisely the drift mechanism this issue was filed about. That resolution is now single-sourced.

A wrinkle worth recording, because it changes the shape of the remaining work. While #1145 was open, #1144 shipped read-model schema independently by a different mechanism — reading the slice's readmodel declaration. The merge was not a matter of picking one:

• A readmodel declaration is the document stating what the model holds, with the types it declares. Synthesis infers a type from an event property that happens to share a name, and leaves it open when none does.
• But invoicing.play — the language's own 17-slice showcase — declares no slice-level readmodel at all (its two readmodel hits are given/then readmodel inside a specification). So the declaration mechanism yields an empty schema for all six read models there, and synthesis yields all six.

Resolved as declared when present, synthesized otherwise. The general lesson for the rest of this issue: adopting a Stage converter is not always a straight substitution, because Studio sometimes has a source of truth Stage's converter does not consult.

Deliberately untouched, so nothing here pre-empts the two open decisions: identity is still stamped fresh rather than derived, and ScreenplayEventOwners is untouched.

What remains, in the order I'd take it:

1. The projection body. The canvas destination exists (SliceReadModelProjectionDefinitionSet, ReadModelItem.ProjectionDefinition), but Stage's ProjectionDefinition and the canvas' differ across eight nested definition families — From, Join, Children, FromDerivatives, FromEvery, FromEventProperty, RemovedWith, RemovedWithJoin — and the canvas' additionally carries Owner/EventSequenceId/Identifier/ReadModel that Stage's does not. A mapping job, not a wiring one.
2. Produces, command StateSchema, and the model name — measured at 17 / 7 / present on Stage's side against 0 / 0 / empty on Studio's.
3. The two decisions, unchanged: deterministic identity, and cross-slice event ownership. The measurements for both are in the comments above.

Also worth noting for whoever picks this up: the schema now carried on import is not written back out by export. StructureScreenplayExtensions emits a bare Get{Name} query and an automapped projection, and never reads ReadModel.Schema — so this improves the canvas and the import preview, not round-trip fidelity.