aif-plan

Plan - 实施规划

为功能或任务创建实施计划。提供三种模式：

• Fast – 快速规划，不创建 git 分支，保存到配置的快速计划路径（默认：.ai-factory/PLAN.md）
• Full — 更完善的计划，会询问偏好，保存到配置的完整计划目录；当 git 已启用且允许创建分支时，还可选择创建 git 分支／工作树
• Ultra — 在配置的完整计划目录下创建详尽的多文件计划包：index.md 是清单／进度台账，每个实施阶段都单独存放在一个规范详尽的 markdown 文件中。适用于使用更强大的模型进行规划，之后交由较小的模型执行。

关于 Ultra 布局、详细要求、完整性检查和使用方行为， 请在创建或修改计划包之前阅读 references/ULTRA-FORMAT.md。

工作流

步骤 0（前置）：检测交接模式

确定交接模式、任务 ID 和分支约定。分别解析每个值，以确保仅传入 HANDOFF_MODE 和 HANDOFF_TASK_ID 的旧版调用方也能正确进入交接模式：

• HANDOFF_MODE：如果存在显式提示词值，则使用该值；否则使用环境变量值；否则为空字符串。
• HANDOFF_TASK_ID：如果存在显式提示词值，则使用该值；否则使用环境变量值；否则为空字符串。
• HANDOFF_BRANCH_PREPARED：如果存在显式提示词值，则使用该值；否则使用环境变量值；否则为 0。
• HANDOFF_BRANCH_NAME：如果存在显式提示词值，则使用该值；否则使用环境变量值；否则为空字符串。

仅对未在提示词中显式传入的值使用 Bash 工具：

Bash: printenv HANDOFF_MODE || true
Bash: printenv HANDOFF_TASK_ID || true
Bash: printenv HANDOFF_BRANCH_PREPARED || true
Bash: printenv HANDOFF_BRANCH_NAME || true

然后检查 HANDOFF_MODE：

当 HANDOFF_MODE 为 1（自主交接 Agent）时

交接协调器已直接管理状态转换和数据库写入。不要调用 MCP 工具（handoff_sync_status、handoff_push_plan）。而应：

• 不提问： 不要使用 AskUserQuestion —— 使用合理的默认值（启用详细日志、执行测试、编写文档、跳过路线图关联）。
• 默认模式： 按显式模式 → 有效的 workflow.plan_mode → fast 的顺序解析。在非交互式交接模式下，ask 默认值回退为 fast；此时绝不要询问模式。应用此回退前，请在步骤 0 中解析配置。
• 计划标注（强制）： 如果 HANDOFF_TASK_ID 非空，必须将 `` 插入计划入口文件的第一行（Ultra 模式下为 index.md；其他模式下为计划文件），并置于标题之前。此标注用于将计划与其交接任务关联，以便双向同步。如果设置了 HANDOFF_TASK_ID 却遗漏此标注，就属于错误 —— 完成前务必检查。

Handoff 下的分支所有权（CRITICAL）

Handoff 在 Agent 代码层面负责创建分支。如果 Handoff 已准备好分支，技能绝不能创建或切换分支。请遵循以下规则：

如果 HANDOFF_BRANCH_PREPARED 为 1：

• 不要执行 git checkout、git pull 或 git checkout -b。
• 后续所有行为中，均视为 --parallel 已禁用。
• 不要创建 worktree。
• 从提示词 / 环境变量中读取 HANDOFF_BRANCH_NAME。
• 严格验证是否完全相等：

  Bash: git rev-parse --abbrev-ref HEAD
  

  输出必须与 HANDOFF_BRANCH_NAME 完全一致。不要接受部分匹配、前缀匹配，也不要采用“分支名称包含 /”的启发式判断。
• 如果当前分支与 HANDOFF_BRANCH_NAME 不匹配，立即停止。在计划摘要中报告阻塞项：

  Branch drift: expected <HANDOFF_BRANCH_NAME>, actual <current>. 不要通过切换或创建分支来“修复”偏差——Handoff 会将其归类为 BranchIsolationError / blocked_external。

• 使用 HANDOFF_BRANCH_NAME（将 / 替换为 -）作为 full/ultra 计划标识符的前缀。full 写入 <configured plans dir>/<stem>.md；ultra 写入 <configured plans dir>/<stem>/index.md。跳过 Step 1.2 中的 slug 推导。

如果 HANDOFF_MODE 为 1，但 HANDOFF_BRANCH_PREPARED 未设置或为 0：

• 对于尚未采用预备分支约定的旧版 Handoff 客户端，使用回退路径。
• 按照 git.create_branches 配置正常执行 Step 1.4 中的分支创建操作。

当 HANDOFF_MODE 不为 1 时（手动 Claude Code 会话）

如果正在完善现有计划，请从计划入口文件第一行的 `` 注释中提取 Handoff 任务 ID（如果有）。如果正在创建新计划且没有注释上下文，请跳过所有 MCP 同步——此时没有关联的 Handoff 任务。

如果在计划注释中找到任务 ID，则通过 MCP 工具与 Handoff 同步：

• 开始时： 使用 { taskId: <extracted-id>, newStatus: "planning", sourceTimestamp: "<current UTC time in ISO 8601 format>", direction: "aif_to_handoff", paused: true } 调用 handoff_sync_status。
• 完成时： 使用 { taskId: <extracted-id>, planContent: <full plan text> } 调用 handoff_push_plan。对于 ultra，将计划包序列化为 index.md，后接按顺序排列的所有 Phase Index 文件，每个文件前都加上 ``。然后使用 { taskId: <extracted-id>, newStatus: "plan_ready", sourceTimestamp: "<current UTC time in ISO 8601 format>", direction: "aif_to_handoff", paused: true } 调用 handoff_sync_status。

CRITICAL： 除 done 外，每次调用 handoff_sync_status 时都必须传入 paused: true。这可防止自主 Handoff Agent 在你手动工作期间接手任务。只有 done 才传入 paused: false。

重写计划入口文件时，保留第一行的 `` 注释。

Step 0：加载项目上下文

首先： 如果 .ai-factory/config.yaml 存在，请读取它以确定：

• 命令默认值： workflow.plan_mode（默认为 ask；允许值：ask、fast、full、ultra）。未设置时使用 ask；值或类型无效时，发出 WARN [config] invalid workflow.plan_mode; falling back to ask 并使用 ask。
• 路径： paths.description、paths.architecture、paths.roadmap、paths.research、paths.rules_file、paths.plan、paths.plans、paths.patches、paths.evolutions、paths.specs、paths.rules 和 paths.archive
  • 为可选的 ultra 研究包派生 research_bundles_dir = <parent directory of paths.research>/research/。无需添加额外的配置键。
