update nav

zachary62 · zachary62 · commit 2fa60fe7d5ae · 2025-04-04T13:48:54.000-04:00
diff --git a/docs/AutoGen Core/index.md b/docs/AutoGen Core/index.md
@@ -36,19 +36,3 @@ flowchart TD
     A7 -- "Updates LLM context" --> A6
     A4 -- "Implemented as" --> A3
 ```
-
-## Chapters
-
-1. [Agent](01_agent.md)
-2. [Messaging System (Topic & Subscription)](02_messaging_system__topic___subscription_.md)
-3. [AgentRuntime](03_agentruntime.md)
-4. [Tool](04_tool.md)
-5. [ChatCompletionClient](05_chatcompletionclient.md)
-6. [ChatCompletionContext](06_chatcompletioncontext.md)
-7. [Memory](07_memory.md)
-8. [Component](08_component.md)
-
-
----
-
-Generated by [AI Codebase Knowledge Builder](https://github.com/The-Pocket/Tutorial-Codebase-Knowledge)
diff --git a/docs/Browser Use/index.md b/docs/Browser Use/index.md
@@ -42,19 +42,3 @@ flowchart TD
     A5 -- "Defines structure for Agent..." --> A6
     A7 -- "Receives events from" --> A0
 ```
-
-## Chapters
-
-1. [Agent](01_agent.md)
-2. [System Prompt](02_system_prompt.md)
-3. [BrowserContext](03_browsercontext.md)
-4. [DOM Representation](04_dom_representation.md)
-5. [Action Controller & Registry](05_action_controller___registry.md)
-6. [Message Manager](06_message_manager.md)
-7. [Data Structures (Views)](07_data_structures__views_.md)
-8. [Telemetry Service](08_telemetry_service.md)
-
-
----
-
-Generated by [AI Codebase Knowledge Builder](https://github.com/The-Pocket/Tutorial-Codebase-Knowledge)
diff --git a/docs/Celery/02_configuration.md b/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:
diff --git a/docs/Celery/03_task.md b/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.
diff --git a/docs/Celery/04_broker_connection__amqp_.md b/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!
diff --git a/docs/Celery/05_worker.md b/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).
diff --git a/docs/Celery/06_result_backend.md b/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).
diff --git a/docs/Celery/07_beat__scheduler_.md b/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?
diff --git a/docs/Celery/08_canvas__signatures___primitives_.md b/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?
diff --git a/docs/Celery/09_events.md b/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?"
diff --git a/docs/Celery/10_bootsteps.md b/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).
diff --git a/docs/Celery/index.md b/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)
diff --git a/docs/Click/01_command___group.md b/docs/Click/01_command___group.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Command & Group"
+parent: "Click"
+nav_order: 1
+---
+
 # Chapter 1: Commands and Groups: The Building Blocks
 
 Welcome to your first step in learning Click! Imagine you want to create your own command-line tool, maybe something like `git` or `docker`. How do you tell your program what to do when someone types `git commit` or `docker build`? That's where **Commands** and **Groups** come in. They are the fundamental building blocks for any Click application.
diff --git a/docs/Click/02_decorators.md b/docs/Click/02_decorators.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Decorators"
+parent: "Click"
+nav_order: 2
+---
+
 # Chapter 2: Decorators: Magic Wands for Your Functions
 
 In [Chapter 1: Commands and Groups](01_command___group.md), we learned how to create basic command-line actions (`Command`) and group them together (`Group`). You might have noticed those strange `@click.command()` and `@click.group()` lines above our functions. What are they, and why do we use them?
diff --git a/docs/Click/03_parameter__option___argument_.md b/docs/Click/03_parameter__option___argument_.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Parameter (Option & Argument)"
+parent: "Click"
+nav_order: 3
+---
+
 # Chapter 3: Parameter (Option / Argument) - Giving Your Commands Input
 
 In the last chapter, [Decorators](02_decorators.md), we saw how decorators like `@click.command()` and `@click.option()` act like magic wands, transforming our Python functions into CLI commands and adding features like command-line options.
diff --git a/docs/Click/04_paramtype.md b/docs/Click/04_paramtype.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "ParamType"
+parent: "Click"
+nav_order: 4
+---
+
 # Chapter 4: ParamType - Checking and Converting Inputs
 
 In [Chapter 3: Parameter (Option / Argument)](03_parameter__option___argument_.md), we learned how to define inputs for our commands using `@click.option` and `@click.argument`. Our `greet` command could take a `--name` option, and our `copy` command took `SRC` and `DST` arguments.
