       end
     end
   end
+
+  docp """
+  See comments & implement me.
+
+  Emits: StepFailedEvent.t, StepRestartedEvent.t
+  """
+  defp fail_step(_step) do
+    # Default fail_step implementation is todo.
+    # Possible implementation:
+    #   1 - Remove all emails/replies sent through that step
+    #   2 - Undo/delete all objects generated on `Steppable.setup`*
+    #   3 - Call `Steppable.setup`, effectively restarting the step.
+    #
+    # Possible problems:
+    #   1 - Email/reply ids are not unique across steps, so step 1 should take
+    #     this into consideration.
+    #   2 - UX: If mission is reset right after it's failed, the client may
+    #     receive the `stepproceeded**` event almost at the same time as
+    #     `stepfailed` event, so user experience should be considered
+    #
+    # Notes:
+    # * - This should be done at `Steppable.fail`
+    # ** - In fact, mission "resetup" should be a different event, maybe
+    #   `StepRestarted`. Otherwise, the client would get `StepProceeded` after
+    #   the step has failed, which doesn't quite make sense.
+  end
 end

    end
  end

  defp step_flow(step) do
    flowing do
      with \

defmodule Helix.Story.Event.Handler.Story do
  @moduledoc """
  The StoryEventHandler is centralized, in the sense that all events that should
  be handled by Steps must get handled by it.

  Once an event is received, we figure out the entity responsible for that event
  and verify whether the StepFlow should be followed. The StepFlow guides the
  Step through the Steppable protocol, allow it to react to the event, either
  by ignoring it, completing the step or failing it.
  """

  import HELF.Flow
  import HELL.MacroHelpers
