update nav

zachary62 · zachary62 · commit 0426110e66cc · 2025-04-04T14:03:22.000-04:00
diff --git a/docs/Crawl4AI/01_asynccrawlerstrategy.md b/docs/Crawl4AI/01_asynccrawlerstrategy.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "AsyncCrawlerStrategy"
+parent: "Crawl4AI"
+nav_order: 1
+---
+
 # Chapter 1: How We Fetch Webpages - AsyncCrawlerStrategy
 
 Welcome to the Crawl4AI tutorial series! Our goal is to build intelligent agents that can understand and extract information from the web. The very first step in this process is actually *getting* the content from a webpage. This chapter explains how Crawl4AI handles that fundamental task.
diff --git a/docs/Crawl4AI/02_asyncwebcrawler.md b/docs/Crawl4AI/02_asyncwebcrawler.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "AsyncWebCrawler"
+parent: "Crawl4AI"
+nav_order: 2
+---
+
 # Chapter 2: Meet the General Manager - AsyncWebCrawler
 
 In [Chapter 1: How We Fetch Webpages - AsyncCrawlerStrategy](01_asynccrawlerstrategy.md), we learned about the different ways Crawl4AI can fetch the raw content of a webpage, like choosing between a fast drone (`AsyncHTTPCrawlerStrategy`) or a versatile delivery truck (`AsyncPlaywrightCrawlerStrategy`).
diff --git a/docs/Crawl4AI/03_crawlerrunconfig.md b/docs/Crawl4AI/03_crawlerrunconfig.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "CrawlerRunConfig"
+parent: "Crawl4AI"
+nav_order: 3
+---
+
 # Chapter 3: Giving Instructions - CrawlerRunConfig
 
 In [Chapter 2: Meet the General Manager - AsyncWebCrawler](02_asyncwebcrawler.md), we met the `AsyncWebCrawler`, the central coordinator for our web crawling tasks. We saw how to tell it *what* URL to crawl using the `arun` method.
diff --git a/docs/Crawl4AI/04_contentscrapingstrategy.md b/docs/Crawl4AI/04_contentscrapingstrategy.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "ContentScrapingStrategy"
+parent: "Crawl4AI"
+nav_order: 4
+---
+
 # Chapter 4: Cleaning Up the Mess - ContentScrapingStrategy
 
 In [Chapter 3: Giving Instructions - CrawlerRunConfig](03_crawlerrunconfig.md), we learned how to give specific instructions to our `AsyncWebCrawler` using `CrawlerRunConfig`. This included telling it *how* to fetch the page and potentially take screenshots or PDFs.
diff --git a/docs/Crawl4AI/05_relevantcontentfilter.md b/docs/Crawl4AI/05_relevantcontentfilter.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "RelevantContentFilter"
+parent: "Crawl4AI"
+nav_order: 5
+---
+
 # Chapter 5: Focusing on What Matters - RelevantContentFilter
 
 In [Chapter 4: Cleaning Up the Mess - ContentScrapingStrategy](04_contentscrapingstrategy.md), we learned how Crawl4AI takes the raw, messy HTML from a webpage and cleans it up using a `ContentScrapingStrategy`. This gives us a tidier version of the HTML (`cleaned_html`) and extracts basic elements like links and images.
diff --git a/docs/Crawl4AI/06_extractionstrategy.md b/docs/Crawl4AI/06_extractionstrategy.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "ExtractionStrategy"
+parent: "Crawl4AI"
+nav_order: 6
+---
+
 # Chapter 6: Getting Specific Data - ExtractionStrategy
 
 In the previous chapter, [Chapter 5: Focusing on What Matters - RelevantContentFilter](05_relevantcontentfilter.md), we learned how to sift through the cleaned webpage content to keep only the parts relevant to our query or goal, producing a focused `fit_markdown`. This is great for tasks like summarization or getting the main gist of an article.
diff --git a/docs/Crawl4AI/07_crawlresult.md b/docs/Crawl4AI/07_crawlresult.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "CrawlResult"
+parent: "Crawl4AI"
+nav_order: 7
+---
+
 # Chapter 7: Understanding the Results - CrawlResult
 
 In the previous chapter, [Chapter 6: Getting Specific Data - ExtractionStrategy](06_extractionstrategy.md), we learned how to teach Crawl4AI to act like an analyst, extracting specific, structured data points from a webpage using an `ExtractionStrategy`. We've seen how Crawl4AI can fetch pages, clean them, filter them, and even extract precise information.
@@ -247,7 +254,7 @@ if __name__ == "__main__":
 
 You don't interact with the `CrawlResult` constructor directly. The `AsyncWebCrawler` creates it for you at the very end of the `arun` process, typically inside its internal `aprocess_html` method (or just before returning if fetching from cache).
 
