diff --git a/docs/LangGraph/01_graph___stategraph.md b/docs/LangGraph/01_graph___stategraph.md
index 6ad72f2..9a98abd 100644
--- a/docs/LangGraph/01_graph___stategraph.md
+++ b/docs/LangGraph/01_graph___stategraph.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Graph & StateGraph"
+parent: "LangGraph"
+nav_order: 1
+---
+
 # Chapter 1: Graph / StateGraph - The Blueprint of Your Application
 
 Welcome to the LangGraph tutorial! We're excited to help you learn how to build powerful, stateful applications with Large Language Models (LLMs).
diff --git a/docs/LangGraph/02_nodes___pregelnode__.md b/docs/LangGraph/02_nodes___pregelnode__.md
index cd85604..1c10233 100644
--- a/docs/LangGraph/02_nodes___pregelnode__.md
+++ b/docs/LangGraph/02_nodes___pregelnode__.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Nodes (PregelNode)"
+parent: "LangGraph"
+nav_order: 2
+---
+
 # Chapter 2: Nodes (`PregelNode`) - The Workers of Your Graph
 
 In [Chapter 1: Graph / StateGraph](01_graph___stategraph.md), we learned how `StateGraph` acts as a blueprint or a flowchart for our application. It defines the overall structure and the shared "whiteboard" (the State) that holds information.
diff --git a/docs/LangGraph/03_channels.md b/docs/LangGraph/03_channels.md
index 2115540..5ab957c 100644
--- a/docs/LangGraph/03_channels.md
+++ b/docs/LangGraph/03_channels.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Channels"
+parent: "LangGraph"
+nav_order: 3
+---
+
 # Chapter 3: Channels - The Communication System
 
 In [Chapter 1: Graph / StateGraph](01_graph___stategraph.md), we learned about the `StateGraph` as the blueprint for our application, holding the shared "whiteboard" or state. In [Chapter 2: Nodes (`PregelNode`)](02_nodes___pregelnode__.md), we met the "workers" or Nodes that perform tasks and read/write to this whiteboard.
diff --git a/docs/LangGraph/04_control_flow_primitives___branch____send____interrupt__.md b/docs/LangGraph/04_control_flow_primitives___branch____send____interrupt__.md
index 37db387..ef6da2d 100644
--- a/docs/LangGraph/04_control_flow_primitives___branch____send____interrupt__.md
+++ b/docs/LangGraph/04_control_flow_primitives___branch____send____interrupt__.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Control Flow Primitives"
+parent: "LangGraph"
+nav_order: 4
+---
+
 # Chapter 4: Control Flow Primitives (`Branch`, `Send`, `Interrupt`)
 
 In [Chapter 3: Channels](03_channels.md), we saw how information is stored and updated in our graph's shared state using Channels. We have the blueprint ([`StateGraph`](01_graph___stategraph.md)), the workers ([`Nodes`](02_nodes___pregelnode__.md)), and the communication system ([Channels](03_channels.md)).
diff --git a/docs/LangGraph/05_pregel_execution_engine.md b/docs/LangGraph/05_pregel_execution_engine.md
index 88aa3a7..a02726a 100644
--- a/docs/LangGraph/05_pregel_execution_engine.md
+++ b/docs/LangGraph/05_pregel_execution_engine.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Pregel Execution Engine"
+parent: "LangGraph"
+nav_order: 5
+---
+
 # Chapter 5: Pregel Execution Engine - The Engine Room
 
 In the previous chapters, we learned how to build the blueprint of our application using [`StateGraph`](01_graph___stategraph.md), define the workers with [`Nodes`](02_nodes___pregelnode__.md), manage the shared state with [`Channels`](03_channels.md), and direct the traffic using [Control Flow Primitives](04_control_flow_primitives___branch____send____interrupt__.md).
