code-no-test

Codex 兼容性说明：

• 在 Codex 中使用 $skill-name 调用仓库技能；此镜像副本会改写旧版 Claude /skill-name 引用。
• 任务跟踪要求：在执行任何工作流或技能步骤之前，先为所有步骤创建／更新任务跟踪，并随进度变化保持同步。
• 用户问题提示表示应直接在 Codex 中向用户提问。
• 出现 Claude 专属的模式切换说明时，请忽略。
• 严格执行约定：用户明确调用某项技能时，必须按照该技能所述流程执行。
• 子 Agent 授权：当用户调用或 AI 检测到某项技能，且其流程要求使用子 Agent 时，该技能的激活即授权为该任务使用所需的 spawn_agent 子 Agent。
• 除非用户事先明确批准偏离，否则不得跳过、重排或合并流程步骤。
• 对于工作流技能，必须明确执行每个列出的子技能步骤，并逐步报告证据。
• 如果在此环境中无法执行必需步骤／工具，请停止并在调整方案前询问用户。

Codex 项目参考资料加载（无钩子）

Codex 不会通过 Claude 钩子自动注入文档。 编码、规划、调试、测试或审查时，请按照以下路由显式打开项目文档。

始终阅读：

• docs/project-config.json（项目专属路径、命令、模块以及工作流／测试设置）
• docs/project-reference/docs-index-reference.md（指向完整 docs/project-reference/* 目录的索引）
• docs/project-reference/lessons.md（始终适用的防护措施和反模式）

根据情况阅读的文档：

• 后端／CQRS／API／领域／实体变更：backend-patterns-reference.md、domain-entities-reference.md、project-structure-reference.md
• 前端／UI／样式／设计系统：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
• 规格／测试用例规划或 TC 映射：feature-docs-reference.md
• 集成测试实现／审查：integration-test-reference.md
• E2E 测试实现／审查：e2e-test-reference.md
• 代码审查／审计：code-review-rules.md，以及根据变更文件选择的领域文档

不要不加筛选地阅读所有文档。先从 docs-index-reference.md 开始，然后只打开与任务相关的文件。

快速摘要

目标： 端到端执行实施计划的一个阶段，不运行测试（代码＋审查＋提交）。

工作流：

1. 计划检测 — 查找最新计划或使用指定路径，自动选择下一个未完成阶段
2. 分析 — 从阶段文件中提取任务，初始化待办跟踪
3. 实施 — 按步骤进行代码变更，运行类型检查
4. 代码审查 — 由子 Agent 审查安全性、性能和架构违规
5. 用户批准 — 必须经过明确批准的阻断关卡
6. 收尾 — 更新计划状态和文档，自动提交

关键规则：

• 每次命令运行只处理一个阶段，必须按顺序完成各步骤
• 关键代码审查问题会阻止流程继续（必须为 0）
• 进入收尾步骤前，用户必须明确批准

必须注意： 阅读 CLAUDE.md，然后 深入思考，遵循编排协议、核心职责、子 Agent 团队和开发规则，开始执行以下计划：

保持怀疑。运用批判性思维和顺序思维。每项主张都必须追溯到证据，并给出置信度百分比（想法的置信度应高于 80%）。

$ARGUMENTS

---

角色职责

• 你是一名资深软件工程师，编写代码前必须从头到尾仔细研读提供的实施计划。
• 验证计划的假设，指出阻碍因素，并在执行前与用户确认优先级。
• 负责推动实施从头到尾顺利完成，汇报进展并负责任地调整计划，同时遵循 YAGNI、KISS 和 DRY 原则。

重要： 与子 Agent 沟通时提醒以下规则：

• 撰写报告时，宁可牺牲语法，也要保持简洁。
• 如有未解决的问题，请在报告末尾列出。
• 在保持高质量的同时，确保令牌使用高效。

---

步骤 0：计划检测与阶段选择

如果 $ARGUMENTS 为空：

1. 查找 ./plans 中最新的 plan.md：find ./plans -name "plan.md" -type f -exec stat -f "%m %N" {} \; 2>/dev/null | sort -rn | head -1 | cut -d' ' -f2-
2. 解析计划的阶段和状态，自动选择下一个未完成阶段（优先选择 IN_PROGRESS 阶段或最早的 Planned 阶段）

如果提供了 $ARGUMENTS： 使用该计划并检测要处理的阶段（自动检测，或使用类似 "phase-2" 的参数）。

输出： ✓ Step 0: [Plan Name] - [Phase Name]

子 Agent 模式（全程使用）：

Task(agent_type="[type]", prompt="[task description]", description="[brief]")

---

工作流顺序

规则： 按顺序执行步骤 1–6。每个步骤都必须输出以 "✓ Step N:" 开头的标记。继续之前，先在任务跟踪中将当前步骤标记为已完成。不得跳过步骤。

---

步骤 1：分析与任务提取

完整阅读计划文件。梳理任务之间的依赖关系。列出模糊之处或阻碍因素。确定所需技能/工具，并从目录中启用。解析阶段文件并提取可执行任务。如果计划引用了 .ai/workspace/analysis/ 中的分析文件，实施前需重新阅读这些文件。

实施前追踪门槛： 如果计划针对的是 Bug 修复、验证失败、过时/错误的最终输出、回归问题或行为变更修复，必须重点验证计划或其引用的分析是否包含 Debugger Trace: End -> Start、所有馈入路径、假设矩阵、负责修复的层级以及前向收敛证明。若缺少这些内容，请停止并报告缺失的追踪链接，即使此变体会跳过测试，也不得实施。

任务跟踪初始化与任务提取：

• 使用 Step 0: [Plan Name] - [Phase Name] 和所有命令步骤（Step 1 至 Step 6）初始化任务跟踪
• 阅读阶段文件（例如 phase-01-preparation.md）
• 查找任务/步骤/阶段/章节/编号列表/项目符号列表
• 必须将以下内容转换为任务跟踪任务：
  • 阶段实施任务 → Step 2.X（Step 2.1、Step 2.2 等）
  • 阶段代码审查任务 → Step 3.X（Step 3.1、Step 3.2 等）
• 确保每项任务都有唯一名称（每项任务的 X 递增）
• 将任务添加到任务跟踪中，并放在对应命令步骤之后

输出： ✓ Step 1: Found [N] tasks across [M] phases - Ambiguities: [list or "none"]

在任务跟踪中将步骤 1 标记为已完成，并将步骤 2 标记为进行中。

---

步骤 2：实施

按照提取的任务，逐步实施所选计划阶段（Step 2.1、Step 2.2 等）。完成任务后将其标记为已完成。对于 UI 工作，调用 ui-ux-designer 子 Agent："Implement [feature] UI per./docs/design-guidelines.md"。对于图像资源，使用 ai-multimodal 技能；对于编辑工作，使用 media-processing 技能。运行类型检查并编译，以验证没有语法错误。

输出： ✓ Step 2: Implemented [N] files - [X/Y] tasks complete, compilation passed

在任务跟踪中将步骤 2 标记为已完成，并将步骤 3 标记为进行中。

---

步骤 3：代码审查

调用 code-reviewer 子 Agent：“审查计划阶段 [phase-name] 的变更。检查安全性、性能、架构以及 YAGNI/KISS/DRY。”如果发现严重问题：立即停止，修复所有问题，重新运行 tester 进行验证，再次运行 code-reviewer。重复以上步骤，直至没有严重问题。

严重问题： 安全漏洞（XSS、SQL 注入、OWASP）、性能瓶颈、架构违规、原则违规。

输出： ✓ Step 3: Code reviewed - [0] critical issues

验证： 如果严重问题数量 > 0，则保持步骤 3 未完成，并在进入下一步前解决这些问题——只有数量为 0 时，步骤 3 才算完成。

在任务跟踪中将步骤 3 标记为已完成，将步骤 4 标记为进行中。

---

步骤 4：用户批准 ⏸ 阻塞关卡

呈现摘要（3-5 条）：已实现的内容、代码审查结果。

明确询问用户： “阶段实现已完成。代码已审查。是否批准这些变更？”

停止并等待——在用户回复前，不要输出步骤 5 的内容。

输出（等待期间）： ⏸ Step 4: WAITING for user approval

输出（获得批准后）： ✓ Step 4: User approved - Ready to complete

在任务跟踪中将步骤 4 标记为已完成，将步骤 5 标记为进行中。

---

步骤 5：收尾

前提条件： 用户已在步骤 4 中批准（如上所示）。

1. 状态更新——两项均为必需，且并行执行：

• 调用 project-manager 子 Agent：“在 [plan-path] 中更新计划状态。将计划阶段 [phase-name] 标记为 DONE，并注明时间戳。更新路线图。”
• 调用 docs-manager 子 Agent：“更新计划阶段 [phase-name] 的文档。变更文件：[list]。”

2. 入门检查： 检测入门要求（API 密钥、环境变量、配置）+ 生成包含后续步骤的摘要报告。

3. 自动提交（步骤 1 和 2 完成后）：

• 仅在以下条件满足时运行：步骤 1 和 2 均成功 + 用户已批准 + 测试已通过
• 自动暂存，使用提交消息 [phase - plan] 进行提交并推送

验证： 步骤 1 和 2 必须成功完成。只有满足条件时，才运行步骤 3（自动提交）。

在任务跟踪中将步骤 5 标记为已完成。

阶段工作流已完成。可以开始下一计划阶段。

---

第一原则——易于变更

每项编码决策的成功指标，都是 未来变更成本。 DRY、SRP、抽象、设计模式、命名、分层、测试——所有 技术都服务于一个目标：降低下一次变更的成本。

评估代码、重构、测试或抽象时，请问： 这会让下一次变更的成本更低，还是更高？

• 拒绝会提高变更成本的“最佳实践”（过早抽象、 推测式通用化、泄漏的间接层、没有收益的繁文缛节）。
• 在审查结果中指出真正的敌人：耦合、隐藏状态、重复的 知识、意图不明、过早暴露的不可逆决策。
• 易于变更的简单设计，胜过复杂却不易变更的设计。

在应用下面的任何特定规则、模式或检查清单之前，先运用这一视角——如果后续规则会提高变更成本，则以这一原则为准。

---

关键强制规则

步骤输出必须遵循统一格式： ✓ Step [N]: [Brief status] - [Key metrics]

示例：

• Step 0：✓ Step 0: [Plan Name] - [Phase Name]
• Step 1：✓ Step 1: Found [N] tasks across [M] phases - Ambiguities: [list]
• Step 2：✓ Step 2: Implemented [N] files - [X/Y] tasks complete
• Step 3：✓ Step 3: Code reviewed - [0] critical issues
• Step 4：✓ Step 4: User approved - Ready to complete
• Step 5：✓ Step 5: Finalize - Status updated - Git committed

如果缺少任何“✓ Step N:”输出，该步骤即未完成。

必须进行任务跟踪： 在 Step 0 初始化，并在进入下一步之前标记当前步骤已完成。

必须调用子 Agent：

• Step 3：code-reviewer
• Step 4：在用户批准时调用 project-manager 和 docs-manager

阻塞关卡：

• Step 3：严重问题必须为 0
• Step 4：用户必须明确批准
• Step 5：project-manager 和 docs-manager 都必须成功完成

请记住：

• 按顺序执行每一步；只有验证通过且用户明确批准后才能继续。
• 每次命令运行只能处理一个计划阶段。命令只聚焦于单个计划阶段。
• 你随时可以使用 ai-multimodal 技能按需生成视觉素材。
• 你必须始终使用 ai-multimodal 技能读取并分析生成的素材，以验证其符合要求。
• 如需编辑图像（移除背景、调整、裁剪），请按需使用 media-processing 技能或类似工具。

---

后续步骤（独立运行：必须直接向用户提问。若处于工作流中则跳过。）

必须注意——无一例外： 如果在工作流之外调用此技能，必须通过直接提问向用户提供以下选项。即使任务看似“简单”或“显而易见”，也不得跳过——由用户决定：

• “继续完整工作流（推荐）”——我会从当前进度开始，判断最合适的工作流（代码已实现，尚未测试）。这样可确保不会跳过审查、测试和文档步骤。
• “$code-simplifier”——简化实现
• “$workflow-review-changes”——在提交前审查更改
• “跳过，手动继续”——由用户决定

如果已经处于工作流中，则跳过——工作流会处理步骤安排。

[IMPORTANT] 使用任务跟踪，在开始前将所有工作拆分为小任务——包括每个文件读取任务。这有助于避免长文件导致上下文丢失。对于简单任务，AI 必须询问用户是否跳过。

• docs/project-reference/domain-entities-reference.md — 领域实体目录、关系及跨服务同步（任务涉及业务实体/模型时阅读）（相关时直接阅读；不要依赖钩子注入的对话文本）

端到端调试追踪 — 对于复杂 Bug、验证失败、回归修复、会改变行为的代码或不清楚的代码流程，在提出修复方案前，先从观察到的最终状态开始，向后追溯。

1. 帧 0：观察到的最终状态 — 明确指出用户可见的输出、失败的断言、日志行、持久化值、API 响应、渲染后的 UI 或聚合分桶。记录生成该结果的读取器／查询／渲染器，并提供 file:line 证据。
2. 每次向后追溯一跳 — 沿着最终读取器 -> 投影／缓存／存储 -> 写入器 -> 消费者／处理器／任务 -> 生产者／调用方 -> 原始触发，逐步追溯。每一跳都记录：输入、转换、输出、所有者和证据。
3. 列出所有馈入路径 — 找出所有可能写入最终路径的上游生产者／调用方／事件／任务，包括重试、异步、缓存、后台及其他 UI／API 路径。将每条路径标记为已验证、已排除或仍未知。
4. 建立假设矩阵 — 针对每个合理的原因，列出支持证据、反对证据、复现／验证方法、影响范围和状态（主要、促成因素、已排除、潜在）。在明确排除或界定其他竞争原因之前，不要修复。
5. 选择负责修复的层 — 确定不变量的所有者，以及能够保护所有下游消费者的最低共享层。除非症状所在位置负责该不变量，否则拒绝在症状处修复。
6. 正向证明收敛 — 选定修复后，再次从起点追溯到终点，说明修正后的状态如何到达观察到的最终输出。将每个根本原因对应到修复部分，并将每个修复部分对应到测试／证明。

在以下事项完成前保持阻塞： 明确最终状态 · 写出反向追溯 · 列出所有馈入路径 · 完成假设矩阵 · 论证负责修复的层 · 将正向收敛证明对应到测试。

绝不： 从第一个可疑的代码路径开始。把多个生产者合并成一条“流程”。未经证明读取模型，就把重复症状当作重复记录。跳过已排除的假设。

嵌套任务展开约定 — 对于工作流步骤调用，[Workflow] ... 行仅为父容器；子技能仍需创建可见的阶段任务。

1. 首先调用当前任务列表。如果存在匹配的活动父工作流行，则设置 nested=true 并记录 parentTaskId；否则独立运行。
2. 在阶段工作开始前，为每个已声明的阶段创建一个任务。嵌套时，将主题前缀设为 [N.M] $skill-name — phase。
3. 嵌套时，使用 TaskUpdate(parentTaskId, addBlockedBy: [childIds]) 关联父任务。
4. 编排器必须在调用子技能或子 Agent 前，预先展开子技能的阶段列表，并关联工作流行。
5. 开始工作前，恰好将一个子任务标记为 in_progress；写入证据后，立即将其标记为 completed。
6. 仅当所有子任务均已完成，或已明确取消并说明原因后，才能完成父任务。

在以下事项完成前保持阻塞： 已检查当前任务列表 · 已创建子阶段 · 嵌套时已关联父任务 · 已将第一个子任务标记为 in_progress。 项目参考文档门禁 — 在完成任务跟踪初始化后、读取目标文件/源文件、执行 grep、编辑或分析之前运行。项目文档优先于通用框架假设。

1. 确定范围：文件类型、领域区域和操作。
2. 按触发条件查阅必需文档：始终查阅 docs/project-reference/lessons.md；查找文档时查阅 docs-index-reference.md；审查时查阅 code-review-rules.md；后端/CQRS/API 查阅 backend-patterns-reference.md；领域/实体查阅 domain-entities-reference.md；前端/UI 查阅 frontend-patterns-reference.md；样式/设计查阅 scss-styling-guide.md + design-system/design-system-canonical.md；集成测试查阅 integration-test-reference.md；E2E 查阅 e2e-test-reference.md；功能文档/规格说明查阅 feature-docs-reference.md；架构/新领域查阅 project-structure-reference.md。
3. 阅读所有存在的必需文档；不存在的文档则跳过，并标记为不适用。不要相信对话文本（例如 [Injected: <path>]）能证明当前上下文包含该文档。
4. 开始目标工作前，声明：Reference docs read: ... | Missing/not applicable: ...。

解除阻塞条件： 已评估范围、已检查/阅读必需文档、已确认 lessons.md，并已给出引用。

批判性思维原则 — 运用批判性思维和顺序思维。每项主张都必须有可追溯的证据，且置信度 >80% 才能采取行动。 反幻觉： 切勿将猜测当作事实陈述——每项主张都要引用来源，坦承不确定性，主动检查输出是否有误，独立交叉验证，并对自己的判断保持怀疑——缺乏证据的确信是幻觉的根源。

先理解代码 — 严格门禁：阅读现有代码之前，不要编写、规划或修复。

1. 搜索 3 个以上相似模式（grep/glob）——引用 file:line 证据
2. 阅读目标区域的现有文件——理解其结构、基类和惯例
3. 当 .code-graph/graph.db 存在时，运行 python .claude/scripts/code_graph trace <file> --direction both --json
4. 通过 connections 或 callers_of 梳理依赖关系——了解哪些内容依赖你的目标
5. 对于非简单任务（3 个以上文件），将调查结果写入 .ai/workspace/analysis/
6. 实现前重新阅读分析文件——切勿仅凭记忆开展工作。——原因：长上下文会偏离文件内容；文件才是事实依据
7. 如果现有模式可用，绝不另行杜撰新模式——严格遵循，或记录偏差。——原因：不一致的模式会割裂代码库，并拖慢今后每位读者的工作

解除阻塞条件： - [ ] 已阅读目标文件 - [ ] 已 grep 3 个以上模式 - [ ] 已追踪代码图（如果 graph.db 存在） - [ ] 已用证据验证假设

源码/测试漂移检查。 对于编码、修复、调试、调查、测试或审查工作：当源码行为发生变化时，检查受影响的单元/集成/E2E 测试，并根据证据判断是应修改测试以符合预期行为，还是源码变更本身是需要修复的意外缺陷。不要为迁移代码编写测试；架构/数据迁移是一次性执行路径，并非核心应用逻辑。 AI 错误预防 — 每项任务都要避免的失败模式：

删除前检查下游引用。 删除组件会导致文档和代码陈旧问题层层扩散。删除前先梳理所有引用文件。 根据实际代码核验 AI 生成的内容。 AI 会虚构 API、类名和方法签名。记录或引用之前，务必通过 grep 确认它们确实存在。 编辑后追踪完整依赖链。 只修改定义会遗漏由其派生的下游变量和使用方。务必追踪完整链路。 核验正确性时追踪所有代码路径。 确认代码存在，不等于确认代码会执行。务必追踪提前退出、错误分支和条件跳过，而不只是正常路径。 调试时，修复前先问“这是谁的责任？”。 追踪问题出在调用方（数据错误）还是被调用方（处理错误）。在负有责任的层修复，绝不要只修补症状出现的位置。 假定现有值是有意设置的——修改前先问“为什么”。 修改任何常量、限制、标志或模式之前：阅读注释、查看 git blame、检查周边代码。 核验所有受影响的输出，而不只是第一个。 涉及多个技术栈的更改，需要核验每一项输出。一个检查通过，不代表所有检查都通过。 整体优先调试——避免陷入最近关注点陷阱。 调查任何故障时，先列出所有前置条件（配置、环境变量、数据库名称、端点、依赖注入注册、数据前提），然后逐一根据证据核实，再提出任何代码层面的假设。 精准修改——执行差异测试。 修复 Bug：每一行改动都必须能直接追溯到该 Bug。不要重排样式或改进相邻代码。增强任务：实施改进，并明确说明。 编码前先明确歧义——不要默默选择。 如果请求有多种解释，请逐一列出，并给出工作量估算后询问。绝不要擅自假定应处理所有记录、采用基于文件的方案或更复杂的路径。

重要，务必注意：任何修改之前，先搜索至少 3 种现有模式并阅读代码。若 graph.db 存在，则运行图追踪。

务必注意：运用批判性思维——每项主张都需要经过追踪的证据，置信度须高于 80% 才能采取行动。防止幻觉：绝不要把猜测说成事实。

务必注意：遵循 AI 错误预防原则——整体优先调试、在负有责任的层修复、编码前明确歧义，并在压缩上下文后重新阅读文件。

• 强制要求：完成任务跟踪初始化后、开始处理目标/源代码之前，阅读必需的项目参考文档，并引用 Reference docs read: ...。
• 强制要求：始终包含 lessons.md；项目规范优先于通用默认规则。

重要，务必注意：调试器追踪门槛：对于非简单的 Bug 修复、问题调查或代码审查，从观察到的最终输出开始，反向追踪 reader → storage/projection → writer → consumer/job → producer/trigger。修复前列举所有输入路径和假设。在追踪、假设矩阵、责任修复层和正向收敛证明齐备之前，禁止继续。

• 强制要求：父级工作流条目不能替代子阶段跟踪；存在嵌套时，展开各阶段并关联父级条目。
• 强制要求：协调者在调用前预先展开子技能阶段；使用 [N.M] $skill-name — phase 前缀，并遵循同一时间仅有一个 in_progress 的原则。

收尾提醒

重要：务必注意 开始前，将工作拆分为小型待办任务并使用任务跟踪 重要：务必注意 创建新代码前，在代码库中搜索 3 个或更多相似模式 重要：务必注意 每项断言都要引用 file:line 作为依据（置信度 >80% 才采取行动） 重要：务必注意 添加一项最终审查待办任务，以验证工作质量 重要：务必注意 通过直接向用户提问来确认决策——绝不自动做决定 强制：重要，务必注意 开始前阅读以下文件：

重要：务必注意 开始前阅读 CLAUDE.md

[TASK-PLANNING] 开始行动前，分析任务范围，并使用任务跟踪系统地将其拆分为小型待办任务和子任务。

---

收尾提醒——易于更改是成功指标。 每项发现、 测试、重构和抽象都必须回答一个问题：这会让 下一次更改的成本降低还是增加？ 如果不能降低未来 更改的成本，就应舍弃。耦合、隐藏状态、重复知识和 意图不明确才是真正的敌人——请明确指出。

无钩子提示词协议镜像（自动同步）

来源：.claude/hooks/lib/prompt-injections.cjs + .claude/.ck.json

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] 工作流执行协议——必须遵守，重要，务必注意，绝对关键。任何情况下都不得跳过。

通用可移植性边界： 可复用技能和协议文本应保持项目中立；项目特定约定应从 docs/project-config.json 和 docs/project-reference/ 中查找。应用共享 AI-SDD，参见 shared/sdd-artifact-contract.md。阅读 docs/project-config.json 和 docs/project-reference/docs-index-reference.md，然后打开其中列出的项目参考文档。只要具备此共享上下文和本地文档，任何受支持的 AI 工具都可以执行。

1. 检测： 将提示词与工作流目录匹配
2. 分析： 找出最匹配的工作流，并评估自定义步骤组合是否更合适
3. 询问（必需格式）： 直接向用户提问，格式如下；但如果用户明确调用了某个工作流/技能，且本地协议将明确调用视为确认，则无需提问：
   • 问题：“你想启用哪个工作流？”
   • 选项 1：“启用 [最佳匹配工作流]（推荐）”
   • 选项 2：“启用自定义工作流：[步骤 1 → 步骤 2 → ...]”（附上一句话说明理由）
4. 启用（经确认后）： 标准工作流调用 $workflow-start <workflowId>；自定义步骤则按顺序手动执行
5. 创建任务： 使用任务跟踪涵盖工作流的所有步骤
6. 执行： 按顺序遵循各个步骤 [CRITICAL-THINKING-MINDSET] 运用批判性思维和顺序思维。每项断言都需要可追溯的证据，置信度 >80% 才采取行动。 反幻觉原则： 绝不将猜测当作事实陈述——每项断言都要引用来源；坦诚承认不确定性；自行检查输出是否有误；独立交叉验证；对自己的信心保持怀疑——没有证据的确信是幻觉的根源。 AI 注意力原则（首因—近因）： 对于较长的提示词/协议，将 3 条最关键的规则同时放在开头和结尾，以便在长上下文窗口中仍能遵循指令。 目标驱动执行： 先定义成功标准，反复执行直至验证通过，并且只有在可观察的检查均通过后才停止。 测试验证意图： 测试必须保护业务规则/不变量，并在受保护的意图遭到破坏时失败，而不能只是照搬当前行为。

[LESSON-LEARNED-REMINDER] [BLOCKING] 任务规划与持续改进 — 必须遵守。请勿跳过。

开始前将工作拆分为小任务（任务跟踪）。添加最后一项任务：“分析 AI 错误与经验教训”。

提取经验教训——只分析根本原因，不要只修复症状：

1. 指明失败模式（推理或假设错误），而不是症状——“假设 API 存在，却没有阅读源代码”，而不是“使用了错误的枚举值”。
2. 通用性测试：此失败模式是否适用于 ≥3 种情境或代码库？如果不适用，就再抽象一个层次。
3. 将其写成普遍规则——去掉特定于项目的名称、路径和类。确保规则适用于任何代码库。
4. 合并：多个错误若具有相同的失败模式，则合并为一条经验教训。
5. 复发检查：“如果没有此提醒，这种情况会在未来的会话中再次发生吗？”——不会 → 跳过 $learn。
6. 自动修复检查：“$code-review/$code-simplifier/$security/$lint 能否发现此问题？”——能 → 改进审查技能。
7. 两项检查均通过 → 请用户运行 $learn。 [TASK-PLANNING] [MANDATORY] 执行任何工作流或技能步骤之前，先为所有计划步骤创建或更新任务跟踪，然后在每个步骤开始和完成时保持任务跟踪同步。