项目规划与评估规范

1. 规划约束

1.1 硬性约束

阶段性聚焦: 单个迭代核心任务控制在 5-6 项以内，超出时遵循"进一出一"原则。
功能解耦: 新功能不破坏现有核心逻辑。涉及核心架构变动必须先技术预研并更新设计文档。
测试先行: 规划任务时同步制定测试方案。不包含测试补全计划的功能不具备准入资格。
验收标准具体化: 待办条目必须写清：执行范围、非目标、可验证验收标准、最小验证矩阵/证据落点，以及必要时的回滚边界。禁止"优化一下""先做最小版本"等模糊口径。
任务粒度约束: 规划时预估单条任务的 diff 规模（文件数 × 行数）。预计新增 > 10 个文件或 > 800 行（新领域 / 跨模块骨架任务从严，> 5 文件即考虑拆分）时，必须拆分为可独立提交的子任务，每个子任务有独立验收点与提交批次；禁止"一个原子条目 = 一个巨型 diff"。本条是任务粒度约束的唯一权威声明：其他文档（git.md、ai-collaboration.md、skill/agent 定义）仅作一行引用，不得重复抄写阈值或教训；合规核验由 review 阶段执行（见 code-reviewer 检查点与 Code Auditor 必查项）。
迭代范围与候选组合: 单次迭代核心任务应在 5-6 项以内；当上一阶段闭环后仅剩单一候选（M15 收口后 UX-R3 仅占 1 项）的尴尬局面时，主动扩展——从 backlog 中挑选 UX 痛点 / 技术债 / 能力扩展类候选填充，使总任务数达到 5 项左右；类型平衡建议：用户体验 ≥ 2 项 + 技术债 ≥ 1 项 + 能力扩展 ≥ 1 项 + 测试覆盖 ≥ 1 项，避免单一类型堆叠。
backlog 历史指针压缩: 每个阶段归档完成后必须执行 backlog 历史指针压缩——已闭环条目不再展开细节，仅保留最近 3-4 个阶段 + 早期间接指针（如 M0-M11：详见 archive/todo-archive-phases-*.md）；避免 backlog 随阶段线性膨胀。禁止在 backlog 中复制 todo-archive.md 已闭环条目的子任务细节。
跨文档内部一致性：新需求处理原则 + 插队例外清单 3 类 + 合规核验 code-auditor 主责边界必查项 三段必须在 AGENTS.md §新需求处理原则 + docs/standards/ai-collaboration.md §1.4 + docs/standards/planning.md §3.1 三处保持一致。修复模式：(a) 规范修改前先 rg -n "新需求.*处理原则" docs/standards/ docs/standards/ai-collaboration.md AGENTS.md docs/standards/planning.md 实证所有相关描述；(b) 修改后 pnpm run check:docs 验证链接 + rg -n 交叉验证措辞一致；(c) 关键原则（hard requirement / 插队例外）必须 3 处同步 + commit message 显式说明"3 处同步落地"。

1.2 阶段归档流程

4. 阶段归档流程

设计先行闸门: 涉及新模块、跨模块边界调整、数据/接口契约重写时，先完成设计文档再进入实现。
阶段切换闸门: 当前阶段归档未完成前，禁止在 roadmap 中开启下一阶段的正式规划。

1.2 迭代内新增事项闸门

开发/测试/审计过程中发现的额外事项默认不自动并入当前阶段：

先核对该事项是否已在 todo.md、roadmap.md 当前阶段或 todo-archive.md 中
若不在当前规划内，先完成快速分流（阻塞/高风险 → 插队；其他 → 延期）
未完成判定前，严禁直接进入开发

2. 路线图与待办管理

2.1 路线图

docs/plan/roadmap.md 维护阶段概览，每阶段包含：目标、优先级、状态
已完成阶段标注状态为"已审计归档"或等价完成状态
下一阶段在上一阶段归档完成后才开启正式规划
详细任务不在 roadmap 中重复展开，以 todo.md / backlog.md 为准

