aif-improve

改进 - 计划细化（第二次迭代）

通过对照代码库重新分析现有计划，对其进行细化。查找缺口、遗漏的任务、错误的依赖关系，并提升任务质量。

核心理念

existing plan + deeper codebase analysis + user feedback (optional)
    ↓
find gaps, missing edge cases, wrong assumptions
    ↓
enhanced plan with better tasks, correct dependencies, more detail

工作流

步骤 0：加载配置并解析参数

**首先：**如果 .ai-factory/config.yaml 存在，则读取它以解析：

• 命令默认值：workflow.improve_check（布尔值，默认值：false）。未设置时使用 false；值或类型无效（包括带引号的布尔字符串）时，发出 WARN [config] invalid workflow.improve_check; falling back to false，并使用 false。
• 路径：paths.plan、paths.plans、paths.fix_plan、paths.research、paths.description、paths.architecture、paths.roadmap、paths.rules_file、paths.rules、paths.patches 和 paths.archive；推导出 research_bundles_dir = <paths.research 的父目录>/research/
• 语言：language.ui 用于提示词和摘要，language.artifacts 用于计划制品更新，language.technical_terms 用于计划制品中面向人类的技术术语
• Git：git.enabled、git.base_branch、git.create_branches
• 工作流：workflow.plan_id_format（默认值：slug）——用于基于分支的计划发现。 有效值：slug 和 sequential。根目录下的 *.md 是命名完整计划， 除非它是解析后的快速计划/修复计划路径；直接子目录中的 */index.md 只有在其中恰好包含一个 `` 时，才是超大计划包入口。当使用 sequential 时， 同时搜索 [0-9]{4}_<branch-slug>.md 和 [0-9]{4}_<branch-slug>/index.md，然后选择前缀最高的条目。 timestamp 和 uuid 是保留值，目前行为与 slug 相同。 将任何未知值视为 slug。

如果 config.yaml 不存在，则使用默认值：

• 计划：paths.plan（默认值：.ai-factory/PLAN.md）
• plans/：.ai-factory/plans/
• 修复计划：paths.fix_plan（默认值：.ai-factory/FIX_PLAN.md）
• 研究：.ai-factory/RESEARCH.md
• patches/：.ai-factory/patches/
• DESCRIPTION.md：.ai-factory/DESCRIPTION.md
• 架构：.ai-factory/ARCHITECTURE.md
• 路线图：.ai-factory/ROADMAP.md
• 规则文件：.ai-factory/RULES.md
• 规则目录：.ai-factory/rules/
• ui_language：en
• artifact_language：en
• technical_terms_policy：keep
• workflow.plan_id_format：slug

解析后的语言值：

• ui_language = language.ui || "en"
• artifact_language = language.artifacts || language.ui || "en"
• technical_terms_policy = language.technical_terms || "keep"

如果 technical_terms_policy 不是 keep、translate 或 mixed，则视为 keep。english 等旧版值也按 keep 处理。

所有 AskUserQuestion 提示、进度更新、细化报告、摘要和后续步骤指导都必须使用 ui_language 编写。

在 paths.plan、paths.plans 或 paths.fix_plan 下生成或更新的任何计划制品内容都必须使用 artifact_language 编写。

例外：现有的 ## Original Request 部分是原始输入内容，而不是生成的制品文本。每次编辑或重新生成时，都必须严格按计划文件中的原样保留其标题和正文，即使 artifact_language 与之不同也不例外。不得翻译、总结、规范化、删减或改写它。 模板和示例定义的是结构，而不是固定的英文输出。如果 artifact_language 不是 en，请在保存前翻译面向读者的标题、标签、任务描述、路线图理由、研究摘要、改进说明和依赖说明。保留 Markdown 结构、复选框语法、任务 ID、数字前缀、分支名称、提交消息、命令、文件路径、配置键、包名称、API 名称、WARN/INFO 标签和原始错误，不作更改。请原样保留 ## Research Context、Source:、Active Summary、Updated: 和 SHA256:，因为下游研究偏移检查会将它们解析为兼容性令牌。请原样保留 ## Requirements Reconciliation，因为下游工作流检查会将其解析为兼容性令牌。对其他面向读者的术语应用 technical_terms_policy。

首先解析参数：

- --list    → list available plans only (read-only, then STOP)
- +check    → after refinement, validate findings via a fresh-context subagent
- --no-check → skip findings validation for this invocation, overriding config
- @<path>   → explicit plan file, ultra directory, or ultra `index.md` override (highest priority)
- remaining argument text → optional improvement prompt

+check 和 --no-check 是独立的控制令牌，可出现在 $ARGUMENTS 的任意位置。在解析 @<path> 和改进提示词之前，仅移除这些令牌；不要移除路径或正文中的子字符串。根据显式标志解析 check_enabled，否则使用 workflow.improve_check。如果两个标志都出现，以最后一个为准。切勿将配置的默认值添加到 $ARGUMENTS 或改进提示词前面。

如果存在 --list，则以它为准，不执行任何优化。在 --list 模式下，验证标志和 workflow.improve_check 都会被静默忽略（优化运行前无需验证任何内容）。下文中，“已设置 +check”表示解析后的 check_enabled = true，无论它是由配置还是显式标志启用。

Step 0.list：列出可用计划（--list）

如果 $ARGUMENTS 包含 --list，请执行 references/LIST-MODE.md 中的流程，然后停止。该文档是发现规则、输出格式和只读约定（不进行优化、不修改文件、静默忽略 +check）的唯一准则。不要在此处重复其内容。

Step 1：解析活动计划

此步骤在默认（非 --list）模式下运行，并按以下优先级链选择一个计划产物进行优化。--list 的发现列表逻辑位于 references/LIST-MODE.md，与此步骤相互独立。

按以下优先级定位活动计划产物：

1. If `$ARGUMENTS` contains `@<path>`:
   - Resolve the path (relative to project root; absolute paths allowed)
   - Accept a markdown file, an ultra directory containing `index.md`, or that `index.md`
   - If missing → show "Plan artifact not found: <path>" and STOP
   - Before normalizing a directory or treating an explicit `index.md` as ultra,
     Read `index.md` and require exactly one
     ``; otherwise STOP with a plan-integrity error
2. No explicit `@<path>` override → Check current git branch:
   git branch --show-current
   → Convert branch name to filename: replace "/" with "-" (this is <branch-slug>)
   → When `workflow.plan_id_format = sequential`, glob both:
     `<configured plans dir>/[0-9][0-9][0-9][0-9]_<branch-slug>.md`
     `<configured plans dir>/[0-9][0-9][0-9][0-9]_<branch-slug>/index.md`
     Read every directory candidate and retain it only when `index.md` contains
     exactly one ``. Choose the highest-numbered
     valid artifact and emit `WARN [aif-improve]` when multiple valid candidates
     exist; if both shapes share the highest prefix, prefer ultra.
   → If no valid sequential match exists, or sequential mode is inactive, check
     `<configured plans dir>/<branch-slug>/index.md` and
     `<configured plans dir>/<branch-slug>.md`. Read the directory entrypoint
     before selection and ignore it unless it contains exactly one ultra marker;
     if both valid shapes exist, warn and prefer ultra.
   Example (slug):       feature/user-auth → .ai-factory/plans/feature-user-auth.md
   Example (sequential): feature/user-auth → .ai-factory/plans/0042_feature-user-auth.md
3. If the branch-based plan is missing or git mode is off:
   → Count root `*.md` full plans plus declared-ultra direct child `*/index.md`
     entrypoints; exclude resolved `paths.plan` and `paths.fix_plan`
   → If exactly one artifact exists, use it
   → Do not count ultra phase files as plans
   → If multiple exist, ask the user to choose or require `@<path>`
4. No named full/ultra plan → Check the resolved fast plan path (from /aif-plan fast)
5. No regular plan and no resolved fast plan → Check the resolved fix plan path (from /aif-fix plan mode)

**注意：**计划发现仅扫描 paths.plans/。通过 /aif-archive 归档到 paths.archive/plans/ 的计划不在发现范围内。 任何自动发现的 */index.md 候选文件都必须在选择前读取，并且除非它恰好包含一个 ``。带有标记但链接损坏的 ultra bundle 属于阻断性完整性错误，不能作为回退机会。

如果在任何位置都找不到计划文件：

No active plan found.

To create a plan first, use:
- /aif-plan full <description>  — for a rich single-file feature plan
- /aif-plan ultra <description> — for an exhaustive multi-file plan bundle
- /aif-plan fast <description>  — for a quick task plan
- /aif-fix <bug description>    - for a bugfix plan (use the resolved fix plan path)

→ **在此停止。**没有计划产物时不得继续。

