release: v2.1.0 发布中心 Skill 与项目计划模板

feat: 按 V2.1 更新中心 Skill、流程图与项目记录模板
2026-10-20 19:09:53 +08:00 · 2026-10-20 18:46:19 +08:00
26 changed files with 592 additions and 83 deletions
@@ -53,14 +53,16 @@ python scripts/dingtalk_notify.py progress milestone --stage "阶段八：复盘
 - 结项资料整理：由中心真人负责人组织四类结项成果，Hub 协助整理工作稿。
 - 资料补充：由产品负责人、业务负责人补充现有线下成果及确认记录，不重做验收。
 - 旧事项停止：由 Hub 停止此前的验收准备催办。
- 结项确认：四类成果及遗留承接安排具备后，由 Hub 请 @{示例业务负责人} 确认结项。
+- Bug 事实确认：由 Hub 请 @{示例中心负责人} 先确认全部 Bug 的事实、对象、版本和实际处理或承接，已有有效确认直接引用。
+- Bug 处理确认：中心确认事实后，由 Hub 请 @{示例产品负责人} 再次确认并在职责内决定处理；双方无异议后登记最终安排。
+- 结项确认：四类成果、遗留承接及 Bug 双方确认具备后，由 Hub 请 @{示例业务负责人} 确认结项。
 - 关闭决定：业务确认结项后，由 Hub 请 @{示例中心负责人} 决定是否关闭；结项必需项完成后锁定四类成果。
 - 本轮工作范围：不新增应用修复、设备测试或发布验证。

 **遗留**

 - 原测试不通过的结果如实保留，不因进入结项阶段改为通过。
- 已接受延期的问题如实保留，后续沿用 Bug 系统中的记录和已有处理安排继续跟进。" --at "示例业务负责人" --at "示例中心负责人"
+- 已接受延期的问题如实保留，后续沿用 Bug 系统中的记录和已有处理安排继续跟进。" --at "示例业务负责人" --at "示例中心负责人" --at "示例产品负责人"
 python scripts/dingtalk_notify.py progress blocked --stage "阶段三：方案设计" "**已确认的进展**

 - 本轮无新增已确认进展。
@@ -85,6 +87,19 @@ python scripts/dingtalk_notify.py message --title "阶段三：方案设计｜

 事件含义见 [通知规则](../ep-hub/references/dingtalk-progress-reporting.md)，详细调用与结果见 [脚本用法](../ep-hub/references/dingtalk-script-usage.md)。

+## 阶段交接和关闭通知
+
+中心真人已批准推进或条件授权实际满足后，将上一阶段总结与下一阶段已确认安排合为一条 `milestone`。阶段内已授权的关键进展、阻塞、失败通知保留，同轮合并。等待决定时先在中心会话汇报，不宣称已进入下一阶段。
+
+项目实际关闭后，用 `complete` 发送一次结项总结，保留未修复 Bug、失败测试和已确认承接；后续整理资料不重复发送。完整示例见 [通知规则](../ep-hub/references/dingtalk-progress-reporting.md)。较长正文可保存为 UTF-8 文件，先离线预览：
+
+```text
+python scripts/dingtalk_notify.py progress milestone --stage "实际当前阶段" --file "阶段交接正文.md" --at "已确认完整姓名" --dry-run
+python scripts/dingtalk_notify.py progress complete --stage "阶段八：复盘结项" --file "结项总结正文.md" --at "已确认完整姓名" --dry-run
+```
+
+正文文件和姓名须替换为实际值，正文无真人提醒时省略 `--at`。通知范围已授权且本次满足触发条件后，真实调用去掉 `--dry-run`；用户要求先审核时先取得本次发送确认。脚本仅渲染和发送，推进授权、Bug 确认和是否已发由中心查原记录判断。正文及真实结果回写阶段过程记录，不新增队列或外层重试。
+
 ## 检查与失败处理

 - `python scripts/dingtalk_notify.py check --at "完整姓名"`：只检查固定账号登录和可选姓名，不发消息，不证明实际 @ 提醒成功。不是每条通知的必做步骤。
@@ -5,7 +5,7 @@
 本文件适用于整个仓库，更具体的子目录说明在其范围内生效，当前任务中的明确用户要求优先。本仓库维护中心业务 Skill、流程文档、记录模板和钉钉通知封装，没有应用构建步骤。

 1. 先读 [ep-hub/SKILL.md](ep-hub/SKILL.md)，仅按本次任务路由读取相关 reference。
-2. 当前设计来源为 [V2.0 总流程图](doc/Codex多角色项目推进总流程图.html)，运行规则已整理到中心 Skill；不要求目标项目具备流程 HTML。流程文档固定路径更新，历史由 Git 保留，不另建日期或版本副本。
+2. 当前设计来源为 [V2.1 总流程图](doc/Codex多角色项目推进总流程图.html)，运行规则已整理到中心 Skill；不要求目标项目具备流程 HTML。流程文档固定路径更新，历史由 Git 保留，不另建日期或版本副本。
 3. 先后检查 Git 状态与差异，保护用户已有改动和未跟踪资料。不要删除用户保留的旧源文件来制造干净工作区。
 4. 当前工具 schema、运行时契约、成员登记和已确认项目基线与通用 Skill 有冲突时，说明具体差异；不自行猜测能力、改写已确认基线或绕过运行时权限。

@@ -15,10 +15,10 @@

 - 一个项目使用一个持续的中心会话；默认角色为项目Hub、业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件、测试。新增角色按已确认职责和 Etunel 实际管理能力配置，不伪造已创建结果。
 - 每项任务只有一名主责真人，按交付结果或内聚任务包管理。真人自行设计内部工作流程、直接协作并决定是否使用 Agent；成员 Agent 之间仍经中心中继。
- 中心组织交付和结果确认，处理依赖、跨角色冲突、信息交接及留档，不替专业真人做结论。阶段推进由中心真人决定，不能代替业务授权、产品资源排期确认及外部验收。
- 原计划、当前有效计划和实际完成时间分别保存；实际完成只取任务提交后对应真人明确确认完成的时间。工具完成、排队、送达、已读或 Agent 检查不能替代。
+- 中心组织交付和结果确认，处理依赖、跨角色冲突、信息交接及留档，不替专业真人做结论。阶段推进由中心真人决定，已有条件授权实际满足后按原范围执行并留依据，不能代替业务授权、产品资源排期确认及外部验收。
+- 项目沿用唯一计划主表，新项目默认 Excel 八列模板；Markdown 进度保留摘要和入口。原计划、当前有效计划和实际完成时间分别保存；实际完成只取任务提交后对应真人明确确认完成的时间。工具完成、排队、送达、已读或 Agent 检查不能替代。
 - 一项任务保留一份原记录，跨阶段引用。项目层持续显示未完成事项、原计划和当前计划时间、影响及必须完成的阶段；改期、退回、重开保留历史。
- 正式成果只保存真人完成并确认的最终版和确认；草稿、旧版、历史确认与推进决定进入过程记录。链接成果只登记地址，不要求重复下载、摘要或截图。
+- 正式成果保存真人完成并确认的全部有效资料或完整外部入口及确认；草稿、旧版、历史确认与推进决定进入过程记录。链接成果不强制重复下载、摘要或截图；明确授权本地复制时保留来源和路径映射，复制日期不覆盖业务日期。
 - 中文职责名称统一为“业务”，机器字段仅在实际接口需要时保留。面向人不索取或编造成员、会话和任务技术编号。

 修改阶段、成果、确认、时间或通知规则时，同步核对 [八阶段规则](ep-hub/references/project-lifecycle.md)、[留档规则](ep-hub/references/project-records.md)、相关模板和通知示例。详细要求下沉到 reference，不重复复制整套规则，也不重新引入成员内部工作流程。
@@ -29,7 +29,7 @@

 - 只有中心／主 Agent 使用 [通知规则](ep-hub/references/dingtalk-progress-reporting.md) 和 [脚本用法](ep-hub/references/dingtalk-script-usage.md)。通知是辅助可见性和行动提醒，不是角色任务通道、审批、真人确认、推进依据或事实源。
 - 只用 `scripts/dingtalk_notify.py` 的 `progress`／`message` 或等价平台入口；事件只有 start、milestone、blocked、complete、failed。progress 使用实际当前阶段，正文按已确认进展、待办、遗留分条，真实姓名按约定原位 @。
- 先维护事实记录再通知，不为通知重新分配已有责任、期限或新建清单，不省掉已明确的停止事项和范围限制。
+- 阶段结果主动汇报到中心会话；已批准或条件授权实际满足的阶段交接合为一条群总结，实际关闭后发一次结项总结，正文及实际结果留在过程记录。先维护事实记录再通知，不为通知重新分配已有责任、期限或新建清单，不省掉已明确的停止事项和范围限制。
 - 不绕过封装调用 OpenAPI 或其他入口，不增加外层重试／通知队列。仅明确 DNS 失败最多 3 次、间隔 10 秒，未知结果不重发。
 - 首次账号、组织、群及通知范围由真人确认，配置用真实查询值；换账号或群重新确认。初始化和部署见 [.dingtalk/README.md](.dingtalk/README.md)。只保存开关、账号、群和项目名，本地配置不提交、不在普通回复或群中输出内部标识。
 - 不读取、输出或提交 DWS 登录凭据、Client Secret、DING_SEC、App Token；不静默将旧机器人授权变成个人代发。保留 AI 标识，发送不代表真人批准。
@@ -1,22 +1,22 @@
 # EP 项目中心 Skill

-本仓库提供基于 **V2.0 八阶段流程**的项目中心 Skill。中心负责流程把控、交付任务、信息与文件交接、过程记录；各角色真人负责人自行设计内部工作流程，并决定是否使用 Agent。
+本仓库提供基于 **V2.1 八阶段流程**的项目中心 Skill。中心负责流程把控、交付任务、信息与文件交接、过程记录；各角色真人负责人自行设计内部工作流程，并决定是否使用 Agent。

 ## 使用入口

 - [中心 Skill：ep-hub](ep-hub/SKILL.md)：中心业务规则与按需阅读入口。
 - **已安装的 etunel-use**：Etunel 配置、角色契约、会话绑定与通信操作；不包含本仓库的阶段、成果和留档规则。
- [当前总流程图](doc/Codex多角色项目推进总流程图.html)：固定路径维护 V2.0，历史通过 Git 追溯。
+- [当前总流程图](doc/Codex多角色项目推进总流程图.html)：固定路径维护 V2.1，历史通过 Git 追溯。
 - [记录与留档](ep-hub/references/project-records.md)：项目、阶段、任务和成果记录的分工与模板。
 - [钉钉消息模板](ep-hub/references/dingtalk-progress-reporting.md)：当前阶段标题、已确认的进展、待办事项、遗留及真人 @。

-本次已将仓库业务规则按 V2.0 和经确认的记录方案重写。旧的全角色 Skill 与独立 Hook 源目录已移除，旧内容仍可从 Git 历史查阅。仓库源文件更新不代表已发布、已安装、已修改 Etunel 配置或已迁移在途项目。
+本次按 V2.1 及已确认的实施口径更新阶段汇报、工时与排期、成果确认、Bug 双方确认和关闭后登记规则。旧的全角色 Skill 与独立 Hook 源目录已移除，旧内容仍可从 Git 历史查阅。仓库源文件更新不代表已发布、已安装、已修改 Etunel 配置或已迁移在途项目。

 ## 中心与角色怎样协作

 一个项目使用一个持续的中心会话。任务按可独立确认的交付结果或同一负责人的内聚任务包管理，明确输入、范围、结果、期限和完成条件。真人可以直接协作，接收和提交可在线下完成；成员 Agent 之间的信息仍由中心中继。

-中心 Agent 汇总事实和待决定事项，角色真人对专业成果负责，中心真人对阶段推进负责。单项任务确认完成后可解锁依赖就绪的后续任务；跨阶段推进需要中心真人决定。业务授权、产品资源排期确认和外部验收仍按各自权限办理。
+中心 Agent 汇总事实和待决定事项，角色真人对专业成果负责，中心真人对阶段推进负责。单项任务确认完成后可解锁依赖就绪的后续任务；跨阶段推进需要中心真人决定；已有条件授权实际满足后按原范围执行并记录依据，原授权日期与实际切换日期分别保存。业务授权、产品资源排期确认和外部验收仍按各自权限办理。

 | 阶段 | 主要成果 |
 | --- | --- |
@@ -29,7 +29,7 @@
 | 7. 内部／外部验收 | 内部验收记录、适用的平台／客户验收结果、共用遗留问题清单 |
 | 8. 复盘结项 | 《结项资料归档》、《变更记录》、《结项报告》、《流程闭环总结》 |

-完整内容与必要确认见 [八阶段与结果要求](ep-hub/references/project-lifecycle.md)。阶段六不要求缺陷清单或零缺陷清单；测试不通过时保留原结论，项目、产品真人共同核实后的放行决定单独记录。阶段八由中心真人组织，业务确认结项，中心真人决定关闭。
+完整内容与必要确认见 [八阶段与结果要求](ep-hub/references/project-lifecycle.md)。阶段六不要求缺陷清单或零缺陷清单；测试不通过时保留原结论，项目、产品真人共同核实后的放行决定单独记录。阶段八由中心真人组织，全部 Bug 处理或承接先由中心确认、再由产品确认，业务确认结项，中心真人决定关闭。关闭后同步记录、锁定有效成果并停止重复催办；未修复 Bug 和失败测试如实保留。

 ## 记录方式

@@ -37,6 +37,7 @@

 | 记录 | 用途 |
 | --- | --- |
+| 唯一计划主表 | 完整工作项、当前有效计划和实际执行；已有项目沿用，新项目默认使用 Excel 八列模板 |
 | 项目概览 | 目标、范围、基线、真人分工和资料入口 |
 | 项目进度 | 当前阶段、整体进度、当前待处理和跨阶段未完成事项、影响及必须完成的阶段 |
 | 阶段记录 | 每个任务的成果、完成与确认情况；正式成果和过程分栏 |
@@ -45,7 +46,9 @@

 每项任务保留三类时间：**原计划完成时间、当前计划完成时间、实际完成时间**。实际完成时间是任务提交后经对应真人明确确认完成的时间，提交时间另记。改期保留旧值、原因和真人决定；跨阶段沿用原记录，项目层持续跟进。

-每个阶段使用 `阶段记录.md`、`正式成果/`、`过程记录/`。正式区只放真人完成并确认的最终版及确认；草稿、旧版和历史确认保留在过程区。外部成果只记录地址，不要求下载、复制或截图。
+每个阶段使用 `阶段记录.md`、`正式成果/`、`过程记录/`。正式区只放真人完成并确认的最终版及确认；草稿、旧版和历史确认保留在过程区。外部成果登记完整真实入口、用途、版本及确认，不强制下载、复制或截图。项目明确授权本地复制时，保存已取得且确认有效的资料、来源与路径映射，操作日期不改变原提交及确认日期。
+
+排期评估和计划更新见 [项目计划规则](ep-hub/references/project-planning.md)。中心主动在持续会话汇报阶段结果，不能仅更新本地文件；详见 [阶段汇报](ep-hub/references/stage-reporting.md)。

 模板可从 [记录与留档](ep-hub/references/project-records.md) 按需打开。Markdown 用明确标题、短摘要、分条字段和关键历史，未知信息如实标明。

@@ -53,7 +56,7 @@

 1. 将仓库中的完整 `ep-hub/` 作为中心 Skill 安装到目标环境的 Skill 目录，保留 `references/`、`assets/` 和 `agents/`；具体安装位置遵循目标环境配置。
 2. 配置与通信使用目标环境已安装的 `etunel-use`。修改 Etunel 中心或成员契约时，按其管理操作和职责 Hook 指南办理；中心自身配置与成员配置是不同操作。
-3. 检查目标项目实际启用的旧 Skill、职责契约与 Hook。迁移须明确目标与范围，保留项目既有任务、时间、旧成果和确认记录；不能仅因仓库升级就宣称在途项目采用 V2.0。
+3. 检查目标项目实际启用的旧 Skill、职责契约与 Hook。迁移须明确目标与范围，保留项目既有任务、时间、旧成果和确认记录；不能仅因仓库升级就宣称在途项目采用 V2.1。
 4. 在迁移已获确认后，按目标环境的安装与配置机制停用冲突的旧角色流程约束。成员内部流程由各角色真人维护，新中心 Skill 不分发统一的内部操作提示词。
 5. 需要钉钉时，将仓库 `scripts/` 中的共用 Python 文件和所需平台入口部署到目标项目 `scripts/`；中心 Skill 安装不会自动部署脚本。按 [钉钉配置说明](.dingtalk/README.md) 确认个人账号、项目群和通知范围。

@@ -61,6 +64,7 @@

 通知是中心向项目群提供进度与行动提醒的辅助能力。先维护事实记录，再依授权发送。消息标题来自项目当前阶段，正文固定为 **已确认的进展／待办事项／遗留**，逐项写清谁做什么，沿用原有责任、时间、范围和停止事项。

+- 已获批准或条件授权实际满足的阶段交接合为一条“上一阶段总结＋下一阶段安排”；等待决定先在中心会话汇报。阶段内关键进展、阻塞和失败仍按已授权范围通知，同轮合并；实际关闭后发一次结项总结，正文及实际发送结果进入阶段过程记录。
 - 用 `scripts/dingtalk_notify.py` 的 `progress`／`message` 或同等平台入口；`progress` 必须提供 `--stage`。
 - 真人提醒在正文使用 `@{完整姓名}`，同时用 `--at` 列出姓名；脚本唯一匹配后原位生成提及。
 - `--dry-run` 完全离线，只展示内容，不证明账号、群或 @ 有效。
@@ -72,7 +76,7 @@

 ## 版本与升级

