feat: 按 V2.0 重构中心 Skill 与项目留档流程

ep-hub/SKILL.md

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

ep-hub/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "项目中心"
+  short_description: "按八阶段管理交付、真人确认、跨阶段遗留与成果留档，生成项目通知"
+  default_prompt: "使用 $ep-hub 根据项目现有记录整理当前阶段、交付成果和需要真人决定的事项，并更新项目进度。"

ep-hub/assets/templates/任务记录.md

@@ -0,0 +1,48 @@
+# 任务记录
+
+> 填写指引：标题改为明确的任务名称，紧接一句当前情况。前部维护最新事实，关键历史按时间追加；内部执行步骤由角色真人自行安排。
+
+## 当前情况
+
+- **任务状态**：按真实情况填写；提交未确认时为“待确认”。
+- **主责真人**：记录姓名和角色；协作者按需要另列。
+- **所属阶段**：记录任务原所属阶段。
+- **原计划完成时间**：保留首次确认的期限。
+- **当前计划完成时间**：记录最近一次经确认的有效期限。
+- **实际完成时间**：任务提交后经对应真人明确确认完成的时间；尚未确认时写“尚未确认完成”。
+- **必须完成的阶段**：记录已确认安排。
+- **开始时间**：有约定时分别保留原计划、当前计划与实际开始时间。
+
+## 任务要求
+
+- **目标**：说明可独立判断的交付结果。
+- **输入资料**：逐条列有效资料、版本与实际位置。
+- **处理范围**：区分本阶段必须完成、后续处理与当前不需要。
+- **应交结果**：列成果或成果包、最低内容、必需／选填与下游用途。
+- **完成条件**：列结果要求、必要真人确认与授权，沿用已有约定。
+- **依赖**：只列影响当前执行或交接的输入与条件。
+
+## 成果与确认
+
+- **接收情况**：记录真人实际接收时间及依据；只有发送证据时标为接收待确认。
+- **提交情况**：每次提交单列提交人、时间、成果版本和保存位置。
+- **完成情况**：说明已完成、未完成部分及具体缺口。
+- **确认情况**：每项单列确认人、真实确认时间、任务／成果及版本、结论、范围和条件。
+- **确认来源**：记录直接确认或线下转述；转述保留实际确认人、转述人、来源及补录时间。
+
+## 下一步与影响
+
+- **下一步**：写清谁需要做什么、需要谁作出什么决定。
+- **延期或阻塞**：写明事实、原因及是否超过原计划／当前计划。
+- **影响范围**：列受影响任务、成果、阶段或对外节点；未知写待确认。
+- **处置或承接**：保留有权真人决定、期限与必须完成阶段，取消／豁免不写为实际完成。
+
+## 关键历史
+
+### 事件时间与名称
+
+- **参与人**：记录实际执行、提交或作出决定的人。
+- **发生了什么**：记录接收、提交、退回、确认、改期、变更或重开。
+- **变化前后**：涉及日期、版本、范围变化时保留旧值与新值。
+- **依据与原因**：记录有效来源、真人结论及原因。
+- **影响及后续**：说明受影响范围和下一步，不复制内部操作或完整聊天记录。

ep-hub/assets/templates/成果索引.md

@@ -0,0 +1,11 @@
+# 当前正式成果索引
+
+> 填写指引：按阶段逐项列出真人完成并确认的当前最终成果。任务状态、草稿、旧版、延期和推进决定在过程记录中维护。
+
+## 阶段名称
+
+### 成果名称
+
+- **当前最终版本**：记录实际有效版本。
+- **位置或链接**：只填写实际文件或链接地址，不复制外部内容。
+- **确认记录**：链接对应阶段的正式确认栏目，确认详情由那里统一维护。

ep-hub/assets/templates/阶段记录.md

@@ -0,0 +1,44 @@
+# 阶段记录
+
+> 填写指引：标题改为阶段编号与名称，紧接一句当前情况。下面两个栏目分别保存最终成果和任务过程；每个任务都要逐项汇总。
+
+- **阶段状态**：记录未开始、进行中、待确认、已完成或实际例外状态。
+- **阶段时间**：记录已约定计划、实际进入与阶段决定时间。
+- **当前情况**：概括本阶段完成到哪里。
+
+## 正式成果及确认记录
+
+### 最终成果
+
+- **成果名称**：每项最终成果独立列出。
+- **最终版本**：记录真人完成并确认的当前有效版本。
+- **保存位置**：使用实际文件位置或外部链接。
+
+### 对应真人确认
+
+- **确认人**：记录实际作出确认的人。
+- **确认时间**：记录真实时间。
+- **成果与版本**：明确此次确认的对象。
+- **结论**：记录真实确认结论。
+- **范围和条件**：保留适用范围与附带条件。
+- **来源**：链接已有依据；转述时注明转述人、来源与补录时间。
+
+## 过程记录
+
+### 任务名称
+
+- **负责人**：记录主责真人。
+- **成果情况**：分条说明应交、已交、版本和位置；待确认稿不能列为正式最终成果。
+- **完成情况**：说明任务状态、已完成与尚缺部分。
+- **确认情况**：列已确认人、时间、对象、结论和未完成的必要确认。
+- **原计划完成时间**：记录首次期限。
+- **当前计划完成时间**：记录最新有效期限。
+- **实际完成时间**：任务提交后经真人明确确认完成的时间；未确认写“尚未确认完成”。
+- **影响及下一步**：列责任、动作、必须完成的阶段及跨阶段承接。
+- **任务原记录**：链接该任务的唯一记录。
+
+### 阶段决定与未完成事项
+
+- **决定**：每次单列决定人、时间、推进／补充／退回／暂缓结论、依据、范围和理由。
+- **未完成事项**：逐项引用原任务，列原计划、当前计划、必须完成阶段、影响、承接与阶段结束提醒情况。
+- **历史资料**：链接旧版、草稿、历史确认及替代关系。

ep-hub/assets/templates/项目概览.md

@@ -0,0 +1,23 @@
+# 项目概览
+
+> 填写指引：标题改为实际项目名称；以下栏目按已确认事实填写，生成项目记录时移除此指引。
+
+## 项目目标与范围
+
+- **项目目标**：说明要完成的结果。
+- **本次范围**：说明纳入和已明确不纳入的内容。
+- **有效流程基线**：记录已确认的基线及采用依据。
+- **验收范围**：记录约定的内部、平台和客户验收范围；未确定的如实说明。
+
+## 真人分工
+
+- **中心负责人**：记录已确认姓名及权限范围。
+- **相关角色**：每个角色单列真人负责人、负责结果与必要协作。
+- **人员变化**：记录生效时间、交接事项及确认依据。
+
+## 资料与协作入口
+
+- **项目进度**：链接实际进度记录。
+- **成果索引**：链接当前有效成果索引。
+- **资料来源**：列已提供的项目资料位置。
+- **交接方式**：说明已确认的通信渠道、接收与提交方式。

ep-hub/assets/templates/项目进度.md

