Exporting an imported event model produces a Screenplay document that does not compile, because external events are never written back

[woksin]

Import a real .play, export it again, and the result is not a legal Screenplay document.

Measured on Screenplay's own 913-line invoicing.play fixture (17 slices, 19 events, 7 commands):

regenerated document compiles = FALSE   (2 errors)
  line 252: Projection 'InvoiceLineReportReadModel' must contain at least one directive
  line 283: Projection 'SystemActivityReadModel'    must contain at least one directive

This is not a fidelity nicety. The renderer and the Stage container both consume that text, so code generation, "play this model", and "run specifications" all sit downstream of it.

Cause

An event a slice consumes but no State Change slice owns is imported as an external event and stored on the slice's ExternalEvents collection. The exporter never reads that collection — ExternalEvents has zero references anywhere under Source/Core/Screenplay/, while the import path populates it in two places and Slice documents it as a first-class member.

So when a State View slice's projection sources are all external, the exported projection is emitted with automap and a key but no from directive, and the compiler rejects it.

Traced concretely: InvoiceLineItemAdded is produced only inside a capture block. Captures are not carried on import, so the event has no owning slice, becomes external, and disappears. It appears 3 times in the source document and 0 times in the regenerated one.

A second, independent trigger for the same failure

The consumed-event walk handles from, join, children, nested, remove and clear, but not all / every. A projection written with all therefore harvests zero events and produces the same empty projection — silently, with no warning.

Suggested direction

Include external events when building the exported slice, and add all/every to the consumed-event walk. Both are small and localized.

The check that would have caught this, and should exist

There is no spec anywhere that round-trips a document and asserts the result is valid. The nearest one asserts produces against the syntax tree rather than the imported model, so it passes while the imported model carries none.

The loop runs headlessly in about 110 ms with no server, database or browser — parse, map to the canvas model, generate — so a spec that imports a .play, exports it, and asserts the regenerated text compiles costs one file in the existing harness and catches this entire class of defect. That single assertion is worth more than any of the individual carries below.

Related fidelity gaps found in the same run

All of these are things the Stage contract can already express — they are gaps on this side, not blocked on Cratis/Stage#23:

• produces is dropped on import (commands are imported with an empty produced-event list) although the contract carries produced events with a full condition tree, and export writes them.
• Constraints are dropped on import although export writes them and the contract carries them on the event definition. (PR #1044 carried specifications and rules; constraints were not included.)
• Read-model schema is always empty on import, although the contract has the field.
• Projection bodies — key and from semantics — are dropped; only event names are harvested.
• Validation rules with a non-literal threshold are silently dropped. A rule comparing against another property rather than a constant vanishes. This accounted for 2 of the 6 rules lost in the measured run.
• NotEqual is dropped and, unlike the other unmapped kinds, is not documented as such.

Two defects in the warnings themselves

1. The specification warning is false. The importer reports "N specifications declared here were not added" while the specifications are added — 4 declared, 4 carried, and still warned about. PR #1044 added the carry and left the warning behind.
2. A spec asserts that false warning, so the incorrect message is now pinned in place.

Silent drops that should at minimum warn

Application-level imports and authentication; slice-level readmodel and reducer; command-level reads, handler and require; every query construct; non-literal rule thresholds; NotEqual.

Export has no warning channel at all

Considerable care has gone into import warnings. Everything lost on the way out — constraints, concurrency, projection bodies, queries, NotNull, EmailAddress, Phone, Url — vanishes with no diagnostic of any kind.

Since code generation renders from the canvas through this same converter, every export gap is also a code-generation gap: a dropped authorize means generated code with no authorization on it.

[woksin]

Fixed in #1139 (released in 0.59.1). On Screenplay's own 913-line invoicing.play, the regenerated document goes from 2 × PLAY0057 to compiling.

Two corrections to what I wrote above, both found while fixing it.

The all / every cause was wrong

I claimed the consumed-event walk handles from/join/children/nested/remove/clear but not all/every, and that a projection using all therefore harvests zero events.

The observation was right and the diagnosis was wrong. AllSyntax and EverySyntax carry no event names by construction — all subscribes to every event type in the system rather than naming any, and every is a mapping modifier over the projection's other blocks. Adding them to the walk would have returned nothing. The _ => [] fallback was already correct.

The real fault was on the export side, and it is the same fault as the external-events one: a read model with nothing to project was written out as a projection with no body, which is not legal Screenplay. A State View slice with a query and no projection does compile — verified against the grammar — so a read model the canvas holds no events for is now written without one, and keeps its query.

So there was one cause with two triggers, not two independent causes.

produces cannot be carried today, and this is not a mapping gap

I listed produces being dropped on import as a fidelity gap fixable now, on the grounds that the Stage contract can already express it. The contract can. The canvas cannot.

CommandItem has no produced-events property at all — it holds Schema, Rules, StateSchema, StateProjection, LogicDescription and Concurrency. Export does not carry produces either; it synthesizes it from slice membership, which ProducesScreenplayExtensions documents as a deliberate choice.

Wiring the conversion in would populate an intermediate field nothing downstream reads. Carrying produces needs new canvas model surface, which is a product decision about what the board should represent — not a mapping fix. It belongs with Cratis/Stage#23-class questions rather than on this list.

Also fixed

• Constraints are now carried on import. This needed three changes, not one: the visitor, EventModelImporter and EventModelPreviewMapper all dropped them independently, so fixing only the visitor would have carried nothing a user could see. (Cratis/Studio#1141)
• The false specification warning is gone. The import no longer reports a slice's specifications as left behind while carrying every one of them.
• A projection that names no event is now reported, so it is visible before committing an import that the read model will arrive with nothing projected into it.

Still open from the list above

• Read-model schema is still empty on import.
• Projection bodies — key and from semantics — are still dropped.
• Validation rules with a non-literal threshold are still silently dropped, and NotEqual is still undocumented.
• The preview dialog still understates the import. EventModelPreviewMapper never sets Rules and hardcodes Specifications: [], while the real importer carries both. Measured on the same document: the intermediate model holds 4 specifications and 13 rules; the preview showed 0 and 0. The constraint half of this is fixed in #1141; rules and specifications remain.

[einari]

Further progress in Cratis/Studio#1144; leaving open for what remains.

Landed: a read model now keeps the shape it declares across a round trip — the import hardcoded an empty schema regardless of what the document said, and never called the DefineSliceReadModelSchema that already existed. The acceptance gate is also stronger: the round-trip spec now runs against the real 913-line invoicing.play rather than a hand-pruned excerpt, and asserts idempotence — a second round trip must leave the document alone. That last part matters, because a carry lost on pass one but not pass two still reads as a passing compile; only a fixed point rules it out.

Still open:

• Projection bodies — key and from semantics are still dropped; only event names are harvested. Both homes exist and sit empty (ProjectionDefinition on the Stage side, ReadModelItem.ProjectionDefinition on the canvas). Note ProjectionScreenplayExtensions fabricates a literal key "default" when no event has a property, which silently collapses every instance into one.
• Export has no warning channel at all. IScreenplayGenerator.Generate returns a bare string. Confirmed silent losses: EmailAddress/Phone/Url rules dropped outright; NotNull coerced to NotEmpty; Length split into Min+Max; composite unique (a,b) exploded into N independent single-property constraints — a different, stronger rule, not a rename; concurrency dimensions bound to a command property dropped; query names always regenerated as Get<ReadModel> and the [] collection modifier degraded to scalar. Since code generation renders through this same converter, each is also a code-generation gap.
• Cross-module import ordering — a consumer in an earlier module referencing a producer in a later one is dropped with no slice event, no external event and no warning. invoicing.play has one module so it does not trip this.
• ScreenplayEventOwners registers only StateChange slices, so an event produced by a Translate slice's capture gets no identity and arrives as external — worth confirming that is intended.

[woksin]

Re-ran the round trip on the full invoicing.play now that it compiles again. It compiles — and loses about a third of the document without saying anything.

	before	after
concepts	14	0
policies	7	0
reactors	3	0
screens	6	0
queries	7 declared	6 synthesized Get<ReadModel>
constraints	3	2 (InvoiceStatusTransition gone)
slices	17	17
specifications	4	4

Concepts, policies and screens are not on the still-open list above, so adding them here rather than filing separately.

The one worth looking at first: the three Automation/Translation slices come back as commands. NotifyCustomer, OverdueInvoiceDetector and PaymentReconciler disappear, and NotifyCustomerOnInvoiceRegistered, DetectOverdueInvoices and ReconcilePayments — the slice names — appear as commands the document never declared. An event is invented alongside them (ArchiveOldInvoicesRecorded). So a reactor does not merely vanish; it comes back as a different kind of thing.

That matters more now than when the document failed to compile: compiling is what made all of it silent.

Reproduction — ScreenplayParser → EventModelPreviewMapper → ScreenplayGenerator → ScreenplayCompiler, on Screenplay's own invoicing.play, counting recursively through nested features (a flat walk misses the Adjustments sub-feature and undercounts both sides).

[woksin]

Ran the same round trip on Ada — a real application, 3,081 files, 17 modules, 241 slices — now that cratis screenplay generate produces a document that compiles (Arc 21.14.2, pinned in the CLI as of Cratis/cli#69). Same losses as invoicing.play, twenty times the document:

	before	after
concepts	160	0
policies	9	0
reactors	23	0
screens	205	0
constraints	54	23
projections	93	70
commands	132	150
modules / slices / specifications	17 / 241 / 957	17 / 241 / 957

The regenerated document compiles with 0 errors, and the import reports 511 warnings on the way in — so the losses are named, not silent, on that half.

The one question, and the only thing I am blocked on: concepts, policies, reactors and screens have nowhere on the canvas to live, so closing those four rows means adding canvas model surface — what the board represents. That is yours to decide, not mine to guess.

Is the canvas meant to grow a home for them, or is the intent that it holds modules/features/slices only and the document keeps more than the board ever will?

• If it grows one — I will do it, and the order I would suggest is reactors first: they are the only row that comes back as something the document never said. The three Automation/Translation slices lose their reactors and reappear as commands named after the slice, with an invented event alongside. That is "nothing is invented", not just "nothing is dropped".
• If it does not — then the losses are by design, and the work is to make export say so. It has no warning channel at all today (Generate returns a bare string), which is the asymmetry that makes all of this invisible on the way out.

I am starting on the export warning channel now either way — it is needed under both answers and needs no decision from you.

[woksin]

Correction to my comment above — withdraw the question. I was wrong about the premise.

I said concepts, policies, reactors and screens have nowhere on the canvas to live. They all do:

	Where it lives on the canvas
concepts	Domains/Concepts — Concept(Name, PrimitiveType, IsPii, Description, Rules)
policies	Projects/Applications/Policies — and policyScreenplay.ts already renders one to Screenplay text
screens	Slice.Actors — UserExperienceActor(Elements, WindowWidth, WindowHeight, Layout)
reactors	SliceType.Automation / SliceType.Translator already distinguish the slice

What I actually found is a converter that never asks. StructureScreenplayExtensions.ToApplication writes ApplicationSyntax([], [], [], modules, …), and every slice with Reactors: [], Screens: [] hardcoded. The zeros in my table are those literals, not a limit of the model. I read the converter and inferred the canvas from it, which was the wrong direction to reason in.

That also explains the reactor-to-command inversion without needing any new surface: ToSlice writes slice.Command whatever the slice type is, so an Automation slice with a command on it emits a command and never a reactor.

So there is no product decision here and nothing is blocked on you. It is converter work, and I am doing it.

One plumbing note, not a question: EventModel is (Id, Name, Collections, StickyNotes) and carries no reference to its domain, so concepts and policies sit one level above what ToApplication is handed. The export path will load them the way it already loads module collections and modules.

Apologies for the noise — the measurement in the previous comment stands, the conclusion I drew from it did not.

[woksin]

Two more from writing an export-side counterpart to ScreenplayImportWarnings and running it over the Ada canvas. 91 losses, and neither of these was on the list.

	count
read models whose projection is written with a key the canvas never stated	70
read models written with no projection at all	21

The 70 is every projection the export writes. ProjectionScreenplayExtensions.ToProjection takes the key from the first event that carries a schema property, and falls back to ExpressionKeySyntax(LiteralExpressionSyntax("default")) when none does. On an imported canvas none does — SliceSyntaxVisitor.Events gives a consumed event string.Empty for its schema, and a State View slice's events are all consumed. So every read model in the regenerated document is keyed on the constant "default", which collapses every instance of it into one. You noted the fabrication when it was a latent branch; on a real document it is not latent, it is the only path.

The 21 are slices where the read model has no event at all on the canvas, so no projection is written — the query still names the read model, which reads as though it answers something.

Both are definition-of-done #4 rather than #1: the document says something the canvas never did, and it compiles, so nothing catches it.

The warning code is on wip/screenplay-export-warnings in Studio — parked rather than proposed, because it has no consumer and no specs yet. IScreenplayGenerator.Generate returning a bare string is still the reason none of this can reach anyone.

Separately, Cratis/Studio#1164 fixes the reactor-to-command inversion: 132 commands in, 132 out on Ada, down from 150.