2.2 待办事项

docs/plan/todo.md 仅包含当前阶段的具体实施任务
任务状态：[ ] 待办 / [x] 已完成 / [-] 已取消
任务详细度要求：每条子任务（子阶段条目）必须含 8 要素（目标 / 范围 / 验收标准 / 不做什么 / 依赖 / 交付物 / 风险与缓解措施 + 必含优先级），缺一项视为"模糊口径"，必须退回补齐——完整要素清单见 §2.5
任务按里程碑分组

2.3 待办积压

docs/plan/backlog.md 存放后续阶段的详细任务
应区分两类条目：
1. 长期主线任务: 可跨阶段保留（覆盖率治理、ESLint/类型债等）。记录最近一次上收阶段、当前状态与下一切片方向。
2. 短期/一次性候选: 上收后去重，不得同时出现在当前规划与 backlog 中。

2.4 归档管理

阶段完成后，详细内容从 todo.md 移入 docs/plan/todo-archive.md
归档保留原始层级结构、状态与验收标准，确保历史可追溯
阶段归档完成后必须从 docs/plan/backlog.md / docs/plan/todo.md 清出所有"已闭环 / 已归档"内容（"归档摘要"、"闭环整理"、已闭环批次指针 / 已落地动作详细描述）；长期主线任务章节下面有且仅有"可多阶段反复执行"的任务，不保留其他任何东西；已闭环 / 已归档内容统一由 todo-archive.md 主窗口 + archive/todo-archive-phases-*.md 分片维护。具体操作规范见 §4.4 第 11 条。

2.5 任务详细度要求

docs/plan/todo.md 与 docs/plan/todo-archive.md 的每条子任务（子阶段条目）必须包含以下 8 要素，缺一项视为"模糊口径"，必须退回补齐：

目标：要达成什么（一句话可证伪，避免"提升 XX 能力"等口号式描述）
优先级：P1 / P2 / P3（与 backlog 主条目 P 编号一致）
范围：包含什么（具体文件 / 模块 / 子模块路径，避免"引擎相关"等抽象范围）
验收标准：可证伪的具体条款（checklist 形式，≥ 3 条；含命令 / 阈值 / 期望输出，避免"通过测试"等口径）
不做什么：边界（明确排除项，避免 scope creep；含相关但本次不动的功能）
依赖：前置任务 / 触发条件 / 关联 backlog 条目（引用具体 commit / PR / 文档段）
交付物：commits 数量 + files 清单 + 文档（每条预期 commit 的文件级 impact）
风险与缓解措施：潜在风险点 + 缓解方案（≥ 1 条，避免"小风险"等空洞描述）

禁止模糊口径（按 §1.1 L10 验收标准具体化扩展）：

"优化一下" / "清理一下" / "增强一下"
"先做最小版本" / "做个基础版" / "做个简化版"
"顺手做" / "一起处理" / "顺便改"
"后续完善" / "持续优化" / "视情况"
仅 1-2 行描述的子任务清单（信息密度不足以指导实施）

反模式示例（禁止）：

markdown

## ❌ 反例（信息密度不足）
- **M.x.1**（P2）Code Scanning RG-W01 修复 —— 来源：audit

正确示例：

markdown

