update nav

zachary62 · zachary62 · commit 581aa6b08f51 · 2025-04-04T14:20:15.000-04:00
diff --git a/docs/OpenManus/06_schema.md b/docs/OpenManus/06_schema.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Schema"
+parent: "OpenManus"
+nav_order: 6
+---
+
 # Chapter 6: Schema - The Official Data Forms
 
 In [Chapter 5: BaseFlow](05_baseflow.md), we saw how Flows act like project managers, coordinating different [Agents](03_baseagent.md) and [Tools](04_tool___toolcollection.md) to complete complex tasks. But for all these different parts (Flows, Agents, LLMs, Tools) to work together smoothly, they need to speak the same language and use the same formats when exchanging information.
diff --git a/docs/OpenManus/07_configuration__config_.md b/docs/OpenManus/07_configuration__config_.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Configuration (config)"
+parent: "OpenManus"
+nav_order: 7
+---
+
 # Chapter 7: Configuration (Config)
 
 Welcome to Chapter 7! In [Chapter 6: Schema](06_schema.md), we learned how OpenManus uses schemas to define the structure of data passed between different components, like official forms ensuring everyone fills them out correctly.
diff --git a/docs/OpenManus/08_dockersandbox.md b/docs/OpenManus/08_dockersandbox.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "DockerSandbox"
+parent: "OpenManus"
+nav_order: 8
+---
+
 # Chapter 8: DockerSandbox - A Safe Play Area for Code
 
 Welcome to Chapter 8! In [Chapter 7: Configuration (Config)](07_configuration__config_.md), we learned how OpenManus manages settings using the `config.toml` file and the `Config` object. We saw settings for the [LLM](01_llm.md), search tools, and something called `[sandbox]`. Now, let's dive into what that sandbox is!
diff --git a/docs/OpenManus/09_mcp__model_context_protocol_.md b/docs/OpenManus/09_mcp__model_context_protocol_.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "MCP (Model Context Protocol)"
+parent: "OpenManus"
+nav_order: 9
+---
+
 # Chapter 9: MCP (Model Context Protocol)
 
 Welcome to the final chapter of our core concepts tutorial! In [Chapter 8: DockerSandbox](08_dockersandbox.md), we saw how OpenManus can safely run code in an isolated environment. Now, let's explore a powerful way to extend your agent's capabilities *without* changing its internal code: the **Model Context Protocol (MCP)**.
diff --git a/docs/Pydantic Core/01_basemodel.md b/docs/Pydantic Core/01_basemodel.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "BaseModel"
+parent: "Pydantic Core"
+nav_order: 1
+---
+
 # Chapter 1: BaseModel - Your Data Blueprint
 
 Welcome to the Pydantic tutorial! We're excited to guide you through the powerful features of Pydantic, starting with the absolute core concept: `BaseModel`.
diff --git a/docs/Pydantic Core/02_fields__fieldinfo___field_function_.md b/docs/Pydantic Core/02_fields__fieldinfo___field_function_.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Fields (FieldInfo & Field function)"
+parent: "Pydantic Core"
+nav_order: 2
+---
+
 # Chapter 2: Customizing Your Blueprint's Rooms - Fields
 
 In [Chapter 1: BaseModel - Your Data Blueprint](01_basemodel.md), we learned how `BaseModel` acts like a blueprint for our data, defining the expected structure and types using simple Python type hints. We saw how Pydantic uses this blueprint to parse, validate, and serialize data.
diff --git a/docs/Pydantic Core/03_configuration__configdict___configwrapper_.md b/docs/Pydantic Core/03_configuration__configdict___configwrapper_.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Configuration (ConfigDict & ConfigWrapper)"
+parent: "Pydantic Core"
+nav_order: 3
+---
+
 # Chapter 3: Configuring Your Blueprint - Model Settings
 
 In [Chapter 1](01_basemodel.md), we learned about `BaseModel` as our data blueprint, and in [Chapter 2](02_fields__fieldinfo___field_function_.md), we saw how `Field()` lets us add specific notes (like defaults or aliases) to individual rooms (fields) on that blueprint.
diff --git a/docs/Pydantic Core/04_custom_logic__decorators___annotated_helpers_.md b/docs/Pydantic Core/04_custom_logic__decorators___annotated_helpers_.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Custom Logic (Decorators & Annotated Helpers)"
+parent: "Pydantic Core"
+nav_order: 4
+---
+
 # Chapter 4: Custom Logic (Decorators & Annotated Helpers)
 
 In [Chapter 3: Configuration (ConfigDict / ConfigWrapper)](03_configuration__configdict___configwrapper_.md), we learned how to set global rules for our data blueprints using `model_config`. But what if we need more specific, custom rules or transformations that go beyond simple settings?
