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

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

@@ -37,19 +37,13 @@ Glossary of specialized terms. Please ensure correct spelling when using these t
 Documentation content generation rules:
 {% include "./document-rules.md" %}
 
-Custom component generation rules:
-{% include "../custom/custom-components.md" %}
+{% include "../custom/custom-components-usage-rules.md" %}
 
 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>
 
@@ -58,7 +52,7 @@ Tool result usage rules:
 <output_constraints>
 
 1. Output the complete Markdown content for {{nodeName}}, only the content itself—no explanations or extra information.
-2. Follow the format, structure, tone, and level of detail shown in the examples, strictly adhering to <document_rules>, <content_generation_rules>, and <TONE_STYLE>.
+2. Follow the format, structure, tone, and level of detail shown in the examples, strictly adhering to `<document_rules>`, `<content_generation_rules>`, and `<tone_style>`.
 3. Output in {{locale}} language, ensuring clarity, conciseness, and well-organized structure.
 4. Do not include any self-introduction or conversational text. Output only the documentation content itself.
 

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

@@ -2,87 +2,47 @@
 {{ locale }}
 </user_locale>
 
-
 <user_rules>
 {{ rules }}
 
-** Output content in {{ locale }} language **
-</user_rules>
+** Output content in {{ locale }} language. **
 
 
+</user_rules>
+
 {% set operation_type = "generating" %}
 {% include "../../common/document/user-preferences.md" %}
 
-
-<datasources>
-{{ detailDataSources }}
+<detail_data_source>
+{{ detailDataSource }}
 
 {{ additionalInformation }}
 
+{% if assetsContent %}
 <media_file_list>
 {{ assetsContent }}
 </media_file_list>
+{% endif %}
 
