# What Is the DocumentationComposer in Litho? The Central Orchestrator Explained > Discover the DocumentationComposer, Litho's orchestrator for generating C4-style architecture documentation through specialized agents and the Chain-of-Responsibility pattern. Learn how it works. - Repository: [Sopaco/deepwiki-rs](https://github.com/sopaco/deepwiki-rs) - Tags: deep-dive - Published: 2026-02-16 --- **The DocumentationComposer is the central orchestrator in Litho's documentation generation pipeline, implementing a Chain-of-Responsibility pattern to sequentially execute specialized editor agents that produce C4-style architecture documentation.** The DocumentationComposer in Litho serves as the backbone of the automated documentation generation system within the sopaco/deepwiki-rs repository. This Rust-based component coordinates the entire composition stage, ensuring that every section of your architecture documentation—from system overviews to database schemas—is generated in the correct order and stored in a shared document tree. ## Core Responsibilities of the DocumentationComposer in Litho ### Chain-of-Responsibility Pipeline The DocumentationComposer implements a Chain-of-Responsibility design pattern in [`src/generator/compose/mod.rs`](https://github.com/sopaco/deepwiki-rs/blob/main/src/generator/compose/mod.rs). This pipeline sequentially invokes specialized editor agents, each responsible for generating a specific section of the final C4-style architecture documentation. The standard pipeline includes the **OverviewEditor**, **ArchitectureEditor**, **WorkflowEditor**, **KeyModulesInsightEditor**, **BoundaryEditor**, and conditionally the **DatabaseEditor**. ### Conditional Database Detection Not every project includes database components, so the DocumentationComposer uses the `has_database_files` helper method to detect SQL schemas before invoking the DatabaseEditor. This conditional logic ensures that database documentation is only generated when relevant source files exist, keeping the output clean and relevant. ## How the DocumentationComposer in Litho Executes The `execute` method in [`src/generator/compose/mod.rs`](https://github.com/sopaco/deepwiki-rs/blob/main/src/generator/compose/mod.rs) serves as the entry point for the entire documentation generation stage. This async method coordinates the pipeline by printing a startup banner, instantiating editor agents in dependency order, and updating the shared `DocTree` structure. Here is how the DocumentationComposer is typically invoked from the main workflow in [`src/generator/workflow.rs`](https://github.com/sopaco/deepwiki-rs/blob/main/src/generator/workflow.rs): ```rust // src/generator/workflow.rs let mut doc_tree = DocTree::new(&context.config.target_language); let documentation_orchestrator = DocumentationComposer::default(); documentation_orchestrator .execute(&context, &mut doc_tree) // <-- the Composer runs all editors .await?; ``` During execution, the DocumentationComposer passes the `GeneratorContext` and mutable references to the `DocTree` to each editor agent, allowing them to append their generated content to the shared document structure. ## Extending the DocumentationComposer Pipeline The modular design of the DocumentationComposer in Litho allows developers to insert custom editor agents into the pipeline without modifying the core orchestration logic. Because the Composer exposes the same `GeneratorContext` and `DocTree` interfaces used by built-in editors, custom extensions integrate seamlessly. Here is an example of adding a custom editor after the standard pipeline: ```rust use crate::generator::compose::DocumentationComposer; use crate::generator::compose::agents::my_custom_editor::MyCustomEditor; // ...inside some async function let mut doc_tree = DocTree::new(&context.config.target_language); let mut composer = DocumentationComposer::default(); // Run the standard pipeline composer.execute(&context, &mut doc_tree).await?; // Insert a custom editor after the standard ones MyCustomEditor::default() .execute(&context, &mut doc_tree) .await?; ``` This extensibility ensures that the DocumentationComposer can adapt to project-specific documentation requirements while maintaining the integrity of the core C4-style generation workflow. ## Summary - The **DocumentationComposer** in Litho serves as the central orchestrator for generating C4-style architecture documentation in the sopaco/deepwiki-rs repository. - Implemented in [`src/generator/compose/mod.rs`](https://github.com/sopaco/deepwiki-rs/blob/main/src/generator/compose/mod.rs), it uses a **Chain-of-Responsibility** pattern to sequentially execute specialized editor agents. - The `execute` method coordinates the pipeline by managing the `GeneratorContext` and updating the shared `DocTree` structure. - **Conditional logic** via `has_database_files` ensures database documentation is only generated when SQL schemas are present. - The architecture is **modular and extensible**, allowing custom editor agents to integrate seamlessly with the standard pipeline. ## Frequently Asked Questions ### What is the primary role of DocumentationComposer in Litho? The primary role of the DocumentationComposer in Litho is to orchestrate the entire documentation generation stage by implementing a Chain-of-Responsibility pipeline. It sequentially invokes specialized editor agents—such as the OverviewEditor, ArchitectureEditor, and WorkflowEditor—to generate comprehensive C4-style architecture documentation while managing the shared DocTree state. ### Where is the DocumentationComposer implemented in the codebase? The DocumentationComposer is implemented in [`src/generator/compose/mod.rs`](https://github.com/sopaco/deepwiki-rs/blob/main/src/generator/compose/mod.rs) within the sopaco/deepwiki-rs repository. This module defines the struct and its `execute` method, which serves as the entry point for the composition stage. The individual editor agents invoked by the Composer are located in the `src/generator/compose/agents/` subdirectory. ### How does DocumentationComposer handle database documentation? The DocumentationComposer handles database documentation conditionally using the `has_database_files` helper method to detect the presence of SQL schema files in the project. Only when database-related files are detected does the Composer invoke the DatabaseEditor agent, ensuring that database sections appear in the final documentation only when relevant to the codebase. ### Can I add custom editors to the DocumentationComposer pipeline? Yes, you can add custom editors to the DocumentationComposer pipeline due to its modular, Chain-of-Responsibility architecture. Custom editor agents can implement the same interface used by built-in editors, accepting `GeneratorContext` and `DocTree` parameters, allowing them to integrate seamlessly with the standard pipeline without modifying the core Composer logic in [`src/generator/compose/mod.rs`](https://github.com/sopaco/deepwiki-rs/blob/main/src/generator/compose/mod.rs).