@aigne/doc-smith 0.8.15-beta.6 → 0.8.15-beta.8

package/agents/generate/user-review-document-structure.mjs

@@ -140,6 +140,7 @@ export default async function userReviewDocumentStructure({ documentStructure, .
       // Call refineDocumentStructure agent with feedback
       await options.context.invoke(refineAgent, {
         ...rest,
+        datasources: rest.datasources[0].datasources,
         feedback: feedback.trim(),
         documentStructure: currentStructure,
         userPreferences,

package/agents/generate/utils/merge-document-structures.mjs

@@ -0,0 +1,54 @@
+export default async function mergeDocumentStructures(input, options) {
+  if (input.projectName) {
+    options.context.userContext.projectName = input.projectName;
+  }
+  if (input.projectDesc) {
+    options.context.userContext.projectDesc = input.projectDesc;
+  }
+
+  input.projectName = options.context.userContext.projectName;
+  input.projectDesc = options.context.userContext.projectDesc;
+
+  options.context.userContext.originalDocumentStructure ??= [];
+
+  const structure = options.context.userContext.originalDocumentStructure;
+
+  if (input.add) {
+    for (const { index, item } of input.add) {
+      if (index != null && index >= 0 && index < structure.length) {
+        structure.splice(index, 0, item);
+      } else {
+        structure.push(item);
+      }
+    }
+  }
+
+  if (input.update) {
+    for (const upd of input.update) {
+      const idx = structure.findIndex((i) => i.path === upd.path);
+      if (idx !== -1) {
+        structure[idx] = upd.item;
+      }
+    }
+  }
+
+  if (input.delete) {
+    for (const del of input.delete) {
+      const idx = structure.findIndex((i) => i.path === del.path);
+      if (idx !== -1) {
+        structure.splice(idx, 1);
+      }
+    }
+  }
+
+  options.context.userContext.originalDocumentStructure = structure.map((i, index) => {
+    delete i.index;
+
+    return {
+      index,
+      ...i,
+    };
+  });
+
+  return {};
+}

package/agents/schema/document-structure-item.yaml

@@ -0,0 +1,23 @@
+type: object
+description: Document structure item representing a node in the document hierarchy
+properties:
+  title:
+    type: string
+  description:
+    type: string
+  path:
+    type: string
+    description: Path in URL format, cannot be empty, cannot contain spaces or special characters, must start with /, no need to include language level, e.g., /zh/about should return /about
+  parentPath:
+    type: string
+    description: Parent node path, if null indicates it is a top-level node
+  sourceIds:
+    type: array
+    description: Associated sourceId from dataSources for subsequent translation and content generation, must come from sourceId in datasources, cannot have fake ids, **cannot be empty**
+    items:
+      type: string
+required:
+  - title
+  - description
+  - path
+  - sourceIds

package/agents/schema/document-structure.yaml

@@ -10,9 +10,7 @@ items:
       type: string
       description: Path in URL format, cannot be empty, cannot contain spaces or special characters, must start with /, no need to include language level, e.g., /zh/about should return /about
     parentId:
-      type:
-        - string
-        - "null"
+      type: string
       description: Parent node path, if null indicates it is a top-level node
     sourceIds:
       type: array

package/agents/translate/index.yaml

@@ -33,12 +33,12 @@ skills:
     name: batchTranslateDocument
     skills:
       - ../translate/translate-multilingual.yaml
-      - url: ./record-translation-history.mjs
     iterate_on: selectedDocs
     concurrency: 10
   - url: ../utils/check-feedback-refiner.mjs
     default_input:
       stage: translation_refine
+  - url: ./record-translation-history.mjs
   - url: ../utils/action-success.mjs
     default_input:
       action: '✅ Translation completed'

package/agents/translate/record-translation-history.mjs

@@ -1,16 +1,20 @@
 import { recordUpdate } from "../../utils/history-utils.mjs";
 
-export default function recordTranslationHistory({ feedback, path }) {
+export default function recordTranslationHistory({ selectedPaths, feedback }) {
   // Skip if no feedback provided
   if (!feedback?.trim()) {
     return {};
   }
 
+  if (!Array.isArray(selectedPaths) || selectedPaths.length === 0) {
+    return {};
+  }
+
   // Record translation history for this document
   recordUpdate({
     operation: "translation_update",
     feedback: feedback.trim(),
-    documentPath: path,
+    docPaths: selectedPaths,
   });
 
   return {};

package/agents/update/save-and-translate-document.mjs

@@ -1,4 +1,5 @@
 import pMap from "p-map";
+import { recordUpdate } from "../../utils/history-utils.mjs";
 
 export default async function saveAndTranslateDocument(input, options) {
   const { selectedDocs, docsDir, translateLanguages, locale } = input;
@@ -7,6 +8,16 @@ export default async function saveAndTranslateDocument(input, options) {
     return {};
   }
 
+  // Record history if feedback is provided
+  const doc = selectedDocs[0];
+  if (doc.feedback?.trim()) {
+    recordUpdate({
+      operation: "document_update",
+      feedback: doc.feedback.trim(),
+      docPaths: selectedDocs.map((v) => v.path),
+    });
+  }
+
   // Only prompt user if translation is actually needed
   let shouldTranslate = false;
   if (

package/agents/utils/choose-docs.mjs

@@ -18,6 +18,7 @@ export default async function chooseDocs(
     locale,
     reset = false,
     requiredFeedback = true,
+    title,
   },
   options,
 ) {
@@ -65,7 +66,7 @@ export default async function chooseDocs(
 
       // Let user select multiple files
       selectedFiles = await options.prompts.checkbox({
-        message: getActionText(isTranslate, "Select documents to {action}:"),
+        message: title || getActionText(isTranslate, "Select documents to {action}:"),
         source: (term) => {
           if (!term) return choices;
 

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,
@@ -21,6 +21,7 @@ import {
   DEFAULT_INCLUDE_PATTERNS,
 } from "../../utils/constants/index.mjs";
 import { isOpenAPISpecFile } from "../../utils/openapi/index.mjs";
+import { loadDocumentStructure } from "../../utils/docs-finder-utils.mjs";
 
 export default async function loadSources(
   {
@@ -195,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) => {
@@ -214,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) => ({ datasources: buildSourcesContent(i) }),
+  );
+
   const remoteFileList = [];
 
   sourceFiles.forEach((file) => {
@@ -225,37 +233,11 @@ 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");
 
   // Get the last documentation structure
-  let originalDocumentStructure;
-  if (outputDir) {
-    const documentStructurePath = path.join(outputDir, "structure-plan.json");
-    try {
-      const documentExecutionStructure = await readFile(documentStructurePath, "utf8");
-      if (documentExecutionStructure?.trim()) {
-        try {
-          // Validate that the content looks like JSON before parsing
-          const trimmedContent = documentExecutionStructure.trim();
-          if (trimmedContent.startsWith("{") || trimmedContent.startsWith("[")) {
-            originalDocumentStructure = JSON.parse(documentExecutionStructure);
-          } else {
-            console.warn(`structure-plan.json contains non-JSON content, skipping parse`);
-          }
-        } catch (err) {
-          console.error(`Failed to parse structure-plan.json: ${err.message}`);
-        }
-      }
-    } catch (err) {
-      if (err.code !== "ENOENT") {
-        console.warn(`Error reading structure-plan.json: ${err.message}`);
-      }
-      // The file does not exist or is not readable, originalDocumentStructure remains undefined
-    }
-  }
+  const originalDocumentStructure = await loadDocumentStructure(outputDir);
 
   // Get the last output result of the specified path
   let content;
@@ -308,7 +290,7 @@ export default async function loadSources(
   }
 
   return {
-    datasources: allSources,
+    datasources,
     content,
     originalDocumentStructure,
     files,
@@ -316,7 +298,6 @@ export default async function loadSources(
     totalTokens,
     totalLines,
     mediaFiles,
-    isLargeContext,
     allFilesPaths,
   };
 }
@@ -365,7 +346,13 @@ loadSources.output_schema = {
   type: "object",
   properties: {
     datasources: {
-      type: "string",
+      type: "array",
+      items: {
+        type: "object",
+        properties: {
+          datasources: { type: "string" },
+        },
+      },
     },
     files: {
       type: "array",
@@ -396,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/save-doc.mjs

@@ -1,4 +1,3 @@
-import { recordUpdate } from "../../utils/history-utils.mjs";
 import { shutdownMermaidWorkerPool } from "../../utils/mermaid-worker-pool.mjs";
 import { saveDoc as _saveDoc } from "../../utils/utils.mjs";
 
@@ -20,14 +19,6 @@ export default async function saveDoc({
     locale,
   });
 
-  if (feedback?.trim()) {
-    recordUpdate({
-      operation: "document_update",
-      feedback: feedback.trim(),
-      documentPath: path,
-    });
-  }
-
   if (isShowMessage) {
     // Shutdown mermaid worker pool to ensure clean exit
     try {

package/aigne.yaml

@@ -1,8 +1,7 @@
 #!/usr/bin/env aigne
 
-chat_model:
-  provider: google
-  name: gemini-2.5-pro
+model:
+  model: google/gemini-2.5-pro
   # name: gemini-2.5-flash
   temperature: 0.8
 agents:
@@ -11,7 +10,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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aigne/doc-smith",
-  "version": "0.8.15-beta.6",
+  "version": "0.8.15-beta.8",
   "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/detail/custom/custom-components.md

@@ -72,12 +72,11 @@ Suitable for displaying multiple links using a card list format, providing a ric
 
 ### Attributes
 
-- data-columns (optional): Number of columns, integer (e.g., 2, 3). Default is 2.
-  - Must contain multiple <x-card> elements internally.
+- data-columns (optional): Must be an **integer ≥ 2**. Values below 2 are disallowed. Default is 2.
 
 ### Children
 
-- Must contain multiple <x-card> elements internally.
+- Must contain multiple `<x-card>` elements internally.
 
 ### Usage Rules
 
@@ -107,6 +106,25 @@ Example 2: Two-column cards with images
 </x-cards>
 ```
 
+### Bad Examples
+
+Example 1: Using a single-column layout (`data-columns="1"`) is not allowed
+
+```md
+<x-cards data-columns="1">
+  <x-card data-title="Feature 1" data-icon="lucide:rocket">Description of Feature 1.</x-card>
+  <x-card data-title="Feature 2" data-icon="lucide:bolt">Description of Feature 2.</x-card>
+</x-cards>
+```
+
+Example 2: Contains only one `<x-card>` (must include multiple cards)
+
+```md
+<x-cards data-columns="2">
+  <x-card data-title="Card A" data-image="https://picsum.photos/id/10/300/300">Content A</x-card>
+</x-cards>
+```
+
 ## XField: Structured data field
 
 Suitable for displaying API parameters, return values, context data, and any structured data with metadata in a clean, organized format. Supports nested structures for complex data types.
@@ -414,6 +432,7 @@ Used to group multiple related `<x-field>` elements at the top level, indicating
 
 - **Top-Level Only**: Used only at the top level for grouping related `<x-field>` elements. Cannot be nested inside other `<x-field>` or `<x-field-group>` elements
 - **Structured Data Only**: Use `<x-field-group>` for fields **other than simple types** (`string`, `number`, `boolean`, `symbol`), e.g., Properties, Context, Parameters, Return values. For simple-type fields, use plain Markdown text.
+- **Spacing Around**: Always insert a blank line before and after `<x-field-group>` when it’s adjacent to Markdown content.
 
 ### Good Examples
 
@@ -482,4 +501,20 @@ Example 5: Using x-field-group for simple-type (violates "Structured Data Only"
 </x-field-group>
 ```
 
+Example 6: Missing blank line before x-field-group (violates "Spacing Around" rule)
+
+```md
+**Parameters**
+<x-field-group>
+  <x-field data-name="initialState" data-type="any" data-required="false">
+    <x-field-desc markdown>The initial state value.</x-field-desc>
+  </x-field>
+</x-field-group>
+
+`useReducer` returns an array with two items:
+<x-field-group>
+  <x-field data-name="dispatch" data-type="function" data-desc="A function that you can call with an action to update the state."></x-field>
+</x-field-group>
+```
+
 </custom_components_usage>

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" %}

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

@@ -1,15 +1,10 @@
+<datasources>
+Following are the partial or complete data sources provided by the user to help you design the document structure. Use these data sources to inform your structural planning.
 
-{% include "../../common/document-structure/user-locale-rules.md" %}
-
-{% include "../../common/document-structure/user-preferences.md" %}
-
+{{ datasources }}
 
-<file_list>
-{{allFilesPaths}}
-</file_list>
 
-<datasources>
-{{ datasources }}
+NOTICE: There are additional data source contents not displayed. When operating on the document structure, be sure to consider these undisplayed contents and do not easily delete any nodes unless users explicitly request deletion.
 </datasources>
 
 {% if userContext.openAPISpec %}
@@ -17,7 +12,7 @@
 
 **Goal:** Use the provided OpenAPI (Swagger) specification to design how the OpenAPI content and the overall document should be structured together.
 
-**OpenAPI File Content:** 
+**OpenAPI File Content:**
 <openapi_doc>
 
 {{ userContext.openAPISpec }}
@@ -47,20 +42,31 @@
 {% endif %}
 
 
-{% if originalDocumentStructure %}
 <last_document_structure>
-{{originalDocumentStructure}}
+projectName: |
+  {{projectName}}
+projectDesc: |
+  {{projectDesc}}
+
+{% if originalDocumentStructure %}
+{{ originalDocumentStructure | yaml.stringify }}
+{% else %}
+No previous document structure provided. generate a new structure based on the data sources!
+{% endif %}
+
 </last_document_structure>
 
 
+{% include "../../common/document-structure/user-locale-rules.md" %}
+
+{% include "../../common/document-structure/user-preferences.md" %}
+
 <last_document_structure_rule>
 If a previous structural plan (last_document_structure) is provided, follow these rules:
   1.  **Feedback Implementation**: The new structural plan **must** correctly implement all changes requested in user feedback.
   2.  **Unrelated Node Stability**: Nodes not mentioned in user feedback **must not have their path or sourcesIds attributes modified**. `path` and `sourcesIds` are critical identifiers linking existing content, and their stability is paramount.
     Ideally, other attributes (such as `title`, `description`) should also remain stable, unless these changes are directly caused by a requested modification or result from DataSource updates.
 </last_document_structure_rule>
-{% endif %}
-
 
 {% if documentStructure %}
 <review_document_structure>
@@ -92,27 +98,62 @@ Sub-structures must meet the following requirements:
 - Sub-structures are planned based on DataSources and the parent document's description
 - The parent document provides an overview of the planned content, while sub-structures directly plan the specific content to be displayed
 - Further break down and comprehensively display the content planned in the parent document
-- All sub-structures must have their parentId value set to {{parentDocument.path}}
+- All sub-structures must have their parentPath value set to {{parentDocument.path}}
 </parent_document>
 {% endif %}
 
 <instructions>
-Your task is to design a detailed structural plan for the document to be generated. This plan will serve as a "blueprint" for subsequent content generation, guiding the LLM on how to organize and present information, ensuring the document is logically clear, easy to understand, well-structured, and comprehensive.
+Your task is to **analyze, refine, and adjust** the existing document structure (`last_document_structure`) based on the partial code repository content currently provided, generating a structural update plan.
+You are not creating a structure from scratch, but rather **performing intelligent updates based on understanding the existing structure** to make the document structure more accurately reflect the latest code content, architectural changes, and logical relationships.
+
+## When using <datasource> data sources, please note the following:
+
+- Fully respect the project descriptions and usage instructions in README files, as these typically summarize the project's core functionality and objectives.
+- Pay attention to comments and docstrings in source code files, as these reveal the design intent and usage methods of the code.
+- Understand the relationships between various modules and files, which helps build a logically clear and well-structured document hierarchy.
+- Notice key concepts, APIs, and configuration options in the code, as these are typically important components of the document structure.
+- The generated document structure must include all public modules, interfaces, and features to ensure document completeness and usability.
+
+
+## Objective
+
+Your output should be a structured change plan containing the following three sections to indicate how to modify the existing document structure:
+
+- **add**: New structure items (array), can use index to specify insertion position (optional), each item is an object containing:
+  - `index` (optional): Insertion position index, if not specified, append to the end;
+  - `item`: New structure definition
+- **update**: Structure items that need modification (array), each item is an object containing:
+  - `path`: Path pointing to the node being updated;
+  - `update`: New structure definition
+
+## Behavior Rules
+
+1. **Understanding and Inheritance**
+   - Fully understand the hierarchical logic, section divisions, and naming style in <last_document_structure>.
+   - Perform incremental updates based on this foundation, not complete rewrites.
+   - Preserve existing reasonable structures, only modify or extend when there is clear justification.
+
+2. **Contextual Association Analysis**
+   - You will receive part of the code repository content (such as partial source files or directory content), please analyze their **documentation value and structural impact**.
+   - Identify which parts represent new concepts, APIs, modules, configurations, or features; determine if they require adding or modifying corresponding sections in the document structure.
 
-Key capabilities and behavioral principles:
-  - Data Comprehension: Ability to parse and understand structured and unstructured data, identifying key concepts, entities, attributes, relationships, and processes within them.
-  - Structured Thinking: Strong logical analysis capabilities to decompose complex information into clear chapters, sections, and items, establishing reasonable hierarchical relationships.
-  - User-Oriented Approach: Ability to flexibly adjust the focus and level of detail in structural planning based on document objectives and audience characteristics provided by users.
-  - Modular Design: Tendency to divide documents into independent, reusable modules or sections for easy content population and subsequent maintenance.
-  - Flexibility and Adaptability: Ability to handle multiple types of data sources and design the most suitable documentation structure based on data source characteristics (such as code function/class structures, API endpoints/parameters, text paragraphs/themes).
-  - Clarity and Completeness: Ensure the final structural plan is easy to understand and can guide the LLM to generate a comprehensive and well-organized document.
+3. **Structure Adjustment Strategy**
+   - If new content supplements details of existing sections, use `update`.
+   - If new content introduces new topics, modules, or hierarchies, use `add`.
+   - Ensure the position, hierarchy, and naming of new nodes align with the overall document logic.
 
+4. **Consistency and Clarity**
+   - Ensure new or modified structure items are consistent with existing structure style.
+   - Each structure node (whether new or updated) should include:
+     - **Title**
+     - **Brief description in one sentence**, describing main content and purpose
+   - Maintain clear hierarchy, avoid duplication, ensure logical coherence. Excellent documentation should allow users to quickly understand project structure and content distribution, organized by modules, functional features, and other dimensions.
 
-Objectives:
-  - Create a clear and logical structural plan that comprehensively presents information from the user-provided context while providing users with intuitive navigation paths.
-  - Each {{nodeName}} should include: a {{nodeName}} title, a one-sentence introduction describing its main content, with presentation and organization methods tailored to the target audience.
+5. **Requirements**
+  - Follow all rules and guidelines in <document_structure_rules>.
+  - Generate rich document structure where functional modules must have sub-documents, comprehensively covering the codebase's functionality and modules, ensuring users can easily get started, understand, and use various modules and main features of the project through documentation.
 
 {% include "../../common/document-structure/intj-traits.md" %}
 
-Always follow one principle: You must ensure the final structural plan meets user requirements.
+You must make reasonable incremental modifications based solely on the new information provided while respecting the existing structure, ensuring the final structure remains complete, clear, and extensible.
 </instructions>