-Here’s a simplified sequence:
+Here's a simplified sequence:
 
 1.  **Fetch:** `AsyncWebCrawler` calls the [AsyncCrawlerStrategy](01_asynccrawlerstrategy.md) to get the raw `html`, `status_code`, `response_headers`, etc.
 2.  **Scrape:** It passes the `html` to the [ContentScrapingStrategy](04_contentscrapingstrategy.md) to get `cleaned_html`, `links`, `media`, `metadata`.
diff --git a/docs/Crawl4AI/08_deepcrawlstrategy.md b/docs/Crawl4AI/08_deepcrawlstrategy.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "DeepCrawlStrategy"
+parent: "Crawl4AI"
+nav_order: 8
+---
+
 # Chapter 8: Exploring Websites - DeepCrawlStrategy
 
 In [Chapter 7: Understanding the Results - CrawlResult](07_crawlresult.md), we saw the final report (`CrawlResult`) that Crawl4AI gives us after processing a single URL. This report contains cleaned content, links, metadata, and maybe even extracted data.
diff --git a/docs/Crawl4AI/09_cachecontext___cachemode.md b/docs/Crawl4AI/09_cachecontext___cachemode.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "CacheContext & CacheMode"
+parent: "Crawl4AI"
+nav_order: 9
+---
+
 # Chapter 9: Smart Fetching with Caching - CacheContext / CacheMode
 
 In the previous chapter, [Chapter 8: Exploring Websites - DeepCrawlStrategy](08_deepcrawlstrategy.md), we saw how Crawl4AI can explore websites by following links, potentially visiting many pages. During such explorations, or even when you run the same crawl multiple times, the crawler might try to fetch the exact same webpage again and again. This can be slow and might unnecessarily put a load on the website you're crawling. Wouldn't it be smarter to remember the result from the first time and just reuse it?
diff --git a/docs/Crawl4AI/10_basedispatcher.md b/docs/Crawl4AI/10_basedispatcher.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "BaseDispatcher"
+parent: "Crawl4AI"
+nav_order: 10
+---
+
 # Chapter 10: Orchestrating the Crawl - BaseDispatcher
 
 In [Chapter 9: Smart Fetching with Caching - CacheContext / CacheMode](09_cachecontext___cachemode.md), we learned how Crawl4AI uses caching to cleverly avoid re-fetching the same webpage multiple times, which is especially helpful when crawling many URLs. We've also seen how methods like `arun_many()` ([Chapter 2: Meet the General Manager - AsyncWebCrawler](02_asyncwebcrawler.md)) or strategies like [DeepCrawlStrategy](08_deepcrawlstrategy.md) can lead to potentially hundreds or thousands of individual URLs needing to be crawled.
diff --git a/docs/CrewAI/06_llm.md b/docs/CrewAI/06_llm.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "LLM"
+parent: "CrewAI"
+nav_order: 6
+---
+
 # Chapter 6: LLM - The Agent's Brain
 
 In the [previous chapter](05_process.md), we explored the `Process` - how the `Crew` organizes the workflow for its `Agent`s, deciding whether they work sequentially or are managed hierarchically. We now have specialized agents ([Agent](02_agent.md)), defined work ([Task](03_task.md)), useful abilities ([Tool](04_tool.md)), and a workflow strategy ([Process](05_process.md)).
diff --git a/docs/CrewAI/07_memory.md b/docs/CrewAI/07_memory.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Memory"
+parent: "CrewAI"
+nav_order: 7
+---
+
 # Chapter 7: Memory - Giving Your Crew Recall
 
 In the [previous chapter](06_llm.md), we looked at the Large Language Model ([LLM](06_llm.md)) – the "brain" that allows each [Agent](02_agent.md) to understand, reason, and generate text. Now we have agents that can think, perform [Task](03_task.md)s using [Tool](04_tool.md)s, and follow a [Process](05_process.md).
diff --git a/docs/CrewAI/08_knowledge.md b/docs/CrewAI/08_knowledge.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Knowledge"
+parent: "CrewAI"
+nav_order: 8
+---
+
 # Chapter 8: Knowledge - Providing External Information
 
 In [Chapter 7: Memory](07_memory.md), we learned how to give our [Crew](01_crew.md) the ability to remember past interactions and details using `Memory`. This helps them maintain context within a single run and potentially across runs.
diff --git a/docs/DSPy/01_module___program.md b/docs/DSPy/01_module___program.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Module & Program"
+parent: "DSPy"
+nav_order: 1
+---
+
 # Chapter 1: Modules and Programs: Building Blocks of DSPy
 
 Welcome to the first chapter of our journey into DSPy! We're excited to have you here.