@@ -0,0 +1,30 @@
+# 项目进度
+
+> 填写指引：标题使用实际项目名，先写一句当前进展；以下是栏目说明，生成记录时替换为真实事实。
+
+## 当前阶段与整体进度
+
+- **更新时间**：记录本次更新的时间。
+- **当前阶段**：记录有效阶段编号、名称及推进依据。
+- **已完成阶段**：逐项列出，跳过或暂缓的单独说明。
+- **关键成果**：说明已经完成、待确认和缺失的关键结果。
+- **下一步**：说明待推进的工作及必要条件。
+
+## 当前待处理事项
+
+### 事项名称
+
+- **所属阶段**：记录原任务阶段。
+- **负责人**：使用已确认真人姓名与角色。
+- **当前情况**：区分已完成部分、未完成部分与确认状态。
+- **原计划完成时间**：记录首次确认的期限。
+- **当前计划完成时间**：记录最新有效期限，未调整时沿用原计划。
+- **必须完成的阶段**：使用已确认安排，未约定则写待确认。
+- **延期情况**：分别说明原计划和当前计划是否超期，以及原因。
+- **影响范围**：列受影响的成果、任务、阶段或对外节点。
+- **下一步／待决定**：写清谁做什么或谁决定什么。
+- **原记录**：链接任务原记录或已有问题系统中的事项。
+
+## 已完成或已处置
+
+- **事项**：每项单列完成或处置结论、真人及时间、原记录入口；仍有后续跟进的继续保留在当前事项中。

ep-hub/references/artifacts-and-confirmation.md

@@ -0,0 +1,37 @@
+# 成果与真人确认
+
+用于提交、接收、完成确认和版本替换。阶段特有的确认人按 [八阶段与结果要求](project-lifecycle.md)，不把中心真人确认推广为所有专业成果的重复审批。
+
+## 分清事实
+
+| 事实 | 如何记录 |
+| --- | --- |
+| 已发出任务或资料 | 记录发送渠道和时间；没有接收依据时，接收待确认 |
+| 真人已接收 | 记录实际接收人、时间、任务或成果版本及依据 |
+| 已提交成果 | 记录提交人、时间、版本与位置，完成确认尚缺时为“待确认” |
+| 真人确认成果或任务完成 | 记录确认人、时间、对象及版本、结论、范围、条件与来源 |
+| 同意推进或放行 | 在过程记录中单独记有权真人的决定；不替换成果本身结论 |
+
+中心真人可在会话中明确转述线下接收、提交或确认事实。保留实际确认人、真实确认时间、对象、结论和范围，并注明转述人、来源及补录时间；缺失信息写待补充。不要求另做审批单、截图或重复确认，不能把转述者写成专业确认人。
+
+## 实际完成时间
+
+**任务提交后，经对应真人明确确认该任务完成的时间，才是实际完成时间。**
+
+- 提交时间、专业成果确认时间和任务完成确认分别记录，可引用同一条有效确认，避免重复审批。
+- 任务条件需要多项确认时，以最后一项必要完成确认的真实时间为准；阶段推进决定另记，不延后已完成任务的时间。
+- 已提交未确认写“待确认／尚未确认完成”；不能用提交时间、Agent 检查时间、Etunel 完成回执或补录时间代填。
+- 退回后继续保留原任务及历次提交。重新提交获最终完成确认后记实际完成时间。
+- 已完成任务因实质变化重开时，保留旧完成事实和重开原因；当前要求未确认完成前不沿用旧时间表示新版已完成。
+- 取消、豁免、延期承接是处置结果，另记处置人和时间，不填为实际交付完成时间。
+
+## 正式成果与历史
+
+- 正式区只保存真人完成并确认的最终成果，每项一个当前有效版本。登记名称、版本、文件位置或链接；确认另列确认人、时间、对象及版本、结论、范围和条件。
+- 待确认稿、部分成果、候选固件、旧版及其历史确认进入过程区。任务记录关联所有提交，阶段正式栏目只列最终成果。
+- 新版获真人确认后才替换当前条目；先保留旧文件、旧确认及替代关系到过程区，再更新正式记录，不能覆盖丢失历史。外部链接成果保留旧地址、版本、确认及替代关系；不额外下载快照，外部系统是否保留历史如实记录。
+- 中心推进、豁免、版本放行、产品接收等事实放过程记录，引用相关正式成果。名为《变更记录》《流程闭环总结》的交付文档，在真人确认最终版后仍属于正式成果。
+- 链接交付只记地址与确认；内容核实由真人负责，不把复制内容、摘要、截图或可下载检查变成中心必做事项。
+- 实质变更、范围扩大或相反证据需要重新确认受影响部分；仅改存放位置、阶段引用或转述补录不自动触发重签。
+
+测试“不通过”可被真人确认是实际测试结论，不能因版本获放行改成“通过”。测试结果确认、版本放行、阶段推进与外部验收分别保留。

ep-hub/references/dingtalk-progress-reporting.md

