docs: update heading levels in book

docs/core-concepts.mdx

@@ -4,22 +4,22 @@ title: Core Concepts Overview
 
 Welcome to the Core Concepts section of Kameo, where you'll find the foundational principles and components that make up the Kameo actor library. Understanding these concepts is crucial for effectively leveraging Kameo to build resilient, scalable, and concurrent applications. Below is an overview of the key concepts that form the backbone of Kameo's design and functionality.
 
-### [<i class="fa-fw fa-solid fa-users"></i>&nbsp; Actors](/core-concepts/actors)
+## [<i class="fa-fw fa-solid fa-users"></i>&nbsp; Actors](/core-concepts/actors)
 
 At the heart of Kameo lies the Actor model, a powerful abstraction that encapsulates state and behavior into independent, concurrent units. Actors are the primary building blocks of applications in Kameo, designed to isolate state and handle messages asynchronously. This isolation enhances fault tolerance and system resilience, as actors can fail and recover without affecting the overall system stability.
 
-### [<i class="fa-fw fa-solid fa-envelope"></i>&nbsp; Messages](/core-concepts/messages)
+## [<i class="fa-fw fa-solid fa-envelope"></i>&nbsp; Messages](/core-concepts/messages)
 
 Communication in Kameo is achieved through messages. Actors interact with each other exclusively by sending and receiving messages, ensuring a loose coupling between components. This messaging system underpins the asynchronous, non-blocking nature of Kameo, enabling efficient communication patterns and facilitating the development of responsive applications.
 
-### [<i class="fa-fw fa-solid fa-question"></i>&nbsp; Requests](/core-concepts/requests)
+## [<i class="fa-fw fa-solid fa-question"></i>&nbsp; Requests](/core-concepts/requests)
 
 Requests represent a specialized form of message exchange in Kameo, supporting both the "ask" and "tell" patterns. This library allows actors to either send messages without expecting a reply ("tell") or send messages and await responses ("ask"). The ask pattern, in particular, introduces a way to handle more complex interaction flows, including synchronous operations and error handling.
 
-### [<i class="fa-fw fa-solid fa-reply"></i>&nbsp; Replies](/core-concepts/replies)
+## [<i class="fa-fw fa-solid fa-reply"></i>&nbsp; Replies](/core-concepts/replies)
 
 Replies are responses to requests, completing the communication cycle between actors. By implementing the `Reply` trait, apps can define custom reply types, ensuring that actors can exchange meaningful data and status information. This mechanism is crucial for implementing robust and interactive systems where actors depend on the outcomes of their interactions.
 
-### [<i class="fa-fw fa-solid fa-shield-alt"></i>&nbsp; Supervision](/core-concepts/supervision)
+## [<i class="fa-fw fa-solid fa-shield-alt"></i>&nbsp; Supervision](/core-concepts/supervision)
 
 Supervision is a strategy for managing actor lifecycle and failure recovery, embodying the principle of "let it crash." In Kameo, actors can be linked together in supervision trees, allowing parent actors to monitor and respond to the failures of their children. This model provides a structured approach to error handling and recovery, ensuring system resilience and stability.

docs/core-concepts/actors.mdx

@@ -4,7 +4,7 @@ title: Actors Overview
 
 The core of Kameo is its actors. Actors are objects that encapsulate state and behavior. They interact with the rest of the system asynchronously, primarily through message passing, which allows for a high degree of concurrency and scalability. This section provides an overview of the `Actor` trait in Kameo, detailing its lifecycle, messaging, and supervision.
 
-### Actor Trait Overview
+## Actor Trait Overview
 
 The `Actor` trait defines the essential functionality and lifecycle hooks for an actor in Kameo. Implementing this trait allows you to create custom actors tailored to your application's requirements. Here are the key components of the `Actor` trait:
 