diff --git a/docs/DSPy/02_signature.md b/docs/DSPy/02_signature.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Signature"
+parent: "DSPy"
+nav_order: 2
+---
+
 # Chapter 2: Signatures - Defining the Task
 
 In [Chapter 1: Modules and Programs](01_module___program.md), we learned that `Module`s are like Lego bricks that perform specific tasks, often using Language Models ([LM](05_lm__language_model_client_.md)). We saw how `Program`s combine these modules.
diff --git a/docs/DSPy/03_example.md b/docs/DSPy/03_example.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Example"
+parent: "DSPy"
+nav_order: 3
+---
+
 # Chapter 3: Example - Your Data Points
 
 In [Chapter 2: Signature](02_signature.md), we learned how to define the *task* for a DSPy module using `Signatures` – specifying the inputs, outputs, and instructions. It's like writing a recipe card.
diff --git a/docs/DSPy/04_predict.md b/docs/DSPy/04_predict.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Predict"
+parent: "DSPy"
+nav_order: 4
+---
+
 # Chapter 4: Predict - The Basic LM Caller
 
 In [Chapter 3: Example](03_example.md), we learned how to create `dspy.Example` objects to represent our data points – like flashcards holding an input and its corresponding desired output. We also saw in [Chapter 2: Signature](02_signature.md) how to define the *task* itself using `dspy.Signature`.
diff --git a/docs/DSPy/05_lm__language_model_client_.md b/docs/DSPy/05_lm__language_model_client_.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "LM (Language Model Client)"
+parent: "DSPy"
+nav_order: 5
+---
+
 # Chapter 5: LM (Language Model Client) - The Engine Room
 
 In [Chapter 4: Predict](04_predict.md), we saw how `dspy.Predict` takes a [Signature](02_signature.md) and input data to magically generate an output. We used our `translator` example:
diff --git a/docs/DSPy/06_rm__retrieval_model_client_.md b/docs/DSPy/06_rm__retrieval_model_client_.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "RM (Retrieval Model Client)"
+parent: "DSPy"
+nav_order: 6
+---
+
 # Chapter 6: RM (Retrieval Model Client) - Your Program's Librarian
 
 In [Chapter 5: LM (Language Model Client)](05_lm__language_model_client_.md), we learned how to connect our DSPy programs to the powerful "brain" of a Language Model (LM) using the LM Client. The LM is great at generating creative text, answering questions based on its vast training data, and reasoning.
diff --git a/docs/DSPy/07_evaluate.md b/docs/DSPy/07_evaluate.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Evaluate"
+parent: "DSPy"
+nav_order: 7
+---
+
 # Chapter 7: Evaluate - Grading Your Program
 
 In the previous chapter, [Chapter 6: RM (Retrieval Model Client)](06_rm__retrieval_model_client_.md), we learned how to connect our DSPy program to external knowledge sources using Retrieval Models (RMs). We saw how combining RMs with Language Models (LMs) allows us to build sophisticated programs like Retrieval-Augmented Generation (RAG) systems.
diff --git a/docs/DSPy/08_teleprompter___optimizer.md b/docs/DSPy/08_teleprompter___optimizer.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Teleprompter & Optimizer"
+parent: "DSPy"
+nav_order: 8
+---
+
 # Chapter 8: Teleprompter / Optimizer - Your Program's Coach
 
 Welcome to Chapter 8! In [Chapter 7: Evaluate](07_evaluate.md), we learned how to grade our DSPy programs using metrics and datasets to see how well they perform. That's great for knowing our score, but what if the score isn't high enough?
diff --git a/docs/DSPy/09_adapter.md b/docs/DSPy/09_adapter.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Adapter"
+parent: "DSPy"
+nav_order: 9
+---
+
 # Chapter 9: Adapter - The Universal Translator
 
 Welcome to Chapter 9! In [Chapter 8: Teleprompter / Optimizer](08_teleprompter___optimizer.md), we saw how DSPy can automatically optimize our programs by finding better prompts or few-shot examples. We ended up with a `compiled_program` that should perform better.
diff --git a/docs/DSPy/10_settings.md b/docs/DSPy/10_settings.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Settings"
+parent: "DSPy"
+nav_order: 10
+---
+
 # Chapter 10: Settings - Your Program's Control Panel
 
 Welcome to the final chapter of our introductory DSPy tutorial! In [Chapter 9: Adapter](09_adapter.md), we saw how Adapters act as translators, allowing our DSPy programs to communicate seamlessly with different types of Language Models (LMs).
diff --git a/docs/design.md b/docs/design.md