diff --git a/docs/LangGraph/06_checkpointer___basecheckpointsaver__.md b/docs/LangGraph/06_checkpointer___basecheckpointsaver__.md
index e3eca2d..b49c6dd 100644
--- a/docs/LangGraph/06_checkpointer___basecheckpointsaver__.md
+++ b/docs/LangGraph/06_checkpointer___basecheckpointsaver__.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Checkpointer (BaseCheckpointSaver)"
+parent: "LangGraph"
+nav_order: 6
+---
+
 # Chapter 6: Checkpointer (`BaseCheckpointSaver`) - Saving Your Progress
 
 In [Chapter 5: Pregel Execution Engine](05_pregel_execution_engine.md), we saw how the engine runs our graph step-by-step. But what happens if a graph takes hours to run, or if it needs to pause and wait for a human? If the program crashes or we need to stop it, do we lose all the progress?
diff --git a/docs/LevelDB/01_table___sstable___tablecache.md b/docs/LevelDB/01_table___sstable___tablecache.md
index 590a2af..13d5484 100644
--- a/docs/LevelDB/01_table___sstable___tablecache.md
+++ b/docs/LevelDB/01_table___sstable___tablecache.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Table, SSTable & TableCache"
+parent: "LevelDB"
+nav_order: 1
+---
+
 # Chapter 1: Table / SSTable & TableCache
 
 Welcome to your LevelDB journey! This is the first chapter where we'll start exploring the fundamental building blocks of LevelDB.
diff --git a/docs/LevelDB/02_memtable.md b/docs/LevelDB/02_memtable.md
index 41add92..255a9f0 100644
--- a/docs/LevelDB/02_memtable.md
+++ b/docs/LevelDB/02_memtable.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "MemTable"
+parent: "LevelDB"
+nav_order: 2
+---
+
 # Chapter 2: MemTable
 
 In [Chapter 1: Table / SSTable & TableCache](01_table___sstable___tablecache.md), we learned how LevelDB stores the bulk of its data permanently on disk in sorted, immutable files called SSTables. We also saw how the `TableCache` helps access these files efficiently.
diff --git a/docs/LevelDB/03_write_ahead_log__wal____logwriter_logreader.md b/docs/LevelDB/03_write_ahead_log__wal____logwriter_logreader.md
index 14082cb..8b13ac3 100644
--- a/docs/LevelDB/03_write_ahead_log__wal____logwriter_logreader.md
+++ b/docs/LevelDB/03_write_ahead_log__wal____logwriter_logreader.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Write-Ahead Log (WAL)"
+parent: "LevelDB"
+nav_order: 3
+---
+
 # Chapter 3: Write-Ahead Log (WAL) & LogWriter/LogReader
 
 In [Chapter 2: MemTable](02_memtable.md), we saw how LevelDB uses an in-memory `MemTable` (like a fast notepad) to quickly accept new writes (`Put` or `Delete`) before they are eventually flushed to an [SSTable](01_table___sstable___tablecache.md) file on disk.
diff --git a/docs/LevelDB/04_dbimpl.md b/docs/LevelDB/04_dbimpl.md
index e222b72..8b396bc 100644
--- a/docs/LevelDB/04_dbimpl.md
+++ b/docs/LevelDB/04_dbimpl.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "DBImpl"
+parent: "LevelDB"
+nav_order: 4
+---
+
 # Chapter 4: DBImpl - The Database General Manager
 
 In the previous chapters, we've explored some key ingredients of LevelDB:
diff --git a/docs/LevelDB/05_writebatch.md b/docs/LevelDB/05_writebatch.md
index a257aa2..3c10c2f 100644
--- a/docs/LevelDB/05_writebatch.md
+++ b/docs/LevelDB/05_writebatch.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "WriteBatch"
+parent: "LevelDB"
+nav_order: 5
+---
+
 # Chapter 5: WriteBatch - Grouping Changes Together
 
 Welcome back! In [Chapter 4: DBImpl](04_dbimpl.md), we saw how `DBImpl` acts as the general manager, coordinating writes, reads, and background tasks. We learned that when you call `Put` or `Delete`, `DBImpl` handles writing to the [Write-Ahead Log (WAL)](03_write_ahead_log__wal____logwriter_logreader.md) and then updating the [MemTable](02_memtable.md).
