Summary
The reactor construct can state what a reactor observes (on <Event>) and where its code lives (file / inline block) — but not what it produces. In Event Modeling, the whole point of an automation slice is its output: it reads events and produces new events or commands. Arc makes this first-class (reactor methods return side-effect events — Task<TEvent>, ReactorSideEffect, collections thereof — or execute commands via ICommandPipeline), yet a Screenplay document can only say "this reactor exists and watches these events".
Evidence (real application)
From Ada:
AcceptedInvitationProvisioner: On(InvitationToJoinAdaAccepted) -> Task<IEnumerable<EventForEventSourceId>> — produces provisioning events; the document shows only the trigger.ConsultantProvisioner: two triggers, both returning side-effect event collections.- Outbox reactors (
InvitationLobbyOutbox and friends) whose entire purpose is translating slice events into another context's inbox — the translation output is invisible in the document.
The generator (Cratis.Arc.Screenplay) already recovers side-effect events and executed commands from reactor bodies — it uses them internally to classify slices as Automation vs Translate — and then has nowhere to put them.
Suggested direction
Allow declaring outputs under a trigger (syntax open):
reactor AcceptedInvitationProvisioner
on InvitationToJoinAdaAccepted
produces UserAccountProvisioned
file Admin/Invitations/Provision/Provision.cs
reactor StockKeeping
on BookReserved
executes DecreaseStock
produces reuses the known-event reference checking that command produces already gets from the validator; executes would reference a command. This closes the loop that makes an Event-Modeling diagram drawable from a Screenplay: state-change → events → projections → automation → commands → state-change.
Context
Found while validating a generated 5,348-line document from a production Arc application against its source; 24 reactors emitted, none able to state their outputs.
Summary
The
reactorconstruct can state what a reactor observes (on <Event>) and where its code lives (file/ inline block) — but not what it produces. In Event Modeling, the whole point of an automation slice is its output: it reads events and produces new events or commands. Arc makes this first-class (reactor methods return side-effect events —Task<TEvent>,ReactorSideEffect, collections thereof — or execute commands viaICommandPipeline), yet a Screenplay document can only say "this reactor exists and watches these events".Evidence (real application)
From Ada:
AcceptedInvitationProvisioner:On(InvitationToJoinAdaAccepted) -> Task<IEnumerable<EventForEventSourceId>>— produces provisioning events; the document shows only the trigger.ConsultantProvisioner: two triggers, both returning side-effect event collections.InvitationLobbyOutboxand friends) whose entire purpose is translating slice events into another context's inbox — the translation output is invisible in the document.The generator (
Cratis.Arc.Screenplay) already recovers side-effect events and executed commands from reactor bodies — it uses them internally to classify slices as Automation vs Translate — and then has nowhere to put them.Suggested direction
Allow declaring outputs under a trigger (syntax open):
producesreuses the known-event reference checking thatcommand producesalready gets from the validator;executeswould reference a command. This closes the loop that makes an Event-Modeling diagram drawable from a Screenplay: state-change → events → projections → automation → commands → state-change.Context
Found while validating a generated 5,348-line document from a production Arc application against its source; 24 reactors emitted, none able to state their outputs.