## ✅ 正例（8 要素齐全）
- **M.x.1**（P3，🛡️ 治理）Code Scanning RG-W01 + RG-W02（execFileSync 替换 execSync 2 处）
  - **目标**：消除 2 处 Code Scanning 命令注入告警
  - **范围**：`packages/engine/src/github/pr-creator.ts:214` + `packages/engine/src/fixers/pnpm/index.ts:144`
  - **验收标准**：
    - [ ] 2 处 execSync 替换为 execFileSync + 参数数组
    - [ ] `pnpm --filter @dependfix/engine test` 全过（既有 pr-creator.test.ts / fixers-pnpm.test.ts）
    - [ ] `pnpm lint` + `pnpm typecheck` 0 error
    - [ ] Code Scanning 告警 #26/#27 在本地重现路径已消除（grep 实证 0 处 execSync 模板拼接）
  - **不做什么**：不重构其他 execSync 调用 / 不升级 pnpm / git 版本
  - **依赖**：M18.4 完成（pr-creator.ts 上下文） + Code Scanning audit #26/#27 已记录
  - **交付物**：2 atomic commits（fix(engine) execFileSync 替换）+ 既有测试不回归
  - **风险**：参数化命令数组需正确转义特殊字符（git URL 含空格等边界）；缓解：复用既有测试覆盖 + 新增 1 case 验证带空格路径

合规核验：本条由 review 阶段执行，详见 code-reviewer skill §5.6 流程编号标记必查项 + code-quality-checklist §todo.md 子任务详细度审计 + Code Auditor「主责边界必查项 - todo.md 子任务详细度审计」。

变更历史：本条由 M21 P 阶段规划新增（2026-08-31）—— 用户反馈"M19 / M20 P 阶段规划 commit 子任务描述过简（仅 1-2 行）"触发强化；之前 §1.1 L10 + §2.2 L41 已有"验收标准具体化" + "任务描述至少包含：优先级、依赖、交付物、验收标准"基础要求，但分散且缺要素清单，本节集中强化为 8 要素硬性约束。

3. 迭代中途新增事项分流

范围核对: 先检查是否已在 todo.md、roadmap.md 当前阶段或 todo-archive.md 中。
分类决策:
- A 类（当前范围内）: 只是补足当前验收标准的配套工作 → 继续执行，补充说明
- B 类（允许插队）: 仅限直接影响可用性的生产事故 + 安全漏洞（详见 §3.1 例外清单）→ 写入 todo.md，标注插队原因 + 用户明确授权
- C 类（延期）: 体验优化、非阻塞重构、探索性想法、未来功能 → 写入 backlog.md
容量控制: B 类事项进入后若超出 5-6 项，须挪出一项低优先级内容至 backlog.md。
禁止静默膨胀: 不得在未告知用户的情况下把原子任务扩展成新的功能包。

3.1 新需求默认走"评估 → backlog"原则（hard requirement）

核心规则：

新需求（新功能 / 新模块 / 新集成）的默认处理路径是：先评估（P 阶段规划 + requirement-analyst 需求澄清）→ 进入 backlog.md §短期候选 → 等待用户明确决策阶段 → 经用户授权后从 backlog 上收至 todo.md §当前阶段
不直接升级为下一阶段 todo.md §Mxx：未经用户明确授权，backlog 候选不得自动获得阶段编号（如 M23.1、M24 等）
不默认优先级排序：候选池按"类型平衡"原则选取是用户决策行为，不是 AI 默认推断

插队例外清单（仅以下 3 类可直接写入 todo.md 当前阶段并分配阶段编号）：

安全问题：已确认的安全漏洞（Code Scanning 告警、Snyk/Dependabot critical 漏洞、有 PoC 的安全 issue）
漏洞问题：依赖链中高危漏洞（critical CVE、GHSA 标识为 critical/high 且影响 dependfix 自身或被 dependfix 管理的仓库）
直接影响可用性的任务：生产环境故障、P0/P1 事故恢复、CI 主链路（lint/typecheck/test/build）阻塞、用户报告的 blocker 级功能缺失

例外清单外的全部需求（含：功能增强、体验优化、代码重构、新模块、依赖升级、监控/告警增强等）→ 必须先评估后入 backlog，不得直接写入 todo.md 当前阶段。

评估标准（requirement-analyst skill 五要素）：

目标（业务价值 + 真实需求 vs 表面需求）
边界（in-scope / out-of-scope）
验收标准（具体可测）
优先级（与 backlog 候选池对比）
风险与依赖

