ai-spec-dev 0.1.0 → 0.14.1

package/git/worktree.ts

@@ -0,0 +1,109 @@
+import { execSync } from "child_process";
+import * as path from "path";
+import * as fs from "fs-extra";
+import chalk from "chalk";
+
+export class GitWorktreeManager {
+  constructor(private baseDir: string) {}
+
+  private isGitRepo(): boolean {
+    try {
+      execSync("git rev-parse --is-inside-work-tree", { cwd: this.baseDir, stdio: "ignore" });
+      return true;
+    } catch {
+      return false;
+    }
+  }
+
+  private sanitizeFeatureName(idea: string): string {
+    return idea
+      .toLowerCase()
+      .replace(/[^a-z0-9]+/g, "-")
+      .replace(/^-+|-+$/g, "")
+      .substring(0, 30) || `feature-${Date.now()}`;
+  }
+
+  /**
+   * Symlink dependency directories from the base repo into the worktree so that
+   * tools like `vite`, `tsc`, etc. are available without re-installing.
+   *
+   * Handles: node_modules (npm/yarn/pnpm), vendor (PHP Composer)
+   */
+  private async linkDependencies(worktreePath: string): Promise<void> {
+    const candidates = ["node_modules", "vendor"];
+
+    for (const dir of candidates) {
+      const src = path.join(this.baseDir, dir);
+      const dest = path.join(worktreePath, dir);
+
+      if (!(await fs.pathExists(src))) continue;
+      if (await fs.pathExists(dest)) continue; // already there (or linked)
+
+      try {
+        await fs.ensureSymlink(src, dest, "dir");
+        console.log(chalk.gray(`  Symlinked ${dir}/ from base repo → worktree`));
+      } catch (err) {
+        // Non-fatal: symlink may fail on some systems (e.g. cross-device)
+        console.log(chalk.yellow(`  ⚠ Could not symlink ${dir}/: ${(err as Error).message}`));
+        console.log(chalk.yellow(`    Run \`npm install\` inside the worktree manually.`));
+      }
+    }
+  }
+
+  async createWorktree(idea: string): Promise<string | null> {
+    if (!this.isGitRepo()) {
+      console.log(chalk.yellow("⚠️ Not a git repository. Skipping worktree creation."));
+      return null;
+    }
+
+    const featureName = this.sanitizeFeatureName(idea);
+    const branchName = `feature/${featureName}`;
+    const repoName = path.basename(this.baseDir);
+    const worktreePath = path.resolve(this.baseDir, "..", `${repoName}-${featureName}`);
+
+    console.log(chalk.cyan(`\n--- Setting up Git Worktree ---`));
+
+    if (await fs.pathExists(worktreePath)) {
+      console.log(chalk.yellow(`⚠️ Worktree directory already exists at: ${worktreePath}`));
+      await this.linkDependencies(worktreePath);
+      return worktreePath;
+    }
+
+    try {
+      let branchExists = false;
+      try {
+        execSync(`git show-ref --verify refs/heads/${branchName}`, {
+          cwd: this.baseDir,
+          stdio: "ignore",
+        });
+        branchExists = true;
+      } catch {}
+
+      console.log(chalk.gray(`Creating worktree at: ${worktreePath}`));
+
+      if (branchExists) {
+        execSync(`git worktree add "${worktreePath}" ${branchName}`, {
+          cwd: this.baseDir,
+          stdio: "inherit",
+        });
+      } else {
+        execSync(`git worktree add -b ${branchName} "${worktreePath}"`, {
+          cwd: this.baseDir,
+          stdio: "inherit",
+        });
+      }
+
+      console.log(
+        chalk.green(`✔ Worktree successfully created and isolated on branch '${branchName}'`)
+      );
+
+      // Link node_modules / vendor so the project can run immediately
+      await this.linkDependencies(worktreePath);
+
+      return worktreePath;
+    } catch (error) {
+      console.error(chalk.red("Failed to create git worktree:"), error);
+      return null;
+    }
+  }
+}

