fix(docs): correct some formatting issues

Author: johannesschobel

content/faq/request-lifecycle.md

@@ -67,22 +67,22 @@ Filters are the only component that do not resolve global first. Instead, filter
 In general, the request lifecycle looks like the following:
 
 1. Incoming request
-1. Globally bound middleware
-1. Module bound middleware
-1. Global guards
-1. Controller guards
-1. Route guards
-1. Global interceptors (pre-controller)
-1. Controller interceptors (pre-controller)
-1. Route interceptors (pre-controller)
-1. Global pipes
-1. Controller pipes
-1. Route pipes
-1. Route parameter pipes
-1. Controller (method handler)
-1. Service (if exists)
-1. Route interceptor (post-request)
-1. Controller interceptor (post-request)
-1. Global interceptor (post-request)
-1. Exception filters (route, then controller, then global)
-1. Server response
+2. Globally bound middleware
+3. Module bound middleware
+4. Global guards
+5. Controller guards
+6. Route guards
+7. Global interceptors (pre-controller)
+8. Controller interceptors (pre-controller)
+9. Route interceptors (pre-controller)
+10. Global pipes
+11. Controller pipes
+12. Route pipes
+13. Route parameter pipes
+14. Controller (method handler)
+15. Service (if exists)
+16. Route interceptor (post-request)
+17. Controller interceptor (post-request)
+18. Global interceptor (post-request)
+19. Exception filters (route, then controller, then global)
+20. Server response

content/fundamentals/dependency-injection.md

@@ -89,7 +89,6 @@ export class AppModule {}
 What exactly is happening under the covers to make this work? There are three key steps in the process:
 
 1. In `cats.service.ts`, the `@Injectable()` decorator declares the `CatsService` class as a class that can be managed by the Nest IoC container.
-
 2. In `cats.controller.ts`, `CatsController` declares a dependency on the `CatsService` token with constructor injection:
 
 ```typescript

content/graphql/federation.md

@@ -203,7 +203,7 @@ import { PostsResolvers } from './posts.resolvers';
 export class AppModule {}
 ```
 
-##### Code first
+#### Code first
 
 We will need to create a class representing our `User` entity. Even though it lives in another service, we will be using and extending it. Note the `@extends` and `@external` directives.
 

content/recipes/cqrs.md

@@ -2,10 +2,10 @@
 
 The flow of simple [CRUD](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete) (Create, Read, Update and Delete) applications can be described using the following steps:
 
-1.  The **controllers** layer handles HTTP requests and delegates tasks to the services layer.
-2.  The **services layer** is where most of the business logic lives.
-3.  Services use **repositories / DAOs** to change / persist entities.
-4.  Entities act as containers for the values, with setters and getters.
+1. The **controllers** layer handles HTTP requests and delegates tasks to the services layer.
+2. The **services layer** is where most of the business logic lives.
+3. Services use **repositories / DAOs** to change / persist entities.
+4. Entities act as containers for the values, with setters and getters.
 
 In most cases, for small and medium-sized applications, this pattern is sufficient. However, when our requirements become more complex, the **CQRS** model may be more appropriate and scalable. To facilitate that model, Nest provides a lightweight [CQRS module](https://github.com/nestjs/cqrs). This chapter describes how to use it.