update nav

zachary62 · zachary62 · commit 14df136587e7 · 2025-04-04T13:44:45.000-04:00
diff --git a/docs/AutoGen Core/01_agent.md b/docs/AutoGen Core/01_agent.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Agent"
+parent: "AutoGen Core"
+nav_order: 1
+---
+
 # Chapter 1: Agent - The Workers of AutoGen
 
 Welcome to the AutoGen Core tutorial! We're excited to guide you through building powerful applications with autonomous agents.
diff --git a/docs/AutoGen Core/02_messaging_system__topic___subscription_.md b/docs/AutoGen Core/02_messaging_system__topic___subscription_.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Messaging System"
+parent: "AutoGen Core"
+nav_order: 2
+---
+
 # Chapter 2: Messaging System (Topic & Subscription)
 
 In [Chapter 1: Agent](01_agent.md), we learned about Agents as individual workers. But how do they coordinate when one agent doesn't know exactly *who* needs the information it produces? Imagine our Researcher finds some facts. Maybe the Writer needs them, but maybe a Fact-Checker agent or a Summary agent also needs them later. How can the Researcher just announce "Here are the facts!" without needing a specific mailing list?
diff --git a/docs/AutoGen Core/03_agentruntime.md b/docs/AutoGen Core/03_agentruntime.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "AgentRuntime"
+parent: "AutoGen Core"
+nav_order: 3
+---
+
 # Chapter 3: AgentRuntime - The Office Manager
 
 In [Chapter 1: Agent](01_agent.md), we met the workers (`Agent`) of our system. In [Chapter 2: Messaging System](02_messaging_system__topic___subscription_.md), we saw how they can communicate broadly using topics and subscriptions. But who hires these agents? Who actually delivers the messages, whether direct or published? And who keeps the whole system running smoothly?
diff --git a/docs/AutoGen Core/04_tool.md b/docs/AutoGen Core/04_tool.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Tool"
+parent: "AutoGen Core"
+nav_order: 4
+---
+
 # Chapter 4: Tool - Giving Agents Specific Capabilities
 
 In the previous chapters, we learned about Agents as workers ([Chapter 1](01_agent.md)), how they can communicate directly or using announcements ([Chapter 2](02_messaging_system__topic___subscription_.md)), and the `AgentRuntime` that manages them ([Chapter 3](03_agentruntime.md)).
diff --git a/docs/AutoGen Core/05_chatcompletionclient.md b/docs/AutoGen Core/05_chatcompletionclient.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "ChatCompletionClient"
+parent: "AutoGen Core"
+nav_order: 5
+---
+
 # Chapter 5: ChatCompletionClient - Talking to the Brains
 
 So far, we've learned about:
diff --git a/docs/AutoGen Core/06_chatcompletioncontext.md b/docs/AutoGen Core/06_chatcompletioncontext.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "ChatCompletionContext"
+parent: "AutoGen Core"
+nav_order: 6
+---
+
 # Chapter 6: ChatCompletionContext - Remembering the Conversation
 
 In [Chapter 5: ChatCompletionClient](05_chatcompletionclient.md), we learned how agents talk to Large Language Models (LLMs) using a `ChatCompletionClient`. We saw that we need to send a list of `messages` (the conversation history) to the LLM so it knows the context.
diff --git a/docs/AutoGen Core/07_memory.md b/docs/AutoGen Core/07_memory.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Memory"
+parent: "AutoGen Core"
+nav_order: 7
+---
+
 # Chapter 7: Memory - The Agent's Notebook
 
 In [Chapter 6: ChatCompletionContext](06_chatcompletioncontext.md), we saw how agents manage the *short-term* history of a single conversation before talking to an LLM. It's like remembering what was just said in the last few minutes.
diff --git a/docs/AutoGen Core/08_component.md b/docs/AutoGen Core/08_component.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Component"
+parent: "AutoGen Core"
+nav_order: 8
+---
+
 # Chapter 8: Component - The Standardized Building Blocks
 
 Welcome to Chapter 8! In our journey so far, we've met several key players in AutoGen Core:
diff --git a/docs/AutoGen Core/index.md b/docs/AutoGen Core/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "AutoGen Core"
+nav_order: 3
+has_children: true
+---
+
 # Tutorial: AutoGen Core
 
 AutoGen Core helps you build applications with multiple **_Agents_** that can work together.
diff --git a/docs/Browser Use/01_agent.md b/docs/Browser Use/01_agent.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Agent"
+parent: "Browser Use"
+nav_order: 1
+---
+
 # Chapter 1: The Agent - Your Browser Assistant's Brain
 
 Welcome to the `Browser Use` tutorial! We're excited to help you learn how to automate web tasks using the power of Large Language Models (LLMs).
diff --git a/docs/Browser Use/02_system_prompt.md b/docs/Browser Use/02_system_prompt.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "System Prompt"
+parent: "Browser Use"
+nav_order: 2
+---
+
 # Chapter 2: The System Prompt - Setting the Rules for Your AI Assistant
 
 In [Chapter 1: The Agent](01_agent.md), we met the `Agent`, our project manager for automating browser tasks. We saw it consults a Large Language Model (LLM) – the "planner" – to decide the next steps based on the current state of the webpage. But how does the Agent tell the LLM *how* it should think, behave, and respond? Just giving it the task isn't enough!