如果找到计划产物 → 继续执行步骤 2（加载上下文）。

Step 2：加载上下文

2.1：读取计划产物

完整读取选定的入口文件。如果它是 ultra index.md，则验证其 Phase Index 链接，并按顺序读取所有链接的阶段文件，然后再分析或重新生成 bundle。将该 bundle 视为一个原子计划。理解以下内容：

• 功能范围和目标
• ## Original Request（如存在）：原始用户意图，以及计划不可变的范围锚点。将此部分视为原始来源输入，在任何计划编辑或重新生成时都必须原样保留。
• 当前任务（主题、描述、依赖项）
• 设置（测试、日志记录偏好）
• 提交检查点
• 已完成的任务（复选框 - [x]）
• 对于 ultra：每个任务阶段文件中的精确路径/符号、实施步骤、约定、风险、验收标准和验证方式

2.2：读取项目上下文

如果 .ai-factory/DESCRIPTION.md 存在，则读取该文件（使用配置中的路径）：

• 技术栈
• 架构
• 约定
• 非功能性需求 存在已解析的架构和路线图制品时，请阅读它们。按顺序阅读已解析的规则层级：paths.rules_file、rules.base，然后是与计划相关的命名 rules.<area> 条目。更具体的规则优先于通用规则。除非项目明确声明路线图文本对详细行为具有权威性，否则应将其视为范围依据。

如果计划包含 ## Research Context，请将其中嵌入的副本视为已提交的需求快照。解析首个 Source: / Reference: 行时，使用规范语法 ^(?:Source|Reference):\s+\x60([^\x60]+)\x60\s+\(；对于较早的裸路径行，回退使用 ^(?:Source|Reference):\s+(.+?)\s+\(。只有当这两种形式都无法识别出可用路径时，才回退使用已配置的 paths.research。

如果解析出的来源位于 research_bundles_dir 内，则要求其同级 INDEX.md 中恰好包含 ``，并从 ## Artifact Index 链接该 RESEARCH.md；否则发出 WARN [research-drift]。有效的同级 C4/ADR/依赖制品仅作为依据，不得扩大计划范围。

存在 SHA256: 时，应严格提取 与 之间当前来源文本，移除 HTML 注释块，保留行顺序和行首空白，删除每行末尾的空格，使用 LF 换行，并以一个换行符结尾。通过标准输入使用 shasum -a 256 或 sha256sum 计算哈希；摘要具有权威性。仅当不存在 SHA256: 时，才将 Updated: 用作旧版回退依据。来源缺失/无效或修订版本不匹配时，发出 WARN [research-drift]；除非用户明确要求重新定基，否则应依据嵌入的 Research Context 进行完善。

为未链接的计划添加 ## Research Context 时，使用相同的规范化算法，并将结果作为 SHA256: 的首个输出字段。通过标准输入 / 内联 shell 输入计算，不得创建临时仓库制品。

否则，按照与 /aif-plan 相同的保守顺序，最多选择一个相关研究来源：显式来源；一个明确匹配的直接子级 bundle，且其 INDEX.md 恰好包含 ``、声明 Status: active，并从 ## Artifact Index 链接其 RESEARCH.md；然后是已配置的旧版文件。不要合并多个来源，也不要仅凭最近时间来选择。

2.3：读取补丁（有限回退）

将补丁用作备用上下文，而非默认来源：

