diff --git a/.dingtalk/README.md b/.dingtalk/README.md index 90bc551..2ffef54 100644 --- a/.dingtalk/README.md +++ b/.dingtalk/README.md @@ -2,7 +2,7 @@ Hub 使用负责人确认的个人 DWS 账号发阶段汇报和 @ 提醒。只需要原生 DWS、Python 3.9+ 和一个项目配置文件；不使用机器人、应用密钥、Webhook 或 Stream 监听。 -**旧版升级：** 用新的个人账号配置替换旧配置，旧机器人配置不会自动转成个人发送授权。摘要入口已改名为 `dingtalk-message`／`dingtalk-message.ps1`，删除目标部署中的旧 `dingtalk-bot-message` 入口及 Stream 实验脚本。更新脚本和 Hub Skill／Hook 不等于已经迁移在途项目；按实际部署安排确认。 +**旧版升级：** 用新的个人账号配置替换旧配置，旧机器人配置不会自动转成个人发送授权。摘要入口已改名为 `dingtalk-message`／`dingtalk-message.ps1`，删除目标部署中的旧 `dingtalk-bot-message` 入口及 Stream 实验脚本。更新脚本和 中心 Skill 及实际部署配置 不等于已经迁移在途项目；按实际部署安排确认。 ## 首次由 Hub 完成配置 @@ -35,7 +35,7 @@ Hub 使用负责人确认的个人 DWS 账号发阶段汇报和 @ 提醒。只 - Windows 使用 PowerShell 7.3+，优先运行 `./scripts/dingtalk-python.ps1 init ...`、`check ...`；事件用 `./scripts/dingtalk-progress.ps1 ...`，提醒用 `./scripts/dingtalk-message.ps1 ...`。 - PowerShell 共用启动器选择独立 Python，避免商店版 Python 无法读取终端的 DWS 登录。必要时用 `DINGTALK_PYTHON` 指定独立解释器路径；原生 `dws.exe` 须在当前进程 PATH 中。 - macOS/Linux 通常用 `python3 scripts/dingtalk_notify.py ...`；也可用 `sh scripts/dingtalk-progress ...`、`sh scripts/dingtalk-message ...`。初始化生成的配置在 POSIX 系统为仅当前用户读写；Windows 使用部署目录的访问权限。 -- 将共用 Python 文件和所需平台入口放在目标 Hub 项目的 `scripts/` 中。安装职责 Skill 不会自动部署这些脚本。 +- 将共用 Python 文件和所需平台入口放在目标 Hub 项目的 `scripts/` 中。安装中心 Skill 不会自动部署这些脚本。 DWS 安装与登录以 [官方项目](https://github.com/DingTalk-Real-AI/dingtalk-workspace-cli) 和当前命令帮助为准；不要为通知分发机器人应用密钥。 @@ -50,31 +50,40 @@ python scripts/dingtalk_notify.py progress milestone --stage "阶段八：复盘 **待办事项** -- 结项资料整理：由 Hub 整理四类结项工作稿。 -- 资料补充：由产品 Agent、业务 Agent 补充现有线下成果及确认索引，不重做验收。 +- 结项资料整理：由中心真人负责人组织四类结项成果，Hub 协助整理工作稿。 +- 资料补充：由产品负责人、业务负责人补充现有线下成果及确认记录，不重做验收。 - 旧事项停止：由 Hub 停止此前的验收准备催办。 -- 结项确认：四类成果具备后，由 Hub 请 @{示例负责人} 确认结项，确认后再锁定成果。 +- 结项确认：四类成果及遗留承接安排具备后，由 Hub 请 @{示例业务负责人} 确认结项。 +- 关闭决定：业务确认结项后，由 Hub 请 @{示例中心负责人} 决定是否关闭；结项必需项完成后锁定四类成果。 - 本轮工作范围：不新增应用修复、设备测试或发布验证。 **遗留** - 原测试不通过的结果如实保留，不因进入结项阶段改为通过。 -- 已接受延期的问题如实保留，后续沿用 Bug 系统中的记录和已有处理安排继续跟进。" --at "示例负责人" -python scripts/dingtalk_notify.py progress blocked --stage "阶段三：方案设计" "**待办事项** +- 已接受延期的问题如实保留，后续沿用 Bug 系统中的记录和已有处理安排继续跟进。" --at "示例业务负责人" --at "示例中心负责人" +python scripts/dingtalk_notify.py progress blocked --stage "阶段三：方案设计" "**已确认的进展** -- 方案设计：请 @{示例甲} 补充接口说明，并回自己的角色会话同步；接口说明缺失影响方案确认。" --at "示例甲" +- 本轮无新增已确认进展。 + +**待办事项** + +- 方案设计：请 @{示例甲} 补充接口说明，并通过已约定渠道同步。 + +**遗留** + +- 接口说明尚未补齐，影响方案确认；沿用该事项已有的责任和期限。" --at "示例甲" python scripts/dingtalk_notify.py message --title "阶段三：方案设计｜资料补充提醒" --text "**待办事项** -- 方案设计：请 @{示例甲} 补齐已约定的接口资料，并回自己的角色会话确认。" --at "示例甲" +- 方案设计：请 @{示例甲} 补齐已约定的接口资料，并通过已约定渠道确认。" --at "示例甲" ``` -以上结项场景、事项和姓名仅作格式演示；验收结论、成果数量、延期安排和确认人不作为其他项目的默认事实或要求。真实发送须使用当前项目的有效记录和已绑定负责人姓名。 +以上结项场景、事项和姓名仅作格式演示；验收结论、成果数量、延期安排和确认人不作为其他项目的默认事实或要求。真实发送须使用当前项目的有效记录和已确认的真人负责人姓名。 -`progress` 现在必须传入 `--stage`，每次使用当前项目记录里的阶段编号和名称；未登记编号时仅写已知名称。标题显示“项目名称｜阶段编号：阶段名称”，不再显示固定的“阶段里程碑”。旧调用需补齐参数，并同步部署脚本和相关 Hub Skill／Hook；本地改动不等于在途项目已更新。 +`progress` 现在必须传入 `--stage`，每次使用当前项目记录里的阶段编号和名称；未登记编号时仅写已知名称。标题显示“项目名称｜阶段编号：阶段名称”，不再显示固定的“阶段里程碑”。旧调用需补齐参数，并同步部署脚本和相关 中心 Skill 及实际部署配置；本地改动不等于在途项目已更新。 -进度通知使用加粗标题和“已确认的进展”“待办事项”“遗留”三个栏目：待办按“事项名称：由谁做什么”逐条写清，当前阶段尚未解决的问题列入遗留。保留已定前提、停止事项和工作范围，阶段启动不写成项目关闭。确实没有待办或遗留时写“无”，未核实不能当作没有；沿用已定责任和期限，不能为了通知新增工作或重填清单。具体写法见[通知规则](../etunel-role-collaboration/references/dingtalk-progress-reporting.md#消息写法)。通知保留 AI 标识并标注自动汇报；摘要用简短中文 Markdown。在对应事项中写 `@{完整姓名}`，并通过 `--at` 传入相同姓名，脚本唯一匹配后原位生成原生 @；多人分别对应各自事项，同一接收人去重。仅传 `--at` 的旧写法仍在末尾追加提醒。离线预览只显示“@姓名”，不证明实际提醒成功。两个发送命令都支持 `--file` 正文和完全离线的 `--dry-run`。不支持临时换群、手填人员编号或退回机器人发送。 +进度通知使用加粗标题和“已确认的进展”“待办事项”“遗留”三个栏目：待办按“事项名称：由谁做什么”逐条写清，当前及此前阶段尚未解决的问题列入遗留，沿用原计划、当前计划、必须完成的阶段和影响范围。保留已定前提、停止事项和工作范围，阶段启动不写成项目关闭。确实没有待办或遗留时写“无”，未核实不能当作没有；沿用已定责任和期限，不能为了通知新增工作或重填清单。具体写法见[通知规则](../ep-hub/references/dingtalk-progress-reporting.md#消息写法)。通知保留 AI 标识并标注自动汇报；摘要用简短中文 Markdown。在对应事项中写 `@{完整姓名}`，并通过 `--at` 传入相同姓名，脚本唯一匹配后原位生成原生 @；多人分别对应各自事项，同一接收人去重。仅传 `--at` 的旧写法仍在末尾追加提醒。离线预览只显示“@姓名”，不证明实际提醒成功。两个发送命令都支持 `--file` 正文和完全离线的 `--dry-run`。不支持临时换群、手填人员编号或退回机器人发送。 -事件含义见 [通知规则](../etunel-role-collaboration/references/dingtalk-progress-reporting.md)，详细调用与结果见 [脚本用法](../etunel-role-collaboration/references/dingtalk-script-usage.md)。 +事件含义见 [通知规则](../ep-hub/references/dingtalk-progress-reporting.md)，详细调用与结果见 [脚本用法](../ep-hub/references/dingtalk-script-usage.md)。 ## 检查与失败处理 diff --git a/AGENTS.md b/AGENTS.md index 9730b6a..da35e4f 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -1,134 +1,65 @@ # AGENTS.md -## Project Overview +## 范围与工作入口 -本仓库维护 Etunel 多 Agent 项目的角色协作约束，核心交付是： +本文件适用于整个仓库，更具体的子目录说明在其范围内生效，当前任务中的明确用户要求优先。本仓库维护中心业务 Skill、流程文档、记录模板和钉钉通知封装，没有应用构建步骤。 -- `etunel-role-collaboration/`：供各角色按需读取的渐进式披露 Skill； -- `etunel-role-hook-contexts/`：供 Etunel 独立配置的八角色精简 Hook 上下文； -- `doc/`：当前流程设计基线和模板参考资料； -- 钉钉参考集成：仅帮助 Hub 理解如何调用辅助通知，不属于 Etunel 任务通信主链路。 +1. 先读 [ep-hub/SKILL.md](ep-hub/SKILL.md)，仅按本次任务路由读取相关 reference。 +2. 当前设计来源为 [V2.0 总流程图](doc/Codex多角色项目推进总流程图.html)，运行规则已整理到中心 Skill；不要求目标项目具备流程 HTML。流程文档固定路径更新，历史由 Git 保留，不另建日期或版本副本。 +3. 先后检查 Git 状态与差异，保护用户已有改动和未跟踪资料。不要删除用户保留的旧源文件来制造干净工作区。 +4. 当前工具 schema、运行时契约、成员登记和已确认项目基线与通用 Skill 有冲突时，说明具体差异；不自行猜测能力、改写已确认基线或绕过运行时权限。 -这是以 Markdown、HTML 为主、附带 Python 和平台启动脚本的约束仓库，没有需要猜测的应用构建步骤。 +仓库更新不等于安装 Skill、修改 Etunel 配置或迁移在途项目。配置和通信使用已安装的 etunel-use；本仓库不维护独立的全角色 Hook 源树，不重造队列、投递、重试、去重、会话授权或文件传输。 -## Scope +## 修改时必须保留的业务边界 -本文件适用于整个仓库。若后续子目录新增更具体的 `AGENTS.md`，以距离目标文件最近的规则为准；当前任务中的明确用户要求始终优先。 +- 一个项目使用一个持续的中心会话；默认角色为项目Hub、业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件、测试。新增角色按已确认职责和 Etunel 实际管理能力配置，不伪造已创建结果。 +- 每项任务只有一名主责真人，按交付结果或内聚任务包管理。真人自行设计内部工作流程、直接协作并决定是否使用 Agent；成员 Agent 之间仍经中心中继。 +- 中心组织交付和结果确认，处理依赖、跨角色冲突、信息交接及留档，不替专业真人做结论。阶段推进由中心真人决定，不能代替业务授权、产品资源排期确认及外部验收。 +- 原计划、当前有效计划和实际完成时间分别保存；实际完成只取任务提交后对应真人明确确认完成的时间。工具完成、排队、送达、已读或 Agent 检查不能替代。 +- 一项任务保留一份原记录，跨阶段引用。项目层持续显示未完成事项、原计划和当前计划时间、影响及必须完成的阶段；改期、退回、重开保留历史。 +- 正式成果只保存真人完成并确认的最终版和确认；草稿、旧版、历史确认与推进决定进入过程记录。链接成果只登记地址，不要求重复下载、摘要或截图。 +- 中文职责名称统一为“业务”，机器字段仅在实际接口需要时保留。面向人不索取或编造成员、会话和任务技术编号。 -## 开始工作前 +修改阶段、成果、确认、时间或通知规则时，同步核对 [八阶段规则](ep-hub/references/project-lifecycle.md)、[留档规则](ep-hub/references/project-records.md)、相关模板和通知示例。详细要求下沉到 reference，不重复复制整套规则，也不重新引入成员内部工作流程。 -1. 先读根 Skill：[etunel-role-collaboration/SKILL.md](etunel-role-collaboration/SKILL.md)。 -2. 只按其中的条件路由读取本次修改涉及的 reference，不要一次加载所有角色和测试细则。 -3. 当前设计文档为 [V2.0 总流程图](doc/Codex多角色项目推进总流程图.html)（编制日期 2026-09-30）。本次仅原位更新设计文档，现有 Skill／Hook 源文件仍待按 V2.0 明确同步；不得据此宣称运行规则已更新。`doc/` 只维护当前流程文件和配套参考，不再按日期或版本复制文档；后续直接更新同一文件，历史通过 Git 提交追溯。仓库更新不等于部署 Skill／Hook 或迁移在途项目；已运行项目继续使用其登记基线，迁移及插件缓存更新须明确确认。 -4. 运行时 Hook、Etunel 工具 schema、项目角色契约、成员登记及已确认的项目流程基线，高于 Skill 的通用说明。发现冲突时说明冲突，不要自行猜测或发明能力。 -5. 保留用户已有改动；修改前后检查 Git 状态与差异。 +实际项目资料只写在目标项目。本仓库的模板是生成指引，使用时用真实事实替换；未知可写待确认，不保留填写说明为项目成果，不伪造记录、确认或文件链接。 -不要让运行时 Skill 依赖某个带版本号的流程图或提示词文件。应把已确认且仍有效的规则整理为稳定约束，并放入正确的渐进式 reference；流程文档只作为设计来源，历史以 Git 提交追溯。 +## 钉钉集成 -## 必须保持的协作边界 +- 只有中心／主 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 标识，发送不代表真人批准。 +- 仓库维护只用隔离假配置和离线测试。真实发送需要任务明确要求且环境已授权，不能作为普通冒烟测试。API 接受不代表接收端渲染或已读。 +- `.agents/skills/dingtalk-*` 是官方参考副本，除非明确要求，不批量改动。 -- 默认八个角色是项目Hub、业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件和测试。 -- 项目Hub是成员 Agent 之间唯一的跨角色中介。现阶段不支持成员角色直接通信；所有跨角色信息必须交给 Hub 定向中继。 -- 一个项目使用一个持续的 Hub 会话贯穿生命周期；不同阶段与不同角色会话交接，不为每个阶段另建 Hub。 -- 每项任务只有一个主责角色。依赖已满足的多项任务可以形成任务波次；同一角色的内聚工作可以一次组成任务包。 -- Hub 派发内容必须足以执行，并与要求的成果文件或成果包一致。成员先与本角色真人负责人对齐、自审并确认，再向 Hub 返回正式结果。 -- Hub 使用 `mcp__etunel__etunel_list_roles` 返回的 `role` 路由任务，以 `display_name` 面向人显示；不得向负责人索取或制造成员、会话和任务编号。 -- Hub 校验身份、结构、版本、证据、确认、依赖和门禁，不代替专业角色完成内容或作出专业结论。 -- 新自定义角色必须先形成职责契约，再由 Hub 真人负责人在 Etunel 中手动添加并绑定；AI 不得宣称已自动创建角色。 -- Etunel 运行时拥有队列、投递、重试、去重、会话授权和文件传输机制。本仓库只约束角色流程，不重复设计这些软件逻辑。 -- 中文职责名称统一写“业务”；仅在运行时标识、文件名或技术映射中使用 `business`。 +## 编辑与发布 -## Key Paths +- 中文编写说明、成果名称和面向人的消息；Markdown 相对链接须可解析，文本保持 LF。 +- 入口保持精简，新增 reference 和模板须能按条件发现。不放日志、缓存、机器配置、凭据或未完成脚手架；模板的填写指引不当作真实记录。 +- 历史模板笔记保留来源和适用年代，不能用旧规则覆盖当前基线。模拟与真实成果分开，不将未执行写通过，不将不适用写失败。 +- 版本统一为 vX.Y.Z：X.Y 跟随 HTML 已确认流程版本，Z 是该流程下仓库迭代。流程不变只升第三位，流程改到新的 X.Y 时 Z 从 0 开始；不按变更规模自行调整前两位，组件不另编号。详见 [版本与升级](README.md#版本与升级)。 +- 仅在用户要求时提交、推送或发版；已发布标签不可覆盖或移动，推送后核对远程提交。日常修改不自动创建标签。 +- 发布说明写基线、变更、验证、安装／配置更新和在途影响。发布不等于部署，插件缓存更新及在途迁移须明确确认，不把仓库版本规则塞进运行时 Skill。 -| 路径 | 用途 | 修改要求 | -| --- | --- | --- | -| `etunel-role-collaboration/SKILL.md` | 入口、共享硬约束、条件路由 | 保持精简；只放高频、跨角色且必须立即知道的规则 | -| `etunel-role-collaboration/references/` | Hub、成员、生命周期、消息、成果、异常等详细规则 | 按条件拆分；新增 reference 必须能从 `etunel-role-collaboration/SKILL.md` 或已路由文件发现 | -| `etunel-role-collaboration/references/roles/` | 七个成员角色的职责契约 | 角色专属决定、输入、输出和边界写在对应文件 | -| `etunel-role-collaboration/references/testing/` | 测试角色二级细则 | 只保留匹配任务时才需要的深层内容 | -| `etunel-role-hook-contexts/` | 八角色 Hook 的完整精简职责与每轮提醒 | 独立于 Skill 发现树；简短、可直接注入、与正式职责一致 | -| `doc/` | 当前流程来源及模板参考 | 固定路径维护一份当前文档；不建日期或版本副本，历史查 Git；变更同步核对链接与基线说明 | -| `.agents/skills/dingtalk-*` | 钉钉官方能力的项目内参考副本 | 不是 Etunel 核心 Skill；除非任务明确要求更新参考包，否则不要批量改动 | -| `.dingtalk/`、`scripts/` 中的钉钉封装 | Hub 通知配置说明、跨平台入口、共用 Python 实现和离线测试 | 不把通知能力扩大为任务派发、审批、门禁或事实源 | +## 验证与完成 -修改共享流程、角色边界、阶段、正式成果或跨角色信息流时，必须同步检查根 Skill、相关公共 reference、受影响角色 reference 和对应 Hook。角色细节优先下沉到角色文件；测试专项优先下沉到测试二级 reference。不要靠复制整段规则维持一致性。 - -实际项目的运行资料不预先创建在本仓库中。Hub 应按 [项目文件与进度留档](etunel-role-collaboration/references/project-files-and-progress.md) 在使用此 Skill 的目标项目里建立阶段目录、保存正式成果并维护进度和成果索引。 - -## 钉钉参考集成边界 - -钉钉内容存在于本仓库，是为了给 Hub 提供“如何调用钉钉发送项目通知”的参考和演示能力，不是本项目的核心职责系统： - -- 只有 Hub／主 Agent 可以调用通知；成员 Agent 只向 Hub 返回成果、状态或阻塞。 -- 通知是项目群的单向辅助可见性与异常提醒，不是角色间通信、任务派发、审批、人类确认、项目门禁或项目事实源。 -- Agent 只用 `scripts/dingtalk_notify.py` 的 `progress`／`message`，或等价的 `dingtalk-progress`／`dingtalk-message` Shell、PowerShell 入口，统一以已确认的个人 DWS 账号发送。进度事件仍限定为 `start`、`milestone`、`blocked`、`complete`、`failed`；负责人提醒不新增状态。同一事项不重复通知，不得绕过封装直接调用 OpenAPI 或 `dws api`。可验证里程碑先完成项目留档，再发送简短中文 Markdown。例如： - - ```sh - python scripts/dingtalk_notify.py progress milestone --stage "阶段六：测试验证" "**已确认的进展** - - - 本轮测试报告已归档。 - - **待办事项** - - - 结果确认：由 Hub 请 @{示例负责人} 确认本轮测试结果。 - - **遗留** - - - 无。" --at "示例负责人" - ``` -- 事件语义与消息格式以 [dingtalk-progress-reporting.md](etunel-role-collaboration/references/dingtalk-progress-reporting.md) 为准；安装与本机配置参考 [.dingtalk/README.md](.dingtalk/README.md)。 -- 通知封装是辅助接入参考，不得据此反推或改变 Etunel 主流程；不创建通知队列或外层重试。仅明确 DNS 失败最多 3 次、间隔 10 秒，结果未知不盲目重发。 -- 仓库维护和测试期间不得把真实发送当作冒烟测试。只有任务明确要求发送且当前环境已经授权时，才允许触发真实通知。 -- Hub 首次查询个人账号及项目群，以姓名、组织和群名取得负责人确认后，用封装 `init` 创建 `.dingtalk/config.env`；只含通知开关、固定账号、群和项目名，不保存机器人或登录密钥。AI 可以在授权范围内维护该配置，但不提交或在群里展示内部标识；换账号或群须重新确认。 -- 不读取、输出或提交 DWS 登录凭据、Client Secret、`DING_SEC`、App Token。旧机器人配置须经确认重新初始化，不静默启用个人代发；保留 AI 标识，个人通知不代表负责人亲自批准。 - -## 编辑约定 - -- 使用中文编写项目说明、职责约束、成果名称和面向负责人的消息；机器枚举与运行时字段只在工具确实要求时保留。 -- Markdown 使用相对链接；每个新增链接都应能从仓库中解析。 -- 保持渐进式披露：入口说明“何时读什么”，详细内容放在对应 reference，不在多个文件重复整套流程。 -- Hook 只保留角色定位、关键边界、工具提醒和每轮控制点，避免塞入大段流程正文。 -- 不伪造 Etunel 工具名、参数、角色、成员、会话、状态或尚不存在的文件。 -- 不把模拟流程结果描述为真实发布、客户验收或生产就绪；不适用项对人统一写“不适用”，只在机器字段要求时使用对应枚举。 -- 文本文件保持 LF；不要提交日志、缓存、临时文件、机器专属配置或凭据。 - -## 版本与发布 - -- 全仓库统一使用三位版本 `vX.Y.Z`：前两位 `X.Y` 跟随 `doc/Codex多角色项目推进总流程图.html` 内明确标注且已确认的流程版本；第三位 `Z` 是该流程版本下的仓库发布迭代号。Git 标签与发布包确定该版 Skill、Hook、脚本和文档，组件不另设发布序列。 -- HTML 主流程版本不迭代时，所有变更均只递增第三位，包括 Skill／Hook 优化、脚本新增、修复、配置调整和文档更新；不按功能规模或兼容性自行提升前两位。流程保持 V1.0 时依次发布 `v1.0.0`、`v1.0.1`、`v1.0.2`。HTML 流程正式升到新的 `X.Y` 时，仓库前两位同步，第三位从 0 开始，例如流程 V1.1 对应 `v1.1.0`；不为凑发布号改流程图。 -- 这是流程版本驱动的项目约定，不采用“新增功能就升次版本”的语义化版本规则；第三位更新也可能需要配置迁移，发布说明必须如实列出。涉及职责或门禁变化仍须先按项目约束确认流程，不能借版本编号规则跳过确认。 -- 日常提交不必发版。发版前确认版本号、完成适用校验，说明流程基线、变更内容、需更新的 Skill／Hook 和在途项目影响；具体说明见 [README 版本与升级](README.md#版本与升级)。 -- 仅在用户要求时提交、推送或发版；已发布标签不可覆盖或移动，修正另发新版本。推送后核验远程分支与标签提交，不能把本地提交当成已发布。 -- 发布不等于部署。仅更新受影响的 Skill／Hook 配置，插件缓存更新及在途项目迁移仍须明确确认；不要求角色每轮核对发布号，不将仓库发版规则塞进运行时 Skill。 - -## Quick Commands - -修改后按影响范围执行： +从仓库根目录执行适用检查： ```powershell -rtk python -X utf8 "$env:USERPROFILE\.codex\skills\.system\skill-creator\scripts\quick_validate.py" "etunel-role-collaboration" -rtk python -X utf8 scripts/test_dingtalk_notify.py -rtk "C:\Program Files\Git\bin\bash.exe" -n scripts/dingtalk-progress -rtk "C:\Program Files\Git\bin\bash.exe" -n scripts/dingtalk-message -rtk proxy git diff --check -rtk proxy git status --short +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 ``` -Skill Creator 的验证脚本位置取决于协作者的 Codex 安装。若默认路径不同，应定位已安装的 quick_validate.py，不要把验证器复制进仓库。 +Skill Creator 验证器按本机安装定位，不复制进仓库。若已安装 rtk，可使用其等价包装；没有时直接执行上述命令。 -## Definition of Done +- 改 Skill 后通过结构校验，并检查渐进式路由、相对链接及规则一致性；结构通过不代表业务行为已验证。 +- 改钉钉脚本时运行离线测试。改 Shell 入口时用 bash -n 检查；改 PowerShell 入口时检查解析和隔离配置下的实际参数传递。需要发送能力时使用独立 Python，商店版仅可用于离线检查。 +- 最终说明改了什么、依据什么、验证了什么，以及未验证／未部署的部分，不把本地源码修改当成线上生效。 -- 修改 Skill 时已通过 Skill Creator 的结构校验。 -- 修改钉钉封装时运行离线测试；修改 Shell 入口时检查语法，修改 PowerShell 入口时核验解析和实际参数传递。只使用隔离假配置，不触发真实通知。 -- 所有新增或改动的 Markdown 相对链接均能解析。 -- 文件中没有待办标记、占位内容、真实凭据、群标识或误导性的缺失文件引用。 -- 根 Skill、公共 reference、角色 reference 和对应 Hook 在受影响规则上保持一致。 -- 最终说明修改了哪些文件、依据什么、执行了哪些验证以及仍有哪些未知项；未验证的内容不得声称通过。 - -## Boundaries - -始终执行：保护已有改动；只读必要资料；保持 Hub 中介、人类负责人确认、正式成果和渐进式披露规则一致。 - -先征得确认：改变当前流程基线、角色集合或职责边界；删除历史资料；批量替换钉钉参考包；进行真实钉钉发送；执行其他不可逆操作。 - -绝不执行：提交秘密配置；让成员绕过 Hub 直接通信；把钉钉当成 Etunel 任务通道；用 Skill 重造 Etunel 队列机制；为不存在的工具、角色、参数或成果制造虚假规则。 +改变尚未获确认的流程基线、角色集合或职责边界，删除未获授权的历史资料，批量替换官方参考包，真实通知或其他不可逆操作，先取得对应授权。当前任务已明确授权的改造继续完成，不反复索要同一确认。 diff --git a/README.md b/README.md index 6162786..95e2ef9 100644 --- a/README.md +++ b/README.md @@ -1,224 +1,103 @@ -# Etunel 多角色项目协作约束 +# EP 项目中心 Skill -本仓库为 Etunel 多 Agent 项目提供一套中文版、渐进式披露的角色职责与协作流程：项目Hub负责跨角色中继和全局推进，七个成员角色在各自真人负责人参与下完成专业任务，并以可追踪成果交回 Hub。 +本仓库提供基于 **V2.0 八阶段流程**的项目中心 Skill。中心负责流程把控、交付任务、信息与文件交接、过程记录；各角色真人负责人自行设计内部工作流程，并决定是否使用 Agent。 -> **钉钉定位说明：** 仓库中的 `.agents/skills/dingtalk-*`、`.dingtalk/` 和 `scripts/` 下的钉钉封装只作为接入参考，用来告诉 Hub 如何发送项目进度、异常摘要或负责人提醒。钉钉不是 Etunel 的角色通信链路、任务队列、审批、门禁或项目事实源，也不会改变任何角色边界。 +## 使用入口 -## 先了解这三件事 +- [中心 Skill：ep-hub](ep-hub/SKILL.md)：中心业务规则与按需阅读入口。 +- **已安装的 etunel-use**：Etunel 配置、角色契约、会话绑定与通信操作；不包含本仓库的阶段、成果和留档规则。 +- [当前总流程图](doc/Codex多角色项目推进总流程图.html)：固定路径维护 V2.0，历史通过 Git 追溯。 +- [记录与留档](ep-hub/references/project-records.md)：项目、阶段、任务和成果记录的分工与模板。 +- [钉钉消息模板](ep-hub/references/dingtalk-progress-reporting.md)：当前阶段标题、已确认的进展、待办事项、遗留及真人 @。 -1. [主 Skill](etunel-role-collaboration/SKILL.md) 是角色 AI 的统一入口，只保留共享硬约束和条件路由；详细职责按当前任务逐层读取。 -2. [Hook 上下文](etunel-role-hook-contexts/) 是给 Etunel 单独配置的精简提醒，不属于 Skill 的渐进式发现树，也不应替代完整职责文件。 -3. 当前设计文档为 [V2.0 总流程图](doc/Codex多角色项目推进总流程图.html)（编制日期 2026-09-30）。本次仅原位更新设计文档，现有 Skill／Hook 源文件尚未按 V2.0 同步；下文协作模型和使用方式仍说明现有运行规则。流程文档只维护一份，后续直接更新同一文件，旧版通过 Git 历史追溯，不再按日期或版本另存。仓库更新不代表部署 Skill／Hook 或自动迁移在途项目；运行时规则已整理进稳定 reference，不要求目标项目持有流程 HTML。 +本次已将仓库业务规则按 V2.0 和经确认的记录方案重写。旧的全角色 Skill 与独立 Hook 源目录已移除，旧内容仍可从 Git 历史查阅。仓库源文件更新不代表已发布、已安装、已修改 Etunel 配置或已迁移在途项目。 -仓库没有应用安装或编译步骤；发布对象是职责 Skill、Hook 上下文及配套文档，不是设备固件或运行中的 Etunel 服务。 +## 中心与角色怎样协作 + +一个项目使用一个持续的中心会话。任务按可独立确认的交付结果或同一负责人的内聚任务包管理，明确输入、范围、结果、期限和完成条件。真人可以直接协作，接收和提交可在线下完成；成员 Agent 之间的信息仍由中心中继。 + +中心 Agent 汇总事实和待决定事项，角色真人对专业成果负责，中心真人对阶段推进负责。单项任务确认完成后可解锁依赖就绪的后续任务；跨阶段推进需要中心真人决定。业务授权、产品资源排期确认和外部验收仍按各自权限办理。 + +| 阶段 | 主要成果 | +| --- | --- | +| 1. 业务需求 | 《业务需求》，包含背景及客户里程碑 | +| 2. 产品定义 | 《立项资料》（含风险）、《测试验收标准》、《里程碑要求》 | +| 3. 方案设计 | 《测试计划》；《总体技术方案》选填 | +| 4. 项目规划 | 《项目计划》、《角色分工》、《项目状态内部记录》 | +| 5. 嵌入式软硬件实现 | 硬件设计包、底层实现资料、应用层固件包 | +| 6. 测试验证 | 《功能测试报告》；缺陷链接及可靠性、专项、提测佐证选填 | +| 7. 内部／外部验收 | 内部验收记录、适用的平台／客户验收结果、共用遗留问题清单 | +| 8. 复盘结项 | 《结项资料归档》、《变更记录》、《结项报告》、《流程闭环总结》 | + +完整内容与必要确认见 [八阶段与结果要求](ep-hub/references/project-lifecycle.md)。阶段六不要求缺陷清单或零缺陷清单；测试不通过时保留原结论，项目、产品真人共同核实后的放行决定单独记录。阶段八由中心真人组织，业务确认结项，中心真人决定关闭。 + +## 记录方式 + +实际资料保存在目标项目，不在本仓库创建项目档案。 + +| 记录 | 用途 | +| --- | --- | +| 项目概览 | 目标、范围、基线、真人分工和资料入口 | +| 项目进度 | 当前阶段、整体进度、当前待处理和跨阶段未完成事项、影响及必须完成的阶段 | +| 阶段记录 | 每个任务的成果、完成与确认情况；正式成果和过程分栏 | +| 任务记录 | 一项任务一份记录，前部显示现状、后部追加关键历史 | +| 成果索引 | 只索引当前有效最终成果和确认入口 | + +每项任务保留三类时间：**原计划完成时间、当前计划完成时间、实际完成时间**。实际完成时间是任务提交后经对应真人明确确认完成的时间，提交时间另记。改期保留旧值、原因和真人决定；跨阶段沿用原记录，项目层持续跟进。 + +每个阶段使用 `阶段记录.md`、`正式成果/`、`过程记录/`。正式区只放真人完成并确认的最终版及确认；草稿、旧版和历史确认保留在过程区。外部成果只记录地址，不要求下载、复制或截图。 + +模板可从 [记录与留档](ep-hub/references/project-records.md) 按需打开。Markdown 用明确标题、短摘要、分条字段和关键历史，未知信息如实标明。 + +## 安装与迁移 + +1. 将仓库中的完整 `ep-hub/` 作为中心 Skill 安装到目标环境的 Skill 目录，保留 `references/`、`assets/` 和 `agents/`；具体安装位置遵循目标环境配置。 +2. 配置与通信使用目标环境已安装的 `etunel-use`。修改 Etunel 中心或成员契约时，按其管理操作和职责 Hook 指南办理；中心自身配置与成员配置是不同操作。 +3. 检查目标项目实际启用的旧 Skill、职责契约与 Hook。迁移须明确目标与范围，保留项目既有任务、时间、旧成果和确认记录；不能仅因仓库升级就宣称在途项目采用 V2.0。 +4. 在迁移已获确认后，按目标环境的安装与配置机制停用冲突的旧角色流程约束。成员内部流程由各角色真人维护，新中心 Skill 不分发统一的内部操作提示词。 +5. 需要钉钉时，将仓库 `scripts/` 中的共用 Python 文件和所需平台入口部署到目标项目 `scripts/`；中心 Skill 安装不会自动部署脚本。按 [钉钉配置说明](.dingtalk/README.md) 确认个人账号、项目群和通知范围。 + +## 钉钉通知 + +通知是中心向项目群提供进度与行动提醒的辅助能力。先维护事实记录，再依授权发送。消息标题来自项目当前阶段，正文固定为 **已确认的进展／待办事项／遗留**，逐项写清谁做什么，沿用原有责任、时间、范围和停止事项。 + +- 用 `scripts/dingtalk_notify.py` 的 `progress`／`message` 或同等平台入口；`progress` 必须提供 `--stage`。 +- 真人提醒在正文使用 `@{完整姓名}`，同时用 `--at` 列出姓名；脚本唯一匹配后原位生成提及。 +- `--dry-run` 完全离线，只展示内容，不证明账号、群或 @ 有效。 +- `accepted` 只表示个人发送请求获接受，不等于送达、已读、真人确认或接收端提醒成功。 +- 仅明确 DNS 失败有限重试；未知结果不重复发送。钉钉异常不阻塞项目工作。 +- 本地配置由目标项目保存且不提交；不读取或输出 DWS 凭据，不把真实发送作为仓库测试。 + +消息模板和事件语义见 [通知规则](ep-hub/references/dingtalk-progress-reporting.md)，命令示例见 [脚本用法](ep-hub/references/dingtalk-script-usage.md)。`.agents/skills/dingtalk-*` 保留为官方能力参考，不是中心核心规则，不批量改动。 ## 版本与升级 -已发布版本 `v1.0.4` 的流程设计基线为 **V1.0**；主分支的设计文档已更新为 **V2.0**，本次提交不创建发布标签，也不代表 Skill／Hook 已同步或部署。版本采用 `vX.Y.Z`：前两位 `X.Y` 跟随 HTML 主流程中明确标注且已确认的版本，第三位 `Z` 表示该流程版本下的仓库发布迭代。正式发布以 Git 标签和对应发布包为准，主分支可能包含尚未发布的修改。 +版本统一采用 `vX.Y.Z`：前两位跟随 HTML 中已确认的流程版本，第三位是该流程下的发布迭代。V2.0 对应 `v2.0.Z`，首次正式发布从 `v2.0.0` 开始；日常修改不自动创建标签。 -| 变更 | 版本规则 | -| --- | --- | -| HTML 流程版本不变，更新 Skill、Hook、脚本、配置或说明等任意内容 | 只递增第三位，例如流程保持 V1.0，`v1.0.1 → v1.0.2` | -| HTML 流程正式更新到新的 X.Y | 前两位同步，第三位从 0 开始，例如流程 V1.1 对应 `v1.1.0` | -| 日常提交，尚未安排发布 | 不必为每次提交创建标签；下一次正式发版按上述规则编号 | +- 流程版本不变，Skill、脚本、配置或文档变更只递增第三位；不按功能规模或兼容性自行改前两位，也不为凑发布号修改流程图。 +- 流程正式更新到新的 X.Y，前两位同步，第三位从 0 开始。全仓库一个发布序列，组件不另编号；第三位更新也可能需要迁移。 +- 仅在用户要求时提交、推送或发版；已发布标签不覆盖或移动。发布以 Git 标签和对应发布包为准，不能将本地修改说成已发布。 +- 发布说明写清流程基线、修改、验证、需更新的安装与配置及在途项目影响。发布不等于部署，插件缓存和在途项目迁移另外明确确认。 -全仓库只维护这一套发布序列，不给 Skill、Hook 或脚本分别编号。前两位不按功能规模、变更文件数或兼容性自行调整，也不为新增脚本等非流程更新修改 HTML 版本。这不是按变更性质升主／次版本的语义化版本规则，第三位更新也可能需要配置迁移；职责或门禁变更仍须先确认流程。日常修改正常提交，需要交给团队使用时才统一校验、确定版本、创建 Git 标签及发布说明；已发布标签和内容不覆盖，修正发新版本。 +[历史发布说明](https://git.playones.com/chenmingxuan/EP-Hub-Skill/releases) 保留旧版信息，README 不累积逐版日志。 -发布说明应写清：流程基线、改了什么、使用者需要更新哪些文件、在途项目是否需要重新确认。不要把“仓库已发布”写成“角色已更新”。更新插件缓存、Etunel 中独立配置的 Hook 或迁移在途项目，都需另外明确确认；已运行项目继续使用其登记基线。 +## 维护与验证 -各版本的变更、验证结果和升级注意事项统一查看[发布说明](https://git.playones.com/chenmingxuan/EP-Hub-Skill/releases)。README 只维护当前项目介绍和使用入口，不累积逐版更新记录。 +先读 [AGENTS.md](AGENTS.md) 和本次涉及的 reference。流程来源、中心规则、记录模板和通知示例一起核对，历史模板只参考结构，不恢复旧版必交要求。 -## 协作模型 +在仓库根目录执行： -一个项目使用一个持续的 Hub 会话贯穿整个生命周期。成员之间现阶段不能直接通信，所有跨角色问题、补充信息、成果和返工都由 Hub 定向中继。 - -```mermaid -flowchart LR - subgraph project["一个项目 / 一个持续的 Hub 会话"] - hub["项目 Hub
Hub AI + Hub 负责人"] - business["业务
角色 AI + 负责人"] - product["产品
角色 AI + 负责人"] - tech["技术负责人
角色 AI + 负责人"] - app["嵌入式应用层
角色 AI + 负责人"] - low["嵌入式底层
角色 AI + 负责人"] - hardware["硬件
角色 AI + 负责人"] - testing["测试
角色 AI + 负责人"] - - business <--> hub - product <--> hub - tech <--> hub - app <--> hub - low <--> hub - hardware <--> hub - testing <--> hub - end - - hub -. "公开进度与异常摘要" .-> ding["钉钉群
辅助通知"] -``` - -图中的成员节点均表示“角色 AI 与对应真人负责人”。箭头只连接 Hub：成员不能绕过 Hub 相互发消息。钉钉只有 Hub 发出的单向虚线，不参与任务交付或状态判定。 - -默认角色共八个： - -| 角色 | 主要定位 | -| --- | --- | -| 项目Hub | 建立项目、维护状态、规划任务波次、校验交付结构、协调阻塞并完成跨角色中继 | -| 业务 | 形成业务需求、客户与授权信息，确认客户验收及复盘结项 | -| 产品 | 把业务需求转化为产品定义、范围、交互和验收标准 | -| 技术负责人 | 负责总体技术方案、接口与跨技术域设计协调 | -| 嵌入式应用层 | 负责应用层软件设计、实现、联调和对应成果 | -| 嵌入式底层 | 负责驱动、BSP、底层接口与对应实现成果 | -| 硬件 | 负责硬件方案、设计交付、样机与测试配合 | -| 测试 | 独立制定测试策略、执行验证、管理缺陷并给出质量结论 | - -自定义角色不是自动生效的。它必须先形成职责契约，再由 Hub 真人负责人在 Etunel 中手动添加。Hub 从 Etunel 实际角色清单读取 `role`、`display_name` 和 `relationship`，不让负责人手工确认不存在的成员或会话编号。 - -正常生命周期为：业务需求 → 产品定义 → 方案设计 → 项目规划 → 软硬件实现 → 测试验证 → 平台/客户验收 → 复盘结项。项目可以按已确认基线进行受控跳转、回退或暂缓；模拟项目应显式记录模拟状态，不能冒充真实交付。 - -## 仓库结构 - -```text -EP-Hub-Skill/ -├── AGENTS.md # 后续 Agent 和协作者的仓库级工作规则 -├── README.md # 项目入口与结构说明 -├── etunel-role-collaboration/ # 核心渐进式披露 Skill -│ ├── SKILL.md # 共享硬约束和条件路由 -│ ├── agents/openai.yaml # Skill 展示信息与默认提示词 -│ └── references/ -│ ├── hub-workflow.md # Hub 工作流 -│ ├── member-workflow.md # 成员通用工作流 -│ ├── project-lifecycle.md # 八阶段、成果和门禁 -│ ├── project-status-and-membership.md -│ ├── etunel-message-lifecycle.md -│ ├── document-templates.md # 模板复用与审核边界 -│ ├── artifacts-and-evidence.md -│ ├── exceptions-and-coordination.md -│ ├── human-readable-communication.md -│ ├── project-files-and-progress.md -│ ├── dingtalk-progress-reporting.md -│ ├── dingtalk-script-usage.md # 通知的跨平台调用与负责人提醒 -│ ├── roles/ # 七个成员角色职责 -│ └── testing/ # 测试任务按需读取的二级细则 -├── etunel-role-hook-contexts/ # 八角色独立 Hook 源文件 -├── doc/ # 当前设计基线与模板参考，历史由 Git 保存 -│ ├── Codex多角色项目推进总流程图.html # 当前 V2.0，后续原位更新 -│ └── 文档模板参考/ # 按任务读取的参考笔记与来源清单 -├── .agents/skills/dingtalk-*/ # 钉钉官方能力参考副本，不是核心 Skill -├── .dingtalk/ # 通知接入说明与无秘密示例配置 -└── scripts/ # Hub 辅助通知，不是 Etunel 任务机制 - ├── dingtalk_notify.py # Python 共用实现，含有限重试 - ├── dingtalk-progress # macOS/Linux 进度入口 - ├── dingtalk-message # macOS/Linux 个人摘要与负责人提醒 - ├── dingtalk-progress.ps1 # Windows PowerShell 进度入口 - ├── dingtalk-message.ps1 # Windows PowerShell 个人摘要与提醒 - ├── dingtalk-python.ps1 # Windows 共用启动器，含初始化与检查 - └── test_dingtalk_notify.py # 不联网的隔离测试 -``` - -Skill 被用于实际项目时，Hub 在目标项目中维护统一的 `项目资料/`，而不是把项目成果写回本约束仓库： - -```text -项目资料/ -├── 00-项目管理/ # 项目概览、项目进度、成果索引、项目成员清单 -├── 01-业务需求/ -├── 02-产品定义/ -├── 03-方案设计/ -├── 04-项目规划/ -├── 05-软硬件实现/ -├── 06-测试验证/ -├── 07-平台客户验收/ -└── 08-复盘结项/ -``` - -每个实际使用的阶段按需建立 `阶段记录.md`、`正式成果/<角色名>/` 和 `过程记录/`。Hub 不覆盖正式历史，也不把完整聊天记录当作项目档案。 - -## 如何使用职责 Skill - -Etunel 为角色会话配置本 Skill 后，角色 AI 应按以下顺序工作： - -1. 从当前 Hook、Etunel 角色契约和入站任务确认自己的职责。Hub 通过 `mcp__etunel__etunel_list_roles` 读取实际角色；成员不向负责人追问成员、会话或任务编号。 -2. 读取 [SKILL.md](etunel-role-collaboration/SKILL.md) 的共享约束。 -3. 只打开本次任务所需的引用： - - Hub 先读 [Hub 工作流](etunel-role-collaboration/references/hub-workflow.md)； - - 成员先读 [成员通用工作流](etunel-role-collaboration/references/member-workflow.md)，再读自己的一个[角色职责文件](etunel-role-collaboration/references/roles/)； - - 涉及派发、中继或返回时读 [Etunel 任务消息流程](etunel-role-collaboration/references/etunel-message-lifecycle.md)； - - 涉及成果、证据、状态或豁免时读 [成果与完成判定](etunel-role-collaboration/references/artifacts-and-evidence.md)； - - 涉及对负责人发消息时读 [人类可读沟通](etunel-role-collaboration/references/human-readable-communication.md)； - - 涉及阶段成果、进度或复盘资料时读 [项目文件与进度留档](etunel-role-collaboration/references/project-files-and-progress.md)； - - 涉及缺信息、阻塞、返工、变更或流程跳转时读 [异常与协调](etunel-role-collaboration/references/exceptions-and-coordination.md)。 -4. 成员先和自己的真人负责人对齐任务与输入，形成明确成果、自审并取得负责人确认后，再交给 Hub。 -5. Hub 校验任务结果，按阶段整理实际文件并更新项目进度和成果索引，只把下游需要的信息定向交给下一角色，不广播无关计划或私有对话。 - -不要为了“全面了解”一次加载全部引用。测试专项文件也只有在任务类型匹配时才继续深入读取。 - -## Hook 上下文 - -[etunel-role-hook-contexts/](etunel-role-hook-contexts/) 为八个默认角色各提供一份“精简职责与每轮提醒”。它们适合由 Etunel Hook 在每轮会话中注入，用来持续提醒身份、边界、负责人参与和工具使用。 - -每份 Hook 文档分为“完整职责 JSON”和“每轮精简提醒”两个独立配置区块，分别复制到 Etunel 对应字段。职责 JSON 不是接口请求，实际绑定与工具参数仍以 Etunel 为准。仓库源文件修改不会自动写入已安装插件或 Etunel 配置。 - -Hook 文件需保持短小，并与完整 Skill 职责一致。它们由 Etunel 独立配置，因此不需要从 `SKILL.md` 中发现；修改角色边界时，应同时检查对应角色 reference 与 Hook，避免两套规则漂移。 - -## 钉钉通知参考 - -钉钉集成是 Hub 的辅助通知参考，不是 Etunel 协作系统的一部分。仓库保留它，是为了让 Hub 在满足事件条件时有一个清晰、安全、可替换的调用方法。 - -只有 Hub／主 Agent 可以使用下面的通用 Python 封装入口（Python 3.9+）： - -```sh -python scripts/dingtalk_notify.py progress "<简短中文 Markdown 摘要>" -``` - -五类事件分别表示项目正式开始、可验证里程碑、真实阻塞、整体完成和最终失败。可验证里程碑由 Hub 先完成成果和进度留档，再发送钉钉消息。成员角色不得发送钉钉消息，只把结果交给 Hub。通知正文可使用多行 Markdown，只写可公开的已验证结论、下一步或阻塞原因，不发送密钥、个人数据、大段日志和未经证实的推断。 - -`message --title "中文标题" --text "问题和下一步"` 用于辅助摘要与负责人提醒，可按需用 `--at`；提醒结果回各自角色会话，不在群里另派任务或批准。两个入口均支持文件正文与离线 `--dry-run`，Windows 可用 `.ps1`，macOS/Linux 可用 Shell 入口。它们是同一封装，不要重复调用。 - -所有通知统一使用负责人确认的个人 DWS 登录，不再使用机器人。Hub 在首次初始化时查询账号和项目群，用姓名、组织和群名取得确认后，调用 `init` 自动生成配置；人不用找编号或填密钥。配置只保留通知开关、固定账号、固定群和项目名，个人登录凭据由 DWS 管理。`progress` 也支持 `--at`，事件汇报和行动提醒可合成一条；保留 AI 标识和自动汇报说明，不冒充本人批准。 - -事件语义、有限重试和结果判定见 [钉钉项目进度汇报](etunel-role-collaboration/references/dingtalk-progress-reporting.md)，命令细节见 [通知脚本用法](etunel-role-collaboration/references/dingtalk-script-usage.md)；跨平台安装、初始化和旧配置迁移见 [.dingtalk/README.md](.dingtalk/README.md)。`.agents/skills/dingtalk-*` 是钉钉官方多 Skill 的项目内参考副本，不应被当作 Etunel 核心 Skill，也不应被成员用来绕过 Hub。 - -本地 `.dingtalk/config.env` 已被 Git 忽略，Hub 可在负责人授权范围内创建或修改；不要提交配置、硬编码真实账号／群标识，或读取和传播 DWS 凭据。`accepted` 表示取得个人发送任务回执，不等于已投递、已读或接收端 @ 提醒成功。仓库维护时不要用真实发送作为普通测试。 - -## 修改项目的推荐流程 - -1. 阅读 [AGENTS.md](AGENTS.md) 和本次变更涉及的最小文件集合。 -2. 若变更来自流程设计，核对 [当前 V2.0 总流程图](doc/Codex多角色项目推进总流程图.html)，在固定文件上修改并通过 Git 提交记录变更；不要新增日期目录或旧版副本。部署及在途项目迁移另行确认。 -3. 把共享规则放在公共 reference，把角色专属规则放在对应角色文件，把低频测试细节放在测试二级 reference。 -4. 只有必须让所有角色立即知道的规则才进入根 `SKILL.md`；同时保持条件路由可发现。 -5. 同步检查受影响的 Hook 文件，并验证链接、结构和 Shell 语法。 - -## 验证 - -本仓库没有构建步骤。提交前至少运行： - -```sh +```powershell +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 ``` -修改核心 Skill 后，使用已安装的 Skill Creator 对 `etunel-role-collaboration/` 运行 `scripts/quick_validate.py`。Skill Creator 的位置取决于协作者的 Codex 安装，不要为此把验证器复制进仓库。 +验证器位置随本机安装确定，不复制进仓库。修改 Shell／PowerShell 入口时检查语法与隔离参数传递；所有测试使用假配置，不真实发送。另核对 Markdown 相对链接、渐进式入口及人工确认边界。 -修改钉钉封装后运行隔离测试；Shell 入口有修改时再检查对应语法： +## 设计与参考资料 -```sh -python -X utf8 scripts/test_dingtalk_notify.py -bash -n scripts/dingtalk-progress -bash -n scripts/dingtalk-message -``` - -还应人工确认： - -- 新增 reference 能从根 Skill 或已路由文件按条件发现； -- Markdown 相对链接实际存在； -- 根 Skill、角色 reference 与 Hook 没有职责漂移； -- 没有占位符、秘密配置、真实凭据或不存在的工具与文件； -- 钉钉仍只是 Hub 辅助通知参考，没有进入任务通信或门禁主链路。 - -## 设计资料 - -- [当前总流程图 V2.0](doc/Codex多角色项目推进总流程图.html) -- [文档模板参考](doc/文档模板参考/README.md) -- 历史流程与变更说明通过 `git log --all -- doc/` 查询，不在工作目录保留旧版副本。 -- [核心 Skill](etunel-role-collaboration/SKILL.md) -- [Hub 工作流](etunel-role-collaboration/references/hub-workflow.md) -- [项目生命周期](etunel-role-collaboration/references/project-lifecycle.md) +- [V2.0 总流程图](doc/Codex多角色项目推进总流程图.html) +- [历史文档模板参考](doc/文档模板参考/README.md)：学习笔记与来源索引，原件未打包入仓库。 +- 流程文档固定路径更新，历史使用 `git log --all -- doc/` 查询，不另建版本或日期副本。 diff --git a/doc/Codex多角色项目推进总流程图.html b/doc/Codex多角色项目推进总流程图.html index 572a489..bd8260f 100644 --- a/doc/Codex多角色项目推进总流程图.html +++ b/doc/Codex多角色项目推进总流程图.html @@ -31,7 +31,7 @@
版本与适用范围