@@ -0,0 +1,117 @@
+# Hub 钉钉项目进度汇报
+
+仅当当前会话是 Hub 且发生汇报事件或需提醒负责人处理具体问题时读取。钉钉是面向项目群组的单向辅助可见性与异常提醒，不是任务派发、跨角色沟通、审批、门禁、人类确认或项目记录的事实源。
+
+## 权限与封装入口
+
+- 只有 Hub／主 Agent 可以发送；成员 Agent 只把成果、状态或阻塞交给 Hub。
+- 项目首次初始化时，由 Hub 查询可用个人 DWS 账号和群，以姓名、组织和群名向负责人确认自动通知范围，再调用 `init` 创建配置；不让人填写编号或密钥。确认并启用后，范围内通知不需每条再次询问，变更账号或群须重新确认。
+- 只用项目封装：`dingtalk-progress` 处理五类项目事件，`dingtalk-message` 处理自定义中文摘要或负责人提醒；二者共用 `scripts/dingtalk_notify.py`，统一使用确认的个人 DWS 账号。初始化、跨平台入口及 @ 用法见 [通知脚本用法](dingtalk-script-usage.md)。
+
+- Agent 不得直接调用底层 OpenAPI、`dws api` 或其他消息入口绕过封装脚本。
+- 配置只保存开关、固定账号、项目群和项目名称；Hub 可在已确认范围内创建或更新，登录凭据由 DWS 管理，不索取、读取或输出 Token、密码与应用密钥。旧机器人配置须重新初始化，不静默切换发送身份。
+- 不在 Skill 或群消息里硬编码账号、群或人员标识；标识从同一账号的真实工具结果取得，仅用于本地配置和工具参数。不因默认账号切换而更换发送人，不退回机器人或 Webhook。
+
+## 汇报单位与顺序
+
+汇报以整个项目生命周期为单位。Hub 合并同一阶段或任务波次的相关结果，不为每条队列消息、普通回复、单个小步骤或短小只读问答发送通知。
+
+Hub 必须先核对真实事实，更新对应任务、阶段和项目进度记录；涉及正式成果变化时再更新成果与索引，然后发送钉钉消息。不为一次通知新增成果文件。钉钉发送失败不回滚留档，也不阻塞项目主任务。
+
+## 事件判定
+
+### start
+
+每个项目最多一次。在第一个真实可执行任务或任务波次已经交给主责真人且已有实际接收依据后（可以通过 Etunel 或其他已授权渠道）发送。仅建立计划、等待输入或讨论想法时不发送。
+
+### milestone
+
+在可验证、会改变下一步的实质进展完成并已留档时发送，例如：
+
+- 关键成果或版本成为当前有效版本；
+- 一个有意义的任务波次完成并触发角色或阶段交接；
+- 门禁、受控跳转、回退或豁免完成真实记录和必要确认；
+- 正式阻塞解除，项目恢复到明确下一动作；
+- 统一固件、版本矩阵、测试结论、验收或发布组合形成。
+
+同一处理轮或同一波次合并成一条，不逐个小任务刷屏。没有固定时间间隔；依靠事件语义和去重控制频率。
+
+### blocked
+
+出现下列实际阻塞时立即发送：
+
+- 已有影响交付的实际阻塞，需要中心协调、有权真人决定或外部条件才能继续；
+- 关键路径等待有权决定；
+- 当前使用的交接渠道实际中断，且没有可用的已授权替代渠道完成必要交接；不把 Etunel 异常自动等同于整个项目阻塞。
+
+普通排队、正常等待、角色仍可自行推进或尚未完成产出不算阻塞。阻塞解除后用 `milestone` 汇报恢复，不修改历史消息。
+
+### complete
+
+整个项目或用户明确指定的整体目标最终完成时发送一次。模拟项目必须明确写“模拟完成”，不得表达真实发布、客户验收或生产就绪。
+
+### failed
+
+整个项目或整体目标已经最终终止、无法恢复或明确失败时发送。可返工的测试失败、单个任务失败或临时脚本异常不使用 `failed`。
+
+## 消息写法
+
+标题使用“项目名称｜阶段编号：阶段名称”，例如“示例项目｜阶段六：测试验证”。Hub 每次从有效项目记录取得当前阶段编号和名称，通过 `progress --stage` 整体传入；编号未登记时只写已知阶段名称，不自行编号或因通知示例改变阶段顺序。阶段变化后使用新名称，不把“阶段里程碑”等事件标签当成阶段，也不根据正文猜测阶段。提醒入口的自定义标题同样先写当前阶段，再写提醒事项。跨阶段事项在对应条目中注明所属阶段，通知标题仍写项目当前阶段。
+
+进度通知采用已确认的格式：加粗项目与阶段标题、自动汇报时间、“已确认的进展”“待办事项”“遗留”三个加粗栏目，栏目间留空行。每件事单独一条，用日常说法写清谁做什么。确实没有待办或遗留时写“无”；资料不足时说明尚未核实，不把未知写成没有。本轮没有新增已确认进展时如实说明。
+
+- 已确认的进展：写清完成了什么、谁已作出什么决定以及适用范围。区分“已进入阶段／开始整理”和“已完成／已关闭”；已通知交接不等于对方已经完成交接。已决定的事项直接说明结果，不再请人重复批准。
+- 待办事项：合并列出本轮需要决定、确认或处理的全部事项，用“事项名称：由谁做什么”逐条表述，例如资料整理、资料补充、旧事项停止、结果确认和本轮工作范围；按实际情况命名，不要求凑齐示例条目。标题已说明当前阶段，不必每条重复阶段名，涉及其他阶段时注明。需人工决定时写“条件具备后，由 Hub 请某负责人确认具体事项，确认后再执行后续动作”，条件只取已有约定；有可选方案时简短列明。需执行时写清已明确的处理人和动作，有已约定期限时沿用，必要时说明结果通过哪个已约定渠道返回。已明确停止的催办、需要复用的成果和不新增的工作须保留，不改写成新任务。
+- 遗留：逐条列出当前阶段及此前阶段尚未解决、需要继续跟进的事项，说明现状、已确认的后续安排及对应处理人；沿用原计划时间、当前计划时间、必须完成的阶段和影响范围，按本轮需要说明变更；跨阶段事项注明原所属阶段。列为遗留不等于获准延期、豁免、关闭问题或通过阶段；同一问题在待办里写本轮动作，在遗留里交代未解决状态，避免重复整段内容。
+- 待办和需跟进的遗留，在已明确真人处理人或决策人时，于对应条目中 @ 该人；Hub 代为请求确认时 @ 被请求确认的真人负责人，不把“Hub”或角色名称当成可查询姓名。纯 Agent 工作可直接写 Hub 或实际角色 Agent；真人姓名缺失时沿用已知角色，不猜测或编造 @ 对象，确需提醒再按项目分工与脚本用法取得已确认姓名。多人分工写清各自动作，同一人可在对应条目中重复出现，发送接收人去重。已完成且无需行动的进展不额外 @ 人。未确定的责任、期限或事实不编造，也不为填写通知重新要求分配或填表。
+- 用具体动作替代“收口”“闭环”“拉齐”等笼统表述。例如“处理方式已收口”可写成“负责人已确定处理方式”，但不得把处理方式确定写成问题已解决。原决定中的“暂不修复”“无需新增清单”等范围和限制必须保留。
+- 资料未说明交接或执行情况时，只写需要核实的事实及已有安排，不直接要求重新交付或执行；通用阶段职责不能直接变成本轮已派发的待办。补充事实不要求重做已经完成的工作。
+
+以下用结项整理场景演示已确认的通知格式，项目名与人员称呼均已泛化。示例中的验收结论、成果数量、确认人及延期安排只属于该场景，不成为其他项目的默认事实、职责或放行条件；各项目仍依据自己的有效记录和流程基线生成内容。
+
+```markdown
+**示例项目｜阶段八：复盘结项**
+
+项目进度自动汇报 · 发送时自动生成带时区的时间
+
+**已确认的进展**
+
+- 相关负责人已确认：产品验收材料已在线下完成，业务已确认客户验收通过。
+- 项目已进入资料归档与复盘结项阶段，目前开始整理结项资料，项目尚未关闭。
+- 已通知相关负责人进行阶段交接，不新增审批。
+
+**待办事项**
+
+- 结项资料整理：由中心真人负责人组织四类结项成果，Hub 协助整理工作稿。
+- 资料补充：由产品负责人、业务负责人补充现有线下成果及确认记录，不重做验收。
+- 旧事项停止：由 Hub 停止此前的验收准备催办。
+- 结项确认：四类成果及遗留承接安排具备后，由 Hub 请 @示例业务负责人 确认结项。
+- 关闭决定：业务确认结项后，由 Hub 请 @示例中心负责人 决定是否关闭；结项必需项完成后锁定四类成果。
+- 本轮工作范围：不新增应用修复、设备测试或发布验证。
+
+**遗留**
+
+- 原测试不通过的结果如实保留，不因进入结项阶段改为通过。
+- 已接受延期的问题如实保留，后续沿用 Bug 系统中的记录和已有处理安排继续跟进。
+```
+
+示例标题、时间和栏目只说明最终呈现方式；调用时正文文件仅含正文，项目名、阶段标题与时间由脚本生成，不重复粘贴整条通知。
+
+保留个人消息的 AI 标识和自动汇报说明，让群成员知道这是 Hub 自动通知，不是负责人本人新增批准、验收或承诺。
+
+根据事件选择必要内容：已验证进展、关键成果、下一步和责任角色；阻塞时再说明问题、影响以及需要谁采取什么动作。尽量简短，但不能为了控制篇幅省掉本轮需要决定或处理的事项。专业细节留在成果或问题系统中，通知不新建另一份问题台账。
+
+不在正文中写运行时 ID、英文成果名、机器状态码或内部字段。只写已验证结论，不得包含密钥、Token、个人数据、客户敏感信息、大段日志、完整内部对话或未经验证的根因推断。
+
+负责人提醒只使用项目协作必需的已确认姓名。Hub 在原始正文中用 `@{完整姓名}` 指定条目内的位置，并用 `--at` 列出相同姓名；脚本查询唯一匹配后原位转换为钉钉原生 @。纯文字“@姓名”只用于人读预览，不能代替实际提及参数。脚本自动生成的人员标记是技术参数，不是要求 Hub 把人员编号写进摘要。需要负责人行动时，说明缺什么、影响什么、请谁做什么，以及通过哪个已约定渠道补充结果。不要在群里建立另一套任务或审批流程。
+
+## 调用与结果
+
+1. Hub 判断事件、取得当前阶段名称，按上面的栏目形成逐条中文摘要。用户要求先看内容时，先展示完整通知预览，得到本次发送确认后再调用真实发送；离线预览不代表已发送。
+2. 调用封装脚本一次；脚本自行处理配置检查、发送和有限重试。
+3. 只有真实个人发送响应成功且含非空 `openTaskId`，才表示请求已经接受；不证明已投递、已读或接收端 @ 提醒成功。必要时按脚本用法查询投递状态，不把任务回执当消息编号。
+4. 缺少或未启用配置时不真实发送；显式 `--dry-run` 仅在本地生成正文，不查通讯录、不联网，也不证明目标配置和 @ 有效。配置仍为旧格式时停止并请求重新初始化。
+5. 只有明确的域名解析失败才自动重试，总计最多 3 次，间隔 10 秒；首次收到有效回执立即停止。认证、权限或未知错误不自动重试；超时、连接中断或缺少回执可能已发出，不盲目重发。每次 DWS 子调用超时为 60 秒。
+6. 有效回执优先于命令退出码，不因退出异常重复发送。发送停止或结果未知时，Etunel 主任务继续；Hub 在本地结果中向负责人说明一次，不递归发送新的阻塞或失败通知，不自动补发历史事件。
+
+脚本输出和退出码只用于判断通知调用，不得把钉钉结果升级成项目门禁。Agent 不在脚本外追加重试循环。