diff --git a/docs/LevelDB/06_version___versionset.md b/docs/LevelDB/06_version___versionset.md
index f50f3ea..3cdc39c 100644
--- a/docs/LevelDB/06_version___versionset.md
+++ b/docs/LevelDB/06_version___versionset.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Version & VersionSet"
+parent: "LevelDB"
+nav_order: 6
+---
+
 # Chapter 6: Version & VersionSet - The Database Catalog
 
 In the previous chapter, [Chapter 5: WriteBatch](05_writebatch.md), we learned how LevelDB groups multiple `Put` and `Delete` operations together to apply them atomically and efficiently. We saw that writes go first to the [Write-Ahead Log (WAL)](03_write_ahead_log__wal____logwriter_logreader.md) for durability, and then to the in-memory [MemTable](02_memtable.md).
diff --git a/docs/LevelDB/07_iterator.md b/docs/LevelDB/07_iterator.md
index c786bc5..d9cc887 100644
--- a/docs/LevelDB/07_iterator.md
+++ b/docs/LevelDB/07_iterator.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Iterator"
+parent: "LevelDB"
+nav_order: 7
+---
+
 # Chapter 7: Iterator - Your Guide Through the Database
 
 Welcome back! In [Chapter 6: Version & VersionSet](06_version___versionset.md), we learned how LevelDB keeps track of all the live SSTable files using `Version` objects and the `VersionSet`. This catalog helps LevelDB efficiently find a single key by looking first in the [MemTable](02_memtable.md) and then pinpointing the right [SSTables](01_table___sstable___tablecache.md) to check.
diff --git a/docs/LevelDB/08_compaction.md b/docs/LevelDB/08_compaction.md
index 521bee1..3cc7cd0 100644
--- a/docs/LevelDB/08_compaction.md
+++ b/docs/LevelDB/08_compaction.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Compaction"
+parent: "LevelDB"
+nav_order: 8
+---
+
 # Chapter 8: Compaction - Keeping the Library Tidy
 
 In [Chapter 7: Iterator](07_iterator.md), we saw how LevelDB provides iterators to give us a unified, sorted view of our data, cleverly merging information from the in-memory [MemTable](02_memtable.md) and the various [SSTable](01_table___sstable___tablecache.md) files on disk.
diff --git a/docs/LevelDB/09_internalkey___dbformat.md b/docs/LevelDB/09_internalkey___dbformat.md
index f29ca3c..5352bff 100644
--- a/docs/LevelDB/09_internalkey___dbformat.md
+++ b/docs/LevelDB/09_internalkey___dbformat.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "InternalKey & DBFormat"
+parent: "LevelDB"
+nav_order: 9
+---
+
 # Chapter 9: InternalKey & DBFormat - LevelDB's Internal Bookkeeping
 
 Welcome to the final chapter of our deep dive into LevelDB's core components! In [Chapter 8: Compaction](08_compaction.md), we saw how LevelDB keeps its storage tidy by merging and rewriting [SSTables](01_table___sstable___tablecache.md) in the background. This compaction process relies heavily on being able to correctly compare different versions of the same key and discard old or deleted data.
diff --git a/docs/MCP Python SDK/01_cli___mcp__command_.md b/docs/MCP Python SDK/01_cli___mcp__command_.md
index a2ccbcc..d2fee92 100644
--- a/docs/MCP Python SDK/01_cli___mcp__command_.md	
+++ b/docs/MCP Python SDK/01_cli___mcp__command_.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "CLI (mcp command)"
+parent: "MCP Python SDK"
+nav_order: 1
+---
+
 # Chapter 1: Your Control Panel - The `mcp` Command-Line Interface
 
 Welcome to the MCP Python SDK! This is your starting point for building powerful, interactive AI tools.
