@aigne/doc-smith 0.8.15-beta.7 → 0.8.15-beta.9

package/agents/utils/load-sources.mjs

@@ -4,11 +4,11 @@ import path from "node:path";
 import imageSize from "image-size";
 import {
   buildSourcesContent,
-  calculateFileStats,
   loadFilesFromPaths,
   readFileContents,
   getMimeType,
   isRemoteFile,
+  calculateTokens,
 } from "../../utils/file-utils.mjs";
 import {
   getCurrentGitHead,
@@ -196,13 +196,10 @@ export default async function loadSources(
   }
 
   // Read all source files using the utility function
-  let sourceFiles = await readFileContents(sourceFilesPaths, process.cwd());
-
-  // Count tokens and lines using utility function
-  const { totalTokens, totalLines } = calculateFileStats(sourceFiles);
-
-  // check if totalTokens is too large
-  const isLargeContext = totalTokens > INTELLIGENT_SUGGESTION_TOKEN_THRESHOLD;
+  let sourceFiles = (await readFileContents(sourceFilesPaths, process.cwd())).map((i) => ({
+    ...i,
+    tokens: calculateTokens(`\n${i.sourceId}\n${i.content}`),
+  }));
 
   // filter OpenAPI doc should after check isLargeContext
   sourceFiles = sourceFiles.filter((file) => {
@@ -215,6 +212,16 @@ export default async function loadSources(
     return !isOpenAPI;
   });
 
+  const totalTokens = sourceFiles.reduce((sum, file) => sum + file.tokens, 0);
+  const totalLines = sourceFiles.reduce(
+    (sum, file) => sum + file.content.split("\n").filter(Boolean).length,
+    0,
+  );
+
+  const datasources = splitSourcesToChunks(sourceFiles, INTELLIGENT_SUGGESTION_TOKEN_THRESHOLD).map(
+    (i) => ({ dataSourceChunk: buildSourcesContent(i) }),
+  );
+
   const remoteFileList = [];
 
   sourceFiles.forEach((file) => {
@@ -226,8 +233,6 @@ export default async function loadSources(
     options.context.userContext.remoteFileList = remoteFileList;
   }
 
-  // Build allSources string using utility function
-  const allSources = buildSourcesContent(sourceFiles, isLargeContext);
   // all files path
   const allFilesPaths = sourceFiles.map((x) => `- ${toRelativePath(x.sourceId)}`).join("\n");
 
@@ -285,7 +290,7 @@ export default async function loadSources(
   }
 
   return {
-    datasources: allSources,
+    datasources,
     content,
     originalDocumentStructure,
     files,
@@ -293,7 +298,6 @@ export default async function loadSources(
     totalTokens,
     totalLines,
     mediaFiles,
-    isLargeContext,
     allFilesPaths,
   };
 }
@@ -342,7 +346,13 @@ loadSources.output_schema = {
   type: "object",
   properties: {
     datasources: {
-      type: "string",
+      type: "array",
+      items: {
+        type: "object",
+        properties: {
+          dataSourceChunk: { type: "string" },
+        },
+      },
     },
     files: {
       type: "array",
@@ -373,3 +383,33 @@ loadSources.output_schema = {
 };
 
 loadSources.task_render_mode = "hide";
+
+function splitSourcesToChunks(sources, maxTokens) {
+  const chunks = [];
+
+  let currentChunk = [];
+  let currentTokens = 0;
+
+  for (const source of sources) {
+    const sourceTokens = source.tokens;
+
+    if (currentTokens + sourceTokens > maxTokens) {
+      // Start a new chunk
+      if (currentChunk.length > 0) {
+        chunks.push(currentChunk);
+      }
+      currentChunk = [source];
+      currentTokens = sourceTokens;
+    } else {
+      // Add to current chunk
+      currentChunk.push(source);
+      currentTokens += sourceTokens;
+    }
+  }
+
+  if (currentChunk.length > 0) {
+    chunks.push(currentChunk);
+  }
+
+  return chunks;
+}

package/agents/utils/transform-detail-datasources.mjs

@@ -2,7 +2,7 @@ import fs from "node:fs";
 import { isRemoteFile } from "../../utils/file-utils.mjs";
 import { normalizePath, toRelativePath } from "../../utils/utils.mjs";
 
-export default function transformDetailDatasources({ sourceIds }, options = {}) {
+export default function transformDetailDatasource({ sourceIds }, options = {}) {
   // Read file content for each sourceId, ignoring failures
   let openAPISpec;
   const remoteFileList = options?.context?.userContext?.remoteFileList || [];
@@ -37,9 +37,9 @@ export default function transformDetailDatasources({ sourceIds }, options = {})
     .filter(Boolean);
 
   return {
-    detailDataSources: contents.join(""),
+    detailDataSource: contents.join(""),
     openAPISpec,
   };
 }
 
-transformDetailDatasources.task_render_mode = "hide";
+transformDetailDatasource.task_render_mode = "hide";

package/aigne.yaml

@@ -1,8 +1,9 @@
 #!/usr/bin/env aigne
 
-chat_model:
-  provider: google
-  name: gemini-2.5-pro
+model:
+  model: aignehub/gemini-2.5-pro # reasoning_effort 128-32768
+  # https://github.com/AIGNE-io/aigne-framework/blob/main/models/gemini/src/gemini-chat-model.ts#L115
+  reasoning_effort: 502
   # name: gemini-2.5-flash
   temperature: 0.8
 agents:
@@ -11,7 +12,6 @@ agents:
 
   # Documentation Structure Generation
   - ./agents/generate/generate-structure.yaml
-  - ./agents/generate/generate-structure-without-tools.yaml
   - ./agents/generate/update-document-structure.yaml
   - ./agents/generate/check-need-generate-structure.mjs
   - ./agents/generate/refine-document-structure.yaml
@@ -95,6 +95,11 @@ agents:
   - ./agents/evaluate/document-structure.yaml
   - ./agents/evaluate/document.yaml
   - ./agents/evaluate/code-snippet.mjs
+
+  # Diagram
+  - ./agents/generate/merge-diagram.yaml
+  - ./agents/update/generate-diagram.yaml
+  - ./agents/update/check-generate-diagram.mjs
 cli:
   chat: ./agents/chat/index.yaml
   agents:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aigne/doc-smith",
-  "version": "0.8.15-beta.7",
+  "version": "0.8.15-beta.9",
   "description": "AI-driven documentation generation tool built on the AIGNE Framework",
   "publishConfig": {
     "access": "public"
@@ -56,6 +56,7 @@
     "remark-lint": "^10.0.1",
     "remark-parse": "^11.0.0",
     "terminal-link": "^4.0.0",
+    "typescript": "^5.9.3",
     "ufo": "^1.6.1",
     "unified": "^11.0.5",
     "unist-util-visit": "^5.0.0",

package/prompts/common/document/content-rules-core.md

@@ -2,12 +2,12 @@ Target Audience: {{targetAudience}}
 
 Content Generation Rules:
 
-- Use only information from DataSources, never fabricate or supplement content not present in the sources
+- Use only information from detailDataSource, never fabricate or supplement content not present in the sources
 - Combine the current {{nodeName}} title and description to create a well-structured content plan that is rich, organized, and engaging
 - Content style must match the target audience
 - Clearly differentiate content from other {{nodeName}} items in the documentStructure to avoid duplication and highlight this {{nodeName}}'s unique value
 {% if enforceInfoCompleteness %}
-- If DataSources lack sufficient information, return an error message requesting users to provide additional content. Ensure page content is sufficiently rich, don't hesitate to ask users for supplementary information
+- If detailDataSource lack sufficient information, return an error message requesting users to provide additional content. Ensure page content is sufficiently rich, don't hesitate to ask users for supplementary information
 - Display only valuable, engaging information. If information is insufficient, prompt users to provide more details
 {% endif %}
 - Output complete information including all content planned for the {{nodeName}}
@@ -15,6 +15,6 @@ Content Generation Rules:
 - Maintain a strict, sequential heading hierarchy; no skipping (e.g., no jump from level-1 to level-3).
 - Format markdown output with proper line breaks and spacing for easy reading
 - For list data with many items, prioritize using markdown table for cleaner, more readable presentation
-- Do not mention 'DataSources' in output, your content is for user consumption, and users are unaware of DataSources
+- Do not mention 'detailDataSource' in output, your content is for user consumption, and users are unaware of detailDataSource
 - Do not include file paths from Data Sources in output as they are meaningless to users
-- Avoid phrases like 'current {{nodeName}}'
+- Avoid phrases like 'current {{nodeName}}'

package/prompts/common/document/openapi-usage-rules.md

@@ -0,0 +1,36 @@
+{% if openAPISpec %}
+<openapi_usage_rules>
+
+**Goal:** Use the provided OpenAPI (Swagger) specification, align it with the current page objective, and leverage it to refine this document.
+
+**OpenAPI File Content:** 
+<openapi_doc>
+
+{{ openAPISpec }}
+
+</openapi_doc>
+
+---
+
+### **Documentation Requirements and Constraints**
+
+1.  **Extract the core content:**
+    * Organize the document by functional modules.
+    * For each path item, include the following elements:
+        * HTTP method and path.
+        * Concise summary.
+        * Detailed description.
+        * Request parameters: name, location (`in`), type, required flag, description.
+        * Request body: describe its structure when present.
+        * Responses: at least the key status codes (e.g., 200, 201, 400, 500) and their schemas.
+
+2.  **Mandatory API description constraints (deduplication rule):**
+    * **Ensure that throughout the document (including preface, overview, etc.), any introduction to the project APIs appears only within this OpenAPI-generated "API reference" section.**
+    * **Never** repeat or expand the interface list elsewhere in the document (for example, "Quick Start" or "Architecture Overview" sections).
+
+---
+
+**Expected output format:** A concise, clear, and easy-to-scan Markdown document.
+
+</openapi_usage_rules>
+{% endif %}

package/prompts/common/document/role-and-personality.md

@@ -13,5 +13,4 @@ Your key strengths include:
 1.  **Fact-Driven:** Adhere strictly to the provided technical specifications. Do not infer or embellish information.
 2.  **Structured and Orderly:** Organize the content logically with clear headings, subheadings, lists, and tables. Present information sequentially where appropriate (e.g., installation steps).
 3.  **Clarity and Precision:** Use precise, unambiguous language. Define technical terms clearly. Avoid marketing jargon or emotionally charged words.
-4.  **Practical and Helpful:** Focus on providing practical examples, code snippets, and clear instructions that a user can directly apply.
-5.  **Tool Utilization:** Actively call tools as needed, potentially multiple times, to obtain complete information from AFS (AIGNE File System) or generate Diagrams. Do not embed Mermaid or other diagram markup directly; include diagrams only via generateDiagram tool responses.
+5.  **Tool Utilization:** Actively call tools as needed, potentially multiple times, to obtain complete information from AFS (AIGNE File System).

package/prompts/detail/d2-diagram/rules.md

@@ -1,13 +1,14 @@
-<diagram_generation_guide>
+<diagram_generation_rules>
+**Generation Workflow**
+1. Use the current `<detail_dataSource>`, `<content_review_feedback>`, and `<feedback>` to decide whether this document requires a diagram.
+2. When a diagram is needed, call the `generateDiagram` tool to create it and insert the returned content at the most fitting location in the document.
+3. Check whether the data sources include `diagramSourceCode`. If not, remove any embedded diagram from the document.
 
-1. Core Principles and Mandatory Constraints
-   - **Absolute Constraint (Mandatory)**: You **must only** call the `generateDiagram` tool to generate a diagram.
-     - **Do not** generate mermaid diagram.
-     - **Do not** generate base64 image.
-     - **Do not** generate fake image url.
-   - **Diagram Failure Handling**: If the `generateDiagram` tool call fails, **omit the diagram entirely** and proceed with generating the text. **Do not** attempt to describe the diagram in words as a replacement.
+**Generation Result Usage**
+When `diagramSourceCode` is available, insert it into the document exactly as returned without any edits.
 
-2. Diagram Triggers and Types: Call `generateDiagram` and select the most appropriate type when describing the following specific content
+**Generation Requirements**
+1. Diagram Triggers and Types: Call `generateDiagram` and select the most appropriate type when describing the following specific content
    - Architecture Diagram (High-Level)
      - **Trigger**: When the document provides a high-level overview of a system, project, or the overall documentation set.
      - **Content**: Must illustrate the main components, their relationships, and the overall structure.
@@ -19,11 +20,7 @@
      - **Diagram Type Selection**:
        - **Flowchart**: Use for step-by-step processes, algorithms, or decision-making logic.
        - **Sequence Diagram**: Use for time-ordered interactions between different components or actors (e.g., API calls).
-3. Constraints and Best Practices
+2. Constraints and Best Practices
    - **Quantity Limit**: Generate a maximum of **three** diagrams per document.
    - **Relevance**: Ensure every diagram **directly** illustrates a concept explained in the surrounding text. Avoid generating diagrams for simple concepts that are easily understood through text alone.
-4. Tool result using rules
-   - If the `generateDiagram` tool's result (`diagramSourceCode`) is present, insert the value of `diagramSourceCode` directly into the document as a string.
-   - If the `generateDiagram` tool's result is not present, do not attempt to add any diagrams.
-
-</diagram_generation_guide>
+</diagram_generation_rules>

package/prompts/detail/d2-diagram/system-prompt.md

@@ -201,20 +201,6 @@ D2 provides special syntax for creating complex, structured diagram types common
 - Lifeline activations, also known as spans, are defined by connecting to a nested object on an actor. This syntax indicates the start and end of an operation on an actor's lifeline. Example: `alice.t1 -> bob: "invoke operation"`.
 - Groups (fragments) like loops or optional blocks are defined using nested containers that are not connected to anything. Example: `loop: { alice -> bob: "ping"; bob -> alice: "pong" }`.
 
-#### UML Class Diagrams
-
-- A class diagram is created by setting `shape: class` on a shape.
-- Fields and methods are defined as key-value pairs within the shape's block.
-- Visibility is specified with a prefix: `+` for public (this is the default), `-` for private, and `#` for protected.
-- Methods are identified by keys containing parentheses `()`. The value of the key specifies the return type. Example: `D2Parser: { shape: class; +reader: io.RuneReader; "-lookahead:rune"; "+peek(): (rune, eof bool)" }`.
-
-#### SQL Table Diagrams
-
-- An SQL table is created by setting `shape: sql_table`.
-- Columns are defined as keys, with their data type as the value.
-- Constraints (e.g., `primary_key`, `foreign_key`, `unique`) are defined in a nested block for the relevant column. Example: `users: { shape: sql_table; id: int { constraint: primary_key }; email: string { constraint: unique } }`.
-- Foreign key relationships are established by creating a standard connection from the foreign key column in one table to the primary key column in another. Example: `orders.user_id -> users.id`.
-
 
 ### 1.4 Strict Adherence to Predefined Keyword Values
 

package/prompts/detail/d2-diagram/user-prompt.md

@@ -12,6 +12,35 @@ Generate a d2 diagram that represents the following document content:
 
 </user_rules>
 
+<diagram_rules>
+
+1. Diagram Triggers and Types: Select the most appropriate type when describing the following specific content
+   - Architecture Diagram (High-Level)
+     - **Trigger**: When the document provides a high-level overview of a system, project, or the overall documentation set.
+     - **Content**: Must illustrate the main components, their relationships, and the overall structure.
+   - Structural Diagram (Module-Level)
+     - **Trigger**: When generating the introductory document for a major section or module.
+     - **Content**: Must show the key sub-components, files, or core concepts within that specific module.
+   - Process and Interaction Diagrams (Detailed)
+     - **Trigger**: When the document describes a workflow, a sequence of events, user interactions, or data flow.
+     - **Diagram Type Selection**:
+       - **Flowchart**: Use for step-by-step processes, algorithms, or decision-making logic.
+       - **Sequence Diagram**: Use for time-ordered interactions between different components or actors (e.g., API calls).
+2. Constraints and Best Practices
+   - **Keep it Simple**: Avoid overcomplicating the diagram.
+   - **Relevance**: Ensure every diagram **directly** illustrates a concept explained in the surrounding text. Avoid generating diagrams for simple concepts that are easily understood through text alone.
+
+</diagram_rules>
+
 <document_content>
 {{documentContent}}
-</document_content>
+</document_content>
+
+{% if diagramError %}
+<diagram_check_feedback>
+
+**Diagram generation error**
+{{ diagramError }}
+
+</diagram_check_feedback>
+{% endif %}

package/prompts/detail/generate/document-rules.md

@@ -10,7 +10,7 @@ Documentation Generation Rules:
 - **Markdown Syntax Constraint**: Use only GitHub Flavored Markdown (GFM) syntax by default. Prohibited extensions include: custom blocks `:::`, footnotes `[^1]: notes`, math formulas `$$ LaTeX`, highlighted text `==code==`, and other non-GFM syntax unless explicitly defined in custom component rules
 - Use proper Markdown link syntax, for example: [Next Chapter Title](next_chapter_path)
 - **Ensure next_chapter_path references either external URLs or valid paths from the documentation structure**—use absolute paths from the documentation structure
-- When DataSources includes third-party links, incorporate them appropriately throughout the document
+- When detailDataSource includes third-party links, incorporate them appropriately throughout the document
 - Structure each section with: title, introduction, code examples, response data samples, and explanatory notes. Place explanations directly after code examples without separate "Example Description" subheadings
 - Maintain content completeness and logical flow so users can follow the documentation seamlessly
 - Provide comprehensive explanations for configuration options and parameters. When parameters accept multiple values, explain each option's purpose and include code examples where applicable

package/prompts/detail/generate/system-prompt.md

@@ -43,14 +43,8 @@ Custom component generation rules:
 Custom code block generation rules:
 {% include "../custom/custom-code-block.md" %}
 
-{% include "../d2-diagram/guide.md" %}
-
 {% include "../../common/document/media-file-list-usage-rules.md" %}
 
-Tool result usage rules:
-- Only use the `"role": "tool"` result as the datasource for document enhancement.
-- Do not include `"role": "agent"` content in the final output.
-
 </content_generation_rules>
 
 

package/prompts/detail/generate/user-prompt.md

@@ -2,20 +2,21 @@
 {{ locale }}
 </user_locale>
 
-
 <user_rules>
 {{ rules }}
 
-** Output content in {{ locale }} language **
-</user_rules>
+** Output content in {{ locale }} language. **
+
+** Don't generate any diagram in the document, give boolean value in `needDiagram` field & plan a placeholder in document content for diagram (use `DIAGRAM_PLACEHOLDER` as placeholder text). **
 
+- **Necessary**: Generate diagrams only when necessary.
+</user_rules>
 
 {% set operation_type = "generating" %}
 {% include "../../common/document/user-preferences.md" %}
 
-
-<datasources>
-{{ detailDataSources }}
+<detail_dataSource>
+{{ detailDataSource }}
 
 {{ additionalInformation }}
 
@@ -23,66 +24,25 @@
 {{ assetsContent }}
 </media_file_list>
 
+</detail_dataSource>
 
 
-</datasources>
-
-{% if openAPISpec %}
-<openapi>
-
-**Goal:** Use the provided OpenAPI (Swagger) specification, align it with the current page objective, and leverage it to refine this document.
-
-**OpenAPI File Content:** 
-<openapi_doc>
-
-{{ openAPISpec }}
-
-</openapi_doc>
-
----
-
-### **Documentation Requirements and Constraints**
-
-1.  **Extract the core content:**
-    * Organize the document by functional modules.
-    * For each path item, include the following elements:
-        * HTTP method and path.
-        * Concise summary.
-        * Detailed description.
-        * Request parameters: name, location (`in`), type, required flag, description.
-        * Request body: describe its structure when present.
-        * Responses: at least the key status codes (e.g., 200, 201, 400, 500) and their schemas.
-
-2.  **Mandatory API description constraints (deduplication rule):**
-    * **Ensure that throughout the document (including preface, overview, etc.), any introduction to the project APIs appears only within this OpenAPI-generated "API reference" section.**
-    * **Never** repeat or expand the interface list elsewhere in the document (for example, "Quick Start" or "Architecture Overview" sections).
-
----
-
-**Expected output format:** A concise, clear, and easy-to-scan Markdown document.
-
-</openapi>
-{% endif %}
-
+{% include "../../common/document/openapi-usage-rules.md" %}
 
 {% include "./detail-example.md" %}
 
-
 {% if content %}
-Content from previous generation:
-<last_content>
+<previous_generation_content>
 {{content}}
-</last_content>
+</previous_generation_content>
 {% endif %}
 
-
 {% if detailFeedback %}
 <content_review_feedback>
 {{ detailFeedback }}
 </content_review_feedback>
 {% endif %}
 
-
 {% if feedback %}
 User feedback on previous generation:
 <feedback>
@@ -90,19 +50,12 @@ User feedback on previous generation:
 </feedback>
 {% endif %}
 
-
 <instructions>
-Generate detailed and well-structured document for the current {{nodeName}} based on user-provided information: current {{nodeName}} details (including title, description, path), DataSources, documentStructure (overall structural planning), and other relevant information.
-
-YOU SHOULD:
-- Use AFS tools `afs_list` `afs_search` or `afs_read` to gather relevant and accurate information to enhance the content.
-- Follow rules in `<diagram_generation_guide>`: use `generateDiagram` tool to create and embed a diagram when appropriate, following the diagram generation guidelines.
-- If the `generateDiagram` tool is not called, do not attempt to add any diagrams.
+Generate detailed and well-structured document for the current {{nodeName}} based on user-provided information: current {{nodeName}} details (including title, description, path), detailDataSource, documentStructure (overall structural planning), and other relevant information.
 
 <steps>
 1. Analyze the provided document structure and user requirements to plan the content.
 2. Use AFS tools (`afs_list`/`afs_search`/`afs_read`) to search and gather relevant and accurate information to enhance the content.
-3. Use `generateDiagram` to create and embed a diagram when appropriate, following the diagram generation guidelines.
-4. Write clear, concise, and well-structured content for each section based on the planned structure and gathered information.
+3. Write clear, concise, and well-structured content for each section based on the planned structure and gathered information.
 </steps>
 </instructions>

package/prompts/detail/update/system-prompt.md

@@ -40,12 +40,6 @@ Custom code block optimization rules:
 
 {% include "../../common/document/media-file-list-usage-rules.md" %}
 
-Diagram generation rules:
-{% include "../d2-diagram/guide.md" %}
-<diagram_generation_rules>
-{% include "../d2-diagram/system-prompt.md" %}
-</diagram_generation_rules>
-
 </content_optimization_rules>
 
 

package/prompts/detail/update/user-prompt.md

@@ -15,9 +15,9 @@
 {{originalContent}}
 </original_page_content>
 
-<datasources>
+<detail_dataSource>
 
-{{ detailDataSources }}
+{{ detailDataSource }}
 
 {{ additionalInformation }}
 
@@ -25,7 +25,7 @@
 {{ assetsContent }}
 </media_file_list>
 
-</datasources>
+</detail_dataSource>
 
 <user_feedback>
 {{feedback}}

package/prompts/structure/generate/system-prompt.md

@@ -14,34 +14,4 @@ You are an AI document strategist with the personality of an **INTJ (The Archite
 {% include "../../common/document-structure/conflict-resolution-guidance.md" %}
 
 
-<sub_structure>
-{% if isLargeContext %}
-Analyze the provided file list and DataSources to complete the document structure planning:
-  - If the DataSources contain sufficient context and already include content from all files in the file list, you can directly generate a detailed document structure.
-  - First plan the document structure based on DataSources and <file_list>, ensuring all user-provided information will be presented in the document
-  - Ensure initial planning has sufficient content separation to avoid oversized data sources when generating sub-documents
-  - For sections with extensive content, use the `generateSubStructure` tool to generate detailed sub-structures
-  - Trigger all Tool calls at once whenever possible
-  - When triggering Tool calls, only output Tool call related information
-  - Carefully check the data returned by the `generateSubStructure` tool, integrate all data, merge the complete document structure, and finally verify that it meets the requirements in <output_constraints>
-
-Using `generateSubStructure`:
-- When the provided file list is large and DataSources don't contain all file contents, resulting in an oversized context, split the generation into sub-document structures to make the context more focused and complete
-- Generate sub-documents to more effectively and fully utilize the data source files provided in <file_list>
-- Requires `parentDocument` and `subSourcePaths` as context parameters
-- `subSourcePaths` supports individual files and Glob Patterns, generation process:
-  - Analyze relevant files from the file list, include as many related files as possible to ensure complete context
-  - Selected files must come from <file_list>, ensure file paths are correct
-  - Consolidation Rules:
-    1. If all files from a single directory (e.g., src/) have been selected, consolidate them into a pattern like src/\*.
-    2. If multiple files with a common naming convention are selected (e.g., README.md, README-dockerfile.md, README-turbo.md), consolidate them into a pattern like README\*.md.
-    3. Ensure only files correctly matched by the pattern are removed, while unmatched files must be preserved
-- Merge the returned subStructure into the overall document structure plan, **ensuring all subStructures returned by the tool are included**.
-
-{% else %}
-The current context is sufficient, proceed directly with document structure planning based on DataSources.
-{% endif %}
-</sub_structure>
-
-
 {% include "../../common/document-structure/output-constraints.md" %}