ep-hub/references/dingtalk-script-usage.md

@@ -0,0 +1,87 @@
+# Hub 个人 DWS 通知用法
+
+仅在 Hub 初始化通知或按 [通知规则](dingtalk-progress-reporting.md) 准备发送时读取。脚本放在实际 Hub 项目的 `scripts/`，配置位于同项目 `.dingtalk/config.env`；安装 Skill 不会自动部署脚本。缺少入口时说明并继续主任务，不猜路径或绕过封装。
+
+## 项目首次初始化
+
+1. 用 `dws profile list --format json` 查询账号，向负责人显示姓名与组织；未登录请负责人完成 DWS 登录，不索取凭据。
+2. 在选定账号下，用 `dws chat +chat-search --query "负责人提供的群名称" --page-all --profile "实际账号标识" --format json` 查群。账号或群有歧义、结果不完整时先澄清，不猜编号、不选第一项。
+3. 一次确认发送账号、项目群及是否允许自动进度和必要 @ 提醒。人只确认名字与用途，不负责找编号。
+4. Hub 将真实查询结果传入 `python scripts/dingtalk_notify.py init --profile "实际账号标识" --group "实际群标识" --project "项目名称" --yes`。这是参数结构示例；值必须替换为同一账号的实际结果。脚本创建仅含开关、账号、群和项目名的配置，不存机器人密钥或登录凭据，不发测试消息。
+
+已有有效配置直接沿用；变更发送账号或群须重新确认，初始化时加 `--replace`。旧机器人配置必须重新初始化，不能静默转换发送身份。账号、群选择与查询由 Hub 完成；`init` 校验账号登录，不替代负责人对目标群的确认。暂停通知可由 Hub 按负责人要求将 `DINGTALK_PROGRESS_ENABLED` 改为 `0`。配置和标识只用于本地工具，不粘贴到群或普通回复，不提交真实配置。
+
+初始化时同时确认目标项目的 Git 忽略规则包含 `.dingtalk/config.env`，不把本机通知配置提交到仓库。
+
+## 选择本机入口
+
+共用实现依赖 Python 3.9+ 和已登录的原生 DWS。相对命令从目标项目根目录执行。
+
+| 环境 | 初始化／检查 | 项目事件 | 摘要／提醒 |
+| --- | --- | --- | --- |
+| 通用 Python | `python scripts/dingtalk_notify.py init ...`／`check ...` | 同入口 `progress ...` | 同入口 `message ...` |
+| Windows PowerShell 7.3+ | `./scripts/dingtalk-python.ps1 init ...`／`check ...` | `./scripts/dingtalk-progress.ps1 ...` | `./scripts/dingtalk-message.ps1 ...` |
+| macOS/Linux | 通常用 `python3` 执行共用入口 | `sh scripts/dingtalk-progress ...` | `sh scripts/dingtalk-message ...` |
+
+Windows 优先用 `.ps1`，须同时部署共用启动器 `dingtalk-python.ps1`，它选择独立 Python，不使用可能隔离 DWS 登录的商店版；必要时用 `DINGTALK_PYTHON` 指定解释器。各系统均通过 PATH 查找原生 DWS，不再设置机器人相关参数。这些入口是同一实现，不能重复调用。
+
+## 日常发送
+
+```text
+python scripts/dingtalk_notify.py progress milestone --stage "阶段八：复盘结项" "**已确认的进展**
+
+- 相关负责人已确认：产品验收材料已在线下完成，业务已确认客户验收通过。
+- 项目已进入资料归档与复盘结项阶段，目前开始整理结项资料，项目尚未关闭。
+- 已通知相关负责人进行阶段交接，不新增审批。
+
+**待办事项**
+
+- 结项资料整理：由中心真人负责人组织四类结项成果，Hub 协助整理工作稿。
+- 资料补充：由产品负责人、业务负责人补充现有线下成果及确认记录，不重做验收。
+- 旧事项停止：由 Hub 停止此前的验收准备催办。
+- 结项确认：四类成果及遗留承接安排具备后，由 Hub 请 @{示例业务负责人} 确认结项。
+- 关闭决定：业务确认结项后，由 Hub 请 @{示例中心负责人} 决定是否关闭；结项必需项完成后锁定四类成果。
+- 本轮工作范围：不新增应用修复、设备测试或发布验证。
+
+**遗留**
+
+- 原测试不通过的结果如实保留，不因进入结项阶段改为通过。
+- 已接受延期的问题如实保留，后续沿用 Bug 系统中的记录和已有处理安排继续跟进。" --at "示例业务负责人" --at "示例中心负责人"
+python scripts/dingtalk_notify.py progress blocked --stage "阶段三：方案设计" "**已确认的进展**
+
+- 本轮无新增已确认进展。
+
+**待办事项**
+
+- 方案设计：请 @{示例甲} 补充接口说明，并通过已约定渠道同步。
+
+**遗留**
+
+- 接口说明尚未补齐，影响方案确认；沿用该事项已有的责任和期限。" --at "示例甲"
+python scripts/dingtalk_notify.py message --title "阶段三：方案设计｜资料补充提醒" --text "**待办事项**
+
+- 方案设计：请 @{示例甲} 补齐已约定的接口资料，并通过已约定渠道确认。" --at "示例甲"
+```
+
+以上结项场景、事项和姓名仅作格式演示；验收结论、成果数量、延期安排和确认人不作为其他项目的默认事实或要求。真实发送须使用当前项目的有效记录和已确认的真人负责人姓名。
+
+事件仍只有 `start`、`milestone`、`blocked`、`complete`、`failed`。`progress` 必须传入 `--stage`，值为 Hub 从当前项目记录取得的阶段编号及中文名称；未登记编号时仅使用已知名称。脚本生成“项目名称｜阶段编号：阶段名称”、带时区时间和自动汇报说明，不推断阶段、不把阶段写进固定配置。阶段缺失、空白、包含控制字符或超过 200 字时停止，不发送泛称“阶段里程碑”的通知。保留 DWS 的 AI 标识，不能冒充负责人本人批准或承诺。
+
+旧调用需补充 `--stage`，并同步更新目标 Hub 项目的脚本与中心 Skill；仓库修改不等于目标项目已经部署。正文由 Hub 按[通知写法](dingtalk-progress-reporting.md#消息写法)组织“已确认的进展”“待办事项”“遗留”三个栏目，待办用“事项名称：由谁做什么”逐条编写。脚本生成加粗标题、时间与自动汇报说明，原样保留正文的条件、范围、顺序和完成状态，仅转换指定的 @ 标记，不自动拆句、推断责任人或追加任务。较长通知优先使用 `--file`，文件只保存三个栏目的正文。
+
+- 多行中文 Markdown 作为一个参数传入；较长摘要可先保存成 UTF-8 文件，再用 `--file "实际正文文件路径"` 替代摘要或 `--text`。文件须实际存在，路径相对工作目录；这是正文，不是上传附件，不发送大段成果或日志。
+- `progress` 和 `message` 均支持 `--at`，多个姓名可逗号分隔或重复传入。负责人姓名来自项目中已确认的真人分工；使用 Etunel 时可读取已绑定的 `member_alias`，不把角色名称当姓名；人员查询和发送固定使用初始化账号，不跟随默认账号切换。
+- 在待办或遗留条目中使用 `@{完整姓名}`，并在 `--at` 中列出同一姓名；脚本在该位置生成原生 @，不把已原位提及的人再追加到末尾。只传 `--at` 而未在正文指定位置的人仍追加到末尾。多人可分别放在各自事项中，同一人重复出现时只查询一次、发送接收人去重。缺少配对姓名或标记不完整时停止，不把普通文字 @ 当成原生提醒。
+- 脚本只接受唯一姓名匹配，自动构造个人消息所需的 `openDingTalkId` 和提及标记。查不到、重名或权限不足时停止，不让负责人手填编号，不删掉 @ 降级发送。
+- 默认且仅发配置的项目群。同一事项合成一条，事件通知可直接 @ 人，不额外重复提醒。提醒讨论结果通过已约定渠道返回并留档，不在群里另派任务或批准。
+
+## 检查与结果
+
+排障可用 `python scripts/dingtalk_notify.py check --at "完整姓名"`，省略 `--at` 只查登录；它联网但不发送，不是每轮必做。两个发送入口加 `--dry-run` 可完全离线预览，条目中的标记显示为“@姓名”；不查人、不验证目标或 @ 效果。
+
+- `initialized`：已创建经确认的个人通知配置，未发送。
+- `accepted`：真实个人发送响应成功且含非空 `openTaskId`，请求已接受，不等于已投递、已读或接收端提醒成功。保留回执供排障，面向负责人只说中文结果。
+- `checked`／`preview`／`skipped`：分别为只读检查、离线预览、未配置或未启用；都没发送。
+- `error`：本次停止，按说明区分失败与未知，不自行补发。错误退出码为 1，参数错误可能为 2，不能只凭退出码 0 判断已发。
+
+需要进一步核实投递时，按发送回执在同一账号下调用 `dws chat +messages-query-send-status --open-task-id "真实回执值" --profile "配置账号" --format json` 只读查询；按实际结果判断，不把 `openTaskId` 当消息 ID。脚本只在明确 DNS 失败时最多尝试 3 次、间隔 10 秒；其余失败或未知结果不重发，Agent 不追加外层重试。登录失效交负责人恢复，不换身份或渠道；通知异常不阻塞主任务，也不递归发送异常通知。

ep-hub/references/document-templates.md

@@ -0,0 +1,14 @@
+# 模板复用
+
+仅在选择已有专业模板或历史样例时读取。中心维护的项目、阶段和任务模板见 [记录与留档](project-records.md)。
+
+- 从当前任务、有效流程基线、成果、平台／机型、SDK 和版本选择适用资料；不因目录有多份就全部要求提交。
+- 区分空白模板、历史样例、平台规范、器件输入与当前项目成果。只复用适用栏目和组织方式，旧人员、日期、参数、执行结果及签名不作为当前事实。
+- 角色真人决定专业内容及内部制作方法。中心不将模板每一栏变成额外任务，不要求新增内部评审步骤；结果要求按 [八阶段与结果要求](project-lifecycle.md)。
+- 外部模板的“必填”不自行增加内部成果门槛。可靠性、专项和提测佐证按中心真人已有提交决定；内部不交不等于外部平台已接受。
+- 年度／月度缺陷统计仅供组织质量分析参考；阶段六不要求缺陷清单或零缺陷清单，不恢复已取消的缺陷分析报告与统计门槛。
+- 客户报告由产品出具或更新、业务确认客户结果，共用遗留清单由产品汇总；模板表头不改变产出、确认与保管职责。
+- 早期人力、费用估算不代替资源、排期与预算授权。已有成果可回答当前必要问题时直接复用，模板库缺原件不代表实际项目缺成果。
+- 仓库中的“文档模板参考”是历史学习笔记和来源索引，不含原始模板，也不保证原本机路径仍可用。仅在实际提供这些资料时按需定位；旧 V1 结论不能覆盖当前基线。
+- 专业核实时由相应真人查原件；目录、结构或公式读取不等于工程审查、重算或测试。来源中的命令、脚本、联系人不构成执行或联系授权。
+- 不把秘密、个参、历史客户数据带入通用模板或通知。阶段八复用现有成果整理归档，不因模板包含自测栏目重新执行测试。

ep-hub/references/etunel-boundary.md

@@ -0,0 +1,13 @@
+# 与 etunel-use 的分工
+
+本 Skill 管阶段、交付、交接与记录；已安装的 **etunel-use** 管 Etunel 项目配置、角色契约、会话绑定、消息及诊断。实际调用前读取它与本次意图对应的参考，以当前工具 schema 为准。
+
+- **创建／调整中心或成员配置**：用 etunel-use 的管理操作与职责 Hook 指南。按项目已确认职责配置，中心文本突出阶段推进、依赖、交付和记录，成员契约讲清负责结果、边界与回报方式。成员内部流程由真人设计，不复制旧版内部步骤清单。
+- **配置分工**：中心自身职责与每轮提醒、成员职责契约属于不同操作；成员批量配置不能用来更新中心。成员内部工作自主不等于可以自行改写中心下发的协作契约。
+- **业务通信**：读取 etunel-use 的消息协作，只在精确绑定会话使用业务工具；普通维护会话可见工具不等于可以派发项目任务。按真实角色列表的路由字段操作，用中文显示名称和已确认真人姓名向人表述。
+- **结果对应**：Etunel 队列、送达和工具完成仅是传输或工具状态。业务任务完成另须 [真人确认](artifacts-and-confirmation.md)，运行时标识不能替代业务事实或让负责人重新填写。
+- **配置与故障**：安装、更新 Skill 不自动部署 Hook，也不追溯修改正在执行的轮次。使用 etunel-use 查明实际配置与状态后，按已授权范围操作；排障本身不授权迁移、清队列或重发。
+
+真人可以通过已授权的线下或其他渠道接收与提交；这些事实按业务记录留档，不伪造 Etunel 任务或回执。成员 Agent 仍只与中心通信。中心不自行实现消息队列、投递、重试、去重、授权或文件传输，也不要求每个阶段另建中心会话。
+
+缺少 etunel-use 或可用工具时，说明配置／通信操作尚未完成；可以继续整理记录、任务草案和待决定事项，不编造操作成功。

ep-hub/references/exceptions-and-decisions.md

@@ -0,0 +1,27 @@
+# 异常与决定
+
+只处理影响交付、交接或有权真人决定的事项；角色内部如何解决由真人组织。把关键事实记入原任务或相关阶段过程记录，项目层显示当前需要处理的部分。
+
+## 延期与跨阶段未完成事项
+
+- 分条记录未完成内容、原因、主责真人、原计划完成时间、当前有效计划时间、影响范围、必须完成的阶段和下一步。
+- 改期由中心真人确认，并取得涉及资源、排期或业务承诺的必要授权；提议的日期先记“拟调整／待确认”，不能当作已生效。
+- 每次改期追加旧时间、新时间、原因、决定人、决定时间及依据；原计划不覆盖。分别说明是否超过原计划、是否超过当前计划，不能借改期抹掉原计划偏差。
+- 原任务一直保留在所属阶段。涉及的新阶段和项目层引用它，不能复制成第二项任务或因阶段切换清除未完成状态。
+- 每个阶段结束时提醒仍待交的延期成果，列责任、原计划、当前计划、影响及必须完成阶段，直至交付或真人明确处置。是否继续推进由中心真人决定。
+- 实际完成时间按 [成果与确认](artifacts-and-confirmation.md) 记录。取消、豁免或结项后的承接不冒充已完成；承接仍需跟进时保持项目层可见，最终处置后留历史引用。
+
+## 阻塞、退回与专业冲突
+
+说明受影响任务、事实和依据、缺失输入或决定、影响、建议下一步及期望时间。普通等待或仍可自行推进不标为阻塞。中心真人安排协调、补充或暂缓，只影响相关任务。
+
+提交不满足条件时列出具体缺口，保留有效成果；退回记录包含原版本、原因和补充要求。专业分歧由相关真人讨论；无法解决时呈现分歧与证据，由有权真人决定，中心 Agent 不替代专业结论。
+
+## 变更、豁免、跳转与放行
+
+- **改变基线**：记录《变更申请》所需的旧基线、拟变更内容、原因、范围、版本、成本／排期／质量影响及建议。可使用已有记录承载，按权限取得产品、业务或专业结论，记录生效范围及后续任务。
+- **必需成果不适用或豁免**：提供成果名称、适用依据、原因、事实、替代证据、影响及风险，由中心真人明确批准或拒绝。只处理对应成果要求，不替代测试确认、版本放行或外部验收。选填未交无需申请豁免。
+- **跳转、回退、暂缓**：记录原状态、目标阶段、缺失成果、原因、风险及补齐安排，取得中心真人决定及其他必要授权。暂停／取消等业务授权由业务负责，不能借阶段决定越权。
+- **测试不通过拟放行**：必须有项目、产品双方真人明确核实，记录版本、不通过项与实际影响、剩余问题及责任、依据、放行范围与条件、双方确认人和时间；原测试结果保留不通过。实质变化重新核实。
+
+未知影响不写“无影响”，未知责任或日期不编造；汇总为需要真人决定的具体问题。已有明确停止事项、暂不修复或无需新增清单等条件必须沿用，不借汇报重新分配。

ep-hub/references/hub-workflow.md

@@ -0,0 +1,47 @@
+# 中心工作流
+
+仅在组织任务、收取结果或推进阶段时读取。阶段要求见 [八阶段与结果要求](project-lifecycle.md)，文件维护见 [记录与留档](project-records.md)。
+
+## 启动或接续项目
+
+读取当前项目概览、进度和正在处理的任务，确认有效流程基线、当前阶段、中心真人负责人、相关角色真人及已有决定。沿用已有项目记录，不因安装新 Skill 自动迁移项目或重开中心会话。实际人员与接收对象取自已确认记录及当前运行时信息，不从示例推断。
+
+开始阶段时向负责人说明三类内容：本阶段必须完成、后续阶段处理、当前不需要。以后阶段的资料不提前成为当前完成条件。阶段 4、8 由中心真人组织，Agent 可协助整理；其他阶段按主责真人组织工作。
+
+## 交付任务
+
+每项任务或同一负责人的内聚任务包说明：
+
+- **任务与负责人**：所属阶段、要达到的结果、唯一主责真人和必要协作角色。
+- **输入与范围**：有效资料、版本及位置，当前必须处理和明确不要求处理的内容。
+- **交付要求**：成果或成果包、最低内容、必需与选填、下游用途。纯查询、确认和决定不要求生成空文件。
+- **时间与依赖**：原计划完成时间、当前有效计划时间、必须完成的阶段、影响执行的依赖；已约定开始时间时一并记录。
+- **完成条件**：如何判断结果完成，需要哪些专业结论、真人确认或授权。
+
+只发送接收方执行所需的资料。依赖就绪的任务可以并行；有依赖的先后顺序不能因批量派发而省略。通过 Etunel 时按 etunel-use 操作，通过其他已授权渠道时记录实际交接事实。送出不等于真人已接收，Agent 的收到回报也不自动等于其负责人已知悉。
+
+每项任务留一份记录，不要求真人提供技术编号。标题和稳定的相对文件链接用来关联同一任务；运行时消息标识只作必要的传输证据，不能成为另一套业务任务编号。
+
+## 执行过程中
+
+角色真人自行安排执行、内部评审、自测及是否使用 Agent。中心只处理影响交付的缺失输入、阻塞、跨角色依赖冲突和需要有权真人决定的变更；不追踪每轮内部操作或为已有结论追加确认步骤。
+
+收到进展后更新原任务记录。未完成事项持续汇总到项目层，明确下一步和影响；同一问题已有 Bug 系统或其他记录时引用它，不重复建立缺陷台账。需要新交付结果时才形成新的任务，并关联原事项。
+
+资料没有提到某次交接、内部工作或确认，不等于它没有发生。先列出需要核实的具体事实，沿用已有安排；不能把信息缺口直接改写成重新执行或补交任务，也不能仅凭通用角色职责声称本轮已经派发。
+
+## 收取结果
+
+1. 登记实际提交时间、成果版本和位置、提交人的完成说明以及已有真人确认。
+2. 核对结果是否对应任务要求、必需项是否齐备、版本及确认范围是否一致、依赖和授权是否满足。链接内容由真人核实，中心不代作专业审查。
+3. 缺口只退回受影响部分，保留有效成果。已提交但未确认完成时保持“待确认”，不登记实际完成时间。
+4. 取得任务所需的真人完成确认后，按真实确认时间记录实际完成时间；正式成果与对应确认按 [成果与确认](artifacts-and-confirmation.md) 留存。
+5. 更新阶段逐任务汇总、项目进度和当前成果索引，再交接下游所需材料。
+
+## 阶段交接与关闭
+
+- 向中心真人逐条展示本阶段每项任务的成果、完成与确认情况，以及未完成项、影响、责任、原计划和当前计划时间、必须完成的阶段。
+- 中心真人决定推进、补充、退回或暂缓，Agent 记录决定及范围；缺项未解决时如实说明例外和承接，不写成正常通过。
+- 阶段结束逐条提醒仍待交的延期成果，持续至交付或有明确处置；只影响部分任务时不停止无关工作。
+- 下一阶段引用已有成果和确认，不重复转存大文件、不因换阶段重派同一未完成任务。
+- 进入复盘结项只表示开始结项整理。业务确认结项、中心真人决定关闭后才记录关闭；未交付的承接项仍保持待交和后续跟进状态。

ep-hub/references/project-lifecycle.md

@@ -0,0 +1,78 @@
+# 八阶段与结果要求
+
+仅在选择阶段、定义交付结果、判断推进或返工影响时读取相关部分。下列是中心所需的结果边界，角色内部流程由真人自行设计。具体项目沿用其已确认基线；变更先记录并取得有权真人决定。
+
+## 通用推进规则
+
+- 正常顺序按以下八阶段；每次跨阶段推进由中心真人决定，不因 Agent 判断满足条件自动进入下一阶段。
+- 必需成果不能如期交付时，按 [异常与决定](exceptions-and-decisions.md) 记录真人确认、影响和补齐／承接安排。延期不等于交付，跳转不等于通过。
+- 选填成果未提交不阻塞、无需豁免；已提供时登记有效版本及专业结论。可靠性、专项、提测佐证是否提交由中心真人决定，沿用已有有效决定。
+- 下面的成果名称可由连贯成果包承载，已经有效的同内容成果无需重做。既有记录能够承载专业结论时，不为配齐文件名新增文档。
+
+## 阶段一：业务需求
+
+- **主责**：业务，产品参与需求对齐。
+- **成果**：一份《业务需求》，包含项目背景和客户里程碑要求。
+- **结果内容**：区分对接客户与最终客户，明确业务对象、目标、范围；提测、入库时间必需，小批量试产、量产时间选填。预期价值、订单和预计销售额选填，不强制成功指标。客户期望日期与已批准的对外承诺分开。
+- **推进依据**：业务与产品确认一致的需求基线，相关冲突已处理，产品具备定义输入；中心真人同意推进。不增加固定的早期风险预检。
+
+## 阶段二：产品定义
+
+- **主责**：产品组织，相关专业真人参与。
+- **成果**：《立项资料》（含风险）、《测试验收标准》、《里程碑要求》。
+- **结果内容**：立项资料包含立项书、功能清单、产品规格书等；风险在其中维护，不另设《项目风险》。测试验收标准包含平台测试用例、客户验收测试用例及标准。里程碑包含提测、客户验收时间，试产、量产时间选填。结构板框图此阶段选填，硬件任务需要时补齐。
+- **推进依据**：产品提交专业评审结论与业务对客户范围、验收边界的批准，定义已确认，验收标准可判断，直接影响本阶段的约束已处理；中心真人决定推进。早期人力费用估算不代替后续资源、排期和预算授权。
+
+## 阶段三：方案设计
+
+- **主责**：技术负责人组织方案和接口工作，测试主责编制计划。
+- **成果**：《测试计划》必需，《总体技术方案》选填。
+- **结果内容**：测试计划包含标准、用例范围和测试项，由技术负责人认可；方案、接口约束和专业决定可留在已有记录。产品给出需求一致性结论。应用层、底层、硬件按实际任务提供本领域结论。
+- **推进依据**：方案与接口可实施、需求未偏离、测试可验证，技术负责人确认方案结论及测试计划；中心真人决定推进。不新增独立接口契约、架构决策文件或本阶段硬件设计包，不以尚未形成的项目计划作前提。
+
+## 阶段四：项目规划
+
+- **组织者**：中心真人；技术负责人、产品及执行真人提供评估，Agent 协助汇总。
+- **成果**：《项目计划》、《角色分工》、《项目状态内部记录》。
+- **结果内容**：计划含任务拆分、工时评估、实际排期；技术负责人给出技术结构、顺序与依赖结论。分工明确每项任务主责、协作、人员变化与交接，引用立项资料中的风险，不另建风险成果或《产品资料整合》。
+- **推进依据**：技术结构及问题任务已有结论，产品确认授权范围内资源和排期，预算、采购、对外承诺等必要业务授权完成，首批任务输入与依赖就绪；中心真人决定推进。不要求全员重签整份计划，同步业务的回执不增加批准条件。
+
+## 阶段五：嵌入式软硬件实现
+
+三个领域各自主责任务，技术负责人提供集成、版本匹配及可提测结论。
+
+| 主责 | 成果 | 结果资料 |
+| --- | --- | --- |
+| 硬件 | 硬件设计包 | 原理图、PCB 源文档、贴片资料（PCBA_BOM、器件位置图 PDF、贴片坐标）、接口定义 |
+| 嵌入式底层 | 嵌入式底层实现资料 | 硬件功能测试报告、BSP 输出路径、PSP 输出路径；WiFi 定频测试固件选填 |
+| 嵌入式应用层 | 嵌入式应用层固件包 | 正式／升级固件、自测用例、分区表、MD5 值文件、Flash 烧写固件、zn_debug 文件、Changelog、串口使能证书 |
+
+- 硬件设计需要实际外设、关键器件规格书和结构板框图；缺失只影响对应任务，不将前置输入重新列为产出，不另设《硬件实现资料》。
+- 底层提供可消费 BSP／PSP，应用层负责合版并交唯一最终提测固件；底层不直接交最终固件给测试，定频固件仅供专项测试。
+- 设计、自测、联调由真人自行组织，中心核对提交结果。**推进依据**：适用成果齐备，最终统一固件和硬件版本匹配，技术负责人明确可提测，中心真人决定推进。
+
+## 阶段六：测试验证
+
+- **主责**：测试，实际需要修复时由对应实现角色主责修复任务。
+- **成果**：《功能测试报告》必需，含通过／不通过结论、覆盖范围、用例执行结果及 bug log。缺陷信息可提供链接，**不要求缺陷清单文件，零缺陷也不另交零缺陷清单**。
+- **选填**：《可靠性测试报告》（高低温，跌落／防水选填）、《专项测试报告》、《提测佐证》（视频、截图、log）。中心真人决定是否提交，未提供不阻塞，仍须执行已约定必测范围；外部平台要求与内部提交决定分开记录。
+- **输入与修复**：使用统一固件、版本矩阵、测试计划及必要变更说明。底层实现资料、硬件设计包不作为常规必交输入。测试自行制定每次执行、复测和回归策略，不增加独立策略文件或审批。真人商议缺陷责任，每项缺陷一个主责角色和责任人；需修复时中心安排交付任务。底层修复由应用层重新合版，硬件 ECO 随结果交兼容、应用有效性及版本矩阵更新结论，测试独立复验。
+- **提交确认**：测试真人提交后，中心真人须实际查看并明确确认或退回测试结果；确认前不宣布正式测试提交完成或进入正式验收。实质变化后的结果／被测版本重新确认。
+- **推进依据**：测试通过并获中心真人确认推进；或测试不通过，但项目与产品双方真人核实后明确同意该版本放行，再由中心记录放行及推进决定。保留原“不通过”，分别记录放行版本、范围、条件、未通过项、责任安排及双方确认。放行不代表外部验收通过。
+
+## 阶段七：内部／外部验收
+
+- **组织者**：项目；内部任务交相应真人，外部平台由产品确认、客户由业务确认。
+- **成果**：内部验收结果记入已有验收记录；产品汇总《平台验收报告或结论》《客户验收通过报告》及共用《遗留问题清单》，按项目已约定的适用验收范围办理。
+- **交接**：测试真人直接向产品真人交付已确认最终测试报告及已提供的提测佐证；中心沿用正式成果与确认，产品接收情况放过程记录。链接交付只记地址，不要求中心收转大文件。
+- **结果内容**：遗留清单标明内部／外部来源、实际验收方、版本、责任人、处置和状态。平台无需业务再次批准；客户报告由产品出具或更新，客户结果由业务确认。各项输入就绪可并行，客户反馈由有联络权限的真人取得。
+- **推进依据**：约定的内部验收完成，适用外部验收取得对应真人确认；同时要求平台和客户验收时两项均须通过。版本一致、风险有承接，中心真人同意进入结项。内部验收或版本放行不能代替外部结果。
+- **返工**：回到受影响环节。新测试结果重新执行阶段六的真人确认；仍不通过拟放行时重新取得项目、产品双方结论。版本变化影响其他验收项时更新对应结果。
+
+## 阶段八：复盘结项
+
+- **组织者**：中心真人，各角色提供已有成果及复盘输入，Agent 协助整理，业务保留结项确认职责。
+- **成果**：《结项资料归档》、《变更记录》、《结项报告》、《流程闭环总结》。
+- **结果内容**：归档沿用已验收最终版及确认；过程资料包括草稿、旧版、历史确认、变更过程、进度和接收记录，单独保留。复盘说明目标完成、计划偏差、协作与质量问题、经验和改进；改进项写入流程闭环总结，明确责任与跟进，不另设正式成果。
+- **关闭依据**：约定内部与外部验收已确认，归档可追踪、复盘完成、遗留已处理或落实承接，业务确认结项，中心真人决定关闭。结项必需项完成后锁定四类成果。仍有延期成果时，由中心真人明确补齐或承接安排后决定是否关闭，待交仍写待交，不伪报已归档。
+- 本阶段不安排冒烟、发布验证或重做固件；新实现／质量问题回相应环节。开始整理不等于关闭，结项不等于后续改进全部完成；模拟只能记录模拟完成。

ep-hub/references/project-records.md

@@ -0,0 +1,106 @@
+# 记录与留档
+
+用于建立资料目录、更新任务、阶段与项目进度。记录写在实际目标项目，仓库只提供规则与模板。先沿用已有资料结构；新项目可使用以下结构，阶段目录按实际工作需要建立，不预造任务或空成果。
+
+```text
+项目资料/
+├── 00-项目管理/
+│   ├── 项目概览.md
+│   ├── 项目进度.md
+│   └── 成果索引.md
+├── 01-业务需求/
+├── 02-产品定义/
+├── 03-方案设计/
+├── 04-项目规划/
+├── 05-嵌入式软硬件实现/
+├── 06-测试验证/
+├── 07-内部外部验收/
+└── 08-复盘结项/
+```
+
+每个启用阶段包含：
+
+```text
+阶段目录/
+├── 阶段记录.md
+├── 正式成果/
+└── 过程记录/
+    ├── 任务记录/       # 每项任务或任务包一份 Markdown，使用明确的任务名称
+    └── 历史资料/       # 按实际需要保存草稿、旧版和历史确认
+```
+
+阶段决定记在阶段记录的过程栏目，任务决定记在原任务；范围较大时可引用已有变更记录。无需为一次确认另建审批文件。角色子目录仅在资料量确有需要时使用。
+
+## 各层分别记录什么
+
+### 项目概览
+
+记录稳定信息：项目目标与范围、有效流程基线、中心及相关真人分工、资料入口、适用验收范围和已确认的通信方式。人员变化保留交接事实，不把固定示例姓名或 Etunel 技术编号当成必填表。
+
+使用 [项目概览模板](../assets/templates/项目概览.md)。
+
+### 项目进度
+
+作为项目当前情况的统一入口，每次相关事实变化后同步维护：
+
+- **当前阶段与整体进度**：已完成、当前、后续阶段，关键成果与下一步。阶段完成依据真人决定；有跳转时如实标记，不将经过阶段等同于完成。
+- **当前待处理事项**：逐项写事项、所属阶段、负责人、当前情况、下一步与需要谁决定。
+- **时间**：原计划完成时间、当前有效计划完成时间；实际完成后记录真人确认完成时间。已约定起始时间也保留。
+- **未完成及影响**：未完成内容、原因、影响的成果／任务／后续阶段／对外节点，必须完成的阶段，必要真人决定及来源。
+- **原记录入口**：链接所属阶段的任务记录；事项详情以该记录为准，项目层维护必要摘要，不复制所有历史。
+
+所有当前需处理事项都列出，逾期事项重点显示。跨阶段未完成事项持续可见；对 Bug 等已有系统引用原条目，不重复分配已明确责任、期限或另造缺陷清单。尚未约定期限或完成阶段时写“待确认”并列为需决定事项，不擅自指定。
+
+完成或获得无需继续跟进的明确处置后，从当前事项移到“已完成或已处置”简要历史入口；仍有承接或跟进动作时继续显示。取消、豁免不写已交付，结项承接不自动移除未完成事项。
+
+整体进度默认用阶段和关键成果说明。只有项目已有真人确认的计算规则才用百分比，保留依据；不按阶段序号除以八估算。
+
+使用 [项目进度模板](../assets/templates/项目进度.md)。
+
+### 阶段记录
+
+顶部列阶段状态、时间和一句话进展。正文固定分为两类：
+
+1. **正式成果及确认记录**：每项最终成果单列名称、版本、位置或链接；对应真人确认逐项列确认人、时间、对象和版本、结论、范围与条件。历史确认留在过程区。
+2. **过程记录**：逐项汇总本阶段每个任务的负责人、应交／已交成果、完成情况、确认情况、原计划／当前计划／实际完成时间、缺口、影响、下一步及原任务入口。这里也列跨阶段引用、待确认成果、阶段决定、延期和历史资料入口。
+
+每个任务都要覆盖成果、完成和确认三方面，不能只给过程文件链接。阶段已结束仍有未完成事项时，继续更新该阶段任务摘要并在项目层跟进；不因跨阶段复制任务。
+
+阶段结束的正式小结只含最终成果与确认，未决项和后续安排放过程栏目。使用 [阶段记录模板](../assets/templates/阶段记录.md)。
+
+### 任务记录
+
+每项独立结果或同一负责人的内聚任务包一份 Markdown；首次创建后沿用稳定文件位置，退回、改期、跨阶段继续维护原记录。
+
+- **前部维护现状**：任务目标、主责真人、阶段、输入版本与位置、范围、应交结果、完成条件、依赖、三类时间、成果、确认、影响和下一步。
+- **后部追加历史**：实际接收、提交、退回、补充、确认、改期、变更、重开、取消等影响交付的事件。每次写时间、人物、内容、依据和影响，不抄录聊天全文或角色内部操作。
+- **状态按事实填写**：待接收、进行中、部分完成、待确认、已完成；退回补充、暂缓、已取消等如实说明。逾期和阻塞另列原因，不用它们掩盖已经完成的部分。
+- **时间口径**：原计划保留首次确认值；当前计划保留最新经确认值，没有改期就与原计划相同；实际完成只取提交后真人明确确认完成的时间。提交、成果确认、补录和重开各自保留。详见 [成果与确认](artifacts-and-confirmation.md)。
+
+延期时写明超过原计划与当前计划的情况，保留每次改期的旧值、新值、原因与真人决定。任务获得部分成果确认不等于整项完成；完成条件有多项确认时核对全部适用确认。
+
+使用 [任务记录模板](../assets/templates/任务记录.md)。
+
+### 成果索引
+
+按阶段列当前有效的最终成果名称、版本、位置及确认入口。确认详情只在对应阶段正式栏目维护，索引链接过去。任务状态、延期、草稿和旧版不混入当前成果索引。
+
+使用 [成果索引模板](../assets/templates/成果索引.md)。原本就在外部系统的成果只记真实链接，不复制内容；外部系统旧版地址与历史情况放过程记录。
+
+## 更新顺序与避免重复
+
+1. 在原任务中记录新事实与来源，更新现状，追加必要历史。
+2. 若涉及正式版本变化，按 [成果与确认](artifacts-and-confirmation.md) 保留旧版及旧确认，再登记新最终版。
+3. 更新所属阶段的逐任务摘要；涉及后续阶段时只添加原任务引用。
+4. 同步项目进度的当前事项、影响与时间；正式成果变化时更新成果索引。
+5. 取得必要真人推进决定并留档后再推进；需要通知时从这些记录生成摘要。
+
+若更新中断，继续前核对原记录、阶段和项目摘要是否一致，以真实事实和确认依据为准补齐，不凭较新的文件时间覆盖业务结论。中心不新增一套任务数据库、通知队列或同步服务。
+
+## 排版约定
+
+- 一级标题写项目／阶段／任务名称，紧接一句当前情况；二级标题划分现状、要求、成果确认、影响和历史。
+- 每个事项单列，字段用子条目；短标签加粗，栏目之间留空行。比较固定字段时可用短表格，避免塞入多段说明形成宽表。
+- 时间写明确日期，需要时注明时刻和时区；只有日期的确认不补造时分秒。未知、尚未确认、不适用、无分别使用。
+- 链接使用可读名称，关联真实路径。生成文件时核对相对链接，不保留模板指引为项目事实，不创建虚假文件链接。
+- 模板提供版式与字段，生成时替换填写说明，按真实内容展开条目；不为填满模板创造任务、确认、负责人或成果。