-当前发布版本为 `v2.0.0`，流程基线为 **V2.0**。版本统一采用 `vX.Y.Z`：前两位跟随 HTML 中已确认的流程版本，第三位是该流程下的发布迭代。V2.0 对应 `v2.0.Z`，首次正式发布从 `v2.0.0` 开始；日常修改不自动创建标签。
+当前发布版本为 `v2.1.0`，流程基线为 **V2.1**。版本统一采用 `vX.Y.Z`：前两位跟随 HTML 中已确认的流程版本，第三位是该流程下的发布迭代。V2.1 对应 `v2.1.Z`，该流程首次正式发布从 `v2.1.0` 开始；日常修改不自动创建标签。

 - 流程版本不变，Skill、脚本、配置或文档变更只递增第三位；不按功能规模或兼容性自行改前两位，也不为凑发布号修改流程图。
 - 流程正式更新到新的 X.Y，前两位同步，第三位从 0 开始。全仓库一个发布序列，组件不另编号；第三位更新也可能需要迁移。
@@ -98,6 +102,6 @@ git status --short

 ## 设计与参考资料

- [V2.0 总流程图](doc/Codex多角色项目推进总流程图.html)
+- [V2.1 总流程图](doc/Codex多角色项目推进总流程图.html)
 - [历史文档模板参考](doc/文档模板参考/README.md)：学习笔记与来源索引，原件未打包入仓库。
 - 流程文档固定路径更新，历史使用 `git log --all -- doc/` 查询，不另建版本或日期副本。
@@ -5,7 +5,7 @@
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <meta name="color-scheme" content="light">
  <link rel="icon" href="data:,">
