Problem

When consuming workflow events via WatchStreamAsync() or NewEvents, there's no way to observe workflow completion or failure through the event stream. The framework emits WorkflowStartedEvent but has no corresponding WorkflowCompletedEvent. For errors, WorkflowErrorEvent exists but requires an Exception object .In scenarios where only an error message string is available (e.g., reading status from an external orchestrator), there's no suitable event type to use.

Additionally, RequestHaltEvent is internal, so implementations that need to surface halt information to stream consumers can't use it.

Proposal

1. Add WorkflowCompletedEvent, a public event signaling that a workflow has completed, optionally carrying a result. This would be the natural counterpart to WorkflowStartedEvent.

2. Add a string based failure event (or overload WorkflowErrorEvent). Either a new WorkflowFailedEvent that accepts a string errorMessage, or an additional constructor on WorkflowErrorEvent that doesn't require an Exception. Not all failure scenarios have an exception object available.

3. Consider making RequestHaltEvent public with an ExecutorId property, so consumers can observe which executor requested a halt. Currently it's internal and filtered out of event streams.