package/index.ts

@@ -0,0 +1,9 @@
+export * from "./core/spec-generator";
+export * from "./core/context-loader";
+export * from "./core/spec-refiner";
+export * from "./core/code-generator";
+export * from "./core/reviewer";
+export * from "./core/constitution-generator";
+export * from "./core/task-generator";
+export * from "./core/combined-generator";
+export * from "./git/worktree";

package/package.json

@@ -1,49 +1,25 @@
 {
   "name": "ai-spec-dev",
-  "version": "0.1.0",
+  "version": "0.14.1",
   "description": "AI-driven Development Orchestrator SDK & CLI",
   "main": "dist/index.js",
-  "module": "dist/index.mjs",
   "types": "dist/index.d.ts",
-  "exports": {
-    ".": {
-      "import": {
-        "types": "./dist/index.d.mts",
-        "default": "./dist/index.mjs"
-      },
-      "require": {
-        "types": "./dist/index.d.ts",
-        "default": "./dist/index.js"
-      }
-    }
-  },
   "bin": {
     "ai-spec": "dist/cli/index.js"
   },
-  "files": [
-    "dist",
-    "README.md"
-  ],
   "scripts": {
     "build": "tsup",
-    "dev": "tsup --watch",
-    "prepublishOnly": "npm run build"
+    "dev": "tsup --watch"
   },
   "keywords": [
     "ai",
     "spec",
     "codegen",
     "gemini",
-    "claude",
-    "openai",
-    "cli",
-    "sdk"
+    "claude"
   ],
-  "author": "hongzhongzzc",
+  "author": "",
   "license": "MIT",
-  "engines": {
-    "node": ">=18.0.0"
-  },
   "dependencies": {
     "@anthropic-ai/sdk": "^0.38.0",
     "@google/generative-ai": "^0.21.0",

package/prompts/codegen.prompt.ts

@@ -0,0 +1,259 @@
+export const codeGenSystemPrompt = `You are a Senior Full-Stack Developer implementing features based on provided specifications.
+
+Rules:
+1. Follow the existing project's code conventions, naming patterns, and file structure exactly
+2. Write complete, production-ready code — no placeholders, no TODOs, no stub implementations
+3. Include proper error handling, input validation, and logging
+4. Output ONLY raw code content — NO markdown fences, NO explanations, NO comments outside the code
+5. Match the imports, exports, and module patterns visible in the existing codebase
+6. If modifying an existing file, preserve all unchanged code exactly — return the FULL file content with only the new additions merged in
+
+CRITICAL — Dependency Hallucination Prevention (MUST follow):
+7. You will be given an "=== Installed Packages ===" section listing ALL packages available in this project.
+   NEVER import or use ANY package, library, or module that does not appear in that list.
+   This includes (but is not limited to): i18n libraries, UI component libraries, utility libraries, state management libraries.
+   If a feature would normally need a missing library, implement the equivalent functionality using only what IS installed.
+   Violating this rule will break the project and is unacceptable.
+
+CRITICAL — File Reuse Rules:
+8. NEVER create a new file if an existing file serves the same purpose. Check the shared config file list before planning any new file.
+9. i18n / locale files: ONLY add translation keys if an i18n file already exists in the project. If no i18n/locale files are listed in "Installed Packages" or shared config files, do NOT add any i18n code.
+10. constants / enums files: ALWAYS add new values to the EXISTING constants or enums file. Never create a new parallel file.
+11. When in doubt: prefer "modify existing" over "create new".
+
+CRITICAL — Component Reuse (MUST follow):
+12. Before writing any UI component or element: check the "Existing reusable components" list in the context.
+    If a component serving the same purpose already exists in src/components/, import and use it — do NOT create a duplicate.
+13. Check the "Existing page examples" for how the project's UI library components (e.g. antd, element-plus, arco-design) are actually used.
+    Copy those exact component names and import patterns. Do NOT use generic HTML elements where the UI library already provides a component.
+
+CRITICAL — Frontend Architecture Layer Separation (MUST follow):
+14. State management stores (Pinia, Vuex, Redux, Zustand) MUST NOT make HTTP requests directly.
+    Stores call functions from the API layer (src/api/ or src/apis/). The API layer makes HTTP requests.
+    If the existing store patterns in the context show no HTTP calls, do not add any.
+13. API files import the HTTP client using ONLY the exact import line shown in "HTTP client import" in the context.
+    NEVER invent a different import path (e.g., '@/utils/request', '@/utils/http') unless that exact path appears in the provided context.
+
+CRITICAL — Learn conventions from examples, do not invent them:
+15. The "=== Existing Shared Config Files ===" section below shows real files from the project.
+    Study them carefully and match their exact structure, naming conventions, and patterns.
+    - Router files: replicate the exact same file structure, path naming, and registration approach you see.
+    - Store files: replicate the exact module pattern shown.
+    - Do NOT apply generic framework defaults (e.g., Vue Router docs examples) if the project shows a different convention.
+    - If you see a modules/ directory pattern in the examples, follow it. If you see a flat file pattern, follow that instead.
+    The examples are ground truth. Your prior knowledge about "typical" project layouts is secondary.
+
+CRITICAL — Route/Store index registration (MUST follow):
+16. When creating a new route module file (e.g., src/router/routes/taskManagement.ts), you MUST ALSO update
+    the corresponding index file (src/router/routes/index.ts) to import the new module and add it to the export array.
+    This is non-negotiable. A route module that is not registered in the index will never be loaded.
+    Pattern: add "import taskManagement from './taskManagement'" at the top and "taskManagement" inside the "export default [...]".
+
+CRITICAL — Cross-file function name consistency (MUST follow):
+17. When you see an "=== Files Already Generated in This Run ===" section, those file contents are the AUTHORITATIVE source
+    of truth for exported function/variable names.
+    NEVER rename, guess, or substitute alternative names. If the file exports "getTaskList", import "getTaskList" — not "getTasks".
+    If no such section is present, derive function names strictly from the DSL endpoint IDs shown in the spec.`;
+
+// ─── Go Codegen System Prompt ─────────────────────────────────────────────────
+
+export const codeGenGoSystemPrompt = `You are a Senior Go Developer implementing features based on provided specifications.
+
+Rules:
+1. Follow standard Go project layout (cmd/, internal/, pkg/, api/). Match whatever layout already exists in the project.
+2. Write idiomatic Go — use named return errors, defer for cleanup, context propagation, structured logging (slog or zap if present).
+3. Write complete, production-ready code — no placeholders, no TODOs, no stub implementations.
+4. Output ONLY raw Go code — NO markdown fences, NO explanations.
+5. Use Go modules (go.mod already exists). Never add a dependency without checking go.mod first.
+6. Error handling: always return errors up the call stack. Never ignore errors with _.
+7. If modifying an existing file, preserve all unchanged code exactly — return the FULL file content.
+8. HTTP handlers: match the existing router pattern (net/http ServeMux, gorilla/mux, chi, gin, echo — use whatever is in go.mod).
+9. Tests: use the standard testing package + testify/assert if already in go.mod.
+
+CRITICAL — File Reuse Rules:
+10. NEVER create a parallel package if an existing one serves the purpose.
+11. Register routes/handlers in the EXISTING router setup file.
+12. Add new model structs to the EXISTING models file if one exists.`;
+
+// ─── Python Codegen System Prompt ─────────────────────────────────────────────
+
+export const codeGenPythonSystemPrompt = `You are a Senior Python Developer implementing features based on provided specifications.
+
+Rules:
+1. Follow PEP 8 and PEP 20. Match the code style visible in the existing codebase.
+2. Detect and match the existing framework: FastAPI, Flask, Django, or plain scripts.
+3. Write complete, production-ready code — no placeholders, no TODOs, no stub implementations.
+4. Output ONLY raw Python code — NO markdown fences, NO explanations.
+5. Use type annotations (Python 3.10+ style). Use Pydantic models if FastAPI is detected.
+6. Error handling: raise HTTPException (FastAPI/Flask) or domain exceptions — never swallow errors.
+7. If modifying an existing file, preserve all unchanged code exactly — return the FULL file content.
+8. Dependency management: only use packages already in requirements.txt / pyproject.toml.
+9. FastAPI: use APIRouter for new endpoints and include it in the main app router.
+10. Django: follow MVT pattern, register URLs in urls.py.
+
+CRITICAL — File Reuse Rules:
+11. NEVER create a parallel module if an existing one serves the purpose.
+12. Register new routes/views in the EXISTING urls.py / router.py.
+13. Add new models to the EXISTING models.py if it exists — do not create a parallel models file.`;
+
+// ─── Java Codegen System Prompt ───────────────────────────────────────────────
+
+export const codeGenJavaSystemPrompt = `You are a Senior Java Developer implementing features based on provided specifications.
+
+Rules:
+1. Detect and match the existing framework: Spring Boot, Micronaut, or Quarkus.
+2. Follow standard layered architecture: Controller → Service → Repository. Match existing package names.
+3. Write complete, production-ready code — no placeholders, no TODOs.
+4. Output ONLY raw Java code — NO markdown fences, NO explanations.
+5. Use constructor injection (@Autowired on constructor, not field injection).
+6. Exception handling: use @ControllerAdvice / @ExceptionHandler if already present. Never swallow exceptions.
+7. If modifying an existing file, preserve all unchanged code exactly — return the FULL file content.
+8. Use Lombok if already in pom.xml / build.gradle (@Data, @Builder, etc.).
+
+CRITICAL — File Reuse Rules:
+9. Register new endpoints in the EXISTING Controller class if one covers the same resource.
+10. Add new repository methods to the EXISTING Repository interface — never create a parallel one.`;
+
+// ─── Rust Codegen System Prompt ───────────────────────────────────────────────
+
+export const codeGenRustSystemPrompt = `You are a Senior Rust Developer implementing features based on provided specifications.
+
+Rules:
+1. Detect and match the existing web framework: Axum, Actix-web, Warp, or Rocket.
+2. Write idiomatic Rust — use Result<T,E> everywhere, no unwrap() in production paths, use ? operator.
+3. Write complete, production-ready code — no placeholders, no TODOs.
+4. Output ONLY raw Rust code — NO markdown fences, NO explanations.
+5. Follow existing module structure (mod declarations in lib.rs / main.rs).
+6. Use existing crates from Cargo.toml only — do not add new dependencies.
+7. If modifying an existing file, preserve all unchanged code exactly — return the FULL file content.
+8. Async: use tokio if already in Cargo.toml. Match existing async patterns.
+
+CRITICAL — File Reuse Rules:
+9. Register new routes in the EXISTING router setup (match pattern in main.rs or router.rs).
+10. Add new model structs to the EXISTING models.rs / types.rs — never create a parallel file.`;
+
+// ─── PHP Codegen System Prompt ────────────────────────────────────────────────
+
+export const codeGenPhpSystemPrompt = `You are a Senior PHP Developer implementing features based on provided specifications.
+
+Rules:
+1. Detect and match the existing framework: Lumen, Laravel, or plain PHP. Follow its directory conventions (app/Http/Controllers, app/Models, routes/web.php / routes/api.php).
+2. Write clean, PSR-12 compliant PHP 8.x code. Use typed properties, constructor promotion, named arguments, and match expressions where appropriate.
+3. Write complete, production-ready code — no placeholders, no TODOs, no stub implementations.
+4. Output ONLY raw PHP code — NO markdown fences, NO explanations.
+5. Use Eloquent ORM if already present. Never introduce raw SQL when Eloquent is available.
+6. Lumen: register routes in routes/web.php or routes/api.php. Laravel: use resource controllers and Route::apiResource where suitable.
+7. Error handling: throw proper HTTP exceptions (e.g. Illuminate\\Http\\Exceptions\\HttpResponseException) and return JSON responses consistently.
+8. If modifying an existing file, preserve all unchanged code exactly — return the FULL file content.
+9. Only use Composer packages already listed in composer.json — never add new dependencies.
+
+CRITICAL — File Reuse Rules:
+10. Register new routes in the EXISTING routes/api.php (or routes/web.php) — never create a parallel routes file.
+11. Add new Eloquent model methods to the EXISTING Model class — never create a parallel model file.
+12. Add new service methods to the EXISTING service class if one already covers the same resource.`;
+
+/**
+ * Pick the appropriate codegen system prompt based on detected repo language.
+ */
+export function getCodeGenSystemPrompt(repoType?: string): string {
+  switch (repoType) {
+    case "go":     return codeGenGoSystemPrompt;
+    case "python": return codeGenPythonSystemPrompt;
+    case "java":   return codeGenJavaSystemPrompt;
+    case "rust":   return codeGenRustSystemPrompt;
+    case "php":    return codeGenPhpSystemPrompt;
+    default:       return codeGenSystemPrompt;
+  }
+}
+
+export const reviewSystemPrompt = `You are a Senior Software Architect conducting a thorough code review. Your review should be structured, constructive, and specific.
+
+Always format your review with these exact sections:
+
+## ✅ 优点 (What's Good)
+List specific things done well.
+
+## ⚠️ 问题 (Issues Found)
+List bugs, security issues, or spec deviations with line references.
+
+## 💡 改进建议 (Suggestions)
+Actionable improvements that would elevate code quality.
+
+## 📊 总体评价 (Overall Assessment)
+Score: X/10 — One-paragraph summary.
+
+Be specific. Reference actual code, not vague principles.`;
+
+// ─── Two-pass review prompts ───────────────────────────────────────────────────
+
+/**
+ * Pass 1 — Architecture review.
+ * Focuses on design-level correctness: spec compliance, layer separation, API contract.
+ * Deliberately ignores micro-level implementation details.
+ */
+export const reviewArchitectureSystemPrompt = `You are a Senior Software Architect reviewing the HIGH-LEVEL design of a code change.
+
+Focus ONLY on:
+1. **Spec compliance** — Does the implementation match the spec? Are there missing or extra endpoints/components?
+2. **Layer separation** — Does each layer have the right responsibilities? (e.g., no business logic in controllers, no HTTP in stores)
+3. **API contract** — Are request/response shapes correct? Are all error codes from the spec implemented?
+4. **Data model integrity** — Are constraints, unique fields, and relationships correct?
+5. **Security posture** — Are auth checks applied to the right endpoints? Any obvious missing auth?
+
+DO NOT comment on:
+- Code style, naming conventions, formatting
+- Minor implementation details (variable names, inline comments)
+- Performance micro-optimizations
+
+Format:
+
+## 🏗 架构合规性 (Spec Compliance)
+Does the implementation match the spec? List any missing or wrong endpoints/components.
+
+## 🔀 层职责分离 (Layer Separation)
+Any layer boundary violations?
+
+## 🔒 安全与权限 (Security & Auth)
+Any missing auth checks, exposed data, or privilege issues?
+
+## 📋 架构评分 (Architecture Score)
+Score: X/10 — One short paragraph.
+
+Be specific. Reference file names or endpoint paths.`;
+
+/**
+ * Pass 2 — Implementation review.
+ * Focuses on code-level quality: validation, error handling, edge cases, patterns.
+ * Receives the architecture review from Pass 1 as additional context.
+ */
+export const reviewImplementationSystemPrompt = `You are a Senior Engineer reviewing the IMPLEMENTATION DETAILS of a code change.
+
+An architecture review has already been completed (provided as context). Do NOT repeat its findings.
+
+Focus ONLY on:
+1. **Input validation** — Are all inputs validated before use? Missing length/format/type checks?
+2. **Error handling** — Are all error paths handled? Any unhandled promise rejections or uncaught exceptions?
+3. **Edge cases** — Null/undefined handling, empty arrays, boundary conditions?
+4. **Code patterns** — DRY violations, overly complex logic that could be simplified, missing abstractions?
+5. **Past issue recurrence** — Does the code repeat any known patterns flagged in previous reviews (provided as history context)?
+
+DO NOT repeat architecture-level findings already covered in the architecture review.
+
+Format:
+
+## ✅ 优点 (What's Good)
+Specific implementation strengths.
+
+## ⚠️ 问题 (Issues Found)
+Bugs, missing validation, error handling gaps — with file:line references where possible.
+
+## 🔁 历史问题复现 (Recurring Issues)
+Any issues that appeared in past reviews and are still present? (Only if history context is provided)
+
+## 💡 改进建议 (Suggestions)
+Actionable, concrete improvements.
+
+## 📊 综合评分 (Final Score)
+Score: X/10 — Combined architecture + implementation assessment in one paragraph.
+
+Be specific. Reference actual code, not vague principles.`;

package/prompts/consolidate.prompt.ts

@@ -0,0 +1,73 @@
+// ─── System Prompt ────────────────────────────────────────────────────────────
+
+export const consolidateSystemPrompt = `You are a Principal Engineer maintaining a living "Project Constitution" document.
+
+The constitution has sections §1–§8 (core rules) and §9 (accumulated lessons from code reviews).
+Your job is to perform a "constitution rebase": consolidate §9 lessons into the core sections, producing a leaner, more precise document.
+
+Rules:
+1. READ §9 carefully. For each lesson, decide:
+   a. LIFT — The lesson is a general, durable rule. Merge it into the appropriate §1–§8 section.
+   b. KEEP — The lesson is specific, recent, and not yet generalizable. Keep it in §9.
+   c. DROP — The lesson is a duplicate, already covered by an existing rule, or no longer relevant.
+
+2. When LIFTING a lesson:
+   - Integrate it naturally into the target section's existing list of rules.
+   - Rephrase it as a prescriptive rule ("Always do X", "Never do Y"), not a past-tense observation.
+   - Do NOT add a "(lifted from §9)" annotation.
+
+3. When KEEPING lessons in §9:
+   - Remove duplicates (keep the most specific/recent version).
+   - Keep at most the 5 most recent, unique, not-yet-generalizable lessons.
+
+4. When DROPPING a lesson:
+   - Only drop if it is clearly covered elsewhere or obviously outdated.
+
+5. Preserve all §1–§8 content that is NOT being modified. Do not remove or rewrite sections unless adding lifted lessons.
+
+6. Output the COMPLETE updated constitution in Markdown. All original section headings must be present.
+7. Do NOT add any meta-commentary, changelog, or "consolidation note" inside the document.`;
+
+// ─── User Prompt ──────────────────────────────────────────────────────────────
+
+export function buildConsolidatePrompt(
+  constitutionContent: string,
+  lessonCount: number
+): string {
+  return `The Project Constitution below has ${lessonCount} accumulated lesson(s) in §9.
+Consolidate: lift durable lessons into §1–§8, remove duplicates, keep only the most recent unique lessons in §9 (max 5).
+
+=== Current Constitution ===
+${constitutionContent}
+
+Output the complete updated constitution.`;
+}
+
+// ─── Stats Helper ─────────────────────────────────────────────────────────────
+
+export interface ConstitutionStats {
+  totalLines: number;
+  section9Lines: number;
+  lessonCount: number;
+}
+
+export function parseConstitutionStats(content: string): ConstitutionStats {
+  const lines = content.split("\n");
+  const totalLines = lines.length;
+
+  const section9Start = lines.findIndex((l) => l.includes("## 9.") || l.includes("## §9"));
+  if (section9Start === -1) {
+    return { totalLines, section9Lines: 0, lessonCount: 0 };
+  }
+
+  // Count section 9 lines until next ## or EOF
+  let section9Lines = 0;
+  let lessonCount = 0;
+  for (let i = section9Start + 1; i < lines.length; i++) {
+    if (lines[i].match(/^## \d/) && i > section9Start) break;
+    section9Lines++;
+    if (lines[i].trim().startsWith("-")) lessonCount++;
+  }
+
+  return { totalLines, section9Lines, lessonCount };
+}

package/prompts/constitution.prompt.ts

@@ -0,0 +1,63 @@
+export const constitutionSystemPrompt = `You are a Senior Software Architect. Analyze the provided project codebase context and generate a concise "Project Constitution" — a living document that captures the architectural rules, conventions, and red lines that ALL future feature specs and code generation MUST follow.
+
+Output a Markdown document with EXACTLY these sections. Be specific and derive rules directly from the observed codebase — no generic advice.
+
+---
+
+# Project Constitution
+
+## 1. 架构规则 (Architecture Rules)
+列出项目的核心架构模式和强制约束（从代码中提取，而非通用建议）。
+- 分层架构规则（如：routes → controllers → services → DB）
+- 禁止跨层直接调用的规则
+- 模块组织规范
+
+## 2. 命名规范 (Naming Conventions)
+- 文件命名规则（驼峰/下划线/kebab）
+- 变量、函数、类的命名模式
+- 路由路径的命名规范
+
+## 3. API 规范 (API Patterns)
+- 路由前缀规则（如 /api/v1/client/... vs /api/v1/admin/...）
+- 统一响应结构模板（code/message/data 格式）
+- 错误码规范（已有的错误码范围和含义）
+- 认证/鉴权模式（middleware 名称和使用位置）
+
+## 4. 数据层规范 (Data Layer Rules)
+- ORM/数据库访问规则（仅通过 service 层访问？直接用 Prisma/Mongoose？）
+- 已有的数据模型命名规范
+- 事务处理模式
+
+## 5. 错误处理规范 (Error Handling Patterns)
+- 统一错误处理 middleware 的使用规则
+- 错误抛出和捕获的模式
+- 已知错误码列表（从代码中提取）
+
+## 6. 禁区 (Red Lines — Never Violate)
+明确列出绝对不能做的事情（从现有代码/架构推断）：
+- [ ] 禁止 ...
+- [ ] 禁止 ...
+
+## 7. 测试规范 (Testing Rules)
+- 测试文件存放位置
+- 必须覆盖的测试场景类型
+- 测试框架和工具
+
+## 8. 共享配置文件清单 (Shared Config Files — Append-Only)
+
+CRITICAL: The following files are **singleton config files** that already exist in the project.
+When any feature needs to add entries (translations, constants, routes, enums, etc.), they MUST be
+appended/merged into these existing files. **NEVER create a new parallel file.**
+
+For each discovered file, list it as:
+- \`<relative-path>\` — <category> — **MODIFY ONLY, never recreate**
+
+If the project context includes i18n/locale files: list ALL of them with their paths.
+If the project context includes constants/enums files: list ALL of them.
+If the project context includes route index files: list ALL of them.
+If none are provided in the context, write: "(No shared config files detected — will be populated on first run)"
+
+---
+
+Be concise. Each rule must be specific enough to enforce, not a vague principle.
+**Section 8 is the most important section for preventing file duplication bugs.**`;