评估完成后形成 backlog.md §短期 / 一次性候选任务条目，包含 8 要素（§2.5 任务详细度要求）。

典型反模式（AI 单方面违规）：

❌ AI 主动将 backlog 候选写为 todo.md §M23.1 等带阶段编号条目
❌ AI 推断"本批次最高优先级是 X"并默认启动 X
❌ 用户提出需求后 AI 不经评估直接进入 D 阶段
❌ backlog 候选因"看起来很重要"被 AI 跨过用户决策直接落地

合规核验：本条由 code-auditor 主责边界「新需求未默认升级为下一阶段 todo」必查项强制检查——改动涉及新增功能需求但未走 backlog → Reject 退回。

变更历史：本条由 2026-09-02 用户规则强化新增——基于 backlog.md §PR 管理候选池决策点反思：AI 默认赋予阶段编号 + 默认最高优先级判断违反"AI 单方面决策最小化"原则，应通过规范约束。

3.4 阶段启动决策前置交叉核验硬要求（M27.1 重复评估教训 / 2026-09-10）

核心规则：

当 todo.md §当前阶段新增条目（无论是 backlog 候选上收 / 插队例外 / 用户直接决策），必须执行以下三重交叉核验，未通过任何一项不得进入 D 阶段：

todo-archive.md 历史阶段表格核验：rg -n "已闭环|不计入本批|不计入 M\d+|ahead=0.*已推" docs/plan/todo-archive.md docs/plan/archive/todo-archive-phases-*.md 扫描最近 3-5 个阶段表格，验证候选对应 backlog 条目的子任务是否已 ahead=0 闭环；若发现"已闭环"标注，必须从 todo.md §当前阶段任务段删除对应子任务范围。
git log 历史核验：git log --oneline -- <候选相关路径> + git log --all --grep="<候选标识>" 验证候选对应 commit hash 是否已 ahead=0 推 origin/master；若发现已推，必须从 todo.md §当前阶段任务段删除对应范围。
实际代码侧 anchor 实证：打开候选相关代码文件（apps/platform/app/pages/alerts.vue / apps/platform/app/composables/use-fix-now.ts 等），验证候选描述的状态与实际代码一致；若发现已实现，必须从 todo.md §当前阶段任务段删除对应范围。

触发条件：

todo.md §当前阶段 banner 修改（新增阶段）
todo.md §当前阶段新增 M\d+.\d+ 原子条目
todo.md §当前阶段任务段范围 / 验收标准 / 交付物修改

典型反模式（M27.1 重复评估教训）：

❌ 仅读 backlog.md / todo-archive.md 文档侧资料，未打开实际代码验证
❌ 决策描述中出现"参考 NNN 实施"自相矛盾——若 NNN 仅"参考实施"则候选未落地，若 NNN 已 100% 落地则候选不需增强，必须先厘清
❌ 决策 D 阶段前未用 git log --oneline -- <相关路径> 5 分钟实证候选状态

合规核验：本条由 code-auditor 主责边界「阶段启动重复评估自检」必查项强制检查——commit 涉及 todo.md §当前阶段新增 / 修改时，三项交叉核验任意一项未执行 / 未通过 → Reject 退回。

backlog 描述同步要求：当 todo.md §当前阶段新增条目对应 backlog 候选时，必须同步修订 backlog.md 描述：(a) 已 ahead=0 闭环的子任务追加 ✅ 已闭环标注 + commit hash 回填；(b) ⏸️ 暂缓的子任务追加 ⏸️ 暂缓标注 + 暂缓原因；(c) 「保留为后续增强候选」措辞必须基于"当前未落地"前提，否则删除。

4. 阶段归档流程

4.1 归档准入

确认当前阶段核心条目全部完成
"进行中""待继续观察"类描述先判断是否阻塞归档还是仅属运行期观察
若缺少 todo.md 清理、回归记录、阶段总结或 todo-archive.md 归档块 → 视仍在收口中

4.2 文件更新顺序

先清理 todo.md：移除已完成阶段正文
再追加 todo-archive.md：完整归档块（审计结论、验收摘要）
最后同步 roadmap.md：阶段状态改为"已完成"或"已审计归档"

4.3 最低验证

todo.md 已清理、todo-archive.md 已追加
roadmap.md 已同步阶段状态
质量门结论可查（lint + typecheck + 定向测试）
Review Gate 有 Pass / Reject 结论
Session Wisdom 蒸馏检查：若 .session/wisdom.md 活跃条目 >= 20（pnpm distill:wisdom --check），执行一次蒸馏（详见 Session Wisdom 蒸馏机制）
用户可见文档同步：里程碑收口时除 todo/roadmap 外，还需同步 docs/index.md 当前状态、guide 文档与设计文档中的"规划中"标记

4.4 大批量归档批次操作规范

涉及跨文件 markdown 链接修改 / 段标题重命名 / 段删除时，必须遵守以下操作规范（避免 wisdom §2026-08-25 已实证的 6 类问题）：

anchor 实证：写 markdown 链接前必须 rg -n "^## " <目标文件> 确认锚点真实形式，避免凭印象写错锚点（括号转 anchor 规则不是直觉）；check:docs 是兜底而非首选。
跨文件外链主动追踪：段删除 / 段重命名前必须 rg -n "<删除段标题>" 全仓库扫描所有外链（不仅是删除段所在文件），列出每个外链文件 + 位置 + 目标，逐个修复为新的归档位置（todo-archive.md 主窗口或 archive/todo-archive-phases-*.md 分片）。
跨目录相对路径精确：从 docs/<dir1>/xxx.md 引用 docs/<dir2>/yyy.md 需 ../<dir2>/yyy.md，多级目录按 ../../ 累加；写之前主动计算，check:docs 兜底。
commit 分组追踪：归档文案中分组 commit 时必须先列每个 commit 归属，避免子批次 commit 与"todo.md 收口 commit" 重复计数（todo.md 收口 commits 通常已含在子批次计数内，独立列出 = 重复 +1）。详见经验归档 §四十八。
ahead commits 实证 + 动态描述：归档文案 "ahead of origin/master N commits" 必须用 git rev-list HEAD ^origin/master --count 双向核验（已推送 commits 不计入 ahead），不能凭印象估算——跨批次归档时用户可能已推送过。具体命令与 ahead 计数语义详见 Git 规范 §3 提交规范（一行引用，不重复抄写命令）。额外约束：ahead 数字写具体值极易过时（用户可在 banner 写后立即推送），改用 commits 列表 + 实证命令替代具体数字（与 AI 协作规范 §2.P.1 配套）。
段结构引用原则：已删除段不在外链保留（避免读者点击 404），外链改为指向新归档位置 + 段标题对齐（避免 VitePress / GitHub 渲染降级到文件顶部）。
死链验证：归档后必须 pnpm run check:docs 实证 0 error；CI Test job 跳过盲区（wis #43）需在归档批次前主动跑通。
算式校对（commit 数量 + 子任务数量去重统计）：归档文案中"X 子任务 / Y commits"等算式信息必须从 git log first-parent 列表去重统计，不依赖估算：
- commit 数量：git log master --first-parent --since=<起始日期> --until=<结束日期> --oneline | grep -E "<子任务前缀>" | sort -u | wc -l
- 子任务数量：子任务编号列表一一对应（T1301+T1302+...+T1403 = 12 子任务），不留估算空间
- 详见经验归档 §四十二
区分已归档内容与必要信息：清理 backlog.md / todo.md 时必须区分"已归档内容"和"必要信息"：
- 可删除：闭环整理 这类已归档内容（如 M16/M17/M18 归档批次的详细记录）
- 必须保留：维护规则（backlog 的治理依据）、长期主线任务详细描述（后续阶段理解任务背景）、未上收待办项（活跃任务）、待人工验收条目（真实环境验证任务）
- 归档后验证链接：pnpm run check:docs 检查断链
- 判断标准：删除前问"这个信息在下一阶段启动时是否需要？"——如果需要，就保留
- 详见经验归档 §四十五
预防性迁出后 cross-reference 更新：todo-archive.md 预防性迁出主窗口内的§至 archive/todo-archive-phases-*.md 分片后，其他文档（roadmap.md / backlog.md / data-model.md / docs/index.md 等）中所有引用已迁出§的锚点全部失效，必须统一更新：
- 扫描范围：用 rg -n "todo-archive.md#m\d+-|<被迁出§标题>" 全仓库检索锚点引用
- 锚点格式：--（双连字符）在 check-docs.mjs 中自动转换为单词连续（如 m161--m162 → m161m162），不要手动拼接
- 跨文件更新：统一指向分片文件路径（如 archive/todo-archive-phases-m16-m17.md），不要保留主窗口引用
- 验证：更新后必须 pnpm run check:docs 实证 0 error
- 详见经验归档 §四十八
归档后 backlog.md / todo.md 必清理（必执行项）：阶段归档完成后必须从 docs/plan/backlog.md / docs/plan/todo.md 清出所有"已闭环 / 已归档"内容——
- 可删除（"已闭环 / 已归档"内容）：
  - backlog.md §历史归档指针（不在 backlog 重复登记） 整段——所有已闭环阶段（M19/M20/M21/...）+ 已闭环特定批次（B3/C53/C16/...）指针段
  - backlog.md §已沉淀经验（已迁移至 standards） 段
  - backlog.md §已评估不实现 段
  - backlog.md 主线任务章节下面的"已闭环批次记录"——来源指针 / 最近一次上收段 / 已落地动作详细描述 / 触发事件 / 临时修复细节
  - backlog.md 短期候选中已闭环条目（如 C16/C21/C22/C34/C39/UX-R1/UX-R2/UX-R3 等）
  - todo.md 顶部"M21/M20 完成摘要"段 + "下一阶段规划"段
  - todo.md 中"待人工验收"段（属 backlog 范畴）