diff --git a/docs/MCP Python SDK/02_fastmcp_server___fastmcp__.md b/docs/MCP Python SDK/02_fastmcp_server___fastmcp__.md
index 5fc6be4..1ebc75e 100644
--- a/docs/MCP Python SDK/02_fastmcp_server___fastmcp__.md	
+++ b/docs/MCP Python SDK/02_fastmcp_server___fastmcp__.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "FastMCP Server (FastMCP)"
+parent: "MCP Python SDK"
+nav_order: 2
+---
+
 # Chapter 2: Easier Server Building with `FastMCP`
 
 In [Chapter 1: Your Control Panel - The `mcp` Command-Line Interface](01_cli___mcp__command_.md), we learned how to use the `mcp` command to run, test, and install MCP servers. We even saw a tiny example of a server file. But how do we *build* that server code without getting lost in complex details?
diff --git a/docs/MCP Python SDK/03_fastmcp_resources___resource____resourcemanager__.md b/docs/MCP Python SDK/03_fastmcp_resources___resource____resourcemanager__.md
index df10c64..2698676 100644
--- a/docs/MCP Python SDK/03_fastmcp_resources___resource____resourcemanager__.md	
+++ b/docs/MCP Python SDK/03_fastmcp_resources___resource____resourcemanager__.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "FastMCP Resources (Resource, ResourceManager)"
+parent: "MCP Python SDK"
+nav_order: 3
+---
+
 # Chapter 3: Sharing Data - FastMCP Resources (`Resource`, `ResourceManager`)
 
 In [Chapter 2: Easier Server Building with `FastMCP`](02_fastmcp_server___fastmcp__.md), we saw how `FastMCP` and the `@server.tool()` decorator make it easy to create servers that can *perform actions* for clients, like our `echo` tool.
diff --git a/docs/MCP Python SDK/04_fastmcp_tools___tool____toolmanager__.md b/docs/MCP Python SDK/04_fastmcp_tools___tool____toolmanager__.md
index 494391b..0101529 100644
--- a/docs/MCP Python SDK/04_fastmcp_tools___tool____toolmanager__.md	
+++ b/docs/MCP Python SDK/04_fastmcp_tools___tool____toolmanager__.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "FastMCP Tools (Tool, ToolManager)"
+parent: "MCP Python SDK"
+nav_order: 4
+---
+
 # Chapter 4: FastMCP Tools (`Tool`, `ToolManager`)
 
 In [Chapter 3: Sharing Data - FastMCP Resources (`Resource`, `ResourceManager`)](03_fastmcp_resources___resource____resourcemanager__.md), we learned how to make data available for clients to read using `Resource` objects, like putting books in a digital library. That's great for sharing information, but what if we want the client to be able to ask the server to *do* something?
diff --git a/docs/MCP Python SDK/05_fastmcp_prompts___prompt____promptmanager__.md b/docs/MCP Python SDK/05_fastmcp_prompts___prompt____promptmanager__.md
index 769188c..c296602 100644
--- a/docs/MCP Python SDK/05_fastmcp_prompts___prompt____promptmanager__.md	
+++ b/docs/MCP Python SDK/05_fastmcp_prompts___prompt____promptmanager__.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "FastMCP Prompts (Prompt, PromptManager)"
+parent: "MCP Python SDK"
+nav_order: 5
+---
+
 # Chapter 5: Reusable Chat Starters - FastMCP Prompts (`Prompt`, `PromptManager`)
 
 In [Chapter 4: FastMCP Tools (`Tool`, `ToolManager`)](04_fastmcp_tools___tool____toolmanager__.md), we learned how to give our server specific *actions* it can perform, like a calculator tool. But modern AI often involves conversations, especially with Large Language Models (LLMs). How do we manage the instructions and conversation starters we send to these models?