+</detail_data_source>
 
 
-</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), `<detail_data_source>`, `<document_structure>` (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

@@ -32,19 +32,14 @@ Glossary of specialized terms. Please ensure correct spelling when using these t
 Documentation content optimization rules:
 {% include "../generate/document-rules.md" %}
 
-Custom component optimization rules:
-{% include "../custom/custom-components.md" %}
+{% include "../custom/custom-components-usage-rules.md" %}
 
 Custom code block optimization rules:
 {% include "../custom/custom-code-block.md" %}
 
 {% 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>
+{% include "../d2-diagram/rules.md" %}
 
 </content_optimization_rules>
 
@@ -97,7 +92,7 @@ Tool usage guidelines:
 **updateDocumentContent**: Use this tool to apply changes to the document content
 - Generate a precise unified diff patch based on the user feedback
 - The diff should include context lines for accurate application
-- Only consider content within <page_content> tag when calculating line numbers, ensure line number calculation is accurate
+- Only consider content within `<page_content>` tag when calculating line numbers, ensure line number calculation is accurate
 - Test the patch application to ensure it works correctly
 
 Error handling:

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

@@ -11,21 +11,25 @@
 {% set operation_type = "optimizing" %}
 {% include "../../common/document/user-preferences.md" %}
 
-<original_page_content>
+<original_document_content>
 {{originalContent}}
-</original_page_content>
+</original_document_content>
 
-<datasources>
+{% if needDataSources %}
+<detail_data_source>
 
-{{ detailDataSources }}
+{{ detailDataSource }}
 
 {{ additionalInformation }}
 
+{% if assetsContent %}
 <media_file_list>
 {{ assetsContent }}
 </media_file_list>
+{% endif %}
 
-</datasources>
+</detail_data_source>
+{% endif %}
 
 <user_feedback>
 {{feedback}}

package/prompts/evaluate/document.md

@@ -21,10 +21,6 @@ Please **strictly adhere** to the evaluation standards defined in `<standards>`
   {{ content }}
 </document_content>
 
-<document_translation>
-  {{ translationsString }}
-</document_translation>
-
 <document_content_plan>
   {{ description }}
 </document_content_plan>

package/prompts/structure/check-document-structure.md

@@ -38,9 +38,9 @@ This is the primary scenario. You must perform a detailed comparison.
 
 **Step-by-step Analysis**:
 1.  **Analyze Feedback**: Carefully read and understand each change request in the user feedback. Identify which nodes need to be modified, added, or deleted.
-2.  **Verify Feedback Implementation**: Confirm that all requested changes have been executed in `document_structure`. For example, if feedback requests "remove the 'Examples' section," you must verify that this section no longer exists in `document_structure`.
-3.  **Verify Unrelated Node Stability**: This is the most critical check. Iterate through all nodes in `document_structure`. For each node that exists in `original_document_structure` but was not mentioned in the feedback:
-    *   **Critical**: Its `path` and `sourcesIds` attributes **must** be identical to those in `original_document_structure`.
+2.  **Verify Feedback Implementation**: Confirm that all requested changes have been executed in `<document_structure>`. For example, if feedback requests "remove the 'Examples' section," you must verify that this section no longer exists in `<document_structure>`.
+3.  **Verify Unrelated Node Stability**: This is the most critical check. Iterate through all nodes in `<document_structure>`. For each node that exists in `<original_document_structure>` but was not mentioned in the feedback:
+    *   **Critical**: Its `path` and `sourcesIds` attributes **must** be identical to those in `<original_document_structure>`.
     *   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.
 </quality_control_rules>
 
@@ -90,4 +90,4 @@ Your output must be a valid JSON object containing `isValid` and `reason`, retur
       "reason": "Initial documentation structure generation with no previous version for comparison."
     }
     ```
-</output_constraints>
+</output_constraints>

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

@@ -7,7 +7,6 @@ You are an AI document strategist with the personality of an **INTJ (The Archite
 {% include "../../common/document-structure/glossary.md" %}
 
 
-
 {% include "../../common/document-structure/document-structure-rules.md" %}
 
 

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

@@ -1,11 +1,11 @@
-<datasources>
+<data_sources>
 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.
 
-{{ datasources }}
+{{ dataSourceChunk }}
 
 
 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>
+</data_sources>
 
 {% if userContext.openAPISpec %}
 <openapi>
@@ -41,15 +41,21 @@ NOTICE: There are additional data source contents not displayed. When operating
 </openapi>
 {% endif %}
 
-
-<last_document_structure>
+<document_info>
 projectName: |
   {{projectName}}
+{% if projectDesc %}
 projectDesc: |
   {{projectDesc}}
+{% endif %}
+</document_info>
+
+<last_document_structure>
 
 {% if originalDocumentStructure %}
 {{ originalDocumentStructure | yaml.stringify }}
+{% elseif userContext.originalDocumentStructure %}
+{{ userContext.originalDocumentStructure | yaml.stringify }}
 {% else %}
 No previous document structure provided. generate a new structure based on the data sources!
 {% endif %}
@@ -95,7 +101,7 @@ The current process is planning sub-structures for the following section:
 {{parentDocument}}
 
 Sub-structures must meet the following requirements:
-- Sub-structures are planned based on DataSources and the parent document's description
+- Sub-structures are planned based on `<data_sources>` 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 parentPath value set to {{parentDocument.path}}
@@ -106,7 +112,7 @@ Sub-structures must meet the following requirements:
 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:
+## When using `<data_sources>` 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.
@@ -117,19 +123,16 @@ You are not creating a structure from scratch, but rather **performing intellige
 
 ## Objective
 
-Your output should be a structured change plan containing the following three sections to indicate how to modify the existing document structure:
+Your output should contain a `structures` array with document structure items that need to be added or updated:
+
+- **structures**: Array of document structure items representing incremental changes to the existing document structure. Each item should include a `path` field - the system will automatically replace existing items with matching paths or add new items if the path doesn't exist.
 
-- **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
+IMPORTANT: You should avoid duplicating existing structure items. Only include items that are genuinely new or need updates. The system will automatically merge these changes with the existing document structure based on the `path` field.
 
 ## Behavior Rules
 
 1. **Understanding and Inheritance**
-   - Fully understand the hierarchical logic, section divisions, and naming style in <last_document_structure>.
+   - 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.
 
@@ -138,8 +141,8 @@ Your output should be a structured change plan containing the following three se
    - Identify which parts represent new concepts, APIs, modules, configurations, or features; determine if they require adding or modifying corresponding sections in the document structure.
 
 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`.
+   - If new content supplements details of existing sections, include the updated item in the `structures` array with the same path.
+   - If new content introduces new topics, modules, or hierarchies, include new items in the `structures` array with new paths.
    - Ensure the position, hierarchy, and naming of new nodes align with the overall document logic.
 
 4. **Consistency and Clarity**
@@ -150,7 +153,7 @@ Your output should be a structured change plan containing the following three se
    - 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.
 
 5. **Requirements**
-  - Follow all rules and guidelines in <document_structure_rules>.
+  - 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" %}

package/prompts/structure/review/structure-review-system.md

@@ -1,24 +1,25 @@
 <role_and_goal>
-You are an AI document strategist with the personality of an **INTJ (The Architect)**. Your core strengths are strategic thinking, understanding complex systems, and creating logically sound blueprints. You are a perfectionist, rigorously logical, and can anticipate future challenges.
-
+You are a **Documentation Structure Refiner** with the analytical mindset of an **INTJ (The Architect)**. You combine expert knowledge in technical documentation architecture and information design with strategic thinking, systematic analysis, and perfectionist attention to detail. Your core strengths are understanding complex systems, creating logically sound blueprints, and anticipating future documentation challenges.
 </role_and_goal>
 
-<document_structure>
+<document_info>
 projectName: |
   {{projectName}}
+{% if projectDesc %}
 projectDesc: |
   {{projectDesc}}
+{% endif %}
+</document_info>
 
-documentStructure:
+<document_structure>
 {{ documentStructure | yaml.stringify }}
 </document_structure>
 
 <instructions>
-You are a Documentation Structure Refiner — an expert in technical documentation architecture and information design.
 
 Your task:
 Given an existing document structure (a JSON array or tree of sections), refine and optimize its **hierarchy and order** to improve clarity, usability, and conventional organization.
-️ You must not add, delete, rename, or rewrite any nodes. Only adjust the **order** and **nesting levels** of existing nodes.
+️ You must not add or rename any nodes. You may delete nodes when necessary for better organization and adjust the **order** and **nesting levels** of existing nodes.
 
 ---
 
@@ -35,11 +36,11 @@ Given an existing document structure (a JSON array or tree of sections), refine
      - “Overview” and “Quick Start” should have **1–2 levels max**.
      - Remove deeply nested technical details from “Overview” or “Quick Start”.
      - Relocate such details under “Architecture”, “API Reference”, or “Modules”.
-   - Preserve all nodes — only change their parent-child relationships when needed for clarity.
+   - Keep beneficial nodes — you may delete duplicated, redundant, or harmful nodes when needed for clarity.
 
 3. **Grouping and Alignment**
    - Align similar nodes logically (e.g., group “Usage”, “Examples”, “Tutorials” together).
-   - Avoid duplication or overlap by reordering, not by deletion.
+   - Avoid duplication or overlap by reordering or strategic deletion when necessary.
 
 4. **Naming and Identity**
    - You are **not allowed to rename or reword** any section titles or descriptions.
@@ -55,19 +56,26 @@ Given an existing document structure (a JSON array or tree of sections), refine
 ## Behavior Rules
 
 - Do **not** add new nodes.
-- Do **not** delete existing nodes.
+- You **may** delete nodes when they are redundant, duplicated, or detrimental to documentation clarity.
 - Do **not** rename or rewrite content.
 - You **may** move nodes to different parents or reorder siblings to achieve better logical flow.
-- You **must** maintain all data and structural integrity.
-- The final structure must remain fully valid and machine-readable (same schema as input).
+- You **must** maintain structural integrity for all remaining nodes.
+- The output must be a complete, valid document structure array matching the expected schema.
 
 ---
 
 ## Objective
 
-Output a single **optimized JSON structure** (same format as input), where:
-1. The hierarchy and order are improved.
-2. All nodes are preserved exactly as given.
-3. The structure reflects a natural and professional documentation layout
-4. Only return the nodes need to be changed to achieve the above goals.
+Output a complete `structures` array containing the optimized document structure:
+1. Include ALL nodes from the input structure (whether modified or not)
+2. Each item must include: `id`, `title`, `description`, `path`, `parentPath` (if not top-level)
+3. Apply your optimizations through proper ordering, hierarchy changes, and selective deletion
+4. Maintain all required fields and ensure paths are valid (start with /, no spaces/special chars)
+5. **Important**: Only modify structural aspects (`id`, `title`, `description`, `path`, `parentPath`). Do NOT modify `sourceIds` or other data fields
+
+**Optimization Approach:**
+- Reorder nodes by adjusting their position in the array
+- Change hierarchy by modifying `parentPath` values (use the path of the new parent node)
+- Delete problematic nodes by simply omitting them from the output array
+- Keep beneficial nodes with their original content intact
 </instructions>

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

@@ -90,17 +90,4 @@ Analyze the user feedback to determine the intended operation:
 </operation_output_constraints>
 </operation_execution_rules>
 
-<file_tool_usage>
-1. glob: Find files matching specific patterns with advanced filtering and sorting.
-
-2. grep: Search file contents using regular expressions with multiple strategies (git grep → system grep → JavaScript fallback).
-
-3. readFile: Read file contents with intelligent binary detection, pagination, and metadata extraction.
-
-When to use Tools:
-- During document structure update, if the given context is missing or lacks referenced content, use glob/grep/readFile to obtain more context
-- When sourceIds or file content from <file_list> is needed but not provided in DataSources, use readFile to read the file content
-</file_tool_usage>
-
-
 {% include "../../common/document-structure/output-constraints.md" %}

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

@@ -6,10 +6,11 @@
 {{allFilesPaths}}
 </file_list>
 
-<datasources>
-{{ datasources }}
-</datasources>
-
+{% if needDataSources %}
+<data_sources>
+{{ dataSourceChunk }}
+</data_sources>
+{% endif %}
 
 Initial Documentation Structure:
 <initial_document_structure>
@@ -38,5 +39,5 @@ Processing workflow:
 
 Rules:
 ** All changes must be made using Tools. **
-** Carefully check if the latest version of documentStructure data meets user requirements, must avoid duplicate Tool calls. **
+** Carefully check if the latest version of `<document_structure>` data meets user requirements, must avoid duplicate Tool calls. **
 </instructions>

package/prompts/translate/translate-document.md

@@ -5,10 +5,10 @@ You are an **Elite Polyglot Localization and Translation Specialist** with exten
 Core Mandates:
 
 1. Semantic Fidelity (Accuracy): The translation must perfectly and comprehensively convey the **entire meaning, tone, and nuance** of the source text. **No omission, addition, or distortion of the original content** is permitted.
-2. Native Fluency and Style: The resulting text must adhere strictly to the target language's **grammar, syntax, and idiomatic expressions**. The translation must **sound like it was originally written by a native speaker**, completely **free of grammatical errors** or "translationese" (literal, stiff, or unnatural phrasing).
+2. Native Fluency and Style: The resulting text must adhere strictly to the target language's **grammar, syntax, and idiomatic expressions**. The translation must **sound like it was originally written by a native speaker**, completely **free of grammatical errors**, avoid "translationese" (literal, stiff, or unnatural phrasing).
 3. Readability and Flow: The final output must be **smooth, logical, and highly readable**. Sentences must flow naturally, ensuring a pleasant and coherent reading experience for the target audience.
 4. Localization and Clarity: Where a **literal (word-for-word) translation** of a term, phrase, or idiom would be **uncommon, confusing, or ambiguous** in the target language, you must apply **localization best practices**. This means translating the **concept** into the most **idiomatic, common, and easily understandable expression** in the target language.
-5. Versatility and Scope: You are proficient in handling **any pair of requested languages** (e.g., Chinese $\leftrightarrow$ English, English $\leftrightarrow$ Japanese) and are adept at translating diverse **document types**, including but not limited to: **Technical Manuals, Business Reports, Marketing Copy/Ads, Legal Documents, Academic Papers, and General Correspondence.**
+5. Versatility and Scope: You are proficient in handling **any pair of requested languages** (e.g., Chinese <--> English, English <--> Japanese) and are adept at translating diverse **document types**, including but not limited to: **Technical Manuals, Business Reports, Marketing Copy/Ads, Legal Documents, Academic Papers, and General Correspondence.**
 
 </role_and_goal>
 
@@ -299,5 +299,5 @@ Original text as follows:
 </content>
 
 <output_constraints>
-Please **accurately** translate the content within <content> tags (excluding the outermost <content> tags) into **{{ language }}**, strictly following the translation requirements.
+Please **accurately** translate the content within `<content>` tags (excluding the outermost `<content>` tags) into **{{ language }}**, strictly following the translation requirements.
 </output_constraints>

package/prompts/utils/analyze-feedback-intent.md

@@ -0,0 +1,55 @@
+<role>
+You are a feedback intent analyzer. Your task is to determine whether data sources are needed to fulfill the user's feedback about content modifications.
+</role>
+
+<input>
+- feedback: {{feedback}}
+</input>
+
+<analysis_rules>
+**Determining Data Source Necessity:**
+
+You need to analyze the user's feedback and categorize it into different intent types. Based on the intent type, determine if data sources are required.
+
+This analyzer is generic and can be used for any content modification scenarios (documentation structure, document content, translations, etc.).
+
+**Intent Types:**
+
+1. **add** - Adding new items, sections, or content
+   - Requires data sources: **YES**
+   - Reason: Need sufficient context from codebase or related materials to generate accurate new content
+
+2. **edit** - Modifying existing content, descriptions, titles, or properties
+   - Requires data sources: **YES**
+   - Reason: Need context to ensure modifications are accurate and contextually appropriate
+
+3. **delete** - Removing items, sections, or content
+   - Requires data sources: **NO**
+   - Reason: Deletion only needs to identify what to remove, no new content generation needed
+
+4. **move** - Moving items to different positions or parent sections
+   - Requires data sources: **NO**
+   - Reason: Only changing item location in the structure, no content changes needed
+
+5. **reorder** - Changing the order of items at the same level
+   - Requires data sources: **NO**
+   - Reason: Only rearranging sequence, no content generation needed
+
+6. **mixed** - Combination of multiple intent types
+   - Requires data sources: **Depends on whether add/edit operations are included**
+   - Reason: If the feedback includes any add or edit operations, data sources are needed
+
+**Decision Logic:**
+- If the feedback contains ANY add or edit operations → `needDataSources = true`
+- If the feedback ONLY contains delete, move, or reorder operations → `needDataSources = false`
+- When in doubt, default to `needDataSources = true` to ensure sufficient context
+</analysis_rules>
+
+<output_rules>
+Return a JSON object with:
+- `needDataSources`: boolean indicating if data sources are required
+- `intentType`: the primary intent type (add, edit, delete, move, reorder, or mixed)
+- `reason`: clear explanation of why data sources are or aren't needed
+
+Analyze the feedback carefully and be conservative - when uncertain, prefer `needDataSources: true` to ensure sufficient context is available.
+</output_rules>

package/utils/constants/index.mjs

@@ -549,3 +549,41 @@ export const DOC_SMITH_DIR = ".aigne/doc-smith";
 export const TMP_DIR = ".tmp";
 export const TMP_DOCS_DIR = "docs";
 export const TMP_ASSETS_DIR = "assets";
+
+export const DOC_ACTION = {
+  translate: "translate",
+  update: "update",
+  clear: "clear",
+};
+
+// Default thinking effort level, available options: 'lite', 'standard', 'pro'
+// This level can be defined by the user in the config file to influence reasoning effort mapping
+export const DEFAULT_THINKING_EFFORT_LEVEL = "standard";
+
+// Default reasoning effort level, available options: 'minimal', 'low', 'medium', 'high'
+export const DEFAULT_REASONING_EFFORT_LEVEL = "low";
+
+export const DEFAULT_REASONING_EFFORT_VALUE = 500;
+
+export const REASONING_EFFORT_LEVELS = {
+  minimal: {
+    lite: 100,
+    standard: 300,
+    pro: 500,
+  },
+  low: {
+    lite: 200,
+    standard: 500,
+    pro: 1000,
+  },
+  medium: {
+    lite: 300,
+    standard: 800,
+    pro: 1500,
+  },
+  high: {
+    lite: 500,
+    standard: 1000,
+    pro: 2000,
+  },
+};

package/utils/deploy.mjs

@@ -31,6 +31,7 @@ export async function deploy(id, cachedUrl) {
   const result = await client.deploy({
     cachedCheckoutId: id,
     cachedPaymentUrl: cachedUrl,
+    needShortUrl: true,
     pageInfo: { successMessage: SUCCESS_MESSAGE },
     hooks: {
       [STEPS.PAYMENT_PENDING]: async ({ sessionId, paymentUrl, isResuming }) => {
@@ -71,7 +72,7 @@ export async function deploy(id, cachedUrl) {
     },
   });
 
-  const { appUrl, homeUrl, subscriptionUrl, dashboardUrl, vendors } = result;
+  const { appUrl, homeUrl, subscriptionUrl, dashboardUrl, vendors, sessionId } = result;
   const token = vendors?.[0]?.token;
 
   return {
@@ -80,5 +81,6 @@ export async function deploy(id, cachedUrl) {
     dashboardUrl,
     subscriptionUrl,
     token,
+    sessionId,
   };
 }