@@ -13,7 +13,7 @@ The `Actor` trait defines the essential functionality and lifecycle hooks for an
 - **Messaging**: Actors communicate by sending messages to each other. When an actor is spawned, it returns an `ActorRef`, a reference to the actor that can be used to send messages to it. Messages are sent asynchronously and are processed sequentially by the receiving actor.
 - **Supervision**: Actors can supervise other actors, allowing for hierarchical error handling and recovery strategies. The `on_panic` and `on_link_died` hooks are integral to this, enabling actors to respond to failures in their child actors, as well as themselves.
 
-#### **Deriving Actor**
+### **Deriving Actor**
 
 To streamline the creation of actors and reduce repetitive boilerplate, Kameo offers a derive macro for the `Actor` trait. This macro not only simplifies the actor definition process but also provides sensible defaults that adhere to common practices.
 
@@ -34,18 +34,18 @@ use kameo::Actor;
 struct MyActor { }
 ```
 
-### Lifecycle Management
+## Lifecycle Management
 
 - **Starting**: The `on_start` hook is called before the actor starts processing messages. It's an opportunity to perform any necessary initialization.
 - **Stopping**: Actors are stopped either explicitly or when all references to their `ActorRef` are dropped. The `on_stop` hook allows for cleanup activities before the actor is fully stopped.
 - **Error Handling**: The `on_panic` hook is invoked when an actor panics or encounters an error while processing a message. This hook can decide whether the actor should be stopped or continue processing messages.
 - **Link Failures**: The `on_link_died` hook is called when a linked actor dies, providing a chance to react to the failure of closely related actors.
 
-### Actor Creation and Messaging
+## Actor Creation and Messaging
 
 Creating an actor involves implementing the `Actor` trait and then spawning the actor using `kameo::spawn`. Upon spawning, an `ActorRef<T>` is returned, which is used to send messages to the actor. The actor processes messages using the `handle` method from the `Message` trait, optionally returning a reply.
 
-#### Example Usage
+### Example Usage
 
 ```rust
 struct MyActor;

docs/core-concepts/messages.mdx

@@ -4,7 +4,7 @@ title: Messages Overview
 
 In Kameo, messages play a central role in the communication between actors. They are the primary means through which actors interact and modify each other's state. Understanding how messages work is fundamental to effectively using Kameo to build concurrent applications.
 
-### **Defining Messages**
+## **Defining Messages**
 
 Messages in Kameo are any static types that are handled by implementing the `Message<T>` trait for an actor. This design allows for a wide variety of message types, from simple data structures to complex commands with associated data. The flexibility in message definition enables developers to design their actor system with clear and concise communication patterns.
 
