Minor doc fixes (#16938)

docs/docs/understanding/workflows/basic_flow.md

@@ -47,6 +47,7 @@ print(result)
 This will simply print "Hello, World!" to the console.
 
 In this code we:
+
 * Define a class `MyWorkflow` that inherits from `Workflow`
 * Use the @step decorator to define a single step `my_step`
 * The step takes a single argument, `ev`, which is an instance of `StartEvent`
@@ -130,6 +131,7 @@ class SecondEvent(Event):
 ## Defining the workflow
 
 Now we define the workflow itself. We do this by defining the input and output types on each step.
+
 * `step_one` takes a `StartEvent` and returns a `FirstEvent`
 * `step_two` takes a `FirstEvent` and returns a `SecondEvent`
 * `step_three` takes a `SecondEvent` and returns a `StopEvent`

docs/docs/understanding/workflows/concurrent_execution.md

@@ -112,6 +112,7 @@ class ConcurrentFlow(Workflow):
 ```
 
 There are several changes we've made to handle multiple event types:
+
 * `start` is now declared as emitting 3 different event types
 * `step_three` is now declared as accepting 3 different event types
 * `collect_events` now takes an array of the event types to wait for

docs/docs/understanding/workflows/index.md

@@ -40,4 +40,4 @@ Let's build [a basic workflow](basic_flow.md). Follow the tutorial sequence step
 
 Once you're done, check out our [Workflows component guide](../../module_guides/workflow/index.md) as a reference guide + more practical examples on building RAG/agents.
 
-If you're done building and want to deploy your workflow to production, check out [our llama_deploy guide](../../module_guides/workflow/deployment.md) ([repo](https://github.com/run-llama/llama_deploy)).
+If you're done building and want to deploy your workflow to production, check out [our llama_deploy guide](../../module_guides/llama_deploy/) ([repo](https://github.com/run-llama/llama_deploy)).

docs/docs/understanding/workflows/stream.md

@@ -89,7 +89,7 @@ if __name__ == "__main__":
     asyncio.run(main())
 ```
 
-`create_task` runs the workflow in the background, while `stream_events` will provide any event that gets written to the stream. It stops when the stream delivers a `StopEvent`, after which you can get the final result of the workflow as you normally would.
+`run` runs the workflow in the background, while `stream_events` will provide any event that gets written to the stream. It stops when the stream delivers a `StopEvent`, after which you can get the final result of the workflow as you normally would.
 
 
 Next let's look at [concurrent execution](concurrent_execution.md).