diff --git a/docs/Click/05_context.md b/docs/Click/05_context.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Context"
+parent: "Click"
+nav_order: 5
+---
+
 # Chapter 5: Context - The Command's Nervous System
 
 In the last chapter, [ParamType](04_paramtype.md), we saw how Click helps validate and convert user input into the right Python types, making our commands more robust. We used types like `click.INT` and `click.Path` to ensure data correctness.
diff --git a/docs/Click/06_term_ui__terminal_user_interface_.md b/docs/Click/06_term_ui__terminal_user_interface_.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Term UI (Terminal User Interface)"
+parent: "Click"
+nav_order: 6
+---
+
 # Chapter 6: Term UI (Terminal User Interface)
 
 Welcome back! In [Chapter 5: Context](05_context.md), we learned how Click uses the `Context` object (`ctx`) to manage the state of a command while it's running, allowing us to share information and call other commands.
diff --git a/docs/Click/07_click_exceptions.md b/docs/Click/07_click_exceptions.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Click Exceptions"
+parent: "Click"
+nav_order: 7
+---
+
 # Chapter 7: Click Exceptions - Handling Errors Gracefully
 
 In the last chapter, [Chapter 6: Term UI (Terminal User Interface)](06_term_ui__terminal_user_interface_.md), we explored how to make our command-line tools interactive and visually appealing using functions like `click.prompt`, `click.confirm`, and `click.secho`. We learned how to communicate effectively *with* the user.
@@ -153,7 +160,7 @@ What exactly happens when a Click exception is raised, either by Click itself or
     *   The formatted message is printed to `stderr` using `click.echo()`, respecting color settings from the context.
 5.  **Exit:** After showing the message, Click calls `sys.exit()` with the exception's `exit_code` (usually `1` for general errors, `2` for usage errors). This terminates the program and signals the error status to the calling shell or script.
 
-Here’s a simplified sequence diagram for the `BadParameter` case when a user provides invalid input that fails type conversion:
+Here's a simplified sequence diagram for the `BadParameter` case when a user provides invalid input that fails type conversion:
 
 ```mermaid
 sequenceDiagram
diff --git a/docs/Click/index.md b/docs/Click/index.md
@@ -35,17 +35,3 @@ flowchart TD
     A4 -- "Injects via @pass_context" --> A0
 ```
 
