feat: 按 V2.0 重构中心 Skill 与项目留档流程
This commit is contained in:
1 parent
33cc16926c
commit
9f08bc131a
54 files changed
+721
-2961
No files matched your search
@@ -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<br/>Hub AI + Hub 负责人"]
|
||||
business["业务<br/>角色 AI + 负责人"]
|
||||
product["产品<br/>角色 AI + 负责人"]
|
||||
tech["技术负责人<br/>角色 AI + 负责人"]
|
||||
app["嵌入式应用层<br/>角色 AI + 负责人"]
|
||||
low["嵌入式底层<br/>角色 AI + 负责人"]
|
||||
hardware["硬件<br/>角色 AI + 负责人"]
|
||||
testing["测试<br/>角色 AI + 负责人"]
|
||||
|
||||
business <--> hub
|
||||
product <--> hub
|
||||
tech <--> hub
|
||||
app <--> hub
|
||||
low <--> hub
|
||||
hardware <--> hub
|
||||
testing <--> hub
|
||||
end
|
||||
|
||||
hub -. "公开进度与异常摘要" .-> ding["钉钉群<br/>辅助通知"]
|
||||
```
|
||||
|
||||
图中的成员节点均表示“角色 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 <start|milestone|blocked|complete|failed> "<简短中文 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/` 查询,不另建版本或日期副本。
|
||||
Reference in new issue
Block a user