• 如果 .ai-factory/skill-context/aif-improve/SKILL.md 不存在，且已解析的补丁目录存在：
  • Glob: <resolved patches dir>/*.md
  • 按文件名升序（字典序）排序补丁，然后选择最后 10 个（如果不足 10 个，则选择全部）
  • 仅阅读这些选中的补丁文件
  • 重点关注会影响计划质量的可复用预防/根因模式
• 如果 skill-context 存在，默认不要阅读所有补丁。
  • 围绕已知的反复出现的问题进行完善时，可酌情检查少量有针对性的补丁。

阅读 .ai-factory/skill-context/aif-improve/SKILL.md——如果该文件存在，则必须阅读。

该文件包含 /aif-evolve 根据补丁、代码库约定和技术栈分析积累的项目专属规则。这些规则针对当前项目量身定制。 如何应用技能上下文规则：

• 将其视为对此技能通用说明的项目级覆盖规则
• 当技能上下文规则与此 SKILL.md 中的通用规则冲突时，以技能上下文规则为准（更具体的上下文优先——与嵌套 CLAUDE.md 文件的原则相同）
• 当不存在冲突时，同时应用两者：SKILL.md 中的通用规则和技能上下文中的项目规则
• 即使技能上下文规则看似与此技能的默认规则矛盾，也不要忽略它们——这些规则的存在，是因为项目实践证明默认规则不够充分
• 重要：技能上下文规则适用于此技能的所有输出，包括计划优化报告和任何计划修改。如果技能上下文规则规定“任务必须包含 X”或“计划结构必须包含 Y”，那么在优化时必须遵守。生成忽略技能上下文规则的优化报告属于缺陷。

**执行要求：**生成任何输出产物后，都要根据所有技能上下文规则进行检查。 如果违反了任何规则——请在向用户展示前修正输出。

2.4：加载当前任务列表

TaskList → Get all tasks with statuses

了解已创建、正在进行和已完成的内容。

第 3 步：深入分析代码库

现在，对代码库进行比 /aif-plan 最初更深入的探索：

3.1：追踪现有代码路径

对于计划中的每项任务，找出相关文件：

Glob + Grep: Find files mentioned in tasks
Read: Understand current implementation

查找：

• 计划应遵循的现有模式
• 已部分实现任务描述内容的代码
• 计划遗漏的隐式依赖项
• 计划应复用而非重新创建的共享实用工具或服务

3.2：检查集成点

查找计划可能遗漏的内容：

• 需要更新的 API 路由
• 所需的数据库迁移
• 需要修改的配置文件
• 导入／导出更新
• 适用的中间件或防护机制
• 现有的验证模式

3.3：检查边缘情况

根据技术栈和代码库，检查：

• 项目使用的错误处理模式
• 空值／未定义安全模式
• 所需的身份验证／授权检查
• 速率限制、缓存方面的考量
• 边界处的数据验证

3.4：协调需求与行为组合

• 阅读计划中的任何 ## Requirements Reconciliation 部分。将有研究依据的引用与嵌入其中的 ## Research Context 对照核实；除非用户明确要求重新设定基准，否则实时研究来源仅用于发现偏差。根据当前权威上下文核实其他引用内容。
• 仅当用户或项目声明了来源优先级时，才遵循该层级。如果相互冲突的来源没有明确的权威性声明，请报告歧义，不要擅自选择。
• 将路线图条目视为范围指示，而非详细的行为约定，除非项目明确另有规定。
• 当行为取决于彼此独立的选择器、状态、模式或输入形态时，请检查输入验证、持久化、输出／转换和副作用中的受支持组合。留意那些分别描述、但从未一起验证的组合。
• 当真实的代码库数据、配置、夹具、架构或内容定义了约定时，请确认计划通过主要集成路径，使用有代表性的现有产物进行测试。

步骤 4：识别改进项

将计划与调研结果进行比较。如果存在 ## Original Request，请将其作为原始意图／范围的基准，同时参考当前任务列表和已提交的任何 ## Research Context。只有支持原始请求或用户明确批准的改进提示时，拟议的优化才属于范围；否则应将其归入 4.6（out_of_scope），而不是加入当前计划。对问题进行分类：

4.1：缺失任务

• 应存在但不存在的任务（例如迁移、配置更新、索引创建）
• 未涵盖边缘情况的任务

4.2：任务质量问题

• 描述过于含糊（缺少文件路径、具体实现细节）
• 缺少日志记录要求
• 缺少错误处理细节
• 文件路径错误
• 缺少或不正确的需求引用、未解决的来源冲突，或在步骤 3.4 要求时缺少 ## Requirements Reconciliation 章节
• 缺少对受支持行为组合或有代表性的真实产物的验证。遵循计划的测试设置：仅在启用测试时添加测试；否则添加可运行／手动验证步骤。

4.3：依赖问题

• 任务顺序错误（任务 A 依赖 B，但 B 排在 A 后面）
• 缺少依赖关系（任务 C 需要任务 A 的输出，却未设置依赖）
• 不必要的依赖关系（任务可以并行执行）

4.4：冗余或重复任务

• 两个任务做同一件事
• 代码已存在，因此不再需要的任务
• 与现有功能重复的任务

4.5：任务规模问题

• 任务过大（应拆分）
• 任务过小（应合并）
• 拆分／合并的发现应放入“📝 Task Improvements”报告章节（improvements 组，与 4.2 并列）——这些发现会重组现有任务，而不是添加或移除任务。

4.6：超出范围的任务

• 计划中已有、单独看来有用，但与计划所针对的功能无关的任务（过度完善）
• 获批后，这些任务会从当前计划中移除——与 removals 相同的删除操作（参见步骤 6.4）。区别仅在报告中：超出范围的任务会单独放入“💡 Out of scope”章节，而不是归入“🗑️ Removals”，让用户在任务被删除前看到这个虽有用但无关的想法，并可选择在其他位置记录。该技能本身不会在任何位置持久保存超出范围的项目。

4.7：用户提示的改进（如果提供了 $ARGUMENTS）

如果用户在 $ARGUMENTS 中提供了具体改进指示（不包括 --list、+check、--no-check 和 @<path> 标记）：

• 根据用户反馈修改计划
• 查找需要根据提示进行修改的任务
• 如果用户提示有此要求，则添加新任务

这是一个调度步骤，而不是单独的发现类别。它产生的每项发现都应根据性质归入相应组：新任务归入 4.1（missing），对现有任务进行改写或扩充归入 4.2（improvements），明确要求移除的任务归入 4.4（removals），而“有用但超出范围”的想法归入 4.6（out_of_scope）。步骤 5 报告和 +check 验证中都没有单独的 4.7 组。

可选：步骤 4 与步骤 5 之间进行 +check 验证

当 check_enabled = true（且未使用 --list）时，请在此处、步骤 4 与步骤 5 之间执行 references/CHECK-MODE.md 中的验证流程。该流程会通过使用全新上下文的子 Agent 重新读取引用文件，然后丢弃编造的项目、改写部分正确的项目，并基于筛选后的列表重新计算依赖关系。对于 ultra，验证器必须将入口文件及所有关联的阶段文件作为计划产物接收；仅验证 index.md 并不完整。当 check_enabled = false 时，完全跳过此流程——输出中不包含任何与验证器相关的行，Summary 块保持默认格式，不显示两行 +check 计数。

第 5 步：呈现改进建议

以清晰的格式向用户展示发现的问题。按表情符号分组的各个部分便于快速浏览，但“🆕 缺失任务”、“📝 任务改进”、“🗑️ 删除项”和“💡 超出范围”中的条目都遵循相同的文本结构，不使用带有 原因： / 问题： / 修复： 标签的字段：

1. 行为影响 — 如果计划保持现状，会出现什么问题，或哪些方面会变得更困难（缺少功能、描述模糊的任务可能被错误实现、冗余任务浪费精力）。
2. 可选说明 — 来自代码库的简短引用、计划应遵循的现有模式或某种后果。仅在能提供有用信息时添加。
3. 计划定位 — Task #X 引用（新任务使用“在 Task #X 之后”）。
4. 建议修改 — 具体说明要添加什么、如何改写或删除什么。

“🔗 依赖关系修正”分组不采用上述结构重新表述 — 始终在其他四个分组之后（以及设置标志时，在 +check 过滤之后；参见 references/CHECK-MODE.md）计算，并采用简短的旧版格式：Task #X should depend on Task #Y. Reason: …。依赖关系条目只能引用通过过滤的任务。

下面的第 5 步报告模板仅定义结构。在面向用户的响应中，所有可读文本都应使用 ui_language 呈现。命令名称、路径、任务 ID、章节结构、选项结构、任务数、数字计数、WARN / INFO 标签和原始错误保持不变。

## Plan Refinement Report

Plan: [plan artifact path]
Tasks analyzed: N

### Findings

#### 🆕 Missing Tasks (N found)
1. The plan currently leaves authenticated requests without a session refresh step — long-running clients silently lose access after the access-token TTL. The existing middleware in `src/middleware/auth.ts` already exposes a `refresh()` hook, so the plan should reuse it instead of inventing a new one. After Task #3. Add a new task: "Wire `authMiddleware.refresh()` into the login flow and cover the expired-token path with an explicit test."

#### 📝 Task Improvements (N found)
1. Task #4 ("Add validation") gives no field-by-field contract — implementer will either over-validate or skip the email format check that the rest of the codebase enforces via `validators/email.ts`. Task #4. Rewrite as: "Validate `email` (via `validators/email.ts`), `password` (min 12 chars), and `displayName` (1-64 chars) in `RegisterRequest`; return 422 with field-level errors when validation fails."

#### 🔗 Dependency Fixes (N found)
1. Task #5 should depend on Task #2. Reason: Task #5 consumes the session helper introduced in Task #2.

#### 🗑️ Removals (N found)
1. Task #7 ("Create UserRepository") duplicates `src/repos/user.ts:12` which already exposes the same query surface — keeping the task will lead to a parallel implementation. Task #7. Remove the task; rely on the existing repository and adjust Task #8 to import it.

#### 💡 Out of scope — for later (N found)
1. Task #11 ("Refactor the logging module") looks reasonable on its own but is unrelated to the login feature this plan is about — keeping it expands scope without any concrete trigger from the current code paths. Task #11. Drop it from the active plan; the idea is surfaced here so you can capture it elsewhere (issue tracker, backlog note) if it's worth revisiting as its own feature later.

#### 📋 Summary
- Missing tasks: N
- Tasks to improve: N
- Dependencies to fix: N
- Tasks to remove: N
- Out of scope: N

When `+check` ran successfully, two extra rows (`Hidden by +check: N`, `Adjusted by +check: M`) are appended to the Summary block — the exact wording and failure-mode replacements live in `references/CHECK-MODE.md`.

AskUserQuestion: Apply these improvements?

Options:
1. Yes, apply all
2. Let me pick which ones
3. No, keep the plan as is

根据所选选项：

• Yes, apply all → 将所有改进应用到计划文件
• Let me pick which ones → 逐项呈现改进并征求批准
• No, keep the plan as is → 不做修改并退出

如果未发现改进：

以下完成模板仅定义结构。在这些面向用户的响应中，所有可读文本都应使用 ui_language 呈现。命令名称、路径、任务数和数字计数保持不变。

## Plan Review Complete

The plan looks solid! No significant gaps or issues found.

Plan: [plan artifact path]
Tasks: N

Ready to implement:
/aif-implement

第 6 步：应用已批准的改进

根据用户的选择：

6.1：改进任务

对于需要更完善描述的现有任务：

TaskGet(taskId) → read current
TaskUpdate(taskId, description: "improved description", subject: "improved subject")

6.2：添加缺失任务

对于新任务：

TaskCreate(subject, description, activeForm)
TaskUpdate(taskId, addBlockedBy: [...]) → set dependencies

6.3：修正依赖关系

TaskUpdate(taskId, addBlockedBy: [...])

6.4：删除冗余任务或超出范围的任务

removals 和 out_of_scope 都会执行相同的计划文件操作 — 删除任务：

TaskUpdate(taskId, status: "deleted")

两者的区别仅体现在报告中。removals 是没有价值的重复项：只提及一次便被遗忘。out_of_scope 项会出现在“💡 超出范围”部分中，让用户知道该想法已被注意到，并且是有意从此计划中移除，而非不留痕迹地删除。此技能不会在任何位置保留超出范围的任务 — 是否在其他地方（问题跟踪系统、待办列表）记录该想法，由用户决定。

6.5：更新计划产物

重要： 完成所有更改后，更新所选计划产物以反映新状态：

• 使用 - [ ] 复选框将新任务添加到正确的阶段
• 如果任务描述发生变化，请更新
• 如果依赖关系发生变化，请调整任务顺序
• 删除已移除的任务
• 如果任务数量发生显著变化，请更新提交检查点
• 保留已完成任务现有的 - [x] 复选框
• 完整保留现有的 ## Original Request，包括标题、正文、空白和换行。不要翻译、概述、规范化、删减或改写；此部分是原始输入，不受 artifact_language 改写规则限制。
• 在任何改写中，除非用户明确要求根据当前研究重新制定计划，否则请原样保留现有的 ## Research Context 及其 Source: / 修订标记
• 根据计划中已提交的证据，保留或更新 ## Requirements Reconciliation；确保标题、声明的权威来源、引文、适用的组合表以及验证场景与细化后的任务保持一致。关联研究发生变化时，在用户明确要求重新制定计划之前，保留由研究支持的既有决策；只有重新制定计划时，才能根据实时研究来源更新这些内容
• 如果根据当前研究细化未关联研究的计划，请通过复制相关的 Active Summary 添加 ## Research Context，并写入 Source: `<selected research path>` (Active Summary, Updated: <research Updated timestamp>, SHA256: <sha256 of copied Active Summary>)
• 使用规范的漂移标准化方式计算该哈希：移除 HTML 注释块，保留行顺序和行首空白，删除每行尾随空格，使用 LF 换行，并且末尾恰好保留一个换行符。通过标准输入 / 内联 shell 输入将标准化文本传递给 shasum -a 256 或 sha256sum，绝不要使用临时文件，并复制输出的第一个字段。
• 如果关联计划存在研究漂移，请在计划中保留已提交的 Research Context 和来源修订，并在细化报告中包含 WARN [research-drift]
• 对于 ultra，请原子化更新 index.md 和受影响的阶段文件：
  • 任务复选框仅保留在 index.md 中
  • 每个任务 ID 必须且只能映射到一个阶段章节
  • 添加 / 删除 / 重命名阶段文件时，必须同时更新 Phase Index 和任务链接
  • 改进已完成任务的详细信息时，保留其完成状态
  • 重新运行链接、孤立项、依赖关系和任务映射完整性检查
  • 满足 ultra 详细信息门槛：精确路径 / 符号、有序编辑、契约、错误 / 日志行为、测试策略、验收标准和验证

使用 Edit 对文件进行精确修改；如果改动较大，则使用 Write 重新生成受影响的文件。阶段详情发生变化时，绝不要只重新生成 index.md。

编辑或重新生成计划产物时，所有面向读者的产物内容都必须使用 artifact_language。上述示例仅用于说明结构。请原样保留已完成任务的 - [x] 复选框。## Original Request 是明确的语言策略例外：请逐字保留，因为它是用户的原始请求，而非生成的产物文本。

标识符不变量： 当现有完整计划文件名或 ultra 目录名符合 ^[0-9]{4}_.*(\.md)?$ 时，改写时必须保留其确切的数字前缀。在改进过程中绝不要重新编号计划——该前缀是永久标识，必须在任何重新生成后保留。请写回读取的同一文件或目录。

6.6：确认完成

下方的 Step 6.6 完成模板仅用于定义结构。请使用 ui_language 编写此用户可见回复中的所有面向读者的文本。命令名称、路径、任务数量和数字计数必须保持不变。

## Plan Refined

Changes applied:
- Added N new tasks
- Improved N task descriptions
- Fixed N dependencies
- Removed N redundant tasks

Updated plan: [plan artifact path]
Total tasks: N

Ready to implement:
/aif-implement

上下文清理

如有需要，建议用户释放上下文空间：使用 /clear 完全重置，或使用 /compact 压缩历史记录。

工件归属

• 主要归属：正在完善的计划工件（已解析的分支计划路径、指定的完整计划路径、已解析的快速计划路径，或在明确指定目标时已解析的修复计划路径）。
• 配置使用：通过 paths.plans 解析完整计划目录，通过 paths.plan 和 paths.fix_plan 解析快速计划和修复计划，通过 git.enabled 和 git.create_branches 配置 Git 行为，从 paths.research 及其派生的同级 research/ 目录读取可选的旧版或捆绑研究背景，并通过 paths.patches 配置补丁回退路径。
• 只读背景：描述、架构、路线图、规则和研究工件，但活动计划文件本身可更新。

重要规则

1. 不要从头重写 — 改进现有计划，而不是替换它
2. 保留已完成的工作 — 绝不修改或移除 - [x] 已完成任务
3. 改进应可追溯 — 每项更改都必须有代码库分析或用户输入作为依据
4. 遵守设置 — 如果测试设置为“无”，就不要添加测试任务。如果日志记录设置为“最低”，就不要添加详细的日志记录任务
5. 不要过度设计 — 除非至关重要，否则不要提出功能范围之外的任务。如果发现计划中的现有任务偏离范围，应将其列入“💡 超出范围”报告部分，而不是“🗑️ 移除”部分——用户应能将有用但不适用于当前计划的想法与无用的重复内容区分开来。
6. 只做最小必要改进 — 只提出重要的改进，不要罗列所有可能的增强项
7. 先征得用户批准 — 未经用户确认，绝不应用更改
8. 确保计划文件同步 — 改进后，计划文件必须与任务列表一致
9. 原始请求不可修改 — 如果存在 ## Original Request，应以其判断范围，并在每次编辑或重新生成计划时原样保留
10. 需求是外部证据 — 绝不要为了让计划看起来一致而重写需求、研究、路线图、规则或架构工件；应完善计划或报告冲突。

示例

默认、提示词驱动、无计划、指定计划文件以及“计划看起来很完善”等流程的示例见 references/EXAMPLES.md。--list 模式的示例见 references/LIST-MODE.md；+check 模式的示例见 references/CHECK-MODE.md。