diff --git a/docs/Browser Use/03_browsercontext.md b/docs/Browser Use/03_browsercontext.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "BrowserContext"
+parent: "Browser Use"
+nav_order: 3
+---
+
 # Chapter 3: BrowserContext - The Agent's Isolated Workspace
 
 In the [previous chapter](02_system_prompt.md), we learned how the `System Prompt` acts as the rulebook for the AI assistant (LLM) that guides our `Agent`. We know the Agent uses the LLM to decide *what* to do next based on the current situation in the browser.
diff --git a/docs/Browser Use/04_dom_representation.md b/docs/Browser Use/04_dom_representation.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "DOM Representation"
+parent: "Browser Use"
+nav_order: 4
+---
+
 # Chapter 4: DOM Representation - Mapping the Webpage
 
 In the [previous chapter](03_browsercontext.md), we learned about the `BrowserContext`, the Agent's private workspace for browsing. We saw that the Agent uses `browser_context.get_state()` to get a snapshot of the current webpage. But how does the Agent actually *understand* the content of that snapshot?
diff --git a/docs/Browser Use/05_action_controller___registry.md b/docs/Browser Use/05_action_controller___registry.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Action Controller & Registry"
+parent: "Browser Use"
+nav_order: 5
+---
+
 # Chapter 5: Action Controller & Registry - The Agent's Hands and Toolbox
 
 In the [previous chapter](04_dom_representation.md), we saw how the `DomService` creates a simplified map (`DOMState`) of the webpage, allowing the Agent and its LLM planner to identify interactive elements like buttons and input fields using unique numbers (`highlight_index`). The LLM uses this map to decide *what* specific action to take next, like "click element [5]" or "type 'hello world' into element [12]".
diff --git a/docs/Browser Use/06_message_manager.md b/docs/Browser Use/06_message_manager.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Message Manager"
+parent: "Browser Use"
+nav_order: 6
+---
+
 # Chapter 6: Message Manager - Keeping the Conversation Straight
 
 In the [previous chapter](05_action_controller___registry.md), we learned how the `Action Controller` and `Registry` act as the Agent's "hands" and "toolbox", executing the specific actions decided by the LLM planner. But how does the LLM get all the information it needs to make those decisions in the first place? How does the Agent keep track of the ongoing conversation, including what it "saw" on the page and what happened after each action?
diff --git a/docs/Browser Use/07_data_structures__views_.md b/docs/Browser Use/07_data_structures__views_.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Data Structures (Views)"
+parent: "Browser Use"
+nav_order: 7
+---
+
 # Chapter 7: Data Structures (Views) - The Project's Blueprints
 
 In the [previous chapter](06_message_manager.md), we saw how the `MessageManager` acts like a secretary, carefully organizing the conversation between the [Agent](01_agent.md) and the LLM. It manages different pieces of information – the browser's current state, the LLM's plan, the results of actions, and more.
diff --git a/docs/Browser Use/08_telemetry_service.md b/docs/Browser Use/08_telemetry_service.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Telemetry Service"
+parent: "Browser Use"
+nav_order: 8
+---
+
 # Chapter 8: Telemetry Service - Helping Improve the Project (Optional)
 
 In the [previous chapter](07_data_structures__views_.md), we explored the essential blueprints (`Data Structures (Views)`) that keep communication clear and consistent between all the parts of `Browser Use`. We saw how components like the [Agent](01_agent.md) and the [Action Controller & Registry](05_action_controller___registry.md) use these blueprints to exchange information reliably.
diff --git a/docs/Browser Use/index.md b/docs/Browser Use/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Browser Use"
+nav_order: 4
+has_children: true
+---
+
 # Tutorial: Browser Use
 
 **Browser Use** is a project that allows an *AI agent* to control a web browser and perform tasks automatically.
diff --git a/docs/Celery/01_celery_app.md b/docs/Celery/01_celery_app.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Celery App"
+parent: "Celery"
+nav_order: 1
+---
+
 # Chapter 1: The Celery App - Your Task Headquarters
 
 Welcome to the world of Celery! If you've ever thought, "I wish this slow part of my web request could run somewhere else later," or "How can I process this huge amount of data without freezing my main application?", then Celery is here to help.
diff --git a/docs/Celery/index.md b/docs/Celery/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Celery"
+nav_order: 5
+has_children: true
+---
+
 # Tutorial: Celery
 
 Celery is a system for running **distributed tasks** *asynchronously*. You define *units of work* (Tasks) in your Python code. When you want a task to run, you send a message using a **message broker** (like RabbitMQ or Redis). One or more **Worker** processes are running in the background, listening for these messages. When a worker receives a message, it executes the corresponding task. Optionally, the task's result (or any error) can be stored in a **Result Backend** (like Redis or a database) so you can check its status or retrieve the output later. Celery helps manage this whole process, making it easier to handle background jobs, scheduled tasks, and complex workflows.
