     end
   end
 
+  docp """
+  The StepFlow guides the step, allowing it to react to the received event.
+
+  Step handling of events is made through Steppable's `handle_event/3`, refer to
+  its documentation for more information.
+
+  Once the event is handled by the step, the returned action is handled by
+  StepFlow. It may be one of `:complete | :fail | :noop`. See doc on
+  `handle_action/2`.
+  """
   defp step_flow(step) do
     flowing do
       with \

      end
    end
  end
  defp handle_action(:fail, step),
    do: Steppable.fail(step)
  defp handle_action(:noop, _),
    do: :noop

  @spec update_next(Step.t(struct), Step.step_name) ::
    term
  defp update_next(prev_step = %{entity_id: entity_id}, next_step_name) do
    next_step = Step.fetch(next_step_name, entity_id, %{})


      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