diff --git a/docs/MCP Python SDK/06_fastmcp_context___context__.md b/docs/MCP Python SDK/06_fastmcp_context___context__.md
index a516ceb..f55797d 100644
--- a/docs/MCP Python SDK/06_fastmcp_context___context__.md	
+++ b/docs/MCP Python SDK/06_fastmcp_context___context__.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "FastMCP Context (Context)"
+parent: "MCP Python SDK"
+nav_order: 6
+---
+
 # Chapter 6: Talking Back - FastMCP Context (`Context`)
 
 In [Chapter 5: Reusable Chat Starters - FastMCP Prompts (`Prompt`, `PromptManager`)](05_fastmcp_prompts___prompt____promptmanager__.md), we learned how to create reusable message templates for interacting with AI models. We've seen how to build servers with data resources ([Chapter 3](03_fastmcp_resources___resource____resourcemanager__.md)) and action tools ([Chapter 4](04_fastmcp_tools___tool____toolmanager__.md)).
@@ -153,7 +160,7 @@ if __name__ == "__main__":
 
 1.  **`@server.resource(...)`**: We added a simple resource named `config://task_settings` that just returns a string.
 2.  **`resource_contents = await ctx.read_resource("config://task_settings")`**: Inside our `run_long_task` tool, we now use `ctx.read_resource()` to fetch the content of our configuration resource. This allows the tool to dynamically access data managed by the server without having direct access to the resource's implementation function (`get_task_settings`).
-3.  **Processing Content**: The `read_resource` method returns an iterable of `ReadResourceContents` objects (often just one). We extract the string content to use it.
+3.  **Processing Content**: The `read_resource` method returns an iterable of `ReadResourceContents` objects (often just one). We extracted the string content to use it.
 
 Now, our tool can both communicate outwards (logs, progress) and interact inwards (read resources) using the same `Context` object, all within the scope of the single request it's handling.
 
diff --git a/docs/MCP Python SDK/07_mcp_protocol_types.md b/docs/MCP Python SDK/07_mcp_protocol_types.md
index cc1915d..5985ab7 100644
--- a/docs/MCP Python SDK/07_mcp_protocol_types.md	
+++ b/docs/MCP Python SDK/07_mcp_protocol_types.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "MCP Protocol Types"
+parent: "MCP Python SDK"
+nav_order: 7
+---
+
 # Chapter 7: MCP Protocol Types - The Standard Language
 
 In the previous chapter, [Chapter 6: Talking Back - FastMCP Context (`Context`)](06_fastmcp_context___context__.md), we saw how the `Context` object gives our tools and resources a "backstage pass" to send logs, report progress, and access other server features during a request. We've built up a good understanding of how `FastMCP` helps us create powerful servers with tools ([Chapter 4](04_fastmcp_tools___tool____toolmanager__.md)), resources ([Chapter 3](03_fastmcp_resources___resource____resourcemanager__.md)), and prompts ([Chapter 5](05_fastmcp_prompts___prompt____promptmanager__.md)).
diff --git a/docs/MCP Python SDK/08_client_server_sessions___clientsession____serversession__.md b/docs/MCP Python SDK/08_client_server_sessions___clientsession____serversession__.md
index afb5835..a1bed05 100644
--- a/docs/MCP Python SDK/08_client_server_sessions___clientsession____serversession__.md	
+++ b/docs/MCP Python SDK/08_client_server_sessions___clientsession____serversession__.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Client/Server Sessions (ClientSession, ServerSession)"
+parent: "MCP Python SDK"
+nav_order: 8
+---
+
 # Chapter 8: Client/Server Sessions (`ClientSession`, `ServerSession`)
 
 Welcome back! In [Chapter 7: MCP Protocol Types](07_mcp_protocol_types.md), we learned about the standardized "digital forms" – the Pydantic models – that define the structure of messages exchanged between an MCP client and server. We saw examples like `CallToolRequest` and `ProgressNotification`.