diff --git a/docs/Click/index.md b/docs/Click/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Click"
+nav_order: 6
+has_children: true
+---
+
 # Tutorial: Click
 
 Click is a Python library that makes creating **command-line interfaces (CLIs)** *easy and fun*.
diff --git a/docs/Crawl4AI/index.md b/docs/Crawl4AI/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Crawl4AI"
+nav_order: 7
+has_children: true
+---
+
 # Tutorial: Crawl4AI
 
 `Crawl4AI` is a flexible Python library for *asynchronously crawling websites* and *extracting structured content*, specifically designed for **AI use cases**.
diff --git a/docs/CrewAI/index.md b/docs/CrewAI/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "CrewAI"
+nav_order: 8
+has_children: true
+---
+
 # Tutorial: CrewAI
 
 **CrewAI** is a framework for orchestrating *autonomous AI agents*.
diff --git a/docs/DSPy/index.md b/docs/DSPy/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "DSPy"
+nav_order: 9
+has_children: true
+---
+
 # Tutorial: DSPy
 
 DSPy helps you build and optimize *programs* that use **Language Models (LMs)** and **Retrieval Models (RMs)**.
diff --git a/docs/FastAPI/index.md b/docs/FastAPI/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "FastAPI"
+nav_order: 10
+has_children: true
+---
+
 # Tutorial: FastAPI
 
 FastAPI is a modern, *high-performance* web framework for building APIs with Python.
diff --git a/docs/Flask/index.md b/docs/Flask/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Flask"
+nav_order: 11
+has_children: true
+---
+
 # Tutorial: Flask
 
 Flask is a lightweight **web framework** for Python.
diff --git a/docs/LangGraph/index.md b/docs/LangGraph/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "LangGraph"
+nav_order: 12
+has_children: true
+---
+
 # Tutorial: LangGraph
 
 LangGraph helps you build complex **stateful applications**, like chatbots or agents, using a *graph-based approach*.
diff --git a/docs/LevelDB/index.md b/docs/LevelDB/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "LevelDB"
+nav_order: 13
+has_children: true
+---
+
 # Tutorial: LevelDB
 
 LevelDB is a fast *key-value storage library* written at Google.
diff --git a/docs/MCP Python SDK/index.md b/docs/MCP Python SDK/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "MCP Python SDK"
+nav_order: 14
+has_children: true
+---
+
 # Tutorial: MCP Python SDK
 
 The **MCP Python SDK** helps developers build applications (clients and servers) that talk to each other using the *Model Context Protocol (MCP)* specification.
diff --git a/docs/NumPy Core/index.md b/docs/NumPy Core/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "NumPy Core"
+nav_order: 15
+has_children: true
+---
+
 # Tutorial: NumPy Core
 
 NumPy provides the powerful **ndarray** object, a *multi-dimensional grid* optimized for numerical computations on large datasets. It uses **dtypes** (data type objects) to precisely define the *kind of data* (like integers or floating-point numbers) stored within an array, ensuring memory efficiency and enabling optimized low-level operations. NumPy also features **ufuncs** (universal functions), which are functions like `add` or `sin` designed to operate *element-wise* on entire arrays very quickly, leveraging compiled code. Together, these components form the foundation for high-performance scientific computing in Python.
diff --git a/docs/OpenManus/index.md b/docs/OpenManus/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "OpenManus"
+nav_order: 16
+has_children: true
+---
+
 # Tutorial: OpenManus
 
 OpenManus is a framework for building autonomous *AI agents*.
diff --git a/docs/Pydantic Core/index.md b/docs/Pydantic Core/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Pydantic Core"
+nav_order: 17
+has_children: true
+---
+
 # Tutorial: Pydantic Core
 
 Pydantic Core provides the fundamental machinery for **data validation**, **parsing**, and **serialization** in Pydantic. It takes Python *type hints* and uses them to define how data should be structured and processed. Users typically interact with it by defining classes that inherit from `BaseModel`, which automatically gets validation and serialization capabilities based on its annotated fields. Pydantic Core ensures data conforms to the defined types and allows converting between Python objects and formats like JSON efficiently, leveraging Rust for performance.
diff --git a/docs/Requests/index.md b/docs/Requests/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Requests"
+nav_order: 18
+has_children: true
+---
+
 # Tutorial: Requests
 
 Requests is a Python library that makes sending *HTTP requests* incredibly simple.
diff --git a/docs/SmolaAgents/index.md b/docs/SmolaAgents/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "SmolaAgents"
+nav_order: 19
+has_children: true
+---
+
 # Tutorial: SmolaAgents
 
 `SmolaAgents` is a project for building *autonomous agents* that can solve complex tasks.
diff --git a/docs/_config.yml b/docs/_config.yml
@@ -1,5 +1,5 @@
 # Basic site settings
-title: Codebase to Tutorial
+title: Codebase2Tutorial
 
 # Theme settings
 remote_theme: just-the-docs/just-the-docs