-  <title>Codex 多角色项目推进总流程图｜V2.0</title>
+  <title>Codex 多角色项目推进总流程图｜V2.1</title>
  <style>
    :root{--ink:#182d42;--muted:#586b7b;--navy:#112e49;--blue:#236fa3;--teal:#087f7a;--amber:#95601b;--line:#d9e3e9;--paper:#f3f6f8;--soft:#eaf5f3}
    *{box-sizing:border-box}html{scroll-behavior:smooth;scroll-padding-top:24px}body{margin:0;background:var(--paper);color:var(--ink);font:16px/1.75 "Microsoft YaHei","PingFang SC",system-ui,sans-serif}a{color:var(--blue);text-underline-offset:3px}h1,h2,h3,p{margin-top:0}h1{font-size:clamp(30px,4vw,48px);line-height:1.35;margin-bottom:20px}h2{font-size:26px;line-height:1.45;margin-bottom:16px}h3{font-size:18px;margin-bottom:10px}p{margin-bottom:12px}ul,ol{margin:10px 0;padding-left:24px}li+li{margin-top:6px}strong{font-weight:700}
@@ -20,7 +20,7 @@
 <body>
  <header class="hero" id="top">
    <div class="hero-inner">
-      <div class="eyebrow">CODEX · 多角色项目流程 · V2.0</div>
+      <div class="eyebrow">CODEX · 多角色项目流程 · V2.1</div>
      <h1>中心下发任务，真人交付结果<br>按八个阶段推进项目</h1>
      <p>真人角色负责组织和完成工作，提交完成情况与结果性资料。中心整理结果，由中心真人项目负责人决定进入下一环节、补充、退回或暂缓。</p>
      <span class="badge">保留八阶段</span><span class="badge">真人角色负责执行与提交</span><span class="badge">中心真人负责人决定推进</span>
@@ -29,12 +29,13 @@
  <main class="wrap">
    <section class="section" id="version">
      <div class="kicker">版本与适用范围</div>
-      <h2>V2.0：根据项目实施反馈调整任务流转</h2>
-      <p><strong>编制日期：2026-09-30。</strong>本版依据本次已确认的优化要求编写：中心按阶段下发任务；真人角色自行组织执行；完成后提交任务完成情况和结果性资料；中心依据结果决定是否推进。保留八阶段，并按审阅意见合并业务需求文档、将风险纳入立项资料、以链接提供缺陷信息、记录延期成果、增加项目与产品双方核实后的版本放行方式，区分内部与外部验收。</p>
-      <div class="note"><strong>当前流程基线为 V2.0。</strong>V1.0 原文通过 Git 历史保留，仓库中的 <a href="../ep-hub/SKILL.md">中心业务 Skill</a> 已按本版流程及经确认的任务留档方案整理；Etunel 配置与通信使用 etunel-use。源文件更新不表示已安装或部署，也不自动迁移在途项目，具体项目采用与配置变更按明确授权执行。</div>
-      <p class="small">历史对照：<a href="https://git.playones.com/chenmingxuan/EP-Hub-Skill/src/commit/3fb9c0658de56c3914f5b27c2df1f415bd73661d/doc/Codex多角色项目推进总流程图.html">V1.0 原流程文档（Git 历史）</a>。模板来源：<a href="文档模板参考/README.md">文档模板参考</a>。旧文档中的过程节点用于历史对照；采用 V2.0 的项目按本版任务与结果流转执行。</p>
+      <h2>V2.1：补齐排期、成果确认、归档和结项规则</h2>
+      <p><strong>编制日期：2026-10-20。</strong>本版依据 YT42-Test2《流程更新》截至 2026-10-20 的已确认规则，在 V2.0 八阶段结构上补充阶段汇报、需求交接、工时与周期评估、预排期维护、成果查看、Bug 双方确认、完整归档及关闭后的登记要求。</p>
+      <p>沿用真人角色组织执行、提交专业结果，中心真人负责人决定推进的分工。项目中的人名、型号、日期、工时、问题数量、单次放行和豁免决定留在项目记录中；其他项目依据自身需求、授权和有效基线执行。</p>
+      <div class="note"><strong>当前固定路径采用 V2.1，历史版本通过 Git 保留。</strong>本轮已按授权同步<a href="../ep-hub/SKILL.md">中心业务 Skill</a>、记录模板及通知脚本说明。仓库更新不等于已发布、安装或迁移在途项目；Etunel 配置与通信仍使用 etunel-use。</div>
+      <p class="small">历史对照：<a href="https://git.playones.com/chenmingxuan/EP-Hub-Skill/src/commit/3fb9c0658de56c3914f5b27c2df1f415bd73661d/doc/Codex多角色项目推进总流程图.html">V1.0 原流程文档（Git 历史）</a>。模板来源：<a href="文档模板参考/README.md">文档模板参考</a>。旧文档中的过程节点用于历史对照；各项目按已确认采用的流程版本执行；本页展示 V2.1 的任务与结果要求。</p>
      <nav class="nav" aria-label="文档导航">
-        <a href="#rules">共同规则</a><a href="#records">成果与过程留档</a><a href="#overview">八阶段总览</a><a href="#stage1">01 业务需求</a><a href="#stage2">02 产品定义</a><a href="#stage3">03 方案设计</a><a href="#stage4">04 项目规划</a><a href="#stage5">05 软硬件实现</a><a href="#stage6">06 测试验证</a><a href="#stage7">07 内部／外部验收</a><a href="#stage8">08 复盘结项</a><a href="#exceptions">变更与阻塞</a><a href="#templates">任务与提交格式</a>
+        <a href="#rules">共同规则</a><a href="#reporting">阶段汇报</a><a href="#notifications">阶段群总结</a><a href="#records">成果与过程留档</a><a href="#overview">八阶段总览</a><a href="#stage1">01 业务需求</a><a href="#stage2">02 产品定义</a><a href="#stage3">03 方案设计</a><a href="#stage4">04 项目规划</a><a href="#schedule-template">预排期格式</a><a href="#stage5">05 软硬件实现</a><a href="#stage6">06 测试验证</a><a href="#stage7">07 内部／外部验收</a><a href="#stage8">08 复盘结项</a><a href="#exceptions">变更与阻塞</a><a href="#templates">任务与提交格式</a>
      </nav>
    </section>

@@ -47,7 +48,7 @@
        <div class="step"><div class="num">03 · 真人角色</div><h3>提交完成情况与资料</h3><p>提交专业结论、实际成果及版本、完成情况、必要授权结论和遗留问题。</p></div>
        <div class="step"><div class="num">04 · 中心</div><h3>确认是否推进</h3><p>中心 Agent 整理结果，中心真人负责人决定推进、补充、退回或暂缓，并留下记录。</p></div>
      </div>
-      <p>这个循环适用于每项任务和阶段收口。同一阶段可有多项任务，每项任务只有一个主责真人角色。单项任务被接受后，可启动依赖已经满足的后续任务；进入下一阶段仍须由中心真人负责人确认本阶段结果。</p>
+      <p>这个循环适用于每项任务和阶段收口。同一阶段可有多项任务，每项任务只有一个主责真人角色。单项任务被接受后，可启动依赖已经满足的后续任务；跨阶段推进须取得中心真人负责人明确决定；已有条件授权的，条件实际满足后按原范围执行并登记依据，不重复申请同一批准。推进不把未交或待确认成果改写为已完成。</p>
      <div class="note"><strong>成果不能如期交付时：</strong>真人角色可提交中心真人负责人确认，说明待交成果、延期原因、影响及计划交付时间。真人确认后，由中心 Agent 记录待交项、责任人、新交付时间和确认决定；在每个阶段结束时提醒中心真人负责人及相关责任角色，直至交付或另有明确处理决定。是否推进由中心真人负责人依据实际影响决定，延期成果仍记为未交付。</div>
      <div class="table-wrap"><table>
        <caption>谁负责什么</caption>
@@ -70,9 +71,13 @@
      <h3>中心按结果确认</h3>
      <ul>
        <li>中心 Agent 将提交内容与下发的完成条件对应，整理已完成项、缺失项、成果与版本、专业结论、必要授权、依赖和剩余风险，交中心真人负责人决定。</li>
+        <li>请求中心真人确认成果前，逐项提供本次范围涉及的全部有效文件名、版本、确认用途及可点击完整地址，或直接展示对应文件。已有索引可引用，但须能定位本次涉及的各份文件；不能只给总目录、摘要或中心确认记录。</li>
+        <li>沿已有成果身份和真实入口交接；包内内容可引用有效索引，缺项和可访问范围如实说明。只补入口时不重复申请已有效的结果确认，不编造路径或声称尚未提供的文件已供查看。</li>
+        <li>可读可用和专业结论由有权真人确认。Agent 无法访问成员磁盘或共享目录，只说明本端访问失败，不据此判定未提交、文件不存在或成果不兼容；不把 Agent 下载、解包、截图或重算哈希设为固定推进前置。</li>
        <li>中心可以针对影响完成判断的缺口提出补充要求，说明缺什么、影响什么；不要求证明全部工作过程或重复提交同一有效资料。</li>
        <li>中心真人负责人决定推进时，明确接受的结果、版本和适用范围。退回或暂缓时，明确原因、待处理事项、责任角色及下一步。</li>
        <li>测试结论与版本放行决定分别记录。测试不通过时，项目、产品双方真人可共同确认核实，以核实结论作为版本放行依据；保留原测试结论，并记录版本、未通过项、影响、放行条件及双方确认。外部验收结果和预算授权仍由有权角色确认。</li>
+        <li>文件或需求有差异时，由有权真人明确采用内容、对象、版本和影响范围。当前文件同步、过去审阅对象和差异对既有结论的影响分别记录，不补造历史审阅事实。</li>
        <li>同一成果、版本和范围的有效确认继续沿用。只有实质变化、用途超出原范围或出现相反证据时，才补充相应结果和确认；尚未完成或未经真人确认的材料只进入过程记录。</li>
      </ul>
      <div class="note"><strong>八个默认角色保持不变：</strong>项目Hub（中心）、业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件、测试。阶段 4、8 由中心真人负责人组织，相关真人角色提供具体工作与结果，中心 Agent 协助整理。新增角色仍须先明确职责契约，由中心真人负责人完成实际配置。</div>
@@ -80,15 +85,48 @@
      <a class="back" href="#top">返回顶部 ↑</a>
    </section>

+    <section class="section" id="reporting">
+      <div class="kicker">先汇报结果，再决定阶段安排</div>
+      <h2>中心主动提交阶段成果汇总</h2>
+      <p>本阶段任务均取得所需真人完成确认后，中心 Agent 须主动在中心持续聊天提交汇总。成果已交但必要确认未齐，或仍有未完成、延期、拟承接事项需要中心判断时，同样提交汇总；成果、版本、确认或遗留发生实质变化时补充说明。仅更新本地记录不算已向中心真人汇报。</p>
+      <div class="table-wrap"><table><caption>汇报中逐项说明什么</caption><thead><tr><th>内容</th><th>必须说明</th></tr></thead><tbody>
+        <tr><td>阶段概况</td><td>项目、阶段、汇报日期；全部确认完成、部分完成或已交待确认；本次需要的决定。</td></tr>
+        <tr><td>任务与成果</td><td>唯一主责真人、必需／选填、适用完成条件、应交／已交、版本及有效文件入口；成果包说明内容与缺项。</td></tr>
+        <tr><td>确认与时间</td><td>确认人、真实确认时间、对象／版本、结论、范围及条件；原计划、当前计划、提交与确认后实际完成时间。</td></tr>
+        <tr><td>未完成与待确认</td><td>实际状态、原因／依赖、负责人、原计划与当前计划、影响、必须完成阶段及补齐或承接建议。选填未交、豁免、取消分别说明。</td></tr>
+        <tr><td>提请决定</td><td>接受哪些结果；推进、补充、退回或暂缓；第八阶段为是否关闭。建议与真人决定分开记录。</td></tr>
+      </tbody></table></div>
+      <div class="note"><strong>没有遗留时明确写：</strong>“未完成项：无；待确认项：无”。有任何未完成或待确认事项时，如实列出。选填未交不自动阻塞，也不需要豁免；外部平台要求另按实际判断。</div>
+      <p>中心决定后，沿原任务登记决定人、日期、范围、条件和下一步。带遗留推进仍保留未完成状态；阶段八保留业务结项结论和其他必要确认。尚无决定时，阶段安排保持待决定。</p>
+      <a class="back" href="#templates">查看汇报格式 ↓</a>
+    </section>
+
+    <section class="section" id="notifications">
+      <div class="note">阶段内已授权的关键进展、阻塞和失败通知继续保留，同轮合并；阶段交接固定合为一条，等待推进决定时先在中心会话汇报，实际关闭后发一次结项总结。</div>
+      <div class="kicker">项目已授权启用后执行</div>
+      <h2>每次阶段交接发送一条群总结</h2>
+      <ul>
+        <li>中心真人明确同意推进，或已有条件授权实际满足后，将上一阶段总结与下一阶段安排合成一条发送；等待决定时，先在中心持续聊天汇报，不提前写已进入下一阶段。</li>
+        <li>阶段八明确结项关闭后发送一次结项总结，说明最终成果、实际关闭结论，以及仍需跟进的遗留、责任和已确认安排。</li>
+        <li>首次须由中心真人确认发送账号、目标群和通知范围；账号或群变更时重新确认。在已确认范围内执行，不因每次交接重复申请同一授权。</li>
+        <li>先更新事实记录，再发送。写清已确认成果、未完成／待确认事项、实际推进决定，以及下一阶段已确认任务、负责人和期限；未知写待确认，不把通用职责写成本轮已派任务。</li>
+        <li>每条信息及子条目单独换行，用直接、自然的语言保留责任人、时间、条件和实际状态；总结及发送结果留在阶段过程记录，避免同一交接重复发送。</li>
+        <li>通过已确认的项目通知入口执行。请求已接受、投递成功和已读分别记录，不能代替真人接收、完成或验收；失败不阻塞主任务，结果未知时不盲目重发。</li>
+      </ul>
+      <a class="back" href="#top">返回顶部 ↑</a>
+    </section>
+
    <section class="section" id="records">
+      <div class="note"><strong>计划主表与日期口径：</strong>已有项目沿用已确认的唯一主表，新项目默认使用可编辑 Excel 八列模板，Markdown 进度只保留摘要和入口。模板不预填日期、工时、人数或迭代轮数。条件授权日期、条件实际满足日期和实际切换日期分别记录，阶段交接管理日期取实际切换日期。实际执行据真实回报更新并保留来源和历史，改动已确认日期、范围或资源安排由有权真人确认；日常状态更新不重批整表。</div>
      <div class="kicker">八阶段共同采用的留档规则</div>
      <h2>正式成果只留最终版与确认记录</h2>
      <h3>正式成果区</h3>
      <ul>
-        <li>只保存各真人角色完成并确认后的最终成果，包括文档、固件、硬件资料及其他约定产出。</li>
+        <li>保存各真人角色完成并确认后的全部有效成果及配套资料，包括文档、固件、硬件资料及其他约定产出。正式区须有有效原件／成果包，或真实完整外部入口及对应确认；不能仅放概括目录或中心确认记录，就称全部资料已归档。</li>
        <li>每项成果只登记一个最终有效版本，并保留该版本对应的真人确认记录。</li>
        <li>正式成果条目只列成果名称、最终版本、文件位置或链接地址；确认记录分条列出确认人、确认时间、对应成果与版本、确认结论及范围和条件。</li>
        <li>未完成项、待确认材料、候选固件、草稿及旧版不登记为最终正式成果；中心 Agent 整理、生成或收到文件均不等于真人确认。</li>
+        <li>同一文件或连贯成果包可以承载多个结果，不为凑齐名称另造文件。文件名含“草稿”“预览”时，正式状态以有效真人确认和实际采用决定为准，保留确认对象及原提交来源。</li>
        <li>成果文件正文按真人确认的最终版本保存，不因记录分区而删改成果内容。</li>
      </ul>
      <h3>过程记录区</h3>
@@ -102,7 +140,9 @@
      <h3>成果中的链接</h3>
      <ul>
        <li>正式成果通过链接交付，或成果中含有相关链接时，记录链接地址即可。</li>
-        <li>不另行复制链接内容、编写链接摘要、截图或重复下载资料作为留档要求。</li>
+        <li>外部成果登记真实完整入口、用途、版本及对应确认，不强制下载或复制全部外部文件，也不要求另作链接摘要或截图。</li>
+        <li>项目已明确授权本地复制归档时，将已取得且确认有效的原件及配套资料按阶段、成果分类复制到正式区，保留原交接资料、历史入口和路径映射；目录、索引及汇总改指正式位置。</li>
+        <li>复制或补地址日期单独记录，不替换原提交、采用、确认、实际完成或阶段起止日期；归档位置变化不重新申请已有有效确认。</li>
        <li>成果对应的真人确认仍单独保留；链接内容的核实由真人角色负责，不因留档增加中心逐项核实任务。</li>
      </ul>
      <h3>所有阶段记录都分条展示</h3>
@@ -115,12 +155,15 @@
      <p class="small">正式成果区和过程记录区分别对应阶段目录中的 <code>正式成果/</code> 与 <code>过程记录/</code>；<code>阶段记录.md</code> 按两个栏目分条展示。阶段 4、8 由中心真人负责人组织完成的成果也须经对应真人确认后，才登记最终版。</p>
      <h3>项目、阶段与任务分别记录</h3>
      <ul>
-        <li><strong>项目层：</strong>记录当前阶段、整体进度和当前需要处理的事项；未按期完成的事项持续列出原计划、当前有效计划、未完成原因、影响范围及必须完成的阶段。整体进度用阶段状态和关键成果说明，百分比须有已确认的计算依据。</li>
+        <li><strong>项目层：</strong>记录当前阶段、整体进度和当前需要处理的事项；未按期完成的事项持续列出原计划、当前有效计划、未完成原因、影响范围及必须完成的阶段。整体进度用阶段状态和关键成果说明，百分比须有已确认的计算依据。项目计划主表由中心按实际回报维护，Markdown 项目进度同步摘要；不另建一套重复任务。</li>
        <li><strong>阶段层：</strong>逐项汇总本阶段每个任务的成果、完成及确认情况，分别列负责人、应交与已交成果、版本与位置、时间、缺口、下一步和任务原记录入口。未完成和待确认情况归入过程栏目。</li>
        <li><strong>任务层：</strong>按可独立确认的交付结果或同一负责人的内聚任务包，一项一份 Markdown；前部维护现状，后部按时间追加接收、提交、退回、确认、改期等关键历史，不记录角色内部每一步操作。</li>
        <li><strong>跨阶段：</strong>同一事项沿用所属阶段的原记录，涉及阶段引用，项目层持续跟进；完成或明确处置后保留历史，承接后仍需跟进的继续显示。</li>
        <li><strong>三类时间：</strong>原计划保留首次确认期限，当前计划保留最新经确认的有效期限，每次改期保留旧值、新值、原因和真人决定；实际完成时间是任务提交后经对应真人明确确认完成的时间。提交时间另记，未确认写“尚未确认完成”，取消或豁免不写为实际完成。</li>
        <li><strong>线下确认：</strong>接受中心真人明确转述的线下接收和确认事实，保留实际确认人、真实时间、对象与版本、结论、范围和条件，以及转述人、来源和补录时间；不新增截图、审批单或重复确认。</li>
+        <li><strong>阶段管理日期：</strong>开始取中心真人实际启用该阶段的日期，完成取明确结束／进入下一阶段的决定日期，第八阶段取明确关闭日期。进行中时完成日期留空；工程开工、测试、验收发生日期另记，不用管理日期计算工程提前／延期或总人时。</li>
+        <li><strong>提交与接收：</strong>本人明确已通过其他渠道提交时据实登记，入口未给、接收可用未确认及验收结论未取得分别说明，不因本聊天无附件回退成未提交。队列待投递不推翻线下已完成事实，也不按队列等待时长判定工程延期。</li>
+        <li><strong>记录更新顺序：</strong>先更新原任务，再同步阶段摘要、项目进度及适用成果索引；需要决定或通知时，使用已更新的事实。未知不填零、不造时间、负责人、地址、专业结论或签名。</li>
        <li><strong>易读排版：</strong>标题后用一句话说明现状，各栏目分条、字段加粗、留出空行，详细历史置后；链接使用明确名称，未知信息如实标明。</li>
      </ul>
      <a class="back" href="#templates">查看分条记录格式 ↓</a>
@@ -129,18 +172,18 @@
    <section class="section" id="overview">
      <div class="kicker">八阶段总览</div><h2>每阶段都以提交结果和中心决定收口</h2>
      <div class="note"><strong>正常顺序：</strong>业务需求 → 产品定义 → 方案设计 → 项目规划 → 嵌入式软硬件实现 → 测试验证 → 内部／外部验收 → 复盘结项。测试不通过时，可安排修复、复验，也可由项目、产品双方真人核实后作出版本放行结论；验收问题回到受影响环节处理，不要求从头重启。</div>
-      <p>各阶段开始时，中心说明本阶段必须完成、后续阶段处理、当前不需要的内容。任务只覆盖当前必需项；后续资料不提前成为当前阶段的完成条件。</p>
+      <p>各阶段开始时，中心说明本阶段必须完成、后续阶段处理、当前不需要的内容。任务只覆盖当前必需项；后续资料不提前成为当前阶段的完成条件。阶段结束或需要中心判断安排时，先按<a href="#reporting">阶段汇报要求</a>提交成果、确认、遗留和有效入口，再取得推进决定。</p>
      <div class="table-wrap"><table class="overview">
        <thead><tr><th>阶段</th><th>真人工作责任</th><th>提交的正式成果</th><th>中心决定推进的结果依据</th></tr></thead>
        <tbody>
          <tr><td><a href="#stage1">01 业务需求</a></td><td>业务主责，产品参与需求对齐</td><td>业务需求（包含项目背景说明、客户里程碑要求）</td><td>业务与产品形成一致的需求基线，产品具备继续定义的输入。</td></tr>
          <tr><td><a href="#stage2">02 产品定义</a></td><td>产品主责，相关专业角色参与</td><td>立项资料（含风险）；测试验收标准；里程碑要求</td><td>产品定义完整，业务范围已批准，验收标准可判断。</td></tr>
          <tr><td><a href="#stage3">03 方案设计</a></td><td>技术负责人组织方案工作；测试编制计划</td><td>测试计划；总体技术方案（选填）</td><td>方案与接口可实施、需求未偏离、测试可验证；技术负责人认可测试计划。</td></tr>
-          <tr><td><a href="#stage4">04 项目规划</a></td><td>中心真人负责人组织，相关真人角色提供评估</td><td>项目计划；角色分工；项目状态内部记录</td><td>技术结构合理，产品确认资源与排期，必要业务授权已完成，首批任务可执行。</td></tr>
+          <tr><td><a href="#stage4">04 项目规划</a></td><td>中心真人负责人组织，相关真人角色提供评估</td><td>项目计划；角色分工；项目状态内部记录</td><td>专业评估与技术依赖明确，中心统筹总排期，产品授权范围内的具体事项及必要业务授权已确认，首批任务可执行。</td></tr>
          <tr><td><a href="#stage5">05 嵌入式软硬件实现</a></td><td>应用层、底层、硬件分别主责任务；技术负责人给出集成结论</td><td>硬件设计包；嵌入式底层实现资料；嵌入式应用层固件包</td><td>适用成果齐备，技术负责人确认最终软硬件版本匹配、可提测。</td></tr>
          <tr><td><a href="#stage6">06 测试验证</a></td><td>测试主责；修复任务由相应实现角色主责</td><td>功能测试报告；缺陷链接（选填，不交缺陷清单文件）；可靠性测试报告、专项测试报告、提测佐证（选填）</td><td>测试提交真实结论与依据；通过时由中心真人负责人确认推进，不通过时可依据项目、产品双方核实的版本放行结论推进。</td></tr>
          <tr><td><a href="#stage7">07 内部／外部验收</a></td><td>项目组织；内部验收任务交真人角色；外部验收结果由产品／业务确认</td><td>内部验收结果记入验收记录；平台验收报告或结论；客户验收通过报告；遗留问题清单</td><td>本阶段约定的内部验收完成，外部验收取得对应产品／业务确认，版本一致，问题和风险有承接。</td></tr>
-          <tr><td><a href="#stage8">08 复盘结项</a></td><td>中心真人负责人组织；各角色提供归档与复盘输入</td><td>结项资料归档；变更记录；结项报告；流程闭环总结</td><td>归档完整、复盘完成、遗留有承接，业务确认结项，中心真人负责人决定关闭。</td></tr>
+          <tr><td><a href="#stage8">08 复盘结项</a></td><td>中心真人负责人组织；各角色提供归档与复盘输入</td><td>结项资料归档；变更记录；结项报告；流程闭环总结</td><td>归档完整、复盘完成，Bug 处理或承接经中心和产品双方确认，业务确认结项，中心真人负责人决定关闭。</td></tr>
        </tbody>
      </table></div>
      <div class="note warn"><strong>必需与选填按本版各阶段说明执行。</strong>选填成果未提交不阻塞推进，无需豁免；已提供时登记版本和专业结论。缺陷信息以选填链接提供，不提交缺陷清单文件。可靠性测试报告、专项测试报告、提测佐证是否提交，由中心真人负责人决定，已有有效决定可沿用。必需成果不能如期交付时，提交真人确认、记录并逐阶段提醒；不适用或豁免另按对应规则处理。</div>
@@ -205,16 +248,28 @@
      <p class="owner">中心真人负责人组织；技术负责人、产品及执行真人角色提供任务、依赖、工期和资源评估。</p>
      <div class="triplet">
        <div class="pane"><h3>中心下发什么任务</h3><ul><li>明确规划目标，将技术结构与依赖、任务工期评估、资源与排期等工作交相应真人角色；</li><li>中心真人负责人负责组织形成计划，中心 Agent 协助汇总。</li></ul></div>
-        <div class="pane"><h3>真人提交什么结果</h3><ul><li>相关真人角色完成各自评估，中心真人负责人组织形成《项目计划》《角色分工》《项目状态内部记录》，随结果保留技术结构结论、产品资源排期确认及必要业务授权。</li></ul></div>
+        <div class="pane"><h3>真人提交什么结果</h3><ul><li>相关真人角色完成各自评估，中心真人负责人组织形成《项目计划》《角色分工》《项目状态内部记录》，随结果保留技术结构结论、产品授权范围内具体资源／排期事项的确认及必要业务授权。</li></ul></div>
        <div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 整理可执行计划、责任分工和待解决约束；</li><li>中心真人负责人确认首批任务的输入与依赖已就绪，决定进入实现阶段。</li></ul></div>
      </div>
      <div class="detail"><h3>保留的结果要求</h3><ul>
-        <li>项目计划包含任务拆分、工时评估和实际排期；技术负责人对技术结构、顺序和依赖给出结论，不要求全员重新确认整份计划。</li>
-        <li>产品确认授权范围内的资源与排期；预算、采购或对外承诺由业务批准。确认结论随规划结果提交，不由中心逐项追问内部商议过程。</li>
+        <li>项目计划包含实际工作项、工时评估、周期、依赖和排期；中心真人负责人统筹总排期与跨角色资源协调。技术负责人核实技术结构、顺序、并行及依赖，不要求全员重新确认整份计划。</li>
+        <li>应用层、底层、硬件开始评估工时时，向三方提供全部有效产品需求文档。各真人明确本人范围、已有成果及剩余工作；未估事项、投入和外部等待分别说明。</li>
+        <li>初版单列；迭代轮数不含初版，各轮内容和周期可不同。研发开发、自测与修复，独立测试与回归，以及样机、环境、器件或生产等等待分别记录，保留实际单位和起算条件。</li>
+        <li>三领域报开发周期后，汇总给技术负责人核实范围、遗漏／重复、顺序、并行、合版和软硬件依赖；核实无问题后交测试衔接初版、各轮测试和回归周期及资源。测试可以先估自身工作量，再按核实后的研发节奏完善；项目日期由中心真人统筹确认。</li>
+        <li>各角色工时沿原任务按工作项以表格记录，列主责真人、原估／当前估及单位、周期与起算条件、投入／等待、提交或确认日期、来源和状态。变更保留旧值、新值、原因及真人确认；未知不填零，工作日不直接换成人日或小时。</li>
+        <li>产品只确认对象、权限依据和范围明确的资源／排期事项，不笼统承担全项目、其他专业或工厂周期；相关专业分别提供实际评估。预算、采购或对外承诺由业务批准。已提交的有限输入按原范围登记，不扩大为全部资源已落实。</li>
        <li>角色分工写明每项任务的唯一主责、协作、人员变化和交接。相关执行角色只接收本角色任务所需的计划与资料。</li>
        <li>规划引用阶段 2《立项资料》中的风险内容，不另造风险成果或《产品资料整合》。计划可同步业务，同步回执不增加批准条件。</li>
      </ul></div>
-      <div class="gate"><strong>进入阶段 5：</strong><ul><li>计划的技术结构及问题任务已有结论，产品确认资源排期，必要业务授权完成，首批依赖就绪任务可执行；</li><li>中心真人负责人决定推进。</li></ul></div>
+      <div class="detail" id="planning-method"><h3>预排期与实际执行</h3><ul>
+        <li>采用<a href="#schedule-template">八列预排期格式</a>，工作项按真实需求、已有成果、剩余工作、依赖及资源增减；不固定套用参考任务数量、迭代轮数、人员、工时或日期。模板预排日期留空，实际编制按专业评估和中心确认填写。</li>
+        <li>每项工时为合计人时，不再乘参与人数；人数不代表资源已落实。工时、开发周期、测试周期、投入比例及外部等待保留各自含义；NA、空白保留原义，不转换为零。</li>
+        <li>客户目标、内部预计、当前有效计划和实际执行分别记录；里程碑名称、编号及完成条件按实际项目确定。客户验收与量产目标分别跟进，不因一项预计改变自动调整另一项。</li>
+        <li>中心按真人实际回报维护唯一计划主表的“实际执行情况”，记录更新日期、进展、实际起止、成果／版本／入口、确认、偏差和下一步；未回报写待登记，不用预排日期代填实际日期。</li>
+        <li>改期经中心真人明确确认后更新，原计划、旧值／新值、原因、影响和决定依据沿原任务或阶段记录保留。Markdown 项目进度同步摘要，成果确认沿原记录维护。</li>
+        <li>串行、并行与起算条件依据真实依赖确定；表中重叠不直接代表技术依赖、已开工或跨阶段授权。八阶段继续管理成果、确认和归档，每轮测试明确对应固件及硬件版本。</li>
+      </ul></div>
+      <div class="gate"><strong>进入阶段 5：</strong><ul><li>专业评估及技术依赖已有结论，中心统筹总排期，产品授权范围内的具体事项与必要业务授权完成，首批依赖就绪任务可执行；</li><li>中心真人负责人决定推进。</li></ul></div>
      <a class="back" href="#overview">返回八阶段总览 ↑</a>
    </section>

@@ -232,9 +287,12 @@
        <tr><td>嵌入式应用层</td><td>嵌入式应用层固件包</td><td>正式／升级固件、自测用例、分区表、MD5 值文件、Flash 烧写固件、zn_debug 文件、Changelog、串口使能证书。</td></tr>
      </tbody></table></div>
      <div class="detail"><h3>保留的结果要求</h3><ul>
+        <li>按实际依赖推进。缺少硬件、软件或环境只阻塞依赖该输入的工作，已具备部分继续执行；到样、整机、PQ、AI 及环境按真人实际回报登记，计划日期和收到输入不证明后续工作已完成。</li>
        <li>硬件真人开始设计前取得实际外设、关键器件规格书及结构板框图；缺失只影响相应硬件任务，需上游协调时向中心提出具体缺口。</li>
        <li>底层提供可消费的 BSP／PSP，应用层负责合版。统一固件与硬件候选就绪后即可组织联调；联调问题关闭后提交最终提测版。</li>
        <li>设计确认、接口协调、自测及联调由真人角色自行完成，中心不逐步核实。最终版本与软硬件匹配关系随结果提交，由技术负责人给出专业结论。</li>
+        <li>PSP 仓库／commit、BSP build 及消费入口是版本和输入信息，不直接代替最终固件身份，不把另一构建的结果写到指定最终包。已有配置提供有效 BSP 消费入口且真人明确无需独立获取时，沿原入口衔接，不重复索包或路径。</li>
+        <li>已有包身份和真实入口时，定向交相关真人确认可用性；需要补交接时只补实际缺口。Agent 访问失败不恢复为重做实现或反复上传整包的要求。</li>
        <li>底层不直接向测试交最终固件；定频测试固件只用于专项测试。不另设《硬件实现资料》，也不把硬件前置输入重新列为产出。</li>
      </ul></div>
      <div class="gate"><strong>进入阶段 6：</strong><ul><li>适用成果齐备，最终统一固件与硬件版本匹配，技术负责人明确可提测；</li><li>中心真人负责人决定推进。</li></ul></div>
@@ -245,7 +303,7 @@
      <div class="flow-title"><span class="stage-num">06</span><h2>测试验证</h2></div>
      <p class="owner">测试真人负责测试执行、缺陷信息维护与独立质量结论；修复工作由相应实现真人角色主责。</p>
      <div class="triplet">
-        <div class="pane"><h3>中心下发什么任务</h3><ul><li>交测试依据统一固件、版本矩阵和测试计划开展验证，明确必测范围、完成时间与提交要求；</li><li>三类选填资料的提交决定沿用或由中心真人负责人明确。</li></ul></div>
+        <div class="pane"><h3>中心下发什么任务</h3><ul><li>交测试依据统一固件、版本矩阵和测试计划开展验证，每轮明确固件及硬件版本、变更、必测范围、完成时间与提交要求；</li><li>三类选填资料的提交决定沿用或由中心真人负责人明确。</li></ul></div>
        <div class="pane"><h3>真人提交什么结果</h3><ul><li>测试自行组织策略、执行、缺陷协调和独立复验，提交《功能测试报告》及约定提供的选填资料，缺陷信息可提供链接，不提交缺陷清单文件；</li><li>给出通过／不通过结论、实际覆盖范围和风险。</li></ul></div>
        <div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 整理本次测试结果、被测版本与质量条件；</li><li>中心真人负责人明确确认或退回测试结果。</li><li>测试不通过时，由项目、产品双方真人确认核实，核实结论可作为版本放行依据；</li><li>中心据此记录放行及阶段推进决定。</li></ul></div>
      </div>
@@ -258,7 +316,7 @@
        <li>测试独立复验并维护缺陷状态。回归输入为统一固件、版本矩阵及必要变更说明；需要定位或复验具体缺陷时引用对应缺陷链接。只在实际需要时补充定位资料或技术负责人的版本结论，不要求中心逐轮核实修复细节。</li>
        <li>底层实现资料、硬件设计包不作为常规测试必交输入。大文件由测试保管，通过链接交付时，中心只记录链接地址及对应真人确认，不重复上传或复制文件。</li>
      </ul></div>
-      <div class="note warn"><strong>测试结果的人工确认保留。</strong><ul><li>测试真人提交后，中心真人负责人须实际查看并明确确认。</li><li>中心 Agent、已读、消息送达或工具任务完成都不能代替确认。</li><li>确认前不宣称正式测试提交完成或已进入正式验收；</li><li>实质变化后的结果或被测版本须重新提交确认。</li></ul></div>
+      <div class="note warn"><strong>测试结果的人工确认保留。</strong><ul><li>测试真人提交后，中心真人负责人须实际查看并明确确认。</li><li>中心 Agent、已读、消息送达或工具任务完成都不能代替确认。</li><li>确认前按实际记为已提交待确认，不宣称测试结果已被接受或已进入正式验收；</li><li>实质变化后的结果或被测版本须重新提交确认。</li></ul></div>
      <div class="note"><strong>测试不通过时的版本放行：</strong><ul><li>项目真人负责人和产品真人负责人共同核实不通过项、实际影响、剩余问题及处理安排，明确该版本是否放行。</li><li>核实结论写明版本、依据、放行范围与条件、遗留责任和双方确认人及时间，作为版本放行依据。</li><li>中心 Agent 保留原“不通过”测试结论，同时记录双方核实结论及后续安排；</li><li>未形成双方明确结论时，不自行放行。</li></ul></div>
      <div class="gate"><strong>进入阶段 7：</strong><ul><li>测试通过时，按约定完成测试、提交功能报告与依据，中心真人负责人确认推进；</li><li>测试不通过时，可依据项目、产品双方核实后明确作出的版本放行结论推进，并保留未通过项和放行条件。</li><li>后续成果延期须经中心真人确认并记录，放行不表示外部验收已通过。</li></ul></div>
      <a class="back" href="#overview">返回八阶段总览 ↑</a>
@@ -275,8 +333,9 @@
      <div class="detail"><h3>保留的结果要求</h3><ul>
        <li>测试真人直接向产品真人交付已完成并确认的最终测试报告及已提供的提测佐证；中心正式成果记录沿用最终版及确认。链接资料只记链接地址，不收转大文件；产品接收情况列入过程记录。</li>
        <li>验收分为内部和外部。内部验收由承担任务的真人角色执行并提交结果；外部验收由产品／业务取得实际反馈并确认。各自输入就绪时可并行开展。</li>
+        <li>平台联系、发包／寄样、收件和进度跟进按项目明确唯一主责，不默认全部由产品或中心真人亲自执行。实际执行协调、产品接收可用、平台结果及客户业务确认分别登记；职责确定不证明动作已发生。</li>
        <li>平台结果由产品确认，无需业务批准；客户验收通过报告由产品出具或更新，客户结果由业务确认。客户反馈由具备联络权限的真人取得。</li>
-        <li>同一份遗留问题清单标明内部／外部来源、实际验收方、对应版本、责任人、处置和状态。未通过时提交具体问题及需中心安排的修复或变更，回到受影响环节处理。</li>
+        <li>沿同一份共用遗留记录标明内部／外部来源、实际验收方、对应版本、责任人、处置和状态；第八阶段按<a href="#bug-confirmation">中心与产品双方确认规则</a>继续，不另要求测试提交重复缺陷清单。未通过时提交具体问题及需中心安排的修复或变更，回到受影响环节处理。</li>
        <li>返工产生新测试结果时，重新完成阶段 6 的结果确认；仍不通过而拟放行时，重新取得项目、产品双方的核实结论。版本变化影响其他验收项时，同步更新相应结果。</li>
      </ul></div>
      <div class="gate"><strong>进入阶段 8：</strong><ul><li>本阶段约定的内部验收完成，适用的外部验收取得产品／业务确认；</li><li>平台由产品确认，客户由业务确认，项目同时要求平台和客户验收时须两项均通过。</li><li>验收对象与有效版本一致，问题和风险有明确承接，中心真人负责人决定推进。</li><li>内部验收完成或版本已放行不能替代外部验收结果。</li></ul></div>
@@ -289,17 +348,39 @@
      <div class="triplet">
        <div class="pane"><h3>中心下发什么任务</h3><ul><li>向实际参与的真人角色下发资料归档、遗留承接和复盘任务，明确所需现有成果、事实及改进安排，不要求重做同内容文件。</li></ul></div>
        <div class="pane"><h3>真人提交什么结果</h3><ul><li>各真人角色提交本角色资料和复盘结论。</li><li>中心真人负责人组织形成《结项资料归档》《变更记录》《结项报告》《流程闭环总结》，中心 Agent 协助整理，业务给出结项结论。</li></ul></div>
-        <div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 汇总资料完整性、验收结论、业务结项确认和遗留承接；</li><li>中心真人负责人决定结项关闭或退回补充，留下决定与后续责任安排。</li></ul></div>
+        <div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 汇总完整成果及入口、验收结论、Bug 双方确认、业务结项确认和遗留承接；</li><li>中心真人负责人决定结项关闭或退回补充，留下决定与后续责任安排。</li></ul></div>
      </div>
      <div class="detail"><h3>保留的结果要求</h3><ul>
-        <li>正式成果归档只保留各真人角色完成并确认的最终版及对应确认记录，沿用已验收版本；有链接的成果只记链接地址。</li>
+        <li>正式成果归档收齐各阶段真人完成并确认的有效原件、成果包或真实外部入口及对应确认，沿用有效版本和配套资料；本地复制按项目明确授权执行，保留原交接与映射，不强制下载外部文件。</li>
+        <li>《结项资料归档》包含各阶段成果目录、有效完整入口、适用版本、阶段管理起止及依据，成果提交、采用和确认日期分别记录。汇总纳入第八阶段正式成果，不另造一类交付要求。</li>
+        <li>成果汇总和《结项报告》按项目已确认格式或模板编制；单工作表 Excel 可作为汇总参考，不强制其他项目使用相同工作表数量、字段粒度或报告栏目。模板中已有内容和日期依据真实记录填写，缺少工时、迭代、评审或签名时保留未知，不按文件数量推算。</li>
        <li>过程资料另行归档：旧版、草稿、历史确认、变更过程、项目进度、产品接收情况及其他过程记录均保留，不混入最终正式成果记录。</li>
        <li>复盘基于事实说明目标完成、计划偏差、协作与质量问题、经验和改进措施。改进项写入流程闭环总结，明确责任人和跟进安排，不另设正式成果。</li>
        <li>业务依据归档、复盘和遗留承接确认结项或提出补充；中心记录这一结论后决定关闭。业务不重复批准已由产品确认的平台结果。</li>
        <li>本阶段不安排冒烟、发布验证或其他测试，不要求重做发布固件。发现新的实现或质量问题，回到相应阶段处理。</li>
        <li>结项必需项完成后锁定四类结项成果；仍有延期成果时，提交中心真人负责人明确补齐或承接安排后再决定是否关闭，未交资料保留待交状态。按安排跟进遗留与改进项，结项不表示后续改进已经全部实施。</li>
      </ul></div>
-      <div class="gate"><strong>项目关闭：</strong><ul><li>约定的内部与外部验收已完成并确认，归档完整可追踪，复盘完成，遗留已关闭或落实承接，业务明确确认结项；</li><li>中心真人负责人决定关闭。</li><li>延期成果按真人确认的处理决定结清或明确承接，不能将未交付写成已归档。</li><li>模拟项目只能记录模拟完成。</li></ul></div>
+      <div class="detail" id="bug-confirmation"><h3>全部 Bug：中心先确认，产品再次确认</h3>
+        <ol>
+          <li>中心真人负责人先确认问题事实、适用版本、实际处理结果或后续承接安排；研发、测试等真人提供已有事实或专业意见。</li>
+          <li>中心将已确认内容提交产品真人负责人再次确认，并由产品在职责范围内决定处理方式。未知部分明确标出，不把中心尚未确认的事实交产品代查。</li>
+          <li>中心和产品对事实、处理结果或后续安排均无异议后，沿原任务及共用问题记录登记双方最终确认。产品提出调整时，中心协调确认受影响内容，再交产品确认；有分歧或缺少确认时保留待确认。</li>
+        </ol>
+        <ul>
+          <li>范围覆盖项目全部 Bug，包括后续发现和此前已处理的问题。已有适用的有效确认直接引用，仅补齐缺少或受变化影响的部分。</li>
+          <li>已修复、延期处理、暂不修复分别记录；未修复保留真实状态、责任人及后续安排。双方无异议不表示全部已修复，问题状态与最终处置确认分开。</li>
+          <li>逐项记录编号／名称、对象／版本、处理结果／状态、双方各自确认人、真实时间、结论、范围／条件、来源及后续责任／安排。过程事实与分歧随时登记，最终确认另记，保留历史；未知不编造。</li>
+          <li>复用原报告和共用记录，不新增测试必交清单或重做已接受测试。原不通过、版本放行及外部验收各自保留；需要新实现或验证时，按实际职责回到受影响阶段办理。</li>
+        </ul>
+      </div>
+      <div class="gate"><strong>项目关闭：</strong><ul><li>约定的内部与外部验收已完成并确认，归档完整可追踪，复盘完成，Bug 处理或承接已取得中心和产品双方确认，其他遗留已处理或落实承接，业务明确确认结项；</li><li>中心真人负责人决定关闭。</li><li>延期成果按真人确认的处理决定结清或明确承接，不能将未交付写成已归档。</li><li>模拟项目只能记录模拟完成。</li></ul></div>
+      <div class="detail"><h3>关闭决定后的登记与跟进</h3><ul>
+        <li>登记实际决定人、日期、原话、范围及条件，同步项目概览、进度、阶段、原任务、成果索引、报告和成果汇总的当前状态。锁定本次有效结项成果及目录，旧版和原交接记录保留。</li>
+        <li>停止对已结束阶段和已确认结果重复催办；队列未送达或工具未结算另记，沿原事项处理，不撤销真人关闭决定、不重派同一业务任务。</li>
+        <li>项目关闭不把原测试不通过改成通过，不把 Bug 改成已修复，不证明实际量产或出货。后续真实质量事项沿已有记录和责任渠道处理，需要新工作时按实际授权安排。</li>
+        <li>按<a href="#notifications">已授权通知规则</a>发送一次结项总结，记录实际发送结果，不因后续文档整理重复发送。</li>
+        <li>项目期间的流程补充、模板和反馈先在项目保留；完成后汇总拟纳入共享 Skill 的具体内容和文件入口，经有权真人对整合范围统一明确确认后再更新。项目关闭或本文件保存不代替整合确认。</li>
+      </ul></div>
      <a class="back" href="#overview">返回八阶段总览 ↑</a>
    </section>

@@ -315,17 +396,18 @@
        <tr><td>必需成果不适用／申请豁免</td><td>《成果豁免申请》：成果名称、适用依据、原因、事实、替代证据、影响和风险。</td><td>由中心真人负责人明确批准或拒绝。批准只满足该文件要求，测试结果确认、项目／产品版本放行核实及内部／外部验收仍按相应规则办理。</td></tr>
        <tr><td>跳转、回退或暂缓</td><td>说明触发原因、当前缺失成果、影响、风险及补齐计划。</td><td>中心真人负责人明确决定；记录原状态、目标环节与约束，保留历史，不把跳过写成通过。</td></tr>
      </tbody></table></div>
+      <div class="note"><strong>处理文件差异时：</strong>列出对象、版本、差异及影响，由有权真人明确采用口径。当前文件同步不证明历史审阅一致；不把另一型号、平台、构建或使用阶段的结论补到当前对象。已有有效确认、明确跳过的事项不恢复为前置，实质变化只补充受影响部分。</div>
      <h3>成果与过程分开留档，记录逐条展示</h3>
      <ul>
        <li>中心维护项目概览、项目进度、阶段记录和成果索引，按正式成果和过程记录分区、分条更新。</li>
        <li>正式成果目录及当前成果索引只登记真人完成并确认的最终成果及对应确认，不混入任务状态、草稿、旧版或推进决定。</li>
        <li>中心 Agent 在过程记录中登记经真人确认的延期事项；阶段结束时分条提醒待交成果、责任人、约定日期与影响，交付后更新对应条目。</li>
        <li>任务、输入基线、提交过程、退回、阻塞、中心决定和下一步进入过程记录；旧版、草稿及历史确认也在过程记录中保留。</li>
-        <li>正式成果中有链接，只记录链接地址；不重复下载或复制链接内容。确认记录与成果关联保存。</li>
+        <li>外部链接成果登记真实完整入口及对应确认，不强制重复下载；本地已取得有效资料的复制归档按项目授权办理，保留来源与映射，不能只用概括目录代替有效成果。</li>
        <li>同一有效成果不重复制作或确认；新版经真人确认后更新最终成果条目，旧版移入过程记录并保留替代关系，不删除历史。</li>
        <li>不适用、未执行、失败、延期和豁免分别说明；未验证内容不写为通过。模拟材料和真实结果分开，模拟完成不代表发布、客户验收或生产就绪。</li>
      </ul>
-      <p class="small">预算、采购、对外承诺和暂停／取消等业务授权仍由业务负责；授权范围内的资源排期由产品确认。中心真人负责项目推进与成果豁免，不能借推进决定代替其他必要授权。</p>
+      <p class="small">预算、采购、对外承诺和暂停／取消等业务授权仍由业务负责；产品只确认明确授权范围内的具体资源／排期事项，中心真人统筹项目总排期与协调。中心真人负责项目推进与成果豁免，不能借推进决定代替其他必要授权。</p>
      <a class="back" href="#top">返回顶部 ↑</a>
    </section>

@@ -339,6 +421,34 @@
        <tr><td>完成条件</td><td><ul><li>能够按结果判断的条件；</li><li>须提交的专业结论及授权，不列内部操作检查清单。</li></ul></td></tr>
        <tr><td>执行中反馈</td><td><ul><li>只有影响任务完成的阻塞或需中心决定的变更及时提交；</li><li>其他工作由真人自行组织。</li></ul></td></tr>
      </tbody></table></div>
+      <h3>中心聊天中的阶段成果汇报</h3>
+      <ul>
+        <li><strong>概况：</strong>项目、阶段、汇报日期、全部确认完成／部分完成／已交待确认、本次需决定事项。</li>
+        <li><strong>成果：</strong>逐项列任务／成果、主责真人、必需／选填、实际状态、已交版本与全部有效文件入口、确认人／时间／范围／条件。</li>
+        <li><strong>遗留：</strong>逐项列状态、责任、原计划／当前计划、原因／依赖、影响、必须完成阶段和补齐或承接建议；选填未交、豁免／取消分别说明。</li>
+        <li><strong>时间与记录：</strong>任务提交、确认后实际完成、阶段管理日期分别记；引用完整原记录，突出改期和相对上次汇报的实质变化。</li>
+        <li><strong>请中心决定：</strong>接受哪些结果、推进／补充／退回／暂缓或结项关闭、遗留处理建议；决定未取得时写待明确。</li>
+      </ul>
+      <h3>角色工时与研发／测试衔接记录</h3>
+      <div class="table-wrap"><table class="template"><thead><tr><th>栏目</th><th>记录内容</th></tr></thead><tbody>
+        <tr><td>角色与范围</td><td>角色、唯一主责真人、工作项、需求及输入版本、已有成果与剩余工作。</td></tr>
+        <tr><td>工时</td><td>原估／当前估、单位、投入及人数、本人提交／确认日期、来源、状态；真实实际工时另记。</td></tr>
+        <tr><td>周期</td><td>初版单列；初版后的各轮内容、开发／自测／修复、独立测试／回归、起算条件、投入和外部等待分别说明。</td></tr>
+        <tr><td>核实与交接</td><td>技术负责人核实人／日期、对象版本、范围、依赖及结论；交测试的版本／范围／渠道和实际接收；测试衔接及资源要求。</td></tr>
+        <tr><td>变更与日期</td><td>旧值、新值、原因、影响及真人确认；中心统筹确定的有效日期及依据。估算、资源承诺和实际完成分别记。</td></tr>
+      </tbody></table></div>
+      <h3 id="schedule-template">项目预排期：八列格式</h3>
+      <p>模板预排日期保持为空。实际编制时按本项目真实工作填写，不套用其他项目日期、任务数量或工时；未知写待评估／待确认。下表只展示列结构。</p>
+      <div class="table-wrap"><table><caption>预排期与实际执行主表</caption><thead><tr><th>里程碑</th><th>工作项</th><th>预排开始日期</th><th>预排结束日期</th><th>预排工时/人时</th><th>负责角色</th><th>参与人数</th><th>实际执行情况</th></tr></thead><tbody><tr><td>&nbsp;</td><td>&nbsp;</td><td>&nbsp;</td><td>&nbsp;</td><td>&nbsp;</td><td>&nbsp;</td><td>&nbsp;</td><td>&nbsp;</td></tr></tbody></table></div>
+      <p class="small">每项任务唯一主责真人、完成条件、原估／当前估和改期依据沿原任务记录维护；参与人数不再乘工时。“实际执行情况”按真实回报登记进展、时间、成果／版本／入口、确认、偏差及下一步，不把空白或待登记当作未开工／未完成。</p>
+      <h3>结项归档成果目录与阶段日期</h3>
+      <p>作为《结项资料归档》的一部分，按阶段和成果逐项提供有效入口及日期；可参照以下字段。项目选择单工作表 Excel 时，在同一表中逐项登记；其他格式按项目明确要求执行。</p>
+      <div class="table-wrap"><table class="template"><thead><tr><th>栏目</th><th>参考字段</th></tr></thead><tbody>
+        <tr><td>阶段管理</td><td>阶段名称、开始日期、完成日期、当前状态、起止决定及依据；进行中时完成日期留空。</td></tr>
+        <tr><td>成果与入口</td><td>成果名称、文件名／入口用途、版本／对象、成果状态、完整可点击路径／地址及类型。</td></tr>
+        <tr><td>提交与确认</td><td>成果提交、正式采用、真人确认日期及记录、确认人、来源、范围／条件；实际工程发生日期另列。</td></tr>
+        <tr><td>说明与变化</td><td>缺项与待办、实际后续安排、正式路径与原交接映射；已有包内资料沿有效索引，不重复展开。</td></tr>
+      </tbody></table></div>
      <h3>阶段记录：正式成果及确认记录</h3>
      <ul>
        <li><strong>最终成果：</strong>每项成果独立列出。
@@ -368,6 +478,8 @@
        <li><strong>延期、阻塞与风险：</strong>每个事项单列，子项分别写原因、影响范围、责任人、原计划与当前计划日期、必须完成的阶段、真人确认和阶段结束提醒情况；跨阶段引用原记录并持续显示在项目层。</li>
        <li><strong>中心决定：</strong>每次推进、补充、退回或暂缓决定单列，子项分别写决定人、时间、依据、适用范围和理由。</li>
        <li><strong>版本放行：</strong>测试不通过而放行时，分条关联原测试结论、项目／产品双方核实结论、版本、放行范围与条件。</li>
+        <li><strong>Bug 双方确认：</strong>逐项列问题、对象／版本、实际处置状态、中心及产品各自确认人／时间／结论／条件、来源与后续安排；过程分歧和最终确认分开。</li>
+        <li><strong>阶段与关闭：</strong>实际启用／结束或关闭决定日期及依据、状态同步、有效成果锁定和停止重复催办情况；群总结及实际发送结果另记。</li>
        <li><strong>下一步：</strong>每项任务或待办单列，子项分别写主责真人角色、期限、依赖和承接安排。</li>
      </ul>
      <div class="note"><strong>成果确认与推进决定分开保存。</strong>真人对最终成果的确认保留在正式成果确认记录中；中心是否推进、为什么推进以及后续安排列入过程记录。阶段 6 的测试成果确认保留为对应正式确认，测试不通过后的核实与放行决定列入过程记录。</div>
@@ -375,6 +487,6 @@
      <a class="back" href="#top">返回顶部 ↑</a>
    </section>
  </main>
-  <footer>Codex 多角色项目推进总流程图 · V2.0 · 2026-09-30 编制<br>固定路径维护当前文档，V1.0 原文通过 Git 历史保留。中心 Skill 源文件已同步，安装、配置部署及在途项目采用按明确授权执行。</footer>
+  <footer>Codex 多角色项目推进总流程图 · V2.1 · 2026-10-20 编制<br>依据《流程更新》截至 2026-10-20 的已确认规则及本轮实施口径整合。固定路径维护当前流程，历史由 Git 保留；仓库更新与配置部署、在途项目采用分别办理。</footer>
 </body>
 </html>
@@ -11,8 +11,8 @@ description: 作为项目中心，按八阶段管理交付任务、真人确认

 - 按可独立确认的交付结果管理任务；同一负责人承担的内聚工作可组成任务包。每项任务有一名主责真人、明确输入、范围、结果、期限与完成条件，不拆成中心监督的内部步骤。
 - 真人可以直接协作，任务接收与结果提交可以在线下完成；必须保留实际接收、提交和确认的依据。成员 Agent 之间的信息仍经中心定向中继。
- 同一阶段内，任务确认完成后可启动依赖已经满足的后续任务；跨阶段推进须取得中心真人明确决定。中心决定不能替代专业判断、业务授权、产品资源排期确认或外部验收。
- 正式成果只保存真人完成并确认的最终有效版本及确认记录；草稿、旧版、历史确认和中心推进决定进入过程记录。链接交付只记录地址，不要求复制、截图或重新下载。
+- 同一阶段内，任务确认完成后可启动依赖已经满足的后续任务；跨阶段须有中心真人明确决定，已有条件授权实际满足后按原范围执行并记录依据，不重复申请。中心决定不能替代专业判断、业务授权、产品授权范围内的资源排期确认或外部验收。
+- 正式成果保存真人完成并确认的全部有效成果、配套资料或完整外部入口及确认；草稿、旧版、历史确认和中心推进决定进入过程记录。链接交付不强制下载、截图或复制；本地复制按项目明确授权处理。
 - 实际完成时间是任务提交后，经对应真人明确确认完成的时间。提交、送达、已读、Agent 检查或工具任务完成都不能替代这一确认。
 - 项目层持续显示当前阶段、整体进度、当前待处理事项，以及未完成事项的原计划、当前计划、影响范围和必须完成的阶段；跨阶段沿用原任务记录。
 - 不重复要求已有有效确认；成果或版本发生实质变化、适用范围扩大或出现相反证据时，仅重新确认受影响部分。
@@ -23,14 +23,16 @@ description: 作为项目中心，按八阶段管理交付任务、真人确认
 | 要做什么 | 读取什么 |
 | --- | --- |
 | 接收请求、组织交付任务、收取结果或交接阶段 | [中心工作流](references/hub-workflow.md) |
+| 向中心真人汇报阶段结果、请求推进或执行条件授权 | [阶段汇报与推进决定](references/stage-reporting.md) |
 | 判断阶段、应交成果和推进条件 | [八阶段与结果要求](references/project-lifecycle.md)，只读当前阶段及受影响阶段 |
-| 建立目录、更新任务、阶段和项目进度 | [记录与留档](references/project-records.md)，其中链接五类 Markdown 模板 |
+| 评估工时、衔接周期、编排或更新计划主表 | [工时、周期与项目计划](references/project-planning.md) |
+| 建立目录、更新任务、阶段和项目进度 | [记录与留档](references/project-records.md)，按需使用其中的记录模板 |
 | 判断成果、真人确认、版本替换或完成时间 | [成果与确认](references/artifacts-and-confirmation.md) |
-| 处理延期、阻塞、变更、退回、豁免或放行 | [异常与决定](references/exceptions-and-decisions.md) |
+| 处理延期、阻塞、变更、退回、豁免、放行或 Bug 双方确认 | [异常与决定](references/exceptions-and-decisions.md) |
 | 配置中心与成员、使用 Etunel 或排障 | [Etunel 分工](references/etunel-boundary.md)，再使用已安装的 etunel-use 对应参考 |
 | 选择旧模板、历史样例或外部成果格式 | [模板复用](references/document-templates.md) |
 | 编写或发送钉钉项目通知、提醒真人 | [通知规则与消息模板](references/dingtalk-progress-reporting.md)；实际调用时再读其脚本用法 |

 ## 本轮输出

-用简洁中文逐条说明已确认进展、需要处理或决定的事项、遗留及影响。先更新事实记录，再依据授权交接、推进或通知。未知的负责人、时间、确认与影响如实标明，不能为补齐格式编造事实，也不把一次问答变成新的交付文件。
+用简洁中文逐条说明已确认进展、需要处理或决定的事项、遗留及影响。先更新事实记录，再主动在中心会话汇报阶段结果；只更新文件不算汇报。需要真人查看时逐项提供本次全部有效成果入口。再依据授权交接、推进或通知。未知的负责人、时间、确认与影响如实标明，不能为补齐格式编造事实，也不把一次问答变成新的交付文件。
@@ -25,10 +25,13 @@
 ## 成果与确认

 - **接收情况**：记录真人实际接收时间及依据；只有发送证据时标为接收待确认。
- **提交情况**：每次提交单列提交人、时间、成果版本和保存位置。
+- **提交情况**：每次提交单列提交人、时间、成果版本和完整入口、用途；本人说明其他渠道已提交时据实登记，入口缺失、接收待确认与验收待确认分别列出。
 - **完成情况**：说明已完成、未完成部分及具体缺口。
 - **确认情况**：每项单列确认人、真实确认时间、任务／成果及版本、结论、范围和条件。
 - **确认来源**：记录直接确认或线下转述；转述保留实际确认人、转述人、来源及补录时间。
+- **采用与存放调整**：适用时分别记录采用对象和日期、本地复制授权、原路径到正式路径映射及操作日期，不覆盖原提交或确认日期。
+
+需要评估时在此嵌入 [工时与周期栏目](工时与周期评估.md)；涉及 Bug 时沿原问题／共用记录保留中心先确认、产品再次确认的 [字段与历史](../../references/exceptions-and-decisions.md#bug-处理与双方最终确认)。生成实际项目记录时仅保留适用内容和真实入口，不将模板链接当项目事实。

 ## 下一步与影响

@@ -0,0 +1,35 @@
+# 工时与周期评估栏目
+
+> 使用指引：仅在需要评估时嵌入原任务记录；按真实工作项展开，不另建一套任务。先列已交接的全部有效需求文件和版本入口。各角色内部执行方法自行决定。
+
+## 工作范围
+
+- **主责真人／角色**：填写已确认分工。
+- **需求输入**：逐项列全部有效文件、版本和入口。
+- **已有成果与剩余工作**：分别说明。
+- **未估项**：说明缺什么信息及受影响部分；不能把未知填零。
+
+## 工作项评估
+
+| 工作项／初版或轮次 | 主责真人 | 原估值及单位 | 当前估值及单位 | 周期及起算条件 |
+| --- | --- | --- | --- | --- |
+| 按真实工作项填写 | 按实际分工填写 | 保留首次评估 | 保留有效评估 | 周期与人时分开 |
+
+### 对应工作项的条件与依据
+
+- **投入与人数**：记录可投入情况及资源是否已确认。
+- **外部等待**：单列条件、等待周期及来源。
+- **提交**：实际提交人、时间、版本及入口。
+- **确认**：确认人、时间、对象、结论、适用范围及来源。
+- **当前状态**：区分已估、待补充、待确认及已确认。
+- **评估变更**：保留旧值、新值、原因和真人确认，关联原任务关键历史。
+
+初版单列，后续迭代不包含初版。开发／自测／修复、独立测试／回归和外部等待分别记录。工作日不直接换算成人日或小时。
+
+## 技术核实与测试衔接
+
+- **技术核实**：记录技术负责人、真实日期、核实的对象及版本、范围／依赖和结论，引用原任务已有有效确认。
+- **交给测试**：记录实际交接日期、版本、范围及渠道。
+- **测试接收与衔接**：记录实际接收人、时间和依据，以及初版、各轮、回归的周期与资源衔接结论；未知部分标明待确认。
+
+沿用已有确认和接收记录，仅补实际缺口，不为此重批评估或另建交接文件。
@@ -7,5 +7,6 @@
 ### 成果名称

 - **当前最终版本**：记录实际有效版本。
- **位置或链接**：只填写实际文件或链接地址，不复制外部内容。
+- **位置与用途**：逐项登记全部有效原件／包、配套资料或真实完整外部入口与用途；包内容可引用有效索引，不强制复制外部内容。
 - **确认记录**：链接对应阶段的正式确认栏目，确认详情由那里统一维护。
+- **存放调整**：适用时关联本地复制授权、原位置与正式位置映射、操作日期；不改原提交、采用或确认时间。
@@ -0,0 +1,32 @@
+# 结项资料归档
+
+> 使用指引：作为既有《结项资料归档》的内容结构，沿用项目已确认格式，不新增第五类结项成果。以下说明替换为真实资料与依据。
+
+## 归档范围
+
+- **项目与范围**：明确实际采用的版本和本次整理范围。
+- **当前成果索引**：关联项目唯一成果索引。
+
+## 各阶段有效资料
+
+### 阶段名称
+
+- **管理开始日期与依据**：中心真人实际启用；条件授权时记录实际切换。
+- **管理完成日期与依据**：明确结束／下一阶段决定；条件授权交接取实际切换日期，阶段八为关闭日期，进行中留空。
+- **工程实际日期**：按实际需要分别记录开发、测试和验收日期及来源。
+
+#### 成果名称
+
+- **有效版本与用途**：列每项成果、配套资料及包内容；一包多成果可引用有效内容索引。
+- **完整入口**：已保存原件／包的实际路径，或真实完整外部地址；不能只列概括目录。
+- **提交与采用**：分别记录真人、日期、对象、范围及依据。
+- **最终确认**：记录确认人、真实日期、对象版本、结论、范围与条件。
+- **原任务及过程记录**：关联原任务、旧版和历史确认。
+- **本地复制或地址调整**：适用时记录授权、原路径与现路径映射、操作日期；不得覆盖原提交、采用、确认或完成时间。
+
+## 关闭及承接
+
+- **Bug 处理与承接**：引用原报告／共用记录中的中心和产品双方最终确认，保留未修复事实与后续责任。
+- **其他遗留**：逐项列状态、责任、原计划、当前计划、影响及必须完成阶段。
+- **业务结项确认与中心关闭决定**：分别列真人、日期、原话、范围、条件和依据。
+- **关闭后登记**：记录概览、进度、阶段、原任务、索引、报告与汇总的同步情况，以及有效成果锁定和停止重复催办情况。
@@ -0,0 +1,33 @@
+# 阶段成果汇报
+
+> 使用指引：可直接作为中心聊天的汇报结构；也可写入阶段过程记录。不新增正式成果要求。将以下说明替换为真实事实。
+
+## 当前阶段
+
+- **项目与汇报日期**：记录项目名称和本次真实汇报日期。
+- **阶段与状态**：记录阶段编号、名称、当前情况及管理开始／完成日期；进行中完成日期留空。
+- **本轮需要决定**：说明推进、补充、退回、暂缓或承接的具体事项。
+
+## 逐项任务与成果
+
+### 任务名称
+
+- **主责真人与完成情况**：记录实际负责人、完成部分和未完成部分。
+- **应交成果**：逐项列必需／选填及适用条件。
+- **已交成果**：每份单列名称、版本、确认用途和完整可点击入口；同一成果包可引用有效内容索引。
+- **确认情况**：逐项列确认人、真实时间、对象、结论、范围、条件和来源；缺失确认单列。
+- **时间**：分别列原计划、当前计划、提交时间和提交后真人确认的实际完成时间。
+- **原任务记录**：引用唯一原记录。
+
+## 未完成与待确认
+
+- **事项**：每项单列状态、原因、依赖、主责、原计划、当前计划、影响及必须完成阶段。
+- **需要的决定**：列已有安排、建议和待决定内容，分别标明。
+
+确实没有时写“未完成项：无；待确认项：无”。资料不足时说明待核实部分。
+
+## 下一步安排
+
+- **建议**：按当前事实提出下一步。
+- **已有决定或条件授权**：记录真人、原话、日期、范围与条件；条件满足及实际切换日期另记。
+- **仍待决定**：列需要谁确认什么，以及确认后的动作。
@@ -3,7 +3,9 @@
 > 填写指引：标题改为阶段编号与名称，紧接一句当前情况。下面两个栏目分别保存最终成果和任务过程；每个任务都要逐项汇总。

 - **阶段状态**：记录未开始、进行中、待确认、已完成或实际例外状态。
- **阶段时间**：记录已约定计划、实际进入与阶段决定时间。
+- **管理开始日期与依据**：中心真人实际启用日期；条件授权时取实际切换日期。
+- **管理完成日期与依据**：明确结束或进入下一阶段的决定日期；条件授权交接取实际切换日期，阶段八取明确关闭日期，进行中留空。
+- **工程实际日期**：按实际需要另记开发、测试和验收日期，不以管理日期计算工程延期或人时。
 - **当前情况**：概括本阶段完成到哪里。

 ## 正式成果及确认记录
@@ -12,7 +14,8 @@

 - **成果名称**：每项最终成果独立列出。
 - **最终版本**：记录真人完成并确认的当前有效版本。
- **保存位置**：使用实际文件位置或外部链接。
+- **保存位置与用途**：逐项给全部有效文件、配套资料或包内有效索引的完整实际入口及用途；不能只列总目录。
+- **提交与采用**：分别记录实际日期、对象和来源；复制或补地址日期另记。

 ### 对应真人确认

@@ -33,6 +36,7 @@
 - **确认情况**：列已确认人、时间、对象、结论和未完成的必要确认。
 - **原计划完成时间**：记录首次期限。
 - **当前计划完成时间**：记录最新有效期限。
+- **实际提交时间**：记录本人提交事实与来源；线下已交但入口缺失时分别说明。
 - **实际完成时间**：任务提交后经真人明确确认完成的时间；未确认写“尚未确认完成”。
 - **影响及下一步**：列责任、动作、必须完成的阶段及跨阶段承接。
 - **任务原记录**：链接该任务的唯一记录。
@@ -40,5 +44,19 @@
 ### 阶段决定与未完成事项

 - **决定**：每次单列决定人、时间、推进／补充／退回／暂缓结论、依据、范围和理由。
+- **条件授权**：适用时分别记原授权日期、原话、条件、条件实际满足日期与依据、实际切换日期；不倒填已推进。
 - **未完成事项**：逐项引用原任务，列原计划、当前计划、必须完成阶段、影响、承接与阶段结束提醒情况。
 - **历史资料**：链接旧版、草稿、历史确认及替代关系。
+
+### 汇报与通知
+
+- **中心会话汇报**：记录本次汇报时间、涉及任务与成果、未完成／待确认事项及待决定内容。
+- **群总结**：记录对应交接或关闭决定、已发送正文及实际结果；区分未发送、请求已接受、送达和已读，只写有依据的状态。
+- **补充汇报**：仅实质变化时补充受影响内容；核对前次记录避免重复通知同一次交接。
+
+### 关闭后登记（阶段八适用）
+
+- **Bug 双方确认**：引用原问题或共用记录中的最终确认与分歧历史。
+- **关闭决定**：记录中心真人、真实日期、原话、范围和条件，业务结项确认另列。
+- **同步与锁定**：记录项目概览、进度、原任务、索引、报告和汇总同步情况，以及有效成果锁定情况。
+- **停止催办与后续**：停止已结束／已确认事项的重复催办；未完成承接和队列未送达分别记录。
@@ -18,6 +18,12 @@
 ## 资料与协作入口

 - **项目进度**：链接实际进度记录。
+- **唯一计划主表**：链接已确认使用的实际主表；已有项目沿用，新项目默认使用 Excel。
 - **成果索引**：链接当前有效成果索引。
 - **资料来源**：列已提供的项目资料位置。
 - **交接方式**：说明已确认的通信渠道、接收与提交方式。
+
+## 项目关闭
+
+- **关闭决定**：实际关闭后记录中心真人、日期、原话、范围、条件及依据；未关闭时不预填。
+- **承接入口**：链接仍需跟进的原任务及当前进度，保留未完成状态。
@@ -6,6 +6,7 @@

 - **更新时间**：记录本次更新的时间。
 - **当前阶段**：记录有效阶段编号、名称及推进依据。
+- **唯一计划主表**：引用实际主表，本记录只维护阶段及当前事项摘要。
 - **已完成阶段**：逐项列出，跳过或暂缓的单独说明。
 - **关键成果**：说明已经完成、待确认和缺失的关键结果。
 - **下一步**：说明待推进的工作及必要条件。
@@ -28,3 +29,8 @@
 ## 已完成或已处置

 - **事项**：每项单列完成或处置结论、真人及时间、原记录入口；仍有后续跟进的继续保留在当前事项中。
+
+## 关闭决定与后续
+
+- **决定依据**：实际关闭后引用中心真人、真实日期、原话、范围及条件。
+- **承接事项**：沿原责任与计划在当前事项中持续跟进，不把关闭写成全部 Bug 已修复或测试通过。
@@ -14,6 +14,16 @@

 中心真人可在会话中明确转述线下接收、提交或确认事实。保留实际确认人、真实确认时间、对象、结论和范围，并注明转述人、来源及补录时间；缺失信息写待补充。不要求另做审批单、截图或重复确认，不能把转述者写成专业确认人。

+本人明确已通过其他渠道提交时，登记已提交。资料入口未提供、接收人尚未确认可用、验收尚未取得结论是不同缺口，逐项记录；无聊天附件、Agent 本端无法读取或队列仍待投递不推翻线下提交事实。
+
+## 供真人查看的成果
+
+请求中心真人确认前，逐项列出本次范围内全部有效文件的名称、版本、确认用途和完整可点击地址，或直接展示文件。成果包可使用能逐项定位内容的有效索引；只给概括目录、摘要或中心确认记录不足以支持查看。
+
+专业内容和接收可用性由相应真人判断。Agent 无法读取本地盘、共享盘或外部链接，只能说明本端访问失败，不能推定成果不存在、未提交或不兼容。不把下载、解包、截图、重算哈希设成固定前置条件。已有包身份和真实入口时交相关真人确认可用，仅补实际缺口，不要求重做或反复上传。
+
+文件、需求或版本存在差异时，由有权真人决定采用的内容、对象、版本和范围。分别记录当前同步情况、历史实际审阅对象及差异对原结论的影响；不能补造历史审阅或把当前采用倒填为过去已审阅。
+
 ## 实际完成时间

 **任务提交后，经对应真人明确确认该任务完成的时间，才是实际完成时间。**
@@ -27,11 +37,13 @@

 ## 正式成果与历史

- 正式区只保存真人完成并确认的最终成果，每项一个当前有效版本。登记名称、版本、文件位置或链接；确认另列确认人、时间、对象及版本、结论、范围和条件。
+- 正式区保存真人完成并确认的全部有效成果和配套资料，每项一个当前有效版本。保存原件／包，或登记真实完整外部入口；确认另列确认人、时间、对象及版本、结论、范围和条件。概括目录或确认记录不能代替资料本身。
 - 待确认稿、部分成果、候选固件、旧版及其历史确认进入过程区。任务记录关联所有提交，阶段正式栏目只列最终成果。
 - 新版获真人确认后才替换当前条目；先保留旧文件、旧确认及替代关系到过程区，再更新正式记录，不能覆盖丢失历史。外部链接成果保留旧地址、版本、确认及替代关系；不额外下载快照，外部系统是否保留历史如实记录。
 - 中心推进、豁免、版本放行、产品接收等事实放过程记录，引用相关正式成果。名为《变更记录》《流程闭环总结》的交付文档，在真人确认最终版后仍属于正式成果。
- 链接交付只记地址与确认；内容核实由真人负责，不把复制内容、摘要、截图或可下载检查变成中心必做事项。
+- 同一文件或连贯成果包可承载多个结果，不为凑名称拆造文件。名称含“草稿／预览”不自动否定真人已确认采用的正式地位；按实际确认判断，不为分区删改成果正文。
+- 链接交付登记真实地址、用途、版本与确认；内容核实由真人负责，不强制复制、摘要、截图或可下载检查。项目明确授权本地复制时，把已取得且确认有效的原件和配套资料复制到对应阶段正式区，保留原交接记录及原路径到现路径的映射，更新索引到正式位置。
+- 复制或补地址日期单独记录，不替换提交、采用、确认、实际完成或阶段日期；未取得的原件仍如实列缺口，不能写已归档。
 - 实质变更、范围扩大或相反证据需要重新确认受影响部分；仅改存放位置、阶段引用或转述补录不自动触发重签。

 测试“不通过”可被真人确认是实际测试结论，不能因版本获放行改成“通过”。测试结果确认、版本放行、阶段推进与外部验收分别保留。
@@ -18,6 +18,14 @@

 Hub 必须先核对真实事实，更新对应任务、阶段和项目进度记录；涉及正式成果变化时再更新成果与索引，然后发送钉钉消息。不为一次通知新增成果文件。钉钉发送失败不回滚留档，也不阻塞项目主任务。

+## 阶段交接与结项总结
+
+- 每次中心真人批准推进，或已有条件授权实际满足并已执行交接后，在已启用且获授权的通知范围内，将上一阶段总结与下一阶段安排合为一条 `milestone`。标题使用实际当前阶段。
+- 等待推进决定时，先在中心会话按 [阶段汇报规则](stage-reporting.md) 说明成果、未完成项及待决定事项，不发宣称已进入下一阶段的总结；已授权的实质进展或阻塞通知仍可按实际事件发送。
+- 正文仍用“已确认的进展／待办事项／遗留”：进展写上一阶段成果和真实推进决定；待办写下一阶段全部已确认任务、主责和期限，未知字段如实说明；遗留写未完成及待确认、影响和承接。完整成果汇报放中心会话，群里可引用适合接收者访问的有效记录入口，不能为缩短篇幅遗漏待办或停止事项。
+- 第八阶段取得明确关闭决定后发送一次 `complete` 结项总结，列有效成果、关闭决定及承接事项的主责和计划。后续资料整理、补地址不重复发关闭通知。
+- 将总结正文、对应决定和实际发送结果记入阶段过程记录；生成前核对是否已通知同一次交接或关闭。复用原记录，不增加通知队列或脚本外重试。API 接受、投递和已读分别记录，未知结果不盲目重发。
+
 ## 事件判定

 ### start
@@ -34,7 +42,7 @@ Hub 必须先核对真实事实，更新对应任务、阶段和项目进度记
 - 正式阻塞解除，项目恢复到明确下一动作；
 - 统一固件、版本矩阵、测试结论、验收或发布组合形成。

-同一处理轮或同一波次合并成一条，不逐个小任务刷屏。没有固定时间间隔；依靠事件语义和去重控制频率。
+保留已授权范围内的阶段关键进展通知；同一处理轮或同一波次合并成一条，不逐个小任务刷屏。同轮发生阶段交接时合入交接总结，核对阶段过程记录避免重复。没有固定时间间隔。

 ### blocked

@@ -48,7 +56,7 @@ Hub 必须先核对真实事实，更新对应任务、阶段和项目进度记

 ### complete

-整个项目或用户明确指定的整体目标最终完成时发送一次。模拟项目必须明确写“模拟完成”，不得表达真实发布、客户验收或生产就绪。
+项目生命周期中，阶段八满足必要条件、业务已确认结项且中心真人明确关闭后发送一次。开始结项整理不使用 `complete`。用户明确指定的独立整体目标最终完成时，限定在该目标范围表述，不能冒充项目关闭。模拟项目必须明确写“模拟完成”，不得表达真实发布、客户验收或生产就绪。

 ### failed

@@ -85,7 +93,9 @@ Hub 必须先核对真实事实，更新对应任务、阶段和项目进度记
 - 结项资料整理：由中心真人负责人组织四类结项成果，Hub 协助整理工作稿。
 - 资料补充：由产品负责人、业务负责人补充现有线下成果及确认记录，不重做验收。
 - 旧事项停止：由 Hub 停止此前的验收准备催办。
- 结项确认：四类成果及遗留承接安排具备后，由 Hub 请 @示例业务负责人 确认结项。
+- Bug 事实确认：由 Hub 请 @示例中心负责人 先确认全部 Bug 的对象、版本和实际处理或承接，已有有效确认直接引用。
+- Bug 处理确认：中心确认事实后，由 Hub 请 @示例产品负责人 再次确认，并在职责内决定处理方式；双方无异议后记录最终安排。
+- 结项确认：四类成果、遗留承接及 Bug 双方确认具备后，由 Hub 请 @示例业务负责人 确认结项。
 - 关闭决定：业务确认结项后，由 Hub 请 @示例中心负责人 决定是否关闭；结项必需项完成后锁定四类成果。
 - 本轮工作范围：不新增应用修复、设备测试或发布验证。

@@ -97,6 +107,32 @@ Hub 必须先核对真实事实，更新对应任务、阶段和项目进度记

 示例标题、时间和栏目只说明最终呈现方式；调用时正文文件仅含正文，项目名、阶段标题与时间由脚本生成，不重复粘贴整条通知。

+### 已关闭项目的结项总结示例
+
+以下仅说明格式。事实、决定人、日期、有效成果入口、后续主责和期限都须替换为项目真实记录，不把此例当成关闭依据。
+
+```markdown
+**示例项目｜阶段八：复盘结项**
+
+项目进度自动汇报 · 发送时自动生成带时区的时间
+
+**已确认的进展**
+
+- 四类结项成果已取得必要确认，有效文件和入口已登记在项目成果索引。
+- 全部 Bug 的处理或承接已由中心先确认、产品再次确认，双方无异议。
+- 业务已确认结项，中心真人已明确关闭项目；决定的日期、范围和条件已记录。
+- 已同步相关记录、锁定有效成果，停止已结束阶段的重复催办。
+
+**待办事项**
+
+- 遗留跟进：请 @示例处理人 按原问题记录中的当前计划继续处理已承接事项，原计划和变更历史保留。
+
+**遗留**
+
+- 已接受延期的 Bug 尚未修复，责任、原计划、当前计划和影响沿用原记录；项目关闭不代表问题已修复。
+- 原测试不通过结论保留，版本放行、验收和关闭决定分别记录。
+```
+
 保留个人消息的 AI 标识和自动汇报说明，让群成员知道这是 Hub 自动通知，不是负责人本人新增批准、验收或承诺。

 根据事件选择必要内容：已验证进展、关键成果、下一步和责任角色；阻塞时再说明问题、影响以及需要谁采取什么动作。尽量简短，但不能为了控制篇幅省掉本轮需要决定或处理的事项。专业细节留在成果或问题系统中，通知不新建另一份问题台账。
@@ -39,14 +39,16 @@ python scripts/dingtalk_notify.py progress milestone --stage "阶段八：复盘
 - 结项资料整理：由中心真人负责人组织四类结项成果，Hub 协助整理工作稿。
 - 资料补充：由产品负责人、业务负责人补充现有线下成果及确认记录，不重做验收。
 - 旧事项停止：由 Hub 停止此前的验收准备催办。
- 结项确认：四类成果及遗留承接安排具备后，由 Hub 请 @{示例业务负责人} 确认结项。
+- Bug 事实确认：由 Hub 请 @{示例中心负责人} 先确认全部 Bug 的事实、对象、版本和实际处理或承接，已有有效确认直接引用。
+- Bug 处理确认：中心确认事实后，由 Hub 请 @{示例产品负责人} 再次确认并在职责内决定处理；双方无异议后登记最终安排。
+- 结项确认：四类成果、遗留承接及 Bug 双方确认具备后，由 Hub 请 @{示例业务负责人} 确认结项。
 - 关闭决定：业务确认结项后，由 Hub 请 @{示例中心负责人} 决定是否关闭；结项必需项完成后锁定四类成果。
 - 本轮工作范围：不新增应用修复、设备测试或发布验证。

 **遗留**

 - 原测试不通过的结果如实保留，不因进入结项阶段改为通过。
- 已接受延期的问题如实保留，后续沿用 Bug 系统中的记录和已有处理安排继续跟进。" --at "示例业务负责人" --at "示例中心负责人"
+- 已接受延期的问题如实保留，后续沿用 Bug 系统中的记录和已有处理安排继续跟进。" --at "示例业务负责人" --at "示例中心负责人" --at "示例产品负责人"
 python scripts/dingtalk_notify.py progress blocked --stage "阶段三：方案设计" "**已确认的进展**

 - 本轮无新增已确认进展。
@@ -75,6 +77,19 @@ python scripts/dingtalk_notify.py message --title "阶段三：方案设计｜
 - 脚本只接受唯一姓名匹配，自动构造个人消息所需的 `openDingTalkId` 和提及标记。查不到、重名或权限不足时停止，不让负责人手填编号，不删掉 @ 降级发送。
 - 默认且仅发配置的项目群。同一事项合成一条，事件通知可直接 @ 人，不额外重复提醒。提醒讨论结果通过已约定渠道返回并留档，不在群里另派任务或批准。

+## 阶段交接和关闭通知
+
+中心真人已批准推进或条件授权实际满足后，将上一阶段总结与下一阶段已确认安排合为一条 `milestone`。阶段内已授权的关键进展、阻塞、失败通知保留，同轮合并。等待决定时先在中心会话汇报，不宣称已进入下一阶段。
+
+项目实际关闭后，用 `complete` 发送一次结项总结，保留未修复 Bug、失败测试和已确认承接；后续整理资料不重复发送。完整示例见 [通知规则](dingtalk-progress-reporting.md)。较长正文可保存为 UTF-8 文件，先离线预览：
+
+```text
+python scripts/dingtalk_notify.py progress milestone --stage "实际当前阶段" --file "阶段交接正文.md" --at "已确认完整姓名" --dry-run
+python scripts/dingtalk_notify.py progress complete --stage "阶段八：复盘结项" --file "结项总结正文.md" --at "已确认完整姓名" --dry-run
+```
+
+正文文件和姓名须替换为实际值，正文无真人提醒时省略 `--at`。通知范围已授权且本次满足触发条件后，真实调用去掉 `--dry-run`；用户要求先审核时先取得本次发送确认。脚本仅渲染和发送，推进授权、Bug 确认和是否已发由中心查原记录判断。正文及真实结果回写阶段过程记录，不新增队列或外层重试。
+
 ## 检查与结果

 排障可用 `python scripts/dingtalk_notify.py check --at "完整姓名"`，省略 `--at` 只查登录；它联网但不发送，不是每轮必做。两个发送入口加 `--dry-run` 可完全离线预览，条目中的标记显示为“@姓名”；不查人、不验证目标或 @ 效果。
@@ -2,6 +2,8 @@

 仅在选择已有专业模板或历史样例时读取。中心维护的项目、阶段和任务模板见 [记录与留档](project-records.md)。

+项目计划的默认 Excel 模板及维护规则见 [项目计划](project-planning.md)。已有主表沿用已确认格式。结项报告和汇总按项目已确认格式制作，单工作表 Excel 仅作参考；不因模板字段齐全就补造工时、轮次、评审、签名或确认。
+
 - 从当前任务、有效流程基线、成果、平台／机型、SDK 和版本选择适用资料；不因目录有多份就全部要求提交。
 - 区分空白模板、历史样例、平台规范、器件输入与当前项目成果。只复用适用栏目和组织方式，旧人员、日期、参数、执行结果及签名不作为当前事实。
 - 角色真人决定专业内容及内部制作方法。中心不将模板每一栏变成额外任务，不要求新增内部评审步骤；结果要求按 [八阶段与结果要求](project-lifecycle.md)。
@@ -25,3 +25,21 @@
 - **测试不通过拟放行**：必须有项目、产品双方真人明确核实，记录版本、不通过项与实际影响、剩余问题及责任、依据、放行范围与条件、双方确认人和时间；原测试结果保留不通过。实质变化重新核实。

 未知影响不写“无影响”，未知责任或日期不编造；汇总为需要真人决定的具体问题。已有明确停止事项、暂不修复或无需新增清单等条件必须沿用，不借汇报重新分配。
+
+## Bug 处理与双方最终确认
+
+结项前对全部 Bug 的处理或承接核对双方确认，包含此前已处理及后续发现的问题。沿用原测试报告、Bug 系统或阶段七共用遗留记录，不要求测试再交独立清单。日常进展据实更新；以下是处理或承接结论的确认顺序，不把每次状态更新变成重复审批。
+
+1. 中心真人先确认问题事实、对象及版本、实际处理结果或承接安排。事实未确认前，不要求产品代为调查中心尚未核实的事实。
+2. 产品真人在上述事实基础上再次确认，并在自身权限内决定处理方式。产品调整处理方案时，中心协调受影响的安排，再补受影响部分的确认。
+3. 双方无异议后，在原记录登记最终结论、范围、条件与后续安排。已有适用于当前对象、版本和范围的有效确认直接引用，仅补缺失或变化部分。
+
+每项保留：
+
+- **问题**：已有 Bug 编号或名称、原记录入口、对象及版本。
+- **实际状态**：已修复、延期、暂不修复或其他真实状态；处理方式已确认不等于问题已修复。
+- **中心确认**：实际确认人、时间、事实与结论、范围、条件和来源。
+- **产品确认**：实际确认人、时间、再次确认及处理决定、权限范围、条件和来源。
+- **承接与分歧历史**：主责、下一步、原计划与当前计划、影响、必须完成阶段；保留每次调整、分歧及最终决定。
+
+双方无异议可以对应修复、延期或暂不修复，不代表全部已修复或测试通过；不因此重测已有有效验收结果。后续发现的问题依同一确认顺序处理，按原责任或新的明确授权跟进，不自动撤销既有关闭决定。
@@ -6,7 +6,7 @@

 读取当前项目概览、进度和正在处理的任务，确认有效流程基线、当前阶段、中心真人负责人、相关角色真人及已有决定。沿用已有项目记录，不因安装新 Skill 自动迁移项目或重开中心会话。实际人员与接收对象取自已确认记录及当前运行时信息，不从示例推断。

-开始阶段时向负责人说明三类内容：本阶段必须完成、后续阶段处理、当前不需要。以后阶段的资料不提前成为当前完成条件。阶段 4、8 由中心真人组织，Agent 可协助整理；其他阶段按主责真人组织工作。
+开始阶段时向负责人说明三类内容：本阶段必须完成、后续阶段处理、当前不需要；先汇报安排，再按真人决定执行。以后阶段的资料不提前成为当前完成条件。阶段 4、8 由中心真人组织，Agent 可协助整理；其他阶段按主责真人组织工作。排期和资源协调按 [项目计划](project-planning.md) 办理。

 ## 交付任务

@@ -34,14 +34,21 @@

 1. 登记实际提交时间、成果版本和位置、提交人的完成说明以及已有真人确认。
 2. 核对结果是否对应任务要求、必需项是否齐备、版本及确认范围是否一致、依赖和授权是否满足。链接内容由真人核实，中心不代作专业审查。
-3. 缺口只退回受影响部分，保留有效成果。已提交但未确认完成时保持“待确认”，不登记实际完成时间。
+3. 缺口只退回受影响部分，保留有效成果。已提交但未确认完成时保持“已提交，待确认”，不登记实际完成时间。本人说明已通过其他渠道提交时据实登记，入口缺失、接收可用待确认、验收未确认分别记录，不因聊天无附件或队列待投递改成未提交。
 4. 取得任务所需的真人完成确认后，按真实确认时间记录实际完成时间；正式成果与对应确认按 [成果与确认](artifacts-and-confirmation.md) 留存。
-5. 更新阶段逐任务汇总、项目进度和当前成果索引，再交接下游所需材料。
+5. 更新阶段逐任务汇总、项目进度和当前成果索引；有计划主表时据真实回报同步实际执行情况，再交接下游所需材料。需要阶段决定或出现实质变化时主动在中心会话汇报。

 ## 阶段交接与关闭

- 向中心真人逐条展示本阶段每项任务的成果、完成与确认情况，以及未完成项、影响、责任、原计划和当前计划时间、必须完成的阶段。
- 中心真人决定推进、补充、退回或暂缓，Agent 记录决定及范围；缺项未解决时如实说明例外和承接，不写成正常通过。
+- 按 [阶段汇报与推进决定](stage-reporting.md) 主动向中心真人逐条汇报本阶段每项任务的成果、完成与确认情况，以及未完成项、影响、责任、原计划和当前计划时间、必须完成的阶段。请求查看确认前提供全部有效文件的完整入口；本地更新不替代聊天汇报。
+- 中心真人决定推进、补充、退回或暂缓，Agent 记录决定及范围；已有条件授权实际满足后依授权执行并留依据，不重复申请。缺项未解决时如实说明例外和承接，不写成正常通过。
 - 阶段结束逐条提醒仍待交的延期成果，持续至交付或有明确处置；只影响部分任务时不停止无关工作。
- 下一阶段引用已有成果和确认，不重复转存大文件、不因换阶段重派同一未完成任务。
- 进入复盘结项只表示开始结项整理。业务确认结项、中心真人决定关闭后才记录关闭；未交付的承接项仍保持待交和后续跟进状态。
+- 下一阶段引用已有成果和确认，不因换阶段强制重复转存大文件或重派同一未完成任务。已批准的交接，在通知授权范围内合并发送上一阶段总结与下一阶段安排，正文和发送结果进入阶段过程记录。
+- 进入复盘结项只表示开始结项整理。满足阶段八的必要条件，包括全部 Bug 处理或承接取得双方确认、业务确认结项后，由中心真人决定关闭；未交付的承接项仍保持待交和后续跟进状态。
+
+## 关闭后的同步
+
+- 记录关闭决定人、真实日期、原话、范围与条件；同步项目概览、进度、阶段、原任务、成果索引、结项报告和流程闭环总结，引用同一决定依据。
+- 锁定当前有效成果，保留旧版和历史；停止已结束阶段、已确认成果的重复催办。仍需跟进的承接项按原责任和计划记录。
+- 队列未送达、工具未结算单独记录，不能推翻真人关闭决定或重派同一业务任务。关闭不证明测试通过、Bug 已修复、已量产或已出货。
+- 在已授权范围内发送一次结项总结，后续补地址或整理文件不重复发送。项目反馈留在实际项目，拟整合到共享 Skill 的内容和入口须经有权真人统一确认范围后再修改；关闭本身不代表共享规则变更授权。
@@ -4,7 +4,7 @@

 ## 通用推进规则

- 正常顺序按以下八阶段；每次跨阶段推进由中心真人决定，不因 Agent 判断满足条件自动进入下一阶段。
+- 正常顺序按以下八阶段；每次跨阶段须有中心真人决定。已有条件授权实际满足时，按原范围执行并记录授权、条件依据和实际切换日期，不重复申请；无授权时不因 Agent 判断满足条件自动推进。详见 [阶段汇报与推进决定](stage-reporting.md)。
 - 必需成果不能如期交付时，按 [异常与决定](exceptions-and-decisions.md) 记录真人确认、影响和补齐／承接安排。延期不等于交付，跳转不等于通过。
 - 选填成果未提交不阻塞、无需豁免；已提供时登记有效版本及专业结论。可靠性、专项、提测佐证是否提交由中心真人决定，沿用已有有效决定。
 - 下面的成果名称可由连贯成果包承载，已经有效的同内容成果无需重做。既有记录能够承载专业结论时，不为配齐文件名新增文档。
@@ -32,10 +32,10 @@

 ## 阶段四：项目规划

- **组织者**：中心真人；技术负责人、产品及执行真人提供评估，Agent 协助汇总。
+- **组织者**：中心真人负责总排期与跨角色资源协调；技术负责人、产品及执行真人按职责提供评估，Agent 协助汇总。
 - **成果**：《项目计划》、《角色分工》、《项目状态内部记录》。
- **结果内容**：计划含任务拆分、工时评估、实际排期；技术负责人给出技术结构、顺序与依赖结论。分工明确每项任务主责、协作、人员变化与交接，引用立项资料中的风险，不另建风险成果或《产品资料整合》。
- **推进依据**：技术结构及问题任务已有结论，产品确认授权范围内资源和排期，预算、采购、对外承诺等必要业务授权完成，首批任务输入与依赖就绪；中心真人决定推进。不要求全员重签整份计划，同步业务的回执不增加批准条件。
+- **结果内容**：先交接全部有效产品需求，再由应用层、底层和硬件分别评估范围、已有成果、剩余工作、工时、周期、投入及等待。初版与后续迭代分开，技术负责人核实范围、先后、并行、合版和依赖后交测试衔接周期；测试可先估自身工作量。评估沿原任务留表，具体字段、八列唯一计划主表和执行更新见 [工时、周期与项目计划](project-planning.md)。分工明确每项任务主责、协作、人员变化与交接，引用立项资料中的风险，不另建风险成果或《产品资料整合》。
+- **推进依据**：技术结构及问题任务已有结论，中心真人统筹的整体排期和跨角色资源安排已明确，产品确认具体授权范围内的资源和排期，预算、采购、对外承诺等必要业务授权完成，首批任务输入与依赖就绪；中心真人决定推进。产品不默认承担全部专业和工厂周期，不要求全员重签整份计划，同步业务的回执不增加批准条件。

 ## 阶段五：嵌入式软硬件实现

@@ -48,7 +48,9 @@
 | 嵌入式应用层 | 嵌入式应用层固件包 | 正式／升级固件、自测用例、分区表、MD5 值文件、Flash 烧写固件、zn_debug 文件、Changelog、串口使能证书 |

 - 硬件设计需要实际外设、关键器件规格书和结构板框图；缺失只影响对应任务，不将前置输入重新列为产出，不另设《硬件实现资料》。
+- 软硬件、环境或样机缺失只阻塞依赖它的工作，其他输入就绪的任务继续。到样、系统、PQ、AI 和环境状态取自真人实际回报，不按计划日期推定，也不把收到输入写成后续工作已完成。
 - 底层提供可消费 BSP／PSP，应用层负责合版并交唯一最终提测固件；底层不直接交最终固件给测试，定频固件仅供专项测试。
+- PSP 仓库／commit、BSP 构建及输入入口不等于最终固件身份，不将其他构建结果移用于最终包。现有配置中已有有效 BSP 消费入口，且真人确认无需另行获取时，直接沿用。已知包身份和入口交相关真人确认可用，Agent 无法访问不构成重做或反复上传的理由。
 - 设计、自测、联调由真人自行组织，中心核对提交结果。**推进依据**：适用成果齐备，最终统一固件和硬件版本匹配，技术负责人明确可提测，中心真人决定推进。

 ## 阶段六：测试验证
@@ -56,8 +58,8 @@
 - **主责**：测试，实际需要修复时由对应实现角色主责修复任务。
 - **成果**：《功能测试报告》必需，含通过／不通过结论、覆盖范围、用例执行结果及 bug log。缺陷信息可提供链接，**不要求缺陷清单文件，零缺陷也不另交零缺陷清单**。
 - **选填**：《可靠性测试报告》（高低温，跌落／防水选填）、《专项测试报告》、《提测佐证》（视频、截图、log）。中心真人决定是否提交，未提供不阻塞，仍须执行已约定必测范围；外部平台要求与内部提交决定分开记录。
- **输入与修复**：使用统一固件、版本矩阵、测试计划及必要变更说明。底层实现资料、硬件设计包不作为常规必交输入。测试自行制定每次执行、复测和回归策略，不增加独立策略文件或审批。真人商议缺陷责任，每项缺陷一个主责角色和责任人；需修复时中心安排交付任务。底层修复由应用层重新合版，硬件 ECO 随结果交兼容、应用有效性及版本矩阵更新结论，测试独立复验。
- **提交确认**：测试真人提交后，中心真人须实际查看并明确确认或退回测试结果；确认前不宣布正式测试提交完成或进入正式验收。实质变化后的结果／被测版本重新确认。
+- **输入与修复**：每轮明确统一固件和硬件版本、版本矩阵、测试计划、变更、必测范围、期限及提交要求。底层实现资料、硬件设计包不作为常规必交输入。测试自行制定每次执行、复测和回归策略，不增加独立策略文件或审批。真人商议缺陷责任，每项缺陷一个主责角色和责任人；需修复时中心安排交付任务。底层修复由应用层重新合版，硬件 ECO 随结果交兼容、应用有效性及版本矩阵更新结论，测试独立复验。
+- **提交确认**：测试真人提交后，中心真人须实际查看并明确确认或退回测试结果；确认前记录“已提交，待确认”，不写未提交，也不宣称已确认完成或进入正式验收。实质变化后的结果／被测版本重新确认。
 - **推进依据**：测试通过并获中心真人确认推进；或测试不通过，但项目与产品双方真人核实后明确同意该版本放行，再由中心记录放行及推进决定。保留原“不通过”，分别记录放行版本、范围、条件、未通过项、责任安排及双方确认。放行不代表外部验收通过。

 ## 阶段七：内部／外部验收
@@ -65,14 +67,19 @@
 - **组织者**：项目；内部任务交相应真人，外部平台由产品确认、客户由业务确认。
 - **成果**：内部验收结果记入已有验收记录；产品汇总《平台验收报告或结论》《客户验收通过报告》及共用《遗留问题清单》，按项目已约定的适用验收范围办理。
 - **交接**：测试真人直接向产品真人交付已确认最终测试报告及已提供的提测佐证；中心沿用正式成果与确认，产品接收情况放过程记录。链接交付只记地址，不要求中心收转大文件。
+- **执行分工**：联系平台、发包寄样、收件和跟进按具体项目明确唯一主责，不默认全部由产品或中心本人执行。实际协调、接收可用、平台结果和业务客户确认分别记录。
 - **结果内容**：遗留清单标明内部／外部来源、实际验收方、版本、责任人、处置和状态。平台无需业务再次批准；客户报告由产品出具或更新，客户结果由业务确认。各项输入就绪可并行，客户反馈由有联络权限的真人取得。
 - **推进依据**：约定的内部验收完成，适用外部验收取得对应真人确认；同时要求平台和客户验收时两项均须通过。版本一致、风险有承接，中心真人同意进入结项。内部验收或版本放行不能代替外部结果。
 - **返工**：回到受影响环节。新测试结果重新执行阶段六的真人确认；仍不通过拟放行时重新取得项目、产品双方结论。版本变化影响其他验收项时更新对应结果。
+- 共用遗留记录延续到阶段八的 Bug 双方确认，不给测试追加重复缺陷清单。

 ## 阶段八：复盘结项

 - **组织者**：中心真人，各角色提供已有成果及复盘输入，Agent 协助整理，业务保留结项确认职责。
 - **成果**：《结项资料归档》、《变更记录》、《结项报告》、《流程闭环总结》。
- **结果内容**：归档沿用已验收最终版及确认；过程资料包括草稿、旧版、历史确认、变更过程、进度和接收记录，单独保留。复盘说明目标完成、计划偏差、协作与质量问题、经验和改进；改进项写入流程闭环总结，明确责任与跟进，不另设正式成果。
- **关闭依据**：约定内部与外部验收已确认，归档可追踪、复盘完成、遗留已处理或落实承接，业务确认结项，中心真人决定关闭。结项必需项完成后锁定四类成果。仍有延期成果时，由中心真人明确补齐或承接安排后决定是否关闭，待交仍写待交，不伪报已归档。
+- **结果内容**：归档沿用已验收最终版及确认，逐项包含全部有效资料、配套资料或完整外部入口，不能只给目录或确认记录。阶段管理起止及依据写入既有《结项资料归档》，提交、采用、确认和工程实际日期分别记录，参见 [归档栏目](../assets/templates/结项资料归档.md)。过程资料包括草稿、旧版、历史确认、变更过程、进度和接收记录，单独保留。复盘说明目标完成、计划偏差、协作与质量问题、经验和改进；改进项写入流程闭环总结，明确责任与跟进，不另设正式成果。
+- **成果格式**：结项报告及汇总沿用项目已确认格式；单工作表 Excel 只是可参考形式，不强制各项目采用同一表或字段。缺少工时、迭代、评审或签名时保留未知，不从文件数量推算或补造。
+- **Bug 处理**：覆盖全部 Bug，包括已处理及后续发现项。中心真人先确认事实和实际处理／承接，产品真人再次确认并在职责内决定处理，双方无异议后登记最终确认；复用有效确认。具体顺序和字段见 [Bug 双方确认](exceptions-and-decisions.md#bug-处理与双方最终确认)。
+- **关闭依据**：约定内部与外部验收已确认，归档可追踪、复盘完成、遗留已处理或落实承接，Bug 处理或承接已取得中心及产品双方确认，业务确认结项，中心真人决定关闭。结项必需项完成后锁定四类成果。仍有延期成果时，由中心真人明确补齐或承接安排后决定是否关闭，待交仍写待交，不伪报已归档。
 - 本阶段不安排冒烟、发布验证或重做固件；新实现／质量问题回相应环节。开始整理不等于关闭，结项不等于后续改进全部完成；模拟只能记录模拟完成。
+- **关闭后**：按 [中心工作流](hub-workflow.md#关闭后的同步) 同步全部相关记录、锁定有效成果、停止重复催办并按授权发送一次结项总结。队列待送和工具未结算另记，不撤销真人关闭或重派业务任务；失败测试、未修复 Bug 和后续责任如实保留，不据此声称量产出货。
@@ -0,0 +1,36 @@
+# 工时、周期与项目计划
+
+阶段四组织评估、编排计划或后续更新执行情况时读取。中心真人统筹总排期和跨角色资源；角色真人决定本领域的执行方法。已有项目沿用已确认的唯一计划主表，新项目默认使用 [Excel 八列计划模板](../assets/templates/项目计划.xlsx)。Markdown 项目进度只维护摘要和主表入口。
+
+## 收集评估与衔接周期
+
+1. 评估前，向嵌入式应用层、嵌入式底层、硬件三方交接全部有效产品需求文件，列明版本和完整入口。各方分别说明本人范围、已有成果、剩余工作、尚不能估算的部分、可投入人员及外部等待。
+2. 初版单列，后续迭代轮数不包含初版；每轮内容和周期可以不同。研发开发、自测、修复与独立测试、回归分别记录，外部等待另列。
+3. 三方提交周期后，由技术负责人核实范围、遗漏与重复、先后和并行、合版以及软硬件依赖，再交测试衔接初版、各轮和回归周期及资源。测试可以先估自身工作量，不必等其他领域全部完成才开始评估。
+4. 产品只确认明确授权范围内的具体资源和排期对象，记录权限及范围；不默认产品对全部专业工作或工厂周期负责。预算、采购、对外承诺等仍按业务权限办理，不要求全员重批整份计划。
+
+评估沿原任务按工作项用表格记录，可嵌入 [工时与周期评估栏目](../assets/templates/工时与周期评估.md)。保留主责真人、原估／当前估及单位、周期及起算条件、投入和等待、提交与确认日期、来源和状态。变更保留前后值、原因及真人确认；未知写待确认，不能把工作日直接换成人日或小时。
+
+## 唯一计划主表
+
+固定八列：**里程碑、工作项、预排开始日期、预排结束日期、预排工时/人时、负责角色、参与人数、实际执行情况**。
+
+- 空白模板不预填日期、工时、人数、任务或迭代轮数。根据项目真实评估展开工作项；不同项目不套用同一套参考任务或周期。
+- 工时是任务合计人时，不再乘参与人数。人数不表示资源已落实；空白和 NA 不改成零。工作周期、工时、投入和外部等待分别记录。
+- 客户目标、内部预计、当前有效计划和实际执行分开；客户验收目标与量产目标分别保留。计划主表显示当前已确认计划，原计划及历次改期保留在原任务记录中并可追溯。
+- 预排日期不证明实际开始或完成；表格日期重叠不证明可并行、依赖已满足或已获跨阶段授权。
+- 主表按项目已有位置维护；新项目在阶段四任务过程中编制，确认有效后按正式成果规则登记。后续持续使用同一主表，不另建 Markdown 全量副本。
+
+## 更新实际执行情况
+
+中心根据真实回报更新同一工作项的“实际执行情况”，按需要分行记录：
+
+- 更新时间及事实来源。
+- 已完成部分、未完成部分与当前进展。
+- 真实开始和完成时间；任务实际完成仍取提交后真人明确确认完成的时间，工程实际发生时间另记。
+- 成果名称、版本和实际入口，已有确认人、时间及范围。
+- 偏差、影响、下一步，以及原任务记录入口。
+
+没有回报时写“待补充执行情况”，不能推定未开始或未完成。日常事实更新直接据实登记并保留来源、历史，不重批整表。修改已确认日期、工作范围或资源安排时，由对应有权真人确认后更新当前计划，原值和决定保留在原任务／变更记录中。
+
+已确认计划基线及历史版本仍按 [成果与确认](artifacts-and-confirmation.md) 保留。“实际执行情况”的后续更新应标明日期与来源，不把旧批准解释成对新发生事实的预先确认。
@@ -39,9 +39,11 @@

 使用 [项目概览模板](../assets/templates/项目概览.md)。

+项目只有一份持续维护的计划主表。已有项目沿用已确认载体，新项目默认采用 [Excel 八列计划模板](../assets/templates/项目计划.xlsx)，实际主表在概览和进度中登记入口；评估、改期和实际执行的维护按 [项目计划规则](project-planning.md)。
+
 ### 项目进度

-作为项目当前情况的统一入口，每次相关事实变化后同步维护：
+作为项目当前情况的统一入口，每次相关事实变化后同步维护；计划主表保留完整工作项和实际执行，Markdown 只显示摘要和入口：

 - **当前阶段与整体进度**：已完成、当前、后续阶段，关键成果与下一步。阶段完成依据真人决定；有跳转时如实标记，不将经过阶段等同于完成。
 - **当前待处理事项**：逐项写事项、所属阶段、负责人、当前情况、下一步与需要谁决定。
@@ -59,14 +61,14 @@

 ### 阶段记录

-顶部列阶段状态、时间和一句话进展。正文固定分为两类：
+顶部列阶段状态、管理开始／完成日期、决定依据和一句话进展。开始取中心真人实际启用日期，完成取明确结束／进入下一阶段决定日期，第八阶段取关闭日期；进行中完成日期留空。已有条件授权时分别记录原授权、条件实际满足及实际切换日期，管理交接日期取实际切换日期。工程实际日期另记，不用管理日期计算工程延期或人时。正文固定分为两类：

 1. **正式成果及确认记录**：每项最终成果单列名称、版本、位置或链接；对应真人确认逐项列确认人、时间、对象和版本、结论、范围与条件。历史确认留在过程区。
 2. **过程记录**：逐项汇总本阶段每个任务的负责人、应交／已交成果、完成情况、确认情况、原计划／当前计划／实际完成时间、缺口、影响、下一步及原任务入口。这里也列跨阶段引用、待确认成果、阶段决定、延期和历史资料入口。

 每个任务都要覆盖成果、完成和确认三方面，不能只给过程文件链接。阶段已结束仍有未完成事项时，继续更新该阶段任务摘要并在项目层跟进；不因跨阶段复制任务。

-阶段结束的正式小结只含最终成果与确认，未决项和后续安排放过程栏目。使用 [阶段记录模板](../assets/templates/阶段记录.md)。
+阶段结束的正式小结只含最终成果与确认，未决项和后续安排放过程栏目。中心聊天汇报及群交接总结、发送实际结果也留在过程栏目，避免同一交接重复发送。使用 [阶段记录模板](../assets/templates/阶段记录.md)，主动汇报见 [阶段汇报](stage-reporting.md)。

 ### 任务记录

@@ -81,19 +83,23 @@

 使用 [任务记录模板](../assets/templates/任务记录.md)。

+需要工时或周期评估时在原任务嵌入 [评估栏目](../assets/templates/工时与周期评估.md)。涉及 Bug 处理或承接时沿原问题／共用记录保存 [双方确认字段](exceptions-and-decisions.md#bug-处理与双方最终确认)，不复制成另一份缺陷台账。
+
 ### 成果索引

 按阶段列当前有效的最终成果名称、版本、位置及确认入口。确认详情只在对应阶段正式栏目维护，索引链接过去。任务状态、延期、草稿和旧版不混入当前成果索引。

-使用 [成果索引模板](../assets/templates/成果索引.md)。原本就在外部系统的成果只记真实链接，不复制内容；外部系统旧版地址与历史情况放过程记录。
+使用 [成果索引模板](../assets/templates/成果索引.md)。逐项登记全部有效成果和配套资料，或可逐项定位内容的有效包索引。原本在外部系统的成果登记真实完整地址、用途和版本，不强制复制；明确授权本地复制时按 [成果与确认](artifacts-and-confirmation.md) 保留原交接和路径映射，索引改为正式位置。复制或补地址日期不改变原提交、采用、确认和完成时间。
+
+结项使用 [结项资料归档栏目](../assets/templates/结项资料归档.md)，属于既有四类结项成果之一。沿用项目确认的格式；目录或确认记录不代表全部原件已归档。

 ## 更新顺序与避免重复

 1. 在原任务中记录新事实与来源，更新现状，追加必要历史。
 2. 若涉及正式版本变化，按 [成果与确认](artifacts-and-confirmation.md) 保留旧版及旧确认，再登记新最终版。
 3. 更新所属阶段的逐任务摘要；涉及后续阶段时只添加原任务引用。
-4. 同步项目进度的当前事项、影响与时间；正式成果变化时更新成果索引。
-5. 取得必要真人推进决定并留档后再推进；需要通知时从这些记录生成摘要。
+4. 同步项目进度的当前事项、影响与时间；有计划主表时据实更新执行情况并保留来源和历史；正式成果变化时更新成果索引。
+5. 主动向中心真人汇报需要确认或决定的阶段结果；取得必要推进决定或既有条件授权实际满足并留档后再推进。需要通知时从这些记录生成摘要，正文及真实发送结果记入过程记录。

 若更新中断，继续前核对原记录、阶段和项目摘要是否一致，以真实事实和确认依据为准补齐，不凭较新的文件时间覆盖业务结论。中心不新增一套任务数据库、通知队列或同步服务。

@@ -0,0 +1,35 @@
+# 阶段汇报与推进决定
+
+阶段结果需要确认、未完成事项需要决定或准备交接阶段时读取。汇报发在项目持续使用的中心会话中；更新本地记录不能替代向中心真人汇报。群通知另按 [通知规则](dingtalk-progress-reporting.md) 执行。
+
+## 何时主动汇报
+
+- 本阶段任务已全部确认完成，需要决定是否推进。
+- 成果已提交但还有必要确认，或存在未完成、延期和跨阶段承接事项，需要中心真人决定。
+- 已汇报的成果、版本、确认或遗留发生实质变化，补充受影响部分。
+
+先更新原任务、阶段、项目进度及适用成果索引，再用 [阶段成果汇报栏目](../assets/templates/阶段成果汇报.md) 逐条汇报。可直接用于聊天，不为每次汇报另建独立成果文件；在阶段过程记录保留本次汇报与决定的依据。
+
+## 汇报什么
+
+1. 项目名称、本次汇报日期、当前阶段、阶段状态及概况。
+2. 本阶段每项任务的主责真人、完成情况、应交成果、必需／选填与适用条件、已交成果及版本、完整入口。对应真人确认逐项写确认人、真实时间、结论、对象、范围与条件。
+3. 原计划、当前有效计划、实际提交和实际完成时间；阶段管理日期与工程实际时间分开。
+4. 未完成项和待确认项逐条说明原因、依赖、责任、原计划与当前计划、影响及必须完成的阶段。确实没有时明确写“未完成项：无；待确认项：无”；未知不填无。
+5. 建议下一步及需要中心真人决定的具体事项。建议和已作出的决定分开，未决定保持待决定。
+
+请求成果确认前，按 [成果与确认](artifacts-and-confirmation.md#供真人查看的成果) 展示本次全部有效成果的名称、版本、用途及完整可点击地址，或直接展示文件。目录或汇总描述不能代替实际查看入口。
+
+## 推进和条件授权
+
+跨阶段须有中心真人明确决定。已有条件授权时，逐项核实条件是否实际满足；满足后按原授权范围执行并记录依据，不重复申请同一批准。条件未满足、事实有变化或超出原范围时，说明缺口并取得相应决定。专业确认、业务授权及外部验收仍按各自权限办理。
+
+在阶段过程记录分别保存：
+
+- 原授权人、授权日期、原话、范围与条件。
+- 条件实际满足的日期及各项证据。
+- 实际切换日期和所执行的安排。
+
+条件授权的阶段交接以实际切换日期登记阶段管理日期，不用早先授权日期倒填。正常阶段开始取中心真人实际启用日期，完成取明确结束或进入下一阶段的决定日期；第八阶段完成取明确关闭日期。进行中完成日期留空。工程开发、测试、验收的实际发生日期另行记录，不以阶段管理日期计算工程延期或人时。
+
+取得推进决定或条件授权实际满足后，在已启用且获授权的范围内，将上一阶段总结与下一阶段已确认安排合为一条群通知。发送正文和实际结果记入阶段过程记录，核对既有记录避免同一次交接重复通知。
@@ -211,7 +211,7 @@ def parse_args(argv):
    init.add_argument('--replace', action='store_true')
    progress = commands.add_parser(
        'progress', help='根据已留档的项目事实汇报当前阶段',
-        description='正文按“已确认的进展、待办事项、遗留”分条填写。沿用项目记录中的负责人、原计划、当前计划、必须完成的阶段和影响；脚本不推断任务完成或阶段推进。')
+        description='正文按“已确认的进展、待办事项、遗留”分条填写。阶段交接用一条 milestone 合并上一阶段总结与下一阶段已确认安排；项目 complete 用于明确关闭后的总结。沿用负责人、原计划、当前计划、必须完成的阶段和影响；脚本不判断授权、任务完成或阶段推进。')
    progress.add_argument('event', choices=EVENTS)
    progress.add_argument('--stage', required=True, help='项目当前阶段编号及中文名称；每次从有效项目记录取得')
    progress.add_argument('summary', nargs='*')
@@ -122,10 +122,11 @@ class NotifyTests(unittest.TestCase):

 **待办事项**

- 结项资料整理：由 Hub 整理四类结项工作稿。
+- 结项资料整理：由中心真人组织四类结项成果，Hub 协助整理工作稿。
 - 资料补充：由产品 Agent、业务 Agent 补充现有线下成果及确认索引，不重做验收。
 - 旧事项停止：由 Hub 停止此前的验收准备催办。
- 结项确认：四类成果具备后，由 Hub 请 @{测试人} 确认结项，确认后再锁定成果。
+- Bug 确认：中心先确认全部问题事实，产品再次确认处理或承接，已有有效确认直接引用。
+- 结项确认：四类成果、遗留承接和 Bug 双方确认具备后，由 Hub 请 @{测试人} 确认结项；中心真人决定关闭后锁定成果。
 - 本轮工作范围：不新增应用修复、设备测试或发布验证。

 **遗留**
@@ -151,6 +152,73 @@ class NotifyTests(unittest.TestCase):
        self.assertEqual(command[command.index('--at-open-dingtalk-ids') + 1], PERSON)
        self.assertEqual(self.path.read_bytes(), before)

+    def test_transition_preserves_conditional_authorization_and_two_mentions(self):
+        body = '''**已确认的进展**
+
+- 上一阶段：中心已实际查看并确认测试报告，原结论为不通过。
+- 阶段交接：项目和产品真人已同意该版本按已定范围放行。
+- 条件授权：10 月 20 日授权的条件已于 10 月 22 日满足，本次实际进入阶段七，条件依据已留档。
+
+**待办事项**
+
+- 下一阶段安排：请 @{甲} 按已定分工联系平台，期限沿用当前计划。
+  - 仅补现有成果入口，不重做已确认测试。
+- 客户验收：请 @{乙} 按已有授权跟进客户结果，尚未取得结果。
+
+**遗留**
+
+- 原测试不通过保留；放行不等于外部验收通过。
+- 已延期问题按原记录承接，原计划、当前计划、影响和必须完成阶段保持可追溯。'''
+        ids = {'甲': 'fake-a', '乙': 'fake-b'}
+        def lookup(command, **kwargs):
+            if command[1:3] == ['aisearch', 'person']:
+                self.calls.append((command, kwargs))
+                name = command[command.index('--query') + 1]
+                return reply({'result': [{'openDingTalkId': ids[name], 'meta': {'name': name}}]})
+            return self.fake(command, **kwargs)
+        args = ['progress', 'milestone', '--stage', '阶段七：内部／外部验收', body, '--at', '甲,乙']
+        code, preview = self.execute(args + ['--dry-run'])
+        self.assertEqual(code, 0)
+        self.assertFalse(self.calls)
+        self.assertEqual(preview['text'].split('\n\n', 2)[2], body.replace('@{甲}', '@甲').replace('@{乙}', '@乙'))
+        code, result = self.execute(args, lookup)
+        self.assertEqual(code, 0)
+        self.assertEqual(result['status'], 'accepted')
+        sends = [c[0] for c in self.calls if c[0][1:3] == ['chat', '+messages-send']]
+        self.assertEqual(len(sends), 1)
+        cmd = sends[0]
+        actual = cmd[cmd.index('--markdown') + 1]
+        self.assertEqual(actual.split('\n\n', 2)[2], body.replace('@{甲}', '<@fake-a>').replace('@{乙}', '<@fake-b>'))
+        self.assertEqual(cmd[cmd.index('--at-open-dingtalk-ids') + 1], 'fake-a,fake-b')
+
+    def test_complete_preserves_closure_and_unfixed_carryover_from_file(self):
+        body = '''**已确认的进展**
+
+- 四类结项成果已确认，全部 Bug 处理或承接已由中心先确认、产品再次确认。
+- 业务已确认结项，中心真人已明确关闭，决定日期、范围和条件已记入原记录。
+- 已同步项目记录、锁定有效成果并停止已结束阶段的重复催办。
+
+**待办事项**
+
+- 遗留跟进：请 @{测试人} 按已确认的当前计划继续处理承接事项。
+
+**遗留**
+
+- 已延期 Bug 尚未修复；原计划、当前计划及影响沿用原记录。
+- 原测试不通过结果保留，项目关闭不代表已量产或出货。
+- 工具回执尚未结算，另记通信状态，不撤销关闭或重派业务任务。'''
+        path = self.root / '结项总结.md'
+        path.write_text(body, encoding='utf-8')
+        code, result = self.execute(['progress', 'complete', '--stage', '阶段八：复盘结项',
+                                     '--file', str(path), '--at', '测试人'])
+        self.assertEqual(code, 0)
+        self.assertEqual(result['status'], 'accepted')
+        sends = [c[0] for c in self.calls if c[0][1:3] == ['chat', '+messages-send']]
+        self.assertEqual(len(sends), 1)
+        actual = sends[0][sends[0].index('--markdown') + 1]
+        self.assertEqual(actual.split('\n\n', 2)[2], body.replace('@{测试人}', '<@fake-person>'))
+        self.assertEqual(path.read_text(encoding='utf-8'), body)
+
    def test_progress_can_include_mention_once(self):
        code, _ = self.execute(['progress', 'blocked', '--stage', '测试验证', '缺输入', '--at', '测试人'])
        self.assertEqual(code, 0)
Author	SHA1	Message	Date
liyun	075837d51f	release: v2.1.0 发布中心 Skill 与项目计划模板	2026-10-20 19:09:53 +08:00
liyun	206aabc06c	feat: 按 V2.1 更新中心 Skill、流程图与项目记录模板	2026-10-20 18:46:19 +08:00