• 语言： language.ui 用于 AskUserQuestion 提示词，language.artifacts 用于生成的计划文件，language.technical_terms 用于计划产物中面向用户的技术术语
• Git： git.enabled、git.base_branch、git.create_branches 和 git.branch_prefix
• 工作流： workflow.plan_id_format — 控制 full/ultra 计划标识符的格式。允许值：slug（默认值）、timestamp、uuid、sequential。只有 slug 和 sequential 当前生效；timestamp 和 uuid 为 保留值，目前的行为与 slug 相同（并记录一条 INFO 日志）。sequential 值会将 full 计划写入 <NNNN>_<plan_file_stem>.md，并将 ultra 包写入 <NNNN>_<plan_file_stem>/index.md（参见步骤 1.2 中的标准文件名主体和算法）。任何未知值均视为 slug，并发出 WARN [aif-plan] unknown workflow.plan_id_format=<value>; falling back to slug。

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

• 路径：所有产物均使用 .ai-factory/
• ui_language：en
• artifact_language：en
• technical_terms_policy：keep
• Git：enabled: true、base_branch: main、create_branches: true、branch_prefix: feature/
• 工作流：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 下生成的计划产物必须使用 artifact_language 编写。 对于 ultra，这同样适用于 index.md 和所有链接的阶段文件。

模板和示例定义的是结构，而非固定的英文输出。如果 artifact_language 不是 en，保存前应翻译面向用户的标题、标签、任务说明、路线图依据、研究摘要、设置说明和依赖说明。保留 Markdown 结构、复选框语法、任务 ID、分支名称、提交消息、命令、文件路径、配置键、包名称、API 名称、WARN/INFO 标签、原始错误，以及完全不变的 ultra 标记 ``。## Research Context、Source:、Active Summary、Updated: 和 SHA256: 必须保持原样，因为下游研究偏移检查会将它们解析为兼容性标记。## Requirements Reconciliation 必须保持原样，因为下游工作流检查会将其解析为兼容性标记。其他面向用户的术语按 technical_terms_policy 处理。

例外：## Original Request 的章节标题和正文是固定的原始来源结构，不得翻译、总结、规范化或改写。

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

• 技术栈（语言、框架、数据库、ORM）
• 项目架构
• 编码规范
• 非功能性需求

还要： 如果解析后的架构产物存在，则读取该文件（paths.architecture，默认值：.ai-factory/ARCHITECTURE.md）以了解：

• 选定的架构模式
• 文件夹结构规范
• 层/模块边界
• 依赖规则

在以下情况中使用这些上下文：

• 探索代码库（了解需要查找哪些模式）
• 编写任务描述（使用正确的技术）
• 规划文件结构（遵循项目约定）
• 规划文件结构和任务组织时，遵循已解析架构文档中的架构指南

**此外：**如果存在已解析的规则层级，也要阅读：

1. paths.rules_file — 项目级公理
2. rules.base — 项目基础约定
3. 与请求工作相关的命名 rules.<area> 条目

将明确规则视为权威要求。范围更具体的领域规则优先于基础规则，基础规则优先于项目级公理。

阅读 .ai-factory/skill-context/aif-plan/SKILL.md — 如果该文件存在，则为强制要求。

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

如何应用 skill-context 规则：

• 将其视为此技能通用说明的项目级覆盖规则
• 当 skill-context 规则与本 SKILL.md 中编写的通用规则冲突时， 以 skill-context 规则为准（更具体的上下文优先，同嵌套 CLAUDE.md 文件的原则）
• 若无冲突，则同时应用：SKILL.md 中的通用规则 + 项目规则
• 即使 skill-context 规则看似与此技能的默认规则矛盾，也不要忽略它们 — 这些规则之所以存在，是因为项目经验已证明默认规则并不充分
• 关键：skill-context 规则适用于此技能的所有输出 — 包括 PLAN.md 模板、超大合并包和任务格式。TASK-FORMAT.md 和 ULTRA-FORMAT.md 中的模板是基础结构。如果 skill-context 规则要求“任务必须包含 X”或“计划必须有章节 Y”，则必须相应扩展模板。 生成违反 skill-context 规则的计划属于错误。

**执行要求：**生成任何输出文档后，依据所有 skill-context 规则进行验证。 如有任何规则未得到遵循 — 在向用户展示之前修正输出。

**可选（建议）：**如果已解析的路线图文档存在，则阅读它（paths.roadmap，默认：.ai-factory/ROADMAP.md）：

• 在适用时，将此计划关联到特定里程碑
• 这样可以减少 /aif-implement 里程碑完成和 /aif-verify 路线图检查中的歧义

**可选（建议）：**最多解析一个相关研究来源：

• 旧版来源是已配置的 paths.research 文件。
• ultra 来源是 research_bundles_dir/<english-slug>/RESEARCH.md，但只有当同级的 INDEX.md 中恰好包含 `` 一次，且其中的 ## Artifact Index 链接到该 RESEARCH.md 时才算。不要把任意目录都视为研究资料包。
• 用户提供了主题或请求时，来源优先级为：明确引用的资料包／文件；然后是一个主题明确匹配且标记为 Status: active 的资料包；最后是相关的旧版文件。明确来源是请求或后续消息中指定的具体 RESEARCH.md 或资料包路径；它属于用户内容，不是被剥离的命令令牌。
• 按以下顺序解析主题匹配：精确匹配英文 slug；然后匹配规范化后的 Topic:；最后根据 Purpose／Active Summary 进行唯一的语义匹配。绝不能按时间新旧选择。如果无法明确确定唯一匹配项，或多个来源会改变范围，应先询问，不要合并或猜测。明确引用了 paused 或 superseded 资料包时，使用前必须先警告。
• 先读取 ultra INDEX.md，再读取其链接的 RESEARCH.md。只有在本计划需要相关依据时，才读取 C4／ADR／依赖项资料。它们不是独立的需求来源；实质性结论必须已反映在 Active Summary 中。
• 将选定文件存储为 selected_research_path。将其 ## Active Summary (input for /aif-plan) 视为额外的需求来源。
• 将约束／决策纳入任务和计划设置。
• 优先采用摘要，而非原始笔记；只有需要更深入的依据时，才查看 ## Sessions 和链接的可选资料。
• 无描述回退是基于主题的优先级规则中为向后兼容而有意设置的例外：如果已配置的 paths.research 中有 Active Summary 主题，则使用它。否则，使用一个标记为 active 的 ultra 资料包；如果有多个 active 资料包，应询问用户选择，不要猜测。
• 跟踪研究内容是否影响了本计划。只有当 Active Summary 提供了默认描述，或者研究资料中的约束、决策、目标、未决问题或会话依据影响了计划范围、任务、设置或权衡时，才设置 research_influenced_plan = true。如果研究资料存在但已过时，或与用户请求的任务无关，则设置 research_influenced_plan = false，忽略其中的计划需求，且不要添加 ## Research Context。
• 只要有任何研究内容影响了计划，生成的计划就必须包含 ## Research Context，并带有规范元数据 Source: `<selected_research_path>` (Active Summary, Updated: <timestamp>, SHA256: <digest>)。遗漏这份由计划保存的研究副本属于错误，因为下游技能会将嵌入的 Research Context 视为权威需求，并仅使用来源研究文件检查偏差。
• 计算哈希前，先规范化复制的 Active Summary：仅包含 Source: 行之后将粘贴到 ## Research Context 下的文本；删除 HTML 注释块；保留行顺序和行首空白；删除每行末尾的空格；使用 LF 换行；并且恰好以一个换行符结尾。计算摘要时，不要写入任何临时文件或仓库文件：通过 stdin／内联 shell 输入将规范化文本传给 shasum -a 256；如果 shasum 不可用，则将相同的规范化文本传给 sha256sum。使用输出的第一个字段作为 SHA256: 值。

步骤 0.1：解析 Git 状态

不要自动运行 git init。

先根据配置解析当前 Git 模式：

• git.enabled: true → 允许使用 Git 感知型工作流
• git.enabled: false → 仅使用无 Git 工作流
• git.base_branch → 用作差异比较／合并指导的目标分支（默认值：检测到的分支或 main）
• git.create_branches: true → full／ultra 模式可以创建分支／工作树
• git.create_branches: false → full／ultra 模式仍会创建计划文件，但会留在当前分支／仓库状态

如果 git.enabled = false：

• 跳过所有分支／工作树命令
• 将完整计划保存到 paths.plans/<slug>.md，将 ultra 计划包保存到 paths.plans/<slug>/index.md
• 将 --parallel、--list 和 --cleanup 视为不可用

如果 git.enabled = true，但仓库实际并不位于 Git 工作树中：

• 提醒用户：在仓库初始化之前，Git 感知型操作不可用
• 回退到上述相同的无 Git 行为

步骤 0.2：解析参数并选择模式

从 $ARGUMENTS 中提取标志和模式：

--parallel  → Enable parallel worktree mode (full/ultra only; requires `git.enabled=true` and `git.create_branches=true`)
--list      → Show all active worktrees, then STOP (git-only)
--cleanup <branch> → Remove worktree and optionally delete branch, then STOP (git-only)
fast        → Fast mode (first word)
full        → Full mode (first word)
ultra       → Ultra mode (first word)

解析规则：

• 仅从 $ARGUMENTS 的命令位置移除已识别的命令标记：
  • 仅当 fast、full 或 ultra 用作开头的模式标记时才移除
  • 已识别的控制标志 --parallel、--list 和 --cleanup <branch>
  • 不要移除用户实际请求文本中出现的匹配词
• 剩余文本作为描述
• 单独解析已配置的默认值；绝不要将它们添加到 $ARGUMENTS 前面，也不要包含在 original_user_request 中。
• 如果剩余文本非空，将其保留为 original_user_request：仅去除命令解析引入的首尾空白，但须原样保留内部空白、换行、措辞、大小写和标点。这是用户原始的计划请求，之后必须保存到计划入口文件中。
• --list 和 --cleanup 会立即执行并停止（不要继续执行步骤 1 及后续步骤）
• 如果 git.enabled = false，用简短说明拒绝 --parallel、--list 和 --cleanup，不要尝试运行 Git 命令
• 如果设置了 --parallel，但 git.create_branches = false，由于并行模式需要创建分支，请用简短说明拒绝该操作

如果存在 --list，跳转到 --list 子命令。 如果存在 --cleanup，跳转到 --cleanup 子命令。

模式选择（仅解析一次，且独立于描述）：

• 显式指定的开头 fast、full 或 ultra 标记优先于配置。
• 否则，workflow.plan_mode: fast|full|ultra 会选择相应模式，不询问模式选择问题。关于 full／ultra 的偏好问题和 Git 限制仍然适用。
• 否则（配置为 ask、缺失或无效），在非交互式 Handoff 模式下使用 fast；在交互式会话中，仅在下方询问 full 或 fast。
• Ultra 只能由用户明确选择。通过开头的 ultra 标记或 workflow.plan_mode: ultra 选择；绝不要根据任务复杂度推断。
• 将选定模式存储为 resolved_mode。以下的描述解析不得重新开启模式选择，也不得更改 resolved_mode。
• 无论配置的模式如何，--list 和 --cleanup 都保持提前返回的行为。

仅当未提供显式模式、配置的偏好解析为 ask，且会话处于交互式状态时，才询问此问题：

AskUserQuestion: Which planning mode?

Options:
1. Full (Recommended) — richer plan, asks preferences, optional branch/worktree flow when git settings allow it
2. Fast – quick plan, no branch, saves to the resolved fast plan path

如果描述为空：

• 如果配置的 paths.research 文件存在，且其 Active Summary 中的 Topic: 非空，则默认将该主题作为描述（无需用户额外输入），将其设为 selected_research_path，并将 original_user_request 留空。
• 否则，如果恰好存在一个标记为 active 的 ultra bundle，且其关联的 RESEARCH.md 中 Topic: 非空，则使用该主题和文件。如果存在多个标记为 active 的 bundle，则请用户选择主题/来源。
• 当研究内容提供描述时，提及所选 Active Summary 主题，并继续使用 resolved_mode，包括已配置的 ultra 模式，不再询问模式，也不再提示用户提供描述。
• 根据所选 RESEARCH.md 创建的计划，如果没有明确的用户请求，则不得包含 Original Request 部分。
• 否则，请用户简要描述功能。将用户的回答原样保留为 original_user_request，并在之后保存到计划入口文件中。

原始请求约定：

• 如果用户明确提供了计划请求（例如 /aif-plan ТУТ ЗАПРОС НА ПЛАН、/aif-plan full ТУТ ЗАПРОС НА ПЛАН、/aif-plan ultra ТУТ ЗАПРОС НА ПЛАН，或对描述提示的回答），生成的计划入口文件 MUST 包含 ## Original Request。
• ## Original Request 包含用户提供的确切请求文本，仅移除已识别的命令标记并去除外围空白。不得改写、总结、翻译或规范化其措辞，即使 artifact_language 不同也不例外。
• 如果描述仅源自所选 RESEARCH.md，且用户没有提供请求，则省略 ## Original Request；已提交的来源改为 ## Research Context。
• 如果用户提供了请求，且所选研究内容也影响了计划，则同时包含 ## Original Request 和 ## Research Context。

有关具体的解析示例和各命令形式对应的预期行为，请阅读 references/EXAMPLES.md（参数解析）。

---

完整与 Ultra 模式

步骤 1：解析描述并侦察

从描述中提取：

• 要添加的核心功能
• 关键领域术语
• 类型（功能、增强、修复、重构）

使用 Task 工具，并设置 subagent_type: Explore，以了解代码库中的相关部分。 这会作为子 Agent 运行，保持主上下文整洁。

根据解析后的描述，并行启动 1–2 个 Explore Agent：

