Render Given/When/Then into Cratis Specifications

[woksin]

Rendering should include rendering Given/When/Then into Cratis Specifications, leveraging the constructs we have. Nothing is rendered today — there are no references to specifications anywhere in the renderer's production code.

Targets available

The in-process scenario family: CommandScenario<TCommand>, EventScenario, ReadModelScenario<TReadModel>, ReactorScenario<TReactor>.

Mapping, and the gaps

Screenplay	Target	Notes
when <command> + then <events>	CommandScenario<T> → Execute() + ShouldHaveAppendedEvent<,>	clean fit
then error	ShouldNotBeSuccessful() + ShouldHaveValidationErrors()	clean fit; a bare then error maps naturally, since the conventions forbid asserting on message strings
given <events> on a State View	ReadModelScenario<T> → Given.ForEventSource(id).Events(…)	clean fit
given readmodel / then readmodel	ReadModelScenario, or bridged into CommandScenario via Services	also dropped on ingest — Source/Contracts/Screenplay/SpecificationConverter.cs reads only given events, when, then events and then errors, while SpecificationSyntax exposes GivenReadModels and ThenReadModels
given <events> on a State Change slice	—	structural gap: CommandScenario has no Given/Events; prior state has to be seeded through Services

So there are two separate pieces of work: the renderer emits no specs, and the ingest converter drops read-model given/then before the renderer could ever see them.

Emitted specs need to carry the repo conventions — the for_ / when_ / and_ folder hierarchy, #if DEBUG wrapping, and the paired ShouldNotBeSuccessful() + ShouldHaveValidationErrors() on every unhappy path.

[woksin]

Landing the renderable half as #36, and correcting this issue's premise while I do.

"Structural gap: CommandScenario has no Given/Events" is no longer true. Cratis.Arc.Chronicle.Testing gained scenario.Given.ForEventSource(id).Events(…) and .ReadModel<T>(…), so both gaps this issue records against the target are gone.

Which moves the problem, rather than solving it. The reason given still is not rendered is the document: a given event names no event source, and it is frequently not the command's own. RejectingAnInvoiceWhoseNumberIsAlreadyTaken in invoicing.play seeds an InvoiceRegistered for a different invoice than the one it registers — that collision is the whole point of the specification. Seeding it against the command's id would render a spec that passes for the wrong reason.

So rendering given needs the language to say which event source a given event belongs to. That is a Screenplay question, not a Stage one, and nothing here should guess it — I left it declined and reported.

What #36 does render, measured on invoicing.play: one of four specifications renders and compiles; the other three are declined with the reason on stderr — two seed prior state, one states read model state. Before it, all four were a single line saying "no specs are rendered".

Also worth recording against the third row of this issue's table: Stage's own spec runner does not execute anything. StateChangeRunStrategy verifies that names resolve and says so itself — "Behavioral execution of the command against a live Chronicle is a follow-up." So there was no existing identity rule to be consistent with; nobody has solved given-event identity anywhere in the system yet.