- 必须保留（活跃 / 多阶段反复）：
  - 维护规则（backlog.md 治理依据）
  - 长期主线任务（仅多阶段反复可执行——如监控上游 changelog + 候选方向评估 / 按需触发的可持续治理，不含已闭环批次记录）
  - 周期性回归验证层（基础设施）
  - 短期候选中未闭环条目（C33/C37/D1/D3/...）
  - 延期暂缓项（T705/T703/C30/...）
  - 待人工验收（T701/T702/T704/...真实环境验证任务）
  - 已知边界与 known-issue（持续观察项）
- 长期主线任务章节硬性规则：下面有且仅有"可以多阶段反复执行"的任务，不保留任何其他东西（包括已闭环批次记录 / 已落地方案详细描述 / 触发事件 / 临时修复细节）
- 判断标准：删除前问"下一阶段启动时是否需要？"——已闭环 / 已归档内容由 todo-archive.md 统一维护，不应在 backlog.md/todo.md 重复
- 执行范围：本规则与 §4.4 第 9 条（"区分已归档内容与必要信息"，反向防"删过头"）互补——第 9 条强调保留必要信息，本规则强调必清出已闭环内容；两者配套执行
- §已知边界段部分闭环处理指引（M28.1 治理债清理批次强化 / 2026-09-11）： §已知边界与 known-issue 段不应仅做"保留 / 删除"二元决策；当某持续观察项已部分闭环时，必须更新描述而非整段保留或删除。具体指引：
  - 完全闭环：整段删除（如 §已知边界 SQLite 单文件脆弱性段持续观察项 TypeORM 1.x 升级已 M23.x 闭环，整段删除）
  - 完全未闭环：保留原描述（如 §已知边界 PrimeVue 4 + Nuxt hydration 主线 #1 持续观察，无阶段闭环）
  - 部分闭环：必须更新描述 + 引用闭环 commit hash（如 §已知边界 M22.7 follow-up 候选 ② Nitro h3 async generator 已 M24.2 commit bbb8f30 判定非根因——更新描述加 ~~删除线~~ 标注 + commit hash 引用；如未来 e2e 复现 fixture 并发问题按经验性模板加 fixtures-throttle.ts 登记 follow-up）
  - 场景变更：必须更新描述（如 §已知边界 M22.8 follow-up 候选 ③ Playwright 1.62 vs 1.61/1.60 fixture pool 行为对比已因 Playwright 1.62 → 1.63 升级（@playwright/test@^1.63.0 实证）场景变更而失效——更新描述标注"持续观察 1.63 fixture pool 行为"）
  - 触发条件：(a) 任意阶段 commit message 涉及 backlog §已知边界段候选的闭环判定；(b) 任意阶段 commit message 涉及 backlog §已知边界段候选的场景变更；(c) Mxx 归档批次涉及 backlog §已知边界段清理
  - 合规核验：本条由 code-auditor 主责边界「§已知边界段 stale 描述未同步」必查项强制检查——commit 涉及 backlog §已知边界段候选状态变更时，三项检查任意一项未执行 / 未通过 → Reject 退回