diff --git a/docs/MCP Python SDK/09_communication_transports__stdio__sse__websocket__memory_.md b/docs/MCP Python SDK/09_communication_transports__stdio__sse__websocket__memory_.md
index 2b2d845..4b5b570 100644
--- a/docs/MCP Python SDK/09_communication_transports__stdio__sse__websocket__memory_.md	
+++ b/docs/MCP Python SDK/09_communication_transports__stdio__sse__websocket__memory_.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Communication Transports"
+parent: "MCP Python SDK"
+nav_order: 9
+---
+
 # Chapter 9: Communication Transports (Stdio, SSE, WebSocket, Memory)
 
 Welcome to the final chapter of our introductory journey into the `MCP Python SDK`! In [Chapter 8: Client/Server Sessions (`ClientSession`, `ServerSession`)](08_client_server_sessions___clientsession____serversession__.md), we learned how `Session` objects manage the ongoing conversation and state for a single connection between a client and a server, like dedicated phone operators handling a call.
diff --git a/docs/NumPy Core/01_ndarray__n_dimensional_array_.md b/docs/NumPy Core/01_ndarray__n_dimensional_array_.md
index 55f1744..d01a7d6 100644
--- a/docs/NumPy Core/01_ndarray__n_dimensional_array_.md	
+++ b/docs/NumPy Core/01_ndarray__n_dimensional_array_.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "ndarray (N-dimensional array)"
+parent: "NumPy Core"
+nav_order: 1
+---
+
 # Chapter 1: ndarray (N-dimensional array)
 
 Welcome to the NumPy Core tutorial! If you're interested in how NumPy works under the hood, you're in the right place. NumPy is the foundation for scientific computing in Python, and its core strength comes from a special object called the `ndarray`.
diff --git a/docs/NumPy Core/02_dtype__data_type_object_.md b/docs/NumPy Core/02_dtype__data_type_object_.md
index 64a8aa4..975945a 100644
--- a/docs/NumPy Core/02_dtype__data_type_object_.md	
+++ b/docs/NumPy Core/02_dtype__data_type_object_.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "dtype (data type object)"
+parent: "NumPy Core"
+nav_order: 2
+---
+
 # Chapter 2: dtype (Data Type Object)
 
 In [Chapter 1: ndarray (N-dimensional array)](01_ndarray__n_dimensional_array_.md), we learned that NumPy's `ndarray` is a powerful grid designed to hold items **of the same type**. This "same type" requirement is fundamental to NumPy's speed and efficiency. But how does NumPy know *what kind* of data it's storing? That's where the `dtype` comes in!
diff --git a/docs/NumPy Core/03_ufunc__universal_function_.md b/docs/NumPy Core/03_ufunc__universal_function_.md
index b2b71d0..b6ed9fe 100644
--- a/docs/NumPy Core/03_ufunc__universal_function_.md	
+++ b/docs/NumPy Core/03_ufunc__universal_function_.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "ufunc (universal function)"
+parent: "NumPy Core"
+nav_order: 3
+---
+
 # Chapter 3: ufunc (Universal Function)
 
 Welcome back! In [Chapter 1: ndarray (N-dimensional array)](01_ndarray__n_dimensional_array_.md), we met the `ndarray`, NumPy's powerful container for numerical data. In [Chapter 2: dtype (Data Type Object)](02_dtype__data_type_object_.md), we learned how `dtype`s specify the exact *kind* of data stored within those arrays.
diff --git a/docs/NumPy Core/04_numeric_types___numerictypes__.md b/docs/NumPy Core/04_numeric_types___numerictypes__.md
index 648c2eb..5a72bd3 100644
--- a/docs/NumPy Core/04_numeric_types___numerictypes__.md	
+++ b/docs/NumPy Core/04_numeric_types___numerictypes__.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Numeric Types (numerictypes)"
+parent: "NumPy Core"
+nav_order: 4
+---
+
 # Chapter 4: Numeric Types (`numerictypes`)
 
 Hello again! In [Chapter 3: ufunc (Universal Function)](03_ufunc__universal_function_.md), we saw how NumPy uses universal functions (`ufuncs`) to perform fast calculations on arrays. We learned that these `ufuncs` operate element by element and can handle different data types using optimized C loops.