V2.0：根据项目实施反馈调整任务流转

编制日期：2026-09-30。本版依据本次已确认的优化要求编写：中心按阶段下发任务；真人角色自行组织执行；完成后提交任务完成情况和结果性资料；中心依据结果决定是否推进。保留八阶段，并按审阅意见合并业务需求文档、将风险纳入立项资料、以链接提供缺陷信息、记录延期成果、增加项目与产品双方核实后的版本放行方式，区分内部与外部验收。

-
本次原位更新流程文档至 V2.0。V1.0 原文通过 Git 历史保留，现有 Skill、Hook 未随本文件同步。本版文档不表示这些运行配置已经部署，也不自动迁移在途项目。具体项目采用 V2.0、运行规则同步和部署，按后续明确决定执行。
+
当前流程基线为 V2.0。V1.0 原文通过 Git 历史保留，仓库中的 中心业务 Skill 已按本版流程及经确认的任务留档方案整理；Etunel 配置与通信使用 etunel-use。源文件更新不表示已安装或部署，也不自动迁移在途项目，具体项目采用与配置变更按明确授权执行。

历史对照：V1.0 原流程文档（Git 历史）。模板来源：文档模板参考。旧文档中的过程节点用于历史对照；采用 V2.0 的项目按本版任务与结果流转执行。