Task(subagent_type: Explore, model: sonnet, prompt:
  "In [project root], find files and modules related to [feature domain keywords].
   Report: key directories, relevant files, existing patterns, integration points.
   Thoroughness: quick. Be concise — return a structured summary, not file contents.")

规则：

• Full：最多 1–2 个 Agent，采用“快速”详尽度——这是侦察，而非深入分析
• Ultra：条件允许时启动 2–3 个有明确侧重点的 Agent；覆盖架构、现有模式、集成/副作用以及测试/运维方面。这些侦察结果将为 ULTRA-FORMAT.md 所要求的深入证据提供基础。
• 深入探索将在之后的步骤 3 中进行
• 如果 .ai-factory/DESCRIPTION.md 已提供足够的上下文，则可跳过此步骤

步骤 1.2：生成 Full/Ultra 计划标识符

此步骤会生成两个不同的值：

• branch_name——Git 分支（仅当 git.enabled = true 且 git.create_branches = true 时）
• plan_file_stem——<configured plans dir>/ 下规范的、无前缀计划文件名干体
• plan_identifier——带可选 NNNN_ 前缀的 plan_file_stem；它将成为完整计划的文件名干体或 ultra 目录名

这些值按固定顺序推导，以确保此处的生成方与 /aif-implement / /aif-improve / /aif-verify / /aif-rules-check 中基于分支的使用方始终能一致地确定完整计划文件或 ultra 入口文件。

1.2.a — 确定规范的 plan_file_stem

选择第一个匹配的情况：

1. HANDOFF_BRANCH_PREPARED = 1 → 将 HANDOFF_BRANCH_NAME 中的每个 / 替换为 -，并赋值给 plan_file_stem。完全跳过 slug 生成。此处不创建 branch_name（分支由 Handoff 管理）。
2. git.enabled = true 且 git.create_branches = true → 生成描述性 slug，然后将 branch_name 设为 <git.branch_prefix><slug>（默认前缀：feature/）。将 branch_name 中的每个 / 替换为 -，并赋值给 plan_file_stem（例如 feature-user-authentication）。
3. 其他情况（git.enabled = false 或 git.create_branches = false）→ 将 <description slug> 赋值给 plan_file_stem。不创建 branch_name。

Slug 规则（情况 2 和 3）：

• 全部小写，以连字符分隔，最多 50 个字符
• 除连字符外，不含特殊字符
• 描述清晰但简洁

分支示例（情况 2）：

• feature/user-authentication
• fix/cart-total-calculation
• refactor/api-error-handling
• chore/upgrade-dependencies

不变量： 基于分支的消费型技能会将 current-branch-with-slashes-replaced 作为查找 stem。上述情况 1 和 2 已符合这一规则。情况 3 不会有分支，因此消费方会回退到 <configured plans dir>/ 中唯一的完整版/超精简版计划产物（见 aif-implement Step 0.2）。生成不符合这些规则的 plan_file_stem 会导致发现失败。

1.2.b — 应用 workflow.plan_id_format 前缀

默认：无前缀。将 plan_file_stem 赋值给 plan_identifier。完整模式写入 <configured plans dir>/<plan_identifier>.md；超精简模式写入 <configured plans dir>/<plan_identifier>/index.md。

按格式处理：

• slug（默认）→ 无前缀。
• timestamp / uuid → 保留值；暂按 slug 处理。 输出 INFO [aif-plan] workflow.plan_id_format=<value> is reserved and behaves like slug; numbering is not applied。不要自行设定 stem 格式——基于分支的消费方不知道如何发现非 sequential 前缀。
• 未知值 → 已在 Step 0 中处理：输出 WARN [aif-plan] unknown workflow.plan_id_format=<value>; falling back to slug。此处按 slug 处理。
• sequential → 将 1.2.c 中的算法应用于 plan_file_stem，生成 plan_identifier。

当 HANDOFF_BRANCH_PREPARED = 1 时，强制禁用 sequential。此时保留原样的 plan_file_stem，并输出 INFO [aif-plan] sequential numbering disabled under HANDOFF_BRANCH_PREPARED=1。

1.2.c — 顺序编号算法

在 plan_file_stem 前加上 4 位数字前缀，生成 plan_identifier。根据 <configured plans dir> 中现有的编号完整计划文件，以及 index.md 包含精确 ultra 标记的编号目录，计算该前缀。分支名称（如果存在）保持不变， 以免影响现有的 git 工具、CI 和 PR 约定。

1. Find existing numbered plans in <configured plans dir>:
     Glob A: <configured plans dir>/[0-9][0-9][0-9][0-9]_*.md
     Glob B: <configured plans dir>/[0-9][0-9][0-9][0-9]_*/index.md
2. Every Glob A match is a numbered full-plan candidate.
   For every Glob B match, Read index.md and keep it only when it contains the
   exact marker . Ignore numbered directories whose
   index.md lacks the marker; they are not plans and cannot consume an ID.
3. Parse the leading 4 digits from each retained full-plan filename or marked
   ultra directory
   basename into an integer. Deduplicate equal prefixes.
   Filter out entries whose relevant basename does not match
   ^[0-9]{4}_.+(\.md)?$.
4. If any matches exist:
     max_existing = max(prefixes)
     If max_existing >= 9999:
       ABORT with error:
         "sequential cap reached: a plan numbered 9999 already exists in <configured plans dir>."
         "Switch workflow.plan_id_format back to slug, or move the 9999-numbered file out of the directory (note: doing so will free 9999 for the next plan to reuse)."
     next = max_existing + 1
   Else:
     next = 1
5. prefix = zero-padded 4-digit string of next   (e.g. 1 → "0001", 42 → "0042")
6. Set plan_identifier = <prefix>_<plan_file_stem>
7. Final artifact:
     full  → <configured plans dir>/<plan_identifier>.md
     ultra → <configured plans dir>/<plan_identifier>/index.md

实现说明：

• 使用 Glob 枚举候选项，并使用 Read 验证每个编号 ultra 候选项的标记。 不要通过 shell 调用 ls——aif-plan 的 frontmatter 未授予 Bash(ls *) 权限，因此 ls 路径在生产环境中会失败。
• 4 位 [0-9][0-9][0-9][0-9] glob 严格遵循约定：格式仅支持 0001～9999。第 4 步中的错误会对此进行强制限制。
• --parallel 的适用范围（简而言之——限定于源工作树）：
  • **计算前缀的位置：**源工作树的 <configured plans dir> （即调用 /aif-plan 的仓库）——也就是第 1.2.c 步。
  • **计算时间：**在第 1.4 步中可选的 cd <WORKTREE> 之前。
  • **写入计划产物的位置：**目标工作树中相同的相对完整文件或 ultra 目录路径，以确保前缀和目标目录保持一致。
  • **绝对不能做的事：**切换到 <WORKTREE> 后，切勿根据目标工作树的 plans dir 重新计算前缀。目标目录通常为空，每次并行运行都会重新分配 0001，从而破坏合并时的跨工作树编号约定。

规则：

• 编号根据 <configured plans dir> 中现有的完整计划文件和带标记的 ultra 目录生成。未标记的编号目录会被忽略。将编号计划从该目录中删除或移出，可以在下次运行时释放该编号供重新使用——如果依赖稳定的交叉引用，请将计划保留在原处。
• **归档的计划不参与编号。**通过 /aif-archive 移至 paths.archive/plans/ 的计划不在 <configured plans dir> 中，因此不会计入。归档编号最高的计划后，该编号可重新使用。
• 编号有上限——9999 是硬性上限；算法会报错，而不会写入 10000_…，以免使用同样 4 位编号的使用方 glob 超出约定范围。
• 前缀仅用于完整计划文件名或 ultra 目录。git 分支（如存在）保持为 <branch_prefix><slug>，不带编号。
• 此设置不适用于快速计划（paths.plan 是单个文件）和修复计划（paths.fix_plan 是单个文件）。

日志：INFO [aif-plan] resolved plan artifact: <path> (mode=<mode>, format=<value>)。

第 1.3 步：询问用户偏好

重要：继续之前务必询问用户：

AskUserQuestion: Before we start, a few questions:

1. Should I write tests for this feature?
   a. Yes, write tests
   b. No, skip tests

2. Logging level for implementation:
   a. Verbose (recommended) - detailed DEBUG logs for development
   b. Standard - INFO level, key events only
   c. Minimal - only WARN/ERROR

3. Documentation policy after implementation?
   a. Yes — mandatory docs checkpoint at completion (recommended)
   b. No — warn-only (`WARN [docs]`), no mandatory checkpoint

4. Roadmap milestone linkage (only if the resolved roadmap artifact exists):
   a. Link this plan to a milestone
   b. Skip — no linkage (allowed; `/aif-verify --strict` should report WARN, not fail, for missing linkage alone)

5. Any specific requirements or constraints?

默认使用详细日志。 AI 生成的代码会因详尽的日志而受益匪浅，原因如下：

• 细微错误很常见，没有日志时很难追踪
• 用户之后随时可以删除日志
• 开发期间缺少日志会浪费调试时间

保存所有偏好——这些偏好将在计划入口点中使用，并传递给 /aif-implement。

文档策略语义：

• Docs: yes → /aif-implement 必须显示必需的文档检查点，并通过 /aif-docs 处理文档变更
• Docs: no（或未设置）→ /aif-implement 发出 WARN [docs]，并在没有必需文档检查点的情况下继续

如果已解析的路线图产物存在，且用户选择关联里程碑：

• 读取已解析的路线图产物，并列出候选里程碑（优先选择未勾选的项目）
• 请用户选择一个里程碑（或输入自定义内容）
• 将选定的里程碑名称及一条说明将其纳入计划入口点的理由保存下来

步骤 1.4：可选的分支 / 工作树设置

如果 HANDOFF_BRANCH_PREPARED = 1（分支由 Handoff 管理）：

• 跳过整个步骤。分支验证已在步骤 0 中完成。
• 计划产物路径使用 HANDOFF_BRANCH_NAME（将斜杠替换为 -）作为名称主体。
• 不要运行 git checkout、git pull、git checkout -b 或 git worktree add。
• 将 --parallel 视为已禁用：不要创建工作树，也不要自动调用 /aif-implement。

如果 git.enabled = false 或 git.create_branches = false：

• 跳过所有分支 / 工作树创建操作
• 继续使用 paths.plans 下生成的完整文件或 ultra 目录

如果设置了 --parallel 标志 → 创建工作树：

顺序前缀已锁定。 步骤 1.2.c 已在此步骤之前，根据源工作树的 <configured plans dir> 计算出 NNNN_ 前缀。 执行 cd <WORKTREE> 后不要重新计算 — 目标工作树的计划目录 通常为空，重新计算会重新分配 0001，导致合并时违反 编号约定。

创建工作树

DIRNAME=$(basename "$(pwd)")
git branch <branch-name> <configured-base-branch>
git worktree add ../${DIRNAME}-<branch-name-with-hyphens> <branch-name>

转换分支名称以用作目录名：将 / 替换为 -。

示例：

Project dir: my-project
Branch: feature/user-auth
Worktree: ../my-project-feature-user-auth

复制上下文文件，使工作树拥有完整的 AI 上下文：

• 在工作树中为解析后的 DESCRIPTION、ARCHITECTURE、RESEARCH、计划、补丁和演进路径创建父目录。
• 将解析后的 DESCRIPTION、ARCHITECTURE 和 RESEARCH 产物复制到工作树中相同的已配置相对位置。
• 将 .ai-factory/skill-context/ 原样复制到工作树中。
• 仅将解析后的 paths.patches 目录中最新的 10 个补丁文件复制到工作树中相同的已配置相对路径。
• 如果只复制了截断后的补丁集，不要复制 patch-cursor.json；该游标仅适用于完整的补丁历史。
• 存在时，复制 Agent 设置（例如 .claude/）和未跟踪的 CLAUDE.md。

创建变更目录并切换：

cd "${WORKTREE}"

显示确认信息：

Parallel worktree created!

  Branch:    <branch-name>
  Directory: <worktree-path>

To manage worktrees later:
  /aif-plan --list
  /aif-plan --cleanup <branch-name>

继续执行步骤 2。

如果没有 --parallel → 正常创建分支：

git checkout <configured-base-branch>
git pull origin <configured-base-branch>
git checkout -b <branch-name>

如果分支已存在，询问用户：

• 切换到现有分支？
• 使用不同的名称创建？

---

Ultra 模式详细要求

Ultra 使用完整模式的偏好设置和上面的可选分支 / 工作树设置， 然后应用更严格的规划门槛：

1. 完整阅读 references/ULTRA-FORMAT.md。
2. 解决所有原本需要由实现者自行推断的跨领域决策：适用时包括文件放置位置、公共接口、数据 / 控制流、兼容性、迁移、故障行为、可观测性、测试、文档和发布安排。
3. 按依赖顺序将工作划分为多个阶段。每个阶段都必须是连贯的实施检查点，而不只是一个类别标题。
4. 每个阶段创建一个 Markdown 文件。每个任务部分都必须满足 ULTRA-FORMAT.md 中的 Required Detail Gate。
5. 阶段内容稳定后，最后创建 index.md，确保其中的 Phase Index、任务链接、依赖关系和提交分组与各阶段文件完全一致。
6. 在呈现计划之前，运行 ULTRA-FORMAT.md 中的 bundle 完整性检查。修复失效链接、缺失 / 重复的任务 ID、孤立阶段文件和不一致的依赖关系。

Ultra 不得将重要的实现决策留给较小的模型。 如果证据不足以安全地做出决策，应在 index.md 中记录一个阻塞性开放问题，并将计划标记为尚未达到可实施状态后停止，而不是用含糊的指示掩盖问题。

---

快速模式

步骤 1：询问偏好

提出一组较简短的问题：

AskUserQuestion: Before we start:

1. Should I include tests in the plan?
   a. Yes, include tests
   b. No, skip tests

2. Any specific requirements or constraints?

3. Roadmap milestone linkage (only if the resolved roadmap artifact exists):
   a. Link this plan to a milestone
   b. Skip — no linkage (allowed; `/aif-verify --strict` should report WARN, not fail, for missing linkage alone)

计划文件： 始终使用解析后的 paths.plan 文件（默认值：.ai-factory/PLAN.md）。

---

共享步骤（所有模式）

步骤 2：分析需求

根据描述，确定：

• 要实现的核心功能
• 需要修改的组件 / 文件
• 任务之间的依赖关系
• 需要处理的边缘情况

如果需求含糊不清，请提出澄清问题：

I need a few clarifications before creating the plan:
1. [Specific question about scope]
2. [Question about approach]

需求核对关卡

对于受现有需求约束的工作，在探索实现方案之前先核对需求：

1. 将路线图条目和任务摘要视为范围指示，而非详细的行为契约，除非项目明确另有规定。
2. 遵循用户或项目上下文声明的来源优先级。如果没有优先级规则，不要擅自从冲突来源中作出选择。
3. 记录每条重要行为规则及其来源路径／章节。若两个来源重叠，说明它们一致、一个细化了另一个，还是彼此冲突。若尚未解决的冲突会改变实现：
   • 手动模式 → 询问用户并停止；
   • HANDOFF_MODE=1 → 不要询问。输出 ERROR [requirement-conflict]，返回 handoff_outcome: blocked_external，并在发布内容或发出 plan_ready 信号前停止。
4. 制定计划时不要编辑源需求。报告过时或相互矛盾的文档，并将其交由相应的负责人命令或用户处理。

当行为取决于两个或更多独立的选择器、状态、模式或输入形态时，在编写任务之前枚举受支持的组合。仅涵盖需求允许的组合，不要臆造笛卡尔积。对于每个重要组合，说明：

• 接受的输入和验证；
• 持久化状态；
• 返回的输出或后续转换；
• 副作用和不变量；
• 一个验证场景。如果启用了测试，就将其作为测试；否则，提供可运行／手动验证步骤，不要额外添加测试任务。

当仓库数据、配置、固定样本、架构或内容定义了实际契约时，在端到端验证路径中至少包含一个有代表性的现有文档，而不是只验证合成的固定样本。

如果多个权威来源对工作有重要约束、冲突已解决、存在独立的行为维度，或需要有代表性的真实文档，则在计划入口添加确切的 ## Requirements Reconciliation 章节。保持简洁：说明声明的权威来源、引用的决策、适用的组合表格和验证证据。对于不符合上述任何条件的简单工作，省略此章节。

第 3 步：探索代码库

制定计划前，通过并行探索了解现有代码。

使用 Task 工具并设置 subagent_type: Explore，并行调查代码库。 这样可以保持主上下文清晰，并加快调研速度。

同时启动 2–3 个 Explore Agent，每个 Agent 聚焦不同方面：

Agent 1 — Architecture & affected modules:
Task(subagent_type: Explore, model: sonnet, prompt:
  "Find files and modules related to [feature domain]. Map the directory structure,
   key entry points, and how modules interact. Thoroughness: medium.")

Agent 2 — Existing patterns & conventions:
Task(subagent_type: Explore, model: sonnet, prompt:
  "Find examples of similar functionality already implemented in the project.
   Show patterns for [relevant patterns: API endpoints, services, models, etc.].
   Thoroughness: medium.")

Agent 3 — Dependencies & integration points (if needed):
Task(subagent_type: Explore, model: sonnet, prompt:
  "Find all files that import/use [module/service]. Identify integration points
   and potential side effects of changes. Thoroughness: medium.")

如果第 1 步的完整／超强模式已完成代码库侦察，就以其结果为起点。让 Explore Agent 聚焦于需要深入了解的领域。

对于超强模式，继续探索，直到计划的每个阶段都有代码级证据，涵盖：

• 相关的现有路径和符号
• 调用方／使用方及副作用
• 确切的集成点和配置点
• 现有的测试、固定样本、命令、日志记录、迁移和文档模式

不要在阶段计划中粘贴整个源文件；只引用足以让实现步骤明确无歧义的证据。

Agent 返回后，综合整理：

• 需要创建／修改哪些文件
• 应遵循哪些模式（依据现有代码）
• 组件之间的依赖关系
• 潜在风险或边缘情况

后备方案： 如果 Task 工具不可用，直接使用 Glob／Grep／Read。

第 4 步：创建任务计划

使用 TaskCreate 创建清晰、可执行的任务。

任务指南：

• 每项任务都应能在一次专注的工作时段内完成
• 按依赖关系对任务排序（先做 X，再做 Y）
• 标明要修改的文件路径
• 明确说明要实现什么，不要含糊其辞
• 在 ultra 模式下，TaskCreate 的描述应简洁，但要包含对应阶段的文件链接；上下文重置后，任务包仍是详细内容的可靠来源

使用 TaskUpdate 设置 blockedBy 关系：

• 如果任务 2 依赖任务 1 的输出，则将任务 2 设置为被任务 1 阻塞
• 保持依赖链逻辑清晰

第 5 步：保存计划文件

**确定计划文件路径：**这些值已在第 1.2 步中解析。

• Fast 模式 → 已解析的 paths.plan。
• Full 模式 → <configured plans dir>/<plan_identifier>.md。
• Ultra 模式 → <configured plans dir>/<plan_identifier>/index.md，以及同一目录中的 phase-NN-<slug>.md 文件。
• 对于 slug、保留字 timestamp / uuid，或由 Handoff 准备的分支，plan_identifier = plan_file_stem。
• 对于启用的 sequential，plan_identifier = <NNNN>_<plan_file_stem>。

plan_file_stem 始终是第 1.2.a 步中的规范 stem（依次采用 Handoff 分支 / git 分支 / 描述 slug）。基于分支的使用方在查找时会生成相同的 stem，因此生成方不得偏离。

在写入任何未添加前缀的 full/ultra 目标（默认/保留 slug 行为或由 Handoff 准备的分支）之前，检查是否存在具有相同 stem 的同级表示：<plan_identifier>.md 与 <plan_identifier>/index.md。如果任一文件已存在，请勿悄悄创建第二个活动表示或覆盖现有文件。请用户完善现有计划、选择其他标识符，或明确要求替换。

保存前，确保目录存在：

mkdir -p <configured plans dir>

对于 ultra，还应在写入文件前创建已解析的任务包目录。

Full/fast 计划文件或 ultra 的 index.md 必须包含：

• 仅适用于 ultra：在 index.md 顶部附近（紧接可选的首行 Handoff 注释之后）准确包含一次机器可读标记。切勿翻译、改写或省略此标记。使用方通过此标记识别任务包，而不是通过 Mode 等本地化的人类可读标签。
• 含功能名称的标题
• 分支和创建日期
• Original Request 部分（用户明确提供计划请求时为必需；若计划仅根据 RESEARCH.md 创建，则省略）
• Settings 部分（Testing、Logging、Docs）
• Roadmap Linkage 部分（可选，仅当已解析的路线图文件存在时）
• Research Context 部分（可选，仅当研究内容影响了此计划时）
• Requirements Reconciliation 部分（条件性要求，遵循第 2 步中的门控条件）
• 按阶段分组的 Tasks 部分；在 ultra 模式下，这是唯一的任务复选框来源
• 任务数达到 5 项或以上时，添加 Commit Plan 部分

如果 original_user_request 非空：

• 在 ## Settings 之前写入 ## Original Request
• 保留用户提供的原始请求文本，仅移除已识别的命令标记并裁剪首尾空白
• 不要翻译保存的请求；它是原始输入，而不是生成的文件文案

如果已解析的路线图文件存在：

• 如果用户关联了里程碑，则写入 ## Roadmap Linkage，并包含 Milestone: "..." 和 Rationale: ...
• 如果用户跳过了关联，则写入 ## Roadmap Linkage，并包含 Milestone: "none" 和 Rationale: "Skipped by user"

如果研究内容影响了此计划：

• 通过仅复制 Active Summary（不要粘贴完整的 Sessions）来包含 ## Research Context
• 包含 Source: `<selected_research_path>` (Active Summary, Updated: <research Updated timestamp>, SHA256: <sha256 of copied Active Summary>)，以便 /aif-implement、/aif-verify、/aif-improve 和相关使用方了解确切提交的研究版本
• 按照 Step 0 中的说明，从规范化后的复制内容 Active Summary 计算哈希：移除 HTML 注释块，保留行顺序和行首空白，删除每行末尾的空格，使用 LF 换行，并且末尾恰好保留一个换行符。通过 stdin / 内联 shell 输入将规范化文本传递给 shasum -a 256 或 sha256sum，绝不要使用临时文件，并复制第一个输出字段。
• 将复制的 Research Context 视为计划拥有的权威需求副本。之后对所选 RESEARCH.md 的更改不得覆盖这些需求，除非明确警告存在偏差，且用户要求重新定基或细化。
• 保持精简；内容应当能作为一屏可读的需求摘要

如果研究内容存在，但未影响此计划，则不要包含 ## Research Context。如果存在主题 A 的 RESEARCH.md，而 /aif-plan 明确请求的是无关主题 B，则必须为主题 B 生成未关联研究的计划。

fast/full 模式使用 references/TASK-FORMAT.md 中的规范模板。 ultra 模式使用 references/ULTRA-FORMAT.md，并在完成前核验每个 Phase Index 链接、任务映射、依赖项和阶段文件。

规范模板仅定义必需的章节和顺序。写入文件前，使用 artifact_language 呈现所有面向人的计划内容，应用 technical_terms_policy，并按照 Step 0 中的说明保留稳定标记。

计划提交规则：

• 5 个或更多任务 → 每 3–5 个任务添加提交检查点
• 少于 5 个任务 → 在最后一次性提交，无需制定提交计划
• 将逻辑相关的任务归为一次提交
• 按照 conventional commits 规范，建议有意义的提交消息

第 6 步：后续步骤

Full/ultra 模式 + 并行（--parallel）： 自动调用 /aif-implement——并行模式的核心就是在隔离的 worktree 中自主完成端到端执行。如果 HANDOFF_BRANCH_PREPARED = 1，则视为已禁用 --parallel，不得自动调用 /aif-implement。

/aif-implement

CONTEXT FROM /aif-plan:
- Plan artifact: <resolved plan file or ultra directory>      # see Step 1.2 / Step 5
- Testing: yes/no
- Logging: verbose/standard/minimal
- Docs: yes/no  # yes => mandatory docs checkpoint, no => warn-only

Full/ultra 普通模式： 规划后停止。用户审核计划，并自行决定何时实施。

以下后续步骤模板仅定义结构。在这些面向用户的回复中，使用 ui_language 呈现所有面向人的文本。保持命令名称、已配置路径、任务数量和 TaskList 引用不变。

Plan created with [N] tasks.
Plan artifact: <resolved plan file or ultra directory>

To start implementation, run:
/aif-implement

To view tasks:
/tasks (or use TaskList)

Fast 模式： 规划后停止。

Plan created with [N] tasks.
Plan file: <resolved fast plan path>

To start implementation, run:
/aif-implement

To view tasks:
/tasks (or use TaskList)

上下文清理

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

---

--list 子命令

传入 --list 时，显示所有活动 worktree 及其功能状态。然后停止。

git worktree list

对于每个 worktree 路径：

1. 检查该 worktree 下是否存在已解析的计划目录（<worktree>/<resolved paths.plans>，默认值：<worktree>/.ai-factory/plans/），以及该目录是否包含任何根目录 *.md 计划或直接子目录中的 */index.md 入口文件，其中包含 ``
2. 显示名称，并注明其是否看起来已完成（包含任务）或仍在进行中

输出格式：

Active worktrees:

  /path/to/my-project          (<configured-base-branch>)        <- you are here
  /path/to/my-project-feature-user-auth  (feature/user-auth)  -> Plan: feature-user-auth.md
  /path/to/my-project-feature-billing    (feature/billing)    -> Ultra: feature-billing/index.md
  /path/to/my-project-fix-cart-bug       (fix/cart-bug)        -> No plan yet

当 workflow.plan_id_format = sequential 时，显示的文件或目录会包含数字前缀，例如 Plan: 0042_feature-user-auth.md 或 Ultra: 0042_feature-user-auth/index.md。针对该 worktree 的分支名称前缀，在两种格式中选择编号最高的匹配项。

--cleanup 子命令

传入 --cleanup <branch> 时，移除工作树，并可选择删除分支。然后停止。

DIRNAME=$(basename "$(pwd)")
BRANCH_DIR=$(echo "<branch>" | tr '/' '-')
WORKTREE="../${DIRNAME}-${BRANCH_DIR}"

git worktree remove "${WORKTREE}"
git branch -d <branch>  # -d (not -D) will fail if unmerged, which is safe

如果 git branch -d 因分支尚未合并而失败：

Branch <branch> has unmerged changes.
To force-delete: git branch -D <branch>
To merge first: git checkout <configured-base-branch> && git merge <branch>

如果工作树路径不存在，请检查 git worktree list 并建议正确的路径。

---

任务描述要求

每个 TaskCreate 项目都必须包含：

• 明确的交付内容和预期行为
• 要更改／创建的文件路径
• 日志要求（记录什么、在哪里记录以及日志级别）
• 适用时的依赖项说明
• 当适用需求对齐关卡时，提供需求来源锚点和适用的行为组合

创建任务时绝不要遗漏日志说明。

请使用 references/TASK-FORMAT.md 中的规范示例：

• TaskCreate 示例
• 日志要求检查清单

重要规则

1. 用户说不需要测试，就不要添加测试 — 不要偷偷加入测试任务
2. 不要添加报告 — 末尾不要创建总结／报告任务
3. 任务必须可执行 — 每项任务都应有明确的交付内容
4. 粒度要合适 — 不能太大（难以应对），也不能太小（徒增噪声）
5. 依赖关系很重要 — 按顺序安排任务，以便依次完成
6. 包含文件路径 — 让实施者知道在哪里开展工作
7. 大型计划要设置提交检查点 — 5 项或更多任务需要制定提交计划，每 3～5 项任务设置一个检查点
8. 计划产物位置 — Fast：paths.plan。Full： paths.plans/<plan_identifier>.md。Ultra： paths.plans/<plan_identifier>/index.md，以及阶段文件。 plan_identifier 使用规范的交接／分支／slug 主干，以及 Step 1.2 中可选的顺序前缀；timestamp 和 uuid 回退为 slug。
9. 所有权边界 — 此命令仅负责计划产物（已解析的 Fast 计划路径，以及 paths.plans 下的 Full／Ultra 产物）。请使用所属命令（/aif-roadmap、/aif-rules、/aif-explore）处理它们各自的产物。
10. 路线图关联（如有） — 如果已解析的路线图产物存在，请在计划中加入 ## Roadmap Linkage 部分（或明确说明已跳过）。
11. 规划前先对齐需求 — 不要让路线图摘要、优先级较低的来源或内部一致的实现覆盖尚未解决的行为需求。

计划文件处理

Fast 模式（paths.plan，默认值：.ai-factory/PLAN.md）

• 用于快速工作的临时计划
• 完成后，/aif-implement 可能会建议删除

Full 模式（paths.plans/<plan_identifier>.md — 默认）

• 用于交付功能的长期计划
• 规范的 plan_file_stem 来自 Step 1.2.a：交接分支名称（将斜杠替换）→ git 分支名称（将斜杠替换）→ 描述的 slug，按此顺序选择
• 当 workflow.plan_id_format = sequential 时，文件名变为 paths.plans/<NNNN>_<plan_file_stem>.md — 前缀是目录中现有编号计划的最大编号之后的下一个 4 位 数字，上限为 9999。编号根据当前存在的文件确定：从目录中删除或移走一个编号计划后，下次运行时该编号可能会被重新使用。交接分支约定会强制禁用此前缀（参见 Step 1.2.b–c）。
• timestamp 和 uuid 是保留值；目前两者的行为都与 slug 相同（不应用前缀）

Ultra 模式（paths.plans/<plan_identifier>/index.md）

• 用于高保真委派的长期计划包
• 使用与 Full 模式相同的规范主干、分支／工作树行为和可选顺序前缀；前缀应用于目录
• index.md 是清单和进度来源文件；直接子级阶段文件是实现规范
• 使用方必须按照 references/ULTRA-FORMAT.md 读取计划包；不要将其扁平化为本地单文件计划

如需了解具体的端到端流程（Fast／Full／Ultra／并行／交互式），请阅读 references/EXAMPLES.md（流程场景）。