diff --git a/docs/NumPy Core/05_array_printing___arrayprint__.md b/docs/NumPy Core/05_array_printing___arrayprint__.md
index b5ba875..66b15b1 100644
--- a/docs/NumPy Core/05_array_printing___arrayprint__.md	
+++ b/docs/NumPy Core/05_array_printing___arrayprint__.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Array Printing (arrayprint)"
+parent: "NumPy Core"
+nav_order: 5
+---
+
 # Chapter 5: Array Printing (`arrayprint`)
 
 In the previous chapter, [Chapter 4: Numeric Types (`numerictypes`)](04_numeric_types___numerictypes__.md), we explored the different kinds of data NumPy can store in its arrays, like `int32`, `float64`, and more. Now that we know about the arrays ([`ndarray`](01_ndarray__n_dimensional_array_.md)), their data types ([`dtype`](02_dtype__data_type_object_.md)), the functions that operate on them ([`ufunc`](03_ufunc__universal_function_.md)), and the specific number types (`numerictypes`), a practical question arises: How do we actually *look* at these arrays, especially if they are very large?
diff --git a/docs/NumPy Core/06_multiarray_module.md b/docs/NumPy Core/06_multiarray_module.md
index efc2fc5..d579379 100644
--- a/docs/NumPy Core/06_multiarray_module.md	
+++ b/docs/NumPy Core/06_multiarray_module.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Multiarray Module"
+parent: "NumPy Core"
+nav_order: 6
+---
+
 # Chapter 6: multiarray Module
 
 Welcome back! In [Chapter 5: Array Printing (`arrayprint`)](05_array_printing___arrayprint__.md), we saw how NumPy takes complex arrays and presents them in a readable format. We've now covered the array container ([`ndarray`](01_ndarray__n_dimensional_array_.md)), its data types ([`dtype`](02_dtype__data_type_object_.md)), the functions that compute on them ([`ufunc`](03_ufunc__universal_function_.md)), the catalog of types ([`numerictypes`](04_numeric_types___numerictypes__.md)), and how arrays are displayed ([`arrayprint`](05_array_printing___arrayprint__.md)).
diff --git a/docs/NumPy Core/07_umath_module.md b/docs/NumPy Core/07_umath_module.md
index 49f6693..03f5747 100644
--- a/docs/NumPy Core/07_umath_module.md	
+++ b/docs/NumPy Core/07_umath_module.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Umath Module"
+parent: "NumPy Core"
+nav_order: 7
+---
+
 # Chapter 7: umath Module
 
 Welcome to Chapter 7! In [Chapter 6: multiarray Module](06_multiarray_module.md), we explored the core C engine that defines the `ndarray` object and handles fundamental operations like creating arrays and accessing elements. We saw that the actual power comes from C code.
diff --git a/docs/NumPy Core/08___array_function___protocol___overrides___overrides__.md b/docs/NumPy Core/08___array_function___protocol___overrides___overrides__.md
index d06fafa..e30f950 100644
--- a/docs/NumPy Core/08___array_function___protocol___overrides___overrides__.md	
+++ b/docs/NumPy Core/08___array_function___protocol___overrides___overrides__.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "__array_function__ Protocol (overrides)"
+parent: "NumPy Core"
+nav_order: 8
+---
+
 # Chapter 8: __array_function__ Protocol / Overrides (`overrides`)
 
 Welcome to the final chapter of our NumPy Core exploration! In [Chapter 7: umath Module](07_umath_module.md), we learned how NumPy implements its fast, element-wise mathematical functions (`ufuncs`) using optimized C code. We've seen the core components: the `ndarray` container, `dtype` descriptions, `ufunc` operations, numeric types, printing, and the C modules (`multiarray`, `umath`) that power them.
