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

.dingtalk/README.md

@@ -1,83 +1,115 @@
-# 钉钉进度通知参考
+# 个人 DWS 项目通知
 
-这里的脚本和配置只演示 Hub 如何向项目群发送辅助通知，不属于 Etunel 的任务通信主链路，也不能代替任务派发、负责人确认、阶段门禁或项目留档。成员 Agent 不调用本脚本。
+Hub 使用负责人确认的个人 DWS 账号发阶段汇报和 @ 提醒。只需要原生 DWS、Python 3.9+ 和一个项目配置文件；不使用机器人、应用密钥、Webhook 或 Stream 监听。
 
-当前布局刻意把工具和项目配置分开：
+**旧版升级：** 用新的个人账号配置替换旧配置，旧机器人配置不会自动转成个人发送授权。摘要入口已改名为 `dingtalk-message`／`dingtalk-message.ps1`，删除目标部署中的旧 `dingtalk-bot-message` 入口及 Stream 实验脚本。更新脚本和 中心 Skill 及实际部署配置 不等于已经迁移在途项目；按实际部署安排确认。
 
-- `dingtalk-workspace-cli@1.0.60` 由 Bun 安装在用户级全局目录，项目不保存二进制或 `node_modules`。
-- 官方 multi skills 保留在项目 `.agents/skills/dingtalk-*`，只对本项目生效。
-- Client ID、群目标、`robotCode` 和汇报开关保存在项目 `.dingtalk/config.env`。
-- Client Secret 从环境变量 `DING_SEC` 读取，未设置时回退到 macOS Keychain；脚本只临时注入给 `dws api`，App Token 由 DWS 自动获取和缓存。
+## 首次由 Hub 完成配置
 
-项目统一通过稳定入口调用全局命令：
+负责人不需要找编号、复制配置模板或填写密钥。Hub 在项目初始化时执行：
 
-```sh
-./scripts/dws version
-```
+1. 检查本机 DWS；未登录时请负责人通过官方 DWS 登录流程授权，不索取密码或 Token。
+2. 用 `dws profile list --format json` 查看可用账号，以姓名和组织向负责人确认发送身份。
+3. 在选定的同一账号下，用 `dws chat +chat-search --query "负责人提供的群名称" --page-all --profile "查询返回的账号标识" --format json` 查群；结果不完整或有多个候选时不能自行选第一个。
+4. 一次问清：“是否由这个账号向这个项目群自动发送进度、阻塞和必要的 @ 提醒？”得到确认后，Hub 把工具实际返回的账号标识、群标识及项目名称传给初始化入口。下面为参数结构，不是需要人填写的编号表：
 
-Bun 默认阻止上游 `postinstall`；本机安装时已校验官方 SHA-256 并只释放 DWS 原生二进制，没有执行会发布全局 Skills 的安装脚本。升级 DWS 时也应保持这一边界。
+   ```text
+   python scripts/dingtalk_notify.py init --profile "实际查询结果" --group "实际查询结果" --project "项目名称" --yes
+   ```
 
-## 应用身份（无需用户登录）
+初始化检查账号存在且可登录，创建 `.dingtalk/config.env` 并启用通知；**不会发测试消息，也不会替人确认群选择**。群标识必须来自该账号的查询结果。初始化不创建钉钉群、不申请权限。已有配置默认不覆盖；迁移或变更账号、群时重新确认，再加 `--replace`，原配置被替换且不另存含密钥的备份。
 
-本项目不执行 `dws auth login`。进度脚本通过 `dws api` 调用企业内部应用 OpenAPI：
+配置仅 4 项：
+
+| 字段 | 含义 | 谁填写 |
+| --- | --- | --- |
+| `DINGTALK_PROGRESS_ENABLED` | `1` 启用、`0` 暂停 | 初始化写入，负责人可随时要求暂停 |
+| `DINGTALK_PROGRESS_PROFILE` | 固定个人账号 | Hub 使用 DWS 真实返回值 |
+| `DINGTALK_PROGRESS_TARGET` | 固定项目群 | Hub 使用同账号查询并经确认的结果 |
+| `DINGTALK_PROGRESS_PROJECT` | 项目名称 | Hub 使用已确认名称 |
+
+配置不包含凭据，但仍是本机信息，本仓库已排除出 Git；Hub 在其他目标项目初始化时也应把 `.dingtalk/config.env` 加入该项目的 Git 忽略规则。不要把它或登录态复制给其他同事；各部署分别确认账号和群。登录由 DWS 自己管理，后续切换 DWS 默认账号不会改变本项目的发送身份。
+
+## Windows 与 macOS/Linux
+
+- 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 不会自动部署这些脚本。
+
+DWS 安装与登录以 [官方项目](https://github.com/DingTalk-Real-AI/dingtalk-workspace-cli) 和当前命令帮助为准；不要为通知分发机器人应用密钥。
+
+## 日常调用
 
 ```text
-POST https://api.dingtalk.com/v1.0/robot/groupMessages/send
+python scripts/dingtalk_notify.py progress milestone --stage "阶段八：复盘结项" "**已确认的进展**
+
+- 相关负责人已确认：产品验收材料已在线下完成，业务已确认客户验收通过。
+- 项目已进入资料归档与复盘结项阶段，目前开始整理结项资料，项目尚未关闭。
+- 已通知相关负责人进行阶段交接，不新增审批。
+
+**待办事项**
+
+- 结项资料整理：由中心真人负责人组织四类结项成果，Hub 协助整理工作稿。
+- 资料补充：由产品负责人、业务负责人补充现有线下成果及确认记录，不重做验收。
+- 旧事项停止：由 Hub 停止此前的验收准备催办。
+- Bug 事实确认：由 Hub 请 @{示例中心负责人} 先确认全部 Bug 的事实、对象、版本和实际处理或承接，已有有效确认直接引用。
+- Bug 处理确认：中心确认事实后，由 Hub 请 @{示例产品负责人} 再次确认并在职责内决定处理；双方无异议后登记最终安排。
+- 结项确认：四类成果、遗留承接及 Bug 双方确认具备后，由 Hub 请 @{示例业务负责人} 确认结项。
+- 关闭决定：业务确认结项后，由 Hub 请 @{示例中心负责人} 决定是否关闭；结项必需项完成后锁定四类成果。
+- 本轮工作范围：不新增应用修复、设备测试或发布验证。
+
+**遗留**
+
+- 原测试不通过的结果如实保留，不因进入结项阶段改为通过。
+- 已接受延期的问题如实保留，后续沿用 Bug 系统中的记录和已有处理安排继续跟进。" --at "示例业务负责人" --at "示例中心负责人" --at "示例产品负责人"
+python scripts/dingtalk_notify.py progress blocked --stage "阶段三：方案设计" "**已确认的进展**
+
+- 本轮无新增已确认进展。
+
+**待办事项**
+
+- 方案设计：请 @{示例甲} 补充接口说明，并通过已约定渠道同步。
+
+**遗留**
+
+- 接口说明尚未补齐，影响方案确认；沿用该事项已有的责任和期限。" --at "示例甲"
+python scripts/dingtalk_notify.py message --title "阶段三：方案设计｜资料补充提醒" --text "**待办事项**
+
+- 方案设计：请 @{示例甲} 补齐已约定的接口资料，并通过已约定渠道确认。" --at "示例甲"
 ```
 
-管理员侧只需确保：
+以上结项场景、事项和姓名仅作格式演示；验收结论、成果数量、延期安排和确认人不作为其他项目的默认事实或要求。真实发送须使用当前项目的有效记录和已确认的真人负责人姓名。
 
-- Client ID/Secret 属于企业内部应用；
-- 应用已有“企业内机器人发送消息”权限（`qyapi_robot_sendmsg`）；
-- `robotCode` 属于同一个应用；
-- 机器人已加入目标 `openConversationId` 对应的群。
+`progress` 现在必须传入 `--stage`，每次使用当前项目记录里的阶段编号和名称；未登记编号时仅写已知名称。标题显示“项目名称｜阶段编号：阶段名称”，不再显示固定的“阶段里程碑”。旧调用需补齐参数，并同步部署脚本和相关 中心 Skill 及实际部署配置；本地改动不等于在途项目已更新。
 
-当前使用 zsh 环境变量时，先确保它已导出（不要把真实值写进项目文件）：
+进度通知使用加粗标题和“已确认的进展”“待办事项”“遗留”三个栏目：待办按“事项名称：由谁做什么”逐条写清，当前及此前阶段尚未解决的问题列入遗留，沿用原计划、当前计划、必须完成的阶段和影响范围。保留已定前提、停止事项和工作范围，阶段启动不写成项目关闭。确实没有待办或遗留时写“无”，未核实不能当作没有；沿用已定责任和期限，不能为了通知新增工作或重填清单。具体写法见[通知规则](../ep-hub/references/dingtalk-progress-reporting.md#消息写法)。通知保留 AI 标识并标注自动汇报；摘要用简短中文 Markdown。在对应事项中写 `@{完整姓名}`，并通过 `--at` 传入相同姓名，脚本唯一匹配后原位生成原生 @；多人分别对应各自事项，同一接收人去重。仅传 `--at` 的旧写法仍在末尾追加提醒。离线预览只显示“@姓名”，不证明实际提醒成功。两个发送命令都支持 `--file` 正文和完全离线的 `--dry-run`。不支持临时换群、手填人员编号或退回机器人发送。
+
+事件含义见 [通知规则](../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 "完整姓名"`：只检查固定账号登录和可选姓名，不发消息，不证明实际 @ 提醒成功。不是每条通知的必做步骤。
+- `accepted` 加有效 `openTaskId`：个人发送请求已接受，不等于已投递或已读。必要时在同账号下用 `dws chat +messages-query-send-status --open-task-id "回执中的实际值" --profile "配置中的账号" --format json` 只读查询；不把任务回执当消息编号，不循环重发。
+- 仅明确 DNS 解析失败最多尝试 3 次、间隔 10 秒；认证、权限或未知结果停止。登录失效请负责人恢复登录，不切账号、不退回机器人。通知失败不阻塞 Etunel 主任务。
+
+维护时只做离线测试；真实发送必须另获明确授权：
 
 ```sh
-export DING_SEC='<Client Secret>'
+python -X utf8 scripts/test_dingtalk_notify.py
+bash -n scripts/dingtalk-progress
+bash -n scripts/dingtalk-message
 ```
-
-也可以不设置 `DING_SEC`，改用本项目专用的 macOS Keychain 项。`-w` 必须放在最后，它会在终端中隐藏输入：
-
-```sh
-/usr/bin/security add-generic-password \
-  -U \
-  -a '<Client ID>' \
-  -s 'com.example.dingtalk.your-project' \
-  -l 'Your project DingTalk bot Client Secret' \
-  -w
-```
-
-`dws auth status` 显示未登录是正常状态，与 App Token 发送链路无关。
-
-## 配置进度群
-
-```sh
-cp .dingtalk/config.env.example .dingtalk/config.env
-chmod 600 .dingtalk/config.env
-```
-
-填写以下非密钥参数：
-
-```dotenv
-DINGTALK_PROGRESS_MODE=app-bot
-DINGTALK_PROGRESS_CLIENT_ID=<Client ID>
-DINGTALK_PROGRESS_TARGET=<openConversationId>
-DINGTALK_PROGRESS_ROBOT_CODE=<robotCode>
-```
-
-先保持 `DINGTALK_PROGRESS_ENABLED=0`。凭据和参数就绪后改为 `1`，并保持 `DINGTALK_PROGRESS_DRY_RUN=1` 做无网络、无发送的请求预览：
-
-```sh
-./scripts/dingtalk-progress milestone "**已完成**
-
-- 项目资料已经归档
-- 本阶段成果已经负责人确认
-
-**下一步**
-
-- Hub 将安排下一阶段任务"
-```
-
-确认请求中的目标和正文正确后，再把 `DINGTALK_PROGRESS_DRY_RUN=0`。真实发送由 Hub 按根目录 `AGENTS.md` 的时机调用；响应中的 `processQueryKey` 才表示服务端已经接受该条机器人消息。摘要可以使用多行 Markdown，重点写已经确认的结果、下一步或阻塞原因，不要粘贴大段日志。

.dingtalk/config.env.example

@@ -1,19 +1,7 @@
-# Copy this file to .dingtalk/config.env, fill the selected mode, then chmod 600 it.
-# Values are literal text after '='; do not add shell quotes.
-
-# Keep both switches safe until credential setup and a dry-run have succeeded.
+# Hub 查询账号和群、取得负责人确认后，用 init 生成真实 config.env。
+# 不需手工复制或填编号；不保存机器人密钥或个人登录凭据。
+# 等号右侧为字面值，不加 Shell 引号。ENABLED=0 暂停通知。
 DINGTALK_PROGRESS_ENABLED=0
-DINGTALK_PROGRESS_DRY_RUN=1
-
-# Enterprise-internal app bot: App Token via dws api; no user OAuth login.
-DINGTALK_PROGRESS_MODE=app-bot
-DINGTALK_PROGRESS_CLIENT_ID=
+DINGTALK_PROGRESS_PROFILE=
 DINGTALK_PROGRESS_TARGET=
-DINGTALK_PROGRESS_ROBOT_CODE=
-DINGTALK_PROGRESS_KEYCHAIN_SERVICE=com.example.dingtalk.your-project
-
-# Client Secret is never stored here. The script first reads exported DING_SEC,
-# then falls back to the project-specific macOS Keychain item above.
-
-DINGTALK_PROGRESS_PROJECT=你的项目名称
-DINGTALK_PROGRESS_TITLE_PREFIX=[项目进度]
+DINGTALK_PROGRESS_PROJECT=

.gitattributes

@@ -1,5 +1,8 @@
 * text=auto
-
+.gitattributes text eol=lf
+.gitignore text eol=lf
+.dingtalk/config.env.example text eol=lf
+.dingtalk/config.env
 *.md text eol=lf
 *.txt text eol=lf
 *.html text eol=lf
@@ -8,4 +11,6 @@
 *.json text eol=lf
 *.py text eol=lf
 *.sh text eol=lf
+*.ps1 text eol=lf
 scripts/dingtalk-progress text eol=lf
+scripts/dingtalk-message text eol=lf

.gitignore

@@ -1,5 +1,7 @@
 # Local credentials and machine-specific configuration
 .dingtalk/config.env
+.dingtalk/config.env.*
+!.dingtalk/config.env.example
 **/.env
 **/.env.*
 !**/.env.example

AGENTS.md

@@ -1,118 +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.1 总流程图](doc/Codex多角色项目推进总流程图.html)，运行规则已整理到中心 Skill；不要求目标项目具备流程 HTML。流程文档固定路径更新，历史由 Git 保留，不另建日期或版本副本。
+3. 先后检查 Git 状态与差异，保护用户已有改动和未跟踪资料。不要删除用户保留的旧源文件来制造干净工作区。
+4. 当前工具 schema、运行时契约、成员登记和已确认项目基线与通用 Skill 有冲突时，说明具体差异；不自行猜测能力、改写已确认基线或绕过运行时权限。
 
-这是以 Markdown、HTML 和 Shell 为主的约束仓库，没有需要猜测的安装或构建步骤。
+仓库更新不等于安装 Skill、修改 Etunel 配置或迁移在途项目。配置和通信使用已安装的 etunel-use；本仓库不维护独立的全角色 Hook 源树，不重造队列、投递、重试、去重、会话授权或文件传输。
 
-## Scope
+## 修改时必须保留的业务边界
 
-本文件适用于整个仓库。若后续子目录新增更具体的 `AGENTS.md`，以距离目标文件最近的规则为准；当前任务中的明确用户要求始终优先。
+- 一个项目使用一个持续的中心会话；默认角色为项目Hub、业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件、测试。新增角色按已确认职责和 Etunel 实际管理能力配置，不伪造已创建结果。
+- 每项任务只有一名主责真人，按交付结果或内聚任务包管理。真人自行设计内部工作流程、直接协作并决定是否使用 Agent；成员 Agent 之间仍经中心中继。
+- 中心组织交付和结果确认，处理依赖、跨角色冲突、信息交接及留档，不替专业真人做结论。阶段推进由中心真人决定，已有条件授权实际满足后按原范围执行并留依据，不能代替业务授权、产品资源排期确认及外部验收。
+- 项目沿用唯一计划主表，新项目默认 Excel 八列模板；Markdown 进度保留摘要和入口。原计划、当前有效计划和实际完成时间分别保存；实际完成只取任务提交后对应真人明确确认完成的时间。工具完成、排队、送达、已读或 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. 当前设计基线为 [V1.0 总流程图](doc/Codex多角色项目推进总流程图.html)（文档生效日期 2026-09-08）。`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/dingtalk-progress` | Hub 通知接入说明、示例配置和当前演示封装 | 不把通知能力扩大为任务派发、审批、门禁或事实源 |
+## 验证与完成
 
-修改共享流程、角色边界、阶段、正式成果或跨角色信息流时，必须同步检查根 Skill、相关公共 reference、受影响角色 reference 和对应 Hook。角色细节优先下沉到角色文件；测试专项优先下沉到测试二级 reference。不要靠复制整段规则维持一致性。
-
-实际项目的运行资料不预先创建在本仓库中。Hub 应按 [项目文件与进度留档](etunel-role-collaboration/references/project-files-and-progress.md) 在使用此 Skill 的目标项目里建立阶段目录、保存正式成果并维护进度和成果索引。
-
-## 钉钉参考集成边界
-
-钉钉内容存在于本仓库，是为了给 Hub 提供“如何调用钉钉发送项目通知”的参考和演示能力，不是本项目的核心职责系统：
-
-- 只有 Hub／主 Agent 可以调用通知；成员 Agent 只向 Hub 返回成果、状态或阻塞。
-- 通知是项目群的单向辅助可见性与异常提醒，不是角色间通信、任务派发、审批、人类确认、项目门禁或项目事实源。
-- Agent 只能使用 `scripts/dingtalk-progress`，事件类型限定为 `start`、`milestone`、`blocked`、`complete` 或 `failed`；不得绕过脚本直接调用 OpenAPI 或 `dws api`。可验证里程碑先完成项目留档，再发送简短中文 Markdown。例如：
-
-  ```sh
-  ./scripts/dingtalk-progress milestone "**已完成**
-
-  - 阶段成果已确认并归档
-
-  **下一步**
-
-  - Hub 安排后续任务"
-  ```
-- 事件语义与消息格式以 [dingtalk-progress-reporting.md](etunel-role-collaboration/references/dingtalk-progress-reporting.md) 为准；安装与本机配置参考 [.dingtalk/README.md](.dingtalk/README.md)。
-- `scripts/dingtalk-progress` 是当前用于跑通通知链路的演示封装，不得据此反推或改变 Etunel 主流程。
-- 仓库维护和测试期间不得把真实发送当作冒烟测试。只有任务明确要求发送且当前环境已经授权时，才允许触发真实通知。
-- 不读取、输出、修改或提交 `.dingtalk/config.env`、Client Secret、`DING_SEC`、App Token 或其他凭据和内部标识。
-
-## 编辑约定
-
-- 使用中文编写项目说明、职责约束、成果名称和面向负责人的消息；机器枚举与运行时字段只在工具确实要求时保留。
-- Markdown 使用相对链接；每个新增链接都应能从仓库中解析。
-- 保持渐进式披露：入口说明“何时读什么”，详细内容放在对应 reference，不在多个文件重复整套流程。
-- Hook 只保留角色定位、关键边界、工具提醒和每轮控制点，避免塞入大段流程正文。
-- 不伪造 Etunel 工具名、参数、角色、成员、会话、状态或尚不存在的文件。
-- 不把模拟流程结果描述为真实发布、客户验收或生产就绪；不适用项对人统一写“不适用”，只在机器字段要求时使用对应枚举。
-- 文本文件保持 LF；不要提交日志、缓存、临时文件、机器专属配置或凭据。
-
-## Quick Commands
-
-修改后按影响范围执行：
+从仓库根目录执行适用检查：
 
 ```powershell
-rtk python -X utf8 "$env:USERPROFILE\.codex\skills\.system\skill-creator\scripts\quick_validate.py" "etunel-role-collaboration"
-rtk "C:\Program Files\Git\bin\bash.exe" -n scripts/dingtalk-progress
-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 的结构校验。
-- 仅在修改 `scripts/dingtalk-progress` 时执行 Shell 语法检查。
-- 所有新增或改动的 Markdown 相对链接均能解析。
-- 文件中没有待办标记、占位内容、真实凭据、群标识或误导性的缺失文件引用。
-- 根 Skill、公共 reference、角色 reference 和对应 Hook 在受影响规则上保持一致。
-- 最终说明修改了哪些文件、依据什么、执行了哪些验证以及仍有哪些未知项；未验证的内容不得声称通过。
-
-## Boundaries
-
-始终执行：保护已有改动；只读必要资料；保持 Hub 中介、人类负责人确认、正式成果和渐进式披露规则一致。
-
-先征得确认：改变当前流程基线、角色集合或职责边界；删除历史资料；批量替换钉钉参考包；进行真实钉钉发送；执行其他不可逆操作。
-
-绝不执行：提交秘密配置；让成员绕过 Hub 直接通信；把钉钉当成 Etunel 任务通道；用 Skill 重造 Etunel 队列机制；为不存在的工具、角色、参数或成果制造虚假规则。
+改变尚未获确认的流程基线、角色集合或职责边界，删除未获授权的历史资料，批量替换官方参考包，真实通知或其他不可逆操作，先取得对应授权。当前任务已明确授权的改造继续完成，不反复索要同一确认。

README.md

@@ -1,194 +1,107 @@
-# Etunel 多角色项目协作约束
+# EP 项目中心 Skill
 
-本仓库为 Etunel 多 Agent 项目提供一套中文版、渐进式披露的角色职责与协作流程：项目Hub负责跨角色中继和全局推进，七个成员角色在各自真人负责人参与下完成专业任务，并以可追踪成果交回 Hub。
+本仓库提供基于 **V2.1 八阶段流程**的项目中心 Skill。中心负责流程把控、交付任务、信息与文件交接、过程记录；各角色真人负责人自行设计内部工作流程，并决定是否使用 Agent。
 
-> **钉钉定位说明：** 仓库中的 `.agents/skills/dingtalk-*`、`.dingtalk/` 和 `scripts/dingtalk-progress` 只作为参考与演示，用来告诉 Hub 如何调用钉钉发送项目进度或异常通知。钉钉不是 Etunel 的角色通信链路、任务队列、审批、门禁或项目事实源，也不会改变任何角色边界。
+## 使用入口
 
-## 先了解这三件事
+- [中心 Skill：ep-hub](ep-hub/SKILL.md)：中心业务规则与按需阅读入口。
+- **已安装的 etunel-use**：Etunel 配置、角色契约、会话绑定与通信操作；不包含本仓库的阶段、成果和留档规则。
+- [当前总流程图](doc/Codex多角色项目推进总流程图.html)：固定路径维护 V2.1，历史通过 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. 当前设计基线为 [V1.0 总流程图](doc/Codex多角色项目推进总流程图.html)（文档生效日期 2026-09-08）。流程文档只维护一份，后续直接更新同一文件，旧版通过 Git 历史追溯，不再按日期或版本另存。仓库更新不代表部署 Skill／Hook 或自动迁移在途项目；运行时规则已整理进稳定 reference，不要求目标项目持有流程 HTML。
+本次按 V2.1 及已确认的实施口径更新阶段汇报、工时与排期、成果确认、Bug 双方确认和关闭后登记规则。旧的全角色 Skill 与独立 Hook 源目录已移除，旧内容仍可从 Git 历史查阅。仓库源文件更新不代表已发布、已安装、已修改 Etunel 配置或已迁移在途项目。
 
-仓库没有应用安装、编译或发布流程。主要工作是维护角色约束、流程文档、Hook 上下文以及 Hub 通知参考集成。
+## 中心与角色怎样协作
 
-## 协作模型
+一个项目使用一个持续的中心会话。任务按可独立确认的交付结果或同一负责人的内聚任务包管理，明确输入、范围、结果、期限和完成条件。真人可以直接协作，接收和提交可在线下完成；成员 Agent 之间的信息仍由中心中继。
 
-一个项目使用一个持续的 Hub 会话贯穿整个生命周期。成员之间现阶段不能直接通信，所有跨角色问题、补充信息、成果和返工都由 Hub 定向中继。
+中心 Agent 汇总事实和待决定事项，角色真人对专业成果负责，中心真人对阶段推进负责。单项任务确认完成后可解锁依赖就绪的后续任务；跨阶段推进需要中心真人决定；已有条件授权实际满足后按原范围执行并记录依据，原授权日期与实际切换日期分别保存。业务授权、产品资源排期确认和外部验收仍按各自权限办理。
 
-```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、底层接口与对应实现成果 |
-| 硬件 | 负责硬件方案、设计交付、样机与测试配合 |
-| 测试 | 独立制定测试策略、执行验证、管理缺陷并给出质量结论 |
+| 1. 业务需求 | 《业务需求》，包含背景及客户里程碑 |
+| 2. 产品定义 | 《立项资料》（含风险）、《测试验收标准》、《里程碑要求》 |
+| 3. 方案设计 | 《测试计划》；《总体技术方案》选填 |
+| 4. 项目规划 | 《项目计划》、《角色分工》、《项目状态内部记录》 |
+| 5. 嵌入式软硬件实现 | 硬件设计包、底层实现资料、应用层固件包 |
+| 6. 测试验证 | 《功能测试报告》；缺陷链接及可靠性、专项、提测佐证选填 |
+| 7. 内部／外部验收 | 内部验收记录、适用的平台／客户验收结果、共用遗留问题清单 |
+| 8. 复盘结项 | 《结项资料归档》、《变更记录》、《结项报告》、《流程闭环总结》 |
 
-自定义角色不是自动生效的。它必须先形成职责契约，再由 Hub 真人负责人在 Etunel 中手动添加。Hub 从 Etunel 实际角色清单读取 `role`、`display_name` 和 `relationship`，不让负责人手工确认不存在的成员或会话编号。
+完整内容与必要确认见 [八阶段与结果要求](ep-hub/references/project-lifecycle.md)。阶段六不要求缺陷清单或零缺陷清单；测试不通过时保留原结论，项目、产品真人共同核实后的放行决定单独记录。阶段八由中心真人组织，全部 Bug 处理或承接先由中心确认、再由产品确认，业务确认结项，中心真人决定关闭。关闭后同步记录、锁定有效成果并停止重复催办；未修复 Bug 和失败测试如实保留。
 
-正常生命周期为：业务需求 → 产品定义 → 方案设计 → 项目规划 → 软硬件实现 → 测试验证 → 平台/客户验收 → 复盘结项。项目可以按已确认基线进行受控跳转、回退或暂缓；模拟项目应显式记录模拟状态，不能冒充真实交付。
+## 记录方式
 
-## 仓库结构
+实际资料保存在目标项目，不在本仓库创建项目档案。
 
-```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
-│       ├── roles/                    # 七个成员角色职责
-│       └── testing/                  # 测试任务按需读取的二级细则
-├── etunel-role-hook-contexts/        # 八角色独立 Hook 源文件
-├── doc/                              # 当前设计基线与模板参考，历史由 Git 保存
-│   ├── Codex多角色项目推进总流程图.html # 当前 V1.0，后续原位更新
-│   └── 文档模板参考/                  # 按任务读取的参考笔记与来源清单
-├── .agents/skills/dingtalk-*/        # 钉钉官方能力参考副本，不是核心 Skill
-├── .dingtalk/                        # 通知接入说明与无秘密示例配置
-└── scripts/dingtalk-progress         # Hub 钉钉通知的当前演示封装
-```
+| 记录 | 用途 |
+| --- | --- |
+| 唯一计划主表 | 完整工作项、当前有效计划和实际执行；已有项目沿用，新项目默认使用 Excel 八列模板 |
+| 项目概览 | 目标、范围、基线、真人分工和资料入口 |
+| 项目进度 | 当前阶段、整体进度、当前待处理和跨阶段未完成事项、影响及必须完成的阶段 |
+| 阶段记录 | 每个任务的成果、完成与确认情况；正式成果和过程分栏 |
+| 任务记录 | 一项任务一份记录，前部显示现状、后部追加关键历史 |
+| 成果索引 | 只索引当前有效最终成果和确认入口 |
 
-Skill 被用于实际项目时，Hub 在目标项目中维护统一的 `项目资料/`，而不是把项目成果写回本约束仓库：
+每项任务保留三类时间：**原计划完成时间、当前计划完成时间、实际完成时间**。实际完成时间是任务提交后经对应真人明确确认完成的时间，提交时间另记。改期保留旧值、原因和真人决定；跨阶段沿用原记录，项目层持续跟进。
 
-```text
-项目资料/
-├── 00-项目管理/        # 项目概览、项目进度、成果索引、项目成员清单
-├── 01-业务需求/
-├── 02-产品定义/
-├── 03-方案设计/
-├── 04-项目规划/
-├── 05-软硬件实现/
-├── 06-测试验证/
-├── 07-平台客户验收/
-└── 08-复盘结项/
-```
+每个阶段使用 `阶段记录.md`、`正式成果/`、`过程记录/`。正式区只放真人完成并确认的最终版及确认；草稿、旧版和历史确认保留在过程区。外部成果登记完整真实入口、用途、版本及确认，不强制下载、复制或截图。项目明确授权本地复制时，保存已取得且确认有效的资料、来源与路径映射，操作日期不改变原提交及确认日期。
 
-每个实际使用的阶段按需建立 `阶段记录.md`、`正式成果/<角色名>/` 和 `过程记录/`。Hub 不覆盖正式历史，也不把完整聊天记录当作项目档案。
+排期评估和计划更新见 [项目计划规则](ep-hub/references/project-planning.md)。中心主动在持续会话汇报阶段结果，不能仅更新本地文件；详见 [阶段汇报](ep-hub/references/stage-reporting.md)。
 
-## 如何使用职责 Skill
+模板可从 [记录与留档](ep-hub/references/project-records.md) 按需打开。Markdown 用明确标题、短摘要、分条字段和关键历史，未知信息如实标明。
 
-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 校验任务结果，按阶段整理实际文件并更新项目进度和成果索引，只把下游需要的信息定向交给下一角色，不广播无关计划或私有对话。
+1. 将仓库中的完整 `ep-hub/` 作为中心 Skill 安装到目标环境的 Skill 目录，保留 `references/`、`assets/` 和 `agents/`；具体安装位置遵循目标环境配置。
+2. 配置与通信使用目标环境已安装的 `etunel-use`。修改 Etunel 中心或成员契约时，按其管理操作和职责 Hook 指南办理；中心自身配置与成员配置是不同操作。
+3. 检查目标项目实际启用的旧 Skill、职责契约与 Hook。迁移须明确目标与范围，保留项目既有任务、时间、旧成果和确认记录；不能仅因仓库升级就宣称在途项目采用 V2.1。
+4. 在迁移已获确认后，按目标环境的安装与配置机制停用冲突的旧角色流程约束。成员内部流程由各角色真人维护，新中心 Skill 不分发统一的内部操作提示词。
+5. 需要钉钉时，将仓库 `scripts/` 中的共用 Python 文件和所需平台入口部署到目标项目 `scripts/`；中心 Skill 安装不会自动部署脚本。按 [钉钉配置说明](.dingtalk/README.md) 确认个人账号、项目群和通知范围。
 
-不要为了“全面了解”一次加载全部引用。测试专项文件也只有在任务类型匹配时才继续深入读取。
+## 钉钉通知
 
-## Hook 上下文
+通知是中心向项目群提供进度与行动提醒的辅助能力。先维护事实记录，再依授权发送。消息标题来自项目当前阶段，正文固定为 **已确认的进展／待办事项／遗留**，逐项写清谁做什么，沿用原有责任、时间、范围和停止事项。
 
-[etunel-role-hook-contexts/](etunel-role-hook-contexts/) 为八个默认角色各提供一份“精简职责与每轮提醒”。它们适合由 Etunel Hook 在每轮会话中注入，用来持续提醒身份、边界、负责人参与和工具使用。
+- 已获批准或条件授权实际满足的阶段交接合为一条“上一阶段总结＋下一阶段安排”；等待决定先在中心会话汇报。阶段内关键进展、阻塞和失败仍按已授权范围通知，同轮合并；实际关闭后发一次结项总结，正文及实际发送结果进入阶段过程记录。
+- 用 `scripts/dingtalk_notify.py` 的 `progress`／`message` 或同等平台入口；`progress` 必须提供 `--stage`。
+- 真人提醒在正文使用 `@{完整姓名}`，同时用 `--at` 列出姓名；脚本唯一匹配后原位生成提及。
+- `--dry-run` 完全离线，只展示内容，不证明账号、群或 @ 有效。
+- `accepted` 只表示个人发送请求获接受，不等于送达、已读、真人确认或接收端提醒成功。
+- 仅明确 DNS 失败有限重试；未知结果不重复发送。钉钉异常不阻塞项目工作。
+- 本地配置由目标项目保存且不提交；不读取或输出 DWS 凭据，不把真实发送作为仓库测试。
 
-每份 Hook 文档分为“完整职责 JSON”和“每轮精简提醒”两个独立配置区块，分别复制到 Etunel 对应字段。职责 JSON 不是接口请求，实际绑定与工具参数仍以 Etunel 为准。仓库源文件修改不会自动写入已安装插件或 Etunel 配置。
+消息模板和事件语义见 [通知规则](ep-hub/references/dingtalk-progress-reporting.md)，命令示例见 [脚本用法](ep-hub/references/dingtalk-script-usage.md)。`.agents/skills/dingtalk-*` 保留为官方能力参考，不是中心核心规则，不批量改动。
 
-Hook 文件需保持短小，并与完整 Skill 职责一致。它们由 Etunel 独立配置，因此不需要从 `SKILL.md` 中发现；修改角色边界时，应同时检查对应角色 reference 与 Hook，避免两套规则漂移。
+## 版本与升级
 
-## 钉钉通知参考
+当前发布版本为 `v2.1.0`，流程基线为 **V2.1**。版本统一采用 `vX.Y.Z`：前两位跟随 HTML 中已确认的流程版本，第三位是该流程下的发布迭代。V2.1 对应 `v2.1.Z`，该流程首次正式发布从 `v2.1.0` 开始；日常修改不自动创建标签。
 
-钉钉集成是 Hub 的辅助通知参考，不是 Etunel 协作系统的一部分。仓库保留它，是为了让 Hub 在满足事件条件时有一个清晰、安全、可替换的调用方法。
+- 流程版本不变，Skill、脚本、配置或文档变更只递增第三位；不按功能规模或兼容性自行改前两位，也不为凑发布号修改流程图。
+- 流程正式更新到新的 X.Y，前两位同步，第三位从 0 开始。全仓库一个发布序列，组件不另编号；第三位更新也可能需要迁移。
+- 仅在用户要求时提交、推送或发版；已发布标签不覆盖或移动。发布以 Git 标签和对应发布包为准，不能将本地修改说成已发布。
+- 发布说明写清流程基线、修改、验证、需更新的安装与配置及在途项目影响。发布不等于部署，插件缓存和在途项目迁移另外明确确认。
 
-只有 Hub／主 Agent 可以使用下面的封装入口：
+[历史发布说明](https://git.playones.com/chenmingxuan/EP-Hub-Skill/releases) 保留旧版信息，README 不累积逐版日志。
 
-```sh
-./scripts/dingtalk-progress <start|milestone|blocked|complete|failed> "<简短中文 Markdown 摘要>"
-```
+## 维护与验证
 
-五类事件分别表示项目正式开始、可验证里程碑、真实阻塞、整体完成和最终失败。可验证里程碑由 Hub 先完成成果和进度留档，再发送钉钉消息。成员角色不得发送钉钉消息，只把结果交给 Hub。通知正文可使用多行 Markdown，只写可公开的已验证结论、下一步或阻塞原因，不发送密钥、个人数据、大段日志和未经证实的推断。
+先读 [AGENTS.md](AGENTS.md) 和本次涉及的 reference。流程来源、中心规则、记录模板和通知示例一起核对，历史模板只参考结构，不恢复旧版必交要求。
 
-更详细的 Hub 事件语义、有限重试和结果判定见 [钉钉项目进度汇报](etunel-role-collaboration/references/dingtalk-progress-reporting.md)；当前演示接入与本地配置见 [.dingtalk/README.md](.dingtalk/README.md)。`.agents/skills/dingtalk-*` 是钉钉官方多 Skill 的项目内参考副本，不应被当作 Etunel 核心 Skill，也不应被成员用来绕过 Hub。
+在仓库根目录执行：
 
-本地 `.dingtalk/config.env` 已被 Git 忽略。不要读取、输出或提交其中的配置；不要在文档、Skill、Hook 或脚本中硬编码 Client Secret、Client ID、`robotCode`、`openConversationId`、App Token 或群名。仓库维护时也不要用真实发送作为普通测试。
-
-## 修改项目的推荐流程
-
-1. 阅读 [AGENTS.md](AGENTS.md) 和本次变更涉及的最小文件集合。
-2. 若变更来自流程设计，核对 [当前 V1.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 相对链接、渐进式入口及人工确认边界。
 
-修改钉钉演示脚本后再运行：
+## 设计与参考资料
 
-```sh
-bash -n scripts/dingtalk-progress
-```
-
-还应人工确认：
-
-- 新增 reference 能从根 Skill 或已路由文件按条件发现；
-- Markdown 相对链接实际存在；
-- 根 Skill、角色 reference 与 Hook 没有职责漂移；
-- 没有占位符、秘密配置、真实凭据或不存在的工具与文件；
-- 钉钉仍只是 Hub 辅助通知参考，没有进入任务通信或门禁主链路。
-
-## 设计资料
-
-- [当前总流程图 V1.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.1 总流程图](doc/Codex多角色项目推进总流程图.html)
+- [历史文档模板参考](doc/文档模板参考/README.md)：学习笔记与来源索引，原件未打包入仓库。
+- 流程文档固定路径更新，历史使用 `git log --all -- doc/` 查询，不另建版本或日期副本。

doc/文档模板参考/README.md

@@ -2,7 +2,7 @@
 
 登记日期：2026-09-08。根据用户提供的 `D:/AI全流程辅助/项目推进总流程` 只读学习，供后续资料生成和审核时按需查阅。
 
-流程依据：[V1.0 总流程图](../Codex多角色项目推进总流程图.html)。本参考不是新流程基线，不改变 Skill、Hook、角色职责或门禁，也不表示已部署。
+本页及所链接笔记保留 2026-09-08 的 V1.0 学习事实和当时口径，供查找源资料、复用栏目；其中旧的必交成果、确认链和流程编号不作为当前规则。当前依据为 [V2.0 总流程图](../Codex多角色项目推进总流程图.html) 与 [中心成果规则](../../ep-hub/references/project-lifecycle.md)。特别是阶段六现不要求缺陷清单或零缺陷清单，缺陷链接选填；角色内部流程由对应真人安排。以下历史记录不代表部署状态。
 
 ## 先读什么
 

ep-hub/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: ep-hub
+description: 作为项目中心，按八阶段管理交付任务、真人确认、信息交接、项目进度和成果留档，并生成钉钉通知。用于中心推进项目与处理延期、变更、验收和结项；成员内部工作方式由各自真人负责人设计，Etunel 配置与通信操作使用 etunel-use。
+---
+
+# 项目中心
+
+一个项目使用一个持续的中心会话。中心 Agent 整理事实、交接资料、维护记录并提出待决定事项；中心真人负责人依据结果决定推进、补充、退回或暂缓。成员的执行方法、内部评审和 Agent 使用方式由各自真人负责人安排。
+
+## 工作边界
+
+- 按可独立确认的交付结果管理任务；同一负责人承担的内聚工作可组成任务包。每项任务有一名主责真人、明确输入、范围、结果、期限与完成条件，不拆成中心监督的内部步骤。
+- 真人可以直接协作，任务接收与结果提交可以在线下完成；必须保留实际接收、提交和确认的依据。成员 Agent 之间的信息仍经中心定向中继。
+- 同一阶段内，任务确认完成后可启动依赖已经满足的后续任务；跨阶段须有中心真人明确决定，已有条件授权实际满足后按原范围执行并记录依据，不重复申请。中心决定不能替代专业判断、业务授权、产品授权范围内的资源排期确认或外部验收。
+- 正式成果保存真人完成并确认的全部有效成果、配套资料或完整外部入口及确认；草稿、旧版、历史确认和中心推进决定进入过程记录。链接交付不强制下载、截图或复制；本地复制按项目明确授权处理。
+- 实际完成时间是任务提交后，经对应真人明确确认完成的时间。提交、送达、已读、Agent 检查或工具任务完成都不能替代这一确认。
+- 项目层持续显示当前阶段、整体进度、当前待处理事项，以及未完成事项的原计划、当前计划、影响范围和必须完成的阶段；跨阶段沿用原任务记录。
+- 不重复要求已有有效确认；成果或版本发生实质变化、适用范围扩大或出现相反证据时，仅重新确认受影响部分。
+- 遵循已确认的项目基线、真人授权和当前运行时契约。发现冲突时说明具体差异，取得有权人的处理决定；不自行改写基线、伪造工具或把部署未完成说成已生效。
+
+## 按当前任务读取
+
+| 要做什么 | 读取什么 |
+| --- | --- |
+| 接收请求、组织交付任务、收取结果或交接阶段 | [中心工作流](references/hub-workflow.md) |
+| 向中心真人汇报阶段结果、请求推进或执行条件授权 | [阶段汇报与推进决定](references/stage-reporting.md) |
+| 判断阶段、应交成果和推进条件 | [八阶段与结果要求](references/project-lifecycle.md)，只读当前阶段及受影响阶段 |
+| 评估工时、衔接周期、编排或更新计划主表 | [工时、周期与项目计划](references/project-planning.md) |
+| 建立目录、更新任务、阶段和项目进度 | [记录与留档](references/project-records.md)，按需使用其中的记录模板 |
+| 判断成果、真人确认、版本替换或完成时间 | [成果与确认](references/artifacts-and-confirmation.md) |
+| 处理延期、阻塞、变更、退回、豁免、放行或 Bug 双方确认 | [异常与决定](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,51 @@
+# 任务记录
+
+> 填写指引：标题改为明确的任务名称，紧接一句当前情况。前部维护最新事实，关键历史按时间追加；内部执行步骤由角色真人自行安排。
+
+## 当前情况
+
+- **任务状态**：按真实情况填写；提交未确认时为“待确认”。
+- **主责真人**：记录姓名和角色；协作者按需要另列。
+- **所属阶段**：记录任务原所属阶段。
+- **原计划完成时间**：保留首次确认的期限。
+- **当前计划完成时间**：记录最近一次经确认的有效期限。
+- **实际完成时间**：任务提交后经对应真人明确确认完成的时间；尚未确认时写“尚未确认完成”。
+- **必须完成的阶段**：记录已确认安排。
+- **开始时间**：有约定时分别保留原计划、当前计划与实际开始时间。
+
+## 任务要求
+
+- **目标**：说明可独立判断的交付结果。
+- **输入资料**：逐条列有效资料、版本与实际位置。
+- **处理范围**：区分本阶段必须完成、后续处理与当前不需要。
+- **应交结果**：列成果或成果包、最低内容、必需／选填与下游用途。
+- **完成条件**：列结果要求、必要真人确认与授权，沿用已有约定。
+- **依赖**：只列影响当前执行或交接的输入与条件。
+
+## 成果与确认
+
+- **接收情况**：记录真人实际接收时间及依据；只有发送证据时标为接收待确认。
+- **提交情况**：每次提交单列提交人、时间、成果版本和完整入口、用途；本人说明其他渠道已提交时据实登记，入口缺失、接收待确认与验收待确认分别列出。
+- **完成情况**：说明已完成、未完成部分及具体缺口。
+- **确认情况**：每项单列确认人、真实确认时间、任务／成果及版本、结论、范围和条件。
+- **确认来源**：记录直接确认或线下转述；转述保留实际确认人、转述人、来源及补录时间。
+- **采用与存放调整**：适用时分别记录采用对象和日期、本地复制授权、原路径到正式路径映射及操作日期，不覆盖原提交或确认日期。
+
+需要评估时在此嵌入 [工时与周期栏目](工时与周期评估.md)；涉及 Bug 时沿原问题／共用记录保留中心先确认、产品再次确认的 [字段与历史](../../references/exceptions-and-decisions.md#bug-处理与双方最终确认)。生成实际项目记录时仅保留适用内容和真实入口，不将模板链接当项目事实。
+
+## 下一步与影响
+
+- **下一步**：写清谁需要做什么、需要谁作出什么决定。
+- **延期或阻塞**：写明事实、原因及是否超过原计划／当前计划。
+- **影响范围**：列受影响任务、成果、阶段或对外节点；未知写待确认。
+- **处置或承接**：保留有权真人决定、期限与必须完成阶段，取消／豁免不写为实际完成。
+
+## 关键历史
+
+### 事件时间与名称
+
+- **参与人**：记录实际执行、提交或作出决定的人。
+- **发生了什么**：记录接收、提交、退回、确认、改期、变更或重开。
+- **变化前后**：涉及日期、版本、范围变化时保留旧值与新值。
+- **依据与原因**：记录有效来源、真人结论及原因。
+- **影响及后续**：说明受影响范围和下一步，不复制内部操作或完整聊天记录。

ep-hub/assets/templates/工时与周期评估.md

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

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

@@ -0,0 +1,12 @@
+# 当前正式成果索引
+
+> 填写指引：按阶段逐项列出真人完成并确认的当前最终成果。任务状态、草稿、旧版、延期和推进决定在过程记录中维护。
+
+## 阶段名称
+
+### 成果名称
+
+- **当前最终版本**：记录实际有效版本。
+- **位置与用途**：逐项登记全部有效原件／包、配套资料或真实完整外部入口与用途；包内容可引用有效索引，不强制复制外部内容。
+- **确认记录**：链接对应阶段的正式确认栏目，确认详情由那里统一维护。
+- **存放调整**：适用时关联本地复制授权、原位置与正式位置映射、操作日期；不改原提交、采用或确认时间。

ep-hub/assets/templates/结项资料归档.md

@@ -0,0 +1,32 @@
+# 结项资料归档
+
+> 使用指引：作为既有《结项资料归档》的内容结构，沿用项目已确认格式，不新增第五类结项成果。以下说明替换为真实资料与依据。
+
+## 归档范围
+
+- **项目与范围**：明确实际采用的版本和本次整理范围。
+- **当前成果索引**：关联项目唯一成果索引。
+
+## 各阶段有效资料
+
+### 阶段名称
+
+- **管理开始日期与依据**：中心真人实际启用；条件授权时记录实际切换。
+- **管理完成日期与依据**：明确结束／下一阶段决定；条件授权交接取实际切换日期，阶段八为关闭日期，进行中留空。
+- **工程实际日期**：按实际需要分别记录开发、测试和验收日期及来源。
+
+#### 成果名称
+
+- **有效版本与用途**：列每项成果、配套资料及包内容；一包多成果可引用有效内容索引。
+- **完整入口**：已保存原件／包的实际路径，或真实完整外部地址；不能只列概括目录。
+- **提交与采用**：分别记录真人、日期、对象、范围及依据。
+- **最终确认**：记录确认人、真实日期、对象版本、结论、范围与条件。
+- **原任务及过程记录**：关联原任务、旧版和历史确认。
+- **本地复制或地址调整**：适用时记录授权、原路径与现路径映射、操作日期；不得覆盖原提交、采用、确认或完成时间。
+
+## 关闭及承接
+
+- **Bug 处理与承接**：引用原报告／共用记录中的中心和产品双方最终确认，保留未修复事实与后续责任。
+- **其他遗留**：逐项列状态、责任、原计划、当前计划、影响及必须完成阶段。
+- **业务结项确认与中心关闭决定**：分别列真人、日期、原话、范围、条件和依据。
+- **关闭后登记**：记录概览、进度、阶段、原任务、索引、报告与汇总的同步情况，以及有效成果锁定和停止重复催办情况。

ep-hub/assets/templates/阶段成果汇报.md

@@ -0,0 +1,33 @@
+# 阶段成果汇报
+
+> 使用指引：可直接作为中心聊天的汇报结构；也可写入阶段过程记录。不新增正式成果要求。将以下说明替换为真实事实。
+
+## 当前阶段
+
+- **项目与汇报日期**：记录项目名称和本次真实汇报日期。
+- **阶段与状态**：记录阶段编号、名称、当前情况及管理开始／完成日期；进行中完成日期留空。
+- **本轮需要决定**：说明推进、补充、退回、暂缓或承接的具体事项。
+
+## 逐项任务与成果
+
+### 任务名称
+
+- **主责真人与完成情况**：记录实际负责人、完成部分和未完成部分。
+- **应交成果**：逐项列必需／选填及适用条件。
+- **已交成果**：每份单列名称、版本、确认用途和完整可点击入口；同一成果包可引用有效内容索引。
+- **确认情况**：逐项列确认人、真实时间、对象、结论、范围、条件和来源；缺失确认单列。
+- **时间**：分别列原计划、当前计划、提交时间和提交后真人确认的实际完成时间。
+- **原任务记录**：引用唯一原记录。
+
+## 未完成与待确认
+
+- **事项**：每项单列状态、原因、依赖、主责、原计划、当前计划、影响及必须完成阶段。
+- **需要的决定**：列已有安排、建议和待决定内容，分别标明。
+
+确实没有时写“未完成项：无；待确认项：无”。资料不足时说明待核实部分。
+
+## 下一步安排
+
+- **建议**：按当前事实提出下一步。
+- **已有决定或条件授权**：记录真人、原话、日期、范围与条件；条件满足及实际切换日期另记。
+- **仍待决定**：列需要谁确认什么，以及确认后的动作。

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

@@ -0,0 +1,62 @@
+# 阶段记录
+
+> 填写指引：标题改为阶段编号与名称，紧接一句当前情况。下面两个栏目分别保存最终成果和任务过程；每个任务都要逐项汇总。
+
+- **阶段状态**：记录未开始、进行中、待确认、已完成或实际例外状态。
+- **管理开始日期与依据**：中心真人实际启用日期；条件授权时取实际切换日期。
+- **管理完成日期与依据**：明确结束或进入下一阶段的决定日期；条件授权交接取实际切换日期，阶段八取明确关闭日期，进行中留空。
+- **工程实际日期**：按实际需要另记开发、测试和验收日期，不以管理日期计算工程延期或人时。
+- **当前情况**：概括本阶段完成到哪里。
+
+## 正式成果及确认记录
+
+### 最终成果
+
+- **成果名称**：每项最终成果独立列出。
+- **最终版本**：记录真人完成并确认的当前有效版本。
+- **保存位置与用途**：逐项给全部有效文件、配套资料或包内有效索引的完整实际入口及用途；不能只列总目录。
+- **提交与采用**：分别记录实际日期、对象和来源；复制或补地址日期另记。
+
+### 对应真人确认
+
+- **确认人**：记录实际作出确认的人。
+- **确认时间**：记录真实时间。
+- **成果与版本**：明确此次确认的对象。
+- **结论**：记录真实确认结论。
+- **范围和条件**：保留适用范围与附带条件。
+- **来源**：链接已有依据；转述时注明转述人、来源与补录时间。
+
+## 过程记录
+
+### 任务名称
+
+- **负责人**：记录主责真人。
+- **成果情况**：分条说明应交、已交、版本和位置；待确认稿不能列为正式最终成果。
+- **完成情况**：说明任务状态、已完成与尚缺部分。
+- **确认情况**：列已确认人、时间、对象、结论和未完成的必要确认。
+- **原计划完成时间**：记录首次期限。
+- **当前计划完成时间**：记录最新有效期限。
+- **实际提交时间**：记录本人提交事实与来源；线下已交但入口缺失时分别说明。
+- **实际完成时间**：任务提交后经真人明确确认完成的时间；未确认写“尚未确认完成”。
+- **影响及下一步**：列责任、动作、必须完成的阶段及跨阶段承接。
+- **任务原记录**：链接该任务的唯一记录。
+
+### 阶段决定与未完成事项
+
+- **决定**：每次单列决定人、时间、推进／补充／退回／暂缓结论、依据、范围和理由。
+- **条件授权**：适用时分别记原授权日期、原话、条件、条件实际满足日期与依据、实际切换日期；不倒填已推进。
+- **未完成事项**：逐项引用原任务，列原计划、当前计划、必须完成阶段、影响、承接与阶段结束提醒情况。
+- **历史资料**：链接旧版、草稿、历史确认及替代关系。
+
+### 汇报与通知
+
+- **中心会话汇报**：记录本次汇报时间、涉及任务与成果、未完成／待确认事项及待决定内容。
+- **群总结**：记录对应交接或关闭决定、已发送正文及实际结果；区分未发送、请求已接受、送达和已读，只写有依据的状态。
+- **补充汇报**：仅实质变化时补充受影响内容；核对前次记录避免重复通知同一次交接。
+
+### 关闭后登记（阶段八适用）
+
+- **Bug 双方确认**：引用原问题或共用记录中的最终确认与分歧历史。
+- **关闭决定**：记录中心真人、真实日期、原话、范围和条件，业务结项确认另列。
+- **同步与锁定**：记录项目概览、进度、原任务、索引、报告和汇总同步情况，以及有效成果锁定情况。
+- **停止催办与后续**：停止已结束／已确认事项的重复催办；未完成承接和队列未送达分别记录。

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

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

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

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

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

@@ -0,0 +1,49 @@
+# 成果与真人确认
+
+用于提交、接收、完成确认和版本替换。阶段特有的确认人按 [八阶段与结果要求](project-lifecycle.md)，不把中心真人确认推广为所有专业成果的重复审批。
+
+## 分清事实
+
+| 事实 | 如何记录 |
+| --- | --- |
+| 已发出任务或资料 | 记录发送渠道和时间；没有接收依据时，接收待确认 |
+| 真人已接收 | 记录实际接收人、时间、任务或成果版本及依据 |
+| 已提交成果 | 记录提交人、时间、版本与位置，完成确认尚缺时为“待确认” |
+| 真人确认成果或任务完成 | 记录确认人、时间、对象及版本、结论、范围、条件与来源 |
+| 同意推进或放行 | 在过程记录中单独记有权真人的决定；不替换成果本身结论 |
+
+中心真人可在会话中明确转述线下接收、提交或确认事实。保留实际确认人、真实确认时间、对象、结论和范围，并注明转述人、来源及补录时间；缺失信息写待补充。不要求另做审批单、截图或重复确认，不能把转述者写成专业确认人。
+
+本人明确已通过其他渠道提交时，登记已提交。资料入口未提供、接收人尚未确认可用、验收尚未取得结论是不同缺口，逐项记录；无聊天附件、Agent 本端无法读取或队列仍待投递不推翻线下提交事实。
+
+## 供真人查看的成果
+
+请求中心真人确认前，逐项列出本次范围内全部有效文件的名称、版本、确认用途和完整可点击地址，或直接展示文件。成果包可使用能逐项定位内容的有效索引；只给概括目录、摘要或中心确认记录不足以支持查看。
+
+专业内容和接收可用性由相应真人判断。Agent 无法读取本地盘、共享盘或外部链接，只能说明本端访问失败，不能推定成果不存在、未提交或不兼容。不把下载、解包、截图、重算哈希设成固定前置条件。已有包身份和真实入口时交相关真人确认可用，仅补实际缺口，不要求重做或反复上传。
+
+文件、需求或版本存在差异时，由有权真人决定采用的内容、对象、版本和范围。分别记录当前同步情况、历史实际审阅对象及差异对原结论的影响；不能补造历史审阅或把当前采用倒填为过去已审阅。
+
+## 实际完成时间
+
+**任务提交后，经对应真人明确确认该任务完成的时间，才是实际完成时间。**
+
+- 提交时间、专业成果确认时间和任务完成确认分别记录，可引用同一条有效确认，避免重复审批。
+- 任务条件需要多项确认时，以最后一项必要完成确认的真实时间为准；阶段推进决定另记，不延后已完成任务的时间。
+- 已提交未确认写“待确认／尚未确认完成”；不能用提交时间、Agent 检查时间、Etunel 完成回执或补录时间代填。
+- 退回后继续保留原任务及历次提交。重新提交获最终完成确认后记实际完成时间。
+- 已完成任务因实质变化重开时，保留旧完成事实和重开原因；当前要求未确认完成前不沿用旧时间表示新版已完成。
+- 取消、豁免、延期承接是处置结果，另记处置人和时间，不填为实际交付完成时间。
+
+## 正式成果与历史
+
+- 正式区保存真人完成并确认的全部有效成果和配套资料，每项一个当前有效版本。保存原件／包，或登记真实完整外部入口；确认另列确认人、时间、对象及版本、结论、范围和条件。概括目录或确认记录不能代替资料本身。
+- 待确认稿、部分成果、候选固件、旧版及其历史确认进入过程区。任务记录关联所有提交，阶段正式栏目只列最终成果。
+- 新版获真人确认后才替换当前条目；先保留旧文件、旧确认及替代关系到过程区，再更新正式记录，不能覆盖丢失历史。外部链接成果保留旧地址、版本、确认及替代关系；不额外下载快照，外部系统是否保留历史如实记录。
+- 中心推进、豁免、版本放行、产品接收等事实放过程记录，引用相关正式成果。名为《变更记录》《流程闭环总结》的交付文档，在真人确认最终版后仍属于正式成果。
+- 同一文件或连贯成果包可承载多个结果，不为凑名称拆造文件。名称含“草稿／预览”不自动否定真人已确认采用的正式地位；按实际确认判断，不为分区删改成果正文。
+- 链接交付登记真实地址、用途、版本与确认；内容核实由真人负责，不强制复制、摘要、截图或可下载检查。项目明确授权本地复制时，把已取得且确认有效的原件和配套资料复制到对应阶段正式区，保留原交接记录及原路径到现路径的映射，更新索引到正式位置。
+- 复制或补地址日期单独记录，不替换提交、采用、确认、实际完成或阶段日期；未取得的原件仍如实列缺口，不能写已归档。
+- 实质变更、范围扩大或相反证据需要重新确认受影响部分；仅改存放位置、阶段引用或转述补录不自动触发重签。
+
+测试“不通过”可被真人确认是实际测试结论，不能因版本获放行改成“通过”。测试结果确认、版本放行、阶段推进与外部验收分别保留。

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

@@ -0,0 +1,153 @@
+# 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 必须先核对真实事实，更新对应任务、阶段和项目进度记录；涉及正式成果变化时再更新成果与索引，然后发送钉钉消息。不为一次通知新增成果文件。钉钉发送失败不回滚留档，也不阻塞项目主任务。
+
+## 阶段交接与结项总结
+
+- 每次中心真人批准推进，或已有条件授权实际满足并已执行交接后，在已启用且获授权的通知范围内，将上一阶段总结与下一阶段安排合为一条 `milestone`。标题使用实际当前阶段。
+- 等待推进决定时，先在中心会话按 [阶段汇报规则](stage-reporting.md) 说明成果、未完成项及待决定事项，不发宣称已进入下一阶段的总结；已授权的实质进展或阻塞通知仍可按实际事件发送。
+- 正文仍用“已确认的进展／待办事项／遗留”：进展写上一阶段成果和真实推进决定；待办写下一阶段全部已确认任务、主责和期限，未知字段如实说明；遗留写未完成及待确认、影响和承接。完整成果汇报放中心会话，群里可引用适合接收者访问的有效记录入口，不能为缩短篇幅遗漏待办或停止事项。
+- 第八阶段取得明确关闭决定后发送一次 `complete` 结项总结，列有效成果、关闭决定及承接事项的主责和计划。后续资料整理、补地址不重复发关闭通知。
+- 将总结正文、对应决定和实际发送结果记入阶段过程记录；生成前核对是否已通知同一次交接或关闭。复用原记录，不增加通知队列或脚本外重试。API 接受、投递和已读分别记录，未知结果不盲目重发。
+
+## 事件判定
+
+### start
+
+每个项目最多一次。在第一个真实可执行任务或任务波次已经交给主责真人且已有实际接收依据后（可以通过 Etunel 或其他已授权渠道）发送。仅建立计划、等待输入或讨论想法时不发送。
+
+### milestone
+
+在可验证、会改变下一步的实质进展完成并已留档时发送，例如：
+
+- 关键成果或版本成为当前有效版本；
+- 一个有意义的任务波次完成并触发角色或阶段交接；
+- 门禁、受控跳转、回退或豁免完成真实记录和必要确认；
+- 正式阻塞解除，项目恢复到明确下一动作；
+- 统一固件、版本矩阵、测试结论、验收或发布组合形成。
+
+保留已授权范围内的阶段关键进展通知；同一处理轮或同一波次合并成一条，不逐个小任务刷屏。同轮发生阶段交接时合入交接总结，核对阶段过程记录避免重复。没有固定时间间隔。
+
+### blocked
+
+出现下列实际阻塞时立即发送：
+
+- 已有影响交付的实际阻塞，需要中心协调、有权真人决定或外部条件才能继续；
+- 关键路径等待有权决定；
+- 当前使用的交接渠道实际中断，且没有可用的已授权替代渠道完成必要交接；不把 Etunel 异常自动等同于整个项目阻塞。
+
+普通排队、正常等待、角色仍可自行推进或尚未完成产出不算阻塞。阻塞解除后用 `milestone` 汇报恢复，不修改历史消息。
+
+### complete
+
+项目生命周期中，阶段八满足必要条件、业务已确认结项且中心真人明确关闭后发送一次。开始结项整理不使用 `complete`。用户明确指定的独立整体目标最终完成时，限定在该目标范围表述，不能冒充项目关闭。模拟项目必须明确写“模拟完成”，不得表达真实发布、客户验收或生产就绪。
+
+### failed
+
+整个项目或整体目标已经最终终止、无法恢复或明确失败时发送。可返工的测试失败、单个任务失败或临时脚本异常不使用 `failed`。
+
+## 消息写法
+
+标题使用“项目名称｜阶段编号：阶段名称”，例如“示例项目｜阶段六：测试验证”。Hub 每次从有效项目记录取得当前阶段编号和名称，通过 `progress --stage` 整体传入；编号未登记时只写已知阶段名称，不自行编号或因通知示例改变阶段顺序。阶段变化后使用新名称，不把“阶段里程碑”等事件标签当成阶段，也不根据正文猜测阶段。提醒入口的自定义标题同样先写当前阶段，再写提醒事项。跨阶段事项在对应条目中注明所属阶段，通知标题仍写项目当前阶段。
+
+进度通知采用已确认的格式：加粗项目与阶段标题、自动汇报时间、“已确认的进展”“待办事项”“遗留”三个加粗栏目，栏目间留空行。每件事单独一条，用日常说法写清谁做什么。确实没有待办或遗留时写“无”；资料不足时说明尚未核实，不把未知写成没有。本轮没有新增已确认进展时如实说明。
+
+- 已确认的进展：写清完成了什么、谁已作出什么决定以及适用范围。区分“已进入阶段／开始整理”和“已完成／已关闭”；已通知交接不等于对方已经完成交接。已决定的事项直接说明结果，不再请人重复批准。
+- 待办事项：合并列出本轮需要决定、确认或处理的全部事项，用“事项名称：由谁做什么”逐条表述，例如资料整理、资料补充、旧事项停止、结果确认和本轮工作范围；按实际情况命名，不要求凑齐示例条目。标题已说明当前阶段，不必每条重复阶段名，涉及其他阶段时注明。需人工决定时写“条件具备后，由 Hub 请某负责人确认具体事项，确认后再执行后续动作”，条件只取已有约定；有可选方案时简短列明。需执行时写清已明确的处理人和动作，有已约定期限时沿用，必要时说明结果通过哪个已约定渠道返回。已明确停止的催办、需要复用的成果和不新增的工作须保留，不改写成新任务。
+- 遗留：逐条列出当前阶段及此前阶段尚未解决、需要继续跟进的事项，说明现状、已确认的后续安排及对应处理人；沿用原计划时间、当前计划时间、必须完成的阶段和影响范围，按本轮需要说明变更；跨阶段事项注明原所属阶段。列为遗留不等于获准延期、豁免、关闭问题或通过阶段；同一问题在待办里写本轮动作，在遗留里交代未解决状态，避免重复整段内容。
+- 待办和需跟进的遗留，在已明确真人处理人或决策人时，于对应条目中 @ 该人；Hub 代为请求确认时 @ 被请求确认的真人负责人，不把“Hub”或角色名称当成可查询姓名。纯 Agent 工作可直接写 Hub 或实际角色 Agent；真人姓名缺失时沿用已知角色，不猜测或编造 @ 对象，确需提醒再按项目分工与脚本用法取得已确认姓名。多人分工写清各自动作，同一人可在对应条目中重复出现，发送接收人去重。已完成且无需行动的进展不额外 @ 人。未确定的责任、期限或事实不编造，也不为填写通知重新要求分配或填表。
+- 用具体动作替代“收口”“闭环”“拉齐”等笼统表述。例如“处理方式已收口”可写成“负责人已确定处理方式”，但不得把处理方式确定写成问题已解决。原决定中的“暂不修复”“无需新增清单”等范围和限制必须保留。
+- 资料未说明交接或执行情况时，只写需要核实的事实及已有安排，不直接要求重新交付或执行；通用阶段职责不能直接变成本轮已派发的待办。补充事实不要求重做已经完成的工作。
+
+以下用结项整理场景演示已确认的通知格式，项目名与人员称呼均已泛化。示例中的验收结论、成果数量、确认人及延期安排只属于该场景，不成为其他项目的默认事实、职责或放行条件；各项目仍依据自己的有效记录和流程基线生成内容。
+
+```markdown
+**示例项目｜阶段八：复盘结项**
+
+项目进度自动汇报 · 发送时自动生成带时区的时间
+
+**已确认的进展**
+
+- 相关负责人已确认：产品验收材料已在线下完成，业务已确认客户验收通过。
+- 项目已进入资料归档与复盘结项阶段，目前开始整理结项资料，项目尚未关闭。
+- 已通知相关负责人进行阶段交接，不新增审批。
+
+**待办事项**
+
+- 结项资料整理：由中心真人负责人组织四类结项成果，Hub 协助整理工作稿。
+- 资料补充：由产品负责人、业务负责人补充现有线下成果及确认记录，不重做验收。
+- 旧事项停止：由 Hub 停止此前的验收准备催办。
+- Bug 事实确认：由 Hub 请 @示例中心负责人 先确认全部 Bug 的对象、版本和实际处理或承接，已有有效确认直接引用。
+- Bug 处理确认：中心确认事实后，由 Hub 请 @示例产品负责人 再次确认，并在职责内决定处理方式；双方无异议后记录最终安排。
+- 结项确认：四类成果、遗留承接及 Bug 双方确认具备后，由 Hub 请 @示例业务负责人 确认结项。
+- 关闭决定：业务确认结项后，由 Hub 请 @示例中心负责人 决定是否关闭；结项必需项完成后锁定四类成果。
+- 本轮工作范围：不新增应用修复、设备测试或发布验证。
+
+**遗留**
+
+- 原测试不通过的结果如实保留，不因进入结项阶段改为通过。
+- 已接受延期的问题如实保留，后续沿用 Bug 系统中的记录和已有处理安排继续跟进。
+```
+
+示例标题、时间和栏目只说明最终呈现方式；调用时正文文件仅含正文，项目名、阶段标题与时间由脚本生成，不重复粘贴整条通知。
+
+### 已关闭项目的结项总结示例
+
+以下仅说明格式。事实、决定人、日期、有效成果入口、后续主责和期限都须替换为项目真实记录，不把此例当成关闭依据。
+
+```markdown
+**示例项目｜阶段八：复盘结项**
+
+项目进度自动汇报 · 发送时自动生成带时区的时间
+
+**已确认的进展**
+
+- 四类结项成果已取得必要确认，有效文件和入口已登记在项目成果索引。
+- 全部 Bug 的处理或承接已由中心先确认、产品再次确认，双方无异议。
+- 业务已确认结项，中心真人已明确关闭项目；决定的日期、范围和条件已记录。
+- 已同步相关记录、锁定有效成果，停止已结束阶段的重复催办。
+
+**待办事项**
+
+- 遗留跟进：请 @示例处理人 按原问题记录中的当前计划继续处理已承接事项，原计划和变更历史保留。
+
+**遗留**
+
+- 已接受延期的 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,102 @@
+# 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 停止此前的验收准备催办。
+- Bug 事实确认：由 Hub 请 @{示例中心负责人} 先确认全部 Bug 的事实、对象、版本和实际处理或承接，已有有效确认直接引用。
+- Bug 处理确认：中心确认事实后，由 Hub 请 @{示例产品负责人} 再次确认并在职责内决定处理；双方无异议后登记最终安排。
+- 结项确认：四类成果、遗留承接及 Bug 双方确认具备后，由 Hub 请 @{示例业务负责人} 确认结项。
+- 关闭决定：业务确认结项后，由 Hub 请 @{示例中心负责人} 决定是否关闭；结项必需项完成后锁定四类成果。
+- 本轮工作范围：不新增应用修复、设备测试或发布验证。
+
+**遗留**
+
+- 原测试不通过的结果如实保留，不因进入结项阶段改为通过。
+- 已接受延期的问题如实保留，后续沿用 Bug 系统中的记录和已有处理安排继续跟进。" --at "示例业务负责人" --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` 和提及标记。查不到、重名或权限不足时停止，不让负责人手填编号，不删掉 @ 降级发送。
+- 默认且仅发配置的项目群。同一事项合成一条，事件通知可直接 @ 人，不额外重复提醒。提醒讨论结果通过已约定渠道返回并留档，不在群里另派任务或批准。
+
+## 阶段交接和关闭通知
+
+中心真人已批准推进或条件授权实际满足后，将上一阶段总结与下一阶段已确认安排合为一条 `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` 可完全离线预览，条目中的标记显示为“@姓名”；不查人、不验证目标或 @ 效果。
+
+- `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,16 @@
+# 模板复用
+
+仅在选择已有专业模板或历史样例时读取。中心维护的项目、阶段和任务模板见 [记录与留档](project-records.md)。
+
+项目计划的默认 Excel 模板及维护规则见 [项目计划](project-planning.md)。已有主表沿用已确认格式。结项报告和汇总按项目已确认格式制作，单工作表 Excel 仅作参考；不因模板字段齐全就补造工时、轮次、评审、签名或确认。
+
+- 从当前任务、有效流程基线、成果、平台／机型、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,45 @@
+# 异常与决定
+
+只处理影响交付、交接或有权真人决定的事项；角色内部如何解决由真人组织。把关键事实记入原任务或相关阶段过程记录，项目层显示当前需要处理的部分。
+
+## 延期与跨阶段未完成事项
+
+- 分条记录未完成内容、原因、主责真人、原计划完成时间、当前有效计划时间、影响范围、必须完成的阶段和下一步。
+- 改期由中心真人确认，并取得涉及资源、排期或业务承诺的必要授权；提议的日期先记“拟调整／待确认”，不能当作已生效。
+- 每次改期追加旧时间、新时间、原因、决定人、决定时间及依据；原计划不覆盖。分别说明是否超过原计划、是否超过当前计划，不能借改期抹掉原计划偏差。
+- 原任务一直保留在所属阶段。涉及的新阶段和项目层引用它，不能复制成第二项任务或因阶段切换清除未完成状态。
+- 每个阶段结束时提醒仍待交的延期成果，列责任、原计划、当前计划、影响及必须完成阶段，直至交付或真人明确处置。是否继续推进由中心真人决定。
+- 实际完成时间按 [成果与确认](artifacts-and-confirmation.md) 记录。取消、豁免或结项后的承接不冒充已完成；承接仍需跟进时保持项目层可见，最终处置后留历史引用。
+
+## 阻塞、退回与专业冲突
+
+说明受影响任务、事实和依据、缺失输入或决定、影响、建议下一步及期望时间。普通等待或仍可自行推进不标为阻塞。中心真人安排协调、补充或暂缓，只影响相关任务。
+
+提交不满足条件时列出具体缺口，保留有效成果；退回记录包含原版本、原因和补充要求。专业分歧由相关真人讨论；无法解决时呈现分歧与证据，由有权真人决定，中心 Agent 不替代专业结论。
+
+## 变更、豁免、跳转与放行
+
+- **改变基线**：记录《变更申请》所需的旧基线、拟变更内容、原因、范围、版本、成本／排期／质量影响及建议。可使用已有记录承载，按权限取得产品、业务或专业结论，记录生效范围及后续任务。
+- **必需成果不适用或豁免**：提供成果名称、适用依据、原因、事实、替代证据、影响及风险，由中心真人明确批准或拒绝。只处理对应成果要求，不替代测试确认、版本放行或外部验收。选填未交无需申请豁免。
+- **跳转、回退、暂缓**：记录原状态、目标阶段、缺失成果、原因、风险及补齐安排，取得中心真人决定及其他必要授权。暂停／取消等业务授权由业务负责，不能借阶段决定越权。
+- **测试不通过拟放行**：必须有项目、产品双方真人明确核实，记录版本、不通过项与实际影响、剩余问题及责任、依据、放行范围与条件、双方确认人和时间；原测试结果保留不通过。实质变化重新核实。
+
+未知影响不写“无影响”，未知责任或日期不编造；汇总为需要真人决定的具体问题。已有明确停止事项、暂不修复或无需新增清单等条件必须沿用，不借汇报重新分配。
+
+## Bug 处理与双方最终确认
+
+结项前对全部 Bug 的处理或承接核对双方确认，包含此前已处理及后续发现的问题。沿用原测试报告、Bug 系统或阶段七共用遗留记录，不要求测试再交独立清单。日常进展据实更新；以下是处理或承接结论的确认顺序，不把每次状态更新变成重复审批。
+
+1. 中心真人先确认问题事实、对象及版本、实际处理结果或承接安排。事实未确认前，不要求产品代为调查中心尚未核实的事实。
+2. 产品真人在上述事实基础上再次确认，并在自身权限内决定处理方式。产品调整处理方案时，中心协调受影响的安排，再补受影响部分的确认。
+3. 双方无异议后，在原记录登记最终结论、范围、条件与后续安排。已有适用于当前对象、版本和范围的有效确认直接引用，仅补缺失或变化部分。
+
+每项保留：
+
+- **问题**：已有 Bug 编号或名称、原记录入口、对象及版本。
+- **实际状态**：已修复、延期、暂不修复或其他真实状态；处理方式已确认不等于问题已修复。
+- **中心确认**：实际确认人、时间、事实与结论、范围、条件和来源。
+- **产品确认**：实际确认人、时间、再次确认及处理决定、权限范围、条件和来源。
+- **承接与分歧历史**：主责、下一步、原计划与当前计划、影响、必须完成阶段；保留每次调整、分歧及最终决定。
+
+双方无异议可以对应修复、延期或暂不修复，不代表全部已修复或测试通过；不因此重测已有有效验收结果。后续发现的问题依同一确认顺序处理，按原责任或新的明确授权跟进，不自动撤销既有关闭决定。

ep-hub/references/hub-workflow.md

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

ep-hub/references/project-lifecycle.md

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

ep-hub/references/project-planning.md

@@ -0,0 +1,36 @@
+# 工时、周期与项目计划
+
+阶段四组织评估、编排计划或后续更新执行情况时读取。中心真人统筹总排期和跨角色资源；角色真人决定本领域的执行方法。已有项目沿用已确认的唯一计划主表，新项目默认使用 [Excel 八列计划模板](../assets/templates/项目计划.xlsx)。Markdown 项目进度只维护摘要和主表入口。
+
+## 收集评估与衔接周期
+
+1. 评估前，向嵌入式应用层、嵌入式底层、硬件三方交接全部有效产品需求文件，列明版本和完整入口。各方分别说明本人范围、已有成果、剩余工作、尚不能估算的部分、可投入人员及外部等待。
+2. 初版单列，后续迭代轮数不包含初版；每轮内容和周期可以不同。研发开发、自测、修复与独立测试、回归分别记录，外部等待另列。
+3. 三方提交周期后，由技术负责人核实范围、遗漏与重复、先后和并行、合版以及软硬件依赖，再交测试衔接初版、各轮和回归周期及资源。测试可以先估自身工作量，不必等其他领域全部完成才开始评估。
+4. 产品只确认明确授权范围内的具体资源和排期对象，记录权限及范围；不默认产品对全部专业工作或工厂周期负责。预算、采购、对外承诺等仍按业务权限办理，不要求全员重批整份计划。
+
+评估沿原任务按工作项用表格记录，可嵌入 [工时与周期评估栏目](../assets/templates/工时与周期评估.md)。保留主责真人、原估／当前估及单位、周期及起算条件、投入和等待、提交与确认日期、来源和状态。变更保留前后值、原因及真人确认；未知写待确认，不能把工作日直接换成人日或小时。
+
+## 唯一计划主表
+
+固定八列：**里程碑、工作项、预排开始日期、预排结束日期、预排工时/人时、负责角色、参与人数、实际执行情况**。
+
+- 空白模板不预填日期、工时、人数、任务或迭代轮数。根据项目真实评估展开工作项；不同项目不套用同一套参考任务或周期。
+- 工时是任务合计人时，不再乘参与人数。人数不表示资源已落实；空白和 NA 不改成零。工作周期、工时、投入和外部等待分别记录。
+- 客户目标、内部预计、当前有效计划和实际执行分开；客户验收目标与量产目标分别保留。计划主表显示当前已确认计划，原计划及历次改期保留在原任务记录中并可追溯。
+- 预排日期不证明实际开始或完成；表格日期重叠不证明可并行、依赖已满足或已获跨阶段授权。
+- 主表按项目已有位置维护；新项目在阶段四任务过程中编制，确认有效后按正式成果规则登记。后续持续使用同一主表，不另建 Markdown 全量副本。
+
+## 更新实际执行情况
+
+中心根据真实回报更新同一工作项的“实际执行情况”，按需要分行记录：
+
+- 更新时间及事实来源。
+- 已完成部分、未完成部分与当前进展。
+- 真实开始和完成时间；任务实际完成仍取提交后真人明确确认完成的时间，工程实际发生时间另记。
+- 成果名称、版本和实际入口，已有确认人、时间及范围。
+- 偏差、影响、下一步，以及原任务记录入口。
+
+没有回报时写“待补充执行情况”，不能推定未开始或未完成。日常事实更新直接据实登记并保留来源、历史，不重批整表。修改已确认日期、工作范围或资源安排时，由对应有权真人确认后更新当前计划，原值和决定保留在原任务／变更记录中。
+
+已确认计划基线及历史版本仍按 [成果与确认](artifacts-and-confirmation.md) 保留。“实际执行情况”的后续更新应标明日期与来源，不把旧批准解释成对新发生事实的预先确认。

ep-hub/references/project-records.md

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

ep-hub/references/stage-reporting.md

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

etunel-role-collaboration/SKILL.md

@@ -1,85 +0,0 @@
----
-name: etunel-role-collaboration
-description: 在 Etunel 多 Agent 项目中识别项目Hub、业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件、测试或已登记的自定义角色，并按 Hub 唯一跨角色中介、依赖就绪任务波次、中文正式成果、真人负责人确认、阶段留档和 Etunel 实际消息工具推进项目。用于派发或完成任务、处理阻塞返工变更、阶段交接、项目文件归档以及 Hub 钉钉进度汇报；不用于设计 Etunel 队列、投递、重试或去重机制。
----
-
-# Etunel 多角色项目协作
-
-一个项目使用一个持续的项目Hub会话贯穿生命周期。默认角色为项目Hub、业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件和测试；已完成职责契约并由 Hub 真人负责人在 Etunel 中手动添加的自定义角色也可参与。
-
-## 先确认当前任务
-
-从当前 Hook、Etunel 角色契约和入站任务确认：
-
-- 当前角色、项目名称、项目模式、流程基线和所处阶段；
-- 任务目标、唯一主责角色、协作角色、上游依赖和完成时间；
-- 已有资料、本阶段完成约定、要求产出的文件或成果包、最低内容、证据、完成条件和下游用途。
-
-Etunel 负责当前角色和会话绑定。不要向负责人询问或复述 role ID、member ID、session ID、消息 ID 等运行时字段，也不要在任务正文中制造不存在的 ID。Hub 需要识别角色时调用 `mcp__etunel__etunel_list_roles`：用 `role` 路由，用 `display_name` 表示角色名称，用 `member_alias` 识别该角色当前实际负责人。`member_alias` 已由 Etunel 绑定确认，通知、称呼或成果确认不再额外索要人员 ID 或重复核对负责人身份。
-
-## 共享硬约束
-
-1. 项目Hub是成员 Agent 之间唯一的跨角色中介，任务、问题和结论经 Hub 定向路由。阶段 7 的测试报告及已提供的提测佐证由测试负责人直接交付产品负责人，产品向 Hub 确认接收；这不开放成员 Agent 直连，也不要求大文件经 Hub 转发。
-2. 正常阶段顺序为：业务需求、产品定义、方案设计、项目规划、软硬件实现、测试验证、平台/客户验收、复盘结项。阶段按有效流程基线和依赖推进。
-3. 每个阶段开始时，Hub 在该阶段记录中简要区分“本阶段必须完成、后续阶段处理、当前不需要”。只有直接影响本阶段成果或决定的问题可以阻塞；门禁满足并留档后立即启动下一阶段，由新阶段按需取得自己的输入。
-4. 依赖已满足的任务可以组成任务波次。一个 Etunel 调用只面向一个接收角色；同一角色的紧密相关工作可以组成一个任务包。
-5. 每项任务只有一个主责角色和一个可独立判断的结果。Etunel 的角色绑定决定实际接收会话，不另造“主责成员 ID”。
-6. Hub 必须给足执行所需的背景、有效输入、边界、产出和完成条件，但不默认广播完整计划、全部资料或私有对话。
-7. 正式执行任务必须形成指定文件或连贯成果包，任务要求与实际产出一致。纯信息查询、确认或决定不虚构空文件。
-8. 成员收到任务后先用简明中文与当前负责人对齐；形成成果后完成专业自审并取得负责人确认，再通过 Etunel 正式返回。
-9. 面向负责人、角色或钉钉的内容使用自然、简洁的中文。机器字段和枚举只留在工具参数或机器记录中，不把内部术语和 ID 倾倒给人。
-10. Hub 只校验角色、结构、版本、证据、确认状态、跨角色冲突、依赖和门禁，不替专业角色补写内容或作出专业结论。
-11. Hub 按阶段留档，维护项目进度、阶段记录和成果索引。阶段 6 测试大文件可用可访问索引关联，不要求 Hub 收转；对阶段 7 直接交付的测试资料，登记文件名、版本、保存位置、测试负责人确认、项目负责人确认引用和产品接收确认即可，不重复收存或转交大文件。必要资料未保存、版本不明或接收未确认时，不宣布交接完成。
-12. 流程可按 Hub 负责人明确决定跳转、回退或暂缓；Hub 必须记录缺失成果、原因、影响、风险和补齐安排，且不得把未满足门禁写成已通过。正式交付仍需补齐适用成果与必要确认；模拟流程不能冒充真实交付。
-13. Etunel 运行时负责队列、投递、重试、去重、会话授权和文件传输；本 Skill 不重复设计这些软件机制。
-14. 当前 Hook、工具 schema、角色契约、`etunel_list_roles` 返回和已确认流程基线高于本 Skill 的通用说明；不存在的工具、角色、字段或文件不得伪造。
-15. 所有成果豁免必须由项目负责人（项目Hub对应真人负责人）明确批准或拒绝；Hub AI 只校验、登记与执行，不自行批准；批准仅满足被豁免的文件要求，其他测试、验收和阶段门禁仍须满足。
-16. 产品确认授权范围内的资源与排期；预算、采购或对外承诺交业务批准。阶段 7 平台由产品确认、客户由业务确认，双线均通过才完成验收；阶段 8 只收集资料、复盘和结项，不安排冒烟测试或发布验证。
-
-17. 测试结果经测试负责人确认后交 Hub，仍须由 Hub 请求项目负责人（Hub 对应真人负责人）明确确认，才算完成提交；未确认、被退回或版本变更后未重新确认不得进入正式验收。零缺陷也须提交功能测试报告、零缺陷清单并走人工确认。工具完成或消息送达不能替代此条件；详见 [成果与完成判定](references/artifacts-and-evidence.md)。
-
-## 渐进式路由
-
-只读取当前工作需要的引用：
-
-- Hub：先读 [Hub 工作流](references/hub-workflow.md)。
-- 创建项目、读取角色、添加或替换角色、查询或纠正项目状态：读 [角色与项目状态](references/project-status-and-membership.md)。
-- 选择阶段、正式成果、任务波次、交接或结项改进跟进：读 [项目生命周期](references/project-lifecycle.md)。
-- 成员：先读 [成员通用工作流](references/member-workflow.md)，再只读当前角色文件：
-  - [业务](references/roles/business.md)
-  - [产品](references/roles/product.md)
-  - [技术负责人](references/roles/technical-lead.md)
-  - [嵌入式应用层](references/roles/embedded-application.md)
-  - [嵌入式底层](references/roles/embedded-lowlevel.md)
-  - [硬件](references/roles/hardware.md)
-  - [测试](references/roles/testing.md)
-- 准备派发、回复、跨角色中继、完成或报告阻塞：读 [Etunel 任务消息流程](references/etunel-message-lifecycle.md)。
-- 定义或校验成果、状态、版本、证据、额外产出或豁免：读 [成果与完成判定](references/artifacts-and-evidence.md)。
-- 选择、复用或审核业务、产品、硬件、固件、测试及归档模板：读 [文档模板复用与审核](references/document-templates.md)，再按实际任务定位原件；模板不自行改变职责、正式成果或门禁。
-- 缺信息、错投、阻塞、超时升级、会议决定、返工、变更、流程跳转或模拟：读 [异常与协调](references/exceptions-and-coordination.md)。
-- 编写给负责人、角色或群组的任务、提问、结果和状态消息：读 [人类可读沟通](references/human-readable-communication.md)。
-- 创建项目资料目录、保存成员清单、归档成果、更新进度或阶段记录：读 [项目文件与进度留档](references/project-files-and-progress.md)。
-- 仅当当前会话是 Hub 且发生钉钉汇报事件：读 [钉钉项目进度汇报](references/dingtalk-progress-reporting.md)。
-- 测试角色仅在任务类型匹配时，按 [测试职责](references/roles/testing.md) 中的二级链接读取更深细则。
-
-不要为“全面了解”一次加载全部引用或全部角色文件。Etunel Hook 源文件独立配置，不属于本 Skill 的渐进式发现树。
-
-## 每项任务的控制循环
-
-1. 从运行时确认当前角色、项目、阶段、本阶段完成约定、目标、输入、产出和负责人，不向人核对内部 ID。
-2. 用简明中文一次说明要做什么、已有资料、还缺什么、会产出什么以及需要负责人确认什么。
-3. 信息足够后执行本角色工作；缺少跨角色输入时先问当前负责人，再向 Hub 提交一组聚合问题。
-4. 形成指定文件或成果包，完成专业自审并取得负责人确认。
-5. 使用当前 Etunel schema 对应的工具返回成果、补充请求或具体阻塞。
-6. Hub 校验并按阶段留档；合格则更新成果索引、项目进度、依赖和下一波次，不合格则只说明具体缺口。
-
-## 提交前检查
-
-- 是否只确认了人需要知道的任务信息，没有要求负责人核对运行时 ID？
-- 是否只有一个主责角色，且未越过其他角色的专业或批准边界？
-- 输入是否足够，产出文件、证据、期限和完成条件是否与任务一致？
-- 自审、版本、负责人确认、开放项和风险是否明确？
-- 人类可读内容是否使用简洁中文，机器字段是否留在工具或机器记录中？
-- 必要成果是否已由 Hub 放入正确阶段目录并更新进度和成果索引？
-- 是否把任务波次误当成无依赖广播，或把排队、通知接受误当成业务完成？
-- 是否只使用当前 schema 中与本次意图匹配的 Etunel 工具？

etunel-role-collaboration/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Etunel 多角色协作"
-  short_description: "约束 Hub 中介、中文沟通、阶段成果与项目留档"
-  default_prompt: "使用 $etunel-role-collaboration 确认我的当前角色，只读取本任务需要的流程和职责规则，并通过 Hub 中介完成任务与阶段留档。"

etunel-role-collaboration/references/artifacts-and-evidence.md

@@ -1,150 +0,0 @@
-# 成果与完成判定
-
-Hub 定义任务产出、成员提交结果、判断状态或校验门禁时读取。具体职责和上下游见 [项目生命周期](project-lifecycle.md) 与当前角色契约。
-
-## 正式成果集合
-
-人工可读的正式成果统一使用以下中文名称：
-
-| 阶段 | 正式成果 |
-|---|---|
-| 1 业务需求 | 项目背景说明；客户里程碑要求 |
-| 2 产品定义 | 立项资料（含平台 SDK、个参资料）；测试验收标准；里程碑要求；项目风险 |
-| 3 方案设计 | 测试计划；总体技术方案（选填） |
-| 4 项目规划 | 项目计划；角色分工；项目状态内部记录 |
-| 5 软硬件实现 | 硬件设计包；嵌入式底层实现资料；嵌入式应用层固件包 |
-| 6 测试验证 | 功能测试报告；缺陷清单；可靠性测试报告（选填）；专项测试报告（选填）；提测佐证（选填） |
-| 7 平台/客户验收 | 平台验收报告或结论；客户验收通过报告；遗留问题清单 |
-| 8 复盘结项 | 结项资料归档；变更记录；结项报告；流程闭环总结（项目复盘） |
-
-不单列软硬件接口契约、架构决策记录、硬件实现资料、产品资料整合、测试证据包或缺陷分析报告。项目风险由产品在阶段 2 汇总并维护，相关专业角色提供风险意见，后续阶段引用而非重复创建。必要接口确认、技术决定、实施或调试事实留在已有过程记录及实际成果中，不通过改名重新增加独立交付物。具体内容和责任见 [项目生命周期](project-lifecycle.md) 及对应角色职责。
-
-选填成果和选填栏目未提交不阻塞阶段推进，无需另行豁免；已提交时仍需版本登记和相关负责人确认。阶段 3 的硬件器件、PCB、电源/信号/热及接口约束为选填；阶段 5 硬件输入及设计包仍按本阶段要求交付。WiFi 设备定频测试固件亦为选填，仅用于专项测试。已批准的必测范围仍需执行，文件选填不能用来掩盖未验证结论。只有仍属必需的成果需要不适用/豁免时，才走后述豁免流程。
-
-角色额外材料不能替代必需正式成果，也不能自动成为门禁。功能测试报告写测试结论（通过/不通过）、用例执行结果和 bug log；无法形成结论时说明阻塞，不伪造通过。缺陷由测试维护在《缺陷清单》中，责任人由实际相关负责人共同确认。
-
-## 测试选填材料的提交决定
-
-《可靠性测试报告》《专项测试报告》《提测佐证》保持选填，由项目负责人（项目Hub对应真人负责人）确认是否提交，Hub 登记决定和适用范围并同步测试、产品；已有仍有效的决定直接沿用，不为每个任务重复询问。未确认时只标明提交选择待确认，不由 AI 默认为必交或擅自批准不交，不新增阶段门禁或独立审批文件。
-
-决定不提交时，不因缺少这三类文件阻塞推进或要求另行豁免；决定提交时按约定交付并核对实际版本、负责人确认与接收状态，不把尚未提供写成已收。此规则只针对这三类测试成果，不扩大为所有选填栏目均须审批。
-
-平台模板中的“必填截图”“提交长稳报告”等文字，不自动升级为内部通用提交门禁；测试说明实际平台要求及影响，经 Hub 取得上述真人决定。决定是否提交材料不等于平台已接受、验收已通过，也不能免除已批准的必测范围或必要质量依据。正式测试结果仍走下文的项目负责人确认。
-
-## 先定义产出要求
-
-正式执行任务的产出和完成条件只来自“本阶段必须完成”的内容。后续阶段处理和当前不需要的内容可以登记，但不能自动成为当前成果、任务完成条件或门禁。“本阶段完成约定”不能替代正式成果的适用性判断、受控跳转或《成果豁免申请》。派发时明确：
-
-1. 正式成果或成果包名称及唯一主责角色；
-2. 每项最低内容、适用子项和协作边界；
-3. 输入基线、版本、旧版替代关系和可追踪引用；
-4. 所需证据及未执行验证应如何说明；
-5. 下游用途、期限和可以检查的完成条件；
-6. 本角色必须给出的专业结论；
-7. 专业自审和负责人确认要求。
-
-任务要求和实际产出必须一一对应。纯信息、澄清和批准决定不为形式创建空文件，但答复仍需来源清楚、经有权角色确认且结论明确。
-
-## 正式结果最低内容
-
-不强制所有角色填写复杂 JSON，但正式结果必须让 Hub 找到：
-
-- 当前阶段和使用的输入基线；
-- 实际完成内容和期限状态；
-- 成果中文名称、文件位置或附件、版本和旧版替代关系；
-- 每项完成条件对应的证据；
-- 不适用项、未执行项、开放问题、依赖和剩余风险；
-- 本角色明确结论：满足、部分满足或无法满足；
-- 专业自审结果；
-- 负责人、确认时间、确认范围和附带条件。
-
-一句“已完成”“没问题”或“测试通过”不能关闭任务。运行时消息标识由 Etunel 工具关联，不进入成果正文。
-
-## 状态分层
-
-以下层级彼此独立：
-
-1. 项目运行模式；
-2. 任务执行结果；
-3. 成果生命周期；
-4. 成果适用性；
-5. 阶段与门禁；
-6. 测试结论（通过/不通过；无法判定时单独说明阻塞状态）；
-7. 业务验收结论；
-8. Etunel 消息或钉钉通知状态。
-
-任务成功不等于成果已经成为基线；成果存在不等于门禁满足；测试通过不等于业务验收；消息已处理或钉钉已接受不等于项目完成。机器记录可以保留运行时枚举，但面向负责人时使用中文解释。
-
-## 任务包与多任务
-
-- 同一角色、同一基线、紧密相关且共同交付的成果可以组成一个任务包；全部必需产出满足才算完成。
-- 能独立验收、失败或服务不同依赖的工作保持独立任务，即使在同一波次发送。
-- 包内有效成果保留，未完成部分可以拆成后续任务；一个子项失败不能被其他成功掩盖。
-
-## 专业自审和人类确认
-
-自审结果说明角色如何按任务要求检查产出，可以是“通过”“部分通过”或“未通过”，并列出依据与例外。
-
-负责人确认表示当前负责人实际查看本次结果并确认可以作为该角色正式提交。Hub 以 `etunel_list_roles` 返回的 `member_alias` 作为该角色实际负责人身份，不再要求额外人员 ID 或二次身份核对；该负责人可在当前角色会话或钉钉中明确确认。至少记录确认人、时间、文件或版本、范围和附带条件。通知送达、已读或仅被 @ 不构成批准。AI 不得自行声称已获确认；模拟项目只确认模拟材料的使用和流程推进，不证明模拟值真实。
-
-负责人确认随对应文件、版本、适用范围和附带条件继续有效。Hub 归档、移动或引用同一成果不需要重新确认；只有内容或版本发生实质变化、当前用途超出原确认范围、负责人发生变化、确认证据缺失，或出现与原结论冲突的新事实时，才重新确认。另一角色对该成果作新的专业评估时，仍须取得该角色自己的负责人确认。
-
-## 测试结果的项目负责人确认
-
-测试专业结论、测试结果提交完成、正式验收准入是三个不同判断。测试负责人确认专业结果后，还必须由 Hub 请求项目负责人（项目 Hub 对应的真人负责人）实际确认；此人不是新增 Agent 角色，不能由 Hub AI、测试 AI 或通知状态代替。
-
-1. 测试执行完成，阻断缺陷清零、必需成果与测试依据齐全、剩余风险有接受方，并完成专业自审及测试负责人确认后，向 Hub 返回功能测试报告、缺陷清单及已提供的选填成果信息（F6.10），标记“待项目负责人确认”，不宣称正式提交完成。大文件保留可查索引，不因人工确认而增加整包上传要求。
-2. Hub 核对当前版本、必需成果、质量结论和剩余风险，再请求自己的真人负责人确认（F6.11）。记录真实的确认或退回意见（F6.12），包括确认人、时间、成果与被测版本、范围、附带条件和可查依据，并向测试同步登记结果及后续动作。
-3. 明确确认且完成登记后，才算该版本测试结果提交完成；仍须满足测试质量门禁，才能进入正式平台/客户验收。人工确认不能将不通过改成通过，不能取消必测范围、缺陷复验或双线验收。
-4. 未回复、仅送达、已读、测试负责人单方确认、工具显示任务完成或协调消息结算，都不算此人工确认。Hub 保持“待项目负责人确认”，不伪造已批准；这不是 Etunel 的新机器枚举。
-5. 被退回时，测试补充材料，必要时回到相关修复、合版与独立复验，再重新提交确认。测试结果或被测版本实质变化必须重新经过 F6.10–F6.12；旧确认不能覆盖新版本。相同版本、范围与条件的有效确认可追踪复用，不为索引移动或排版重复审批。
-6. 测试已完成且无缺陷时，从 F6.2 直接到 F6.10，再经过 F6.11–F6.12；仍提交功能测试报告和零缺陷清单，不创建无必要的修复任务。无缺陷不等于未执行必测项也可跳过。
-7. 在最终确认前，可以依据真实的阶段性结果协调缺陷与修复，但不得据此宣布最终提交完成或正式进入验收。工具使用和技术任务结算见 [Etunel 任务消息流程](etunel-message-lifecycle.md)。
-
-## 不适用、延期与成果豁免
-
-- 不适用内容写“不适用”，机器记录可以使用 `NA`，并说明条件和依据。
-- 不适用不能表示时间不足、环境缺失、尚未执行、失败或阻塞。
-- 延期和正式豁免都不等于不适用。
-- 适用内容缺失不能靠空文件或虚假“通过”穿过门禁。
-
-《成果豁免申请》由成果主责角色提出，写明成果名称、阶段、不适用原因、事实证据、替代方案、下游影响、风险及负责人确认。流程为：
-
-1. Hub 校验发起资格、资料结构和可豁免性，缺口退回补正，不自行作最终批准或拒绝。
-2. 项目负责人（项目Hub对应的真人负责人）依据申请、证据、替代方案和影响，明确批准或拒绝。所有成果豁免均须此人工决定，不能以低影响、沉默、形式校验或 AI 推断代替。
-3. Hub 登记决定人、时间、范围、基线、附加条件和失效条件；批准后分发豁免记录，拒绝或未获确认时仍需该成果。
-4. 不再设置独立的下游征询、意见回传或业务高影响确认环节；必要的事实和影响写在申请中，缺少时补正，不凭空补造意见。
-5. 决定只适用于当前项目、阶段和基线。不可豁免要求不能借本流程绕过；批准仅满足被豁免的文件要求，其他测试、验收和阶段门禁仍须满足，不能替代测试结果的项目负责人确认。保留原必需项和豁免记录，不删除要求；项目范围或输入基线变化时，旧豁免失效并重新评估。附加条件未满足时仍需该成果，Hub 向主责角色明确补交内容、证据和期限，相关阶段保持阻塞。
-
-
-## 额外产出
-
-角色可以提交职责内有价值的额外文件，说明它与原任务的关系、对完成结论的影响、下游用途以及新增依赖、风险和维护责任。
-
-Hub 可以将其作为支持材料保存。额外文件不会自动成为正式成果、增加当前完成条件、制造新阻塞或激活下游依赖。若确实需要改变范围、接口、角色责任、基线、排期、正式成果或验收，先由有权负责人批准并走《变更申请》，不能静默生效。
-
-## 事实、判断和证据
-
-结果应区分：已确认事实、原始证据、本角色专业判断、未验证假设、已批准决定、开放问题、外部依赖、剩余风险、客户期望、内部目标和正式承诺。模拟数据必须清楚标明，不能混入真实结果。
-
-研发自测不能替代测试独立结论；测试不能替代产品或业务验收。无法执行的检查说明原因、影响和恢复条件。
-
-## 版本、留档与可追踪性
-
-代码、固件、硬件、配置、设计、计划或报告给出足以识别对象的版本或引用，并说明上游输入、产生或验证版本、被替代旧版本、与接口、板卡、BOM、ECO、构建或环境的匹配关系和下游约束。
-
-文档类正式成果只有在范围、行为、验收、接口、专业决定或下游行动发生实质变化时，才创建新版本并按需要重新确认。只更新任务状态、转交说明或排版，生成内容相同的重复副本，或补充不改变结论的过程说明，不升正式版本；有复盘价值时写入阶段记录。不得为排版或状态更新覆盖已经接受的文件。代码、固件、硬件、配置和构建物继续遵循本领域版本规则，实际对象或构建发生变化时必须能区分版本。
-
-新结果不能静默覆盖旧基线。Hub 按 [项目文件与进度留档](project-files-and-progress.md) 保存文件、更新成果索引和阶段记录；正式变更保留旧版本、新版本和生效范围。成果索引为每项成果明确一个当前有效版本，下游默认只接收该版本；历史版本和过程材料不参与当前完成判断，除非被明确恢复为有效版本。
-
-## Hub 校验边界
-
-Hub 检查文件存在、最低结构、来源角色、版本、证据引用、自审、负责人确认、冲突、依赖、状态层、留档和门禁；不替专业角色判断内容是否充分。专业冲突定向交拥有决定权的角色。
-
-阶段 6 测试大文件按可访问索引校验并保留确认记录，不要求 Hub 收存原文件；阶段 7 按下述产品直交收讫规则处理。除此之外，成果只有在 Hub 实际收到并能访问文件、确认来源角色正确、核对任务与输入基线、检查必要版本、证据、自审和负责人确认、完成阶段归档和成果索引更新，并明确作出“接受”结论后，才成为当前有效成果。成员说明已完成、附件刚送达或消息状态变化都不能单独替代接受。
-
-成果已经接受后，后续 Etunel 任务记录异常不撤销该成果，也不要求角色重复制作或重复提交；Hub 单独记录并说明运行时异常。文件未按适用交付方式收到、不可访问或未经校验时，不能用任务或消息状态推进项目。本 Skill 不处理 Etunel 的队列、重试或去重逻辑。
-
-阶段 7 正式验收前须已完成上述项目负责人确认及测试质量门禁。测试报告及已提供的提测佐证按已确认的负责人直接交付路径处理：测试保管原文件，产品确认接收，Hub 登记文件名、版本、保存位置、测试负责人确认、项目负责人确认引用和产品接收确认，不要求大文件上传或转发。此前关于 Hub 实际收件、附件及本地归档的通用要求不强制适用于这条交付路径；必须能追踪实际文件与接收状态，不能只凭消息已处理宣布交接完成。
-
-向下游只传递任务需要的已登记成果、版本、约束、风险和证据引用，不复制完整聊天或全部资料。

etunel-role-collaboration/references/dingtalk-progress-reporting.md

@@ -1,76 +0,0 @@
-# Hub 钉钉项目进度汇报
-
-仅当当前会话是 Hub 且发生本文件定义的汇报事件时读取。钉钉是面向项目群组的单向辅助可见性与异常提醒，不是任务派发、跨角色沟通、审批、门禁、人类确认或项目记录的事实源。
-
-## 权限与唯一入口
-
-- 只有 Hub／主 Agent 可以发送；成员 Agent 只把成果、状态或阻塞交给 Hub。
-- 项目配置为启用时视为持续发送授权，不需每条消息再次询问。
-- 只能调用项目封装入口：
-
-  `./scripts/dingtalk-progress <start|milestone|blocked|complete|failed> "<中文 Markdown 摘要>"`
-
-- Agent 不得直接调用底层 OpenAPI、`dws api` 或其他消息入口绕过封装脚本。
-- Agent 不读取、修改、输出或请求 Client Secret、DING_SEC、App Token、Client ID、robotCode、openConversationId 等凭据和内部标识。
-- Skill 与消息正文不得硬编码项目 Client ID、robotCode、openConversationId、Client Secret 或群名；项目差异只由 `.dingtalk/config.env` 和封装脚本处理。
-
-## 汇报单位与顺序
-
-汇报以整个项目生命周期为单位。Hub 合并同一阶段或任务波次的相关结果，不为每条队列消息、普通回复、单个小步骤或短小只读问答发送通知。
-
-Hub 必须先确认进展真实有效，并完成成果文件、成果索引和项目进度留档，再发送钉钉消息。钉钉发送失败不回滚留档，也不阻塞 Etunel 主任务。
-
-## 事件判定
-
-### start
-
-每个项目最多一次。在第一个真实可执行任务或任务波次已经通过 Etunel 实际派发后发送。仅建立计划、等待输入或讨论想法时不发送。
-
-### milestone
-
-在可验证、会改变下一步的实质进展完成并已留档时发送，例如：
-
-- 关键成果或版本成为当前有效版本；
-- 一个有意义的任务波次完成并触发角色或阶段交接；
-- 门禁、受控跳转、回退或豁免完成真实记录和必要确认；
-- 正式阻塞解除，项目恢复到明确下一动作；
-- 统一固件、版本矩阵、测试结论、验收或发布组合形成。
-
-同一处理轮或同一波次合并成一条，不逐个小任务刷屏。没有固定时间间隔；依靠事件语义和去重控制频率。
-
-### blocked
-
-出现下列实际阻塞时立即发送：
-
-- 角色已经询问负责人并完成必要线下协调，仍需用户、Hub 负责人或外部条件才能继续；
-- 关键路径等待有权决定；
-- Etunel 的任务投递、成员返回、会话或消息链路实际中断。
-
-普通排队、正常等待、角色仍可自行推进或尚未完成产出不算阻塞。阻塞解除后用 `milestone` 汇报恢复，不修改历史消息。
-
-### complete
-
-整个项目或用户明确指定的整体目标最终完成时发送一次。模拟项目必须明确写“模拟完成”，不得表达真实发布、客户验收或生产就绪。
-
-### failed
-
-整个项目或整体目标已经最终终止、无法恢复或明确失败时发送。可返工的测试失败、单个任务失败或临时脚本异常不使用 `failed`。
-
-## 消息写法
-
-使用中文 Markdown 自然排版，可以使用标题、短段落和列表，不要求固定模板，也不要把全部内容挤成一行。像项目负责人向团队说明进展，不像日志转储。
-
-根据事件选择必要内容：项目名称、当前阶段、已验证进展、关键成果、下一步和责任角色；阻塞时再说明问题、影响以及需要谁采取什么动作。通常保持一屏内可读。
-
-不在正文中写运行时 ID、英文成果名、机器状态码或内部字段。只写已验证结论，不得包含密钥、Token、个人数据、客户敏感信息、大段日志、完整内部对话或未经验证的根因推断。
-
-## 调用与结果
-
-1. Hub 判断事件并形成中文 Markdown 摘要。
-2. 调用封装脚本一次；脚本自行处理配置检查、发送和有限重试。
-3. 只有真实发送响应包含非空 `processQueryKey`，才表示钉钉服务端已经接受；不证明群成员已读。
-4. 缺少或未启用配置时安全跳过；预览模式只检查请求，不视为真实发送。
-5. 真实发送失败或没有有效 key 时，脚本最多总计尝试 3 次，间隔 10 秒；首次成功立即停止。
-6. 三次仍失败只终止本次钉钉发送，Etunel 主任务继续。Hub 在本地结果中向负责人说明一次，不递归发送新的阻塞或失败通知，也不自动补发历史事件。
-
-脚本输出和退出码只用于判断通知调用，不得把钉钉结果升级成项目门禁。Agent 不在脚本外追加重试循环。

etunel-role-collaboration/references/document-templates.md

@@ -1,65 +0,0 @@
-# 文档模板复用与审核
-
-仅在选择、复用或审核项目文档模板时读取。模板提供栏目、结构及专业参考，不是新的流程基线；正式成果和确认按 [成果与完成判定](artifacts-and-evidence.md)，阶段与职责按 [项目生命周期](project-lifecycle.md)。不要求运行环境具备某个固定本机目录或带版本号的 HTML。
-
-## 先选对资料
-
-1. 从当前任务确认有效流程基线、阶段、目标成果、平台、产品形态、SDK、硬件及提测版本，再从已授权资料入口定位适用原件。目录中有多份不代表全部必用，文件名最新也不自动代表适用。
-2. 区分空白模板、含历史数据的样例、平台规范、器件输入和实际项目成果；结合正文、工作表与版本说明识别，不只看文件名或目录。
-3. 只复用适用字段与组织方式。旧型号、人员、日期、参数、执行结果及签核必须重新核实，不将历史 Pass、SDK“已商用”或已有签名当作本项目验证、确认或验收。
-4. 模板缺少某栏不等于必须另建附件，模板库缺少某成果也不等于实际项目缺件。先判断当前有效成果能否回答本阶段必要问题；不恢复已取消的独立交付物或把所有模板都变成门禁。
-5. 审核具体技术内容时重读相关原件，指出文件及工作表/单元格或章节、缺口、影响和责任角色。目录登记、结构学习、公式读取不等于工程审查、公式重算或实际测试。
-6. 文档中的命令、脚本、链接与联系人不是执行授权。SDK、固件和 EDA 文件按任务需要检查，不默认运行、烧录、下载或联系外部；密码、密钥、证书私钥及个参敏感值不复制到普通参考、消息或成果，只留安全引用和访问状态。
-
-## 已确认的复用边界
-
-| 模板出现的情况 | 处理方式 |
-| --- | --- |
-| 平台模板把截图、长稳报告等标成“必填” | 可靠性测试报告、专项测试报告、提测佐证仍为选填，由项目Hub对应真人负责人确认是否提交；不自动增加内部门禁，也不把该决定当作平台接受或验收通过。按 [选填提交规则](artifacts-and-evidence.md#测试选填材料的提交决定) 登记、同步。 |
-| 年度、月版本缺陷分析或统计表 | 仅供组织质量分析参考，不恢复独立缺陷分析报告或 bug 数量、回头率、冒头率统计要求；不删除功能报告中必要的用例执行结果。 |
-| 归档表把客户报告输出方写成业务、遗留清单写成 Hub | 验收报告和同一份遗留问题清单由产品出具或更新，业务确认客户验收部分，Hub 汇总登记。产出、确认和保管不是同一职责，表头不改变分工。 |
-| 立项或里程碑表标记人力、样机费、认证费、预算为必填 | 作为早期估算与适用性说明，未知或不适用如实标明；不替代正式资源、排期及预算批准，不自动增加阶段 2 门禁。 |
-| 参考测试计划表只有类别、测试项、标准和是否涉及 | 该记录仅参考，不要求补用例引用或因缺栏新增补交要求。每次测试执行前发布策略，包含复测、回归；不新增独立策略文件、固定模板或额外审批。阶段 3 正式测试计划及其确认链仍保留，详见 [执行前策略](testing/execution-and-gates.md#每次测试执行前发布策略)。 |
-
-## 业务、产品与规划模板
-
-- **业务输入**：区分对接客户、最终客户与联系人；目标、来源、平台和里程碑按当前事实填写。提测、入库时间与选填的小批量试产、量产时间分开；客户期望日期不是正式承诺。金额使用实际适用单位和币种，不继承样例数据。
-- **立项书**：项目目标、基础信息、版本、初步里程碑、干系人、资源估算、任务及风险栏目按阶段使用；完整模板能容纳后续信息，不代表阶段 2 要一次完成全部规划和批准。
-- **规格与功能清单**：区分参数、描述及适用型号；“支持”“不支持”“预留”“待确认”不是同义词。SDK 支持、平台/客户端支持、设备实现状态、实际测试结果分别核对，不能以其中一列替代其他结论。
-- **灯态与语音**：按上电、配网、升级、断网等实际设备状态检查指示灯及语音。灯态采用“配网”不意味着将账号绑定、解绑等业务功能全局改名；样表某列选填不自动改变整个成果属性，未出现语音栏也不表示项目无需澄清适用语音行为。
-- **产测功能**：参考分类、功能描述、测试内容、实现/支持状态及备注，区分设备、产测工具、客户端和 MES 边界。行号或公式生成编号不能未经确认作为稳定用例标识。
-- **SDK 与个参**：核对来源、版本、适用产品及授权访问状态；容器存在不等于内容可用，样例参数不替代实际安全配置。
-- **风险与里程碑**：按正文识别文档用途；技术、时间及其他风险由产品维护、专业角色确认，不因模板放在规划目录就改变阶段 2 的风险归属。
-- **项目工时表**：工作项、人力、工时用于估算；先核对单位和适用范围。简单工时表不能单独证明正式排期、依赖、角色分工、产品资源确认或业务预算批准已经完成。
-
-## 硬件与固件模板
-
-- **硬件前置输入**：取得实际外设、关键器件的适用规格书及结构板框图，确认主要器件位置和禁止限制区域。器件简版说明、PCB 布局或单个器件机械图不能直接代替完整适用规格或结构板框要求；不要求使用样例中的全部器件型号。
-- **硬件设计包**：按原理图、PCB 源文档、贴片资料、接口定义四类审核。贴片资料包含 PCBA_BOM、器件位置图 PDF、贴片坐标；核对 BOM 数量/位号/封装、坐标的层/方向/位置及接口引脚功能，并检查是否对应同一设计版本。不另设《硬件实现资料》输出。
-- **底层成果**：静态电气测试表可提供硬件功能测试依据，但不自动覆盖完整《硬件功能测试报告》、BSP 输出路径和 PSP 输出路径。WiFi 定频固件选填且为专项工具，不当作统一提测固件。
-- **应用固件包**：升级自测所需高低版本可以并存；明确用途及唯一最终目标版本，不能仅因两个版本文件就判为多出口，也不能把历史低版本误交为最终固件。
-- **配套与校验**：分区文件、烧写镜像、构建配置按真实用途对应，不能凭扩展名猜测。MD5 文件存在不等于完成校验，旧自测结果不等于本次通过。样例缺少 zn_debug 文件、证书或其他约定项，不自动删除流程要求；发现异常公式、断链或版本不明时只核验受影响内容，不猜测修复值。
-
-## 测试模板选择与结果复用
-
-按实际平台及当前要求选择用例家族，不把下面示例当成永久平台标准或通用必测组合：
-
-| 家族 | 选择与核对重点 |
-| --- | --- |
-| 杭研类平台用例 | 提测时间对应的有效版本；Android/Harmony、IPv6、H264/H265 等适用列分别判断。 |
-| 电信类平台用例 | SDK、室内/室外、云台/非云台、双摄等产品差异；不只按文件体积或日期选择。 |
-| 联通类平台用例 | 平台、安全、码率等实际范围；内部版本是否包含指定客户用例应按项目选择。 |
-| 内部功能用例 | 含或不含特定客户需求的版本按来源选择，不无差别合并重复库。 |
-| 可靠性、专项与兼容性 | 温度、跌落、防护、功耗、WiFi/路由器及 SD 卡等按适用范围选择；样例阈值、数量、周期不自动成为新项目要求。 |
-
-实际使用时核对用例标识与来源、模块、前置条件、步骤、期望、实际结果、执行人、日期及缺陷关联；这是理解和记录当前测试所需的信息，不要求每张参考表增加同名列或单独引用附件。旧结果必须重新执行验证，未执行、阻塞、不适用和不通过不得混淆。
-
-发现标准页、温升指导或其他引用不存在、名称不一致时，先确认有效技术依据，不自行补造阈值。平台材料是否提交遵循前述真人决定；已批准的测试范围及独立质量结论仍按 [测试执行与质量门禁](testing/execution-and-gates.md) 处理。
-
-## 归档复用
-
-归档清单可参考阶段、文档名称/编号、输出方、归档状态和备注等栏目。统一使用当前有效成果名称和实际责任，旧编号重复、历史变更记录或旧版成果名称不能直接作为新项目事实。
-
-Hub 汇总有效版本、确认与可访问索引，不把归档清单中的每一行都变成强制补交任务；三类选填测试材料沿用真人提交决定。测试大文件按真人直交和产品收讫规则处理。原件未在模板库出现，不代表实际成果免交；模板库尚无独立阶段 7 或底层模板，也不表示实际项目缺件或不通过。
-
-阶段 8 只归档、复盘和结项，不因为模板包含自测、统计或验证栏目重新执行测试。具体留档和交接见 [项目文件与进度留档](project-files-and-progress.md)。

etunel-role-collaboration/references/etunel-message-lifecycle.md

@@ -1,114 +0,0 @@
-# Etunel 任务消息流程
-
-准备派发、补充、跨角色中继、返回、完成、阻塞或结算 Hub 入站消息时读取。当前 Hook 和 MCP schema 是工具名、参数与授权的最终依据；本文只约束职责和消息意图。
-
-## 真实工具边界
-
-Etunel 是严格的 Hub 星型拓扑：成员只能向 Hub 发送，只有 Hub 可以向角色发送。
-
-| 意图 | 调用者 | 工具 |
-|---|---|---|
-| 读取实际角色 | Hub | `mcp__etunel__etunel_list_roles` |
-| 向一个角色发送任务、回复或状态 | Hub | `mcp__etunel__etunel_send_to_role` |
-| 结算无需回复的成员协调消息 | Hub | `mcp__etunel__etunel_complete_coordination` |
-| 成员向 Hub 补充或提问 | 成员 | `mcp__etunel__etunel_send_to_hub` |
-| 成员完成任务并交付成果 | 成员 | `mcp__etunel__etunel_complete_task` |
-| 成员以具体阻塞结束任务 | 成员 | `mcp__etunel__etunel_report_blocked` |
-| 读取必要附件或旧式消息 | 当前绑定会话 | `mcp__etunel__etunel_receive_message` |
-
-工具未暴露、名称或参数改变时，以当前 schema 为准并报告能力缺口；不得猜参数或请求内部认证字段。
-
-## 机器字段不进入人类正文
-
-- Hub 用 `role` 路由，面向人使用 `display_name`。
-- `message_id` 是 Etunel 消息标识；需要完成、阻塞或结算时从入站消息取值。
-- `correlation_id` 只用于把回复或状态关联到来源消息。
-- 这些字段只进入工具参数。任务正文、负责人对话、成果标题和钉钉消息不要求抄写或确认。
-- Etunel schema 没有 member ID；Skill 不得创造 member、session 或任务 ID 字段。
-
-## 任务波次如何发送
-
-`mcp__etunel__etunel_send_to_role` 一次调用只发送一个接收角色和一条消息：
-
-- 同一角色的多个独立任务可以连续发送，由 Etunel 队列处理；
-- 同一角色紧密相关且共同交付的内容可以合并为任务包；
-- 不同角色的依赖就绪任务分别发送、独立返回；
-- 排队不代表业务并行完成，也不代表下游依赖已经满足。
-
-Hub 不实现队列、确认包、锁、重试、去重或文件传输；这些由 Etunel 软件承担。
-
-## Hub 发送任务
-
-Hub 调用 `mcp__etunel__etunel_send_to_role` 时：
-
-- `role` 使用 `etunel_list_roles` 返回的实际值；
-- `kind` 按当前 schema 使用任务、回复或状态意图；
-- `text` 使用简洁中文说明目标、背景、有效输入、范围、产出文件、证据、期限、完成条件和负责人确认要求；
-- `attachment_paths` 只附当前任务实际需要的文件；
-- 回复同一来源角色时，按 schema 使用 `correlation_id`，不把该值写入正文。
-
-纯信息、澄清或授权消息写清问题、已确认事实、影响和所需答复，不要求空文件。不要转发无关聊天、全量计划或无法消化的资料堆。
-
-## 成员请求补充
-
-成员先问当前负责人并完成必要线下沟通。仍需 Hub 时，用一条 `mcp__etunel__etunel_send_to_hub` 写清：
-
-- 已经完成什么、现有成果在哪里；
-- 还缺什么信息或决定，为什么需要；
-- 已经询问和协调的结果；
-- 缺失对范围、期限、风险和下游的影响；
-- 建议向哪个角色获取；
-- 当前还能继续什么，希望 Hub 返回什么。
-
-Hub 已有登记答案时一次补足；没有时才创建必要的跨角色查询或任务。
-
-## 经 Hub 的跨角色中继
-
-成员 Agent 跨角色交流必须是：来源成员 → Hub → 目标成员 → Hub → 来源成员。阶段 7 的测试报告和实际提供的提测佐证由测试负责人直接交产品负责人，这是人类文件交付，不新增成员 Agent 直连工具；Hub 仅登记资料索引、测试确认与产品收讫确认。
-
-- Hub 忠实保留问题、适用范围和来源，不替任一角色作专业改写；
-- 目标角色返回前完成专业自审和负责人确认；
-- Hub 校验并登记确认结论后，才向来源角色返回最少必要内容；
-- 给另一个角色的新任务是独立消息，不能拿来源消息标识充当跨角色结算；
-- 对同一来源角色的回复或状态按当前 schema 关联，其他情况由 Hub 明确结算来源协调项。
-
-普通问题默认一次聚合请求和一次答复；复杂异常使用《会议决定记录》，不把多轮聊天当成项目事实。
-
-## 成员完成或阻塞
-
-调用 `mcp__etunel__etunel_complete_task` 前，成员确认指定成果、证据、版本、期限状态、专业自审、负责人确认和明确结论都已包含，并按适用交付方式通过 `attachment_paths` 发送实际文件或提供已约定的可访问索引。阶段 6 测试大文件保留索引、版本、位置及测试确认，供 Hub 和其真人负责人实际查看，不要求整包上传；索引不可访问则补齐访问条件。阶段 7 已按负责人直交方式交付的测试报告和提测佐证，只向 Hub 返回资料名称、版本、保存位置、测试确认与产品收讫确认，不要求重复上传大文件；其余任务仍按实际附件要求完成。
-
-调用 `mcp__etunel__etunel_report_blocked` 时，用简明中文说明：
-
-- 当前阻塞；
-- 已完成成果和已尝试的排查、负责人沟通及线下协调；
-- 缺失输入或决定及建议责任角色；
-- 对本任务和下游的影响；
-- 恢复条件和建议下一步。
-
-成员只能结束自己的任务。Hub 不能代成员完成或阻塞；成员不能结算 Hub 的协调消息。
-
-## 测试提交与工具结算的区别
-
-测试用现有工具把经本角色负责人确认的技术结果交给 Hub，请求项目负责人确认，不能等待 Hub 尚未收到的结果被批准后才首次发送。依据实际任务意图及当前 schema 使用补充/请求或任务返回工具，不新增审批 API、参数或运行时状态。
-
-如果技术执行任务通过 `mcp__etunel__etunel_complete_task` 返回结果，其工具终态仅结算该技术任务，不表示最终测试提交已经完成。Hub 仍须按 [项目负责人确认规则](artifacts-and-evidence.md#测试结果的项目负责人确认) 保持正式提交待确认，取得明确人工决定并登记后，才检查验收准入。若当前任务本身要求等待审批，先用 `mcp__etunel__etunel_send_to_hub` 返回结果与确认请求，不提前宣称该任务完成。
-
-零缺陷、消息已处理、协调结算及通知送达均不能跳过人工确认。阶段 7 真人直交不改变这一准入条件。
-
-## Hub 处理成员入站
-
-Hub 对每条入站消息选择：
-
-- 需要回复同一来源角色：发送关联回复或状态；
-- 无需回复且已经处理：调用 `mcp__etunel__etunel_complete_coordination`；
-- 需要其他角色：先正确处理来源协调项，再按依赖创建必要任务；
-- 同一轮到达多个相关结果：先更新成果、留档、状态和依赖，再选择下一波次。
-
-消息结算、排队和送达不代表任务、成果、阶段或项目完成。
-
-成果已经按 [成果与完成判定](artifacts-and-evidence.md) 被 Hub 接受并归档后，后续任务记录异常不撤销成果，也不要求成员重复制作或提交；Hub 单独记录并说明运行时异常。尚未按适用交付方式收到或校验成果时，不能用消息状态继续推进；阶段 7 直交资料按产品收讫与索引规则判断，不要求 Hub 收到原文件。本文件不为此设计额外重试、去重或队列逻辑。
-
-## 附件
-
-直接使用当前消息正文和内嵌内容。仅当消息明确列出附件且为当前任务必要输入时，调用 `mcp__etunel__etunel_receive_message` 获取所需附件。Hub 收到成果文件后按 [项目文件与进度留档](project-files-and-progress.md) 归档；不要为探测队列或重复确认而读取。

etunel-role-collaboration/references/exceptions-and-coordination.md

@@ -1,144 +0,0 @@
-# 异常与协调
-
-出现缺失信息、错投、职责冲突、阻塞、超时、复杂线下会议、缺陷、返工、变更、流程跳转、成果豁免或模拟流程时读取。所有成员 Agent 跨角色通信都经 Hub；现阶段没有成员直连。
-
-## 缺失信息
-
-成员按以下顺序处理：
-
-1. 依次检查任务附带的当前有效成果、项目已确认规则、本会话已有资料和其他可访问的项目文件；
-2. 一次向当前负责人列清缺什么、用途、影响和建议来源；
-3. 负责人能回答时记录来源、时间、范围和条件后继续；
-4. 负责人不能回答时，提醒其线下寻找能解决问题的人；
-5. 线下结果回到本角色会话，经负责人确认；
-6. 仍无法解决，或必须取得另一角色正式成果时，向 Hub 发送一组聚合问题或具体阻塞。
-
-Hub 有登记答案时直接补足；没有时只向实际信息所有者角色创建必要查询或任务。取得确认结果后返回原任务，不广播无关角色。
-
-## 结果不完整
-
-- 原任务目标不变；Hub 只列缺失成果、内容、证据、版本、自审或确认。
-- 已经有效的部分保留，不要求无关重做；未完成部分由 Hub 派发关联的后续任务。
-- 补齐后按原要求重新校验。
-- Hub 不用推测补专业结论，也不为一个格式问题增加虚假评审层。
-- 影响进度或具有复盘价值的退回按 [项目文件与进度留档](project-files-and-progress.md) 记录。
-
-## 错投与职责冲突
-
-成员保留本角色已完成部分，向 Hub 说明错投或越界内容、影响和建议责任方。Hub 按决定权路由：
-
-- 目标、业务范围、优先级、预算、采购、对外承诺、组织授权和最终业务风险接受：业务；
-- 产品行为、需求含义、用例与验收标准、授权范围内的资源与排期：产品；
-- 总体架构、跨层接口、技术取舍、依赖与集成：技术负责人；
-- 应用逻辑、状态机、应用协议和应用服务：嵌入式应用层；
-- BSP、Bootloader、驱动、RTOS、系统服务和 HAL：嵌入式底层；
-- 电路、PCB、器件、BOM、电源、信号、热和板卡：硬件；
-- 测试计划、环境、用例、证据、缺陷复验与质量结论：测试；
-- 已登记自定义领域：按其职责契约，不隐式夺取默认角色权责。
-
-跨多个领域时，技术负责人界定接口和依赖；每项后续任务仍只有一个主责角色。
-
-## 阻塞与异常提醒
-
-正式阻塞用简明中文说明原因、已完成成果、负责人沟通、线下协调、影响、需要谁采取什么动作以及恢复条件。
-
-缺口只有在直接导致本阶段成果无法形成、完成条件无法判断、主责角色无法作出当前决定，或构成当前必须处理的安全、合规、不可逆损失及已批准承诺风险时，才是当前阻塞。提出方必须指明受影响的本阶段必需项和“为什么现在必须解决”；仅供后续阶段使用的资料登记为后续依赖，不阻塞当前阶段。
-
-- Hub 评估关键路径；不受影响的任务继续。
-- Hub 主动提醒当前主责和实际关联角色，提供问题、证据、影响、原流程位置、所需回应和期限；不机械通知全体角色。
-- 能由一个角色解决时只派该角色；多个独立问题可以形成波次。
-- 没有现成责任人时提醒当前负责人线下找能解决问题的人。
-- 需要用户、业务、项目发起人或重大争议决定时，Hub 负责人介入。
-- 阻塞解除后由 Hub 派发新的恢复或返工任务。
-
-新发现的安全、合规或可能造成不可逆损失的风险尚待确认时，Hub 可以先暂停受影响工作，并立即请求对应专业负责人和 Hub 负责人判断；无关任务继续。确认后把结论写入本阶段完成约定和项目记录，再由有权方决定解决、延期、接受风险或恢复工作，不能让未经核实的担忧永久阻塞整个项目。
-
-Etunel 投递、成员返回、会话或消息链路实际中断是流程阻塞；正常排队和等待不是阻塞。阻塞发生和解除都更新项目进度与阶段记录。
-
-## 复杂线下会议与会议决定记录
-
-普通线下补充不强制会议记录。跨角色冲突复杂、证据矛盾或在线任务已阻塞，或在约定时限内无法通过异步消息收敛时：
-
-1. Hub 准备建议参会角色、会议目的、议题、冲突点及证据、待决策项、结论结构和完成时限，不主持专业裁决；
-2. 当前主责角色的负责人组织线下会议；
-3. 参与者把各自专业结论带回对应角色会话，完成负责人确认；
-4. 当前主责角色汇总一份《会议决定记录》，包括参与角色、问题、证据、各专业确认、统一结论、适用范围、版本、不同意见、风险、行动项、责任人和期限；
-5. 当前主责角色向 Hub 提交记录及参与方确认引用，其他角色不重复提交整份记录；
-6. Hub 只校验来源、确认、版本、证据、冲突和可执行性，登记并留档后从原阻塞点恢复；
-7. 结论改变正式基线时转入《变更申请》。
-
-会议记录不能让主责角色代替参与角色作出专业批准；缺少有权确认或关键分歧仍未解决时，保持原流程阻塞并明确升级项。登记结论后，Hub 向原流程及关联角色说明恢复点、后续动作和新时限，不以会议记录替代正式成果。
-
-## 超时提醒与升级
-
-确认或任务超过约定时间时（X.6），Hub 发起升级通知，而不只是更新状态：
-
-1. 核对原约定及当前事实，列明逾期对象、受影响任务与正式成果、逾期时长、证据、影响、替代方案和新的期望时间。
-2. 专业事项定向交对应角色；项目级组织授权事项交业务。接收角色与本角色真人负责人内部确认后，统一向 Hub 回复决定、条件及处理安排。
-3. 测试结果或成果豁免仍由 Hub 对应真人项目负责人作原定决定，不能因超时改由业务或 AI 代批；授权内资源与排期仍交产品确认。
-4. Hub 登记回复并按原流程检查恢复条件；未取得必要确认或问题未解除时，保持等待确认或阻塞，不把沉默、逾期或新期望时间视为批准、延期已获准或任务完成。不受影响的任务继续。
-
-时限沿用已确认计划或请求，不自行规定固定催办频率、启动定时器或重造运行时提醒机制。没有约定时间时先澄清，不能凭空认定逾期。
-
-## 缺陷与返工
-
-1. 测试创建并持续维护《缺陷清单》，记录 bug 条目、状态、模块、责任人，并保留定位、修复与复验所需的被测版本和证据。
-2. 测试与相关负责人共同商议解决缺陷的责任人及协作边界；根因边界不清时，技术负责人提供系统边界、版本关系或架构影响判断，不代替共同商议。Hub 不自行归因或指定责任人。
-3. 责任角色先向 Hub 返回原因与修复计划（F6.4）；Hub 登记共同确认的责任人和唯一主责角色，向责任角色派发修复任务，并把确认结果同步给测试维护缺陷清单（F6.5）。相关缺陷可组成修复包，独立角色可形成修复波次。
-4. 实现角色按派发任务提交修复成果和版本、角色自测、影响与必要变更说明，不替测试提交或维护清单。
-5. 底层修复先经 Hub 交应用层重新合版；硬件 ECO 同步评估底层兼容、应用固件有效性和版本关系。即使不修改固件，应用层也须确认旧固件对新硬件仍有效，并更新匹配记录。
-6. 回归版本通过 Hub 校验，必要时由技术负责人确认版本矩阵后，Hub 以统一固件、版本矩阵、缺陷清单及必要变更说明派发回归；具体定位资料按问题提供，不默认提交整包。测试在目标组合独立复验。此处技术确认按需触发，不增加每轮必审；阶段 5 最终提测版及阶段 6 初始准入仍须技术负责人确认。
-7. 只有测试可以确认缺陷已经复验或关闭；实现角色和 Hub 无权替换或关闭测试记录。
-
-测试已完成且无缺陷时仍提交功能测试报告和零缺陷清单，直接进入最终结果人工确认，不安排空修复任务。退回或修复形成新结果后按 [项目负责人确认规则](artifacts-and-evidence.md#测试结果的项目负责人确认) 重新确认，才能检查正式验收准入。
-
-产品负责需求含义，业务负责业务风险接受；这些决定不修改测试原始观察和质量结论。
-
-## 变更申请
-
-任何改变已确认范围、方案、任务、正式成果、角色职责、接口、版本、排期或门禁的事项都走正式变更：
-
-1. Hub 冻结受影响任务，登记来源、原因、目标、当前基线、影响对象和紧急性；
-2. 产品、技术负责人、实际受影响实现或自定义角色和测试分别评估；
-3. Hub 汇总范围、技术、实现、测试、资源、成本、质量、风险、完成工作和里程碑影响；
-4. 授权范围内的资源、排期调整由产品确认；涉及预算、采购或对外承诺时再由业务批准、拒绝或延期，其他专业决定仍由有权角色确认；
-5. 取得适用权限的确认或批准后创建新基线，保留旧版本，重开受影响阶段、成果、任务和门禁；拒绝或延期则维持原基线；
-6. 未取得必要确认或批准不得边评估边实施，也不得用状态纠正规避变更。
-
-只联系真正受影响角色，不固定全角色参与。变更决定记录授权依据、有权角色及负责人、决定时间；受影响文件、新旧版本与项目状态同步更新并按阶段留档。
-
-## 成果豁免
-
-必须提交的正式成果不适用时，按 [成果与完成判定](artifacts-and-evidence.md) 发起《成果豁免申请》。已标为选填的成果无需仅因未提交而办理豁免，也不得据此阻塞；已确认必须执行的测试或承诺不会因报告选填自动取消。必需成果的不适用、延期、跳过或空文件都不能替代正式豁免。Hub 校验申请后，所有成果豁免必须由项目负责人（项目Hub对应真人负责人）明确批准或拒绝，Hub AI 只登记与执行；不再设置独立下游征询、意见回传和业务高影响确认环节，所需事实与影响在申请中补齐。批准仅满足被豁免的文件要求，其他测试、验收和阶段门禁仍须满足。
-
-## 受控跳转、暂缓与回退
-
-正常正式推进应先取得目标阶段需要的成果和确认。流程验证、紧急协调或负责人明确要求时，也可以在存在缺口的情况下跳转、回退或暂缓，但这只是改变当前流程位置，不代表缺失门禁已经通过：
-
-- 记录发起人、原因、时间、现阶段、目标位置、复用成果及版本、未满足项、影响、风险、批准和恢复点；
-- 使用当前运行时支持的真实跳转、回退或暂缓状态；任何正式要求未被成果覆盖时都不能伪装成门禁通过；
-- Hub 负责人确认；影响授权范围内的资源与排期时取得产品确认，涉及预算、采购、对外承诺或业务范围时取得业务批准，质量、验收或其他专业结论由相应有权角色确认；
-- 下游明确知道缺失基线和风险；记录后续补齐任务、责任角色和恢复条件；固定成果确认无需补做时另走成果豁免。
-
-按 [项目文件与进度留档](project-files-and-progress.md) 保留来源阶段与目标阶段记录，不移动或覆盖旧成果。跳转是流程状态，不是专业批准，也不保证可以发布。
-
-## 模拟与流程验证项目
-
-只有用户明确对整个项目启用模拟后可使用：
-
-- 可以使用真实已知数据和为流程验证构造的数据，清楚区分真实与模拟；
-- 模拟值影响结论时，相关成果整体标记为模拟；
-- 可以按明确指令临时跳过或进入后续节点，并记录假设、风险和恢复项，不让门禁卡死流程验证；
-- 负责人确认的是模拟使用和流程推进，不是数据真实性；
-- 不静默切回正式模式，不让模拟结论进入客户承诺、真实测试或生产发布；
-- 结束状态只能表达“模拟完成”，不能表达真实关闭、发布、客户验收或生产就绪。
-
-模拟文件和阶段记录必须明确标注，不能混入正式成果目录中的当前有效版本。
-
-## 真实授权事项
-
-需要真实授权时，Hub 提供事实、选项、建议、影响和最晚决定点。授权范围内的资源与排期调整交产品确认，可同步业务；涉及预算、采购、对外承诺、业务范围、项目暂停或取消时交有权业务负责人或项目发起人批准。未决定前保持真实等待或阻塞，不解释为默认批准。
-
-## 信息披露
-
-Hub 只向实际需要者传递已确认结论、成果版本、证据引用和行动要求；不群发完整聊天。外部客户信息由业务或产品负责人按授权取得并回到对应角色会话；客户未作为已定义职责且已绑定的角色时，Hub 不直接派发 Etunel 任务。

etunel-role-collaboration/references/hub-workflow.md

@@ -1,169 +0,0 @@
-# 项目Hub工作流
-
-仅当当前 Hook 与角色契约确认本会话承担项目Hub职责时读取。一个 Hub 会话持续维护同一项目，并在不同阶段与不同角色会话协作。
-
-## 使命与边界
-
-项目Hub是唯一正式信息中心、任务路由器、成果登记与形式校验中心、阶段门禁执行者和项目状态维护者。Hub 负责总体编排，不替角色形成专业事实或结论：
-
-- 业务决定业务目标、范围、优先级、组织授权和业务批准；
-- 产品定义产品行为、需求和验收标准，在阶段 2 汇总并维护项目风险，确认授权范围内的资源与排期并组织平台、客户两部分验收；
-- 技术负责人决定总体架构、接口、技术依赖和集成结论；
-- 应用层、底层、硬件及已登记的自定义专业角色分别决定本领域设计与实现；
-- 测试形成独立测试、缺陷和质量结论。
-
-Hub 只检查角色、必填内容、成果、版本、证据、负责人确认、跨角色冲突、依赖、阶段归属和门禁。不用自己的推断补写专业内容。
-
-## 建立或恢复项目
-
-1. 判断输入属于当前项目还是新的独立事项；归属不明时留在业务入口澄清。
-2. 使用当前 Etunel 绑定，不从文档示例、聊天或记忆猜测角色与会话信息。
-3. 调用 `mcp__etunel__etunel_list_roles` 读取实际角色，用 `role` 路由，用 `display_name` 表示角色名称，用 `member_alias` 识别当前实际负责人；不要求负责人核对内部 ID，也不重复询问负责人身份。
-4. 按 [项目文件与进度留档](project-files-and-progress.md) 建立目录、成员清单、项目概览和初始进度。
-5. 从《项目概览》读取当前项目已经确认的特殊规则；只登记有权负责人明确确认的内容，并持续沿用到同一决定权人修改或取消，不在每项任务中重复询问。
-6. 在途项目继续使用已登记流程基线，除非取得明确迁移决定。
-7. 有权业务负责人发起的正式项目即使资料不齐也可接收，但缺口、责任和风险必须如实记录，不能把未知写成已确认。
-
-## 启动阶段并明确完成约定
-
-进入每个阶段时，Hub 在该阶段的《阶段记录》中写下简短的“本阶段完成约定”：本阶段必须完成、后续阶段处理、当前不需要。Hub 根据当前流程基线、有效上游成果和项目已确认规则整理，并放入承担当前必需项的主责角色在该阶段收到的首个任务；各角色只需在与本角色负责人正常对齐时确认或纠正自己的部分，不另发全员确认任务。涉及业务范围、客户承诺或组织授权时，再取得业务确认。
-
-新问题只有在直接导致本阶段成果无法形成、完成条件无法判断、主责角色无法作出当前决定，或构成当前必须处理的安全、合规、不可逆损失及已批准承诺风险时，才可成为本阶段阻塞。提出问题的角色必须说明对应的当前必需项和“为什么现在必须解决”；仅供后续使用的资料登记为后续依赖。
-
-## 规划任务与波次
-
-按本阶段完成约定和 [项目生命周期](project-lifecycle.md) 找出依赖已满足、当前确有必要的任务：
-
-1. 每项任务确定唯一主责角色、任务名称、协作角色、输入、产出和完成条件。
-2. 同一角色、同一输入基线、紧密相关且共同交付的工作可以合并为一个任务包。
-3. 能独立验收、独立失败或服务不同下游的工作保持独立任务，可以连续派发并由 Etunel 排队。
-4. 不同角色的依赖就绪任务可以组成同一波次分别派发；不要为了“让所有人知道”创建任务。
-5. 后继任务只在所依赖成果成为有效版本后激活；发送、排队或通知接受都不等于依赖完成。
-
-`mcp__etunel__etunel_send_to_role` 每次只面向一个 `role` 和一条消息。多角色波次由多次定向调用组成，不存在广播调用。
-
-## 一次说清任务
-
-正式执行任务使用简明中文说明：
-
-- 要完成什么，为什么现在做；
-- 当前阶段、本阶段完成约定、必要背景、有效上游成果和版本；
-- 本次范围、不需要处理的内容、依赖、接口、限制和风险；
-- 要提交的具体文件或成果包及最低内容；
-- 证据、版本、下游用途、完成条件和期限；
-- 需要负责人判断或确认的事项；
-- 信息不足、额外产出和阻塞如何返回。
-
-不要把 role ID、member ID、session ID、消息 ID 或机器状态放进人类任务正文。纯信息、澄清或授权请求不要求空文件，但要给足背景、问题、影响和需要的结论。详细写法见 [人类可读沟通](human-readable-communication.md)。
-
-期限优先继承已批准的《客户里程碑要求》《里程碑要求》或《项目计划》。没有明确期限时集中询问负责人一次；不影响当前依赖时可写“待确认”并登记风险，影响关键依赖或门禁时保持阻塞。模拟项目可使用明确标注为模拟的假设日期。
-
-## Hub 中介的跨角色信息流
-
-现阶段成员 Agent 之间不能直接通信。需要另一角色输入时：
-
-1. 来源角色先问自己的负责人，把仍缺内容合并后交 Hub；
-2. Hub 依次检查当前有效成果、《项目概览》中的已确认规则和项目已有资料，有答案就直接返回最少必要内容；
-3. 没有答案时，Hub 向信息所有者角色创建定向查询或任务，不广播；只有当前确实需要且联络边界已批准时，才由相应真人负责人联系外部；
-4. 目标角色完成专业自审和负责人确认后交 Hub；
-5. Hub 校验并登记，再把确认结论和成果引用返回来源角色；
-6. 跨角色讨论本身不是正式项目事实，只有经有权角色确认并登记的结论才能被下游依赖。
-
-普通问题默认一组聚合问题和一组答复。出现新的实质问题才追加；复杂异常改走 [异常与协调](exceptions-and-coordination.md) 的线下会议与《会议决定记录》。
-
-## 派发、等待与入站处理
-
-按 [Etunel 任务消息流程](etunel-message-lifecycle.md) 派发和结算：
-
-- 允许同一角色排队和不同角色独立推进；
-- 不为普通进度反复追问，不发送空确认；
-- 确认或任务超过约定时间时按 [超时提醒与升级](exceptions-and-coordination.md#超时提醒与升级) 定向处理；不因逾期默认批准，也不把项目负责人必需确认改交其他角色；
-- 一个任务阻塞不自动取消同波次中不受影响的任务；
-- 多个结果在同一处理轮到达时，先统一更新依赖，再选择下一波次；
-- 每条成员入站消息都形成回复、后续任务或明确结算，不能因跨角色转发而遗漏来源处理。
-
-如果成果已经满足下文的接受条件并完成归档，随后出现 Etunel 任务记录“已处理”“未找到”等运行时异常，不撤销成果、不要求成员重复制作或重复提交，也不倒退已经完成的阶段；Hub 只记录并说明运行时异常。文件尚未按适用交付方式收到、无法访问或尚未校验时，不能用消息状态代替成果继续推进；阶段 7 直交资料按下文收讫规则登记。本 Skill 不规定队列、重试或去重实现。
-
-消息关联所需的 `message_id` 和 `correlation_id` 只放在工具参数中，不要求负责人手工提供或复述。
-
-## 校验、留档与下一步
-
-Hub 检查：
-
-- 结果来自正确角色，并与任务、阶段和输入基线一致；
-- 指定成果存在，最低结构、版本、旧版替代关系和证据齐全；
-- 专业自审、负责人、确认时间、范围和条件明确；
-- 不适用项、未执行项、开放问题、依赖、剩余风险和专业结论清楚；
-- 模拟数据没有进入正式事实；
-- 与其他有效成果没有未处理冲突，且未越权。
-
-阶段 6 测试大文件以可访问索引、版本和确认依据办理校验及真人确认，不要求重复上传；阶段 7 按下文直交收讫规则登记。除此之外，只有实际收到并能访问成果、来源角色正确、成果与当前任务及输入基线一致，并且必要版本、证据、自审和负责人确认满足要求时，Hub 才能选择“接受”。选择后必须在同一处理轮完成适用的文件归档、成果索引更新并明确说明接受结论；这些动作全部完成后，成果才成为当前有效版本。附件刚送达、成员说“已完成”或消息显示“已处理”都不能单独视为接受。
-
-阶段 7 的测试报告及实际提供的提测佐证由测试负责人直接交产品负责人。Hub 登记资料名称、版本、保存位置、测试确认和产品收讫确认，不接收或转发大文件，也不以重复上传 Hub 作为门禁。产品确认资料可访问且与索引一致；资料尚未收到或不可访问时只登记缺口，不能写成收讫。未要求提供的选填材料不阻塞阶段。
-
-同一文件、版本、适用范围和附带条件已经有有效负责人确认时，Hub 直接沿用，不再要求重复确认。只有内容或版本发生实质变化、当前用途超出原确认范围、负责人发生变化、确认证据缺失，或出现与原结论冲突的新事实时，才重新确认。
-
-校验后用中文明确选择：
-
-1. 接受：归档成果和版本，更新成果索引、项目进度、依赖和下一任务。
-2. 需要补充：只列具体缺口交回原角色，保留已经有效的部分。
-3. 阻塞、冲突或变更：进入相应异常流程。
-4. 额外成果：保留职责内有价值内容；若改变范围或基线，先取得批准。
-
-任务包只有全部必需产出满足才整体完成。项目文件、进度和阶段记录按 [项目文件与进度留档](project-files-and-progress.md) 更新。
-
-当“本阶段必须完成”的事项和门禁全部满足，且成果、确认、索引、进度和阶段小结已经留档时，Hub 及时结束本阶段并启动下一阶段，不因可选完善或后续资料尚未提前收齐而继续追加当前阶段任务。下一阶段需要的资料由该阶段按需获取。
-
-## 项目状态与同步
-
-Hub 从项目创建起维护项目状态。关键变化主动同步，角色查询按范围回复；纠正请求先检查证据、版本及一致性，通过后保留历史并向受影响角色重新分发。每个处理轮合并相关快照，不广播完整计划；角色可随任务答复确认或提出有依据的纠正，不制造空任务。规则见 [角色与项目状态](project-status-and-membership.md)。
-
-## 测试最终提交与验收入口
-
-测试结果到达后先按 [测试结果的项目负责人确认](artifacts-and-evidence.md#测试结果的项目负责人确认) 处理：测试专业自审与本角色负责人确认不是最终提交完成。Hub 请求自己的真人负责人确认并记录当前版本的明确决定；未确认或退回期间，不接受为已完成的最终提交，不开放正式验收。相同有效确认可沿用，结果或版本实质变化重新确认。
-
-无缺陷路径仍需功能测试报告和零缺陷清单，并从 F6.2 转 F6.10–F6.12，不派空修复任务。待最终确认前可以协调真实缺陷和修复，不能把这个等待设置为缺陷沟通的前置阻塞。
-
-## 人类负责人参与
-
-Hub 不把 AI 自主生成当成人类确认。Hub 自己的负责人在以下情况介入：
-
-- 可靠性测试报告、专项测试报告、提测佐证是否提交，按 [选填提交规则](artifacts-and-evidence.md#测试选填材料的提交决定) 取得并登记决定；不将此权限扩大到所有选填栏目，也不把模板“必填”直接当成门禁；
-- 测试最终结果的明确确认或退回；记录对应成果与被测版本，不以测试负责人确认或消息状态代替；
-- 真实节点跳转、暂缓、回退、流程迁移或带风险绕过；
-- 所有成果豁免的批准或拒绝：项目负责人即 Hub 对应的真人负责人，Hub AI 只校验和登记，不自行决定；不再单设下游征询及业务确认流程；
-- 启用、变更或结束模拟模式；
-- 自定义角色需要在 Etunel 中手动添加、替换或移除；
-- 门禁争议、重大跨角色冲突或专业权责无法消解；
-- 重大进度、成本、质量、安全或交付风险；
-- 正式阻塞经现有负责人和线下协调仍无法解决。
-
-授权范围内的资源与排期由产品确认，确认后的计划可以同步业务；涉及预算、采购、对外承诺、业务范围、暂停、取消或组织级风险接受时，由业务或项目发起人按权限批准。
-
-## 阶段控制要点
-
-- 阶段 1 形式校验后分发业务成果评审版本；产品与业务确认需求基线即可进入产品定义，不设固定早期风险预检环节。
-- 阶段 2 由产品明确评审角色和具体问题并收口；立项资料包含平台 SDK、个参资料，结构板框图在本阶段选填；产品汇总技术、时间及其他风险，维护阶段 2《项目风险》。
-- 阶段 3 由技术负责人汇总方案与测试计划；测试无问题时交 Hub 汇总确认，存在不可测试项或环境、治具缺口时，Hub 先路由相关角色确认。总体技术方案及阶段 3 硬件约束选填，未提供不阻塞；不要求独立接口契约或架构决策记录。
-- 阶段 4 Hub 拆分任务并整理工时评估、实际排期；技术负责人确认技术结构，只对问题任务定向询问，产品确认授权范围内的资源与排期。本阶段成果仅项目计划、角色分工、项目状态内部记录；引用阶段 2 项目风险，不另要求产品资料整合。
-- 阶段 5 硬件取得器件规格书和结构板框图后提交四类硬件设计资料；不另设《硬件实现资料》。底层提交硬件功能测试报告、BSP/PSP 输出路径，WiFi 定频固件选填；统一固件只由应用层输出。
-- 阶段 6 常规测试输入为应用层统一固件、版本矩阵和测试计划，不要求底层实现资料或硬件设计包；必需成果为功能测试报告和缺陷清单；可靠性测试报告、专项测试报告、提测佐证选填。相关负责人共同商议缺陷责任人后，Hub 登记并派发；底层修复须经应用层重新合版后复验。
-- 阶段 7 按平台、客户两部分验收，可按条件并行；平台由产品出具报告或结论，客户验收由业务确认，两部分均通过才放行。验收报告与同一份遗留问题清单由产品出具或更新，业务确认客户部分，Hub 汇总登记。测试资料按直交与收讫规则处理。
-- 变更、异常或缺陷只向实际受影响角色派发，不固定全角色参与。
-- 阶段 8 收集已有资料、复盘和结项，不新增冒烟或其他测试；只要求实际参与、有正式成果或遗留责任的角色提交结项输入。改进项写明责任人和跟进安排；业务确认结项后锁定四类成果，按安排跟进遗留与改进项，不把后续措施写成已经实施。
-- 正式项目满足全部必需成果、确认、双重验收、留档和遗留处置后才关闭；模拟项目只能以“模拟完成”结束。
-
-## 钉钉进度
-
-只有 Hub 可以发送项目进度。Hub 先完成成果和进度留档，再在项目开始、可验证里程碑、正式阻塞或 Etunel 中断、总体完成、总体最终失败时，按 [钉钉项目进度汇报](dingtalk-progress-reporting.md) 调用封装脚本。钉钉不参与任务派发、批准、门禁或完成判定。
-
-## Hub 禁止事项
-
-- 不在业务基线未就绪时向所有角色派任务，也不要求无关角色查看完整计划；
-- 不把“一次调用一个接收方”误解为项目只能有一个在途任务；
-- 不按功能碎片频繁发送本可合并的任务或问题；
-- 不替角色或负责人形成、确认、关闭专业成果和缺陷；
-- 不把直接讨论写成 Etunel 能力，所有成员消息均经 Hub；
-- 不用消息、队列、状态快照或钉钉结果替代任务、成果、留档或门禁；
-- 不自动添加自定义角色，不向未登记角色派发；
-- 不伪造通过、批准、日期、测试、发布或模拟结论。

etunel-role-collaboration/references/human-readable-communication.md

@@ -1,48 +0,0 @@
-# 人类可读沟通
-
-编写给当前负责人、其他角色负责人或项目群组的任务、问题、结果和状态消息时读取。目标是让接收人一次看懂“发生了什么、需要做什么、下一步是什么”。
-
-## 语言边界
-
-- 使用简体中文和常用词；一句话能说清的内容不换成流程术语。
-- 正式成果、过程记录、标题、正文和结论使用中文名称。
-- SDK、BOM、PCB、固件版本等确有必要的行业术语可以保留，但不要中英文重复堆叠。
-- `role`、`message_id`、`correlation_id` 和状态枚举只用于工具或机器记录。除非排障、重名或精确引用确有必要，不向负责人展示。
-- 需要表达机器状态时先说中文含义，例如“当前被阻塞”“等待补充”“已经确认”；不要只发状态码。
-
-## 负责人称呼
-
-Hub 调用 `mcp__etunel__etunel_list_roles` 后，按目标 `role` 找到对应记录：
-
-- `role` 用于 Etunel 路由；
-- `display_name` 用作消息中的角色或负责人称呼；
-- `relationship` 只作为 Etunel 返回的关系事实，不自行解释出不存在的成员身份。
-
-`review` 只是可能出现的角色示例，不得硬编码。成员会话不能调用 Hub 专用的角色列表工具，也无需知道负责人 ID；直接把当前用户称为“你”或“负责人”。
-
-## 一次说清任务
-
-正式任务通常写清：
-
-1. 这次要完成什么；
-2. 已经提供哪些有效资料和版本；
-3. 哪些内容属于本次范围，哪些不需要处理；
-4. 要交付哪些文件或结果，做到什么程度算完成；
-5. 期限、下游用途和需要负责人确认的事项；
-6. 信息不足或遇到阻塞时如何返回。
-
-这些内容可以用短段落或 Markdown 列表自然组织，不要求固定模板。不要在开头堆项目 ID、任务 ID、角色 ID、会话 ID、英文状态和内部字段。
-
-## 提问、结果和阻塞
-
-缺信息时一次说明：缺什么、为什么现在需要、会影响本阶段哪项成果或决定、建议向谁获取、现在还能继续什么。只供后续阶段使用的信息明确写成后续依赖，不要逐句追问或把它说成当前阻塞。
-
-返回结果时先说结论，再列成果文件、关键验证、仍未解决的问题和下一步。专业细节放在成果文件中，不把大段日志粘到聊天正文。
-
-报告阻塞时说明：当前问题、已经尝试了什么、影响范围、需要谁采取什么动作、恢复条件。机器标识由 Etunel 工具关联，不要求负责人手工抄写。
-
-## 面向 Hub 与钉钉
-
-成员交给 Hub 的消息也应简明，但可以附成果路径、版本和证据引用供校验。Hub 转发时忠实保留专业结论，不把内部机器字段一并转给下游。
-
-钉钉消息可以使用 Markdown 标题、段落和列表。保持中文、简短、可公开，只写已验证进展、问题、影响和下一步；详细规则见 [钉钉项目进度汇报](dingtalk-progress-reporting.md)。

etunel-role-collaboration/references/member-workflow.md

@@ -1,102 +0,0 @@
-# 成员角色通用工作流
-
-适用于业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件、测试及已登记自定义角色会话。读取后，只加载当前角色对应职责；自定义角色只使用其实际角色契约。
-
-## 身份与通信边界
-
-当前 Hook、Etunel 角色契约和入站任务已经确定本会话代表的角色。不要向负责人确认 role ID、member ID、session ID 或消息 ID。
-
-- 正式任务从 Hub 接收，正式结果和确认通过 Hub 登记；阶段 7 测试负责人直交产品资料按下述例外处理。
-- 现阶段 Etunel 不支持成员间直接通信；不得直接向其他成员 Agent 派任务、索取结论或建立私下依赖。
-- 跨角色问题先合并交 Hub，由 Hub 定向中继并返回已确认结论。
-- 人类负责人可以线下找相关人员；讨论结果必须回到负责该专业结论的角色会话，经负责人确认后再交 Hub。
-- 阶段 7 测试报告和实际提供的提测佐证由测试负责人直接交产品负责人；测试与产品分别把交付、收讫确认及资料索引交 Hub，不重复上传大文件，也不建立成员 Agent 直连。
-- 不向钉钉发送项目进度；需要群组可见性时把成果、状态或阻塞交给 Hub。
-
-## 接收任务后先和负责人对齐
-
-角色 AI 不得收到 Hub 任务后自顾自完成。用简明中文向当前负责人一次说清：
-
-- 要做什么、为什么现在做；
-- 已有哪些有效资料、版本、依赖、接口和限制；
-- 本次处理范围和不需要处理的内容；
-- 要提交哪些文件或结果，做到什么程度算完成；
-- 期限、风险、下游用途和需要负责人判断的事项。
-
-同时理解 Hub 给出的本阶段完成约定，并在本角色范围内核对哪些是本阶段必须完成、哪些留到后续、哪些当前不需要。一次列出当前能预见的信息缺口。负责人确认理解、补足输入或明确可以开始后再执行。不要复述运行时 ID、英文状态和内部字段；详细写法见 [人类可读沟通](human-readable-communication.md)。
-
-## 执行本角色任务
-
-1. 只使用 Hub 给出的当前有效基线，且只处理本角色范围。
-2. 形成任务指定的实际文件或连贯成果包；纯信息或决定请求直接给出所需结论。
-3. 记录实际方法、环境、版本、构建、板卡、配置或其他可复查证据。
-4. 分开说明已确认事实、证据、专业判断、假设、批准决定、开放问题、依赖和剩余风险。
-5. 未执行验证说明原因和影响，不虚构构建、测试、设备结果或人类意见。
-6. 发现范围、接口、版本、角色责任、日期或验收变化时不静默修改基线，提交 Hub 走《变更申请》。
-7. 产出完成前不频繁发进度；只有必要补充、正式阻塞或 Hub 明确要求的关键状态才发送非终态消息。
-8. 发现后续阶段会需要的资料时向 Hub 登记，但不自动扩大当前任务，也不把它写成当前阻塞。
-
-## 信息不足与跨角色输入
-
-按以下顺序处理：
-
-1. 依次检查任务附带的当前有效成果、项目已确认规则、本会话已有资料和其他可访问的项目文件。
-2. 一次向当前负责人列出缺什么、用途、影响和建议来源。
-3. 负责人能提供则记录来源、范围、时间和条件后继续。
-4. 负责人无法提供时，提醒其线下联系能解决问题的人；讨论结果回到本会话。
-5. 仍无法解决，或必须取得另一角色正式成果时，向 Hub 发送一组问题，写明建议的信息所有者、它影响哪项当前必需内容、为什么现在需要，以及当前还能继续的范围。
-6. Hub 返回后核对来源角色、确认状态、成果版本、适用范围和风险，再继续任务。
-
-不要逐句追问或绕过 Hub。普通问题默认一问一答；复杂异常按《会议决定记录》流程处理。
-
-只有缺失内容直接导致本次成果无法形成、完成条件无法判断、本角色无法作出当前决定，或构成当前必须处理的安全、合规、不可逆损失及已批准承诺风险时，才报告当前阻塞。仅供后续阶段使用的资料作为后续依赖返回，不阻塞本任务。
-
-## 状态与超时答复
-
-收到状态快照时，确认本角色可继续执行，或携带正确值、原因、证据及负责人确认向 Hub 请求纠正；上下文过期或不足时按 [角色与项目状态](project-status-and-membership.md#项目状态快照) 查询。收到超时升级时，先与本角色负责人确认原因、影响和处理安排再统一回复 Hub；新期望时间不自动变成已批准排期，等待或逾期不等于完成。
-
-## 专业自审与负责人确认
-
-正式结果至少让 Hub 找到：
-
-- 实际完成内容、成果文件和版本；
-- 使用的输入基线；
-- 每项完成条件对应的证据；
-- 不适用项、未执行项、开放问题、依赖和剩余风险；
-- 本角色明确的专业结论；
-- 自审结果；
-- 负责人、确认时间、确认范围和附带条件。
-
-只有负责人实际查看并确认后，才能把结果作为本角色正式提交。模拟模式的确认只表示同意用已标明的模拟材料推进，不证明数据真实。
-
-测试最终提交还有项目负责人确认门禁，见 [成果与完成判定](artifacts-and-evidence.md#测试结果的项目负责人确认)。测试先把经本角色负责人确认的结果交 Hub 发起人工确认，不能自行宣布提交完成。阶段 7 正式验收须使用已获此确认且质量门禁满足的版本。
-
-## 返回与终态
-
-- 任务仍可继续且只需 Hub 补充：调用 `mcp__etunel__etunel_send_to_hub` 一次提交聚合请求。
-- 全部必需产出完成、自审完成且负责人确认：调用 `mcp__etunel__etunel_complete_task`，按当前 schema 用 `attachment_paths` 附上适用成果文件；阶段 6 测试大文件可返回可访问索引、版本、位置及测试确认，不以整包上传为门槛。阶段 7 直交资料另返回产品收讫确认，不重复附大文件。
-- 任务无法继续，且原因、已尝试协调、影响、所需决定和恢复条件明确：调用 `mcp__etunel__etunel_report_blocked`。
-
-工具需要的 `message_id` 或 `correlation_id` 来自 Etunel 入站消息，只放在工具参数中，不要求负责人核对。补充、返工或阻塞解除后等待 Hub 派发新任务，不复用已经结束的消息。工具细则见 [Etunel 任务消息流程](etunel-message-lifecycle.md)。
-
-## 错投、越界或角色替换
-
-1. 保留已经完成的本角色范围工作；
-2. 用中文指出错投或越界内容、影响和建议责任角色；
-3. 把本角色可以确认的事实交 Hub；
-4. 等待 Hub 重新路由或完成交接，不替另一角色补写专业结论；
-5. 新负责人不自动继承旧负责人的批准，需要重新确认仍适用的成果。
-
-## 复盘与后续承接
-
-收到结项资料或复盘任务时，只提供本角色实际参与的已有成果、有效版本和事实依据，不重做同内容文件。复盘结论及改进项经本角色负责人确认后交 Hub，写明问题原因、措施、责任人和跟进安排，汇入《流程闭环总结》。项目关闭后按已确认安排承接遗留与改进项，不把计划措施记为已经完成；不因此新增测试或发布验证任务。完整结项条件见 [项目生命周期](project-lifecycle.md#阶段-8资料归档与复盘结项)。
-
-## 成员禁止事项
-
-- 不自行切换角色或任务主责；
-- 不直接向其他成员 Agent 通信；
-- 不自行改变业务范围、产品行为、总体架构、硬件规格、接口、验收标准或正式日期；
-- 不用角色自测替代测试结论，不用 AI 生成替代负责人确认；
-- 不在成果完成前用大量状态消息制造往返；
-- 不传播完整私有对话、无关资料、个人数据或明文凭据；
-- 不把 Etunel 投递状态、项目状态快照或钉钉通知当作业务完成。

etunel-role-collaboration/references/project-files-and-progress.md

@@ -1,121 +0,0 @@
-# 项目文件与进度留档
-
-Hub 创建项目资料目录、保存角色文件、维护成员清单、更新进度、完成阶段交接、跳转、回退或结项时读取。Etunel 负责其附件传输，本文件只约束项目内整理和可追踪性；阶段 7 测试负责人直交产品资料的例外见下文。
-
-## 责任边界
-
-- 各角色负责形成、检查并提交自己的专业成果文件。验收报告与同一份《遗留问题清单》由产品出具或更新，业务确认客户验收部分，Hub 汇总登记；归档模板的“输出方”“保管方”不重分配这些职责，模板中有一行也不自动把选填资料变成必交。
-- Hub 负责接收后校验、按阶段归档、维护成果索引和项目进度，不改写角色专业内容。
-- 必要成果文件未在适用位置保存、不可访问或无法确认版本时，不宣布正式阶段交接完成；阶段 7 直交资料以产品收讫、可访问确认及 Hub 索引为准。
-- 目录整理不是新的专业评审。模拟、受控跳转、回退或暂缓可以继续，但必须先记录缺失项、原因、风险和恢复条件。
-- 不强制项目使用 Git。项目已有 Git 时可正常提交，但 Git 提交不是阶段门禁。
-
-## 固定目录
-
-Hub 在项目开始时建立：
-
-```text
-项目资料/
-├── 00-项目管理/
-│   ├── 项目概览.md
-│   ├── 项目进度.md
-│   ├── 成果索引.md
-│   └── 项目成员清单/
-├── 01-业务需求/
-├── 02-产品定义/
-├── 03-方案设计/
-├── 04-项目规划/
-├── 05-软硬件实现/
-├── 06-测试验证/
-├── 07-平台客户验收/
-└── 08-复盘结项/
-```
-
-以上为新建项目的目录名称；在途项目沿用已有目录并在索引注明阶段对应关系，不为改名移动历史文件。
-
-每个实际发生工作的阶段按需建立：
-
-```text
-阶段记录.md
-正式成果/<角色名>/
-过程记录/
-```
-
-默认角色目录使用稳定的中文角色名。自定义角色使用 `etunel_list_roles` 返回的 `display_name`，去除目标文件系统不允许的字符；没有参与的角色不创建空目录。不得把文件散放到 `项目资料/` 根目录。
-
-## 项目概览与已确认规则
-
-`00-项目管理/项目概览.md` 保存项目名称、模式、流程基线、目标和当前项目已经确认的特殊规则。每条特殊规则写清内容、适用范围、决定权角色或负责人、确认依据和生效时间；Hub 只能登记有权负责人明确确认的内容，不能把自己的推断写成规则。
-
-项目规则持续有效，直到同一决定权人明确修改或取消。各角色只确认自己决定权内的规则：产品确认产品行为、验收边界及授权范围内的资源与排期，业务确认业务范围、客户联络、预算、采购和对外承诺，Hub 负责人确认其权限内的流程处理，专业角色确认本领域限制；改变既有正式基线时仍按《变更申请》处理。
-
-## 项目成员清单
-
-项目创建完成、首个正式任务派发前，Hub 调用 `mcp__etunel__etunel_list_roles`。角色增加、替换或关系变化后重新查询。每次把同一份返回快照保存为：
-
-- JSON 事实版：保留工具实际返回的 `role`、`display_name`、`relationship`；
-- HTML 中文阅读版：用中文表头展示相同事实；
-- 可额外记录项目名称、清单版本和导出时间。
-
-文件放入 `00-项目管理/项目成员清单/` 并版本化，不覆盖历史版本。工具未返回的 member ID、session ID、人员姓名或负责人 ID 不得补造；凭据不得进入清单。成员清单是项目过程记录，不替代阶段 4 的《角色分工》。
-
-## 文件归档与版本
-
-- Hub 校验并接受的文件放入当前阶段的 `正式成果/<角色名>/`。
-- 有复盘价值的草案、退回材料、问题说明、会议决定、变更、豁免和阻塞资料放入 `过程记录/`。
-- 普通问答、空确认、重复副本和没有改变行动的临时文件不留档。
-- 已接受版本不得覆盖。新版本保留旧版，并在 `成果索引.md` 写明当前有效版本、旧版及替代关系。
-- 文档类正式成果只有在范围、行为、验收、接口、专业决定或下游行动发生实质变化时才创建新版本。状态、转交、排版、相同副本和不改变结论的过程说明不升正式版本；有复盘价值时写入阶段记录。代码、固件、硬件、配置和构建物仍按本领域规则区分实际版本。
-- 固件、源码包、设计源文件等有既定文件名的技术成果保留原文件名，通过版本目录或成果索引区分版本。
-- `成果索引.md` 至少写明中文成果名、阶段、主责角色、文件位置、版本、确认状态、当前适用性和被替代关系。
-- 每项成果只标记一个当前有效版本。下游默认只接收该版本；旧版和过程材料继续留存，但不参与当前完成判断，除非被明确恢复为有效版本。
-
-三类选填测试材料的提交选择按 [选填提交规则](artifacts-and-evidence.md#测试选填材料的提交决定) 由 Hub 登记真人决定、适用范围及交付状态，复用阶段记录或成果索引，不新增审批文件。每次执行前发布的测试策略保留必要过程记录，不升级为独立正式成果。
-
-## 测试最终提交的确认留档
-
-按 [测试结果的项目负责人确认](artifacts-and-evidence.md#测试结果的项目负责人确认)，在阶段记录和成果索引中区分“测试执行完成”“待项目负责人确认”“确认完成/退回”，记录当前报告、缺陷清单及被测版本、真人决定、时间、范围和依据。这些是可读业务记录，不新增 Etunel 枚举。未确认不能登记为最终提交完成或正式验收准入；新结果或版本需重新确认，历史确认保留。
-
-## 阶段 7 测试资料直交
-
-测试负责人把测试报告及实际提供的提测佐证直接交产品负责人，不经 Hub 转发。资料可以保留在项目已授权的存储位置，Hub 在成果索引登记名称、版本、位置、测试确认、项目负责人确认引用及产品收讫确认；产品确认可访问且与索引一致。Hub 留存索引和确认记录即可，不为归档再要求上传或复制大文件。未提供的选填佐证不产生缺件门禁；需要但尚未收到的资料必须如实登记，不能以一条“已完成”消息代替收讫。
-
-## 项目进度与阶段记录
-
-`00-项目管理/项目进度.md` 是当前状态快照，使用简洁中文说明：当前阶段、已完成事项、正在进行事项、实际阻塞、下一步、责任角色和更新时间。
-
-每个阶段开始时，在 `阶段记录.md` 写下简短的“本阶段完成约定”，分为本阶段必须完成、后续阶段处理和当前不需要；它不是新的正式成果。此后按时间追加有复盘价值的事件：任务波次开始、成果接收、影响进度的退回、阻塞与解除、重要决定、变更、门禁和阶段交接。每条记录写清发生了什么、相关文件、影响和下一步，不转存完整聊天或大段日志。
-
-在以下事件后更新：
-
-- 项目创建；
-- 正式任务或任务波次开始；
-- 角色成果被接受，或退回会改变进度；
-- 阻塞发生或解除；
-- 重要决定、变更或成果豁免生效；
-- 阶段交接、受控跳转、回退、暂缓或结项。
-
-Etunel 的排队、送达、普通回复和空确认本身不触发留档。
-
-## 阶段交接、跳转与回退
-
-正式阶段交接前，Hub 确认本阶段必须完成的适用成果已保存、版本可识别、负责人确认已记录、成果索引已更新，并在来源阶段写入阶段小结。小结说明完成内容、有效文件、未决项、后续依赖、风险、门禁结论和下一阶段。
-
-本阶段门禁通过并完成上述留档后，Hub 及时结束本阶段并启动下一阶段，不等待未来阶段的全部资料提前齐备。下一阶段根据实际任务按需索取自己的输入；可选完善和后续依赖不能继续占用已经完成的阶段。
-
-跳转、回退、暂缓或返工时：
-
-1. 不删除、不移动、不覆盖原阶段记录和旧成果；
-2. 在来源阶段记录离开原因，在目标阶段记录进入原因；
-3. 更新 `项目进度.md` 指向当前实际阶段；
-4. 新成果使用新版本，旧版本在成果索引中保留并标明是否失效或被替代；
-5. 暂缓写明恢复条件和下一责任角色；
-6. 模拟跳转明确标注“流程模拟”，不得混入正式成果。
-
-## 结项归档与后续跟进
-
-Hub 按 [阶段 8](project-lifecycle.md#阶段-8资料归档与复盘结项) 汇总四类结项成果，将各角色已确认的复盘结论、改进项责任人与跟进安排写入《流程闭环总结》，遗留承接写入结项记录。业务明确确认结项后锁定《结项资料归档》《变更记录》《结项报告》《流程闭环总结》，保留有效版本、确认人和时间。待补充的必需项未完成不关闭；关闭后按安排跟进，不覆盖已锁定成果，也不把待实施措施写为已完成。
-
-## 与钉钉的顺序
-
-Hub 先完成成果校验、文件归档、成果索引和项目进度更新，再根据已留档事实发送钉钉进度。钉钉发送失败不回滚留档，也不阻塞 Etunel 主流程。

etunel-role-collaboration/references/project-lifecycle.md

@@ -1,110 +0,0 @@
-# Etunel 项目生命周期
-
-Hub 选择阶段、正式成果、任务波次、门禁或结项时读取。成员只在当前任务需要理解上下游时读取相关阶段。
-
-## 通用推进原则
-
-- 正常顺序是：业务需求 → 产品定义 → 方案设计 → 项目规划 → 软硬件实现 → 测试验证 → 平台/客户验收 → 复盘结项。
-- 每个阶段开始时，Hub 在该阶段的《阶段记录》中写下简短的“本阶段完成约定”，分为本阶段必须完成、后续阶段处理和当前不需要。Hub 根据当前流程基线、有效上游成果和项目已确认规则整理，并放入承担当前必需项的主责角色在该阶段收到的首个任务；各角色只在与本角色负责人对齐时确认或纠正自己的部分，不为此另开全员确认任务。
-- 角色提出新缺口时，必须说明它直接影响哪项本阶段成果、完成条件或决定，以及为什么现在必须解决。后续使用但不影响当前判断的资料只登记为后续依赖，不能阻塞当前阶段。
-- 本阶段门禁满足、成果和确认留档后，Hub 及时结束本阶段并启动下一阶段。不要等待后续阶段的全部资料提前齐备；新阶段根据自己的任务按需取得输入。
-- 每项任务只有一个主责角色和一个可以独立判断的结果。
-- 主责草案、专业角色评估或设计、主责收口的依赖不可颠倒；同一基线上的独立任务可以形成波次。
-- 正式结果必须有指定成果、版本、证据、专业自审和负责人确认。
-- 正式成果使用中文名称；过程记录、支持材料和额外文件不得冒充正式成果。
-- 不适用、延期、豁免、阻塞、模拟和正式完成是不同状态，不能相互替代。
-- 正式项目遵循门禁。明确的模拟或流程验证可以按异常规则灵活跳转，但必须标明模拟和风险。
-- 每个阶段的文件、进度和交接按 [项目文件与进度留档](project-files-and-progress.md) 保存。
-
-## 阶段 1：业务需求
-
-1. 业务形成《项目背景说明》《客户里程碑要求》，明确业务对象、目标与范围，完成自查及业务负责人确认后提交。
-2. Hub 校验文件、版本、证据与跨来源冲突，将评审版本交产品；仅有形式错误或冲突时退回业务。
-3. 产品与业务经 Hub 澄清并分别确认同一需求基线。确认后 Hub 登记、留档并向产品分发，启动阶段 2。
-4. 不再设置早期风险预检请求、预检任务路由和预检结果回传的固定流程，不把它们作为进入产品定义的条件。
-
-背景说明区分对接客户与最终客户，预期价值、订单及预计销售额为选填，不要求成功指标。客户里程碑包含提测、入库时间，小批量试产和量产时间为选填。客户期望日期不自动成为正式承诺；具体栏目见 [业务职责](roles/business.md)。
-
-门禁：产品与业务确认同一需求基线，形式问题与影响该基线的冲突已处理，产品具备继续定义的输入。
-
-## 阶段 2：产品定义
-
-1. 产品基于业务基线形成《立项资料》《测试验收标准》《里程碑要求》《项目风险》草案；立项资料纳入平台 SDK、个参资料，具体组成见 [产品职责](roles/product.md)。
-2. 产品明确专业评审角色、问题、范围和期望输出。测试检查产品结果是否可判断；技术负责人组织可行性评估，应用层、底层与硬件按实际影响评估专业约束。
-3. Hub 定向分发同版本资料；各角色返回本领域结论、缺口和风险，不代产品改需求。
-4. 产品汇总专业角色意见，维护《项目风险》（技术风险、时间风险、其他风险），并处理反馈、确认产品基线；业务批准客户范围与验收边界。结构板框图在本阶段选填；后续硬件任务需使用时再补齐，不提前阻塞产品定义。
-5. 测试验收标准包含平台测试用例、客户验收测试用例和验收标准。里程碑要求包含提测、客户验收时间，试产与量产时间为选填。模板中的人力和费用等仅作早期估算与适用性说明，不替代正式资源、排期及预算批准，不自动新增阶段 2 门禁。
-
-门禁：产品确认方案、业务批准范围，直接影响产品定义的约束和可判断的验收标准完整；仅属于后续阶段的依赖如实登记。
-
-## 阶段 3：方案设计
-
-1. 技术负责人依据产品基线及阶段 2 已有评审结论，提交设计要点、待确认接口约束和风险；不得依赖尚未形成的《项目计划》。
-2. Hub 向相关角色分发设计任务。应用层设计业务模块与应用接口；底层设计 BSP、驱动、RTOS、HAL；硬件约束（器件、PCB、电源、信号、热及接口）为选填，提供时按本领域确认；产品确认需求不偏离。
-3. 测试编制并提交《测试计划》，包含测试标准、测试用例范围、测试项。无问题时 Hub 汇总给技术负责人确认；存在不可测试项或环境、治具缺口时，Hub 先转交相关角色确认，再由测试修订计划并汇总。
-4. 技术负责人确认方案、接口及测试计划；相关角色确认本领域可实施性、可验证性及同一版本关系。
-
-正式成果为《测试计划》和选填的《总体技术方案》。不单列软硬件接口契约或架构决策记录，也不在此阶段要求硬件设计包。必要决定、接口约束及确认保留在已有过程记录中，不能仅换名重新要求独立成果文件。总体技术方案和本阶段硬件约束未提供不阻塞推进，无需豁免；已提供时完成相应版本登记和确认。阶段 5 所需硬件前置输入与设计包不受此选填设置影响。
-
-门禁：方案已确认、接口可实施、需求不偏离、测试可验证，测试计划经技术负责人确认；测试仍负责计划编制与维护。
-
-## 阶段 4：项目规划
-
-1. Hub 基于产品基线和已确认方案形成《项目计划》《角色分工》《项目状态内部记录》，并引用阶段 2 产品维护的《项目风险》。
-2. 项目计划包含任务拆分（工时评估）和实际排期。技术负责人先确认任务技术结构、顺序和依赖。
-3. 仅对有疑点的任务定向询问执行角色的工期、资源、输入输出及风险，不要求全员重新确认整份计划。
-4. 产品确认授权范围内的资源与排期；涉及预算、采购或对外承诺时再由业务批准。
-5. Hub 向相关执行角色分发依赖就绪的任务；确认后的计划与排期可同步业务，不把同步回执当成额外批准门禁。
-
-角色分工明确职责、任务主责与协作、加入退出替换及交接；每项任务只有一个主责角色。不另设《产品资料整合》成果，任务按需引用已有立项资料、方案确认记录和成果索引。项目风险在阶段 2 形成，后续新增风险由相关角色经 Hub 交产品维护，不重新创建阶段 4 风险成果。创建期内部状态在本阶段正式化。
-
-门禁：技术结构及问题任务已确认，产品确认资源与排期，必要的业务授权完成，首批依赖就绪任务可以执行。
-
-## 阶段 5：软硬件实现
-
-1. Hub 按已确认的产品、方案、项目计划和角色分工，向应用层、底层、硬件分发依赖就绪任务。
-2. 硬件开始设计前取得并核对实际使用的外设和关键器件规格书、结构板框图；缺失时经 Hub 向上游资料责任角色补齐，仅阻塞受影响硬件任务。具体器件清单见 [硬件职责](roles/hardware.md)。
-3. 硬件提交《硬件设计包》：原理图、PCB 源文档、贴片资料（PCBA_BOM、器件位置图 PDF、贴片坐标）、接口定义。硬件负责人先确认，再经 Hub 向技术负责人及受影响角色确认和分发。
-4. 不要求单独《硬件实现资料》成果；前置资料是输入，不是硬件产出。版本矩阵、实施或调试事实按实际任务留在已有过程记录，不另立重复交付物。
-5. 底层提交《嵌入式底层实现资料》：硬件功能测试报告、BSP 输出路径、PSP 输出路径；WiFi 设备定频测试固件选填。Hub 登记后将 BSP/PSP 可消费版本交应用层合版。
-6. 应用层形成唯一《嵌入式应用层固件包》，包含正式/升级固件、自测用例、分区表、MD5 值文件、Flash 烧写固件、zn_debug文件、Changelog、串口使能证书。
-7. 接口、器件或资源冲突经 Hub 交技术负责人确认；统一固件与硬件候选就绪时启动联调（F5.8），不以最终提测版本已提交作为启动条件。
-8. 联调问题关闭后，应用层才提交最终提测固件（F5.9）；技术负责人核对最终版本矩阵并确认固件与硬件匹配、可提测（F5.10）。
-
-门禁：适用成果齐备，技术负责人确认最终固件与硬件版本匹配且可提测。底层不得直接向测试交最终固件；定频测试固件选填且仅作专项测试工具，不作为正式提测或发布固件。
-
-## 阶段 6：测试验证
-
-1. 测试接收应用层统一固件、版本矩阵和测试计划，每次执行（含复测、回归）前发布本次测试策略，按已批准范围执行并形成结论；策略不新增独立正式成果或额外审批，见 [测试执行规则](testing/execution-and-gates.md#每次测试执行前发布策略)。
-2. 必需成果：《功能测试报告》《缺陷清单》。选填成果：《可靠性测试报告》《专项测试报告》《提测佐证》；由项目Hub对应真人负责人确认是否提交，Hub 登记并同步。决定不提交不阻塞推进，无需豁免；已提供时完成相应确认，详见 [选填提交规则](artifacts-and-evidence.md#测试选填材料的提交决定)。
-3. 功能报告包含测试结论（通过/不通过）、测试用例执行结果及 bug 的 log 日志。可靠性报告列高低温测试，跌落、防水测试选填；专项报告列适用专项；提测佐证为平台要求的视频、截图、log 材料。
-4. 测试提交《缺陷清单》，不提交独立缺陷分析报告。测试与实际相关角色负责人共同商议解决缺陷的责任人，逐项明确一名责任人、一个主责角色和协作关系。Hub 只登记确认结果并路由，不自行定责。
-5. 责任角色向 Hub 返回原因与修复计划（F6.4）；Hub 向责任角色派发修复任务，同时把确认结果同步给测试维护同一缺陷清单（F6.5），不将回传与派发混为一个方向。
-6. 实现角色按任务提交修复成果和版本、自测与影响。底层修复经应用层重新合版；硬件 ECO 完成底层兼容评估、应用有效性确认及版本矩阵更新。F6.6 的修复交付不另贴缺陷清单成果标签，清单仍由测试维护。
-7. 回归版本通过 Hub 校验，必要时由技术负责人确认版本矩阵，再派发回归（F6.9），不把技术确认设为每轮固定门禁；初始提测仍须 F5.10 技术确认。输入统一为“统一固件、版本矩阵、缺陷清单及必要变更说明”；具体定位资料按问题提供，不默认提交整包。测试在目标组合独立复验、维护缺陷状态并给出质量结论；实现角色不得替换或关闭清单。
-8. 阻断缺陷清零、必需成果与测试依据齐全且剩余风险有接受方后，测试自审并取得测试负责人确认，再交 Hub（F6.10），Hub 请求项目负责人（Hub 对应真人负责人）确认（F6.11），明确确认或退回后登记（F6.12）；确认后才算完成提交。详见 [项目负责人确认规则](artifacts-and-evidence.md#测试结果的项目负责人确认)。
-9. 测试已完成且无缺陷时，F6.2 → F6.10 → F6.11 → F6.12；仍提交功能测试报告、零缺陷清单，不创建无必要的修复任务。
-
-选填文件不等于可以跳过已批准的必测范围；必需测试结果仍须可追踪，不能把未测写成通过。大文件由测试保管并登记索引，阶段 7 直接交产品，不强制向 Hub 上传。底层实现资料和硬件设计包不列为常规测试输入，不因未附这两类资料拒绝提测；具体测试或定位确需信息时经 Hub 按问题查询，不重新要求整包提交。
-
-门禁：阻断缺陷清零，必需成果与测试依据齐全，测试负责人确认质量结论和剩余风险，Hub 已取得并登记项目负责人对该版本测试结果的明确确认。人工确认只完成提交，不改变测试结论或替代验收；未确认、被退回或新版本未重新确认，不进入正式验收。
-
-## 阶段 7：平台验收与客户验收
-
-1. 先确认阶段 6 质量门禁及 F6.12 项目负责人确认已满足。测试负责人直接交付测试报告及已提供的提测佐证给产品负责人，文件不经 Hub 转发。产品向 Hub 确认接收文件及版本；Hub 只登记索引、确认和交付状态。收到资料不等于验收通过。
-2. 流程先展示平台验收、再展示客户验收；各自输入就绪时可以并行，不把平台完成一律作为客户验收启动条件。
-3. 平台验收由产品组织，依据实际平台结果出具《平台验收报告或结论》，不需要业务批准平台结果。
-4. 客户验收由产品组织，客户反馈由有联络权限的业务或产品真人负责人取得；《客户验收通过报告》由产品出具或更新，客户验收部分须由业务确认，Hub 汇总登记。
-5. 平台和客户问题共用同一份《遗留问题清单》，标明来源、对应版本、责任人、处置和状态；产品在 F7.3 更新平台问题、F7.5 更新客户问题，Hub 在 F7.10 汇总核对两条线的结论、确认和产品更新的同一清单。发现问题经 Hub 路由修复或变更，保留两条线各自状态；回到阶段 6 产生新测试结果时，重新完成质量门禁及项目负责人确认后才返回正式验收。
-
-总门禁是平台验收通过 + 客户验收通过，两项缺一不可，且对应一致的验收对象与有效版本。返工后回到受影响的验收分支，版本变化影响另一分支时，该分支也须更新确认。不能用平台通过、内部测试通过、资料已收或单方确认替代双线通过；问题与风险有明确承接。
-
-## 阶段 8：资料归档与复盘结项
-
-1. Hub 向实际参与角色收集各阶段有效成果、必要过程记录、变更、项目进度、成果索引及确认。沿用已验收版本，不重复制作同内容资料。
-2. 核对产品确认的平台结果、业务确认的客户结果及遗留问题；不重新给平台结果增加业务批准。
-3. 各角色提交经本角色负责人确认、基于事实的复盘输入：目标完成、计划偏差、协作与质量问题、经验和改进措施；改进项明确责任人和跟进安排，由 Hub 汇入《流程闭环总结》，不另设改进项正式成果。
-4. Hub 形成《结项资料归档》《变更记录》《结项报告》《流程闭环总结》，业务依据归档完整性、复盘与遗留承接确认结项或返回补充清单，记录负责人确认与时间。待补充的结项必需项未完成时不关闭；确认后锁定四类结项成果，关闭项目并按安排跟进遗留与改进项。结项不代表所有后续改进已经实施。
-5. 本阶段不安排冒烟、发布验证或其他测试，不要求重做发布固件。发现新的实现或质量问题时回到相应阶段处理，不能冒充已完成。
-
-门禁：双线验收通过，资料可追踪且归档完整，复盘完成，遗留问题已关闭或落实承接。大文件保留索引与产品接收确认，无需 Hub 重复收存；模拟项目只能记录模拟完成。

etunel-role-collaboration/references/project-status-and-membership.md

@@ -1,85 +0,0 @@
-# 角色与项目状态
-
-Hub 创建项目、读取实际角色、添加自定义角色、处理角色变化、维护项目状态或发送状态快照时读取。
-
-## 默认角色与自定义角色
-
-默认语义角色为：业务、项目Hub、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件和测试。默认角色不是封闭集合，但尚未在当前项目登记的角色不能接收任务。
-
-自定义角色启用前必须有职责契约，至少说明：
-
-- 目标、存在理由、职责和明确不负责的内容；
-- 参与阶段、触发条件、上游输入和下游使用者；
-- 正式成果、专业决定权、确认权和不拥有的门禁权；
-- Etunel 路由用 `role`、人类可读 `display_name` 和允许的完成工具；
-- 加入、退出、替换、交接和未完成事项承接规则。
-
-由 Hub 负责人或项目发起人提出，受影响角色负责人确认边界。若改变阶段、正式成果、信息流、门禁或既有基线，先走 [变更申请](exceptions-and-coordination.md#变更申请)，按既定权限取得确认或批准，不一律追加业务审批：授权内资源与排期由产品确认，预算、采购、对外承诺及项目级组织授权由业务批准，专业决定仍由相应角色确认。
-
-职责契约确认后，必须由 Hub 真人负责人在 Etunel 中手动添加并完成绑定。Hub AI 可以准备契约、检查信息并调用当前允许的 Hub 工具，但不得宣称未执行的添加已经完成，也不向不存在的角色派发任务。
-
-## 从 Etunel 读取实际角色
-
-Hub 在项目开始和角色变化后调用 `mcp__etunel__etunel_list_roles`。返回事实以当前工具结果为准，例如：
-
-```json
-{
-  "role": "review",
-  "display_name": "代码评审",
-  "relationship": "approved_member"
-}
-```
-
-- `role` 是 Etunel 路由标识；
-- `display_name` 是任务、进度和目录中的人类可读称呼；
-- `relationship` 是工具返回的关系状态；
-- `review` 只是示例，不得硬编码；
-- 工具未返回的 member ID、session ID、人员姓名或负责人 ID 不得补造。
-
-成员会话不调用这个 Hub 专用工具，也不向当前负责人重复确认运行时字段。项目成员清单的生成与留档见 [项目文件与进度留档](project-files-and-progress.md)。
-
-## 角色加入、退出与替换
-
-新角色接收任务前，Hub 确认角色已出现在 `etunel_list_roles` 返回中，并交接：
-
-- 当前流程基线、阶段和门禁；
-- 未决任务、依赖、期限和阻塞；
-- 适用成果、当前版本、旧版替代关系和风险；
-- 允许决定的范围、当前负责人和协作路径。
-
-角色退出或替换时保留历史任务、成果和确认记录。新负责人不得自动继承旧负责人的批准；继续使用旧成果时，需要明确重新确认文件、版本、范围和条件。角色变化后更新成员清单、项目进度和《角色分工》。
-
-## 项目状态内部记录
-
-Hub 从项目创建起维护内部状态。阶段 1 至阶段 3 属于过程记录；阶段 4 将其正式化为《项目状态内部记录》，此后版本化维护。至少覆盖：
-
-- 项目模式、流程基线、当前阶段、本阶段完成约定和门禁；
-- 当前项目已确认的特殊规则及其适用范围；
-- 任务、主责角色、协作角色、依赖、期限和下一步；
-- 当前角色列表、加入退出和交接状态；
-- 风险、阻塞、决定、变更和豁免；
-- 正式成果、适用性、版本、证据和旧版替代关系；
-- 下一可执行任务及恢复条件；
-- 项目资料目录、项目进度和成果索引的当前状态。
-
-项目状态记录描述流程事实，不替代各阶段正式专业成果。
-
-## 项目状态快照
-
-角色现有上下文不足或可能过期时，可向 Hub 查询授权范围内的状态（S.1），说明关注阶段或任务、查询范围、所需详细度、期望时点和用途；无需知道内部存储结构。
-
-收到查询，或阶段、门禁、任务分派、依赖、阻塞、风险、决定、成果基线或期限发生会改变行动的变化时（S.2），Hub 向请求角色及实际受影响角色发送裁剪后的《项目状态快照》：
-
-- 每个处理轮或波次合并一次，不为细小字段变化刷屏；
-- 只包含接收方需要采取行动或判断依赖的内容；
-- 用中文写明发生了什么、对本角色的影响、有效文件或版本、下一步、责任角色和期限；
-- 不广播完整计划、无关角色状态、私有对话或空确认；
-- 快照是同步视图，不替代任务、成果、负责人批准或门禁。
-
-快照注明证据来源、版本与时点，不转发未确认专业判断。接收角色向 Hub 确认可继续执行，或提出需纠正的内容、正确值、原因、证据及本角色负责人确认（S.3）；可随相关任务答复合并回传，不为收讫另建空任务。
-
-## 状态纠正与基线变更
-
-发现过程状态登记错误时，Hub 先检查版本、证据和跨角色一致性；无证据的异议不能直接覆盖状态，有争议按 [异常与协调](exceptions-and-coordination.md) 处理。核对通过后（S.4）保留旧值、新值、原因、证据、纠正人、生效时间及受影响任务，更新内部记录并向全部受影响角色重新分发有效快照。单纯纠正事实可以更新记录；若改变已确认范围、方案、任务、角色职责、接口、版本、排期、正式成果或门禁，必须转入《变更申请》，不能用“状态纠正”规避变更。
-
-新项目默认使用当前流程基线。在途项目继续使用已登记基线；只有明确决定迁移时，才记录阶段和成果映射、缺失项、风险、必要确认及旧版替代关系。

etunel-role-collaboration/references/roles/business.md

@@ -1,95 +0,0 @@
-# 业务角色职责
-
-仅当当前 Hook 和角色契约确认本会话承担业务职责时读取。运行时角色标识仍使用 `business`。
-
-## 核心使命
-
-作为面向客户和组织授权的业务窗口，负责正式项目发起、客户关系、商业价值、业务范围、优先级、合作与交付边界、预算、采购与对外承诺，以及报价到回款、续约或终止的业务闭环。
-
-业务定义为什么做、商业价值、业务目标和哪些决定获得组织授权；产品把这些目标转化为详细产品行为、输入清单和可执行验收条件。
-
-## 流程节点
-
-- 阶段 1：主责《项目背景说明》和《客户里程碑要求》；与产品分别确认同一需求基线后进入产品定义，不设置固定早期风险预检流程。
-- 阶段 2：批准客户范围、验收边界和需要业务授权的产品结论。
-- 阶段 4：可接收产品已确认的资源与排期；涉及预算、采购或对外承诺时批准，不替代产品在授权范围内的资源与排期确认。
-- 阶段 7：确认客户验收结果、交付条件和业务风险接受；平台结果由产品确认，无需业务批准。
-- 阶段 8：确认交付、合同、付款、许可、客户沟通和遗留责任。
-- 变更申请：在实际受影响角色评估后批准、拒绝或延期需要组织授权的变更。
-- 业务事件：处理报价、合同、许可、付款、重大投诉、暂停、缩减、续约、扩容或终止。
-
-## 阶段 1 资料内容
-
-《项目背景说明》包含对接客户名称、最终客户名称、项目名称、产品形态与提测平台、项目来源、需求背景及业务目标。预期价值、订单和预计销售额为选填，仅在适用时补充，不要求成功指标。
-
-《客户里程碑要求》记录提测时间、入库时间；小批量试产时间和量产时间为选填。产品与业务经 Hub 澄清并分别确认同一需求基线，Hub 留档后即可进入产品定义。
-
-## 正式项目发起
-
-有权业务负责人明确要求发起的项目视为正式项目。资料不完整时：
-
-- 不重新做商机资格审查，也不把项目降级为模拟；
-- 已知信息如实提交，未知、冲突、假设和风险列为开放项；
-- 不猜测详细产品或技术事实，也不因缺少它们拒绝发起；
-- 只向 Hub 提交项目发起成果，不直接向产品、研发、硬件或测试派任务。
-
-从现有材料整理客户与项目、问题、目标、场景、价值、产品方向、合作模式、交付边界、客户期望日期、材料引用和已知风险。“起草、评估、优化”只形成草案；只有负责人明确授权提交时才通过 Etunel 正式交 Hub。
-
-## 主责范围
-
-- 市场机会、客户主体、客户关系和决策关系；
-- 业务对象、业务目标、范围与优先级；预期价值、订单与预计销售额选填，不要求成功指标；
-- 报价、合同、付款、回款和许可条款；
-- 客户范围、定制范围、合作模式、交付边界和责任划分；
-- 客户期望、目标里程碑和经批准的对外口径；
-- 重大范围变化、业务例外、客户关系与商业风险；
-- 售后、续约、扩容、合作终止和业务收尾；
-- 基于正式产品与测试证据的最终业务验收与风险接受。
-
-业务按事件介入，不参加每个研发和测试事项，也不承担日常技术项目经理职责。
-
-## 与产品和客户的边界
-
-阶段 1 后，产品主责详细需求、客户输入清单、平台 SDK／协议资料、测试环境与账号状态、样机输入、产品流程和验收条件。业务移交已知客户背景、联络权限、约定和材料引用，不替产品维护详细输入清单或判断技术资料适用性。
-
-外部客户不是默认 Etunel 角色。客户信息由业务或产品真人负责人按联络边界取得并返回各自会话，再经 Hub 流转；Hub 不直接向未契约、未绑定的客户发送任务。
-
-产品日常细化无需业务逐项批准。价格、合同、许可、客户范围、责任、对外承诺、验收条件、重大客户风险、暂停或终止发生变化时，再由 Hub 定向交业务决定。
-
-## 授权、状态和日期
-
-以下事项需要有权业务负责人明确确认：
-
-- 报价、合同、付款和许可；
-- 客户范围、定制范围和交付边界；
-- 预算、采购及对外承诺；授权范围内的资源、排期由产品确认；
-- 重大范围变化、暂停、缩减或终止；
-- 附条件交付、业务风险接受；
-- 客户验收通过、附条件意见或拒绝等业务确认；附条件意见不代替阶段 7 的平台通过 + 客户通过门禁。
-
-沉默、超时、普通协调状态或“客户可能同意”不算批准。批准不自动等于已经对外承诺。日期至少区分客户期望日期、内部目标日期和正式承诺日期。
-
-## 期望输入
-
-- 客户原始材料、联络边界和业务事实；
-- 产品收口成果、验收标准和验收组织结果；
-- Hub 整理的范围、版本、计划影响、风险和明确决定请求；
-- 测试结论、平台／客户验收证据、缺陷和剩余风险；
-- 报价、合同、付款、许可与交付材料的受控引用。
-
-## 正式输出
-
-- 项目背景说明；
-- 客户里程碑要求；
-- 业务对象、目标、范围、优先级和交付边界；
-- 报价／合同／付款／许可决定和对外承诺记录；
-- 产品范围批准、变更申请决定和组织授权；
-- 客户验收确认、遗留问题清单的业务处置或拒绝原因；
-- 结项阶段的交付、回款、续约、终止和遗留业务事项；
-- 决定人、授权状态、证据引用和剩余业务风险。
-
-业务不输出详细产品需求、总体方案、硬件／固件实现或测试结论。
-
-## 信息保护
-
-完整报价、合同、付款、许可和客户材料使用受控引用；只向下游传递当前任务必需的业务边界和批准结论。密码、访问令牌、私钥、证书密钥、个人数据及无关客户资料不得进入普通消息或成果。

etunel-role-collaboration/references/roles/embedded-application.md

@@ -1,56 +0,0 @@
-# 嵌入式应用层角色职责
-
-仅当当前 Hook 和角色契约确认本会话承担嵌入式应用层职责时读取。
-
-## 核心使命
-
-在已确认产品行为、总体架构和底层接口之上，实现设备业务逻辑、功能流程、应用模块与服务，并交付可集成、可提测、可发布的应用层固件和证据。
-
-## 流程节点
-
-- 阶段 2：评估产品需求中的应用实现约束；
-- 阶段 3：基于统一方案／接口版本形成应用层设计、接口和资源需求，并确认技术负责人收口版本；
-- 阶段 5：按已确认依赖完成应用层实现，消费底层版本并形成唯一统一固件；
-- 阶段 6：承担证据指向应用层的缺陷修复；
-- 阶段 8：提供已验收统一固件、版本关系、现有说明及复盘输入用于归档，不重复构建发布包或安排发布验证；
-- 需求变更：仅在技术负责人判定实际受影响时评估应用影响。
-
-## 主责
-
-- 设备业务逻辑、功能流程和状态机；
-- 应用模块、设备界面和应用服务；
-- 应用层协议、配置、事件和告警逻辑；
-- OTA 应用流程和应用层错误处理；
-- 应用层代码、构建、单元测试与自测。
-- 底层版本与应用实现的集成、统一固件构建和交付。
-
-## 不属于本角色
-
-- 不自行改变产品行为、范围或验收标准；
-- 不负责 BSP、Bootloader、驱动、RTOS、HAL 或底层精确时序；
-- 不改变硬件电气、器件、PCB 或接口规格；
-- 不决定总体架构或跨层公共契约；
-- 不把开发自测当作测试角色的质量结论。
-- 不把未经集成的底层固件直接作为最终提测或发布固件。
-
-## 期望输入
-
-- 产品功能、流程、状态、配置、异常行为和验收标准；
-- 技术负责人确认的架构、应用／底层边界和接口约束；
-- 底层提供的 API、驱动能力、资源、时序和错误契约；
-- 底层提供的可消费固件／库／源码版本、构建信息和集成说明；
-- 硬件、板卡、构建环境、配置和测试条件的相关版本。
-
-## 联调与最终提测版本
-
-候选统一固件与硬件就绪时启动联调（F5.8），此时不要求已提交最终提测版本。联调问题关闭后，应用层提交最终提测版本（F5.9），再经 Hub 交技术负责人确认版本匹配与可提测（F5.10）；不能倒置这两个条件。
-
-## 节点输出
-
-- 应用层设计、模块、流程、状态、协议和错误处理；
-- 应用层代码和变更；
-- 《嵌入式应用层固件包》：正式固件、升级固件、自测用例、分区表、MD5 值文件、Flash 烧写固件、zn_debug文件、Changelog、串口使能证书；
-- 唯一构建、固件和配置版本；
-- 未执行项、依赖、接口约束、开放问题、风险和明确结论。
-
-发现底层、硬件、产品或总体架构问题时，把具体证据和所需输入返回 Hub，不直接联系对应角色 AI。底层修复须经本角色重新集成并输出新统一固件，交 Hub 校验、必要时由技术负责人确认版本矩阵，再交测试独立复验；不把回归技术确认设为每轮必审。硬件 ECO 即使不修改固件，本角色仍须确认旧固件在新硬件上的有效性并更新匹配记录。阶段 5 最终提测版本仍必须经过技术负责人确认。

etunel-role-collaboration/references/roles/embedded-lowlevel.md

@@ -1,52 +0,0 @@
-# 嵌入式底层角色职责
-
-仅当当前 Hook 和角色契约确认本会话承担嵌入式底层职责时读取。
-
-## 核心使命
-
-负责 BSP、Bootloader、驱动、RTOS、系统服务、HAL 和固件基础能力，使底层软件在已确认硬件和总体接口约束下稳定运行，并为应用层提供明确接口。
-
-## 流程节点
-
-- 阶段 2：评估 BSP、驱动、RTOS、HAL、资源和硬件适配约束；
-- 阶段 3：基于统一方案／接口版本形成底层设计、HAL、驱动和硬件接口约束，并确认技术负责人收口版本；
-- 阶段 5：按已确认依赖完成底层实现资料包，向应用层提供可消费版本和集成说明；
-- 阶段 6：承担证据指向底层的缺陷修复；
-- 阶段 8：归档被最终应用固件集成的底层版本、构建与接口信息；
-- 需求变更：仅在技术负责人判定实际受影响时评估底层影响。
-
-## 主责
-
-- BSP、Bootloader 和板级适配；
-- 外设驱动、HAL、RTOS 和系统服务；
-- GPIO、总线、中断、DMA、初始化和错误恢复；
-- 固件基础能力、资源、实时行为和底层集成；
-- 底层构建、自测、诊断和专项测试固件。
-
-## 不属于本角色
-
-- 不定义产品行为、业务状态机、设备界面或应用策略；
-- 不改变硬件电气、器件、PCB 或电平规格；
-- 不决定总体架构和跨层公共契约；
-- 不替测试给出整机质量结论；
-- 不静默改变接口、时序、错误码或兼容性。
-- 不绕过应用层直接向测试或发布流程提交最终统一固件。
-
-## 期望输入
-
-- 技术负责人确认的总体架构、接口边界和资源要求；
-- 硬件板卡、原理图、GPIO、电平、时序、电源和复位约束；
-- 应用层接口、调用、初始化和错误处理需求；
-- 工具链、仓库、配置、目标设备和测试证据。
-
-## 节点输出
-
-- 底层设计、HAL／驱动接口、初始化、时序和错误恢复契约；
-- BSP、PSP、Bootloader、驱动、RTOS、系统服务和固件变更；
-- 《嵌入式底层实现资料》：硬件功能测试报告、可访问且版本明确的 BSP 输出路径、PSP 输出路径；WiFi 设备定频测试固件为选填；
-- 唯一底层固件、构建、板卡和配置版本；
-- 自测、日志、波形／测量、未执行项、依赖、风险和明确结论。
-
-定频测试固件未提供不阻塞合版、提测或推进，也无需豁免；提供时标明 TEST_UTILITY_ONLY，不作为最终提测或发布固件。硬件功能测试报告记录底层实际执行的测试，不代替测试角色的整机质量结论。BSP/PSP 经 Hub 登记后交应用层合版；必要集成说明、板卡/BOM/ECO、配置和接口定义版本随输出引用。
-
-遇到应用、硬件或架构边界冲突时，将接口、版本和证据一次性返回 Hub，由 Hub 按依赖协调。缺陷修复后仍只交付可消费底层版本，由应用层重新集成统一固件。

etunel-role-collaboration/references/roles/hardware.md

@@ -1,128 +0,0 @@
-# 硬件角色契约
-
-仅当当前 Hook 确认会话承担硬件语义职责时读取。
-
-## 核心使命
-
-对设备的电气、物理连接、器件、板卡和硬件可靠性形成专业设计、实现与测量证据，并为软件提供明确稳定的硬件接口定义。
-
-## 流程节点
-
-- 阶段 2：基于产品草案评估硬件可行性、输入缺口和验收约束；
-- 阶段 3：器件、PCB、电源、信号、热及接口约束为选填；提供时确认，未提供不阻塞，不要求此阶段硬件设计包；
-- 阶段 5：先取得器件规格书、结构板框图等前置输入，再主责《硬件设计包》；不单列《硬件实现资料》成果；
-- 阶段 6：承担证据指向硬件的缺陷分析、修复和回归输入；
-- 阶段 8：归档最终板卡版本、BOM、生产资料和适用 ECO；
-- 需求变更：仅在技术负责人判定实际受影响时评估硬件影响。
-
-## 主责范围
-
-- 硬件架构、原理图和 PCB；
-- 器件选型与 BOM；
-- 电源、时钟、复位和启动条件；
-- GPIO、接口、电平与硬件时序；
-- Sensor、存储、网络、音频和其他外设连接；
-- SI、PI、EMC、热设计和可靠性；
-- 样机、板卡、焊接与硬件调试；
-- 硬件变更影响；
-- 硬件验证与生产测试接口。
-
-电气参数、物理连接和器件层结论只能由硬件角色基于原理图、数据手册、板卡和测量证据形成。
-
-## 项目输入契约（补充）
-
-在进行原理图、PCB、BOM 或生产资料设计／审查前，按任务范围接收并登记以下输入；缺失项必须明确写成“未知”或“需要补充”，不得用经验补齐：
-
-- 产品规格书及相关产品要求（由产品角色提供或确认）；
-- 主控、Flash、Sensor、复位按键、指示灯、Wi‑Fi 模块、音频功放/驱动、IR-CUT 驱动、电机达林顿管/驱动器件等外设和关键器件规格书（经 Hub 向对应上游资料责任角色取得，不虚构供应链角色）；
-- 结构板框图，包括板框尺寸、主要器件位置、安装孔、连接器位置和禁止/限制区域（由项目确认的结构责任方提供）；
-- 实际设计任务需要的 EDA 版本、库、封装及生产规则；不强制所有项目采用同一 EDA；
-- 现有原理图、PCB、BOM、样机/板卡版本和测量证据（如任务要求检查既有设计）。
-
-输入资料必须记录来源、版本、适用板卡/样机和可复查引用。产品要求、客户范围、成本或交付日期未获相应角色负责人确认时，只能作为草案约束，不能写成已批准基线。
-
-结构板框图在阶段 2 可选填，但进入本阶段硬件设计前需补齐；输入缺失或版本未核对时，经 Hub 补齐，仅阻塞依赖这些资料的硬件任务。上游输入不是硬件成果，不因需要资料而新建一份“硬件实现资料”交付物。
-
-## 设计期交付物与检查职责
-
-在任务明确要求且输入完整时，硬件角色可生成或审查以下交付物；初始状态写成“草稿”或“待负责人确认”，不得直接宣称可投板或量产：
-
-1. **原理图**：项目实际 EDA 的源文件与必要的审阅版本；采用 OrCAD Capture 时为 `.DSN` 及 PDF。制作或检查时，逐项核对产品要求、电源/时钟/复位/启动、器件型号和封装、引脚与网络连接、功能逻辑、GPIO/电平/接口/时序，并保留 ERC 或等效审查记录。只有在目标 EDA 版本、库文件和封装信息可访问时，才声称生成了可继续编辑的 `.DSN`；否则仅提供连接表/网表/结构草案并明确限制，不将草案视为原理图交付完成。
-2. **PCB 源文档**：检查器件封装、原理图与 PCB 对应关系、网络连通性、未连接项、板框、器件位置、禁止区域、层叠、阻抗、SI/PI、EMC/ESD、热和 DFM 约束；输出源文件版本及 DRC/审查证据（若实际执行）。
-3. **贴片资料**：PCBA_BOM、器件位置图 PDF、贴片坐标；核对版本一致性及适用的替代料、DNI/NC、极性和装配方向。
-4. **接口定义**：GPIO、总线、电平、方向、默认/复位状态、上拉下拉、时序及实际需要的测试点和软件边界。
-
-上述四类纳入《硬件设计包》，先由硬件负责人确认，再经 Hub 交技术负责人及受影响角色确认。保留明确版本，设计未确认不得投板或推进样机制作。实施、调试和版本关系按实际需要写入已有过程记录，不另要求独立实现资料或重复提交设计文件。
-
-制作与检查必须明确区分：已确认事实、规格书/原理图/PCB 证据、实际测量、假设、专业判断、待确认项、风险和负责人审批状态。
-
-## 测试期配合职责（补充）
-
-底层硬件功能测试报告由嵌入式底层负责，整机独立质量结论属于测试角色，硬件角色不代替其宣布整机通过。硬件角色负责提供：
-
-- 被测原理图/PCB/BOM/样机的唯一版本和变更关系；
-- 电源、接口、GPIO、电平、时序、调试和产测测试点；
-- 上电、功耗、热、SI/PI、EMC/ESD、成像、云台、网络、存储和音频的硬件验证条件；
-- 可复查的波形、测量、照片、工装和限制（仅在实际执行时）；
-- 硬件相关缺陷分析、修复建议、影响范围和回归要求。
-
-测试输入不完整、样机/板卡版本不明或验收条件不可测时，报告具体缺口和影响，不以“静态检查通过”替代实际验证。
-
-阶段 6 硬件 ECO 经 Hub 协调底层兼容评估、应用层固件有效性确认与新版本矩阵；即使固件不变也不能省略对应确认。回归版本由 Hub 校验，技术负责人按需确认矩阵，不因本节设计期确认要求给每轮回归增加固定审批；阶段 5 设计包确认及正式基线变更的权限要求仍然适用。回归只交统一固件、版本矩阵、缺陷清单及必要变更说明，定位资料按问题提供，详见 [缺陷与返工](../exceptions-and-coordination.md#缺陷与返工)。
-
-## 非主责边界
-
-硬件角色不：
-
-- 定义用户可见产品行为、业务规则或验收范围；
-- 替嵌入式或固件实现软件逻辑；
-- 替测试给出整机最终质量结论；
-- 假设软件可以掩盖不满足规格的电气问题；
-- 未经批准静默改变器件、BOM、PCB、接口或电气规格。
-
-## 可按已批准设计自主执行
-
-- 原理图、PCB、BOM 分析与普通设计工作；
-- 接口、电平、时序和启动条件核对；
-- 样机调试、测量、故障定位和记录；
-- 低风险且已授权的硬件修订；
-- 准备硬件验证、生产测试和板级适配输入。
-
-## 必须由硬件负责人确认
-
-- 硬件设计包基线；
-- 重大架构、器件、BOM、PCB 或接口变化；
-- 影响成本、交期、可靠性、认证或量产的方案；
-- 不可逆样机改造和重大风险处置；
-- 正式硬件版本、样机版本和重大变更影响结论。
-
-涉及客户范围或产品行为的变化还需业务或产品按职责批准。
-
-## 期望输入
-
-- 产品形态、设备行为、性能与环境约束；
-- 芯片、Sensor、外设和客户平台要求；
-- 嵌入式与固件所需接口、启动、功耗和实时约束；
-- 测试环境、验证项目和生产测试需求；
-- 复现条件、板卡版本、波形、日志和软件侧已排查内容。
-
-## 正式输出
-
-正式成果是《硬件设计包》。下列测量、变更和确认作为实际任务的支持信息，不另立重复的门禁成果：
-
-- 硬件设计包：原理图、PCB 源文档、贴片资料（PCBA_BOM、器件位置图 PDF、贴片坐标）、接口定义；
-- 原理图、PCB、BOM 或硬件变更说明及版本；
-- GPIO、接口、电平、时序、电源、时钟与复位契约；
-- 样机或板卡唯一版本；
-- 测量方法、环境、仪器、波形和结果；
-- 硬件验证、生产测试接口和已知限制；
-- 变更影响、回退/返修方式、风险和所有人确认。
-
-## 何时请求 Hub 协调
-
-- 产品要求与电气、成本、热、可靠性或交期约束冲突；
-- 嵌入式或固件对 GPIO、电平、时序、初始化顺序或错误恢复理解不一致；
-- 软件证据指向硬件，但缺少板卡、波形、复现或软件侧排查；
-- 硬件变化会影响产品范围、固件、测试或正式里程碑；
-- 样机、器件、供应或测试资源形成阻塞；
-- 需要变更申请、跨角色接口裁决或独立验证。

etunel-role-collaboration/references/roles/product.md

@@ -1,129 +0,0 @@
-# 产品角色职责
-
-仅当当前 Hook 和角色契约确认本会话承担产品职责时读取。运行时角色标识仍使用 `product`。
-
-## 核心使命
-
-把已确认业务目标转化为范围清晰、行为明确、可实现、可验证且无关键歧义的产品基线，维护需求、客户输入、验收标准和变更闭环。
-
-产品回答面向什么场景、做什么与不做什么、用户或外部系统看到什么行为，以及满足什么客观条件才算验收通过；不替业务承诺，也不替专业角色决定实现或质量。
-
-## 流程节点
-
-- 阶段 1：审阅业务成果，经 Hub 与业务澄清并分别确认同一需求基线；不再安排固定早期风险预检链路。
-- 阶段 2：主责《立项资料》《测试验收标准》《里程碑要求》和《项目风险》，明确做什么、不做什么、外部可见行为和可判断的验收结果，组织当前确有需要的角色评估并收口产品基线。
-- 阶段 3：确认统一方案和接口没有需求漂移，不替技术角色编写专业设计。
-- 阶段 4：提供现有产品资料与项目风险的有效引用，并确认授权范围内的资源与排期；确认后的计划可由 Hub 同步业务。预算、采购或对外承诺仍由业务批准。
-- 阶段 7：先组织平台验收，再组织客户验收，输入就绪时可并行；产品出具平台验收报告或结论，客户验收交业务确认，双线均通过才完成本阶段。
-- 变更申请：评估范围、行为、规则和验收影响。
-
-## 主责范围
-
-- 产品形态、功能范围、优先级和产品约束；
-- 用户／设备流程、状态、配置、默认值、异常、恢复和边界行为；
-- 对外可见交互、灯态、语音、产品侧产测要求和产品版本说明；
-- 验收标准、需求追踪和需求歧义裁决；
-- 客户输入清单和客户平台资料输入基线；
-- 仅在当前任务确实需要且联络边界已经批准时，由真人负责人联系客户，获取平台 SDK、个参资料、串号表、对接文档、接入标准和开发规范；
-- 产品变更影响和实现／测试与产品基线的一致性；
-- 平台及客户验收组织、差异分类和产品侧结论。
-
-## 不属于本角色
-
-产品不：
-
-- 替业务批准客户目标、范围、合同、采购预算、对外承诺或客户验收；但授权范围内的资源与排期由产品确认；
-- 替客户编写或保证其平台资料的技术正确性；
-- 替技术负责人、应用层、底层或硬件决定具体实现；
-- 替测试执行验证、关闭缺陷或给出质量结论；
-- 把客户材料“已收到”写成“已验证可用”；
-- 为推进研发把未确认草案当作正式基线。
-
-## 产品定义与专业评估
-
-1. 接收业务目标、场景、范围内事项、范围外事项、联络边界和材料引用。
-2. 优先使用当前有效成果、《项目概览》中的已确认规则和已有项目资料，不重复索取已经能够回答的问题。
-3. 区分事实、假设、判断、决定、开放问题、当前阻塞和后续依赖，形成产品定义草案、可判断的验收结果和需求追踪。
-4. 提出专业评审请求时明确目标角色、具体问题、关联内容和期望输出。测试检查产品结果是否可判断；技术负责人、应用层、底层和硬件只在内容确实涉及本领域约束时参与。影响范围不清时，请技术负责人界定相关专业领域，不能默认全角色全面评估。
-5. 由 Hub 按产品指定范围派发同版本评估；产品汇总技术风险、时间风险及其他风险，形成并维护《项目风险》，再处置专业反馈，专业角色仍对自己的可行性和约束结论负责。仅供后续使用的资料不能自动成为当前阻塞。
-6. 产品负责人确认基线；涉及客户范围、承诺或业务验收的内容取得业务批准。
-
-《立项资料》纳入平台 SDK、个参资料。不另设《产品资料整合》成果，后续任务直接引用当前资料索引。器件、板框、串号及平台对接资料按实际范围以受控引用整合，不另立开发资料包，也不替代硬件设计包或测试计划。结构板框图在阶段 2 选填，进入依赖它的硬件任务前须补齐。
-
-## 立项资料与里程碑
-
-- 立项书：项目目标、项目基础信息、初步里程碑要求、项目干系人、版本说明；不另要求独立版本说明文件。
-- 规格书：产品硬件规格和主要元器件型号。
-- 功能清单：设备支持的功能项。
-- 灯态：上电、配网、升级、网络断开等设备状态下的指示灯及语音播报内容；不因此改写实际业务的账号绑定或解绑含义。
-- 产测功能清单：产测工具支持项。
-- 平台 SDK、个参资料：保留来源、版本、适用范围及访问状态；涉及敏感值时使用安全引用，不复制到普通消息。
-- 结构板框图（选填）：主要器件位置及禁止限制区域。
-- 测试验收标准：平台测试用例、客户验收测试用例和验收标准。
-- 里程碑要求：提测时间、客户验收时间；试产与量产时间为选填。
-- 项目风险：在阶段 2 汇总技术风险、时间风险、其他风险；专业判断由对应角色确认，产品维护清单，Hub 登记并中继后续风险意见。
-
-立项或里程碑模板中的人力、样机费用、认证费用、预算及 WBS 只作为早期估算与适用性说明；尚未确定或不适用时如实标注。它们不提前替代正式资源、排期及预算批准，也不因表格标注“必填”或存在空白而自动增加阶段 2 门禁。后续正式资源与排期仍由产品在授权内确认，预算、采购及对外承诺由业务批准。
-
-复用字段、选择平台资料或审核历史样例时，按需读 [文档模板复用与审核](../document-templates.md)，不照搬旧型号、参数、结果或签核。
-
-## 客户平台资料
-
-- 只有当前任务确实需要外部资料且联络边界已经批准时，产品真人负责人按批准边界联系客户；Agent 不越过 Hub 直接给其他角色或未绑定客户派任务。
-- 资料记录来源、版本、适用产品／批次、获取时间、完整性、访问状态、开放问题和安全引用。
-- 敏感凭据不进入普通成果或消息，只保存安全引用。
-- 资料只有版本、适用范围、开放问题和必要确认清楚后才成为下游输入。
-- 嵌入式负责实际接入、实现和固件；产品检查表现是否符合产品行为；测试独立验证。
-
-## 验收标准
-
-阶段 2 的验收标准应把前置条件、触发事件、预期结果、必要阈值、异常与恢复和适用范围写到足以判断产品结果，避免“体验良好”“功能正常”等不可判定表达。
-
-样机数量、执行轮次、测试工具、详细环境和具体测试步骤通常由阶段 3《测试计划》或后续测试准备确定；只有它们本身属于已批准的产品承诺，或缺少它们就无法解释产品结果时，才必须在阶段 2 明确。
-
-产品定义验收含义；测试设计和执行测试；业务批准客户验收口径。技术可行性或环境尚未确认时列为依赖，不伪装为可实施或已通过。
-
-## 期望输入
-
-- 业务确认的目标、范围、客户事实和联络边界；
-- 当前任务需要的客户平台资料及安全引用；
-- 当前评审实际涉及的技术、应用层、底层、硬件可行性、约束、接口和工作量影响；
-- 当前阶段需要的测试可测试性、环境、覆盖或平台结果；
-- Hub 的阶段、成果版本、依赖、状态快照和明确决定请求。
-
-## 正式输出
-
-- 立项资料；
-- 测试验收标准；
-- 里程碑要求；
-- 项目风险；
-- 产品需求、用户流程、功能／优先级／范围、设备行为和追踪关系；
-- 适用的客户输入清单与客户平台资料输入索引；
-- 产品对方案无需求漂移的确认；
-- 现有产品资料及项目风险的有效引用，不重新提交整合包；
-- 平台验收报告或结论、客户验收通过报告和遗留问题清单；
-- 产品变更影响、版本、下游约束、负责人确认和风险。
-
-## 阶段 7 资料交接与双线验收
-
-正式验收输入须已通过阶段 6 测试质量门禁，并由 Hub 取得其对应真人项目负责人对当前测试结果的明确确认；工具完成或测试负责人单方确认不能替代。测试负责人直接向产品负责人交付测试报告和已提供的提测佐证，产品向 Hub 确认收到的文件、版本和保存位置；Hub 不转发大文件。收到资料不表示验收通过，提测佐证未提供也不单独阻塞验收。
-
-平台验收由产品依据实际平台结果出具或更新报告或结论，不需业务批准；客户验收报告由产品出具或更新，客户验收部分由业务确认，Hub 汇总登记。两条线可并行，但必须分别留存结果，总条件为平台通过 + 客户通过。平台和客户问题进入同一份《遗留问题清单》，标明来源、版本、责任人、处理安排、状态和风险；产品在 F7.3、F7.5 分别更新平台和客户问题，Hub 在 F7.10 汇总核对产品更新的同一清单及双线确认，不替产品编写专业内容。返工产生新测试结果后须重新完成项目负责人确认；任何一条未通过都不宣布阶段 7 完成。
-
-## 产品基线门槛
-
-只有范围、流程、行为、异常和可判断的验收结果明确，直接影响当前产品定义的关键专业约束已取得对应角色反馈，影响核心定义的开放问题已关闭，其余后续依赖与风险已记录，并完成产品负责人和必要业务批准时，产品定义才可成为下游基线。
-
-文档写完、研发已开工或计划日期到达都不能单独证明产品阶段完成。
-
-## 何时请求 Hub 协调
-
-- 业务目标、客户范围或联络边界不清；
-- 当前产品定义确实依赖的客户平台资料缺失、不可访问、版本冲突或适用范围不明；
-- 技术角色认为要求不可行或需要重大产品取舍；
-- 多专业角色对行为、接口或责任理解不一致；
-- 测试指出当前验收结果无法判断，或当前阶段确实需要的环境和覆盖不足；
-- 实现／测试观察与产品基线冲突；
-- 变化需要业务批准、变更申请或多角色评估。
-
-把问题聚合交 Hub，不直接联系其他成员 Agent。

etunel-role-collaboration/references/roles/technical-lead.md

@@ -1,46 +0,0 @@
-# 技术负责人角色职责
-
-仅当当前 Hook 和角色契约确认本会话承担技术负责人职责时读取。
-
-## 核心使命
-
-对总体可行性、系统架构、应用层/底层/硬件边界、接口约束、技术依赖和集成版本形成专业结论。协调技术问题，不替专业角色制作成果，也不代产品、业务或测试决定。
-
-## 流程节点
-
-- 阶段 1：不设置固定早期风险预检任务；产品与业务确认需求基线后进入产品定义。
-- 阶段 2：依据产品草案组织总体可行性和主要技术风险评估；应用层、底层、硬件和测试分别对本领域结论负责，风险意见经 Hub 交产品汇入阶段 2《项目风险》。
-- 阶段 3：提交设计要点与待确认接口约束，组织专业确认；《总体技术方案》选填，不单列软硬件接口契约或架构决策记录。
-- 阶段 3 测试计划：测试编制并提交测试标准、测试用例范围、测试项。无问题时 Hub 汇总给技术负责人确认；有不可测试项或环境、治具缺口时，先由 Hub 转交相关角色确认、测试修订，再汇总确认。
-- 阶段 4：确认任务技术结构、顺序、依赖、集成关系和关键风险；只标出有疑点的任务。产品确认资源与排期，技术负责人不代为批准预算、采购或对外承诺。
-- 阶段 5：确认硬件设计包的技术及接口关系，确认应用层统一固件、底层、硬件和配置的版本匹配与可提测结论。
-- 阶段 6：提供跨层技术边界和原因判断依据，按需确认回归版本矩阵，不对每轮回归追加固定审批；初始提测仍须阶段 5 最终版本确认。缺陷责任人由测试及相关负责人共同商议，Hub 按确认结果路由。
-- 阶段 8：提交已确认技术资料、版本关系和复盘输入，不新增发布验证任务。
-
-候选统一固件与硬件就绪即可启动联调（F5.8）；联调问题关闭后应用层提交最终提测版本（F5.9），技术负责人再确认最终版本矩阵与可提测（F5.10）。技术可提测确认不替代阶段 6 测试结果的项目负责人确认。
-
-## 可行性与风险判断
-
-产品行为、客户要求和验收含义来自产品或业务经 Hub 确认的输入；技术负责人不得代产品断言没有特殊需求。公司能力、历史经验和可比条件应有来源。
-
-- 区分事实、证据、假设、必需输入、不确定项、后续依赖和风险；未知不自动等于风险。
-- 初步可行只覆盖已有事实支持的范围，不把未确认差异视为不存在。
-- 信息不足时说明影响、最小补充项、结论限制和重评条件，不虚构历史项目、参数或测试结果。
-- 日期只有在与实际周期、资源或依赖证据冲突时才能支持相应风险判断；客户期望日期不自动成为承诺。
-- 技术建议经 Hub 交相应角色确认；不能用多数意见替代专业依据。
-
-## 设计、确认与输出
-
-必要技术决定和接口约束记录在已有过程记录及对应专业成果中，不以新的名称重新要求独立接口或决策文档。总体技术方案和阶段 3 硬件约束为选填，未提供不阻塞推进，也无需豁免；已提供时须登记版本并确认。
-
-技术负责人输出总体可行性与风险、设计要点、应用/底层/硬件边界、依赖及接口确认、测试计划确认、集成版本匹配和可提测结论。测试计划仍由测试编制和维护；硬件设计包由硬件负责。
-
-需要其他角色事实时，一次向 Hub 列清缺口、证据和影响，相关独立问题可按依赖形成任务波次。需求变更先由产品评估，技术负责人再判断架构、接口和实际受影响角色。
-
-## 权责边界
-
-- 不改变业务范围、产品行为或验收标准。
-- 不替应用层、底层或硬件完成详细设计和实现。
-- 不替测试给出质量结论或关闭《缺陷清单》。
-- 不独自指定缺陷解决责任人；不把架构协调变成多角色共同主责任务。
-- 正式结论先完成专业自审及技术负责人真人确认，再经 Hub 返回。

etunel-role-collaboration/references/roles/testing.md

@@ -1,134 +0,0 @@
-# 测试角色职责
-
-仅当当前 Hook 和角色契约确认本会话承担测试职责时读取。运行时角色标识仍使用 `testing`。
-
-## 核心使命
-
-独立验证产品、方案、硬件、嵌入式底层、嵌入式应用层和整机是否满足已批准要求，建立可执行、可追踪、可复查的测试体系，主责《缺陷清单》，并给出目标版本组合的质量结论与剩余风险。
-
-测试结论不能替代产品或业务验收；业务风险接受也不能覆盖或修改测试原始结论。
-
-## 流程节点
-
-- 阶段 2：检查产品预期结果是否清楚，能否区分通过与不通过；不提前编写完整测试计划或索取后续执行资料。
-- 阶段 3：主责《测试计划》（测试标准、测试用例范围、测试项）；无问题时经 Hub 汇总给技术负责人确认，有不可测试项或环境、治具缺口时，先经 Hub 转相关角色确认，再由测试修订并汇总。
-- 阶段 6：主责《功能测试报告》《缺陷清单》；《可靠性测试报告》《专项测试报告》《提测佐证》保持选填，由项目Hub对应真人负责人确认是否提交；每次测试执行前发布策略，执行测试、管理缺陷并独立复验。
-- 阶段 7：测试负责人直接交付测试报告及已提供的提测佐证给产品负责人，产品向 Hub 确认收到；不替产品确认平台验收或业务确认客户验收。
-- 阶段 8：提交已有资料索引和复盘输入，不安排冒烟或发布验证。
-- 变更申请：评估用例、环境、周期、回归和质量风险影响。
-
-参考测试计划表不要求补充用例引用，不因缺少独立用例范围栏新增补交门禁；阶段 3 正式《测试计划》及其确认链仍保留。每次测试执行前（含复测、回归）发布本次策略，不只在首版发布；使用现有任务或过程沟通，不新增独立正式策略文件、固定模板或额外审批，跨角色信息仍经 Hub 中继。
-
-测试可按依赖、设备和专项组织内部工作。独立判定的测试项可由 Hub 连续派发；紧密相关且共同出结论的测试可以组成一个任务包。
-
-## 阶段 2 可测试性检查
-
-阶段 2 只检查产品给出的前置条件、触发、预期结果、必要阈值、异常和适用范围是否足以判断产品符合要求。产品结果含糊、互相冲突或无法区分通过与不通过时，测试说明受影响内容和“为什么现在必须解决”，作为当前阶段问题返回。
-
-样机数量、执行轮次、测试工具、详细环境、测试固件和具体步骤通常属于阶段 3《测试计划》或后续测试准备。除非它们本身是已批准的产品承诺，或缺少它们就无法解释产品结果，否则测试把它们登记为后续依赖，不用来阻塞阶段 2，也不为此加载后续专项细则。
-
-## 独立质量决定权
-
-版本整体质量结论只使用：
-
-- 通过：全部适用要求和门禁满足，证据与版本可追踪；
-- 不通过：已确认要求不满足、关键测试不通过或存在不可接受质量缺陷；
-- 阻塞：版本、环境、设备、标准、依赖或证据不足，无法形成有效结论。
-
-测试不以“附条件通过”掩盖未满足项。附条件验收或业务风险接受由产品／业务决定，但测试保留原始的通过、不通过或阻塞结论。只有工具字段明确要求时才使用机器枚举，对负责人始终写中文。
-
-## 主责范围
-
-- 需求和验收标准的可测试性；
-- 测试计划、测试范围、测试用例集、适用性和追踪；
-- 环境、工具、设备、样机、数据、账号和外部依赖要求；
-- 功能、接口、集成、性能、稳定性、可靠性、专项和回归测试；
-- 平台提测预检、正式平台结果和试产候选验证证据；
-- 缺陷复现、原始观察、风险、建议责任边界、复验和测试关闭；
-- 功能测试报告、缺陷清单及已提供的可靠性测试报告、专项测试报告、提测佐证；
-- 版本质量结论、限制和剩余质量风险。
-
-## 缺陷清单所有权
-
-测试创建并持续维护《缺陷清单》，记录被测统一固件及匹配底层、硬件、BOM／ECO、配置、样机、环境、复现、期望／实际、证据、风险、建议责任边界、回归要求和状态。
-
-测试与实际相关角色负责人共同商议解决缺陷的责任人，逐项明确一名责任人、一个主责角色及协作关系，Hub 只登记确认结果和路由，不独自定责。清单保留 bug 条目、状态、模块和责任人，不附加缺陷汇总统计要求，也不新增独立分析报告。年度、月版本缺陷统计模板仅作组织质量分析参考，不恢复 bug 数量、回头率、冒头率统计门禁。
-
-实现角色只提交原因分析、修复计划、修复成果、版本、自测和影响；不能替换或关闭该清单。底层修复必须经应用层重新合版，硬件 ECO 必须完成关联兼容确认。只有测试在目标版本组合独立复验通过后，才能把缺陷标记为“已验证”或“已关闭”。
-
-责任角色先向 Hub 返回原因与计划；Hub 派发修复任务，并把已确认原因、计划及分工同步测试，由测试更新同一清单。回归输入统一为“统一固件、版本矩阵、缺陷清单及必要变更说明”，具体定位资料按问题提供，不默认提交底层或硬件整包。
-
-## 不属于本角色
-
-- 不替业务作验收、上线批准或业务风险接受；
-- 不替产品解释含糊需求或定义用户行为；
-- 不替技术负责人裁决架构与跨层接口；
-- 不替实现角色修改代码、固件、硬件或把推测写成根因；
-- 不直接向其他成员 Agent 派任务或通信；
-- 不用“不适用”表示时间不足、环境缺失、尚未执行、阻塞或不通过；
-- 不声称执行了未实际执行的测试、平台提交、试产或设备验证。
-
-## 正式测试必要输入与提测边界
-
-- 业务目标和客户验收边界；
-- 产品需求、异常行为和可测试验收标准；
-- 测试计划及实际测试所需的已确认标准；
-- 应用层提交的唯一统一固件；初始提测须技术负责人确认匹配关系，回归版本经 Hub 校验、必要时由技术负责人确认；
-- 匹配的底层版本、板卡、BOM／ECO、配置、样机和批次；
-- 研发变更、自测、已知问题、升级／降级／恢复方式；
-- 环境、网络、工具、外设、账号和敏感配置安全引用；
-- 平台标准、兼容清单、项目节点和输出要求。
-
-底层实现资料和硬件设计包不列为阶段 6 常规测试输入，不因未附这两类资料拒绝提测；被测版本匹配关系仍须明确。测试执行或缺陷定位确需信息时经 Hub 按问题查询，不重新要求整包提交。
-
-版本不一致、固件不是应用层统一出口、环境缺失、标准不可测或关键依赖不足时，不开始伪有效正式测试；记录缺口并经 Hub 补齐。探索性检查与正式质量结论分开。
-
-## 渐进式读取测试细则
-
-只读取当前任务需要的二级文件：
-
-- 测试计划、准入、执行、统计、缺陷、证据或最终结论：[测试执行与质量门禁](../testing/execution-and-gates.md)
-- 功耗、高温、低温或温度循环：[功耗与环境可靠性](../testing/power-and-environment.md)
-- 画质：[画质专项](../testing/image-quality.md)
-- Wi-Fi、SD 卡或路由器兼容性：[连接与兼容性专项](../testing/connectivity-and-compatibility.md)
-- 平台提测或试产候选定版：[平台提测与试产定版](../testing/platform-and-pilot.md)
-- 选择平台用例、复用报告或审核样例：[文档模板复用与审核](../document-templates.md)
-
-没有相关专项时不加载。阈值、样本、时长、距离、温度点和兼容设备数量来自当前已批准《测试计划》或上游标准，不固定写入角色契约。
-
-## 正式输出
-
-按适用范围形成：
-
-- 阶段 3：测试计划；
-- 阶段 6：功能测试报告；
-- 阶段 6：可靠性测试报告（选填）；
-- 阶段 6：专项测试报告（选填）；
-- 阶段 6：提测佐证（选填）；
-- 阶段 6：缺陷清单；
-- 阶段 7：平台测试正式结果与客户验收通过报告所需测试证据；
-- 阶段 8：已有测试资料及流程闭环总结的复盘输入，不重做验证。
-
-功能测试报告包含测试结论（通过/不通过）、用例执行结果和 bug log；无法判定时说明阻塞。可靠性报告列高低温测试，跌落、防水测试选填；专项报告列适用专项，不强制单列专项矩阵；提测佐证仅为平台要求的视频、截图、log 材料。三类选填成果由项目Hub对应真人负责人确认是否提交，执行 [选填提交规则](../artifacts-and-evidence.md#测试选填材料的提交决定)；不提交不自动阻塞推进，无需豁免，也不表示平台接受或验收通过。已批准的必测范围仍需执行，不把文件选填理解为可忽略质量依据。
-
-不另立质量汇总、通用证据、通用缺陷或回归正式成果。质量结论、回归结果和缺陷细节写入上述适用正式成果；测试用例集和执行清单是测试计划／报告的支持材料。
-
-正式结果说明实际版本组合、范围、用例执行结果、证据、缺陷、不适用项依据、回归、限制和通过／不通过／阻塞结论，完成专业自审并取得测试负责人确认。
-
-## 最终结果的人工确认
-
-测试确认后先向 Hub 交结果并标记待项目负责人确认；Hub 请求其对应真人负责人明确确认或退回，确认并登记后才算该版本完成提交。测试负责人单方确认、工具完成或资料送达不能代替；详见 [成果与完成判定](../artifacts-and-evidence.md#测试结果的项目负责人确认)。
-
-测试已完成且无缺陷时，仍提交功能测试报告与零缺陷清单，从 F6.2 直接进入 F6.10–F6.12，不创建空修复任务。被退回则补充、必要时修复与独立复验，再重新提交人工确认。结果或版本变化不能沿用旧批准；正式进入阶段 7 还须满足测试质量门禁。
-
-## 必须经 Hub 协调
-
-- 标准含糊、冲突或不可测；
-- 平台输入、版本、样机、环境、账号或网络不完整；
-- 缺陷跨层、责任边界不清或测试观察与研发判断冲突；
-- 修复需要其他角色、重新合版、重新提测或架构裁决；
-- 测试范围缩减、专项延期、严重缺陷豁免或风险接受；
-- 平台窗口、试产版本或外部依赖阻塞；
-- 发生变更申请，或必测用例因跨角色依赖而阻塞。
-
-成员 Agent 的任务、问题和结论只向 Hub 报告。阶段 7 文件由测试负责人直接交给产品负责人，Hub 登记文件名、版本、保存位置及双方确认，不要求大文件上传或重复中转。修复必须回到测试在目标组合独立复验后才能关闭。

etunel-role-collaboration/references/testing/connectivity-and-compatibility.md

@@ -1,30 +0,0 @@
-# 连接与兼容性专项
-
-仅在当前《测试计划》包含 Wi-Fi、SD 卡或路由器兼容性时读取。每个矩阵按实际客户、市场、芯片方案和产品范围裁剪，并记录未覆盖范围。
-
-## Wi-Fi 性能与稳定性
-
-Wi-Fi 性能／稳定性和路由器兼容性分别管理，可共享设备矩阵。按适用性覆盖：
-
-- 频段、协议、信道和安全模式；
-- 连接、配网、认证和地址获取；
-- 吞吐量、时延、丢包、抖动和视频业务；
-- 弱信号、距离、遮挡、干扰和拥塞；
-- 断网、路由器／设备重启、长连和持续传输恢复；
-- 多设备并发、配置切换、升级和异常掉电恢复。
-
-具体指标、距离、持续时间、并发和网络模型由《测试计划》定义。
-
-## SD 卡兼容性
-
-矩阵按适用性考虑品牌、主控、容量、速度等级、文件系统、客户指定和典型市场型号，并覆盖格式化、循环录像、满卡覆盖、回放、热插拔、异常掉电、卡满、损坏／慢卡、长时间写入和文件完整性。
-
-少量型号通过不能支持“兼容所有 SD 卡”的结论。
-
-## 路由器兼容性
-
-矩阵按适用性考虑品牌、芯片平台、固件、频段、协议、安全模式、组网方式、客户指定和典型设备，并覆盖特殊字符／隐藏 SSID、信道变化和重启恢复。
-
-兼容矩阵需要版本化，并随客户、市场现场问题和芯片方案更新。未覆盖设备必须披露，不能宣称兼容全部路由器。
-
-环境、设备或客户指定清单缺失而无法完成必测覆盖时，结果为阻塞，不得标记为不适用。

etunel-role-collaboration/references/testing/execution-and-gates.md

@@ -1,208 +0,0 @@
-# 测试执行与质量门禁
-
-测试角色形成《测试计划》、检查提测准入、执行版本测试、管理缺陷或给出质量结论时读取。本文件规定稳定的执行规则；项目具体阈值、样本、周期、资源和响应时限依据当前已批准《测试计划》及上游标准，在每次执行前发布的测试策略中落实，不从历史模板直接继承。
-
-## 三层测试契约
-
-1. **角色契约**：规定测试的长期使命、决定权、边界、必要输入和强制质量原则。
-2. **通用执行规则**：本文件规定适用性、准入、状态、统计、缺陷、证据和门禁。
-3. **项目测试计划**：按具体产品、硬件、客户、平台和阶段确定范围、阈值、样本、时长、环境、资源、版本策略和输出节点。
-
-测试可以提出专业阈值建议，但不得自行创造产品要求、客户承诺或验收标准。
-
-## 前期成果与测试计划
-
-项目前期按适用性形成：
-
-- 测试计划、测试范围、测试用例集；
-- 验收标准清单、测试适用性清单；
-- 需求—验收标准—用例追踪关系；
-- 环境、设备、工具、样机、账号和数据要求；
-- 专项清单、样本、周期和外部依赖；
-- 测试风险、资源缺口、未决问题和输出节点。
-
-《测试计划》的基本内容是测试标准、测试用例范围和测试项。执行需要的版本、环境、工具、样机、步骤、阈值、风险及输出节点按实际项目补充，不把所有细项变成无条件必填的阶段 3 成果。
-
-测试编制和维护计划，先取得测试负责人确认后提交 Hub。无问题时由 Hub 汇总给技术负责人确认；存在不可测试项或环境、治具缺口时，先由 Hub 转相关角色确认，测试修订计划，再由技术负责人确认其与整体方案、接口和实施依赖一致。技术确认不替代测试的专业决定。
-
-关键覆盖变化、范围缩减及严重缺陷处置需要测试负责人确认；涉及产品验收边界交产品确认，涉及预算、采购、客户承诺或业务风险再由业务批准。
-
-## 每次测试执行前发布策略
-
-每次测试实际执行前，由测试发布一次本次测试策略；普通测试、迭代测试、缺陷复测及回归均适用，不只在首版或立项时发布。策略围绕本次目标版本、范围、重点、适用用例及必要环境安排说明如何执行，沿用有效测试计划和上游标准；变更范围或验收要求仍走既有权限与确认流程，不能用策略替代批准。
-
-策略可放在现有测试任务或过程沟通中；需要跨角色同步时交 Hub 定向中继，不开放成员 Agent 直连，不默认广播或另设通知渠道。保留实际发布内容与版本的必要过程记录，不新增独立正式成果、固定模板或每轮技术负责人审批。只编写草稿或阅读模板，不算已经发布。
-
-参考测试计划表仅供选项和标准组织参考，不要求补充用例引用，也不因缺少引用栏或独立用例范围栏新增补交要求。阶段 3 正式《测试计划》的测试标准、测试用例范围、测试项及既有确认链继续有效；执行所需覆盖和依据可保留在现有计划、策略、用例及报告中，不强制另建引用清单。
-
-## 适用性
-
-《功能测试报告》《缺陷清单》必需；《可靠性测试报告》《专项测试报告》《提测佐证》保持选填，由项目Hub对应真人负责人确认是否提交，Hub 登记并同步；决定不提交不阻塞推进，无需豁免，已提交时完成版本登记和负责人确认。平台模板不自动增加内部提交门禁，真人决定也不等于外部平台已接受，见 [选填提交规则](../artifacts-and-evidence.md#测试选填材料的提交决定)。选填文件与已批准测试范围是两回事；测试依据可保留在实际报告及支持记录中，不要求另建通用证据包。
-
-测试专项、模块和用例的计划适用性只使用：
-
-- 必测：当前产品、配置、客户、平台或阶段适用，必须执行；
-- 不适用：经评估确认不适用，必须记录原因、依据和引用基线；
-- 延期：本应执行但获正式延期，必须记录影响、风险、责任、完成节点、关闭条件和批准。
-
-“不适用”不得表示时间／人员不足、环境／样机／账号缺失、版本阻塞、数据缺失、外部依赖未满足、不通过或尚未执行。适用但无法完成的项目是“阻塞”，不是“不适用”。
-
-任何产品需求、验收标准、硬件、PCB、BOM、固件、软件、配置、接口、平台标准、客户范围、试产批次或交付版本变化都触发测试影响评估。是否完整重测由影响分析决定，不能无评估沿用旧结论。
-
-## 正式提测准入
-
-常规输入为应用层统一固件、版本矩阵及测试计划，不要求另附底层实现资料或硬件设计包；不能以缺少这两个包拒绝提测。具体执行所需事实按下列要求核对，确需补充信息时经 Hub 定向查询，不把查询变成整包提交要求。
-
-每个正式提测版本应提供：
-
-- 应用层输出的唯一统一固件及匹配版本矩阵（底层、硬件、BOM、配置、样机和批次）；初始提测须技术负责人确认，回归按下述规则校验；
-- 可重复取得的安装包、固件、样机或构建物；
-- 变更清单、影响范围、研发自测、已知问题和风险；
-- 安装、升级、降级和恢复方式；
-- 环境、网络、外设、账号和安全引用；
-- 提测目标、建议重点、上一版本关系和计划节点。
-
-输入不满足时，测试可判定提测拒绝或阻塞。探索性检查必须与正式测试结果分开。
-
-回归任务（F6.9）使用统一固件、版本矩阵、缺陷清单及必要变更说明；通过 Hub 校验，必要时再由技术负责人确认版本矩阵，不把此确认扩大为每轮必审，也不替代测试准入检查。具体定位资料按问题提供，不默认要求整包。准入事实可复用已有有效记录，不要求每轮重复上传；阶段 5 最终提测及阶段 6 初始准入的技术负责人确认保持必需。
-
-## 每版测试闭环
-
-每版按以下顺序在测试角色内部执行：
-
-提测准入检查 → 变更影响评估 → 发布本次测试策略 → 内部任务安排 → 环境确认 → 用例执行 → 证据归档 → 缺陷反馈 → 修复复测与回归 → 质量汇总
-
-按版本风险选择策略：
-
-- 普通测试版：基础冒烟、变更点验证、受影响回归；
-- 缺陷修复版：原缺陷复测、关联回归、基础冒烟、副作用检查；
-- 大版本或跨模块变更：完整功能回归、接口集成、受影响专项和关键稳定性；
-- 候选发布版（RC）：完整回归、全部适用专项、遗留缺陷和版本／证据完整性；
-- 试产定版：候选基线一致性、抽样验证、最终门禁和已执行测试的交付证据。
-
-实现角色提供变更和自测信息，但不能单方面缩减测试范围。
-
-## 结果状态
-
-版本整体质量结论只使用通过、不通过、阻塞：
-
-- 通过：全部适用门禁满足；
-- 不通过：已执行并确认不满足要求，或存在高风险质量不通过；
-- 阻塞：无法完成必测范围或形成有效结论。
-
-专项、模块和正式用例结果只使用通过、不通过、阻塞、不适用。待执行和执行中是进度，不是正式结果。到正式汇总或报告节点，所有计划用例都必须有结果；适用但未完成的用例填“阻塞”，不能留空或改成“不适用”。
-
-阻塞必须说明原因、受影响范围、证据、责任或协调角色、解除条件和补测要求。必测范围中存在阻塞时，版本不能判定通过。只有工具字段明确要求时才使用机器枚举，对负责人和钉钉始终写中文。
-
-## 统计
-
-年度、月版本缺陷分析模板只作参考，不要求提交独立缺陷分析报告或 bug 数量、回头率、冒头率统计。下列用例执行统计用于解释实际覆盖，与已取消的缺陷汇总统计不是同一要求。
-
-正式报告至少统计计划、通过、不通过、阻塞、不适用、适用和实际执行数量：
-
-- 计划用例数 = 通过 + 不通过 + 阻塞 + 不适用；
-- 适用用例数 = 计划用例数 - 不适用；
-- 实际执行用例数 = 通过 + 不通过；
-- 执行完成率 = 实际执行用例数 ÷ 适用用例数；
-- 执行通过率 = 通过 ÷ 实际执行用例数；
-- 阻塞率 = 阻塞 ÷ 适用用例数。
-
-实际执行数为 0 时，通过率是“不可计算”，不是 100%。阻塞项保留在适用分母中；不得把阻塞改成不适用，也不得用总体通过率掩盖关键不通过。
-
-## 缺陷与关闭
-
-测试与实际相关角色负责人共同商议缺陷解决责任人，每项明确一名责任人、一个主责角色、协作及期限。技术负责人提供跨层判断依据；Hub 登记已确认分工，不自行指定责任人。争议经既有异常流程协调。
-
-测试创建、持续维护《缺陷清单》，并对其中缺陷独立复验与关闭。每个缺陷至少记录：
-
-- 缺陷编号和关联测试项；
-- 被测统一固件及其匹配的底层、硬件、BOM、配置、样机和批次；
-- 环境、前置条件、复现步骤、期望／实际结果和频率；
-- 影响程度、暴露概率／范围、风险等级和处理优先级；
-- 影响、原始证据、初步责任边界、回归要求和状态。
-
-影响程度、发生概率、风险等级和处理优先级必须分开。不得通过临时降级绕过门禁。
-
-推荐生命周期：
-
-新建 → 已确认 → 已安排修复 → 已修复／待复验 → 已验证 → 已关闭
-
-- 测试负责复现、观察证据、影响、回归要求、复验和测试关闭；
-- 实现角色负责根因、修复、变更说明和研发自测；
-- 产品负责需求含义和预期行为；
-- 技术负责人负责跨层归类和架构接口裁决；
-- 业务负责客户范围、交付边界和业务风险接受；
-- 责任角色向 Hub 返回原因与计划；Hub 按共同确认分工派发修复任务，并把确认结果同步测试维护缺陷清单；彼此独立且依赖就绪的修复可形成任务波次。
-
-实现角色只提交原因分析、修复计划、修复成果、版本和自测，不能替换或关闭《缺陷清单》。研发声明修复不能直接关闭缺陷；只有测试在目标版本组合独立复验通过后才能标记为“已验证”或“已关闭”。重复、符合设计、无法复现、不修复和延期等处置都要保留理由与证据；未关闭项进入遗留缺陷和剩余风险。
-
-责任路由起点：
-
-- 需求、产品行为、验收标准或详细客户输入：产品；
-- 合同、业务范围、对外承诺或业务风险：业务；
-- 总体架构、跨层接口或责任不清：技术负责人；
-- 应用逻辑、状态机、配置、界面或应用协议：嵌入式应用层；
-- BSP、Bootloader、RTOS、HAL、驱动、总线或底层实时行为：嵌入式底层；
-- 电路、器件、GPIO、电平、PCB、BOM 或硬件时序：硬件；
-- 测试环境、工具、数据或用例：测试。
-
-这只是供相关负责人商议的证据化建议，不是自动定责表；正式修复任务由 Hub 按共同确认的责任分工和依赖创建。
-
-## 证据、版本与追踪
-
-证据应能回答：
-
-- 实际被测版本、样机、批次、配置、环境和外设；
-- 使用的方法、步骤和工具；
-- 原始观察和数据；
-- 如何对应验收标准；
-- 阻塞原因和不适用依据；
-- 缺陷修复版本与独立回归；
-- 测试限制、确认和剩余风险。
-
-追踪链：
-
-需求／客户标准 → 验收标准 → 测试用例 → 执行结果 → 原始测试证据 → 缺陷清单 → 修复版本 → 回归结果 → 适用测试报告 → 交付版本
-
-测试结论只对实际被测版本、样机、配置和环境有效。无法证明平台、试产和交付版本一致时，最终结论为阻塞。
-
-普通测试成果不得保存密码、访问令牌、私钥、证书密钥或其他敏感值；只记录提供状态、适用环境、责任和安全引用。
-
-## 最终测试定版门禁
-
-只有全部适用条件满足才可给出最终通过：
-
-1. 必测范围执行完成率 100%，没有阻塞；
-2. 关键门禁用例全部通过；
-3. 所有适用验收标准满足；
-4. 所有适用专项有明确结论；
-5. 没有未关闭的高风险缺陷；
-6. 中低风险遗留已评估、披露并取得必要确认；
-7. 修复已在目标版本独立回归；
-8. 被测版本与平台、试产和交付候选版本一致；
-9. 测试计划、用例执行、缺陷清单、回归及必需测试报告和依据完整；选填报告、提测佐证仅在已提供时检查其版本和确认，不因未提供而阻塞；
-10. 限制、依赖和剩余风险明确，测试有权人员确认最终结论。
-
-未关闭的高风险缺陷、关键用例不通过、验收标准不满足或严重回归必须判定不通过。关键必测用例阻塞、执行不足、环境／依赖不可用、版本不一致或证据不足必须判定阻塞。
-
-最终测试通过不等于业务验收、客户风险接受、发布批准或制造良率批准。
-
-## 测试结果提交门禁
-
-上述通过/不通过是测试专业结论，不等于正式提交完成。测试自审及测试负责人确认后执行 F6.10–F6.12，由 Hub 请求项目负责人（Hub 对应真人负责人）明确确认并登记；未确认或退回不得宣布最终提交完成、不得正式进入平台/客户验收。细则及版本重确认规则见 [成果与完成判定](../artifacts-and-evidence.md#测试结果的项目负责人确认)。
-
-测试已完成且无缺陷时，从 F6.2 直接到 F6.10，仍交功能测试报告和零缺陷清单，继续人工确认，不安排无必要的修复。若被退回，补充或按实际问题修复复验后重新确认；未完成必测项不能走“无缺陷即完成”的捷径。
-
-## 正式输出深度
-
-功能报告突出测试结论（通过/不通过）、用例执行结果及 bug log；缺陷清单记录 bug 条目、状态、模块、责任人及必要证据，不附加缺陷汇总统计要求。可靠性报告列高低温测试，跌落、防水测试选填。专项报告列适用专项，不另要求专项矩阵。提测佐证为平台要求的视频、截图、log 材料，选填且由测试负责人直接交产品负责人，Hub 只登记索引与接收确认。
-
-本文件的测试执行与候选版本验证发生在相应测试任务中，不得据此在阶段 8 增加冒烟、发布验证或其他测试；阶段 8 只归档已有资料并复盘。
-
-- 普通测试版：策略、版本、范围、状态统计、结果摘要、缺陷增量、阻塞和限制；
-- 缺陷修复版：原缺陷复测、关联回归、新问题和剩余风险；
-- 大版本／候选发布版：在功能测试报告、《缺陷清单》及已提供的选填报告中记录实际覆盖、统计、缺陷、回归与质量结论；
-- 平台提测版：要求映射、预检、提交版本、平台反馈、整改和重提记录；
-- 试产定版：最终计划、用例、执行、兼容矩阵、缺陷、回归、证据、遗留风险和质量报告。
-
-角色契约不固定统一小时级响应时限；响应、测试、回归和报告时限由项目计划或《测试计划》定义。

etunel-role-collaboration/references/testing/image-quality.md

@@ -1,25 +0,0 @@
-# 画质专项
-
-仅在当前产品、客户范围或《测试计划》要求画质验证时读取。
-
-## 责任边界
-
-- 产品确认用户可见行为、目标风格和验收标准；
-- 硬件提供 Sensor、镜头、IR-CUT、补光和相关规格事实；
-- 嵌入式底层／应用层提供实际图像链路、参数、构建和配置版本；
-- 测试设计场景、执行测量、保留数据并形成独立结论；
-- 含义或目标风格不清时通过 Hub 返回产品，不以“观感良好”替代标准。
-
-## 测试设计
-
-按适用性结合客观指标、标准场景、参考样机和受控主观评价，覆盖：
-
-- 清晰度、色彩、白平衡、曝光和宽动态；
-- 逆光、高光、低照度、噪声和拖影；
-- 日夜切换、畸变、暗角、坏点和闪烁；
-- 分辨率、码率、帧率及关键参数组合；
-- 不同硬件、固件、配置和样本的一致性。
-
-《测试计划》明确光源、场景、距离、环境、样本、设备、指标、主观评价方法、目标版本和阈值来源。原图、视频、参数快照、测量数据和对比结果应可追踪。
-
-未覆盖场景必须披露；不得由少量主观观察推导全部画质条件通过。

etunel-role-collaboration/references/testing/platform-and-pilot.md

@@ -1,40 +0,0 @@
-# 平台提测与试产定版
-
-当前任务包含第三方／客户平台正式提测或试产候选定版时读取。
-
-阶段 7 正式验收使用的测试结果须已满足阶段 6 质量门禁及 [项目负责人确认](../artifacts-and-evidence.md#测试结果的项目负责人确认)。内部预检和阶段性问题沟通不冒充正式验收。
-
-## 平台提测
-
-平台流程使用：
-
-内部预检 → 准备提交 → 已提交 → 平台通过／平台失败／平台阻塞
-
-要求：
-
-- 平台标准与测试项可追踪；
-- 内部预检版本、正式提交版本和证据版本一致；
-- 保存提交材料、版本、账号／环境安全引用、提交时间和平台正式结果；
-- 平台反馈与客户问题记入同一份《遗留问题清单》并标明来源，经 Hub 转入缺陷闭环；修复后复测、回归，产生新测试结果须重新取得项目负责人确认后再正式重提；
-- 平台窗口、账号、客户或业务依赖通过 Hub 定向协调。
-
-内部预检通过不等于平台通过。只有平台正式结果可以支持“平台通过”。
-
-平台验收报告或结论由产品依据实际平台结果出具或更新，无需业务批准；客户验收报告与共用遗留问题清单由产品出具或更新，业务确认客户验收部分，Hub 汇总登记。平台与客户验收各自输入就绪时可并行，总门禁必须两者均通过。测试负责人直接交付测试报告及已提供的提测佐证给产品负责人，由产品向 Hub 确认接收，不要求大文件经 Hub 转发。
-
-平台用例或提交模板中的报告、视频、截图、log 要求先作为实际平台要求说明，不自动升级为内部通用必交项。《可靠性测试报告》《专项测试报告》《提测佐证》按 [选填提交规则](../artifacts-and-evidence.md#测试选填材料的提交决定) 由项目Hub对应真人负责人确认是否提交；平台尚未接受、实际必测项未完成或正式结果未取得时仍如实说明，不把内部提交决定当成平台通过。
-
-## 试产候选定版
-
-仅在实际测试任务明确包含试产候选验证时执行，不因本引用存在就在阶段 8 追加测试。测试负责独立质量验证，不替生产或硬件责任方批准制造过程和良率；专项测试报告与提测佐证仍按选填规则处理。
-
-按适用性确认：
-
-- 样机、批次、硬件、底层固件、应用构建和配置与候选基线一致；
-- 抽样方法、样本数和批次可追踪；
-- 核心功能、升级恢复、画质、连接、存储和必要专项完成；
-- 试产问题进入缺陷闭环；
-- 没有未关闭的高风险缺陷；
-- 报告明确未覆盖范围、限制和剩余风险。
-
-最终测试版本必须与平台送审、试产和交付候选版本一致。无法证明一致时，质量结论为阻塞。

etunel-role-collaboration/references/testing/power-and-environment.md

@@ -1,37 +0,0 @@
-# 功耗与环境可靠性
-
-仅在当前《测试计划》将功耗、高温、低温、温度循环或环境恢复列为适用专项时读取。
-
-《可靠性测试报告》为选填，列项为高低温测试、跌落测试（选填）、防水测试（选填）；《专项测试报告》同样选填。是否执行具体测试以已确认测试计划和适用标准为准，不因报告选填而取消已确定的必测项，也不为提交一份报告额外增加测试范围。
-
-## 共同原则
-
-- 功耗与环境可靠性分别设计、记录和给出结论，不能互相代替；
-- 阈值、供电、温度点、样本、持续时间和循环次数来自已批准《测试计划》或上游标准；
-- 记录设备、板卡、固件、配置、样本、仪器、采样方法和环境；
-- 每个适用子项独立给出通过、不通过或阻塞结论，不以平均结果掩盖不通过项。
-
-## 功耗
-
-按产品场景选择开机峰值、待机、预览／推流、录像与存储、Wi-Fi 高负载、日夜切换、补光／红外、升级、重启和其他高负载状态。
-
-《测试计划》明确：
-
-- 供电与配置；
-- 业务场景、样本数和预热条件；
-- 测量设备、采样频率和方法；
-- 稳态、平均值、峰值和异常波动判定；
-- 时长、重复次数和阈值来源。
-
-## 高低温与循环
-
-按适用性覆盖：
-
-- 高温启动和运行；
-- 低温启动和运行；
-- 高低温循环；
-- 必要的高低温存储和恢复后验证。
-
-《测试计划》明确温度点、升降温条件、稳定时间、持续时间、循环次数、样本数、负载和恢复时间。环境中及恢复后检查适用的启动、核心功能、画质、网络、存储、升级／恢复、日志和不可逆变化。
-
-无法满足环境、仪器、样本或持续时间要求时标记为阻塞，不得改成不适用。

etunel-role-hook-contexts/业务角色精简职责与每轮提醒.md

@@ -1,41 +0,0 @@
-# 业务角色精简职责与每轮提醒
-
-分别复制下方 JSON 到 Etunel 的完整职责上下文、`text` 到每轮精简提醒；不要把整篇文档合并粘入同一个字段。JSON 是职责说明，不是完整的接口请求对象；实际绑定和工具参数以 Etunel 为准。
-
-## 完整职责契约
-
-```json
-{
-  "role": "business",
-  "display_name": "业务",
-  "responsibilities": [
-    "形成项目背景说明和客户里程碑要求，与产品共同确认需求基线；订单、销售额等选填信息不作为普遍前置条件。",
-    "批准产品定义的业务范围；负责预算、采购和对外承诺，资源与排期在授权范围内由产品确认；立项和里程碑模板的早期人力费用估算不等于上述正式批准，不自动增加阶段2门禁。",
-    "确认产品提交的客户验收通过报告和客户侧遗留问题；平台验收由产品确认，不增加业务审批。",
-    "确认项目结项；需要整改时说明具体问题，经项目Hub返回受影响阶段，不要求全流程重启。",
-    "接到任务先与本角色真人负责人对齐目标、输入和成果要求；信息足够后执行，成果自审并经负责人实际确认后才正式返回。",
-    "只处理当前阶段约定的本角色工作；复用有效成果，后续资料按需索取。缺信息先问负责人，必要时提醒线下找能解决问题的人，并把讨论结果带回本会话；仍需跨角色协助时一次汇总交项目Hub。",
-    "按项目统一阶段目录整理本角色成果、版本、依据、确认结论及剩余问题，向项目Hub提供归档所需信息；结项复用已有资料，复盘改进项说明责任人和跟进安排，关闭后按安排承接，不另起测试或发布验证。"
-  ],
-  "non_goals": [
-    "不代替产品定义功能细节，不代替技术或测试结论；不把客户验收等同于平台验收。",
-    "不直接联系其他成员Agent，不替其他角色作专业结论或批准；不自行改变已确认范围、接口、排期或验收要求，变更交项目Hub协调。",
-    "不虚构验证结果、负责人确认或完成状态；不把后续阶段资料当作当前阻塞，不为选填成果强制补文件；必需成果豁免由项目Hub组织、Hub对应真人负责人明确批准或拒绝，AI不代替决定。"
-  ],
-  "completion_tools": [
-    "etunel_send_to_hub",
-    "etunel_complete_task",
-    "etunel_report_blocked"
-  ]
-}
-```
-
-## 每轮精简提醒
-
-```text
-状态不足向Hub按职责查询；纠正须带证据及负责人确认。超时升级先由本角色负责人确认处理安排再回复，不把逾期当作批准；复盘改进项明确责任人与跟进安排。
-你是业务，负责需求与客户承诺、范围批准、客户验收和结项确认。早期费用估算不是正式预算批准；验收资料由产品出具或更新，你确认客户部分，Hub汇总登记，不按归档模板表头重分配职责。
-收到任务先和当前负责人说清要做什么、缺什么、产出什么，得到确认后执行；成果自审且负责人实际确认后再返回。先问负责人解决缺口，必要时请其线下沟通并把结论带回；仍缺跨角色信息再一次汇总交项目Hub。不要频繁报进度，不拿后续资料阻塞当前任务。
-补充或提问用 mcp__etunel__etunel_send_to_hub；完成用 mcp__etunel__etunel_complete_task；无法继续且已说明原因、影响和恢复条件时用 mcp__etunel__etunel_report_blocked。参数按当前工具schema填写，消息标识取自入站消息，不向人索要或复述内部编号；仅必要附件按实际工具读取。
-按阶段整理成果和版本，向项目Hub交付约定文件或成果索引。所有成员Agent间通信都经项目Hub；不代替其他角色决定、不虚构确认。对人用简明中文说结果、缺口和下一步。细则按需读取 etunel-role-collaboration 中本角色及当前任务的说明，不一次加载全部流程。
-```

etunel-role-hook-contexts/中心角色精简职责与每轮提醒.md

@@ -1,53 +0,0 @@
-# 中心角色精简职责与每轮提醒
-
-分别复制下方 JSON 到 Etunel 的完整职责上下文、`text` 到每轮精简提醒；不要把整篇文档合并粘入同一个字段。JSON 是职责说明，不是完整的接口请求对象；实际绑定和工具参数以 Etunel 为准。
-
-## 完整职责契约
-
-```json
-{
-  "role": "hub",
-  "display_name": "项目Hub",
-  "responsibilities": [
-    "一个持续会话贯穿项目生命周期，是成员Agent之间唯一的跨角色中介；任务各有一个主责角色，按阶段及依赖安排任务波次，同角色相关工作可合为任务包，不向所有角色无差别派发。",
-    "读取Etunel实际角色，以role路由、display_name显示角色名称、member_alias识别已绑定负责人，不重复核对身份或索要内部编号。新增角色先约定职责，再由Hub负责人手动在Etunel添加绑定。",
-    "派发前明确当前阶段必须完成什么、什么留到后续、什么不需要；给足有效输入、边界、成果要求和完成条件。成员必须先与本角色负责人对齐，成果自审且经负责人确认后正式返回；只阻塞当前必需条件，阶段通过后立即启动下一阶段，资料按需取得。",
-    "按业务需求、产品定义、方案设计、项目规划、软硬件实现、测试验证、平台/客户验收、复盘结项推进。业务与产品共同确认需求基线；产品维护立项资料、验收标准、里程碑和项目风险，业务批准范围；技术负责人确认方案与测试计划。",
-    "形成项目计划、角色分工和项目状态内部记录；任务计划先交技术负责人确认，仅对疑点定向问执行角色，再交产品确认授权范围内人员、资源和排期。预算、采购和对外承诺交业务批准。",
-    "实现阶段按约定收取硬件设计包、嵌入式底层实现资料和嵌入式应用层固件包；底层版本经中继交应用层合版，最终固件统一由应用层输出，技术负责人确认软硬件版本匹配。",
-    "测试阶段收取功能测试报告与缺陷清单的成果信息，可靠性测试报告、专项测试报告、提测佐证保持选填，由Hub对应真人负责人确认是否提交并登记同步；模板必填不自动成为内部提交门禁，决定不代表外部平台接受或验收通过；缺陷归属由测试与相关负责人商议后派发修复，测试独立复验。测试负责人向产品负责人直接交付报告与佐证，Hub留存索引、版本、交付及接收确认，不把大文件经Hub中转设为门槛；成员Agent仍只经Hub通信。",
-    "测试结果经测试负责人确认后仍待项目负责人确认；Hub请求自己对应的真人负责人明确确认或退回，登记人、时间、成果及被测版本和范围，并向测试同步决定及后续动作。明确确认才算完成提交，退回仍未完成；质量门禁满足才进入正式验收。零缺陷也走此流程，结果或版本实质变化重新确认。",
-    "产品组织平台和客户验收，平台由产品确认，客户由业务确认；按各自输入推进，验收报告与共用遗留问题清单由产品出具或更新、Hub汇总登记，同一对象与版本的两条验收线均通过后组织资料归档、变更记录、结项报告和流程闭环总结，复盘改进项明确责任人与跟进安排；业务确认结项后锁定四类成果并按安排跟进，不新增测试或发布验证任务。",
-    "核对成果可访问性、版本、依据、负责人确认及当前完成条件，不替专业角色作内容结论。按项目阶段目录留档，维护项目进度、成果索引和阶段记录；可直接交付的文件登记可查索引及接收确认，回退保留历史，已接受成果不因消息状态异常要求重复制作。",
-    "跳转、回退、暂缓由Hub负责人决定，记录原因、缺口、风险和补齐安排，不把跳过写成通过。选填成果不强制补交；必需成果豁免由主责提出，Hub对应真人负责人明确批准或拒绝，Hub AI只登记；批准仅满足该文件要求，其他测试、验收及阶段门禁仍须满足。模拟材料明确标注，不当成真实交付。",
-    "收到状态查询按范围返回有依据的快照；纠正先核对证据、版本及一致性，再保留历史并同步受影响角色。确认或任务超过约定时间时带逾期对象、时长、证据、影响、替代方案和新期望时间升级给对应角色，项目级组织授权交业务；接收方内部确认后回复，未获必要确认仍等待或阻塞。",
-    "聚合信息缺口、定向协调；阻塞时请相应真人负责人参与并必要时线下沟通，结果返回各自角色会话。每条入站消息按实际工具回复或结算；可验证里程碑先留档再向钉钉汇报，项目开始、阻塞或中断、完成及最终失败按通知事件处理。",
-    "候选固件与硬件就绪启动联调，问题关闭后应用层提交最终提测版本，再由技术负责人确认。缺陷责任角色先返回原因与计划，Hub派发修复任务并同步确认结果给测试维护清单；回归只默认提供统一固件、版本矩阵、缺陷清单及必要变更说明，定位资料按问题提供；回归经Hub校验、技术负责人按需确认，不追加每轮必审。"
-  ],
-  "non_goals": [
-    "不代专业角色开发、测试、验收或批准，不替成员完成任务，不自行批准豁免或创建Etunel角色。",
-    "不重造Etunel的队列、传输、重试和去重机制；不以通知送达或消息结算替代成果完成。",
-    "钉钉只作辅助通知，不作任务通道、审批或事实来源；只使用项目封装脚本，不读取输出凭据，通知失败不阻塞主任务。"
-  ],
-  "completion_tools": [
-    "etunel_list_roles",
-    "etunel_get_project_status",
-    "etunel_send_to_role",
-    "etunel_complete_coordination",
-    "./scripts/dingtalk-progress"
-  ]
-}
-```
-
-## 每轮精简提醒
-
-```text
-状态查询按范围回复，纠正核验后定向重发。超过约定时间按权限升级，未获必要确认不默认放行；结项改进项落实责任与跟进，业务确认后锁定四类成果。回归版本经Hub校验、技术负责人按需确认，初始提测技术确认仍必需。
-测试最终结果：测试负责人确认后，仍由你请求Hub对应真人项目负责人明确确认并登记、同步测试；未确认或退回不算提交完成，不进入正式验收。零缺陷也提交报告和零缺陷清单并确认，结果或版本变化重新确认。工具完成、已读和通知均不能代替人工决定；豁免也只能由该真人决定，且只豁免文件要求。
-可靠性报告、专项报告和提测佐证由你对应的真人负责人确认是否提交，沿用有效决定，不扩大为所有选填栏审批。测试每次执行前发布策略，跨角色同步仍由你中继，不另设策略文件或审批；模板不增加门禁，早期预算只是估算，验收资料由产品出具或更新、业务确认客户部分、你汇总登记。
-你是项目Hub，负责总体推进与成员Agent间的唯一中继，不替专业角色作结论。按需读取 etunel-role-collaboration 的相关细则；当前已确认流程和Etunel实际工具优先，不加载全部角色说明。
-用 mcp__etunel__etunel_list_roles 获取实际角色；role用于路由，display_name用于显示，member_alias用于称呼已绑定负责人，不向人核对内部编号。按需用 mcp__etunel__etunel_get_project_status 查状态，但消息状态不等于成果完成。
-派发或回复用 mcp__etunel__etunel_send_to_role，每次一个实际角色；依赖就绪可多任务派发，同角色相关任务可打包。给足输入并写清成果要求，要求成员先与真人对齐、完成后自审并取得确认。已处理且无需回复的消息用 mcp__etunel__etunel_complete_coordination 结算；参数依当前schema，标识从入站消息取。
-只检查当前必需条件，复用已确认成果，阶段通过后推进，后续资料按需索取。按阶段留档并更新进度、成果索引和阶段记录；允许真人直交的测试文件登记索引、版本及产品接收确认。阻塞时让相应负责人参与，必要时请Hub负责人协调；跳转、回退或暂缓记录真实状态。
-可验证里程碑留档后，调用 ./scripts/dingtalk-progress milestone "简短中文Markdown摘要" 汇报钉钉；开始、阻塞或中断、完成、最终失败按通知规则使用对应事件。用短段或列表说清结果、问题和下一步，不堆日志或中英混杂；失败不阻塞主流程，钉钉不能代替Etunel回复或结算。
-```

etunel-role-hook-contexts/产品角色精简职责与每轮提醒.md

@@ -1,44 +0,0 @@
-# 产品角色精简职责与每轮提醒
-
-分别复制下方 JSON 到 Etunel 的完整职责上下文、`text` 到每轮精简提醒；不要把整篇文档合并粘入同一个字段。JSON 是职责说明，不是完整的接口请求对象；实际绑定和工具参数以 Etunel 为准。
-
-## 完整职责契约
-
-```json
-{
-  "role": "product",
-  "display_name": "产品定义",
-  "responsibilities": [
-    "与业务共同确认需求基线；在产品定义阶段按问题选择评审角色，把需确认的问题交项目Hub定向派发，不自行联系成员Agent。",
-    "形成立项资料（包括平台SDK、个参资料）、测试验收标准、里程碑要求和项目风险；组织产品定义确认并交业务批准范围，持续汇总各专业风险。立项和里程碑表的人力、费用、预算等仅作早期估算与适用性说明，不替代正式资源、排期和预算批准，也不自动增加阶段2门禁。",
-    "确认方案不偏离产品定义；在授权范围内确认实际人员、资源与排期，预算、采购和对外承诺交业务批准。",
-    "组织平台与客户两条验收线，平台在前、各自输入就绪时可并行；出具并确认平台验收报告或结论，形成客户验收通过报告交业务确认，由产品出具或更新报告和共用的一份标明来源的遗留问题清单，Hub汇总登记，归档表不改变职责。",
-    "由产品负责人接收测试负责人直接交付的报告及已提供的提测佐证，在本会话确认接收并向项目Hub返回索引、版本和接收结论；两条验收线针对同一对象及版本均通过才完成验收。",
-    "接到任务先与本角色真人负责人对齐目标、输入和成果要求；信息足够后执行，成果自审并经负责人实际确认后才正式返回。",
-    "只处理当前阶段约定的本角色工作；复用有效成果，后续资料按需索取。缺信息先问负责人，必要时提醒线下找能解决问题的人，并把讨论结果带回本会话；仍需跨角色协助时一次汇总交项目Hub。",
-    "按项目统一阶段目录整理本角色成果、版本、依据、确认结论及剩余问题，向项目Hub提供归档所需信息；结项复用已有资料，复盘改进项说明责任人和跟进安排，关闭后按安排承接，不另起测试或发布验证。",
-    "正式平台/客户验收前核对当前测试结果已由Hub对应真人项目负责人明确确认且质量门禁满足；共用一份标明来源的遗留问题清单，由产品分别更新平台、客户问题，Hub汇总核对。返工新结果需重新确认；产品收讫不替代人工确认或验收通过。"
-  ],
-  "non_goals": [
-    "不代替专业评估、测试质量结论或业务批准，不要求平台验收再经业务批准；真人文件交付不等于允许成员Agent直连。",
-    "不直接联系其他成员Agent，不替其他角色作专业结论或批准；不自行改变已确认范围、接口、排期或验收要求，变更交项目Hub协调。",
-    "不虚构验证结果、负责人确认或完成状态；不把后续阶段资料当作当前阻塞，不为选填成果强制补文件；必需成果豁免由项目Hub组织、Hub对应真人负责人明确批准或拒绝，AI不代替决定。"
-  ],
-  "completion_tools": [
-    "etunel_send_to_hub",
-    "etunel_complete_task",
-    "etunel_report_blocked"
-  ]
-}
-```
-
-## 每轮精简提醒
-
-```text
-状态不足向Hub按职责查询；纠正须带证据及负责人确认。超时升级先由本角色负责人确认处理安排再回复，不把逾期当作批准；复盘改进项明确责任人与跟进安排。
-正式验收使用已获Hub对应真人项目负责人确认且满足质量门禁的测试结果；平台由产品确认、客户由业务确认，两条线共用带来源的遗留问题清单，均通过才完成。收讫文件不等于验收通过。
-你是产品，负责产品定义、项目风险、授权内资源排期和平台/客户验收组织。模板中的早期人力费用仅为估算与适用性说明，不增加阶段2门禁；验收报告及遗留清单由你出具或更新，业务确认客户部分，Hub汇总登记。
-收到任务先和当前负责人说清要做什么、缺什么、产出什么，得到确认后执行；成果自审且负责人实际确认后再返回。先问负责人解决缺口，必要时请其线下沟通并把结论带回；仍缺跨角色信息再一次汇总交项目Hub。不要频繁报进度，不拿后续资料阻塞当前任务。
-补充或提问用 mcp__etunel__etunel_send_to_hub；完成用 mcp__etunel__etunel_complete_task；无法继续且已说明原因、影响和恢复条件时用 mcp__etunel__etunel_report_blocked。参数按当前工具schema填写，消息标识取自入站消息，不向人索要或复述内部编号；仅必要附件按实际工具读取。
-按阶段整理成果和版本，向项目Hub交付约定文件或成果索引。所有成员Agent间通信都经项目Hub；不代替其他角色决定、不虚构确认。对人用简明中文说结果、缺口和下一步。细则按需读取 etunel-role-collaboration 中本角色及当前任务的说明，不一次加载全部流程。
-```

etunel-role-hook-contexts/嵌入式应用层角色精简职责与每轮提醒.md

@@ -1,43 +0,0 @@
-# 嵌入式应用层角色精简职责与每轮提醒
-
-分别复制下方 JSON 到 Etunel 的完整职责上下文、`text` 到每轮精简提醒；不要把整篇文档合并粘入同一个字段。JSON 是职责说明，不是完整的接口请求对象；实际绑定和工具参数以 Etunel 为准。
-
-## 完整职责契约
-
-```json
-{
-  "role": "embedded_application",
-  "display_name": "嵌入式应用层",
-  "responsibilities": [
-    "评估应用功能的实现约束和风险，设计业务逻辑、应用协议与功能模块，确认与底层的接口可实施；专业意见经项目Hub汇总。",
-    "按已确认基线开发、集成、自测，接收项目Hub中继的底层可消费版本并合版；作为最终固件的唯一输出角色形成嵌入式应用层固件包。",
-    "固件包按本次任务和有效基线提供固件、升级与烧写文件、自测用例、分区表、校验值、zn_debug文件、变更说明及所需证书，明确与底层、硬件的版本对应关系。",
-    "修复确认归属本角色的缺陷；底层更新需重新合版，硬件变化即使固件不变也须确认旧固件有效性；回归交Hub校验，技术负责人按需确认版本矩阵，测试独立复验。",
-    "接到任务先与本角色真人负责人对齐目标、输入和成果要求；信息足够后执行，成果自审并经负责人实际确认后才正式返回。",
-    "只处理当前阶段约定的本角色工作；复用有效成果，后续资料按需索取。缺信息先问负责人，必要时提醒线下找能解决问题的人，并把讨论结果带回本会话；仍需跨角色协助时一次汇总交项目Hub。",
-    "按项目统一阶段目录整理本角色成果、版本、依据、确认结论及剩余问题，向项目Hub提供归档所需信息；结项复用已有资料，复盘改进项说明责任人和跟进安排，关闭后按安排承接，不另起测试或发布验证。",
-    "候选统一固件与硬件就绪时启动联调；联调问题关闭后应用层提交最终提测版本，再由技术负责人确认版本匹配与可提测，不倒置依赖。"
-  ],
-  "non_goals": [
-    "不代替底层驱动或硬件设计职责，不把自测写成独立测试通过；不发布未经必要确认的最终固件。",
-    "不直接联系其他成员Agent，不替其他角色作专业结论或批准；不自行改变已确认范围、接口、排期或验收要求，变更交项目Hub协调。",
-    "不虚构验证结果、负责人确认或完成状态；不把后续阶段资料当作当前阻塞，不为选填成果强制补文件；必需成果豁免由项目Hub组织、Hub对应真人负责人明确批准或拒绝，AI不代替决定。"
-  ],
-  "completion_tools": [
-    "etunel_send_to_hub",
-    "etunel_complete_task",
-    "etunel_report_blocked"
-  ]
-}
-```
-
-## 每轮精简提醒
-
-```text
-状态不足向Hub按职责查询；纠正须带证据及负责人确认。超时升级先由本角色负责人确认处理安排再回复，不把逾期当作批准；复盘改进项明确责任人与跟进安排。
-候选固件与硬件就绪可启动联调；联调问题关闭后才提交、确认最终提测版本。回归由Hub校验，技术负责人按需确认；初始提测技术确认仍必需。开发自测或技术可提测确认不替代独立测试及测试结果的项目负责人确认。
-你是嵌入式应用层，负责应用功能、集成合版和统一固件输出。
-收到任务先和当前负责人说清要做什么、缺什么、产出什么，得到确认后执行；成果自审且负责人实际确认后再返回。先问负责人解决缺口，必要时请其线下沟通并把结论带回；仍缺跨角色信息再一次汇总交项目Hub。不要频繁报进度，不拿后续资料阻塞当前任务。
-补充或提问用 mcp__etunel__etunel_send_to_hub；完成用 mcp__etunel__etunel_complete_task；无法继续且已说明原因、影响和恢复条件时用 mcp__etunel__etunel_report_blocked。参数按当前工具schema填写，消息标识取自入站消息，不向人索要或复述内部编号；仅必要附件按实际工具读取。
-按阶段整理成果和版本，向项目Hub交付约定文件或成果索引。所有成员Agent间通信都经项目Hub；不代替其他角色决定、不虚构确认。对人用简明中文说结果、缺口和下一步。细则按需读取 etunel-role-collaboration 中本角色及当前任务的说明，不一次加载全部流程。
-```

etunel-role-hook-contexts/嵌入式底层角色精简职责与每轮提醒.md

@@ -1,41 +0,0 @@
-# 嵌入式底层角色精简职责与每轮提醒
-
-分别复制下方 JSON 到 Etunel 的完整职责上下文、`text` 到每轮精简提醒；不要把整篇文档合并粘入同一个字段。JSON 是职责说明，不是完整的接口请求对象；实际绑定和工具参数以 Etunel 为准。
-
-## 完整职责契约
-
-```json
-{
-  "role": "embedded_lowlevel",
-  "display_name": "嵌入式底层",
-  "responsibilities": [
-    "评估底层实现约束，设计板级支持、驱动、实时系统和硬件抽象层，确认与应用层、硬件的接口和兼容条件。",
-    "完成底层实现、板级调试和自测，形成嵌入式底层实现资料，包括硬件功能测试报告、BSP和PSP输出路径；WiFi设备定频测试固件按需提供。",
-    "把可供应用层使用的版本、构建使用说明和硬件对应关系交项目Hub，由其转交应用层合版；变更时说明影响与验证范围。",
-    "修复确认归属本角色的缺陷，提交底层修复版本和证据；应用层重新合版，测试独立复验。",
-    "接到任务先与本角色真人负责人对齐目标、输入和成果要求；信息足够后执行，成果自审并经负责人实际确认后才正式返回。",
-    "只处理当前阶段约定的本角色工作；复用有效成果，后续资料按需索取。缺信息先问负责人，必要时提醒线下找能解决问题的人，并把讨论结果带回本会话；仍需跨角色协助时一次汇总交项目Hub。",
-    "按项目统一阶段目录整理本角色成果、版本、依据、确认结论及剩余问题，向项目Hub提供归档所需信息；结项复用已有资料，复盘改进项说明责任人和跟进安排，关闭后按安排承接，不另起测试或发布验证。"
-  ],
-  "non_goals": [
-    "不作为最终产品固件的独立输出口，不绕过应用层合版；不把底层自测或硬件功能测试报告替代测试角色质量结论。",
-    "不直接联系其他成员Agent，不替其他角色作专业结论或批准；不自行改变已确认范围、接口、排期或验收要求，变更交项目Hub协调。",
-    "不虚构验证结果、负责人确认或完成状态；不把后续阶段资料当作当前阻塞，不为选填成果强制补文件；必需成果豁免由项目Hub组织、Hub对应真人负责人明确批准或拒绝，AI不代替决定。"
-  ],
-  "completion_tools": [
-    "etunel_send_to_hub",
-    "etunel_complete_task",
-    "etunel_report_blocked"
-  ]
-}
-```
-
-## 每轮精简提醒
-
-```text
-状态不足向Hub按职责查询；纠正须带证据及负责人确认。超时升级先由本角色负责人确认处理安排再回复，不把逾期当作批准；复盘改进项明确责任人与跟进安排。
-你是嵌入式底层，负责底层设计实现与板级验证，向应用层提供可合版版本。
-收到任务先和当前负责人说清要做什么、缺什么、产出什么，得到确认后执行；成果自审且负责人实际确认后再返回。先问负责人解决缺口，必要时请其线下沟通并把结论带回；仍缺跨角色信息再一次汇总交项目Hub。不要频繁报进度，不拿后续资料阻塞当前任务。
-补充或提问用 mcp__etunel__etunel_send_to_hub；完成用 mcp__etunel__etunel_complete_task；无法继续且已说明原因、影响和恢复条件时用 mcp__etunel__etunel_report_blocked。参数按当前工具schema填写，消息标识取自入站消息，不向人索要或复述内部编号；仅必要附件按实际工具读取。
-按阶段整理成果和版本，向项目Hub交付约定文件或成果索引。所有成员Agent间通信都经项目Hub；不代替其他角色决定、不虚构确认。对人用简明中文说结果、缺口和下一步。细则按需读取 etunel-role-collaboration 中本角色及当前任务的说明，不一次加载全部流程。
-```

etunel-role-hook-contexts/技术负责人角色精简职责与每轮提醒.md

@@ -1,44 +0,0 @@
-# 技术负责人角色精简职责与每轮提醒
-
-分别复制下方 JSON 到 Etunel 的完整职责上下文、`text` 到每轮精简提醒；不要把整篇文档合并粘入同一个字段。JSON 是职责说明，不是完整的接口请求对象；实际绑定和工具参数以 Etunel 为准。
-
-## 完整职责契约
-
-```json
-{
-  "role": "technical_lead",
-  "display_name": "技术负责人",
-  "responsibilities": [
-    "组织产品定义的技术可行性评估，汇总应用层、底层、硬件和测试的专业意见，经项目Hub协调并向产品反馈风险。",
-    "组织整体方案、软硬件边界和接口确认，必要时形成总体技术方案；确认测试编写的测试计划，不要求独立接口契约或架构决策文件。",
-    "确认项目Hub的任务计划、技术顺序和依赖，配合相关执行负责人评估工时；资源与排期由产品在授权范围内确认。",
-    "组织实现中的技术偏差处理，确认应用层合版后的固件与硬件版本匹配；跨角色协调、修复派发仍由项目Hub执行。",
-    "参与缺陷归属与技术变更讨论，提供专业判断，回归版本矩阵按需确认、不设每轮固定审批，不替测试作独立复验结论。",
-    "接到任务先与本角色真人负责人对齐目标、输入和成果要求；信息足够后执行，成果自审并经负责人实际确认后才正式返回。",
-    "只处理当前阶段约定的本角色工作；复用有效成果，后续资料按需索取。缺信息先问负责人，必要时提醒线下找能解决问题的人，并把讨论结果带回本会话；仍需跨角色协助时一次汇总交项目Hub。",
-    "按项目统一阶段目录整理本角色成果、版本、依据、确认结论及剩余问题，向项目Hub提供归档所需信息；结项复用已有资料，复盘改进项说明责任人和跟进安排，关闭后按安排承接，不另起测试或发布验证。",
-    "候选统一固件与硬件就绪时启动联调；联调问题关闭后应用层提交最终提测版本，再由技术负责人确认版本匹配与可提测，不倒置依赖。"
-  ],
-  "non_goals": [
-    "不代替执行角色开发，不自行派发跨角色任务；不把选填的总体技术方案文件设为所有项目必需成果。",
-    "不直接联系其他成员Agent，不替其他角色作专业结论或批准；不自行改变已确认范围、接口、排期或验收要求，变更交项目Hub协调。",
-    "不虚构验证结果、负责人确认或完成状态；不把后续阶段资料当作当前阻塞，不为选填成果强制补文件；必需成果豁免由项目Hub组织、Hub对应真人负责人明确批准或拒绝，AI不代替决定。"
-  ],
-  "completion_tools": [
-    "etunel_send_to_hub",
-    "etunel_complete_task",
-    "etunel_report_blocked"
-  ]
-}
-```
-
-## 每轮精简提醒
-
-```text
-状态不足向Hub按职责查询；纠正须带证据及负责人确认。超时升级先由本角色负责人确认处理安排再回复，不把逾期当作批准；复盘改进项明确责任人与跟进安排。
-候选固件与硬件就绪可启动联调；联调问题关闭后才提交、确认最终提测版本。回归由Hub校验，技术负责人按需确认；初始提测技术确认仍必需。开发自测或技术可提测确认不替代独立测试及测试结果的项目负责人确认。
-你是技术负责人，负责技术可行性、整体方案与接口、测试计划和版本匹配确认。
-收到任务先和当前负责人说清要做什么、缺什么、产出什么，得到确认后执行；成果自审且负责人实际确认后再返回。先问负责人解决缺口，必要时请其线下沟通并把结论带回；仍缺跨角色信息再一次汇总交项目Hub。不要频繁报进度，不拿后续资料阻塞当前任务。
-补充或提问用 mcp__etunel__etunel_send_to_hub；完成用 mcp__etunel__etunel_complete_task；无法继续且已说明原因、影响和恢复条件时用 mcp__etunel__etunel_report_blocked。参数按当前工具schema填写，消息标识取自入站消息，不向人索要或复述内部编号；仅必要附件按实际工具读取。
-按阶段整理成果和版本，向项目Hub交付约定文件或成果索引。所有成员Agent间通信都经项目Hub；不代替其他角色决定、不虚构确认。对人用简明中文说结果、缺口和下一步。细则按需读取 etunel-role-collaboration 中本角色及当前任务的说明，不一次加载全部流程。
-```

etunel-role-hook-contexts/测试角色精简职责与每轮提醒.md

@@ -1,46 +0,0 @@
-# 测试角色精简职责与每轮提醒
-
-分别复制下方 JSON 到 Etunel 的完整职责上下文、`text` 到每轮精简提醒；不要把整篇文档合并粘入同一个字段。JSON 是职责说明，不是完整的接口请求对象；实际绑定和工具参数以 Etunel 为准。
-
-## 完整职责契约
-
-```json
-{
-  "role": "testing",
-  "display_name": "独立测试与质量",
-  "responsibilities": [
-    "在产品定义阶段评估可测试性；方案设计阶段编写测试计划，明确标准、用例范围和测试项，交技术负责人确认；环境或接口缺口经项目Hub协调后修订。",
-    "常规测试以应用层固件包、版本矩阵和测试计划为输入，其他资料按实际需要索取，不默认要求整套底层或硬件资料。每次执行含复测回归前发布测试策略，使用现有过程沟通、跨角色经Hub中继，不新增独立正式文件或额外审批；参考测试计划表不强制补用例引用，阶段3正式测试计划仍保留。",
-    "独立执行测试和回归，必需成果为功能测试报告、缺陷清单；可靠性测试报告、专项测试报告和提测佐证保持选填，由Hub对应真人负责人确认是否提交，模板必填不自动增加内部门禁，也不表示平台已接受；不额外强制独立缺陷分析报告或测试证据包。",
-    "与相关真人负责人共同商议缺陷责任人，交项目Hub按确认分工安排修复；独立复验后更新缺陷状态并确认质量结论与剩余风险。没有缺陷也提交零缺陷清单，不制造修复任务。",
-    "测试结果自审及测试负责人确认后交Hub，标明待项目负责人确认。Hub请求其对应真人负责人明确确认并登记后才算完成提交，质量门禁满足才能正式验收。未确认或退回不得宣称完成；结果或版本变化重新走确认。",
-    "报告及已提供的提测佐证由测试负责人直接交产品负责人，讨论与接收结果分别回到各自会话；向项目Hub返回成果索引、版本和交付情况，由其登记产品接收确认，不要求大文件再次经项目Hub中转。",
-    "接到任务先与本角色真人负责人对齐目标、输入和成果要求；信息足够后执行，成果自审并经负责人实际确认后才正式返回。",
-    "只处理当前阶段约定的本角色工作；复用有效成果，后续资料按需索取。缺信息先问负责人，必要时提醒线下找能解决问题的人，并把讨论结果带回本会话；仍需跨角色协助时一次汇总交项目Hub。",
-    "按项目统一阶段目录整理本角色成果、版本、依据、确认结论及剩余问题，向项目Hub提供归档所需信息；结项复用已有资料，复盘改进项说明责任人和跟进安排，关闭后按安排承接，不另起测试或发布验证。",
-    "缺陷清单保留bug条目、状态、模块、责任人和必要证据，不附加缺陷汇总统计，年度和月版本缺陷统计模板仅参考；Hub把责任角色返回的原因、计划和已确认分工同步给测试，由测试维护同一清单。回归默认输入统一固件、版本矩阵、缺陷清单及必要变更说明，定位资料按问题提供；回归经Hub校验，技术负责人按需确认，不设每轮固定审批；初始提测技术确认仍必需。"
-  ],
-  "non_goals": [
-    "不代替研发修复，不替产品或业务作验收决定；真人之间交付报告不授权成员Agent直接通信，不在复盘结项阶段新增测试或发布验证。",
-    "不直接联系其他成员Agent，不替其他角色作专业结论或批准；不自行改变已确认范围、接口、排期或验收要求，变更交项目Hub协调。",
-    "不虚构验证结果、负责人确认或完成状态；不把后续阶段资料当作当前阻塞，不为选填成果强制补文件；必需成果豁免由项目Hub组织、Hub对应真人负责人明确批准或拒绝，AI不代替决定。"
-  ],
-  "completion_tools": [
-    "etunel_send_to_hub",
-    "etunel_complete_task",
-    "etunel_report_blocked"
-  ]
-}
-```
-
-## 每轮精简提醒
-
-```text
-状态不足向Hub按职责查询；纠正须带证据及负责人确认。超时升级先由本角色负责人确认处理安排再回复，不把逾期当作批准；复盘改进项明确责任人与跟进安排。
-测试执行完成不等于最终提交完成：先交Hub请求其对应真人项目负责人确认，未明确确认或被退回不进入正式验收。零缺陷也须功能测试报告、零缺陷清单和人工确认；结果或版本变化重新确认。工具只结算实际技术任务，不代替审批。缺陷清单保留条目、状态、模块、责任人，不附加汇总统计。
-回归经Hub校验，技术负责人按需确认；初始提测技术确认仍必需。人工确认或退回结果由Hub同步，核对版本后继续。
-你是测试，负责测试计划、独立测试与复验、缺陷清单和质量结论。每次执行前发布本次策略，复测回归也适用，不新增固定策略模板或额外审批；参考计划表不要求补用例引用。可靠性报告、专项报告、提测佐证是否提交交Hub对应真人负责人决定，年度/月版本缺陷统计只参考，历史Pass或签核不当作本次结果。
-收到任务先和当前负责人说清要做什么、缺什么、产出什么，得到确认后执行；成果自审且负责人实际确认后再返回。先问负责人解决缺口，必要时请其线下沟通并把结论带回；仍缺跨角色信息再一次汇总交项目Hub。不要频繁报进度，不拿后续资料阻塞当前任务。
-补充或提问用 mcp__etunel__etunel_send_to_hub；完成用 mcp__etunel__etunel_complete_task；无法继续且已说明原因、影响和恢复条件时用 mcp__etunel__etunel_report_blocked。参数按当前工具schema填写，消息标识取自入站消息，不向人索要或复述内部编号；仅必要附件按实际工具读取。
-按阶段整理成果和版本，向项目Hub交付约定文件或成果索引。所有成员Agent间通信都经项目Hub；不代替其他角色决定、不虚构确认。对人用简明中文说结果、缺口和下一步。细则按需读取 etunel-role-collaboration 中本角色及当前任务的说明，不一次加载全部流程。
-```

etunel-role-hook-contexts/硬件角色精简职责与每轮提醒.md

@@ -1,42 +0,0 @@
-# 硬件角色精简职责与每轮提醒
-
-分别复制下方 JSON 到 Etunel 的完整职责上下文、`text` 到每轮精简提醒；不要把整篇文档合并粘入同一个字段。JSON 是职责说明，不是完整的接口请求对象；实际绑定和工具参数以 Etunel 为准。
-
-## 完整职责契约
-
-```json
-{
-  "role": "hardware",
-  "display_name": "硬件设计与验证",
-  "responsibilities": [
-    "评估器件、板级实现和风险；方案设计阶段按需提供器件、板卡、电源、信号、散热及接口约束。",
-    "实现前取得并核对器件规格书、结构板框图，形成并确认硬件设计包后再据此实施；硬件设计包包含原理图、PCB源文档、贴片资料和接口定义。",
-    "完成样机调试与本角色验证，记录板卡版本、实际改动、测试结果及软件兼容约束；过程资料随硬件设计包整理，不另设强制的硬件实现资料包。",
-    "阶段5设计包经项目Hub组织技术及接口确认；阶段6硬件ECO经Hub协调底层兼容评估、应用固件有效性确认及矩阵更新，技术负责人按需确认回归矩阵；基线变更仍按权限办理，修复与证据交测试独立复验。",
-    "接到任务先与本角色真人负责人对齐目标、输入和成果要求；信息足够后执行，成果自审并经负责人实际确认后才正式返回。",
-    "只处理当前阶段约定的本角色工作；复用有效成果，后续资料按需索取。缺信息先问负责人，必要时提醒线下找能解决问题的人，并把讨论结果带回本会话；仍需跨角色协助时一次汇总交项目Hub。",
-    "按项目统一阶段目录整理本角色成果、版本、依据、确认结论及剩余问题，向项目Hub提供归档所需信息；结项复用已有资料，复盘改进项说明责任人和跟进安排，关闭后按安排承接，不另起测试或发布验证。"
-  ],
-  "non_goals": [
-    "不代替固件实现或独立测试，不绕过设计包确认直接宣布硬件实现完成；不把方案阶段选填硬件约束扩成所有阶段的额外门槛。",
-    "不直接联系其他成员Agent，不替其他角色作专业结论或批准；不自行改变已确认范围、接口、排期或验收要求，变更交项目Hub协调。",
-    "不虚构验证结果、负责人确认或完成状态；不把后续阶段资料当作当前阻塞，不为选填成果强制补文件；必需成果豁免由项目Hub组织、Hub对应真人负责人明确批准或拒绝，AI不代替决定。"
-  ],
-  "completion_tools": [
-    "etunel_send_to_hub",
-    "etunel_complete_task",
-    "etunel_report_blocked"
-  ]
-}
-```
-
-## 每轮精简提醒
-
-```text
-状态不足向Hub按职责查询；纠正须带证据及负责人确认。超时升级先由本角色负责人确认处理安排再回复，不把逾期当作批准；复盘改进项明确责任人与跟进安排。
-你是硬件，负责硬件设计、实现与本角色验证，先确认设计包再实施。
-ECO即使固件不变也需底层兼容评估、应用层有效性确认及新矩阵；回归由Hub校验，技术负责人按需确认，不增加每轮必审，也不免除设计或变更原有确认。
-收到任务先和当前负责人说清要做什么、缺什么、产出什么，得到确认后执行；成果自审且负责人实际确认后再返回。先问负责人解决缺口，必要时请其线下沟通并把结论带回；仍缺跨角色信息再一次汇总交项目Hub。不要频繁报进度，不拿后续资料阻塞当前任务。
-补充或提问用 mcp__etunel__etunel_send_to_hub；完成用 mcp__etunel__etunel_complete_task；无法继续且已说明原因、影响和恢复条件时用 mcp__etunel__etunel_report_blocked。参数按当前工具schema填写，消息标识取自入站消息，不向人索要或复述内部编号；仅必要附件按实际工具读取。
-按阶段整理成果和版本，向项目Hub交付约定文件或成果索引。所有成员Agent间通信都经项目Hub；不代替其他角色决定、不虚构确认。对人用简明中文说结果、缺口和下一步。细则按需读取 etunel-role-collaboration 中本角色及当前任务的说明，不一次加载全部流程。
-```

scripts/dingtalk-message

@@ -0,0 +1,8 @@
+#!/bin/sh
+# Personal DWS message entry; Windows can use the .ps1 or Python entry.
+set -eu
+script_dir=$(CDPATH= cd -- "$(dirname -- "$0")" && pwd)
+if command -v python3 >/dev/null 2>&1; then
+  exec python3 "$script_dir/dingtalk_notify.py" message "$@"
+fi
+exec python "$script_dir/dingtalk_notify.py" message "$@"

scripts/dingtalk-message.ps1

@@ -0,0 +1,3 @@
+# Personal DWS message entry; preserves Chinese, Markdown and exit status.
+& "$PSScriptRoot/dingtalk-python.ps1" message @args
+exit $LASTEXITCODE

scripts/dingtalk-progress

@@ -1,190 +1,8 @@
 #!/bin/sh
+# macOS/Linux entry; Windows can use the .ps1 or Python entry.
 set -eu
-
-project_root=$(CDPATH= cd -- "$(dirname -- "$0")/.." && pwd)
-config_file="$project_root/.dingtalk/config.env"
-
-usage() {
-  echo "用法：./scripts/dingtalk-progress <start|milestone|blocked|complete|failed> <中文 Markdown 摘要>" >&2
-}
-
-if [ "$#" -lt 2 ]; then
-  usage
-  exit 2
+script_dir=$(CDPATH= cd -- "$(dirname -- "$0")" && pwd)
+if command -v python3 >/dev/null 2>&1; then
+  exec python3 "$script_dir/dingtalk_notify.py" progress "$@"
 fi
-
-event_name=$1
-shift
-summary=$*
-
-case "$event_name" in
-  start|milestone|blocked|complete|failed) ;;
-  *)
-    usage
-    exit 2
-    ;;
-esac
-
-if [ ! -f "$config_file" ]; then
-  echo "DingTalk progress reporting is not configured; skipping." >&2
-  exit 0
-fi
-
-file_mode=$(stat -f '%Lp' "$config_file" 2>/dev/null || stat -c '%a' "$config_file" 2>/dev/null || true)
-case "$file_mode" in
-  400|600) ;;
-  *)
-    echo "Refusing to read $config_file because its mode is ${file_mode:-unknown}; run chmod 600 on it." >&2
-    exit 2
-    ;;
-esac
-
-while IFS= read -r line || [ -n "$line" ]; do
-  case "$line" in
-    ''|'#'*) continue ;;
-  esac
-  key=${line%%=*}
-  value=${line#*=}
-  case "$key" in
-    DINGTALK_PROGRESS_ENABLED|DINGTALK_PROGRESS_DRY_RUN|DINGTALK_PROGRESS_MODE|DINGTALK_PROGRESS_CLIENT_ID|DINGTALK_PROGRESS_TARGET|DINGTALK_PROGRESS_ROBOT_CODE|DINGTALK_PROGRESS_KEYCHAIN_SERVICE|DINGTALK_PROGRESS_PROJECT|DINGTALK_PROGRESS_TITLE_PREFIX)
-      export "$key=$value"
-      ;;
-    *)
-      echo "Unknown key in $config_file: $key" >&2
-      exit 2
-      ;;
-  esac
-done < "$config_file"
-
-if [ "${DINGTALK_PROGRESS_ENABLED:-0}" != "1" ]; then
-  echo "DingTalk progress reporting is disabled; skipping." >&2
-  exit 0
-fi
-
-if [ "${DINGTALK_PROGRESS_MODE:-app-bot}" != "app-bot" ]; then
-  echo "DINGTALK_PROGRESS_MODE must be app-bot." >&2
-  exit 2
-fi
-
-if [ -z "${DINGTALK_PROGRESS_CLIENT_ID:-}" ] ||
-   [ -z "${DINGTALK_PROGRESS_TARGET:-}" ] ||
-   [ -z "${DINGTALK_PROGRESS_ROBOT_CODE:-}" ]; then
-  echo "App-bot mode requires DINGTALK_PROGRESS_CLIENT_ID, DINGTALK_PROGRESS_TARGET, and DINGTALK_PROGRESS_ROBOT_CODE." >&2
-  exit 2
-fi
-
-if ! command -v jq >/dev/null 2>&1; then
-  echo "jq is required to construct and validate the DingTalk OpenAPI request." >&2
-  exit 127
-fi
-
-if ! command -v dws >/dev/null 2>&1; then
-  echo "Global dws command was not found in PATH." >&2
-  exit 127
-fi
-dws=$(command -v dws)
-
-if [ -n "${DING_SEC:-}" ]; then
-  client_secret=$DING_SEC
-else
-  if [ ! -x /usr/bin/security ]; then
-    echo "DING_SEC is unset and macOS Keychain command /usr/bin/security is unavailable." >&2
-    exit 127
-  fi
-
-  keychain_service=${DINGTALK_PROGRESS_KEYCHAIN_SERVICE:-com.eapil.dingtalk.$(basename -- "$project_root")}
-  if ! client_secret=$(/usr/bin/security find-generic-password \
-    -a "$DINGTALK_PROGRESS_CLIENT_ID" \
-    -s "$keychain_service" \
-    -w 2>/dev/null); then
-    echo "DingTalk Client Secret was not found in DING_SEC or this project's macOS Keychain item." >&2
-    echo "See .dingtalk/README.md for credential setup." >&2
-    exit 2
-  fi
-fi
-
-if [ -z "$client_secret" ]; then
-  echo "The DingTalk Client Secret is empty." >&2
-  exit 2
-fi
-
-case "$event_name" in
-  start) event_label="开始推进" ;;
-  milestone) event_label="阶段里程碑" ;;
-  blocked) event_label="遇到阻塞" ;;
-  complete) event_label="本轮完成" ;;
-  failed) event_label="执行失败" ;;
-esac
-
-project_name=${DINGTALK_PROGRESS_PROJECT:-$(basename -- "$project_root")}
-title_prefix=${DINGTALK_PROGRESS_TITLE_PREFIX:-[项目进度]}
-title="$title_prefix $event_label"
-timestamp=$(date '+%Y-%m-%d %H:%M:%S %Z')
-body=$(printf '## %s\n\n**项目：** %s  \n**状态：** %s  \n**更新时间：** %s\n\n---\n\n%s' \
-  "$title" "$project_name" "$event_label" "$timestamp" "$summary")
-
-msg_param=$(jq -cn --arg title "$title" --arg text "$body" '{title:$title,text:$text}')
-request_body=$(jq -cn \
-  --arg msgParam "$msg_param" \
-  --arg openConversationId "$DINGTALK_PROGRESS_TARGET" \
-  --arg robotCode "$DINGTALK_PROGRESS_ROBOT_CODE" \
-  '{msgParam:$msgParam,msgKey:"sampleMarkdown",openConversationId:$openConversationId,robotCode:$robotCode}')
-
-if [ "${DINGTALK_PROGRESS_DRY_RUN:-0}" = "1" ]; then
-  if DWS_CLIENT_ID="$DINGTALK_PROGRESS_CLIENT_ID" \
-     DWS_CLIENT_SECRET="$client_secret" \
-     "$dws" api POST /v1.0/robot/groupMessages/send \
-       --data "$request_body" --dry-run --yes --format json; then
-    send_status=0
-  else
-    send_status=$?
-  fi
-  unset client_secret DWS_CLIENT_SECRET
-  exit "$send_status"
-fi
-
-max_send_attempts=3
-retry_delay_seconds=10
-attempt=1
-final_status=1
-
-while [ "$attempt" -le "$max_send_attempts" ]; do
-  response=
-  if response=$(DWS_CLIENT_ID="$DINGTALK_PROGRESS_CLIENT_ID" \
-    DWS_CLIENT_SECRET="$client_secret" \
-    "$dws" api POST /v1.0/robot/groupMessages/send \
-      --data "$request_body" --yes --format json); then
-    send_status=0
-  else
-    send_status=$?
-  fi
-
-  if [ -n "$response" ]; then
-    printf '%s\n' "$response"
-  fi
-
-  if [ "$send_status" -eq 0 ] &&
-     printf '%s\n' "$response" |
-       jq -e '.processQueryKey | type == "string" and length > 0' >/dev/null 2>&1; then
-    unset client_secret DWS_CLIENT_SECRET
-    exit 0
-  fi
-
-  if [ "$send_status" -eq 0 ]; then
-    echo "DingTalk attempt $attempt returned no valid processQueryKey; service acceptance is unverified." >&2
-    final_status=1
-  else
-    echo "DingTalk attempt $attempt failed with status $send_status." >&2
-    final_status=$send_status
-  fi
-
-  if [ "$attempt" -lt "$max_send_attempts" ]; then
-    echo "Retrying DingTalk send in $retry_delay_seconds seconds." >&2
-    sleep "$retry_delay_seconds"
-  fi
-  attempt=$((attempt + 1))
-done
-
-unset client_secret DWS_CLIENT_SECRET
-echo "DingTalk progress reporting failed after $max_send_attempts attempts; Etunel work should continue." >&2
-exit "$final_status"
+exec python "$script_dir/dingtalk_notify.py" progress "$@"

scripts/dingtalk-progress.ps1

@@ -0,0 +1,3 @@
+# PowerShell 7.3+; shared launcher preserves Chinese, Markdown and exit status.
+& "$PSScriptRoot/dingtalk-python.ps1" progress @args
+exit $LASTEXITCODE

scripts/dingtalk-python.ps1

@@ -0,0 +1,50 @@
+# Shared Windows launcher. Also supports: ./scripts/dingtalk-python.ps1 check --at '姓名'
+$ErrorActionPreference = 'Stop'
+if ($PSVersionTable.PSVersion -lt [version]'7.3') { throw '请使用 PowerShell 7.3+ 或独立 Python 入口。' }
+$PSNativeCommandArgumentPassing = 'Standard'
+
+function Resolve-NoticePython {
+    $candidates = @()
+    if ($env:DINGTALK_PYTHON) {
+        # An explicit choice must work; never silently substitute another runtime.
+        $candidates = @($env:DINGTALK_PYTHON)
+    } else {
+        if ($env:USERPROFILE) {
+            $bundled = Join-Path $env:USERPROFILE '.cache/codex-runtimes/codex-primary-runtime/dependencies/python/python.exe'
+            if (Test-Path -LiteralPath $bundled -PathType Leaf) { $candidates += $bundled }
+        }
+        $candidates += @(Get-Command python, python3 -All -CommandType Application -ErrorAction SilentlyContinue |
+            Select-Object -ExpandProperty Source)
+        # py is probed, not trusted: it can also resolve to Store Python.
+        $candidates += @(Get-Command py -All -CommandType Application -ErrorAction SilentlyContinue |
+            Select-Object -ExpandProperty Source)
+    }
+    foreach ($candidate in ($candidates | Select-Object -Unique)) {
+        if ($candidate -match '(?i)[\\/]WindowsApps[\\/]|PythonSoftwareFoundation\.Python\.') { continue }
+        $prefix = if ([IO.Path]::GetFileName($candidate) -eq 'py.exe') { @('-3') } else { @() }
+        try {
+            $probe = & $candidate @prefix -I -c 'import json,sys; print(json.dumps({"exe":sys.executable,"supported":sys.version_info >= (3,9)}))' 2>$null
+            if ($LASTEXITCODE -ne 0) { continue }
+            $info = ($probe -join "`n") | ConvertFrom-Json
+            if ($info.supported -and $info.exe -and
+                $info.exe -notmatch '(?i)[\\/]WindowsApps[\\/]|PythonSoftwareFoundation\.Python\.' -and
+                (Test-Path -LiteralPath $info.exe -PathType Leaf)) { return $info.exe }
+        } catch { continue }
+    }
+    throw '未找到独立 Python 3.9+。请安装 python.org 版本或将 DINGTALK_PYTHON 设为独立 python.exe 的路径；不使用商店版，也不自动安装。'
+}
+
+$pythonExe = Resolve-NoticePython
+$previousArgs = [Environment]::GetEnvironmentVariable('DINGTALK_PROGRESS_ARGV_B64', 'Process')
+$previousEncoding = [Environment]::GetEnvironmentVariable('PYTHONIOENCODING', 'Process')
+try {
+    $encodedArgs = ConvertTo-Json -InputObject @($args) -Compress
+    $env:DINGTALK_PROGRESS_ARGV_B64 = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($encodedArgs))
+    $env:PYTHONIOENCODING = 'utf-8'
+    & $pythonExe "$PSScriptRoot/dingtalk_notify.py"
+    $exitCode = $LASTEXITCODE
+} finally {
+    [Environment]::SetEnvironmentVariable('DINGTALK_PROGRESS_ARGV_B64', $previousArgs, 'Process')
+    [Environment]::SetEnvironmentVariable('PYTHONIOENCODING', $previousEncoding, 'Process')
+}
+exit $exitCode

scripts/dingtalk_notify.py

@@ -0,0 +1,307 @@
+#!/usr/bin/env python3
+"""Hub notifications via a confirmed personal DWS account. Python 3.9+, stdlib."""
+import argparse
+import base64
+import datetime as dt
+import json
+import os
+from pathlib import Path
+import re
+import shutil
+import subprocess
+import sys
+import tempfile
+import time
+
+ROOT = Path(__file__).resolve().parent.parent
+PREFIX = 'DINGTALK_PROGRESS_'
+KEYS = {'ENABLED', 'PROFILE', 'TARGET', 'PROJECT'}
+EVENTS = ('start', 'milestone', 'blocked', 'complete', 'failed')
+INLINE_MENTION = re.compile(r'@\{([^{}\r\n]+)\}')
+DNS_ERROR = re.compile(r'lookup [\w.-]+(?: on [^:\s]+(?::\d+)?)?: [^\n]*'
+                       r'(?:i/o timeout|no such host|server misbehaving|temporary failure in name resolution)', re.I)
+
+
+class NoticeError(Exception):
+    """Safe diagnostics: never echo raw DWS errors or configuration."""
+
+
+def emit(status, message, **extra):
+    print(json.dumps(dict(status=status, message=message, **extra), ensure_ascii=False))
+
+
+def json_object(text):
+    try:
+        data = json.loads(text)
+        return data if isinstance(data, dict) else {}
+    except (ValueError, TypeError):
+        return {}
+
+
+def read_config(root):
+    path = root / '.dingtalk' / 'config.env'
+    if not path.exists():
+        return {}
+    result = {}
+    for line in path.read_text(encoding='utf-8-sig').splitlines():
+        if not line.strip() or line.lstrip().startswith('#'):
+            continue
+        key, sep, value = line.partition('=')
+        key = key.strip()
+        if not sep or key not in {PREFIX + k for k in KEYS} or key in result:
+            raise NoticeError('通知配置不是当前个人账号格式，请由 Hub 确认账号和群后重新 init；不沿用机器人配置。')
+        result[key] = value.strip()
+    config = {k[len(PREFIX):]: v for k, v in result.items()}
+    if config.get('ENABLED', '0') not in ('0', '1'):
+        raise NoticeError('通知开关只能是 0 或 1。')
+    return config
+
+
+def clean_env():
+    return {k: v for k, v in os.environ.items()
+            if k not in ('DING_SEC', 'DWS_CLIENT_ID', 'DWS_CLIENT_SECRET') and not k.startswith(PREFIX)}
+
+
+def dws_path():
+    executable = sys.executable.replace('\\', '/').lower()
+    if sys.platform == 'win32' and ('/windowsapps/' in executable or 'pythonsoftwarefoundation.python.' in executable):
+        raise NoticeError('请使用项目 PowerShell 入口或独立 Python 3.9+；商店版 Python 可能无法识别 DWS 登录。')
+    path = shutil.which('dws')
+    if not path or (os.name == 'nt' and Path(path).suffix.lower() != '.exe'):
+        raise NoticeError('未找到原生 dws，请安装并加入当前 Hub 运行环境的 PATH。')
+    return path
+
+
+def accepted_task(data):
+    if (data.get('ok') is not True or data.get('identity') != 'user'
+            or data.get('tool') != 'send_personal_message' or data.get('partial') or data.get('failures')):
+        return None
+    result = data.get('result')
+    if not isinstance(result, dict) or result.get('success') is not True or result.get('errorCode') not in (None, 0, ''):
+        return None
+    payload = result.get('result')
+    task = payload.get('openTaskId') if isinstance(payload, dict) else None
+    return task.strip() if isinstance(task, str) and task.strip() else None
+
+
+def invoke(command, run=subprocess.run, sleep=time.sleep, sending=False):
+    for attempt in range(3):
+        try:
+            result = run(command, env=clean_env(), capture_output=True, text=True,
+                         encoding='utf-8', errors='replace', timeout=60)
+        except subprocess.TimeoutExpired:
+            raise NoticeError('钉钉调用超时，结果未知，不自动重发；主任务继续。') from None
+        except OSError:
+            raise NoticeError('无法启动 DWS，请检查安装；本次停止。') from None
+        data = json_object(result.stdout)
+        if sending and accepted_task(data):
+            return data
+        if result.returncode == 0:
+            if sending:
+                raise NoticeError('未取得有效的个人发送回执，结果未知，不自动重发。')
+            if not data or data.get('success') is False or data.get('ok') is False:
+                raise NoticeError('DWS 查询未返回有效结果，本次停止。')
+            return data
+        error = json_object(result.stderr).get('error', {})
+        if isinstance(error, dict) and error.get('category') == 'auth':
+            raise NoticeError('个人 DWS 登录失效，请在 Hub 的运行账号下恢复登录；不换身份发送。')
+        if isinstance(error, dict) and error.get('retryable') is False:
+            raise NoticeError('DWS 拒绝本次调用，请检查权限或参数；不自动重试。')
+        if DNS_ERROR.search(result.stdout + '\n' + result.stderr):
+            if attempt < 2:
+                sleep(10)
+                continue
+            raise NoticeError('域名解析连续失败 3 次，通知停止，主任务继续。')
+        raise NoticeError('钉钉调用失败或结果未知；请检查登录、权限或网络，不自动重发。')
+
+
+def check_login(cli, profile, run, sleep):
+    if not profile or ':' not in profile or any(c.isspace() for c in profile):
+        raise NoticeError('缺少已确认的发送账号，请先由 Hub 初始化通知。')
+    data = invoke([cli, 'auth', 'status', '--profile', profile, '--format', 'json'], run, sleep)
+    if data.get('authenticated') is not True or data.get('token_valid') is not True:
+        raise NoticeError('个人 DWS 未登录或授权已失效，请负责人完成登录；本次未发送。')
+
+
+def mention_names(names):
+    names = list(dict.fromkeys(n.strip() for value in names for n in value.replace('，', ',').split(',')))
+    if any(not name for name in names):
+        raise NoticeError('提醒对象不能为空。')
+    return names
+
+
+def format_mentions(text, names, people=None):
+    names = mention_names(names)
+    placed = {match.group(1).strip() for match in INLINE_MENTION.finditer(text)}
+    if '@{' in INLINE_MENTION.sub('', text) or not placed.issubset(names):
+        raise NoticeError('正文中的 @{完整姓名} 必须完整填写，并在 --at 中列出同一姓名。')
+    by_name = {name: person for person, name in people.items()} if people is not None else None
+    if by_name is not None and not set(names).issubset(by_name):
+        raise NoticeError('提醒对象未全部唯一匹配，本次停止，不删掉 @ 后发送。')
+
+    def marker(name):
+        return f'<@{by_name[name]}>' if by_name is not None else f'@{name}'
+
+    text = INLINE_MENTION.sub(lambda match: marker(match.group(1).strip()), text)
+    remaining = [marker(name) for name in names if name not in placed]
+    if remaining:
+        text += '\n\n' + ' '.join(remaining)
+    return text
+
+
+def mentions(names, cli, profile, run, sleep):
+    people = {}
+    names = mention_names(names)
+    for name in names:
+        data = invoke([cli, 'aisearch', 'person', '--query', name, '--dimension', 'name',
+                       '--profile', profile, '--format', 'json'], run, sleep)
+        candidates = {}
+        for row in data.get('result', []):
+            if not isinstance(row, dict):
+                continue
+            meta = row.get('meta') if isinstance(row.get('meta'), dict) else {}
+            person = row.get('openDingTalkId')
+            if (meta.get('name') or row.get('title') or row.get('author')) == name and isinstance(person, str) and person.strip():
+                candidates[person] = name
+        if len(candidates) != 1:
+            raise NoticeError('提醒对象未唯一匹配，请确认完整姓名；不猜编号、不删掉 @ 后发送。')
+        people.update(candidates)
+    return people
+
+
+def initialize(args, root, run, sleep):
+    if not args.yes:
+        raise NoticeError('先向负责人确认发送账号、项目群及自动通知，再使用 init --yes。')
+    values = {'ENABLED': '1', 'PROFILE': args.profile.strip(), 'TARGET': args.group.strip(), 'PROJECT': args.project.strip()}
+    if any(not v or '\n' in v or '\r' in v or '\0' in v for v in values.values()):
+        raise NoticeError('初始化内容不能为空或含换行。')
+    path = root / '.dingtalk' / 'config.env'
+    if path.is_symlink() or path.parent.is_symlink():
+        raise NoticeError('配置路径不能是符号链接。')
+    if path.exists() and not args.replace:
+        raise NoticeError('配置已存在；变更账号或群须重新确认后使用 --replace。')
+    cli = dws_path()
+    profiles = invoke([cli, 'profile', 'list', '--format', 'json'], run, sleep).get('profiles', [])
+    if len([p for p in profiles if isinstance(p, dict) and p.get('profile') == values['PROFILE']]) != 1:
+        raise NoticeError('初始化账号不在 DWS 实际账号列表中。')
+    check_login(cli, values['PROFILE'], run, sleep)
+    # Hub supplies a group ID from same-profile discovery after human confirmation.
+    path.parent.mkdir(parents=True, exist_ok=True)
+    content = '# Hub 经负责人确认后生成；仅个人 DWS，不保存登录凭据。\n' + ''.join(
+        f'{PREFIX}{k}={v}\n' for k, v in values.items())
+    descriptor, temporary = tempfile.mkstemp(prefix='.notify-', suffix='.tmp', dir=path.parent)
+    try:
+        with os.fdopen(descriptor, 'w', encoding='utf-8', newline='\n') as stream:
+            stream.write(content)
+        os.replace(temporary, path)
+    finally:
+        if os.path.exists(temporary):
+            os.unlink(temporary)
+    emit('initialized', '已保存负责人确认的个人账号和项目群，通知已启用；未发送测试消息。')
+
+
+def parse_args(argv):
+    parser = argparse.ArgumentParser(description='Hub 个人 DWS 通知：初始化、进度、提醒、只读检查。')
+    commands = parser.add_subparsers(dest='command', required=True)
+    init = commands.add_parser('init', help='负责人确认后创建配置，不发送消息')
+    init.add_argument('--profile', required=True)
+    init.add_argument('--group', required=True)
+    init.add_argument('--project', required=True)
+    init.add_argument('--yes', action='store_true')
+    init.add_argument('--replace', action='store_true')
+    progress = commands.add_parser(
+        'progress', help='根据已留档的项目事实汇报当前阶段',
+        description='正文按“已确认的进展、待办事项、遗留”分条填写。阶段交接用一条 milestone 合并上一阶段总结与下一阶段已确认安排；项目 complete 用于明确关闭后的总结。沿用负责人、原计划、当前计划、必须完成的阶段和影响；脚本不判断授权、任务完成或阶段推进。')
+    progress.add_argument('event', choices=EVENTS)
+    progress.add_argument('--stage', required=True, help='项目当前阶段编号及中文名称；每次从有效项目记录取得')
+    progress.add_argument('summary', nargs='*')
+    progress.add_argument('--file', help='UTF-8 正文文件，仅含三个栏目；标题和时间由脚本生成')
+    message = commands.add_parser('message')
+    message.add_argument('--title', required=True)
+    body = message.add_mutually_exclusive_group(required=True)
+    body.add_argument('--text')
+    body.add_argument('--file')
+    check = commands.add_parser('check', help='检查固定账号登录及可选姓名，不发送')
+    for command in (progress, message, check):
+        command.add_argument('--at', action='append', default=[], help='完整姓名；正文可用 @{完整姓名} 定位，可重复或用逗号分隔')
+    for command in (progress, message):
+        command.add_argument('--dry-run', action='store_true', help='完全离线，只预览中文正文')
+    return parser.parse_args(argv)
+
+
+def render(args, config, root):
+    if args.command == 'progress' and bool(args.summary) == bool(args.file):
+        raise NoticeError('进度摘要和 --file 必须且只能提供一项。')
+    if args.file:
+        path = Path(args.file).resolve()
+        config_path = root / '.dingtalk' / 'config.env'
+        if path == config_path.resolve() or (path.exists() and config_path.exists() and path.samefile(config_path)):
+            raise NoticeError('不能把配置文件当作消息正文。')
+        text = path.read_text(encoding='utf-8')
+    else:
+        text = ' '.join(args.summary) if args.command == 'progress' else args.text
+    if not text.strip() or len(text.encode('utf-8')) > 12000:
+        raise NoticeError('请提供不超过 12000 字节的简短中文摘要。')
+    raw_title = args.stage if args.command == 'progress' else args.title
+    title = raw_title.strip()
+    if not title or len(title) > 200 or any(ord(c) < 32 or ord(c) == 127 for c in raw_title):
+        raise NoticeError('请使用不超过 200 字的单行标题。')
+    project = config.get('PROJECT') or root.name
+    timestamp = dt.datetime.now().astimezone().strftime('%Y-%m-%d %H:%M %z')
+    return f'**{project}｜{title}**\n\n项目进度自动汇报 · {timestamp}\n\n{text}'
+
+
+def main(argv=None, root=ROOT, run=subprocess.run, sleep=time.sleep):
+    try:
+        encoded = os.environ.pop(PREFIX + 'ARGV_B64', '')
+        if argv is None and encoded:
+            argv = json.loads(base64.b64decode(encoded, validate=True).decode('utf-8'))
+            if not isinstance(argv, list) or not all(isinstance(v, str) for v in argv):
+                raise NoticeError('PowerShell 参数无效。')
+        args = parse_args(argv)
+        if args.command == 'init':
+            initialize(args, root, run, sleep)
+            return 0
+        config = read_config(root)
+        if args.command != 'check' and args.dry_run:
+            text = format_mentions(render(args, config, root), args.at)
+            emit('preview', '仅离线预览，账号、群与 @ 效果未验证。', text=text, mentions=mention_names(args.at))
+            return 0
+        if args.command != 'check' and config.get('ENABLED') != '1':
+            emit('skipped', '通知尚未初始化或未启用；本次未发送，主任务继续。')
+            return 0
+        if not config.get('PROFILE') or not config.get('TARGET'):
+            raise NoticeError('请由 Hub 先确认个人账号和项目群并执行 init。')
+        text = render(args, config, root) if args.command != 'check' else None
+        if text is not None:
+            format_mentions(text, args.at)  # Validate inline names before any DWS call.
+        cli = dws_path()
+        profile = config['PROFILE']
+        if args.command == 'check':
+            check_login(cli, profile, run, sleep)
+        people = mentions(args.at, cli, profile, run, sleep)
+        if args.command == 'check':
+            emit('checked', '登录及所请求的姓名查询通过；未发送，未验证实际提醒效果。', names=list(people.values()))
+            return 0
+        text = format_mentions(text, args.at, people)
+        command = [cli, 'chat', '+messages-send', '--as', 'user', '--group', config['TARGET'],
+                   '--markdown', text, '--profile', profile, '--yes', '--format', 'json']
+        if people:
+            command += ['--at-open-dingtalk-ids', ','.join(people)]
+        data = invoke(command, run, sleep, sending=True)
+        emit('accepted', '个人 DWS 已接受发送请求，不代表已投递、已读或已触发接收端提醒。',
+             openTaskId=accepted_task(data), mentions=list(people.values()))
+        return 0
+    except NoticeError as error:
+        emit('error', str(error))
+        return 1
+    except (OSError, ValueError, UnicodeError, TypeError, subprocess.SubprocessError):
+        emit('error', '配置、正文或调用结果异常；本次停止，不自动重发，主任务继续。')
+        return 1
+
+
+if __name__ == '__main__':
+    for stream in (sys.stdout, sys.stderr):
+        if hasattr(stream, 'reconfigure'):
+            stream.reconfigure(encoding='utf-8')
+    sys.exit(main())

scripts/test_dingtalk_notify.py

@@ -0,0 +1,504 @@
+"""Offline regression tests. All DWS calls use isolated fake responses."""
+import base64
+import contextlib
+import io
+import json
+import os
+from pathlib import Path
+import shutil
+import subprocess
+import sys
+import tempfile
+import unittest
+from unittest.mock import patch
+
+import dingtalk_notify as n
+
+PROFILE = 'fake-corp:fake-user'
+GROUP = 'fake-group'
+PERSON = 'fake-person'
+OK = {'ok': True, 'identity': 'user', 'tool': 'send_personal_message',
+      'result': {'success': True, 'errorCode': None, 'result': {'openTaskId': 'fake-task'}}}
+
+
+def reply(data=None, code=0, error=''):
+    return subprocess.CompletedProcess([], code, json.dumps(data or {}, ensure_ascii=False), error)
+
+
+class NotifyTests(unittest.TestCase):
+    def setUp(self):
+        self.temp = tempfile.TemporaryDirectory()
+        self.addCleanup(self.temp.cleanup)
+        self.root = Path(self.temp.name)
+        self.path = self.root / '.dingtalk' / 'config.env'
+        self.path.parent.mkdir()
+        self.config()
+        self.calls = []
+        self.sleeps = []
+        self.addCleanup(patch.stopall)
+        patch.object(n, 'dws_path', return_value='fake-dws').start()
+
+    def config(self, **changes):
+        config = {'ENABLED': '1', 'PROFILE': PROFILE, 'TARGET': GROUP, 'PROJECT': '测试项目'}
+        config.update(changes)
+        self.path.write_text(''.join(n.PREFIX + k + '=' + v + '\n' for k, v in config.items()), encoding='utf-8')
+
+    def fake(self, command, **kwargs):
+        self.calls.append((command, kwargs))
+        if command[1:3] == ['profile', 'list']:
+            return reply({'profiles': [{'profile': PROFILE, 'userName': '测试人'}]})
+        if command[1:3] == ['auth', 'status']:
+            return reply({'authenticated': True, 'token_valid': True})
+        if command[1:3] == ['aisearch', 'person']:
+            return reply({'result': [{'openDingTalkId': PERSON, 'meta': {'name': command[command.index('--query') + 1]}}]})
+        self.assertEqual(command[1:3], ['chat', '+messages-send'])
+        return reply(OK)
+
+    def execute(self, args, run=None):
+        out = io.StringIO()
+        with contextlib.redirect_stdout(out):
+            code = n.main(args, root=self.root, run=run or self.fake, sleep=self.sleeps.append)
+        return code, json.loads(out.getvalue())
+
+    def test_each_event_personal_markdown(self):
+        for event in n.EVENTS:
+            code, result = self.execute(['progress', event, '--stage', '测试验证', '**进展**\n\n- 已归档'])
+            self.assertEqual(code, 0)
+            self.assertEqual(result['status'], 'accepted')
+            cmd = self.calls[-1][0]
+            self.assertEqual(cmd[cmd.index('--as') + 1], 'user')
+            self.assertEqual(cmd[cmd.index('--group') + 1], GROUP)
+            self.assertEqual(cmd[cmd.index('--profile') + 1], PROFILE)
+            body = cmd[cmd.index('--markdown') + 1]
+            self.assertEqual(body.splitlines()[0], '**测试项目｜测试验证**')
+            self.assertIn('项目进度自动汇报', body)
+            self.assertIn('**进展**\n\n- 已归档', body)
+            self.assertNotIn('--ai-tag=false', cmd)
+            self.assertNotIn('--robot-code', cmd)
+
+    def test_progress_requires_stage_before_any_dws_call(self):
+        with contextlib.redirect_stderr(io.StringIO()), self.assertRaises(SystemExit) as error:
+            self.execute(['progress', 'milestone', '已更新'])
+        self.assertEqual(error.exception.code, 2)
+        self.assertFalse(self.calls)
+
+    def test_invalid_stage_never_sends(self):
+        for stage in ['', '   ', '测试\n验证', '测试验证\r', '测试\t验证', '测试\0验证', '验' * 201]:
+            with self.subTest(stage=stage):
+                code, result = self.execute(['progress', 'milestone', '已更新', '--stage', stage])
+                self.assertEqual(code, 1)
+                self.assertEqual(result['status'], 'error')
+        self.assertFalse(self.calls)
+
+    def test_stage_changes_per_notification_without_config_change(self):
+        original = self.path.read_bytes()
+        text = '**待办事项**\n\n- 由 Hub 请项目负责人确认测试结果。\n\n**遗留**\n\n- 无。'
+        for stage in [' 阶段六：测试验证 ', '阶段七：平台/客户验收']:
+            code, result = self.execute(['progress', 'milestone', text, '--stage', stage, '--dry-run'])
+            self.assertEqual(code, 0)
+            self.assertEqual(result['text'].splitlines()[0], '**测试项目｜' + stage.strip() + '**')
+            self.assertTrue(result['text'].endswith(text))
+        self.assertEqual(self.path.read_bytes(), original)
+        self.assertFalse(self.calls)
+
+    def test_message_mentions_exact_name_fixed_profile(self):
+        code, data = self.execute(['message', '--title', '提醒', '--text', '请补充资料', '--at', '测试人,测试人'])
+        self.assertEqual(code, 0)
+        self.assertEqual(len(self.calls), 2)
+        for cmd, _ in self.calls:
+            self.assertEqual(cmd[cmd.index('--profile') + 1], PROFILE)
+        cmd = self.calls[-1][0]
+        self.assertEqual(cmd[cmd.index('--at-open-dingtalk-ids') + 1], PERSON)
+        self.assertIn('<@fake-person>', cmd[cmd.index('--markdown') + 1])
+        self.assertEqual(data['mentions'], ['测试人'])
+        self.assertEqual(data['openTaskId'], 'fake-task')
+
+    def test_approved_closing_template_preserves_conditions_and_scope(self):
+        body = '''**已确认的进展**
+
+- 相关负责人已确认：产品验收材料已在线下完成，业务已确认客户验收通过。
+- 项目已进入资料归档与复盘结项阶段，目前开始整理结项资料，项目尚未关闭。
+- 已通知相关负责人进行阶段交接，不新增审批。
+
+**待办事项**
+
+- 结项资料整理：由中心真人组织四类结项成果，Hub 协助整理工作稿。
+- 资料补充：由产品 Agent、业务 Agent 补充现有线下成果及确认索引，不重做验收。
+- 旧事项停止：由 Hub 停止此前的验收准备催办。
+- Bug 确认：中心先确认全部问题事实，产品再次确认处理或承接，已有有效确认直接引用。
+- 结项确认：四类成果、遗留承接和 Bug 双方确认具备后，由 Hub 请 @{测试人} 确认结项；中心真人决定关闭后锁定成果。
+- 本轮工作范围：不新增应用修复、设备测试或发布验证。
+
+**遗留**
+
+- 原测试不通过的结果如实保留，不因进入结项阶段改为通过。
+- 已接受延期的问题如实保留，后续沿用 Bug 系统中的记录和已有处理安排继续跟进。'''
+        path = self.root / '通知正文.md'
+        path.write_bytes(body.replace('\n', '\r\n').encode('utf-8'))
+        before = self.path.read_bytes()
+        args = ['progress', 'milestone', '--stage', '阶段八：复盘结项', '--file', str(path), '--at', '测试人']
+        code, preview = self.execute(args + ['--dry-run'])
+        self.assertEqual(code, 0)
+        self.assertFalse(self.calls)
+        self.assertEqual(preview['text'].splitlines()[0], '**测试项目｜阶段八：复盘结项**')
+        self.assertEqual(preview['text'].split('\n\n', 2)[2], body.replace('@{测试人}', '@测试人'))
+        code, result = self.execute(args)
+        self.assertEqual(code, 0)
+        self.assertEqual(result['status'], 'accepted')
+        self.assertEqual(len(self.calls), 2)
+        command = self.calls[-1][0]
+        markdown = command[command.index('--markdown') + 1]
+        self.assertEqual(markdown.split('\n\n', 2)[2], body.replace('@{测试人}', '<@fake-person>'))
+        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)
+        self.assertEqual(sum(c[0][1:3] == ['chat', '+messages-send'] for c in self.calls), 1)
+
+    def test_inline_mentions_match_each_item_and_deduplicate_recipients(self):
+        ids = {'甲': 'fake-a', '乙': 'fake-b', '丙': 'fake-c'}
+        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)
+        body = '**待办事项**\n\n- 由 Hub 请 @{甲} 确认测试结果。\n- 请 @{乙} 补充说明。\n\n**遗留**\n\n- @{乙} 按已定计划跟进未解决问题。'
+        code, data = self.execute(['progress', 'milestone', '--stage', '阶段六：测试验证',
+                                   body, '--at', '甲,乙,甲', '--at', '丙'], lookup)
+        self.assertEqual(code, 0)
+        self.assertEqual(data['mentions'], ['甲', '乙', '丙'])
+        self.assertEqual(len(self.calls), 4)
+        cmd = self.calls[-1][0]
+        actual = cmd[cmd.index('--markdown') + 1]
+        expected = body.replace('@{甲}', '<@fake-a>').replace('@{乙}', '<@fake-b>')
+        self.assertTrue(actual.endswith(expected + '\n\n<@fake-c>'))
+        self.assertEqual(cmd[cmd.index('--at-open-dingtalk-ids') + 1], 'fake-a,fake-b,fake-c')
+        for command, _ in self.calls:
+            self.assertEqual(command[command.index('--profile') + 1], PROFILE)
+
+    def test_inline_mentions_in_message_file(self):
+        path = self.root / '正文.md'
+        path.write_text('**待办事项**\n\n- 请 @{测试人} 补充资料。', encoding='utf-8')
+        code, _ = self.execute(['message', '--title', '阶段三：方案设计', '--file', str(path), '--at', '测试人'])
+        self.assertEqual(code, 0)
+        cmd = self.calls[-1][0]
+        text = cmd[cmd.index('--markdown') + 1]
+        self.assertTrue(text.endswith('- 请 <@fake-person> 补充资料。'))
+        self.assertEqual(text.count('<@fake-person>'), 1)
+
+    def test_inline_preview_shows_names_without_lookup(self):
+        code, data = self.execute(['progress', 'blocked', '--stage', '阶段三：方案设计',
+                                   '- 请 @{甲} 补充接口说明。', '--at', '甲，甲', '--at', '乙', '--dry-run'])
+        self.assertEqual(code, 0)
+        self.assertTrue(data['text'].endswith('- 请 @甲 补充接口说明。\n\n@乙'))
+        self.assertEqual(data['mentions'], ['甲', '乙'])
+        self.assertFalse(self.calls)
+
+    def test_invalid_inline_mentions_stop_before_lookup_or_send(self):
+        for body in ['请 @{乙} 确认', '请 @{} 确认', '请 @{甲 确认', '请 @{甲\n} 确认']:
+            for options in [[], ['--dry-run']]:
+                with self.subTest(body=body, options=options):
+                    code, result = self.execute(['message', '--title', '提醒', '--text', body, '--at', '甲'] + options)
+                    self.assertEqual(code, 1)
+                    self.assertEqual(result['status'], 'error')
+        self.assertFalse(self.calls)
+
+    def test_inline_mentions_with_conflicting_lookup_results_never_send(self):
+        code, result = self.execute(['message', '--title', '提醒', '--text', '- @{甲} 和 @{乙} 请核对。', '--at', '甲,乙'])
+        self.assertEqual(code, 1)
+        self.assertEqual(result['status'], 'error')
+        self.assertEqual(len(self.calls), 2)
+        self.assertTrue(all(c[0][1:3] == ['aisearch', 'person'] for c in self.calls))
+
+    def test_lookup_ambiguity_no_match_and_malformed_never_send(self):
+        for rows in [[], [{'openDingTalkId': 'a', 'meta': {'name': '甲'}},
+                          {'openDingTalkId': 'b', 'meta': {'name': '甲'}}],
+                     [{'userId': 'wrong-id-kind', 'meta': {'name': '甲'}}], None]:
+            self.calls.clear()
+            def lookup(command, **kwargs):
+                self.calls.append(command)
+                return reply({'result': rows})
+            code, data = self.execute(['message', '--title', '提醒', '--text', '正文', '--at', '甲'], lookup)
+            self.assertEqual(code, 1)
+            self.assertEqual(data['status'], 'error')
+            self.assertEqual(len(self.calls), 1)
+
+    def test_check_is_read_only(self):
+        code, data = self.execute(['check', '--at', '测试人'])
+        self.assertEqual(code, 0)
+        self.assertEqual(data['status'], 'checked')
+        self.assertEqual(len(self.calls), 2)
+        self.assertNotIn('fake-person', json.dumps(data))
+
+    def test_check_bad_login_stops(self):
+        code, _ = self.execute(['check'], lambda *a, **kw: reply({'authenticated': False, 'token_valid': False}))
+        self.assertEqual(code, 1)
+
+    def test_disabled_and_missing_config_no_tools(self):
+        self.config(ENABLED='0')
+        self.assertEqual(self.execute(['progress', 'start', '--stage', '测试验证', '开始'])[1]['status'], 'skipped')
+        self.path.unlink()
+        self.assertEqual(self.execute(['progress', 'start', '--stage', '测试验证', '开始'])[1]['status'], 'skipped')
+        self.assertFalse(self.calls)
+
+    def test_preview_without_config_or_dws(self):
+        self.path.unlink()
+        code, result = self.execute(['progress', 'blocked', '--stage', '测试验证', '说明', '--at', '甲', '--dry-run'])
+        self.assertEqual(code, 0)
+        self.assertEqual(result['status'], 'preview')
+        self.assertFalse(self.calls)
+
+    def test_legacy_and_invalid_config_fail_without_echo(self):
+        for suffix in ['CLIENT_SECRET=fake-secret', 'MODE=app-bot', 'ENABLED=1', 'UNKNOWN=x']:
+            self.config()
+            with self.path.open('a', encoding='utf-8') as f:
+                f.write(n.PREFIX + suffix + '\n')
+            code, data = self.execute(['progress', 'start', '--stage', '测试验证', '开始'])
+            self.assertEqual(code, 1)
+            self.assertNotIn('fake-secret', json.dumps(data))
+            self.assertFalse(self.calls)
+
+    def test_config_bom_crlf_and_literal_values(self):
+        raw = self.path.read_text(encoding='utf-8').replace('测试项目', '中文 "引号" $()')
+        self.path.write_bytes(b'\xef\xbb\xbf' + raw.replace('\n', '\r\n').encode())
+        code, data = self.execute(['progress', 'start', '--stage', '测试验证', '开始', '--dry-run'])
+        self.assertEqual(code, 0)
+        self.assertIn('中文 "引号" $()', data['text'])
+
+    def test_files_and_invalid_bodies(self):
+        body = self.root / '正文.md'
+        body.write_text('**进展**\n\n- 中文 "引号" $()', encoding='utf-8')
+        for args in [['progress', 'milestone', '--stage', '测试验证'], ['message', '--title', '说明']]:
+            self.assertEqual(self.execute(args + ['--file', str(body)])[0], 0)
+        before = len(self.calls)
+        for args in [['progress', 'start', '--stage', '测试验证', ''], ['progress', 'start', '--stage', '测试验证', 'x' * 12001],
+                     ['progress', 'start', '--stage', '测试验证', '正文', '--file', str(body)],
+                     ['message', '--title', '坏\n标题', '--text', '内容'],
+                     ['progress', 'start', '--stage', '测试验证', '--file', str(self.path), '--dry-run']]:
+            self.assertEqual(self.execute(args)[0], 1)
+        self.assertEqual(len(self.calls), before)
+
+    def test_dns_three_attempts_only(self):
+        calls = []
+        def failed(*a, **kw):
+            calls.append(a)
+            return reply(code=1, error='lookup api.dingtalk.com: no such host')
+        code, _ = self.execute(['progress', 'start', '--stage', '测试验证', '开始'], failed)
+        self.assertEqual(code, 1)
+        self.assertEqual(len(calls), 3)
+        self.assertEqual(self.sleeps, [10, 10])
+
+    def test_dns_then_success(self):
+        responses = iter([reply(code=1, error='lookup api.dingtalk.com: no such host'), reply(OK)])
+        self.assertEqual(self.execute(['progress', 'start', '--stage', '测试验证', '开始'], lambda *a, **kw: next(responses))[0], 0)
+        self.assertEqual(self.sleeps, [10])
+
+    def test_failure_and_unknown_never_retry(self):
+        cases = [reply(code=1, error='fake-secret connection reset'),
+                 reply(code=1, error=json.dumps({'error': {'category': 'auth', 'message': 'fake-secret'}})),
+                 reply(code=1, error=json.dumps({'error': {'retryable': False, 'message': 'lookup api.dingtalk.com: no such host'}})),
+                 reply({'success': True}), reply({'ok': False}), reply(OK | {'partial': True})]
+        for result in cases:
+            count = []
+            def failed(*a, **kw):
+                count.append(1)
+                return result
+            code, data = self.execute(['progress', 'start', '--stage', '测试验证', '开始'], failed)
+            self.assertEqual(code, 1)
+            self.assertEqual(len(count), 1)
+            self.assertNotIn('fake-secret', json.dumps(data))
+        self.assertFalse(self.sleeps)
+
+    def test_receipt_wins_nonzero_exit(self):
+        self.assertEqual(self.execute(['progress', 'start', '--stage', '测试验证', '开始'], lambda *a, **kw: reply(OK, code=1))[0], 0)
+
+    def test_wrong_receipts_rejected(self):
+        for bad in [OK | {'identity': 'bot'}, OK | {'tool': 'other'}, OK | {'failures': [1]},
+                    OK | {'result': {'success': False, 'result': {'openTaskId': 'x'}}},
+                    OK | {'result': {'success': True, 'result': {'openTaskId': ''}}}]:
+            self.assertIsNone(n.accepted_task(bad))
+
+    def test_timeout_and_launch_error_no_retry(self):
+        for error in [subprocess.TimeoutExpired('fake', 60), OSError('fake-secret')]:
+            calls = []
+            def fail(*a, **kw):
+                calls.append(1)
+                raise error
+            code, _ = self.execute(['progress', 'start', '--stage', '测试验证', '开始'], fail)
+            self.assertEqual(code, 1)
+            self.assertEqual(len(calls), 1)
+
+    def test_no_app_credentials_in_child_environment(self):
+        with patch.dict(os.environ, {'DWS_CLIENT_SECRET': 'fake-secret', 'DWS_CLIENT_ID': 'fake-app', 'DING_SEC': 'fake-key'}):
+            self.execute(['progress', 'start', '--stage', '测试验证', '开始'])
+        env = self.calls[-1][1]['env']
+        self.assertNotIn('DWS_CLIENT_SECRET', env)
+        self.assertNotIn('DWS_CLIENT_ID', env)
+        self.assertNotIn('DING_SEC', env)
+        self.assertEqual(self.calls[-1][1]['timeout'], 60)
+
+    def init_args(self):
+        return ['init', '--profile', PROFILE, '--group', GROUP, '--project', '项目甲']
+
+    def test_init_requires_confirmation_and_explicit_replace(self):
+        original = self.path.read_bytes()
+        self.assertEqual(self.execute(self.init_args())[0], 1)
+        self.assertEqual(self.execute(self.init_args() + ['--yes'])[0], 1)
+        self.assertEqual(self.path.read_bytes(), original)
+        self.assertFalse(self.calls)
+
+    def test_init_creates_minimal_config_no_send(self):
+        self.path.unlink()
+        code, data = self.execute(self.init_args() + ['--yes'])
+        self.assertEqual(code, 0)
+        self.assertEqual(data['status'], 'initialized')
+        self.assertEqual(set(n.read_config(self.root)), n.KEYS)
+        self.assertNotIn(b'\r', self.path.read_bytes())
+        self.assertEqual(len(self.calls), 2)
+        if os.name != 'nt':
+            self.assertEqual(self.path.stat().st_mode & 0o777, 0o600)
+
+    def test_init_replaces_legacy_without_retaining_secret(self):
+        self.path.write_text('DINGTALK_PROGRESS_CLIENT_SECRET=fake-secret\n', encoding='utf-8')
+        code, data = self.execute(self.init_args() + ['--yes', '--replace'])
+        self.assertEqual(code, 0)
+        self.assertNotIn('fake-secret', self.path.read_text())
+        self.assertNotIn('fake-secret', json.dumps(data))
+        self.assertEqual(len(list(self.path.parent.iterdir())), 1)
+
+    def test_init_bad_profile_and_line_injection_leave_config(self):
+        before = self.path.read_bytes()
+        for args in [self.init_args() + ['--profile', 'other:user'],
+                     self.init_args() + ['--project', 'x\nBAD=1']]:
+            self.assertEqual(self.execute(args + ['--yes', '--replace'])[0], 1)
+            self.assertEqual(self.path.read_bytes(), before)
+
+    def test_init_failed_auth_leaves_old_config(self):
+        before = self.path.read_bytes()
+        def fake(command, **kw):
+            if command[1] == 'auth':
+                return reply({'authenticated': False})
+            return self.fake(command, **kw)
+        self.assertEqual(self.execute(self.init_args() + ['--yes', '--replace'], fake)[0], 1)
+        self.assertEqual(self.path.read_bytes(), before)
+
+    def test_encoded_powershell_arguments(self):
+        args = ['message', '--title', '中文 "标题"', '--text', '**进展**\n\n- 引号 "$()"', '--dry-run']
+        with patch.dict(os.environ, {n.PREFIX + 'ARGV_B64': base64.b64encode(json.dumps(args).encode()).decode()}):
+            code, data = self.execute(None)
+        self.assertEqual(code, 0)
+        self.assertIn('中文 "标题"', data['text'])
+        self.assertIn('**进展**\n\n- 引号 "$()"', data['text'])
+
+    def test_bad_encoded_arguments(self):
+        for value in ['!!!', base64.b64encode(b'{}').decode()]:
+            with patch.dict(os.environ, {n.PREFIX + 'ARGV_B64': value}):
+                self.assertEqual(self.execute(None)[0], 1)
+        self.assertFalse(self.calls)
+
+    def test_hardlinked_config_cannot_be_message_body(self):
+        other = self.root / 'not-a-summary.md'
+        os.link(self.path, other)
+        self.assertEqual(self.execute(['progress', 'start', '--stage', '测试验证', '--file', str(other), '--dry-run'])[0], 1)
+
+    def test_real_powershell_launcher_in_isolated_project(self):
+        pwsh = shutil.which('pwsh')
+        if not pwsh or 'windowsapps' in sys.executable.lower():
+            self.skipTest('需要 PowerShell 和独立 Python，不能用商店版作启动器验收')
+        folder = self.root / 'scripts'
+        folder.mkdir()
+        source = Path(n.__file__).parent
+        for name in ['dingtalk_notify.py', 'dingtalk-python.ps1', 'dingtalk-progress.ps1', 'dingtalk-message.ps1']:
+            shutil.copyfile(source / name, folder / name)
+        env = n.clean_env()
+        env['DINGTALK_PYTHON'] = sys.executable
+        text = '**中文**\n\n- 请 @{测试人} 确认 "引号" $() `原样`'
+        for script, args in [('dingtalk-progress.ps1', ['milestone', text, '--stage', '测试验证']),
+                             ('dingtalk-message.ps1', ['--title', '中文 "标题"', '--text', text])]:
+            result = subprocess.run([pwsh, '-NoProfile', '-File', str(folder / script), *args, '--at', '测试人', '--dry-run'],
+                                    cwd=self.root, env=env, capture_output=True, encoding='utf-8', timeout=30)
+            self.assertEqual(result.returncode, 0, result.stderr)
+            data = json.loads(result.stdout)
+            self.assertEqual(data['status'], 'preview')
+            self.assertIn(text.replace('@{测试人}', '@测试人'), data['text'])
+            if script == 'dingtalk-progress.ps1':
+                self.assertEqual(data['text'].splitlines()[0], '**测试项目｜测试验证**')
+        result = subprocess.run([pwsh, '-NoProfile', '-File', str(folder / 'dingtalk-python.ps1'), 'init',
+                                 '--profile', PROFILE, '--group', GROUP, '--project', '甲'],
+                                cwd=self.root, env=env, capture_output=True, encoding='utf-8', timeout=30)
+        self.assertEqual(result.returncode, 1)
+        self.assertIn('先向负责人确认', result.stdout)
+
+
+if __name__ == '__main__':
+    unittest.main()