Stage should be able to run specifications declared in Screenplay the same way it runs a solution — with Studio typically handing in a single slice carrying one or more specifications. Two things stand between here and that.
1. The spec runner verifies structure, not behaviour
All three run strategies check that names resolve and report Inconclusive; none executes the specification. Their own messages say so — projection execution "is not yet available", reactor behaviour "is not modeled and was not executed", and state-change behavioural execution "is a follow-up".
So a passing run today means the slice is internally consistent, not that the modelled behaviour is correct.
2. The slice and specification filters cannot match what Studio sends
SpecRunnerArguments accepts --slice and --spec, and SpecificationRunner.Run(model, sliceId, specificationId) filters on them.
Studio passes its canvas GUIDs for both, and then matches results back by the same id. Stage's Screenplay ingest derives every id with DeterministicId.From("<Module>.<Feature>.<Slice>…") — a SHA-256 of the fully-qualified path. Those two id spaces cannot coincide, so a single-specification run should filter to nothing and fail with "no result was produced for specification …".
This became possible when the feed switched from Studio-serialized JSON, where Studio owned the ids, to a generated .play, where Stage does. A run-all survives only because it applies no filter.
Adopting deterministic ids on the Studio side is a prerequisite for the slice-plus-specifications handoff, not just a tidy-up. Worth confirming with a single-specification run against the current image before designing the fix.
Stage should be able to run specifications declared in Screenplay the same way it runs a solution — with Studio typically handing in a single slice carrying one or more specifications. Two things stand between here and that.
1. The spec runner verifies structure, not behaviour
All three run strategies check that names resolve and report
Inconclusive; none executes the specification. Their own messages say so — projection execution "is not yet available", reactor behaviour "is not modeled and was not executed", and state-change behavioural execution "is a follow-up".So a passing run today means the slice is internally consistent, not that the modelled behaviour is correct.
2. The slice and specification filters cannot match what Studio sends
SpecRunnerArgumentsaccepts--sliceand--spec, andSpecificationRunner.Run(model, sliceId, specificationId)filters on them.Studio passes its canvas GUIDs for both, and then matches results back by the same id. Stage's Screenplay ingest derives every id with
DeterministicId.From("<Module>.<Feature>.<Slice>…")— a SHA-256 of the fully-qualified path. Those two id spaces cannot coincide, so a single-specification run should filter to nothing and fail with "no result was produced for specification …".This became possible when the feed switched from Studio-serialized JSON, where Studio owned the ids, to a generated
.play, where Stage does. A run-all survives only because it applies no filter.Adopting deterministic ids on the Studio side is a prerequisite for the slice-plus-specifications handoff, not just a tidy-up. Worth confirming with a single-specification run against the current image before designing the fix.