diff --git a/docs/OpenManus/01_llm.md b/docs/OpenManus/01_llm.md
index d0cebf3..4525f78 100644
--- a/docs/OpenManus/01_llm.md
+++ b/docs/OpenManus/01_llm.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "LLM"
+parent: "OpenManus"
+nav_order: 1
+---
+
 # Chapter 1: The LLM - Your Agent's Brainpower
 
 Welcome to the OpenManus tutorial! We're thrilled to have you on board. Let's start with the absolute core of any intelligent agent: the "brain" that does the thinking and understanding. In OpenManus, this brainpower comes from something called a **Large Language Model (LLM)**, and we interact with it using our `LLM` class.
diff --git a/docs/OpenManus/02_message___memory.md b/docs/OpenManus/02_message___memory.md
index b225d16..eeace7e 100644
--- a/docs/OpenManus/02_message___memory.md
+++ b/docs/OpenManus/02_message___memory.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Message & Memory"
+parent: "OpenManus"
+nav_order: 2
+---
+
 # Chapter 2: Message / Memory - Remembering the Conversation
 
 In [Chapter 1: The LLM - Your Agent's Brainpower](01_llm.md), we learned how our agent uses the `LLM` class to access its "thinking" capabilities. But just like humans, an agent needs to remember what was said earlier in a conversation to make sense of new requests and respond appropriately.
diff --git a/docs/OpenManus/03_baseagent.md b/docs/OpenManus/03_baseagent.md
index 1d97e27..9b6220e 100644
--- a/docs/OpenManus/03_baseagent.md
+++ b/docs/OpenManus/03_baseagent.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "BaseAgent"
+parent: "OpenManus"
+nav_order: 3
+---
+
 # Chapter 3: BaseAgent - The Agent Blueprint
 
 In the previous chapters, we learned about the "brain" ([Chapter 1: The LLM](01_llm.md)) that powers our agents and how they remember conversations using [Chapter 2: Message / Memory](02_message___memory.md). Now, let's talk about the agent itself!
@@ -114,7 +121,7 @@ What actually happens when you call `agent.run()`? The `BaseAgent` provides a st
 9.  **Finalize:** Once the loop finishes (either `max_steps` reached or state changed to `FINISHED`/`ERROR`), it sets the state back to `IDLE` (unless it ended in `ERROR`).
 10. **Return Results:** It returns a string summarizing the results from all the steps.
 
-Here’s a simplified diagram showing the flow:
+Here's a simplified diagram showing the flow:
 
 ```mermaid
 sequenceDiagram
diff --git a/docs/OpenManus/04_tool___toolcollection.md b/docs/OpenManus/04_tool___toolcollection.md
index 0fee7ca..2b07964 100644
--- a/docs/OpenManus/04_tool___toolcollection.md
+++ b/docs/OpenManus/04_tool___toolcollection.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Tool & ToolCollection"
+parent: "OpenManus"
+nav_order: 4
+---
+
 # Chapter 4: Tool / ToolCollection - Giving Your Agent Skills
 
 In [Chapter 3: BaseAgent - The Agent Blueprint](03_baseagent.md), we learned how `BaseAgent` provides the standard structure for our agents, including a brain ([LLM](01_llm.md)) and memory ([Message / Memory](02_message___memory.md)). But what if we want our agent to do more than just *think* and *remember*? What if we want it to *act* in the world – like searching the web, running code, or editing files?
diff --git a/docs/OpenManus/05_baseflow.md b/docs/OpenManus/05_baseflow.md
index 4c3774a..63c05ec 100644
--- a/docs/OpenManus/05_baseflow.md
+++ b/docs/OpenManus/05_baseflow.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "BaseFlow"
+parent: "OpenManus"
+nav_order: 5
+---
+
 # Chapter 5: BaseFlow - Managing Multi-Step Projects
 
 In [Chapter 4: Tool / ToolCollection](04_tool___toolcollection.md), we saw how to give agents specific skills like web searching or running code using Tools. Now, imagine you have a task that requires multiple steps, maybe even using different skills (tools) or agents along the way. How do you coordinate this complex work?