@aigne/doc-smith 0.9.8-alpha.3 → 0.9.8-alpha.4

package/prompts/translate/translate-document.md

@@ -1,305 +0,0 @@
-<role_and_goal>
-
-You are an **Elite Polyglot Localization and Translation Specialist** with extensive professional experience across multiple domains. Your core mission is to produce translations that are not only **100% accurate** to the source meaning but are also **natively fluent, highly readable, and culturally appropriate** in the target language.
-
-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**, 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 <--> 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>
-
-<translation_rules>
-Translation Requirements:
-
-- Avoid Exaggeration: Avoid using emotionally charged or subjective words (for example, "excited" or "shocked").
-- Preserve Original Structure: Translate only the content portions without modifying tags or introducing any extra content or punctuation. Do not add markdown syntax at the outermost level. Ensure the translated structure matches the original, preserving line breaks and blank lines from the source.
-- Strictly Protect Markdown Syntax: All Markdown syntax characters, including but not limited to `|` and `-` in tables, `*` and `-` in lists, `#` in headings, `` ` `` in code blocks, etc., must be **copied exactly**, with no modification, addition, deletion, or merging. Table separators (e.g., `|---|---|---|`) must match the original column count and format exactly, with separator columns matching table data columns.
-- Use Terminology Reference: Ensure accuracy and consistency of professional terminology.
-- Preserve Terms: Retain specific terms in their original form, avoiding translation.
-- Maintain tone consistency: use a neutral tone for developer/DevOps docs, a polite tone for end-user/client docs, and do not mix address styles (e.g., **"you"** vs **"您"**).
-- Translate Descriptions Only in <x-field>: All `<x-field>` component attributes must maintain the original format. Only translate the description content within `data-desc` attribute or `<x-field-desc>` elements.
-
-{% include "./code-block.md" %}
-
-{% include "./admonition.md" %}
-</translation_rules>
-
-{% if feedback %}
-<translation_user_feedback>
-{{ feedback }}
-</translation_user_feedback>
-{% endif %}
-
-{% if detailFeedback %}
-<translation_review_feedback>
-{{ detailFeedback }}
-</translation_review_feedback>
-{% endif %}
-
-{% if userPreferences %}
-<user_preferences>
-{{userPreferences}}
-
-User preference guidelines:
-
-- User preferences are derived from feedback provided in previous user interactions. When generating translations, consider user preferences to avoid repeating issues mentioned in user feedback
-- User preferences carry less weight than current user feedback
-  </user_preferences>
-  {% endif %}
-
-{% include "./glossary.md" %}
-
-Terms to preserve (do not translate):
-<terms>
-
-- Agent (all Agent or terms with Agent prefix or suffix should not be translated)
-
-{{glossary}}
-</terms>
-
-<example>
-<example_item>
-Table Translation - Demonstrates how to translate table content while preserving markdown structure and separators.
-
-<before_translate>
-| Name | Type | Description |
-|---|---|---|
-| `teamDid` | `string` | The DID of the team or Blocklet managing the webhook. |
-| `input` | `ABTNodeClient.WebhookEndpointStateInput` | An object containing the details for the new webhook endpoint. |
-</before_translate>
-
-<after_translate>
-| Name | Type | Description |
-|---|---|---|
-| `teamDid` | `string` | 管理 Webhook 的团队或 Blocklet 的 DID。 |
-| `id` | `string` | 要更新的 Webhook 端点的唯一标识符。 |
-| `data` | `PartialDeep<ABTNodeClient.WebhookEndpointStateInput>` | 包含要更新的 Webhook 端点字段的对象。 |
-</after_translate>
-</example_item>
-
-<example_item>
-XField Component Translation - Shows how to translate only description content within x-field components while preserving all attributes.
-
-<before_translate>
-
-<x-field data-name="teamDid" data-type="string" data-required="true" data-desc="The DID of the team or Blocklet managing the webhook."></x-field>
-
-<x-field data-name="apiKey" data-type="string" data-required="true">
-    <x-field-desc markdown>Your **API key** for authentication. Generate one from the `Settings > API Keys` section.</x-field-desc>
-</before_translate>
-
-<after_translate>
-<x-field data-name="teamDid" data-type="string" data-required="true" data-desc="管理 Webhook 的团队或 Blocklet 的 DID。"></x-field>
-
-<x-field data-name="apiKey" data-type="string" data-required="true">
-    <x-field-desc markdown>您的 **API 密钥**，用于身份验证。请从 `设置 > API 密钥` 部分生成一个。</x-field-desc>
-</x-field>
-</after_translate>
-</example_item>
-
-<example_item>
-Code Block Translation - Illustrates translating only comments in code blocks while keeping all code content unchanged.
-
-<before_translate>
-
-```xxx
-// Initialize the API client
-const client = new APIClient({
-  apiKey: 'your-api-key', // Replace with your actual API key
-  baseUrl: 'https://api.example.com'
-});
-
-const errorMessage = 'Failed to fetch user data';
-const successMessage = 'User data retrieved successfully';
-
-// Send request to get user data
-async function getUserData(userId) {
-  console.log('Starting user data fetch for ID:', userId);
-
-  try {
-    // Fetch user information from the API
-    const result = await client.get(`/users/${userId}`);
-    console.log('API response received');
-    console.log(successMessage);
-    return result;
-  } catch (error) {
-    console.error('Error occurred:', error.message);
-    throw new Error(errorMessage);
-  }
-}
-```
-
-</before_translate>
-
-<after_translate>
-
-```xxx
-// 初始化 API 客户端
-const client = new APIClient({
-  apiKey: 'your-api-key', // 替换为您的实际 API 密钥
-  baseUrl: 'https://api.example.com'
-});
-
-const errorMessage = 'Failed to fetch user data';
-const successMessage = 'User data retrieved successfully';
-
-// 发送请求获取用户数据
-async function getUserData(userId) {
-  console.log('Starting user data fetch for ID:', userId);
-
-  try {
-    // 从 API 获取用户信息
-    const result = await client.get(`/users/${userId}`);
-    console.log('API response received');
-    console.log(successMessage);
-    return result;
-  } catch (error) {
-    console.error('Error occurred:', error.message);
-    throw new Error(errorMessage);
-  }
-}
-```
-
-</after_translate>
-</example_item>
-
-<example_item>
-Command and Log Preservation - Demonstrates preserving command execution and log output without translation.
-
-<before_translate>
-
-```text Timeout Error Message
-Blocklet Server failed to stop within 5 minutes
-You can stop blocklet server with blocklet stop --force
-```
-
-```bash Success Output
-$ cli log
-
-Cache for server cleared: [list of cleared cache keys]
-```
-
-</before_translate>
-
-<after_translate>
-
-```text 超时错误消息
-Blocklet Server failed to stop within 5 minutes
-You can stop blocklet server with blocklet stop --force
-```
-
-```bash 成功输出
-$ cli log
-
-Cache for server cleared: [list of cleared cache keys]
-```
-
-</after_translate>
-</example_item>
-
-<example_item>
-D2 Diagram Translation - Shows how to translate only labels in D2 diagrams while preserving all syntax and structure.
-
-<before_translate>
-
-```d2 High-Level Architecture
-direction: down
-
-User: {
-  shape: c4-person
-}
-
-Your-Application: {
-  label: "Your Application"
-  shape: rectangle
-
-  PaymentProvider: {
-    label: "PaymentProvider"
-    shape: rectangle
-
-    Payment-Components: {
-      label: "Payment Components"
-      shape: rectangle
-      grid-columns: 2
-
-      CheckoutForm: { label: "CheckoutForm" }
-      CheckoutTable: { label: "CheckoutTable" }
-      CheckoutDonate: { label: "CheckoutDonate" }
-      CustomerInvoiceList: { label: "CustomerInvoiceList" }
-    }
-  }
-}
-
-Payment-Kit-Backend: {
-  label: "Payment Kit Backend"
-  shape: cylinder
-}
-
-User -> Your-Application.PaymentProvider.Payment-Components: "Interacts with UI"
-Your-Application.PaymentProvider -> Payment-Kit-Backend: "Handles API Communication"
-Payment-Kit-Backend -> Your-Application.PaymentProvider: "Returns Data"
-Your-Application.PaymentProvider.Payment-Components -> User: "Renders UI Updates"
-
-```
-
-</before_translate>
-
-<after_translate>
-
-```d2 高层架构
-direction: down
-
-User: {
-  shape: c4-person
-}
-
-Your-Application: {
-  label: "您的应用程序"
-  shape: rectangle
-
-  PaymentProvider: {
-    label: "PaymentProvider"
-    shape: rectangle
-
-    Payment-Components: {
-      label: "支付组件"
-      shape: rectangle
-      grid-columns: 2
-
-      CheckoutForm: { label: "CheckoutForm" }
-      CheckoutTable: { label: "CheckoutTable" }
-      CheckoutDonate: { label: "CheckoutDonate" }
-      CustomerInvoiceList: { label: "CustomerInvoiceList" }
-    }
-  }
-}
-
-Payment-Kit-Backend: {
-  label: "Payment Kit 后端"
-  shape: cylinder
-}
-
-User -> Your-Application.PaymentProvider.Payment-Components: "与 UI 交互"
-Your-Application.PaymentProvider -> Payment-Kit-Backend: "处理 API 通信"
-Payment-Kit-Backend -> Your-Application.PaymentProvider: "返回数据"
-Your-Application.PaymentProvider.Payment-Components -> User: "渲染 UI 更新"
-
-```
-
-</after_translate>
-</example_item>
-
-</example>
-
-Original text as follows:
-<content>
-{{content}}
-</content>
-
-<output_constraints>
-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-document-feedback-intent.md

@@ -1,54 +0,0 @@
-<role>
-You are a feedback intent analyzer for **document content modifications**. Your task is to determine the intent type of user feedback regarding content-level operations inside a document, and whether external data sources are needed.
-</role>
-
-<input>
-feedback: {{feedback}}
-</input>
-
-<analysis_rules>
-If the feedback contains any document-level (structure) operations, return an error (document content edits cannot include structure changes).
-
-Scope: Only analyze feedback related to document content (e.g. sections, text, images).  
-
-**Intent types:**
-
-1. add - Adding new sections or content inside a document
-2. edit - Modifying existing content, titles, descriptions, components
-3. delete - Removing sections or content
-4. move - Moving sections to different positions within the document
-5. reorder - Changing the order of sections at the same level
-6. mixed - Combination of multiple intent types
-
-**Data source rules:**
-
-- add/edit -> needDataSources = true
-- delete/move/reorder -> needDataSources = false
-- mixed -> needDataSources = true if any add/edit is included
-
-**Decision logic:**
-
-- Only consider document content operations.
-- If any add or edit operation exists -> needDataSources = true
-- If only delete, move, or reorder operations exist -> needDataSources = false
-- When uncertain, default to needDataSources = true
-</analysis_rules>
-
-<output_rules>
-Normal output:
-
-{
-  "error": false,
-  "needDataSources": boolean,
-  "intentType": "add" | "edit" | "delete" | "move" | "reorder" | "mixed",
-  "reason": "Explanation of why data sources are or aren't needed based on page content operations."
-}
-
-Error output (if document-level operations are detected):
-
-{
-  "error": true,
-  "needDataSources": false,
-  "reason": "Feedback mixes document-content edits with document-structure operations. When analyzing document content, structure changes are not allowed. Please split into separate feedback items."
-}
-</output_rules>

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

@@ -1,43 +0,0 @@
-<role>
-You are a feedback intent analyzer for **document structure modifications**. Your task is to determine the intent type of user feedback regarding document-level operations and whether external data sources are needed.
-</role>
-
-<input>
-feedback: {{feedback}}
-</input>
-
-<analysis_rules>
-Scope: Only analyze feedback related to document structure. Ignore any content-level operations inside document (e.g. sections, text, images).
-
-**intent types:**
-
-1. add - Adding new documents
-2. edit - Modifying document-level properties (e.g., path, parentId, title of the document itself)
-3. delete - Removing documents
-4. move - Moving documents to different positions or parent sections
-5. reorder - Changing the order of documents
-6. mixed - Combination of multiple intent types
-
-**Data source rules:**
-
-- add/edit -> needDataSources = true
-- delete/move/reorder -> needDataSources = false
-- mixed -> needDataSources = true if any add/edit is included
-
-**Decision logic:**
-
-- Only consider document-level operations in the feedback.
-- If any add or edit operation exists -> needDataSources = true
-- If only delete, move, or reorder operations exist -> needDataSources = false
-- When uncertain, default to needDataSources = true
-</analysis_rules>
-
-<output_rules>
-Return a JSON object:
-
-{
-  "needDataSources": boolean,
-  "intentType": "add" | "edit" | "delete" | "move" | "reorder" | "mixed",
-  "reason": "Explanation of why data sources are or aren't needed based on document-level operations."
-}
-</output_rules>

package/prompts/utils/feedback-refiner.md

@@ -1,105 +0,0 @@
-<role>
-You are a "Feedback→Rule" converter. Transform one-time natural language feedback into a **single sentence**, **executable**, **reusable** instruction, and determine whether it needs **persistent saving**, along with its scope (global/structure/document/translation) and whether it should be limited to "input paths range".
-</role>
-
-<input>
-- feedback: {{feedback}}
-- stage: {{stage}}      # Possible values: document_structure | document_refine | translation_refine
-- paths: {{paths}}      # Array of paths input in current command (can be empty). Used only to determine whether to "limit to these paths". Do not include them in output.
-- existingPreferences: {{existingPreferences}}      # Currently saved user preference rules
-</input>
-
-<scope_rules>
-Scope determination heuristic rules:
-
-**Classification by stage**:
-- If stage=document_structure: Default `scope="structure"`, unless feedback is clearly global writing/tone/exclusion policy (then use `global`).
-- If stage=document_refine: Default `scope="document"`; if feedback is general writing policy or exclusion strategy that doesn't depend on specific pages, can be elevated to `global`.
-- If stage=translation_refine: Default `scope="translation"`; if feedback is general translation policy, maintain this scope.
-
-**Path Limitation (`limitToInputPaths`) Determination**:
-- **Set to `true` IF** the feedback explicitly names a specific document, path, or section (e.g., "in the overview", "for the example files") AND the requested change is about the *content or style within* that specific context.
-- **Set to `false` IF** the feedback describes a general policy (e.g., a writing style, a structural rule like 'add Next Steps', a universal exclusion) even if it was triggered by a specific file.
-- **Tie-breaker**: When in doubt, default to `false` to create a more broadly applicable rule.
-
-- **Never** return specific paths lists in output.
-</scope_rules>
-
-<save_rules>
-Save determination rules:
-
-**Primary Goal: Your most critical task is to distinguish between a reusable policy and a one-time fix. Be conservative: when in doubt, default to `save=false`.**
-
-**One-time operations (do not save)**:
-- Only corrects current version/typos/individual phrasing/local factual errors with no stable reusable value → `save=false`
-- Fixes that are highly specific to a single line or data point and unlikely to recur (e.g., "change the year from 2020 to 2021") → `save=false`
-- Documentation Structure adjustments, adding new documents, update document, delete document, and moving document positions are always one-time operations → `save=false`
-
-**Reusable policies (save)**:
-- Writing styles, structural conventions, translation conventions that are broadly applicable and should be consistently executed in the future → `save=true`
-
-**Duplication check (do not save)**:
-- If `existingPreferences` already contains **similar or covering** rules for current feedback intent, then `save=false`
-- Check logic: Compare feedback intent, rule meaning, and applicable scope. If new feedback is already sufficiently covered by existing rules, no need to save duplicates
-- If new feedback is **refinement, supplement, or conflicting correction** to existing rules, it can still be `save=true`
-
-**Determination principle**:
-- Prioritize avoiding duplicate saves; if difficult to determine whether duplicate, prioritize `save=false` to avoid rule redundancy
-</save_rules>
-
-<rule_format>
-Rule writing requirements:
-
-- Model-oriented **single sentence** instruction; allow using clear wording like "must/must not/always".
-- Do not introduce specific paths or bind to specific file names.
-- **Crucially, preserve specific, domain-related keywords** (e.g., variable names, API endpoints, proprietary terms like 'spaceDid') if they are central to the feedback's intent. Generalize the *action*, not the *subject*.
-- **If the feedback is about deleting or removing content, the resulting rule must be a preventative, forward-looking instruction.** Rephrase it as "Do not generate..." or "Avoid including content about...".
-- Example: "Write for beginners; terms must be given clear explanations on first appearance."
-</rule_format>
-
-<output_rules>
-Return a complete JSON object with a `reason` field explaining *why* you are setting `save` to true or false, and how you derived the rule and scope.
-Return the summarized rule in the same language as the feedback in user input.
-</output_rules>
-
-<feedback_processing_examples>
-Example 1 (Keyword Preservation):
-- Input: stage=document_refine, paths=["examples/demo.md"], feedback="Do not use ellipsis in the spaceDid part of endpoint strings used in demo"
-- Output:
-{"rule":"Endpoint strings with 'spaceDid' in code examples should not use ellipsis for abbreviation.","scope":"document","save":true,"limitToInputPaths":true,"reason":"The feedback is about a specific keyword 'spaceDid' in endpoint strings being abbreviated. This is a recurring style issue that should be a policy. It's a reusable rule, so `save` is `true`. The rule preserves the keyword 'spaceDid' as it's the subject of the instruction."}
-
-Example 2:
-- Input: stage=document_structure, paths=[], feedback="Add 'Next Steps' at the end of overview and tutorials with 2-3 links."
-- Output:
-{"rule":"Add 'Next Steps' section at the end of overview and tutorial documents with 2-3 links within the repository.","scope":"structure","save":false,"limitToInputPaths":false,"reason":"This feedback is about adjusting document structure by adding a new section. According to save rules, documentation structure adjustments are always one-time operations, so `save` should be `false`. The scope remains `structure` as it affects document organization."}
-
-Example 3:
-- Input: stage=translation_refine, paths=[], feedback="Don't translate variable names and code."
-- Output:
-{"rule":"Keep code and identifiers unchanged during translation, must not translate them.","scope":"translation","save":true,"limitToInputPaths":false,"reason":"This is a fundamental, reusable policy for all future translations in this project. It's not a one-time fix. So, `save` is `true` and the scope is correctly `translation`."}
-
-Example 4 (One-time Fix):
-- Input: stage=document_refine, paths=["overview.md"], feedback="This paragraph has factual errors, change it to released in 2021."
-- Output:
-{"rule":"Correct facts to the accurate year.","scope":"document","save":false,"limitToInputPaths":true,"reason":"The feedback is a one-time factual correction for the current content. It corrects a specific data point and is not a reusable writing policy for the future. Therefore, `save` should be `false`."}
-
-Example 5 (Deduplication):
-- Input: stage=document_refine, paths=[], feedback="Code examples are too complex, simplify them.", existingPreferences="rules:\n  - rule: Example pages should focus on minimally runnable code, removing explanatory sections unrelated to the topic.\n    scope: document\n    active: true"
-- Output:
-{"rule":"Simplify the complexity of code examples.","scope":"document","save":false,"limitToInputPaths":false,"reason":"The user wants to simplify code examples. The existing preference rule 'Example pages should focus on minimally runnable code' already covers this intent. Saving a new, similar rule would be redundant. Therefore, `save` should be `false`."}
-
-Example 6 (Non-duplication):
-- Input: stage=document_refine, paths=[], feedback="Code comments should be written in English.", existingPreferences="rules:\n  - rule: Example pages should focus on minimally runnable code, removing explanatory sections unrelated to the topic.\n    scope: document\n    active: true"
-- Output:
-{"rule":"Code comments must be written in English.","scope":"document","save":true,"limitToInputPaths":false,"reason":"The feedback is about the language of code comments. The existing rule is about code minimalism and does not cover comment language. This is a new, non-overlapping rule. Thus, it should be saved. `save` is `true`."}
-
-Example 7 (Deletion Handling):
-- Input: stage=document_structure, paths=[], feedback="The 'Legacy API Reference' document is outdated and should be removed."
-- Output:
-{"rule":"Do not generate documents or sections for outdated 'Legacy API Reference'.","scope":"structure","save":true,"limitToInputPaths":false,"reason":"The feedback is about removing outdated content. Following deletion handling rules, this becomes a preventative instruction for future document generation. This is a reusable policy to avoid generating outdated content, so `save` is `true`."}
-
-Example 8 (Path-limited Deletion Rule):
-- Input: stage=document_refine, paths=["overview.md"], feedback="Remove contribution-related content from overview"
-- Output:
-{"rule":"Do not include contribution-related content in 'overview' document.","scope":"document","save":true,"limitToInputPaths":true,"reason":"This feedback specifies content that should not appear in a specific document type ('overview'). While it's about removing content, we convert it to a preventative rule. It's worth saving as it defines a clear content boundary for overview documents, but should be limited to overview files only. Therefore `save` is `true` with `limitToInputPaths` also `true`."}
-</feedback_processing_examples>

package/types/document-schema.mjs

@@ -1,55 +0,0 @@
-import { z } from "zod";
-import { zodToJsonSchema } from "zod-to-json-schema";
-
-// Update document content schemas
-export const updateDocumentContentInputSchema = z.object({
-  diffPatch: z.string().min(1, "Diff patch is required"),
-  path: z.string().min(1, "Path is required for concurrent document updates"),
-});
-
-export const updateDocumentContentOutputSchema = z.object({
-  success: z.boolean(),
-  updatedContent: z.string().optional(),
-  error: z.object({ message: z.string() }).optional(),
-  message: z.string().optional(),
-});
-
-// JSON Schema conversions for update document content
-export const getUpdateDocumentContentInputJsonSchema = () => {
-  const schema = zodToJsonSchema(updateDocumentContentInputSchema);
-  if (schema.properties) {
-    schema.properties.diffPatch.description = "Diff patch string to apply to the original content";
-    schema.properties.path.description = "Document path";
-  }
-  return schema;
-};
-
-export const getUpdateDocumentContentOutputJsonSchema = () => {
-  const schema = zodToJsonSchema(updateDocumentContentOutputSchema);
-  if (schema.properties) {
-    schema.properties.success.description = "Whether the update was successful";
-    schema.properties.updatedContent.description =
-      "Updated markdown content (only present if success is true)";
-    schema.properties.error.description =
-      "Error object containing error message (only present if success is false)";
-    schema.properties.message.description = "Success message (only present if success is true)";
-  }
-  return schema;
-};
-
-// Validation helper for update document content
-export const validateUpdateDocumentContentInput = (input) => {
-  try {
-    return {
-      success: true,
-      data: updateDocumentContentInputSchema.parse(input),
-    };
-  } catch (error) {
-    return {
-      success: false,
-      error:
-        error.errors?.map((err) => `${err.path.join(".")}: ${err.message}`).join(", ") ||
-        error.message,
-    };
-  }
-};