-## Chapters
-
-1. [Command / Group](01_command___group.md)
-2. [Decorators](02_decorators.md)
-3. [Parameter (Option / Argument)](03_parameter__option___argument_.md)
-4. [ParamType](04_paramtype.md)
-5. [Context](05_context.md)
-6. [Term UI (Terminal User Interface)](06_term_ui__terminal_user_interface_.md)
-7. [Click Exceptions](07_click_exceptions.md)
-
-
----
-
-Generated by [AI Codebase Knowledge Builder](https://github.com/The-Pocket/Tutorial-Codebase-Knowledge)
diff --git a/docs/Crawl4AI/index.md b/docs/Crawl4AI/index.md
@@ -38,22 +38,4 @@ flowchart TD
     A7 -- "Processes Links from" --> A5
     A3 -- "Provides Cleaned HTML to" --> A9
     A1 -- "Specifies Content Filter" --> A9
-```
-
-## Chapters
-
-1. [AsyncCrawlerStrategy](01_asynccrawlerstrategy.md)
-2. [AsyncWebCrawler](02_asyncwebcrawler.md)
-3. [CrawlerRunConfig](03_crawlerrunconfig.md)
-4. [ContentScrapingStrategy](04_contentscrapingstrategy.md)
-5. [RelevantContentFilter](05_relevantcontentfilter.md)
-6. [ExtractionStrategy](06_extractionstrategy.md)
-7. [CrawlResult](07_crawlresult.md)
-8. [DeepCrawlStrategy](08_deepcrawlstrategy.md)
-9. [CacheContext / CacheMode](09_cachecontext___cachemode.md)
-10. [BaseDispatcher](10_basedispatcher.md)
-
-
----
-
-Generated by [AI Codebase Knowledge Builder](https://github.com/The-Pocket/Tutorial-Codebase-Knowledge)
+```
diff --git a/docs/CrewAI/01_crew.md b/docs/CrewAI/01_crew.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Crew"
+parent: "CrewAI"
+nav_order: 1
+---
+
 # Chapter 1: Crew - Your AI Team Manager
 
 Welcome to the world of CrewAI! We're excited to help you build teams of AI agents that can work together to accomplish complex tasks.
diff --git a/docs/CrewAI/02_agent.md b/docs/CrewAI/02_agent.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Agent"
+parent: "CrewAI"
+nav_order: 2
+---
+
 # Chapter 2: Agent - Your Specialized AI Worker
 
 In [Chapter 1](01_crew.md), we learned about the `Crew` – the manager that organizes our AI team. But a manager needs a team to manage! That's where `Agent`s come in.
diff --git a/docs/CrewAI/03_task.md b/docs/CrewAI/03_task.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Task"
+parent: "CrewAI"
+nav_order: 3
+---
+
 # Chapter 3: Task - Defining the Work
 
 In [Chapter 1](01_crew.md), we met the `Crew` - our AI team manager. In [Chapter 2](02_agent.md), we met the `Agent`s - our specialized AI workers. Now, we need to tell these agents *exactly* what to do. How do we give them specific assignments?
diff --git a/docs/CrewAI/04_tool.md b/docs/CrewAI/04_tool.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Tool"
+parent: "CrewAI"
+nav_order: 4
+---
+
 # Chapter 4: Tool - Equipping Your Agents
 
 In [Chapter 3: Task](03_task.md), we learned how to define specific assignments (`Task`s) for our AI `Agent`s. We told the 'Travel Researcher' agent to find sunny cities and the 'Activity Planner' agent to create an itinerary.
diff --git a/docs/CrewAI/05_process.md b/docs/CrewAI/05_process.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Process"
+parent: "CrewAI"
+nav_order: 5
+---
+
 # Chapter 5: Process - Orchestrating the Workflow
 
 In [Chapter 4: Tool](04_tool.md), we learned how to give our [Agent](02_agent.md)s special abilities using `Tool`s, like searching the web. Now we have specialized agents, defined tasks, and equipped agents. But how do they actually *work together*? Does Agent 1 finish its work before Agent 2 starts? Or is there a manager overseeing everything?
diff --git a/docs/CrewAI/index.md b/docs/CrewAI/index.md
@@ -34,20 +34,4 @@ flowchart TD
     A0 -- "Uses as brain" --> A5
     A0 -- "Queries" --> A7
     A1 -- "Assigned to" --> A0
-```
-
-## Chapters
-
-1. [Crew](01_crew.md)
-2. [Agent](02_agent.md)
-3. [Task](03_task.md)
-4. [Tool](04_tool.md)
-5. [Process](05_process.md)
-6. [LLM](06_llm.md)
-7. [Memory](07_memory.md)
-8. [Knowledge](08_knowledge.md)
-
-
----
-
-Generated by [AI Codebase Knowledge Builder](https://github.com/The-Pocket/Tutorial-Codebase-Knowledge)
+```
diff --git a/docs/DSPy/index.md b/docs/DSPy/index.md
@@ -44,22 +44,4 @@ flowchart TD
     A9 -- "Configures default" --> A3
     A9 -- "Configures default" --> A4
     A9 -- "Configures default" --> A8
-```
-
-## Chapters
-
-1. [Module / Program](01_module___program.md)
-2. [Signature](02_signature.md)
-3. [Example](03_example.md)
-4. [Predict](04_predict.md)
-5. [LM (Language Model Client)](05_lm__language_model_client_.md)
-6. [RM (Retrieval Model Client)](06_rm__retrieval_model_client_.md)
-7. [Evaluate](07_evaluate.md)
-8. [Teleprompter / Optimizer](08_teleprompter___optimizer.md)
-9. [Adapter](09_adapter.md)
-10. [Settings](10_settings.md)
-
-
----
-
-Generated by [AI Codebase Knowledge Builder](https://github.com/The-Pocket/Tutorial-Codebase-Knowledge)
+```
diff --git a/docs/FastAPI/index.md b/docs/FastAPI/index.md
diff --git a/docs/Flask/index.md b/docs/Flask/index.md
diff --git a/docs/LangGraph/index.md b/docs/LangGraph/index.md
diff --git a/docs/LevelDB/index.md b/docs/LevelDB/index.md
diff --git a/docs/MCP Python SDK/index.md b/docs/MCP Python SDK/index.md
diff --git a/docs/NumPy Core/index.md b/docs/NumPy Core/index.md
diff --git a/docs/OpenManus/index.md b/docs/OpenManus/index.md
diff --git a/docs/Pydantic Core/index.md b/docs/Pydantic Core/index.md
diff --git a/docs/Requests/index.md b/docs/Requests/index.md
diff --git a/docs/SmolaAgents/index.md b/docs/SmolaAgents/index.md
