# -*- coding: utf-8 -*-
"""内置替换映射表模块。

该模块定义了Jarvis系统内置的默认替换映射表。
格式: {"标记名": {"template": "替换模板", "description": "描述信息"}}
"""

from jarvis.jarvis_utils.tag import ct
from jarvis.jarvis_utils.tag import ot

BUILTIN_REPLACE_MAP = {
    "Web": {
        "append": True,
        "template": f"""
请使用search_web工具进行网页搜索，必须严格遵守以下工具调用格式：

{ot("TOOL_CALL")}
want: 想要从执行结果中获取到的信息
name: search_web
arguments:
    query: "xxx技术的最新发展是什么？"
{ct("TOOL_CALL")}

可以使用的提问格式包括：
1. xxx技术的最新发展是什么？
2. xxx框架的官方文档在哪里？
3. xxx库的GitHub仓库地址是什么？
4. xxx问题的解决方案有哪些？
5. xxx概念的详细解释是什么？
""",
        "description": "网页搜索",
    },
    "FindRelatedFiles": {
        "append": False,
        "template": """
请使用工具在当前目录下查找与以下功能相关的文件：
""",
    },
    "Dev": {
        "append": False,
        "template": """
请调用create_code_agent开发以下需求：
""",
    },
    "Fix": {
        "append": False,
        "template": """
请修复以下问题：
""",
    },
    "Check": {
        "append": True,
        "template": """
请使用静态检查工具检查当前代码，必须严格遵守工具调用格式。

检查要求：
1. 如果发现致命错误，必须立即修复
2. 如果发现警告或风格问题，应询问用户是否需要修复
3. 检查完成后应报告结果
4. 确保使用项目对应的静态检查工具
""",
        "description": "执行静态代码检查",
    },
    "sdd/1.spec": {
        "append": False,
        "template": """
请执行SDD规范阶段（Specification）- 需求澄清与规范编写：

📝 规范阶段详细执行步骤：

第一步：需求澄清
1. 从模糊想法出发，通过与用户/团队的迭代对话澄清需求
2. 问自己："这个功能要解决什么问题？"而不是"这个功能如何实现？"
3. 从用户角度思考功能需求，而不是从技术角度
4. 明确功能的边界，什么在范围内，什么在范围外
5. 使用用户故事格式（作为...我需要...以便...）描述需求

第二步：识别边界和异常
1. 考虑各种可能的输入场景（正常、边界、异常）
2. 识别边界情况：空值、最大值、最小值、特殊字符等
3. 识别异常情况：错误输入、网络故障、资源不足等
4. 为每种情况定义明确的处理方式

第三步：编写Spec文档
1. Spec文件必须放置在项目的 `.jarvis/spec/` 目录
2. Spec文件命名规范：
   - 必须：使用小写字母
   - 必须：使用下划线 `_` 分隔单词
   - 必须：使用 `.md` 后缀
   - 禁止：使用空格、连字符 `-` 或大写字母
   - ✅ 正确示例：`user_auth_spec.md`, `data_processing_spec.md`
   - ❌ 错误示例：`UserAuthSpec.md`, `user-auth-spec.md`

第四步：Spec必须包含的内容
1. 功能概述：
   - 简要说明功能的目标和价值
   - 明确功能的使用场景
   - 说明功能要解决什么问题

2. 接口定义：
   - 函数/方法的签名（参数类型、返回值类型）
   - API端点的定义（路径、方法、请求/响应格式）
   - 类的公共接口（属性和方法）

3. 输入输出说明：
   - 所有参数的详细说明（类型、范围、约束）
   - 返回值的详细说明（类型、含义）
   - 可能抛出的异常或错误码

4. 功能行为：
   - 正常情况的处理逻辑（提供具体示例）
   - 边界条件的处理方式（空值、极值等）
   - 异常情况的处理策略（错误处理、降级方案）
   - 性能要求（如适用：响应时间、吞吐量等）

5. 验收标准：
   - 明确的通过条件（可量化的标准）
   - 可验证的测试场景（正常、边界、异常）
   - 具体的验证方法（测试用例、检查清单）

第五步：Spec编写规范
1. 使用清晰、简洁的语言
2. 避免模糊的表述（如"尽可能快"、"合理的"），使用具体的数值和范围
3. 提供具体的示例来说明复杂的需求
4. 使用结构化的格式（列表、表格、代码块）
5. 为每个验收标准编号，便于追踪
6. 区分"必须"和"可选"的需求
7. 考虑向后兼容性和可扩展性

第六步：Spec评审和确认
1. 检查Spec的完整性：是否包含所有必需内容
2. 检查Spec的清晰性：是否容易理解和实现
3. 检查Spec的可验证性：验收标准是否明确
4. 与用户/团队确认Spec内容
5. Spec必须经过评审和确认后才能进入下一阶段

执行检查清单（必须全部完成）：
- [ ] 已通过对话澄清需求，明确功能边界
- [ ] 已识别所有边界情况和异常情况
- [ ] 已创建Spec文件在 `.jarvis/spec/` 目录
- [ ] Spec文件命名符合规范（小写字母、下划线分隔、.md后缀）
- [ ] Spec包含功能概述和目标
- [ ] Spec包含清晰的接口定义
- [ ] Spec包含完整的输入输出说明
- [ ] Spec包含功能行为（正常/边界/异常情况）
- [ ] Spec包含明确的验收标准
- [ ] Spec使用结构化格式，包含具体示例
- [ ] Spec已经过评审和确认

重要原则：
- 禁止：在没有Spec的情况下开始实现功能
- 必须：Spec应该清晰、具体、可验证
- 必须：遇到需求不明确时，先澄清再编写Spec
- 必须：Spec与代码不一致时，优先更新Spec
""",
        "description": "SDD规范阶段：编写功能规范",
    },
    "sdd/2.plan": {
        "append": False,
        "template": """
请执行SDD规划阶段（Planning）- 技术决策与实现规划：

🗺️ 规划阶段详细执行步骤：

第一步：规范一致性验证
1. 仔细阅读Spec文档，理解所有需求
2. 分析规范中的歧义：找出表述不清、可能产生多种理解的地方
3. 分析规范中的矛盾：找出相互冲突的需求或约束
4. 分析规范中的缺口：找出缺失的关键信息（如错误处理、性能要求等）
5. 如果发现歧义、矛盾或缺口，必须先更新Spec再继续规划

第二步：架构设计
1. 制定整体架构设计方案：
   - 系统分层结构（表现层、业务层、数据层等）
   - 模块划分和职责定义
   - 模块之间的依赖关系
   - 数据流向和交互方式
2. 设计模块接口：
   - 定义模块的公共接口
   - 明确模块间的通信方式
   - 设计数据模型和数据结构

第三步：技术栈选择
1. 为每个技术选择提供明确的理由：
   - 为什么选择这个技术/框架/库？
   - 有哪些替代方案？为什么没有选择？
   - 这个选择有什么优缺点？
   - 是否符合项目约束（性能、安全、兼容性等）？
2. 记录技术决策文档，包括：
   - 决策背景和问题描述
   - 考虑的备选方案
   - 选择的方案及理由
   - 风险评估和缓解措施

第四步：依赖关系分析
1. 识别所有外部依赖：
   - 第三方库和框架
   - 系统服务和API
   - 数据库和存储
   - 网络和基础设施
2. 分析依赖关系：
   - 依赖的版本要求
   - 依赖之间的兼容性
   - 依赖的许可证要求
   - 依赖的维护状态

第五步：性能和安全规划
1. 性能要求分析：
   - 响应时间要求（如：API响应<100ms）
   - 吞吐量要求（如：支持1000 QPS）
   - 资源使用限制（内存、CPU、存储）
   - 并发处理能力
2. 安全要求分析：
   - 认证和授权机制
   - 数据加密要求
   - 输入验证和防护
   - 安全审计和日志

第六步：实现路径规划
1. 确定实现顺序：
   - 基础功能优先
   - 依赖关系优先
   - 风险高的功能优先
2. 识别关键里程碑：
   - 每个里程碑的交付物
   - 里程碑之间的依赖关系
   - 里程碑的验收标准

第七步：风险评估和缓解
1. 识别潜在风险：
   - 技术风险（新技术、复杂实现）
   - 时间风险（工期紧张）
   - 资源风险（人力、硬件）
   - 依赖风险（第三方服务）
2. 制定风险缓解措施：
   - 备选方案
   - 降级策略
   - 监控和告警

执行检查清单（必须全部完成）：
- [ ] 已验证Spec的完整性和一致性，无歧义、矛盾或缺口
- [ ] 已制定架构设计方案，包括模块划分和依赖关系
- [ ] 已选择技术栈，每项选择都有明确的理由记录
- [ ] 已分析所有依赖关系，确认兼容性和版本要求
- [ ] 已明确性能要求和实现方案
- [ ] 已明确安全要求和实现方案
- [ ] 已规划实现路径和关键里程碑
- [ ] 已识别风险并制定缓解措施
- [ ] 规划文档已记录所有技术决策和理由

重要原则：
- 必须：所有技术决策都要有明确的理由和记录
- 必须：规划要与Spec保持一致，不得偏离
- 必须：发现Spec问题时要先更新Spec再继续规划
- 必须：规划要考虑可维护性、可扩展性和可测试性
- 禁止：在没有完成规划的情况下进入任务分解阶段
""",
        "description": "SDD规划阶段：技术决策与实现规划",
    },
    "sdd/3.task": {
        "append": False,
        "template": """
请执行SDD任务阶段（Tasks）- 任务分解与执行清单：

📋 任务阶段详细执行步骤：

第一步：任务分解
1. 基于Spec和规划，将整体功能分解为可执行的任务
2. 任务粒度要求：
   - 每个任务应该是独立的、可测试的单元
   - 任务大小适中（建议1-3天完成）
   - 任务边界清晰，职责单一
3. 任务分类：
   - 数据模型任务：将域名概念转化为数据模型
   - API接口任务：将用户故事转化为API接口定义
   - 业务逻辑任务：实现核心业务功能
   - 测试任务：将验收场景转化为测试用例
   - 文档任务：编写使用文档和API文档

第二步：数据模型设计
1. 识别所有实体和概念：
   - 从Spec中提取领域概念
   - 定义实体的属性和关系
2. 设计数据模型：
   - 数据库表结构（如适用）
   - 数据类/结构体定义
   - 数据验证规则
   - 数据迁移方案（如适用）

第三步：API接口设计
1. 将用户故事转化为API接口：
   - 定义API端点（路径、方法）
   - 定义请求格式（参数、请求体）
   - 定义响应格式（成功响应、错误响应）
   - 定义状态码和错误码
2. 编写API文档：
   - 接口说明
   - 参数说明
   - 响应示例
   - 错误处理说明

第四步：测试用例设计
1. 将验收场景转化为测试用例：
   - 正常场景测试用例
   - 边界条件测试用例
   - 异常场景测试用例
2. 测试用例格式：
   - 测试名称和描述
   - 前置条件
   - 测试步骤
   - 预期结果
   - 测试数据

第五步：任务依赖分析
1. 识别任务之间的依赖关系：
   - 前置依赖：哪些任务必须先完成
   - 后置依赖：哪些任务依赖当前任务
   - 并行任务：可以同时执行的任务
2. 构建任务依赖图：
   - 明确任务的执行顺序
   - 识别关键路径
   - 优化任务调度

第六步：任务定义和验收标准
1. 为每个任务定义：
   - 任务名称和描述
   - 任务输入（依赖的任务输出、文档、数据）
   - 任务输出（代码、文档、测试用例）
   - 验收标准（如何验证任务完成）
   - 估算工作量（时间、复杂度）
2. 验收标准要求：
   - 具体、可测量
   - 可验证（通过测试或检查）
   - 与Spec的验收标准对应

第七步：任务优先级排序
1. 根据依赖关系确定执行顺序
2. 根据风险和价值确定优先级：
   - 高风险任务优先
   - 核心功能优先
   - 阻塞其他任务的任务优先
3. 制定任务执行计划：
   - 任务执行顺序
   - 里程碑节点
   - 并行执行计划

执行检查清单（必须全部完成）：
- [ ] 已将功能分解为可执行的任务清单
- [ ] 已设计数据模型，包括实体、属性和关系
- [ ] 已设计API接口，包括端点、请求/响应格式
- [ ] 已设计测试用例，覆盖正常、边界、异常场景
- [ ] 已明确所有任务之间的依赖关系
- [ ] 已为每个任务定义输入、输出和验收标准
- [ ] 已确定任务执行顺序和优先级
- [ ] 任务清单已确认，可以开始实现

重要原则：
- 必须：任务要具体、可执行、可验证
- 必须：每个任务都要有明确的验收标准
- 必须：任务依赖关系要清晰，避免循环依赖
- 必须：任务粒度要适中，既不过大也不过小
- 禁止：在没有完成任务分解的情况下开始实现
""",
        "description": "SDD任务阶段：任务分解与执行清单",
    },
    "sdd/4.code": {
        "append": False,
        "template": """
请执行SDD实现阶段（Code Generation）- 基于规范编码：

⚡ 实现阶段详细执行步骤：

第一步：准备工作
1. 确认Spec文档已完整且经过评审
2. 确认规划文档已明确技术方案
3. 确认任务清单已分解完成
4. 准备开发环境：
   - 安装必要的工具和依赖
   - 配置开发环境
   - 设置代码规范和检查工具

第二步：按任务顺序实现
1. 严格按照任务清单的顺序执行
2. 对于每个任务：
   - 仔细阅读任务描述和验收标准
   - 参考Spec中的相关部分
   - 参考规划中的技术方案
   - 实现代码功能
   - 同步编写测试用例

第三步：代码实现要求
1. 严格按照Spec进行实现：
   - 接口定义必须与Spec一致
   - 功能行为必须符合Spec描述
   - 输入输出必须符合Spec要求
   - 异常处理必须符合Spec定义
2. 不得偏离Spec定义：
   - 禁止实现超出Spec范围的功能（除非先更新Spec）
   - 禁止简化或省略Spec要求的功能
   - 禁止改变Spec定义的接口签名
3. 代码质量要求：
   - 遵循项目代码规范
   - 编写清晰的注释和文档
   - 使用有意义的变量和函数名
   - 保持代码结构清晰

第四步：测试驱动开发
1. 同步编写测试用例：
   - 为每个功能编写单元测试
   - 测试正常场景、边界场景、异常场景
   - 测试覆盖率要达到要求（建议>80%）
2. 测试用例要求：
   - 测试用例要对应Spec中的验收标准
   - 测试用例要可重复执行
   - 测试用例要有清晰的断言
3. 运行测试验证：
   - 实现后立即运行测试
   - 确保所有测试通过
   - 修复测试失败的问题

第五步：处理Spec不明确的情况
1. 如果实现过程中发现Spec不明确：
   - 立即停止实现
   - 分析不明确的地方
   - 更新Spec文档，澄清或补充信息
   - 重新评审更新后的Spec
   - 确认Spec完整后继续实现
2. 如果发现Spec有错误：
   - 立即停止实现
   - 记录错误和修正方案
   - 更新Spec文档
   - 重新评审更新后的Spec
   - 确认Spec正确后继续实现

第六步：探索性验证
1. 可进行探索性生成验证规范的实用性：
   - 快速实现原型验证想法
   - 验证技术方案的可行性
   - 发现潜在的问题和风险
2. 根据探索结果：
   - 如果发现规范问题，更新Spec
   - 如果发现技术问题，更新规划
   - 如果发现任务问题，更新任务清单

第七步：代码审查和自检
1. 完成实现后进行自检：
   - 检查代码是否符合Spec
   - 检查代码是否符合规划
   - 检查测试是否通过
   - 检查代码质量
2. 准备代码审查：
   - 确保代码可以编译/运行
   - 确保测试全部通过
   - 准备审查材料

执行检查清单（必须全部完成）：
- [ ] 已确认Spec、规划和任务清单完整
- [ ] 已按任务顺序完成所有实现
- [ ] 代码实现与Spec完全一致
- [ ] 已同步编写测试用例，覆盖所有验收标准
- [ ] 所有测试用例已通过
- [ ] 遇到Spec不明确时已更新Spec
- [ ] 代码符合项目规范和最佳实践
- [ ] 代码已通过自检，准备审查

重要原则：
- 禁止：在没有Spec的情况下开始实现
- 禁止：实现超出Spec范围的功能（除非更新Spec）
- 必须：严格按照Spec进行实现，不得偏离
- 必须：遇到Spec不明确时先更新Spec再继续
- 必须：同步编写测试用例验证验收标准
- 必须：代码实现必须与Spec保持一致
""",
        "description": "SDD实现阶段：基于规范编码",
    },
    "sdd/5.verify": {
        "append": False,
        "template": """
请执行SDD验证阶段（Verification）- 验证符合规范：

✅ 验证阶段详细执行步骤：

第一步：功能验证
1. 对照Spec验证实现的正确性：
   - 逐项检查Spec中的功能要求
   - 验证功能是否完整实现
   - 验证功能行为是否符合Spec描述
2. 验证接口定义：
   - 检查函数/方法签名是否与Spec一致
   - 检查API端点是否与Spec一致
   - 检查参数和返回值类型是否匹配
3. 验证输入输出：
   - 检查参数验证是否符合Spec要求
   - 检查返回值格式是否符合Spec定义
   - 检查异常抛出是否符合Spec定义

第二步：验收标准验证
1. 确保所有验收标准都已满足：
   - 逐项检查Spec中的验收标准
   - 运行对应的测试用例
   - 验证测试结果是否符合预期
2. 验证正常场景：
   - 使用正常输入测试功能
   - 验证输出是否符合预期
   - 验证功能逻辑是否正确
3. 验证边界条件：
   - 测试空值、最大值、最小值等边界情况
   - 验证边界处理是否符合Spec要求
   - 验证边界情况的错误处理
4. 验证异常情况：
   - 测试各种异常输入
   - 验证异常处理是否符合Spec要求
   - 验证错误信息和错误码是否正确

第三步：测试执行
1. 运行所有测试用例：
   - 单元测试
   - 集成测试
   - 端到端测试（如适用）
2. 检查测试结果：
   - 确保所有测试通过
   - 分析失败的测试用例
   - 修复测试发现的问题
3. 测试覆盖率检查：
   - 检查代码覆盖率是否达到要求
   - 识别未覆盖的代码路径
   - 补充缺失的测试用例

第四步：代码审查
1. 代码质量审查：
   - 检查代码是否符合项目规范
   - 检查代码结构是否清晰
   - 检查代码注释是否完整
   - 检查变量和函数命名是否合理
2. 代码一致性审查：
   - 检查代码实现与Spec的一致性
   - 检查代码实现与规划的一致性
   - 检查代码实现与任务描述的一致性
3. 代码安全性审查：
   - 检查输入验证是否充分
   - 检查错误处理是否完善
   - 检查潜在的安全漏洞

第五步：文档检查
1. 检查代码文档：
   - 函数/方法注释是否完整
   - 参数和返回值说明是否清晰
   - 异常说明是否完整
2. 检查API文档：
   - API文档是否与实现一致
   - API示例是否正确
   - 错误处理说明是否完整
3. 检查用户文档：
   - 使用说明是否清晰
   - 示例是否可运行
   - 常见问题是否覆盖

第六步：性能验证（如适用）
1. 如果Spec中有性能要求：
   - 运行性能测试
   - 验证响应时间是否符合要求
   - 验证吞吐量是否符合要求
   - 验证资源使用是否符合要求
2. 性能优化：
   - 如果性能不达标，进行优化
   - 更新Spec记录实际性能数据

第七步：问题处理和修正
1. 如果验证发现问题：
   - 记录所有发现的问题
   - 分析问题的根本原因
   - 确定问题所属的阶段（实现/任务/规划/Spec）
2. 回到相应阶段进行修正：
   - 如果是实现问题：回到实现阶段修正代码
   - 如果是任务问题：更新任务清单，重新实现
   - 如果是规划问题：更新规划文档，调整实现
   - 如果是Spec问题：更新Spec文档，重新评审
3. 修正后重新验证：
   - 修正问题后重新执行验证
   - 确保所有问题都已解决
   - 确保所有验收标准都已满足

执行检查清单（必须全部完成）：
- [ ] 已对照Spec验证所有功能要求
- [ ] 已验证所有接口定义与Spec一致
- [ ] 已验证所有输入输出符合Spec要求
- [ ] 已验证所有验收标准都已满足
- [ ] 已运行所有测试用例，全部通过
- [ ] 已检查代码覆盖率，达到要求
- [ ] 已完成代码审查，无质量问题
- [ ] 已检查文档，与实现保持一致
- [ ] 已进行性能验证（如适用），符合要求
- [ ] 已处理所有发现的问题
- [ ] 所有验证活动已完成，可以进入下一阶段

重要原则：
- 必须：所有验收标准都要验证通过
- 必须：代码实现与Spec保持一致
- 必须：文档与实现保持同步
- 必须：测试用例要覆盖所有验收标准
- 必须：验证失败时要回到相应阶段修正
- 禁止：跳过任何验证步骤
- 禁止：在验证未通过的情况下进入下一阶段
""",
        "description": "SDD验证阶段：验证符合规范",
    },
    "sdd/6.feedback": {
        "append": False,
        "template": """
请执行SDD反馈循环阶段（Feedback Loop）- 持续迭代优化：

🔄 反馈循环阶段详细执行步骤：

第一步：收集反馈信息
1. 收集生产指标：
   - 性能指标（响应时间、吞吐量、资源使用）
   - 错误率和异常情况
   - 用户使用情况和反馈
   - 系统监控数据
2. 收集事故信息：
   - 生产环境中的故障和问题
   - 安全漏洞和安全隐患
   - 数据丢失或损坏事件
   - 服务中断事件
3. 收集用户反馈：
   - 功能使用情况
   - 用户体验问题
   - 功能改进建议
   - 新需求

第二步：分析反馈信息
1. 分析性能问题：
   - 识别性能瓶颈
   - 分析性能下降的原因
   - 评估性能优化的必要性
2. 分析安全问题：
   - 识别安全漏洞
   - 分析安全风险
   - 评估安全修复的优先级
3. 分析功能问题：
   - 识别功能缺陷
   - 分析用户需求变化
   - 评估功能改进的价值

第三步：更新规范
1. 将生产指标转化为规范约束：
   - 更新性能要求（如：响应时间要求更严格）
   - 更新资源使用限制
   - 更新并发处理能力要求
2. 将事故信息转化为规范约束：
   - 添加新的错误处理要求
   - 添加新的安全要求
   - 添加新的容错和恢复要求
3. 将用户反馈转化为规范更新：
   - 更新功能描述
   - 添加新的功能需求
   - 更新验收标准

第四步：更新实现
1. 根据更新的规范调整实现：
   - 优化性能瓶颈
   - 修复安全漏洞
   - 改进功能实现
2. 实现新的约束条件：
   - 添加新的错误处理逻辑
   - 添加新的安全检查
   - 实现新的功能需求
3. 保持实现与规范的一致性：
   - 确保代码实现符合更新的规范
   - 确保接口定义与规范一致

第五步：更新测试和文档
1. 更新测试用例：
   - 添加新的测试场景
   - 更新性能测试用例
   - 更新安全测试用例
   - 更新验收测试用例
2. 更新文档：
   - 更新API文档
   - 更新用户文档
   - 更新部署文档
   - 更新运维文档
3. 验证更新：
   - 运行更新的测试用例
   - 确保所有测试通过
   - 验证文档的准确性

第六步：持续监控和迭代
1. 建立监控机制：
   - 设置性能监控指标
   - 设置错误告警
   - 设置安全监控
2. 定期回顾：
   - 定期回顾生产指标
   - 定期分析用户反馈
   - 定期评估规范的有效性
3. 持续优化：
   - 根据监控数据持续优化
   - 根据用户反馈持续改进
   - 形成规范、实现与现实的持续迭代

执行检查清单（必须全部完成）：
- [ ] 已收集生产指标和事故信息
- [ ] 已分析反馈信息，识别问题和改进点
- [ ] 已更新规范，反映新的约束和要求
- [ ] 已更新实现，符合更新的规范
- [ ] 已更新测试用例，覆盖新的场景
- [ ] 已更新文档，保持与实现同步
- [ ] 已建立监控机制，持续跟踪
- [ ] 已形成持续迭代的流程

重要原则：
- 必须：根据生产反馈更新规范
- 必须：将运维问题转化为规范约束
- 必须：保持规范、实现与现实的同步
- 必须：持续监控和优化
- 必须：形成规范、实现、运维的闭环
- 禁止：忽视生产环境中的问题
- 禁止：规范与实际脱节
""",
        "description": "SDD反馈循环阶段：持续迭代优化",
    },
}