@@ -28,13 +28,13 @@ pub trait Message<T>: Actor {
 - **Reply Type**: Each message has an associated `Reply` type, which is the type of the response that the message sender can expect to receive. This reply must implement the `Reply` trait, which ensures that it can be properly handled and sent back to the caller.
 - **Message Handler**: The core of the Message trait is the handle function. This function is where the logic for handling a specific message is defined. It takes mutable access to the actor (&mut self), the message itself (msg), and a context (ctx) that provides access to actor-specific functionality like sending messages to other actors or accessing the actor's state. The handle function returns a future that resolves to the message's reply type, allowing for asynchronous processing of messages. This design supports non-blocking message handling, which is essential for building responsive and scalable actor systems.
 
-### Sequential Processing
+## Sequential Processing
 
 Messages in Kameo are processed sequentially, one at a time, with exclusive mutable access to the actor's state. This sequential processing model simplifies state management within actors, as there is no need for explicit synchronization mechanisms like locks. When an actor is handling a message, it can safely modify its state without worrying about concurrent modifications from other messages.
 
 This model also ensures that messages are processed in the order they are received, which can be critical for maintaining consistency and correctness in certain applications.
 
-### Asynchronous and Concurrent
+## Asynchronous and Concurrent
 
 While messages are processed sequentially within a single actor, Kameo allows for concurrent processing across multiple actors. This is where the actor model shines, enabling high levels of concurrency without the complexity associated with traditional multithreading and synchronization.
 

docs/core-concepts/replies.mdx

@@ -4,19 +4,19 @@ title: Replies Overview
 
 In Kameo, replies are the responses sent back from an actor following the receipt and processing of a message. These replies are fundamental to the ask pattern of actor communication, where a sender awaits a response to proceed. Ensuring that replies are properly structured and handled is crucial for maintaining the flow of information and control within your actor system.
 
-### The Reply Trait
+## The Reply Trait
 
 To facilitate communication within Kameo, all types intended to serve as responses from an actor must implement the `Reply` trait. This designation ensures that a type is recognized as a valid form of reply, capable of being processed within the actor's messaging system.
 
 Special attention is given to replies that encapsulate a `Result::Err` variant from the Rust standard library. These are treated distinctively compared to their non-error counterparts. Specifically, when a message is dispatched using the "tell" method, any errors emerging from the actor's message handler are interpreted as panics. This mechanism highlights the critical role of thorough error handling and validation in an actor's message processing routine, safeguarding against unexpected terminations.
 
 While most standard library types already implement the `Reply` trait, there might be exceptions. Should you encounter a standard library type not implementing `Reply`, you are encouraged to report this through an issue. For types outside the standard library that do not implement `Reply`, a straightforward workaround is to wrap your reply type in a `Result<T, kameo::error::Infallible>`, where `T` is your original type. Given that any `Result` type inherently implements `Reply`, this approach often obviates the need for custom implementations of the `Reply` trait for your types, especially in scenarios where using `Result` types is a common practice.
 
-### Deriving the Reply Trait
+## Deriving the Reply Trait
 
 Kameo simplifies the implementation of the `Reply` trait through the `#[derive(Reply)]` macro. This macro automatically provides the necessary trait implementations for a type, making it straightforward to create custom reply types that integrate seamlessly with Kameo's messaging system.
 
-#### Example Usage
+### Example Usage
 
 ```rust
 use kameo::Reply;
@@ -47,7 +47,7 @@ impl Message<MyRequest> for MyActor {
 
 In this example, `MyReply` is defined as a struct with data relevant to the response expected by a sender. By deriving the `Reply` trait, `MyReply` is automatically equipped to serve as a response in Kameo's messaging system. This pattern allows for rich, structured data to be communicated back to senders, facilitating complex interactions and workflows within your actor system.
 
-### Handling Replies
+## Handling Replies
 
 When dealing with ask requests, it's important to handle replies gracefully. This involves not only receiving the reply but also managing potential timeouts and errors that might occur during the interaction. If the message handler returned an error while processing a message, it will be returned as a `SendError::HandlerError`. Kameo's design encourages clear, concise handling of these scenarios, ensuring that your actor system remains robust and resilient under various operational conditions.
 

docs/core-concepts/requests.mdx

@@ -4,7 +4,7 @@ title: Requests Overview
 
 In the context of the Kameo, requests are the means through which actors communicate and interact with each other. These interactions are encapsulated in two primary forms: ask requests and tell requests. Understanding the nuances between these two types of requests is crucial for effectively managing actor behaviors and ensuring the robustness of your application.
 
-### Ask Requests
+## Ask Requests
 
 Ask requests are a form of message sending where the sender waits for a response from the receiver. This pattern is useful when the sender requires data or confirmation that an action has been completed before proceeding. Unlike tell requests, ask requests inherently support handling responses and errors, providing a direct way to deal with exceptional conditions.
 
@@ -16,7 +16,7 @@ Key Features of Ask Requests:
 	- **Mailbox Timeout**: For actors with a bounded mailbox, an optional `mailbox_timeout` can be specified. This timeout represents the maximum duration the request will wait in the queue before being processed. If the mailbox is full beyond this duration, the request may be dropped or an error returned.
 	- **Reply Timeout**: A `reply_timeout` can also be set, indicating how long the sender will wait for a response. This is particularly useful for avoiding indefinite blocking in scenarios where the receiver might be unable to process the request promptly.
 
-### Tell Requests
+## Tell Requests
 
 Tell requests, on the other hand, are the "fire-and-forget" type of messages. When a tell request is sent, the sender does not wait for any acknowledgment or reply from the receiver. This approach is ideal for notifications or commands where the outcome does not directly influence the sender's immediate actions.
 
@@ -26,7 +26,7 @@ Characteristics of Tell Requests:
 - **Error Handling**: Errors encountered by the actor while processing a tell request are treated as panics. By default, such panics may lead to the stopping of the actor, although this behavior can be customized via the `Actor::on_panic` hook to allow for error recovery or logging.
 - **Mailbox Timeout**: Similar to ask requests, a `mailbox_timeout` can be set for tell requests sent to actors with bounded mailboxes. This timeout helps manage the queuing behavior in scenarios where the actor's mailbox might be at capacity, ensuring that the system can gracefully handle backpressure.
 
-### Request Methods
+## Request Methods
 
 Sending a message can be done using one of the traits/methods listed in this table. Each cell describes the behaviour of the implementation depending on the mailbox type.
 
@@ -48,7 +48,7 @@ The column headings describe the following:
 | `TryBlockingMessageSend` :: `try_blocking_send` | Tries to send a message, blocking the thread while waiting for a reply, but failing if the mailbox is full. | Tries to send a message, blocking the thread while waiting for a reply.    | Tries to send a message, failing if the mailbox is full.                   | Sends a message.               |
 | `ForwardMessageSend` :: `forward`               | Sends a message, waiting for mailbox capacity with the reply being forwarded to a provided ReplySender.     | Sends a message, with the reply being forwarded to a provided ReplySender. | ❌                                                                          | ❌                              |
 
-#### **Supported Requests**
+### **Supported Requests**
 
 Depending on whether a message is being sent with a timeout set or to a remote actor, some methods may not be available. Below is table showing which methods are available under different circumstances.
 

docs/core-concepts/supervision.mdx

@@ -4,28 +4,28 @@ title: Supervision Overview
 
 Supervision is a critical concept in building resilient actor systems, ensuring that the system can recover from failures and continue operating without interruption. In Kameo, supervision and actor lifecycle management are facilitated through a combination of customizable behavior hooks and actor linking. This page discusses how to effectively use these features to create robust actor hierarchies and manage actor failures gracefully.
 
-### Customizing Actor Behavior on Panic
+## Customizing Actor Behavior on Panic
 
 When an actor panics, its default behavior can be customized using the `on_panic` hook within the `Actor` trait. This hook allows developers to define custom logic that should execute when an actor encounters a panic, providing a first line of defense in managing unexpected failures.
 
-### Linking Actors
+## Linking Actors
 
 Beyond individual actor behavior, Kameo supports linking actors together to create a supervision tree. This structure enables actors to monitor each other's health and respond to failures, forming the backbone of a self-healing system.
 
-#### Actor Links
+### Actor Links
 
 Actors can be linked using two primary methods, which establish parent-child and sibling relationships:
 
 - `ActorRef::link_child`
 - `ActorRef::link_together`
 
-#### Handling Link Failures
+### Handling Link Failures
 
 When a linked actor dies, the surviving actors can react to this event using the `on_link_died` hook in the `Actor` trait. This hook provides the ID of the deceased actor and the reason for its termination, enabling the surviving actors to implement custom logic, such as restarting the failed actor or taking other remedial actions.
 
 The default behavior for `on_link_died` is to stop the current actor if the linked actor died for any reason other than a normal shutdown. This conservative default ensures that failures are not silently ignored, promoting system stability by preventing dependent actors from continuing in an inconsistent state.
 
-#### Unlinking Actors
+## Unlinking Actors
 
 In some scenarios, it may be necessary to remove links between actors, either to restructure the supervision tree or in response to changing application dynamics. Kameo provides methods for this purpose: