update nav

docs/Celery/02_configuration.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Configuration"
+parent: "Celery"
+nav_order: 2
+---
+
 # Chapter 2: Configuration - Telling Celery How to Work
 
 In [Chapter 1: The Celery App](01_celery_app.md), we created our first `Celery` app instance. We gave it a name and told it where our message broker and result backend were located using the `broker` and `backend` arguments:

docs/Celery/03_task.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Task"
+parent: "Celery"
+nav_order: 3
+---
+
 # Chapter 3: Task - The Job Description
 
 In [Chapter 1: The Celery App](01_celery_app.md), we set up our Celery headquarters, and in [Chapter 2: Configuration](02_configuration.md), we learned how to give it instructions. Now, we need to define the *actual work* we want Celery to do. This is where **Tasks** come in.

docs/Celery/04_broker_connection__amqp_.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Broker Connection (AMQP)"
+parent: "Celery"
+nav_order: 4
+---
+
 # Chapter 4: Broker Connection (AMQP) - Celery's Postal Service
 
 In [Chapter 3: Task](03_task.md), we learned how to define "job descriptions" (Tasks) like `add(x, y)` and how to request them using `.delay()`. But when you call `add.delay(2, 2)`, how does that request actually *get* to a worker process that can perform the addition? It doesn't just magically appear!

docs/Celery/05_worker.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Worker"
+parent: "Celery"
+nav_order: 5
+---
+
 # Chapter 5: Worker - The Task Doer
 
 In [Chapter 4: Broker Connection (AMQP)](04_broker_connection__amqp_.md), we learned how Celery uses a message broker, like a postal service, to send task messages. When you call `add.delay(2, 2)`, a message asking to run the `add` task with arguments `(2, 2)` gets dropped into a mailbox (the broker queue).

docs/Celery/06_result_backend.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Result Backend"
+parent: "Celery"
+nav_order: 6
+---
+
 # Chapter 6: Result Backend - Checking Your Task's Homework
 
 In [Chapter 5: Worker](05_worker.md), we met the Celery Worker, the diligent entity that picks up task messages from the [Broker Connection (AMQP)](04_broker_connection__amqp_.md) and executes the code defined in our [Task](03_task.md).

docs/Celery/07_beat__scheduler_.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Beat (Scheduler)"
+parent: "Celery"
+nav_order: 7
+---
+
 # Chapter 7: Beat (Scheduler) - Celery's Alarm Clock
 
 In the last chapter, [Chapter 6: Result Backend](06_result_backend.md), we learned how to track the status and retrieve the results of our background tasks. This is great when we manually trigger tasks from our application. But what if we want tasks to run automatically, without us needing to press a button every time?

docs/Celery/08_canvas__signatures___primitives_.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Canvas (Signatures & Primitives)"
+parent: "Celery"
+nav_order: 8
+---
+
 # Chapter 8: Canvas (Signatures & Primitives) - Building Task Workflows
 
 In the previous chapter, [Chapter 7: Beat (Scheduler)](07_beat__scheduler_.md), we learned how to schedule tasks to run automatically at specific times using Celery Beat. This is great for recurring jobs. But what if you need to run a sequence of tasks, where one task depends on the result of another? Or run multiple tasks in parallel and then collect their results?

docs/Celery/09_events.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Events"
+parent: "Celery"
+nav_order: 9
+---
+
 # Chapter 9: Events - Listening to Celery's Heartbeat
 
 In [Chapter 8: Canvas (Signatures & Primitives)](08_canvas__signatures___primitives_.md), we saw how to build complex workflows by chaining tasks together or running them in parallel. But as your Celery system gets busier, you might wonder: "What are my workers doing *right now*? Which tasks have started? Which ones finished successfully or failed?"

docs/Celery/10_bootsteps.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Bootsteps"
+parent: "Celery"
+nav_order: 10
+---
+
 # Chapter 10: Bootsteps - How Celery Workers Start Up
 
 In [Chapter 9: Events](09_events.md), we learned how to monitor the real-time activity within our Celery system. We've now covered most of the key parts of Celery: the [Celery App](01_celery_app.md), [Task](03_task.md)s, the [Broker Connection (AMQP)](04_broker_connection__amqp_.md), the [Worker](05_worker.md), the [Result Backend](06_result_backend.md), [Beat (Scheduler)](07_beat__scheduler_.md), [Canvas (Signatures & Primitives)](08_canvas__signatures___primitives_.md), and [Events](09_events.md).

docs/Celery/index.md

@@ -38,20 +38,3 @@ flowchart TD
     A9 -- "Manages connection via" --> A3
 ```
 
-## Chapters
-
-1. [Celery App](01_celery_app.md)
-2. [Configuration](02_configuration.md)
-3. [Task](03_task.md)
-4. [Broker Connection (AMQP)](04_broker_connection__amqp_.md)
-5. [Worker](05_worker.md)
-6. [Result Backend](06_result_backend.md)
-7. [Beat (Scheduler)](07_beat__scheduler_.md)
-8. [Canvas (Signatures & Primitives)](08_canvas__signatures___primitives_.md)
-9. [Events](09_events.md)
-10. [Bootsteps](10_bootsteps.md)
-
-
----
-
-Generated by [AI Codebase Knowledge Builder](https://github.com/The-Pocket/Tutorial-Codebase-Knowledge)