diff --git a/docs/Pydantic Core/05_core_schema___validation_serialization.md b/docs/Pydantic Core/05_core_schema___validation_serialization.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Core Schema & Validation/Serialization"
+parent: "Pydantic Core"
+nav_order: 5
+---
+
 # Chapter 5: Core Schema & Validation/Serialization
 
 In the previous chapters, we've seen how to define data structures using [BaseModel](01_basemodel.md), customize fields with [Field()](02_fields__fieldinfo___field_function_.md), set model-wide behavior with [Configuration](03_configuration__configdict___configwrapper_.md), and even add [Custom Logic](04_custom_logic__decorators___annotated_helpers_.md) using decorators. You might be wondering: how does Pydantic take all these Python definitions and use them to perform such fast and reliable validation and serialization?
diff --git a/docs/Pydantic Core/06_typeadapter.md b/docs/Pydantic Core/06_typeadapter.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "TypeAdapter"
+parent: "Pydantic Core"
+nav_order: 6
+---
+
 # Chapter 6: TypeAdapter - Your Universal Data Handler
 
 Welcome to the final chapter of our Pydantic Core tutorial! In [Chapter 5: Core Schema & Validation/Serialization](05_core_schema___validation_serialization.md), we dove deep into how Pydantic uses the `CoreSchema` and the `pydantic-core` engine to efficiently validate and serialize data for your `BaseModel` classes.
diff --git a/docs/Requests/01_functional_api.md b/docs/Requests/01_functional_api.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Functional API"
+parent: "Requests"
+nav_order: 1
+---
+
 # Chapter 1: The Simplest Way - The Functional API
 
 Welcome to the world of `Requests`! If you need to get information from a website or interact with a web service using Python, `Requests` is your friendly helper.
diff --git a/docs/Requests/02_request___response_models.md b/docs/Requests/02_request___response_models.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Request & Response Models"
+parent: "Requests"
+nav_order: 2
+---
+
 # Chapter 2: What Happens When You Order? Request & Response Models
 
 In [Chapter 1: The Simplest Way - The Functional API](01_functional_api.md), we saw how easy it is to fetch a webpage or send data using simple functions like `requests.get()` and `requests.post()`. We also noticed that these functions return something called a `Response` object.
diff --git a/docs/Requests/03_session.md b/docs/Requests/03_session.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Session"
+parent: "Requests"
+nav_order: 3
+---
+
 # Chapter 3: Remembering Things - The Session Object
 
 In [Chapter 1](01_functional_api.md), we learned the easiest way to make web requests using functions like `requests.get()`. In [Chapter 2](02_request___response_models.md), we looked at the `Request` and `Response` objects that structure our communication with web servers.
diff --git a/docs/Requests/04_cookie_jar.md b/docs/Requests/04_cookie_jar.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Cookie Jar"
+parent: "Requests"
+nav_order: 4
+---
+
 # Chapter 4: The Cookie Jar - Remembering Website Visits
 
 In [Chapter 3: Remembering Things - The Session Object](03_session.md), we saw how `Session` objects are super useful for making multiple requests to the same website. A big reason they work so well is that they automatically remember **cookies** sent by the server, just like your web browser does.
diff --git a/docs/Requests/05_authentication_handlers.md b/docs/Requests/05_authentication_handlers.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Authentication Handlers"
+parent: "Requests"
+nav_order: 5
+---
+
 # Chapter 5: Authentication Handlers - Showing Your ID Card
 
 In [Chapter 4: The Cookie Jar](04_cookie_jar.md), we learned how `requests` uses `Session` objects and cookie jars to automatically remember things like login cookies. This is great for websites that use cookies to manage sessions after you log in.
diff --git a/docs/Requests/06_exception_hierarchy.md b/docs/Requests/06_exception_hierarchy.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Exception Hierarchy"
+parent: "Requests"
+nav_order: 6
+---
+
 # Chapter 6: When Things Go Wrong - The Exception Hierarchy
 
 In [Chapter 5: Authentication Handlers](05_authentication_handlers.md), we learned how to prove our identity to websites that require login or API keys. We assumed our requests would work if we provided the correct credentials.
diff --git a/docs/Requests/07_transport_adapters.md b/docs/Requests/07_transport_adapters.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Transport Adapters"
+parent: "Requests"
+nav_order: 7
+---
+
 # Chapter 7: Transport Adapters - Custom Delivery Routes
 
 In the previous chapter, [Chapter 6: Exception Hierarchy](06_exception_hierarchy.md), we learned how `requests` signals problems like network errors or bad responses. Most of the time, we rely on the default way `requests` handles sending our requests and managing connections.
diff --git a/docs/Requests/08_hook_system.md b/docs/Requests/08_hook_system.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Hook System"
+parent: "Requests"
+nav_order: 8
+---
+
 # Chapter 8: The Hook System - Setting Up Checkpoints
 
 In [Chapter 7: Transport Adapters](07_transport_adapters.md), we saw how to customize the low-level details of *how* requests are sent and connections are managed, like setting custom retry strategies. Transport Adapters give you control over the delivery mechanism itself.
