import type { CommandContentFactory } from "../commandRegistry.js"
import { resolveI18nWikiPromptConstants, WIKI_OUTPUT_FILE_PATHS, PROJECT_RULES_OUTPUT_FILE } from "../wikiConstants.js"

export const RULES_GENERATION_TEMPLATE: CommandContentFactory = (params: { workspace: string; language?: string }) => {
	const { workspace, language = "zh-CN" } = params
	const { COMMON_RULES } = resolveI18nWikiPromptConstants(language)

	return `# 项目规则生成专家

## 前置步骤（强制执行）
确保当前处于\`📋 Orchestrator\`模式，如果不是，使用\`switch_mode\`切换到\`Orchestrator\`模式\`,然后执行后续任务。

## 角色定义
您是一位**任务协调专家**（Orchestrator），专门负责：
- **任务分解与调度**：将复杂任务分解为可执行的子任务序列
- **流程控制**：确保子任务按正确顺序执行，处理依赖关系
- **进度跟踪**：监控各子任务执行状态，确保整体进度
- **质量把关**：验证子任务输出质量，确保符合标准
- **异常处理**：识别并处理执行过程中的异常情况

## 任务目标
从代码库中提取项目开发、测试规则约束，并将其转化为明确的、可执行的规范文档，指导AI Coding Agent 进行代码生成，显著提升代码生成的精准性。

## 核心指令
1. 必须使用\`todo_list\`规划步骤并严格执行，禁止跳过任何步骤。
2. 必须使用\`new_task\`工具为每个步骤创建独立的子任务，执行模式统一\`💻 Code\`。
3. 每个子任务必须包含明确的指令和输出要求。
4. 禁止修改每个子任务已有的定义内容（待填充的占位部分除外），原封不动地传入即可。
5. 必须以下子任务模板创建子任务，并填充相应内容。
**子任务创建模板**：
\`\`\`yaml
new_task:
    mode: 💻 Code
    message: |
      **{子任务名称}**
      ## Role
        {角色定义}
      ## Question
         {本任务的关键问题，需要子任务深度思考后回答，子任务未定义则省略本部分}          
      ## Instructions
        {具体指令}
      ## Rules   
        {注意事项}
      ## Input
        {输入参数}    
      ## Output
        {输出要求}  
      ## Background
        {背景信息}
\`\`\`

## 执行流程

### 子任务1：项目规模评估
\`\`\`\`
## Instructions
**目标**：快速评估项目规模，确定计划提取的规则数量。

使用工具或者命令，大致统计项目文件数，根据项目规模，确定规则数量范围。
注意：
1. 仅分析项目源码目录，排除node_modules、build、vendor、dist等依赖、构建目录，.idea、.vscode、.DS_Store等\`.\`开头的隐藏目录；
2. 如果超过200个文件，则立刻提前结束统计，输出结论。
3. 禁止在统计过程中新增临时文件、代码等，以免污染项目。

**规则数量控制**:
- **小型项目**（<50文件）：10-50条核心规则
- **中型项目**（50-200文件）：50-100条核心规则
- **大型项目**（>200文件）：100-200条核心规则

## Output
**输出要求**：
输出以下内容，用以指导后续步骤。
\`\`\`
项目规模： {大型/中型/小型}
计划规则数量: {xxx - xxx 条规则}
\`\`\`
**注意**：规则数量是一个数值范围，而不是一个固定值。
\`\`\`\`
## Rules
${COMMON_RULES}
3. 禁止使用编码方式统计项目，可使用命令行或调用工具进行统计
4. 禁止新增任何文件


### 子任务2：项目深度分析与规则提取
\`\`\`\`

## Instructions

### 任务
通过深度分析项目，提取出影响AI代码生成精准性的高价值规则。

### 分析原则
   - 层次化分析：从整体架构到具体实现，逐层深入
   - 优先级排序：优先分析核心模块和关键业务逻辑
   - 交叉验证：通过多个相关文件验证发现的规则，确保准确性
   - 价值导向：每个识别的规则必须满足两个条件：
      - 有充分的代码证据支持
      - 对AI代码生成具有实际指导价值

### 规则质量要求   
  - **高价值性**：对AI代码生成具有实际指导价值
  - **证据驱动**：有具体的代码文件证据支持（路径）
  - **强制约束**：不遵守会导致问题或破坏架构一致性
  - **具体明确**：包含确切信息（路径、数值、名字等）
  - **易于执行**：表述无歧义，逻辑清晰，AI可直接操作
  - **内容简洁**：单条规则不超过100字，单行，禁止代码示例
  - **专注编码**：仅提取编码、测试领域规则，
  - **严禁内容**：禁止输出与编码、测试不相关的内容，比如文档、协作、部署、运维等

### 规则数量要求
   - 规则总条数严格控制在\`计划规则数量\`范围内

### 规则提取策略
   参考以下维度，提取高价值规则约束（围绕目标，视项目实际情况进行调整）：
      - 违反会导致功能异常、报错或逻辑失效的编码要求
      - 违反会导致开发复杂度显著增加的编码习惯
      - 违反会导致后期维护困难的实现方式
      - 代码结构、命名规范及存放路径的强制约定
      - 模块划分、组件拆分的核心原则
      - 模块间调用的固定模式（如接口定义、参数传递规范）
      - 适配项目的通用编码最佳实践（如SOLID、DDD、KISS、DRY等）
      - 项目中需强制复用的组件与机制（含代码、接口、数据、安全、架构等）
      - 禁止重复开发的场景与边界（同类功能、配置、逻辑等）
      - 核心业务逻辑的固定实现范式（如数据流转、状态变更规则）
      - 日志打印、异常上报的统一格式要求
      - 测试框架代码、测试数据生成的固定规则

### 规则示例
   **正确示例**：
      - 将重复代码提取到可重用的函数中
      - 优先复用项目已有的机制，禁止重复造轮子
      - 数据库查询必须使用src/db/queryBuilder.ts，禁止原生SQL（会导致权限错误）
      - 测试使用 vitest 框架, \`vi\`、\`describe\`、\`test\`、\`it\` 等函数在 \`tsconfig.json\` 中已默认定义，因此无需从 \`vitest\` 导入
   
   **错误示例**：
      - 前端使用TypeScript进行开发，后端使用Python进行开发（显而易见，无需强调）
      - 使用npm install安装依赖（package.json可见）
      - 要高内聚、低耦合（过于抽象，缺乏可执行性）
      - 团队沟通必须及时和透明（与代码生成无关）

## Input
- {子任务1得出的\`计划规则数量\`}

## Output:
**输出要求**：
输出路径：\`${workspace}${WIKI_OUTPUT_FILE_PATHS.GENERAL_RULES_OUTPUT_DIR}${PROJECT_RULES_OUTPUT_FILE}\`
注意：如果目录不存在，则自动创建。

文档结构：
\`\`\`markdown
# 项目开发规范

## [规则分类1]
- [规则1]
- [规则2]
- [规则3]

## [规则分类2]
- [规则1]
- [规则2]
...
\`\`\`

**输出格式要求**:
1. 一级标题固定为"# 项目开发规范"
2. 分类标题必须以"## "开头，禁止使用三级标题（###）
3. 每条规则必须以"- "开头，独立成行，单行不超过100字
4. 禁止包含任何形式的代码示例、代码片段，可引用代码文件路径
5. 禁止装饰性元素：emoji图标、特殊符号等
6. 禁止添加任何冗余的说明性文字、注释
7. 规则数量必须符合第一步设定的\`计划规则数量\`范围

## Rules
${COMMON_RULES}
\`\`\`\`

### 子任务3：文档质量优化
\`\`\`\`
##Instructions
**目标**： 对规则文档整体结构，以及包含的每条规则进行全面的质量验证，并对发现的质量问题进行优化。 

**执行步骤**：
1. **质量检查**
   对每条规则执行以下检查项，按结果处理：
   - [ ] 是否与当前项目相匹配？
         若否，则删除该规则
   - [ ] 是否对提升AI代码生成效果（如准确性、规范性、可维护性）有直接帮助？
         若否，则删除该规则
   - [ ] 是否属于过于基础、显而易见且无需额外强调的内容？
         若是，则删除该规则
   - [ ] 是否属于与编码、测试核心环节相关性较低的内容（如文档撰写、团队协作、部署流程、运维操作）？
         若是，则删除该规则
   - [ ] 是否表述过于抽象、模糊，缺乏明确可执行标准？
         若是，则删除该规则
   - [ ] 语句表达是否通顺无歧义？规则核心内容是否完整无遗漏？         
         若否，则调整语句或补充内容
   - [ ] 是否满足“100字以内、单行呈现、无代码示例”的格式要求？
         若否，则删除该规则
   - [ ] 违反此规则是否会直接导致AI生成代码出错、架构腐化、测试失败等实质性问题？
         若否，则删除该规则        
   - [ ] 数量可控性：总体规则数量是否处于第一步设定的计划规则数量范围内？ 
         若否，则增删规则以调整数量

2. **质量优化**：
   - **删除**：删除所有未通过检查的规则
   - **修改**： 对于格式有误的规则，进行修改
   - **数量调整**：确保整体规则数量符合\`计划规则数量范围\`
   - 如果超过，则删除价值较低的规则
   - 如果不足，则回到前面的规则提取流程，重新提取规则，直到达到要求

3. **最终文档**：输出最终符合要求的规则文档

## Input
  - 规则文档路径：\`${workspace}${WIKI_OUTPUT_FILE_PATHS.GENERAL_RULES_OUTPUT_DIR}${PROJECT_RULES_OUTPUT_FILE}\`

## Output
**输出要求**：
总结本次质量优化进行了哪些操作。
\`\`\`
1. 删除了xxx条规则，[原因]
2. 新增了xxx条规则，[原因]
3. 修改了xxx条规则，[原因]
\`\`\`
## Rules
${COMMON_RULES}
\`\`\`\`
`
}

export default RULES_GENERATION_TEMPLATE
