9.9 KiB
EP 项目中心 Skill
本仓库提供基于 V2.1 八阶段流程的项目中心 Skill。中心负责流程把控、交付任务、信息与文件交接、过程记录；各角色真人负责人自行设计内部工作流程，并决定是否使用 Agent。
使用入口
- 中心 Skill：ep-hub：中心业务规则与按需阅读入口。
- 已安装的 etunel-use：Etunel 配置、角色契约、会话绑定与通信操作；不包含本仓库的阶段、成果和留档规则。
- 当前总流程图：固定路径维护 V2.1，历史通过 Git 追溯。
- 记录与留档：项目、阶段、任务和成果记录的分工与模板。
- 钉钉消息模板：当前阶段标题、已确认的进展、待办事项、遗留及真人 @。
本次按 V2.1 及已确认的实施口径更新阶段汇报、工时与排期、成果确认、Bug 双方确认和关闭后登记规则。旧的全角色 Skill 与独立 Hook 源目录已移除，旧内容仍可从 Git 历史查阅。仓库源文件更新不代表已发布、已安装、已修改 Etunel 配置或已迁移在途项目。
中心与角色怎样协作
一个项目使用一个持续的中心会话。任务按可独立确认的交付结果或同一负责人的内聚任务包管理，明确输入、范围、结果、期限和完成条件。真人可以直接协作，接收和提交可在线下完成；成员 Agent 之间的信息仍由中心中继。
中心 Agent 汇总事实和待决定事项，角色真人对专业成果负责，中心真人对阶段推进负责。单项任务确认完成后可解锁依赖就绪的后续任务；跨阶段推进需要中心真人决定；已有条件授权实际满足后按原范围执行并记录依据，原授权日期与实际切换日期分别保存。业务授权、产品资源排期确认和外部验收仍按各自权限办理。
| 阶段 | 主要成果 |
|---|---|
| 1. 业务需求 | 《业务需求》，包含背景及客户里程碑 |
| 2. 产品定义 | 《立项资料》（含风险）、《测试验收标准》、《里程碑要求》 |
| 3. 方案设计 | 《测试计划》；《总体技术方案》选填 |
| 4. 项目规划 | 《项目计划》、《角色分工》、《项目状态内部记录》 |
| 5. 嵌入式软硬件实现 | 硬件设计包、底层实现资料、应用层固件包 |
| 6. 测试验证 | 《功能测试报告》；缺陷链接及可靠性、专项、提测佐证选填 |
| 7. 内部／外部验收 | 内部验收记录、适用的平台／客户验收结果、共用遗留问题清单 |
| 8. 复盘结项 | 《结项资料归档》、《变更记录》、《结项报告》、《流程闭环总结》 |
完整内容与必要确认见 八阶段与结果要求。阶段六不要求缺陷清单或零缺陷清单；测试不通过时保留原结论，项目、产品真人共同核实后的放行决定单独记录。阶段八由中心真人组织，全部 Bug 处理或承接先由中心确认、再由产品确认，业务确认结项，中心真人决定关闭。关闭后同步记录、锁定有效成果并停止重复催办；未修复 Bug 和失败测试如实保留。
记录方式
实际资料保存在目标项目，不在本仓库创建项目档案。
| 记录 | 用途 |
|---|---|
| 唯一计划主表 | 完整工作项、当前有效计划和实际执行；已有项目沿用，新项目默认使用 Excel 八列模板 |
| 项目概览 | 目标、范围、基线、真人分工和资料入口 |
| 项目进度 | 当前阶段、整体进度、当前待处理和跨阶段未完成事项、影响及必须完成的阶段 |
| 阶段记录 | 每个任务的成果、完成与确认情况；正式成果和过程分栏 |
| 任务记录 | 一项任务一份记录，前部显示现状、后部追加关键历史 |
| 成果索引 | 只索引当前有效最终成果和确认入口 |
每项任务保留三类时间：原计划完成时间、当前计划完成时间、实际完成时间。实际完成时间是任务提交后经对应真人明确确认完成的时间，提交时间另记。改期保留旧值、原因和真人决定；跨阶段沿用原记录，项目层持续跟进。
每个阶段使用 阶段记录.md、正式成果/、过程记录/。正式区只放真人完成并确认的最终版及确认；草稿、旧版和历史确认保留在过程区。外部成果登记完整真实入口、用途、版本及确认，不强制下载、复制或截图。项目明确授权本地复制时，保存已取得且确认有效的资料、来源与路径映射，操作日期不改变原提交及确认日期。
排期评估和计划更新见 项目计划规则。中心主动在持续会话汇报阶段结果，不能仅更新本地文件；详见 阶段汇报。
模板可从 记录与留档 按需打开。Markdown 用明确标题、短摘要、分条字段和关键历史，未知信息如实标明。
安装与迁移
- 将仓库中的完整
ep-hub/作为中心 Skill 安装到目标环境的 Skill 目录，保留references/、assets/和agents/；具体安装位置遵循目标环境配置。 - 配置与通信使用目标环境已安装的
etunel-use。修改 Etunel 中心或成员契约时，按其管理操作和职责 Hook 指南办理；中心自身配置与成员配置是不同操作。 - 检查目标项目实际启用的旧 Skill、职责契约与 Hook。迁移须明确目标与范围，保留项目既有任务、时间、旧成果和确认记录；不能仅因仓库升级就宣称在途项目采用 V2.1。
- 在迁移已获确认后，按目标环境的安装与配置机制停用冲突的旧角色流程约束。成员内部流程由各角色真人维护，新中心 Skill 不分发统一的内部操作提示词。
- 需要钉钉时，将仓库
scripts/中的共用 Python 文件和所需平台入口部署到目标项目scripts/；中心 Skill 安装不会自动部署脚本。按 钉钉配置说明 确认个人账号、项目群和通知范围。
钉钉通知
通知是中心向项目群提供进度与行动提醒的辅助能力。先维护事实记录，再依授权发送。消息标题来自项目当前阶段，正文固定为 已确认的进展／待办事项／遗留，逐项写清谁做什么，沿用原有责任、时间、范围和停止事项。
- 已获批准或条件授权实际满足的阶段交接合为一条“上一阶段总结＋下一阶段安排”；等待决定先在中心会话汇报。阶段内关键进展、阻塞和失败仍按已授权范围通知，同轮合并；实际关闭后发一次结项总结，正文及实际发送结果进入阶段过程记录。
- 用
scripts/dingtalk_notify.py的progress／message或同等平台入口；progress必须提供--stage。 - 真人提醒在正文使用
@{完整姓名}，同时用--at列出姓名；脚本唯一匹配后原位生成提及。 --dry-run完全离线，只展示内容，不证明账号、群或 @ 有效。accepted只表示个人发送请求获接受，不等于送达、已读、真人确认或接收端提醒成功。- 仅明确 DNS 失败有限重试；未知结果不重复发送。钉钉异常不阻塞项目工作。
- 本地配置由目标项目保存且不提交；不读取或输出 DWS 凭据，不把真实发送作为仓库测试。
消息模板和事件语义见 通知规则，命令示例见 脚本用法。.agents/skills/dingtalk-* 保留为官方能力参考，不是中心核心规则，不批量改动。
版本与升级
当前发布版本为 v2.1.0，流程基线为 V2.1。版本统一采用 vX.Y.Z：前两位跟随 HTML 中已确认的流程版本，第三位是该流程下的发布迭代。V2.1 对应 v2.1.Z，该流程首次正式发布从 v2.1.0 开始；日常修改不自动创建标签。
- 流程版本不变，Skill、脚本、配置或文档变更只递增第三位；不按功能规模或兼容性自行改前两位，也不为凑发布号修改流程图。
- 流程正式更新到新的 X.Y，前两位同步，第三位从 0 开始。全仓库一个发布序列，组件不另编号；第三位更新也可能需要迁移。
- 仅在用户要求时提交、推送或发版；已发布标签不覆盖或移动。发布以 Git 标签和对应发布包为准，不能将本地修改说成已发布。
- 发布说明写清流程基线、修改、验证、需更新的安装与配置及在途项目影响。发布不等于部署，插件缓存和在途项目迁移另外明确确认。
历史发布说明 保留旧版信息，README 不累积逐版日志。
维护与验证
先读 AGENTS.md 和本次涉及的 reference。流程来源、中心规则、记录模板和通知示例一起核对，历史模板只参考结构，不恢复旧版必交要求。
在仓库根目录执行：
python -X utf8 "$env:USERPROFILE/.codex/skills/.system/skill-creator/scripts/quick_validate.py" ep-hub
python -X utf8 scripts/test_dingtalk_notify.py
git diff --check
git status --short
验证器位置随本机安装确定，不复制进仓库。修改 Shell／PowerShell 入口时检查语法与隔离参数传递；所有测试使用假配置，不真实发送。另核对 Markdown 相对链接、渐进式入口及人工确认边界。