- 详见经验归档 §四十九

本节为大批量文档归档批次（multi-file edit + 段结构变更）的统一操作规范；其他文档归档 / 小批量编辑仅执行相关条目。详见经验归档 §四十二 + §四十五 + §四十八 + §四十九。

5. 需求采访与意图抽离

针对模糊需求，必须先通过"采访"方式反问用户：

先结构后细节，一步步递进
一次一个问题，待用户回答后再追问
目标是抽离出最核心、最真实的业务需求
在核心需求未对齐前严禁进入开发阶段

6. 相关文档

本文档在 1.0.0 前参考 momei 项目的成熟做法完成继承与适配；1.0.0 后按项目自身实践持续演进，形成自有规范。

项目规划与评估规范 ​

1. 规划约束 ​

1.1 硬性约束 ​

1.2 阶段归档流程 ​

4. 阶段归档流程 ​

1.2 迭代内新增事项闸门 ​

2. 路线图与待办管理 ​

2.1 路线图 ​

2.2 待办事项 ​

2.3 待办积压 ​

2.4 归档管理 ​

2.5 任务详细度要求 ​

3. 迭代中途新增事项分流 ​

3.1 新需求默认走"评估 → backlog"原则（hard requirement） ​

3.4 阶段启动决策前置交叉核验硬要求（M27.1 重复评估教训 / 2026-09-10） ​

4. 阶段归档流程 ​

4.1 归档准入 ​

4.2 文件更新顺序 ​

4.3 最低验证 ​

4.4 大批量归档批次操作规范 ​

5. 需求采访与意图抽离 ​

6. 相关文档 ​

项目规划与评估规范

1. 规划约束

1.1 硬性约束

1.2 阶段归档流程

4. 阶段归档流程

1.2 迭代内新增事项闸门

2. 路线图与待办管理

2.1 路线图

2.2 待办事项

2.3 待办积压

2.4 归档管理

2.5 任务详细度要求

3. 迭代中途新增事项分流

3.1 新需求默认走"评估 → backlog"原则（hard requirement）

3.4 阶段启动决策前置交叉核验硬要求（M27.1 重复评估教训 / 2026-09-10）

4. 阶段归档流程

4.1 归档准入

4.2 文件更新顺序

4.3 最低验证

4.4 大批量归档批次操作规范

5. 需求采访与意图抽离

6. 相关文档