Compare commits
13
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 liyun
|
075837d51f | ||
|
liyun
|
206aabc06c | ||
 chenmingxuan
|
98541d682b | ||
|
liyun
|
9f08bc131a | ||
|
liyun
|
33cc16926c | ||
|
liyun
|
3fb9c0658d | ||
|
chenmingxuan
|
1d85de4c7c | ||
|
chenmingxuan
|
7b22e2802f | ||
|
chenmingxuan
|
20c0de9b38 | ||
|
chenmingxuan
|
a08cfd6a3b | ||
|
chenmingxuan
|
4f9efd175d | ||
|
chenmingxuan
|
ba95337650 | ||
|
chenmingxuan
|
64db56a951 |
No files matched your search
+101
-69
@@ -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`。
|
## 首次由 Hub 完成配置
|
||||||
- 官方 multi skills 保留在项目 `.agents/skills/dingtalk-*`，只对本项目生效。
|
|
||||||
- Client ID、群目标、`robotCode` 和汇报开关保存在项目 `.dingtalk/config.env`。
|
|
||||||
- Client Secret 从环境变量 `DING_SEC` 读取，未设置时回退到 macOS Keychain；脚本只临时注入给 `dws api`，App Token 由 DWS 自动获取和缓存。
|
|
||||||
|
|
||||||
项目统一通过稳定入口调用全局命令：
|
负责人不需要找编号、复制配置模板或填写密钥。Hub 在项目初始化时执行：
|
||||||
|
|
||||||
```sh
|
1. 检查本机 DWS；未登录时请负责人通过官方 DWS 登录流程授权，不索取密码或 Token。
|
||||||
./scripts/dws version
|
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 时也应保持这一边界。
|
|
||||||
|
|
||||||
## 应用身份（无需用户登录）
|
|
||||||
|
|
||||||
本项目不执行 `dws auth login`。进度脚本通过 `dws api` 调用企业内部应用 OpenAPI：
|
|
||||||
|
|
||||||
```text
|
```text
|
||||||
POST https://api.dingtalk.com/v1.0/robot/groupMessages/send
|
python scripts/dingtalk_notify.py init --profile "实际查询结果" --group "实际查询结果" --project "项目名称" --yes
|
||||||
```
|
```
|
||||||
|
|
||||||
管理员侧只需确保：
|
初始化检查账号存在且可登录，创建 `.dingtalk/config.env` 并启用通知；**不会发测试消息，也不会替人确认群选择**。群标识必须来自该账号的查询结果。初始化不创建钉钉群、不申请权限。已有配置默认不覆盖；迁移或变更账号、群时重新确认，再加 `--replace`，原配置被替换且不另存含密钥的备份。
|
||||||
|
|
||||||
- Client ID/Secret 属于企业内部应用；
|
配置仅 4 项：
|
||||||
- 应用已有“企业内机器人发送消息”权限（`qyapi_robot_sendmsg`）；
|
|
||||||
- `robotCode` 属于同一个应用；
|
|
||||||
- 机器人已加入目标 `openConversationId` 对应的群。
|
|
||||||
|
|
||||||
当前使用 zsh 环境变量时，先确保它已导出（不要把真实值写进项目文件）：
|
| 字段 | 含义 | 谁填写 |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| `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
|
||||||
|
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 "示例甲"
|
||||||
|
```
|
||||||
|
|
||||||
|
以上结项场景、事项和姓名仅作格式演示；验收结论、成果数量、延期安排和确认人不作为其他项目的默认事实或要求。真实发送须使用当前项目的有效记录和已确认的真人负责人姓名。
|
||||||
|
|
||||||
|
`progress` 现在必须传入 `--stage`，每次使用当前项目记录里的阶段编号和名称；未登记编号时仅写已知名称。标题显示“项目名称｜阶段编号：阶段名称”，不再显示固定的“阶段里程碑”。旧调用需补齐参数，并同步部署脚本和相关 中心 Skill 及实际部署配置；本地改动不等于在途项目已更新。
|
||||||
|
|
||||||
|
进度通知使用加粗标题和“已确认的进展”“待办事项”“遗留”三个栏目：待办按“事项名称：由谁做什么”逐条写清，当前及此前阶段尚未解决的问题列入遗留，沿用原计划、当前计划、必须完成的阶段和影响范围。保留已定前提、停止事项和工作范围，阶段启动不写成项目关闭。确实没有待办或遗留时写“无”，未核实不能当作没有；沿用已定责任和期限，不能为了通知新增工作或重填清单。具体写法见[通知规则](../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
|
```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，重点写已经确认的结果、下一步或阻塞原因，不要粘贴大段日志。
|
|
||||||
@@ -1,19 +1,7 @@
|
|||||||
# Copy this file to .dingtalk/config.env, fill the selected mode, then chmod 600 it.
|
# Hub 查询账号和群、取得负责人确认后，用 init 生成真实 config.env。
|
||||||
# Values are literal text after '='; do not add shell quotes.
|
# 不需手工复制或填编号；不保存机器人密钥或个人登录凭据。
|
||||||
|
# 等号右侧为字面值，不加 Shell 引号。ENABLED=0 暂停通知。
|
||||||
# Keep both switches safe until credential setup and a dry-run have succeeded.
|
|
||||||
DINGTALK_PROGRESS_ENABLED=0
|
DINGTALK_PROGRESS_ENABLED=0
|
||||||
DINGTALK_PROGRESS_DRY_RUN=1
|
DINGTALK_PROGRESS_PROFILE=
|
||||||
|
|
||||||
# Enterprise-internal app bot: App Token via dws api; no user OAuth login.
|
|
||||||
DINGTALK_PROGRESS_MODE=app-bot
|
|
||||||
DINGTALK_PROGRESS_CLIENT_ID=
|
|
||||||
DINGTALK_PROGRESS_TARGET=
|
DINGTALK_PROGRESS_TARGET=
|
||||||
DINGTALK_PROGRESS_ROBOT_CODE=
|
DINGTALK_PROGRESS_PROJECT=
|
||||||
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=[项目进度]
|
|
||||||
+6
-1
@@ -1,5 +1,8 @@
|
|||||||
* text=auto
|
* text=auto
|
||||||
|
.gitattributes text eol=lf
|
||||||
|
.gitignore text eol=lf
|
||||||
|
.dingtalk/config.env.example text eol=lf
|
||||||
|
.dingtalk/config.env
|
||||||
*.md text eol=lf
|
*.md text eol=lf
|
||||||
*.txt text eol=lf
|
*.txt text eol=lf
|
||||||
*.html text eol=lf
|
*.html text eol=lf
|
||||||
@@ -8,4 +11,6 @@
|
|||||||
*.json text eol=lf
|
*.json text eol=lf
|
||||||
*.py text eol=lf
|
*.py text eol=lf
|
||||||
*.sh text eol=lf
|
*.sh text eol=lf
|
||||||
|
*.ps1 text eol=lf
|
||||||
scripts/dingtalk-progress text eol=lf
|
scripts/dingtalk-progress text eol=lf
|
||||||
|
scripts/dingtalk-message text eol=lf
|
||||||
@@ -1,5 +1,7 @@
|
|||||||
# Local credentials and machine-specific configuration
|
# Local credentials and machine-specific configuration
|
||||||
.dingtalk/config.env
|
.dingtalk/config.env
|
||||||
|
.dingtalk/config.env.*
|
||||||
|
!.dingtalk/config.env.example
|
||||||
**/.env
|
**/.env
|
||||||
**/.env.*
|
**/.env.*
|
||||||
!**/.env.example
|
!**/.env.example
|
||||||
|
|||||||
@@ -1,118 +1,65 @@
|
|||||||
# AGENTS.md
|
# AGENTS.md
|
||||||
|
|
||||||
## Project Overview
|
## 范围与工作入口
|
||||||
|
|
||||||
本仓库维护 Etunel 多 Agent 项目的角色协作约束，核心交付是：
|
本文件适用于整个仓库，更具体的子目录说明在其范围内生效，当前任务中的明确用户要求优先。本仓库维护中心业务 Skill、流程文档、记录模板和钉钉通知封装，没有应用构建步骤。
|
||||||
|
|
||||||
- `etunel-role-collaboration/`：供各角色按需读取的渐进式披露 Skill；
|
1. 先读 [ep-hub/SKILL.md](ep-hub/SKILL.md)，仅按本次任务路由读取相关 reference。
|
||||||
- `etunel-role-hook-contexts/`：供 Etunel 独立配置的八角色精简 Hook 上下文；
|
2. 当前设计来源为 [V2.1 总流程图](doc/Codex多角色项目推进总流程图.html)，运行规则已整理到中心 Skill；不要求目标项目具备流程 HTML。流程文档固定路径更新，历史由 Git 保留，不另建日期或版本副本。
|
||||||
- `doc/`：流程设计基线和历史资料；
|
3. 先后检查 Git 状态与差异，保护用户已有改动和未跟踪资料。不要删除用户保留的旧源文件来制造干净工作区。
|
||||||
- 钉钉参考集成：仅帮助 Hub 理解如何调用辅助通知，不属于 Etunel 任务通信主链路。
|
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/20260908/Codex多角色项目推进总流程图-V1.0.html)（CURRENT，文档生效日期 2026-09-08），基于用户已确认的 V0.16 全文生成，不新增角色或流程规则。V0.15、V0.16 HTML 保留原文件；本地文档定版不表示已发布 Git、部署 Skill／Hook 或替换在途项目基线。未经用户再次通知，不提交、不推送、不合入主分支，也不自动更新已安装的插件缓存。旧版流程用于追溯；已在运行的项目继续使用其登记基线，迁移须明确确认。
|
|
||||||
4. 运行时 Hook、Etunel 工具 schema、项目角色契约、成员登记及已确认的项目流程基线，高于 Skill 的通用说明。发现冲突时说明冲突，不要自行猜测或发明能力。
|
|
||||||
5. 保留用户已有改动；修改前后检查 Git 状态与差异。
|
|
||||||
|
|
||||||
不要让运行时 Skill 依赖某个带版本号的流程图或提示词文件。应把已确认且仍有效的规则整理为稳定约束，并放入正确的渐进式 reference；版本文件只作为设计来源和追溯依据。
|
## 钉钉集成
|
||||||
|
|
||||||
## 必须保持的协作边界
|
- 只有中心／主 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/` | 已确认流程来源及历史版本 | 不把历史版本误写成当前规则；新增基线时明确其状态 |
|
|
||||||
| `.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
|
```powershell
|
||||||
rtk python -X utf8 "$env:USERPROFILE\.codex\skills\.system\skill-creator\scripts\quick_validate.py" "etunel-role-collaboration"
|
python -X utf8 "$env:USERPROFILE/.codex/skills/.system/skill-creator/scripts/quick_validate.py" ep-hub
|
||||||
rtk "C:\Program Files\Git\bin\bash.exe" -n scripts/dingtalk-progress
|
python -X utf8 scripts/test_dingtalk_notify.py
|
||||||
rtk proxy git diff --check
|
git diff --check
|
||||||
rtk proxy git status --short
|
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 队列机制；为不存在的工具、角色、参数或成果制造虚假规则。
|
|
||||||
@@ -1,195 +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 的统一入口，只保留共享硬约束和条件路由；详细职责按当前任务逐层读取。
|
本次按 V2.1 及已确认的实施口径更新阶段汇报、工时与排期、成果确认、Bug 双方确认和关闭后登记规则。旧的全角色 Skill 与独立 Hook 源目录已移除，旧内容仍可从 Git 历史查阅。仓库源文件更新不代表已发布、已安装、已修改 Etunel 配置或已迁移在途项目。
|
||||||
2. [Hook 上下文](etunel-role-hook-contexts/) 是给 Etunel 单独配置的精简提醒，不属于 Skill 的渐进式发现树，也不应替代完整职责文件。
|
|
||||||
3. 当前本地定版文档为 [V1.0 总流程图](doc/20260908/Codex多角色项目推进总流程图-V1.0.html)（CURRENT，文档生效日期 2026-09-08），基于已确认的 V0.16 全文生成，保留原有流程与灯态“配网”修正。V0.15、V0.16 历史文件保留；文档定版不代表已推送、部署 Skill／Hook 或自动迁移在途项目。未经用户再次通知，不提交、不推送、不合入主分支，也不自动更新已安装的插件缓存。运行时规则已整理进稳定 reference，不要求目标项目持有版本 HTML。
|
|
||||||
|
|
||||||
仓库没有应用安装、编译或发布流程。主要工作是维护角色约束、流程文档、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 | 建立项目、维护状态、规划任务波次、校验交付结构、协调阻塞并完成跨角色中继 |
|
| 1. 业务需求 | 《业务需求》，包含背景及客户里程碑 |
|
||||||
| 业务 | 形成商业需求、客户与授权信息、业务验收及发布结项输入 |
|
| 2. 产品定义 | 《立项资料》（含风险）、《测试验收标准》、《里程碑要求》 |
|
||||||
| 产品 | 把业务需求转化为产品定义、范围、交互和验收标准 |
|
| 3. 方案设计 | 《测试计划》；《总体技术方案》选填 |
|
||||||
| 技术负责人 | 负责总体技术方案、接口与跨技术域设计协调 |
|
| 4. 项目规划 | 《项目计划》、《角色分工》、《项目状态内部记录》 |
|
||||||
| 嵌入式应用层 | 负责应用层软件设计、实现、联调和对应成果 |
|
| 5. 嵌入式软硬件实现 | 硬件设计包、底层实现资料、应用层固件包 |
|
||||||
| 嵌入式底层 | 负责驱动、BSP、底层接口与对应实现成果 |
|
| 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 和协作者的仓库级工作规则
|
| 唯一计划主表 | 完整工作项、当前有效计划和实际执行；已有项目沿用，新项目默认使用 Excel 八列模板 |
|
||||||
├── 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
|
|
||||||
│ ├── 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/ # 当前设计基线和历史流程资料
|
|
||||||
├── .agents/skills/dingtalk-*/ # 钉钉官方能力参考副本，不是核心 Skill
|
|
||||||
├── .dingtalk/ # 通知接入说明与无秘密示例配置
|
|
||||||
└── scripts/dingtalk-progress # Hub 钉钉通知的当前演示封装
|
|
||||||
```
|
|
||||||
|
|
||||||
Skill 被用于实际项目时，Hub 在目标项目中维护统一的 `项目资料/`，而不是把项目成果写回本约束仓库：
|
每项任务保留三类时间：**原计划完成时间、当前计划完成时间、实际完成时间**。实际完成时间是任务提交后经对应真人明确确认完成的时间，提交时间另记。改期保留旧值、原因和真人决定；跨阶段沿用原记录，项目层持续跟进。
|
||||||
|
|
||||||
```text
|
每个阶段使用 `阶段记录.md`、`正式成果/`、`过程记录/`。正式区只放真人完成并确认的最终版及确认；草稿、旧版和历史确认保留在过程区。外部成果登记完整真实入口、用途、版本及确认，不强制下载、复制或截图。项目明确授权本地复制时，保存已取得且确认有效的资料、来源与路径映射，操作日期不改变原提交及确认日期。
|
||||||
项目资料/
|
|
||||||
├── 00-项目管理/ # 项目概览、项目进度、成果索引、项目成员清单
|
|
||||||
├── 01-业务需求/
|
|
||||||
├── 02-产品定义/
|
|
||||||
├── 03-方案设计/
|
|
||||||
├── 04-项目规划/
|
|
||||||
├── 05-软硬件实现/
|
|
||||||
├── 06-测试验证/
|
|
||||||
├── 07-平台客户验收/
|
|
||||||
└── 08-复盘结项/
|
|
||||||
```
|
|
||||||
|
|
||||||
每个实际使用的阶段按需建立 `阶段记录.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` 读取实际角色；成员不向负责人追问成员、会话或任务编号。
|
1. 将仓库中的完整 `ep-hub/` 作为中心 Skill 安装到目标环境的 Skill 目录，保留 `references/`、`assets/` 和 `agents/`；具体安装位置遵循目标环境配置。
|
||||||
2. 读取 [SKILL.md](etunel-role-collaboration/SKILL.md) 的共享约束。
|
2. 配置与通信使用目标环境已安装的 `etunel-use`。修改 Etunel 中心或成员契约时，按其管理操作和职责 Hook 指南办理；中心自身配置与成员配置是不同操作。
|
||||||
3. 只打开本次任务所需的引用：
|
3. 检查目标项目实际启用的旧 Skill、职责契约与 Hook。迁移须明确目标与范围，保留项目既有任务、时间、旧成果和确认记录；不能仅因仓库升级就宣称在途项目采用 V2.1。
|
||||||
- Hub 先读 [Hub 工作流](etunel-role-collaboration/references/hub-workflow.md)；
|
4. 在迁移已获确认后，按目标环境的安装与配置机制停用冲突的旧角色流程约束。成员内部流程由各角色真人维护，新中心 Skill 不分发统一的内部操作提示词。
|
||||||
- 成员先读 [成员通用工作流](etunel-role-collaboration/references/member-workflow.md)，再读自己的一个[角色职责文件](etunel-role-collaboration/references/roles/)；
|
5. 需要钉钉时，将仓库 `scripts/` 中的共用 Python 文件和所需平台入口部署到目标项目 `scripts/`；中心 Skill 安装不会自动部署脚本。按 [钉钉配置说明](.dingtalk/README.md) 确认个人账号、项目群和通知范围。
|
||||||
- 涉及派发、中继或返回时读 [Etunel 任务消息流程](etunel-role-collaboration/references/etunel-message-lifecycle.md)；
|
|
||||||
- 涉及成果、证据、状态或豁免时读 [成果与完成判定](etunel-role-collaboration/references/artifacts-and-evidence.md)；
|
|
||||||
- 涉及对负责人发消息时读 [人类可读沟通](etunel-role-collaboration/references/human-readable-communication.md)；
|
|
||||||
- 涉及阶段成果、进度或复盘资料时读 [项目文件与进度留档](etunel-role-collaboration/references/project-files-and-progress.md)；
|
|
||||||
- 涉及缺信息、阻塞、返工、变更或流程跳转时读 [异常与协调](etunel-role-collaboration/references/exceptions-and-coordination.md)。
|
|
||||||
4. 成员先和自己的真人负责人对齐任务与输入，形成明确成果、自审并取得负责人确认后，再交给 Hub。
|
|
||||||
5. Hub 校验任务结果，按阶段整理实际文件并更新项目进度和成果索引，只把下游需要的信息定向交给下一角色，不广播无关计划或私有对话。
|
|
||||||
|
|
||||||
不要为了“全面了解”一次加载全部引用。测试专项文件也只有在任务类型匹配时才继续深入读取。
|
## 钉钉通知
|
||||||
|
|
||||||
## Hook 上下文
|
通知是中心向项目群提供进度与行动提醒的辅助能力。先维护事实记录，再依授权发送。消息标题来自项目当前阶段，正文固定为 **已确认的进展／待办事项／遗留**，逐项写清谁做什么，沿用原有责任、时间、范围和停止事项。
|
||||||
|
|
||||||
[etunel-role-hook-contexts/](etunel-role-hook-contexts/) 为八个默认角色各提供一份“精简职责与每轮提醒”。它们适合由 Etunel Hook 在每轮会话中注入，用来持续提醒身份、边界、负责人参与和工具使用。
|
- 已获批准或条件授权实际满足的阶段交接合为一条“上一阶段总结＋下一阶段安排”；等待决定先在中心会话汇报。阶段内关键进展、阻塞和失败仍按已授权范围通知，同轮合并；实际关闭后发一次结项总结，正文及实际发送结果进入阶段过程记录。
|
||||||
|
- 用 `scripts/dingtalk_notify.py` 的 `progress`／`message` 或同等平台入口；`progress` 必须提供 `--stage`。
|
||||||
|
- 真人提醒在正文使用 `@{完整姓名}`，同时用 `--at` 列出姓名；脚本唯一匹配后原位生成提及。
|
||||||
|
- `--dry-run` 完全离线，只展示内容，不证明账号、群或 @ 有效。
|
||||||
|
- `accepted` 只表示个人发送请求获接受，不等于送达、已读、真人确认或接收端提醒成功。
|
||||||
|
- 仅明确 DNS 失败有限重试；未知结果不重复发送。钉钉异常不阻塞项目工作。
|
||||||
|
- 本地配置由目标项目保存且不提交；不读取或输出 DWS 凭据，不把真实发送作为仓库测试。
|
||||||
|
|
||||||
本轮先同步远程 `main` 的 Hook 提醒（`0b133bf`），保留“完整职责 JSON + 每轮精简提醒”结构；职责 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 或群名。仓库维护时也不要用真实发送作为普通测试。
|
```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
|
||||||
|
|
||||||
1. 阅读 [AGENTS.md](AGENTS.md) 和本次变更涉及的最小文件集合。
|
|
||||||
2. 若变更来自流程设计，核对 [V1.0 CURRENT 总流程图](doc/20260908/Codex多角色项目推进总流程图-V1.0.html)；保持历史 HTML 不变，不把本地文档定版或规则更新当作远程发布、部署或在途项目自动迁移。
|
|
||||||
3. 把共享规则放在公共 reference，把角色专属规则放在对应角色文件，把低频测试细节放在测试二级 reference。
|
|
||||||
4. 只有必须让所有角色立即知道的规则才进入根 `SKILL.md`；同时保持条件路由可发现。
|
|
||||||
5. 同步检查受影响的 Hook 文件，并验证链接、结构和 Shell 语法。
|
|
||||||
|
|
||||||
## 验证
|
|
||||||
|
|
||||||
本仓库没有构建步骤。提交前至少运行：
|
|
||||||
|
|
||||||
```sh
|
|
||||||
git diff --check
|
git diff --check
|
||||||
git status --short
|
git status --short
|
||||||
```
|
```
|
||||||
|
|
||||||
修改核心 Skill 后，使用已安装的 Skill Creator 对 `etunel-role-collaboration/` 运行 `scripts/quick_validate.py`。Skill Creator 的位置取决于协作者的 Codex 安装，不要为此把验证器复制进仓库。
|
验证器位置随本机安装确定，不复制进仓库。修改 Shell／PowerShell 入口时检查语法与隔离参数传递；所有测试使用假配置，不真实发送。另核对 Markdown 相对链接、渐进式入口及人工确认边界。
|
||||||
|
|
||||||
修改钉钉演示脚本后再运行：
|
## 设计与参考资料
|
||||||
|
|
||||||
```sh
|
- [V2.1 总流程图](doc/Codex多角色项目推进总流程图.html)
|
||||||
bash -n scripts/dingtalk-progress
|
- [历史文档模板参考](doc/文档模板参考/README.md)：学习笔记与来源索引，原件未打包入仓库。
|
||||||
```
|
- 流程文档固定路径更新，历史使用 `git log --all -- doc/` 查询，不另建版本或日期副本。
|
||||||
|
|
||||||
还应人工确认：
|
|
||||||
|
|
||||||
- 新增 reference 能从根 Skill 或已路由文件按条件发现；
|
|
||||||
- Markdown 相对链接实际存在；
|
|
||||||
- 根 Skill、角色 reference 与 Hook 没有职责漂移；
|
|
||||||
- 没有占位符、秘密配置、真实凭据或不存在的工具与文件；
|
|
||||||
- 钉钉仍只是 Hub 辅助通知参考，没有进入任务通信或门禁主链路。
|
|
||||||
|
|
||||||
## 设计资料
|
|
||||||
|
|
||||||
- [当前本地定版 V1.0（CURRENT）](doc/20260908/Codex多角色项目推进总流程图-V1.0.html)
|
|
||||||
- [保留的评审版本 V0.16（REVIEW）](doc/20260907/Codex多角色项目推进总流程图-V0.16.html)
|
|
||||||
- [保留的总流程图 V0.15](doc/20260904/Codex多角色项目推进总流程图-V0.15.html)
|
|
||||||
- [历史总流程图 V0.14](doc/20260902/Codex多角色项目推进总流程图-V0.14.html)
|
|
||||||
- [补充与历史追溯：项目Hub系统提示词 V0.13](doc/20260828/Codex多角色项目推进-项目Hub系统提示词-V0.13.txt)
|
|
||||||
- [历史总流程图 V0.13](doc/20260828/Codex多角色项目推进总流程图-V0.13.html)
|
|
||||||
- [历史总流程图 V0.4](doc/20260827/Codex多角色项目推进总流程图-V0.4.html)
|
|
||||||
- [核心 Skill](etunel-role-collaboration/SKILL.md)
|
|
||||||
- [Hub 工作流](etunel-role-collaboration/references/hub-workflow.md)
|
|
||||||
- [项目生命周期](etunel-role-collaboration/references/project-lifecycle.md)
|
|
||||||
@@ -1,933 +0,0 @@
|
|||||||
<!doctype html>
|
|
||||||
<html lang="zh-CN">
|
|
||||||
<head>
|
|
||||||
<meta charset="utf-8" />
|
|
||||||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
|
||||||
<meta name="color-scheme" content="light" />
|
|
||||||
<link rel="icon" href="data:," />
|
|
||||||
<title>Codex 多角色项目推进总流程图与信息流图谱｜V0.3</title>
|
|
||||||
<style>
|
|
||||||
:root {
|
|
||||||
--navy: #10253f;
|
|
||||||
--navy-2: #17395f;
|
|
||||||
--blue: #2368a2;
|
|
||||||
--cyan: #2a9d9f;
|
|
||||||
--amber: #c67a1b;
|
|
||||||
--ink: #182331;
|
|
||||||
--muted: #5d6a78;
|
|
||||||
--line: #d8e0e7;
|
|
||||||
--paper: #f5f8fa;
|
|
||||||
--white: #ffffff;
|
|
||||||
--soft-cyan: #e9f7f6;
|
|
||||||
--soft-amber: #fff4df;
|
|
||||||
--soft-red: #fcecee;
|
|
||||||
--soft-green: #e9f6ef;
|
|
||||||
--max: 1180px;
|
|
||||||
}
|
|
||||||
|
|
||||||
* { box-sizing: border-box; }
|
|
||||||
html { scroll-behavior: smooth; }
|
|
||||||
body {
|
|
||||||
margin: 0;
|
|
||||||
color: var(--ink);
|
|
||||||
background: var(--paper);
|
|
||||||
font-family: Inter, ui-sans-serif, -apple-system, BlinkMacSystemFont,
|
|
||||||
"Segoe UI", "PingFang SC", "Microsoft YaHei", sans-serif;
|
|
||||||
line-height: 1.65;
|
|
||||||
}
|
|
||||||
|
|
||||||
.hero {
|
|
||||||
color: white;
|
|
||||||
background:
|
|
||||||
radial-gradient(circle at 88% 8%, rgba(42,157,159,.32), transparent 28%),
|
|
||||||
linear-gradient(145deg, #0c1f36 0%, #173f67 100%);
|
|
||||||
}
|
|
||||||
.hero-inner {
|
|
||||||
width: min(var(--max), calc(100% - 56px));
|
|
||||||
margin: 0 auto;
|
|
||||||
padding: 62px 0 52px;
|
|
||||||
}
|
|
||||||
.eyebrow {
|
|
||||||
display: inline-block;
|
|
||||||
margin-bottom: 18px;
|
|
||||||
padding: 6px 10px;
|
|
||||||
border: 1px solid rgba(255,255,255,.18);
|
|
||||||
border-radius: 999px;
|
|
||||||
color: #b9eff0;
|
|
||||||
background: rgba(255,255,255,.06);
|
|
||||||
font-size: 11px;
|
|
||||||
font-weight: 800;
|
|
||||||
letter-spacing: .12em;
|
|
||||||
}
|
|
||||||
h1, h2, h3, h4, p { margin-top: 0; }
|
|
||||||
h1 {
|
|
||||||
max-width: 900px;
|
|
||||||
margin-bottom: 18px;
|
|
||||||
font-size: clamp(40px, 5vw, 68px);
|
|
||||||
line-height: 1.05;
|
|
||||||
letter-spacing: -.04em;
|
|
||||||
}
|
|
||||||
.hero p {
|
|
||||||
max-width: 860px;
|
|
||||||
margin-bottom: 0;
|
|
||||||
color: rgba(255,255,255,.68);
|
|
||||||
font-size: 18px;
|
|
||||||
}
|
|
||||||
|
|
||||||
.page {
|
|
||||||
width: min(var(--max), calc(100% - 56px));
|
|
||||||
margin: 0 auto;
|
|
||||||
padding: 46px 0 72px;
|
|
||||||
}
|
|
||||||
.map-shell {
|
|
||||||
padding: 30px;
|
|
||||||
border: 1px solid var(--line);
|
|
||||||
border-radius: 24px;
|
|
||||||
background:
|
|
||||||
linear-gradient(rgba(35,104,162,.035) 1px, transparent 1px),
|
|
||||||
linear-gradient(90deg, rgba(35,104,162,.035) 1px, transparent 1px),
|
|
||||||
#eef4f7;
|
|
||||||
background-size: 28px 28px;
|
|
||||||
}
|
|
||||||
.map-head {
|
|
||||||
display: flex;
|
|
||||||
justify-content: space-between;
|
|
||||||
gap: 24px;
|
|
||||||
align-items: end;
|
|
||||||
margin-bottom: 28px;
|
|
||||||
}
|
|
||||||
.map-head h2 { margin-bottom: 6px; font-size: 30px; letter-spacing: -.025em; }
|
|
||||||
.map-head p { max-width: 760px; margin: 0; color: var(--muted); font-size: 14px; }
|
|
||||||
.legend { display: flex; flex-wrap: wrap; gap: 7px; justify-content: flex-end; }
|
|
||||||
.legend span {
|
|
||||||
padding: 5px 8px;
|
|
||||||
border-radius: 999px;
|
|
||||||
color: var(--muted);
|
|
||||||
background: var(--white);
|
|
||||||
box-shadow: 0 3px 12px rgba(16,37,63,.06);
|
|
||||||
font-size: 10px;
|
|
||||||
white-space: nowrap;
|
|
||||||
}
|
|
||||||
|
|
||||||
.track { display: grid; gap: 0; }
|
|
||||||
.node {
|
|
||||||
display: grid;
|
|
||||||
grid-template-columns: 58px 180px minmax(0,1fr) minmax(270px,.9fr);
|
|
||||||
gap: 18px;
|
|
||||||
align-items: center;
|
|
||||||
padding: 20px;
|
|
||||||
border: 1px solid #ccd9e3;
|
|
||||||
border-radius: 16px;
|
|
||||||
background: rgba(255,255,255,.97);
|
|
||||||
box-shadow: 0 8px 22px rgba(16,37,63,.055);
|
|
||||||
}
|
|
||||||
.index {
|
|
||||||
display: grid;
|
|
||||||
width: 46px;
|
|
||||||
height: 46px;
|
|
||||||
place-items: center;
|
|
||||||
border-radius: 14px;
|
|
||||||
color: white;
|
|
||||||
background: var(--navy-2);
|
|
||||||
font-weight: 850;
|
|
||||||
}
|
|
||||||
.stage h3 { margin: 0 0 5px; font-size: 19px; }
|
|
||||||
.role {
|
|
||||||
display: inline-block;
|
|
||||||
padding: 3px 7px;
|
|
||||||
border-radius: 999px;
|
|
||||||
color: #155e60;
|
|
||||||
background: var(--soft-cyan);
|
|
||||||
font-size: 10px;
|
|
||||||
font-weight: 800;
|
|
||||||
}
|
|
||||||
.work { color: var(--muted); font-size: 13px; }
|
|
||||||
.work strong { color: var(--ink); }
|
|
||||||
.artifacts {
|
|
||||||
padding-left: 18px;
|
|
||||||
border-left: 1px solid var(--line);
|
|
||||||
}
|
|
||||||
.artifacts strong { display: block; margin-bottom: 6px; font-size: 12px; }
|
|
||||||
.artifacts span { display: block; color: var(--muted); font-size: 11px; line-height: 1.55; }
|
|
||||||
.artifacts span + span { margin-top: 8px; }
|
|
||||||
.artifacts span::first-line { color: var(--ink); font-size: 12px; font-weight: 600; line-height: 1.75; }
|
|
||||||
|
|
||||||
.connector {
|
|
||||||
display: grid;
|
|
||||||
min-height: 72px;
|
|
||||||
place-items: center;
|
|
||||||
}
|
|
||||||
.connector::before { content: ""; width: 2px; height: 22px; background: #93aec5; }
|
|
||||||
.gate {
|
|
||||||
position: relative;
|
|
||||||
margin: 4px 0;
|
|
||||||
padding: 8px 14px 8px 30px;
|
|
||||||
border: 1px solid #e6c27b;
|
|
||||||
border-radius: 999px;
|
|
||||||
color: #70480d;
|
|
||||||
background: var(--soft-amber);
|
|
||||||
font-size: 11px;
|
|
||||||
font-weight: 760;
|
|
||||||
text-align: center;
|
|
||||||
}
|
|
||||||
.gate::before { content: "◆"; position: absolute; left: 11px; color: var(--amber); }
|
|
||||||
.connector::after { content: "↓"; color: var(--blue); font-size: 20px; font-weight: 900; line-height: 1; }
|
|
||||||
|
|
||||||
.parallel {
|
|
||||||
display: grid;
|
|
||||||
grid-template-columns: repeat(2, minmax(0,1fr));
|
|
||||||
gap: 8px;
|
|
||||||
margin-top: 8px;
|
|
||||||
}
|
|
||||||
.parallel span {
|
|
||||||
padding: 8px;
|
|
||||||
border: 1px solid var(--line);
|
|
||||||
border-radius: 9px;
|
|
||||||
color: var(--ink);
|
|
||||||
background: #f8fafb;
|
|
||||||
font-size: 11px;
|
|
||||||
}
|
|
||||||
.branch {
|
|
||||||
display: grid;
|
|
||||||
grid-template-columns: repeat(2, minmax(0,1fr));
|
|
||||||
gap: 10px;
|
|
||||||
margin-top: 12px;
|
|
||||||
}
|
|
||||||
.path { padding: 12px 14px; border-radius: 12px; font-size: 11px; }
|
|
||||||
.path strong { display: block; margin-bottom: 3px; }
|
|
||||||
.path.pass { border: 1px solid #a9d4c0; color: #266746; background: var(--soft-green); }
|
|
||||||
.path.return { border: 1px dashed #dc9ca0; color: #863b40; background: var(--soft-red); }
|
|
||||||
.crosscut {
|
|
||||||
margin-top: 20px;
|
|
||||||
padding: 18px 20px;
|
|
||||||
border: 1px dashed #95abc0;
|
|
||||||
border-radius: 14px;
|
|
||||||
background: rgba(255,255,255,.75);
|
|
||||||
}
|
|
||||||
.crosscut strong { color: var(--blue); }
|
|
||||||
.crosscut p { margin: 5px 0 0; color: var(--muted); font-size: 12px; }
|
|
||||||
|
|
||||||
.footer {
|
|
||||||
margin-top: 24px;
|
|
||||||
color: var(--muted);
|
|
||||||
font-size: 11px;
|
|
||||||
text-align: center;
|
|
||||||
}
|
|
||||||
|
|
||||||
@media (max-width: 920px) {
|
|
||||||
.node { grid-template-columns: 54px 160px minmax(0,1fr); }
|
|
||||||
.artifacts { grid-column: 3; padding-left: 0; border-left: 0; }
|
|
||||||
}
|
|
||||||
@media (max-width: 640px) {
|
|
||||||
.hero-inner, .page { width: min(100% - 28px, var(--max)); }
|
|
||||||
.hero-inner { padding: 44px 0 36px; }
|
|
||||||
.hero p { font-size: 15px; }
|
|
||||||
.page { padding-top: 24px; }
|
|
||||||
.map-shell { padding: 16px; border-radius: 18px; }
|
|
||||||
.map-head { display: block; }
|
|
||||||
.legend { justify-content: flex-start; margin-top: 14px; }
|
|
||||||
.node { grid-template-columns: 44px minmax(0,1fr); gap: 12px; padding: 16px; }
|
|
||||||
.index { width: 40px; height: 40px; border-radius: 12px; }
|
|
||||||
.stage, .work, .artifacts { grid-column: 2; }
|
|
||||||
.artifacts { padding-top: 12px; border-top: 1px solid var(--line); }
|
|
||||||
.parallel, .branch { grid-template-columns: 1fr; }
|
|
||||||
.gate { max-width: 290px; }
|
|
||||||
}
|
|
||||||
|
|
||||||
@media print {
|
|
||||||
@page { size: A4 portrait; margin: 12mm; }
|
|
||||||
body { background: white; font-size: 9pt; }
|
|
||||||
.hero { color: var(--ink); background: white; border-bottom: 3px solid var(--navy); }
|
|
||||||
.hero-inner, .page { width: 100%; }
|
|
||||||
.hero-inner { padding: 14mm 0 10mm; }
|
|
||||||
.hero .eyebrow { color: var(--blue); border-color: var(--line); }
|
|
||||||
.hero p { color: var(--muted); }
|
|
||||||
.page { padding: 10mm 0 0; }
|
|
||||||
.map-shell { padding: 0; border: 0; background: white; }
|
|
||||||
.node { break-inside: avoid; box-shadow: none; }
|
|
||||||
.connector { min-height: 16mm; }
|
|
||||||
}
|
|
||||||
/* Embedded stage information-flow atlas */
|
|
||||||
.if-atlas {
|
|
||||||
margin-top: 76px;
|
|
||||||
padding-top: 58px;
|
|
||||||
border-top: 4px solid var(--navy);
|
|
||||||
}
|
|
||||||
.if-intro {
|
|
||||||
margin-bottom: 42px;
|
|
||||||
padding: 40px;
|
|
||||||
border-radius: 22px;
|
|
||||||
color: white;
|
|
||||||
background:
|
|
||||||
radial-gradient(circle at 88% 10%, rgba(42,157,159,.28), transparent 30%),
|
|
||||||
linear-gradient(145deg, #10253f, #1a4a72);
|
|
||||||
}
|
|
||||||
.if-intro .if-eyebrow {
|
|
||||||
color: #b9eff0;
|
|
||||||
font-size: 11px;
|
|
||||||
font-weight: 850;
|
|
||||||
letter-spacing: .13em;
|
|
||||||
}
|
|
||||||
.if-intro h2 {
|
|
||||||
margin: 10px 0 12px;
|
|
||||||
font-size: clamp(34px,4vw,56px);
|
|
||||||
line-height: 1.05;
|
|
||||||
}
|
|
||||||
.if-intro p {
|
|
||||||
max-width: 900px;
|
|
||||||
margin-bottom: 20px;
|
|
||||||
color: rgba(255,255,255,.7);
|
|
||||||
}
|
|
||||||
.if-quicknav { display: flex; flex-wrap: wrap; gap: 8px; }
|
|
||||||
.if-quicknav a {
|
|
||||||
padding: 6px 9px;
|
|
||||||
border: 1px solid rgba(255,255,255,.18);
|
|
||||||
border-radius: 999px;
|
|
||||||
color: rgba(255,255,255,.75);
|
|
||||||
background: rgba(255,255,255,.06);
|
|
||||||
font-size: 10px;
|
|
||||||
text-decoration: none;
|
|
||||||
}
|
|
||||||
.if-section {
|
|
||||||
padding: 58px 0;
|
|
||||||
border-bottom: 1px solid var(--line);
|
|
||||||
}
|
|
||||||
.if-section-head {
|
|
||||||
display: grid;
|
|
||||||
grid-template-columns: 122px minmax(0,1fr);
|
|
||||||
gap: 24px;
|
|
||||||
margin-bottom: 28px;
|
|
||||||
}
|
|
||||||
.if-section-no {
|
|
||||||
color: var(--blue);
|
|
||||||
font-size: 11px;
|
|
||||||
font-weight: 850;
|
|
||||||
letter-spacing: .13em;
|
|
||||||
}
|
|
||||||
.if-section-head h2 {
|
|
||||||
margin-bottom: 8px;
|
|
||||||
font-size: clamp(28px,3vw,43px);
|
|
||||||
line-height: 1.1;
|
|
||||||
}
|
|
||||||
.if-section-head p {
|
|
||||||
max-width: 900px;
|
|
||||||
margin: 0;
|
|
||||||
color: var(--muted);
|
|
||||||
font-size: 14px;
|
|
||||||
}
|
|
||||||
.if-callout {
|
|
||||||
padding: 21px 24px;
|
|
||||||
border-left: 5px solid var(--cyan);
|
|
||||||
border-radius: 0 16px 16px 0;
|
|
||||||
background: var(--white);
|
|
||||||
box-shadow: 0 10px 28px rgba(16,37,63,.07);
|
|
||||||
font-size: 17px;
|
|
||||||
font-weight: 680;
|
|
||||||
}
|
|
||||||
.if-role-legend {
|
|
||||||
display: flex;
|
|
||||||
flex-wrap: wrap;
|
|
||||||
gap: 8px;
|
|
||||||
margin: 21px 0;
|
|
||||||
}
|
|
||||||
.if-actor {
|
|
||||||
display: inline-flex;
|
|
||||||
min-width: 125px;
|
|
||||||
min-height: 50px;
|
|
||||||
align-items: center;
|
|
||||||
justify-content: center;
|
|
||||||
padding: 9px 12px;
|
|
||||||
border: 2px solid currentColor;
|
|
||||||
border-radius: 13px;
|
|
||||||
background: white;
|
|
||||||
font-size: 12px;
|
|
||||||
font-weight: 800;
|
|
||||||
text-align: center;
|
|
||||||
}
|
|
||||||
.if-center { color: #183d63; background: #eaf2f8; }
|
|
||||||
.if-business { color: #9b5d0b; background: #fff5df; }
|
|
||||||
.if-product { color: #7755a7; background: #f4eefb; }
|
|
||||||
.if-tech { color: #14787a; background: #e9f7f6; }
|
|
||||||
.if-app { color: #2f855a; background: #edf8f1; }
|
|
||||||
.if-low { color: #4265af; background: #eef2fc; }
|
|
||||||
.if-hardware { color: #8b5e3c; background: #f7f0eb; }
|
|
||||||
.if-test { color: #9b3d45; background: #fceef0; }
|
|
||||||
.if-human { color: #68561b; background: #fff9df; }
|
|
||||||
.if-flow-board {
|
|
||||||
display: grid;
|
|
||||||
gap: 10px;
|
|
||||||
padding: 23px;
|
|
||||||
border: 1px solid var(--line);
|
|
||||||
border-radius: 19px;
|
|
||||||
background: #edf3f6;
|
|
||||||
}
|
|
||||||
.if-exchange {
|
|
||||||
display: grid;
|
|
||||||
grid-template-columns: 150px minmax(240px,1fr) 150px;
|
|
||||||
gap: 14px;
|
|
||||||
align-items: center;
|
|
||||||
padding: 12px;
|
|
||||||
border: 1px solid #d0dce5;
|
|
||||||
border-radius: 15px;
|
|
||||||
background: rgba(255,255,255,.94);
|
|
||||||
}
|
|
||||||
.if-exchange .if-actor { width: 100%; }
|
|
||||||
.if-arrow {
|
|
||||||
position: relative;
|
|
||||||
min-height: 60px;
|
|
||||||
display: flex;
|
|
||||||
flex-direction: column;
|
|
||||||
align-items: center;
|
|
||||||
justify-content: center;
|
|
||||||
padding: 8px 34px 9px 10px;
|
|
||||||
color: var(--navy-2);
|
|
||||||
text-align: center;
|
|
||||||
}
|
|
||||||
.if-arrow::before {
|
|
||||||
content: "";
|
|
||||||
position: absolute;
|
|
||||||
left: 8px;
|
|
||||||
right: 18px;
|
|
||||||
top: 50%;
|
|
||||||
height: 2px;
|
|
||||||
background: #83a9c5;
|
|
||||||
}
|
|
||||||
.if-arrow::after {
|
|
||||||
content: "";
|
|
||||||
position: absolute;
|
|
||||||
right: 7px;
|
|
||||||
top: calc(50% - 6px);
|
|
||||||
border-left: 11px solid #83a9c5;
|
|
||||||
border-top: 7px solid transparent;
|
|
||||||
border-bottom: 7px solid transparent;
|
|
||||||
}
|
|
||||||
.if-arrow > * {
|
|
||||||
position: relative;
|
|
||||||
z-index: 1;
|
|
||||||
padding: 0 7px;
|
|
||||||
background: rgba(255,255,255,.96);
|
|
||||||
}
|
|
||||||
.if-flow-id {
|
|
||||||
color: var(--blue);
|
|
||||||
font-family: "SFMono-Regular", Consolas, monospace;
|
|
||||||
font-size: 10px;
|
|
||||||
font-weight: 900;
|
|
||||||
}
|
|
||||||
.if-arrow strong { font-size: 13px; }
|
|
||||||
.if-arrow small { color: var(--muted); font-size: 10px; }
|
|
||||||
.if-conditional { border-style: dashed; }
|
|
||||||
.if-blocking .if-arrow::before { background: #d28c91; }
|
|
||||||
.if-blocking .if-arrow::after { border-left-color: #d28c91; }
|
|
||||||
.if-stage-summary {
|
|
||||||
display: grid;
|
|
||||||
grid-template-columns: repeat(3,minmax(0,1fr));
|
|
||||||
gap: 12px;
|
|
||||||
margin-bottom: 18px;
|
|
||||||
}
|
|
||||||
.if-summary-card {
|
|
||||||
padding: 16px;
|
|
||||||
border: 1px solid var(--line);
|
|
||||||
border-radius: 14px;
|
|
||||||
background: white;
|
|
||||||
}
|
|
||||||
.if-summary-card b {
|
|
||||||
display: block;
|
|
||||||
margin-bottom: 5px;
|
|
||||||
color: var(--blue);
|
|
||||||
font-size: 11px;
|
|
||||||
}
|
|
||||||
.if-summary-card span { color: var(--muted); font-size: 12px; }
|
|
||||||
.if-table-wrap {
|
|
||||||
margin-top: 23px;
|
|
||||||
overflow-x: auto;
|
|
||||||
border: 1px solid var(--line);
|
|
||||||
border-radius: 15px;
|
|
||||||
background: white;
|
|
||||||
}
|
|
||||||
.if-table-wrap table {
|
|
||||||
width: 100%;
|
|
||||||
min-width: 1050px;
|
|
||||||
border-collapse: collapse;
|
|
||||||
font-size: 12px;
|
|
||||||
}
|
|
||||||
.if-table-wrap th,
|
|
||||||
.if-table-wrap td {
|
|
||||||
padding: 12px 13px;
|
|
||||||
border-right: 1px solid var(--line);
|
|
||||||
border-bottom: 1px solid var(--line);
|
|
||||||
text-align: left;
|
|
||||||
vertical-align: top;
|
|
||||||
}
|
|
||||||
.if-table-wrap th:last-child,
|
|
||||||
.if-table-wrap td:last-child { border-right: 0; }
|
|
||||||
.if-table-wrap tr:last-child td { border-bottom: 0; }
|
|
||||||
.if-table-wrap th {
|
|
||||||
color: white;
|
|
||||||
background: var(--navy);
|
|
||||||
font-size: 11px;
|
|
||||||
white-space: nowrap;
|
|
||||||
}
|
|
||||||
.if-table-wrap tbody tr:nth-child(even) { background: #f8fafb; }
|
|
||||||
.if-table-wrap td:first-child {
|
|
||||||
color: var(--blue);
|
|
||||||
font-family: "SFMono-Regular", Consolas, monospace;
|
|
||||||
font-weight: 850;
|
|
||||||
white-space: nowrap;
|
|
||||||
}
|
|
||||||
.if-block { color: #8f3038; font-weight: 700; }
|
|
||||||
.if-pass { color: #266746; font-weight: 700; }
|
|
||||||
.if-cross-flow {
|
|
||||||
padding: 22px;
|
|
||||||
border: 1px dashed #9aafc0;
|
|
||||||
border-radius: 18px;
|
|
||||||
background: #eef4f7;
|
|
||||||
}
|
|
||||||
@media (max-width: 920px) {
|
|
||||||
.if-exchange { grid-template-columns: 125px minmax(210px,1fr) 125px; }
|
|
||||||
}
|
|
||||||
@media (max-width: 640px) {
|
|
||||||
.if-intro { padding: 26px 20px; }
|
|
||||||
.if-intro h2 { font-size: 30px; }
|
|
||||||
.if-section-head { grid-template-columns: 1fr; gap: 8px; }
|
|
||||||
.if-stage-summary { grid-template-columns: 1fr; }
|
|
||||||
.if-flow-board { padding: 13px; }
|
|
||||||
.if-exchange { grid-template-columns: 1fr; gap: 7px; }
|
|
||||||
.if-exchange .if-actor { min-height: 45px; }
|
|
||||||
.if-arrow { min-height: 72px; padding: 22px 10px; }
|
|
||||||
.if-arrow::before {
|
|
||||||
left: 50%;
|
|
||||||
right: auto;
|
|
||||||
top: 7px;
|
|
||||||
bottom: 15px;
|
|
||||||
width: 2px;
|
|
||||||
height: auto;
|
|
||||||
}
|
|
||||||
.if-arrow::after {
|
|
||||||
right: auto;
|
|
||||||
left: calc(50% - 6px);
|
|
||||||
top: auto;
|
|
||||||
bottom: 5px;
|
|
||||||
border-left: 7px solid transparent;
|
|
||||||
border-right: 7px solid transparent;
|
|
||||||
border-top: 11px solid #83a9c5;
|
|
||||||
border-bottom: 0;
|
|
||||||
}
|
|
||||||
.if-blocking .if-arrow::after {
|
|
||||||
border-top-color: #d28c91;
|
|
||||||
border-left-color: transparent;
|
|
||||||
}
|
|
||||||
}
|
|
||||||
@media print {
|
|
||||||
.if-atlas { page-break-before: always; }
|
|
||||||
.if-exchange,
|
|
||||||
.if-summary-card { break-inside: avoid; box-shadow: none; }
|
|
||||||
.if-table-wrap table { font-size: 8pt; }
|
|
||||||
}
|
|
||||||
</style>
|
|
||||||
</head>
|
|
||||||
<body>
|
|
||||||
<header class="hero">
|
|
||||||
<div class="hero-inner">
|
|
||||||
<div class="eyebrow">CODEX MULTI-ROLE PROJECT FLOW · V0.3</div>
|
|
||||||
<h1>项目推进总流程图</h1>
|
|
||||||
<p>以业务、项目、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件、测试八类角色为基础，其中项目角色由中心 AI 承担；通过正式成果、角色内部确认门和中心服务路由，推进项目从需求到发布结项。</p>
|
|
||||||
</div>
|
|
||||||
</header>
|
|
||||||
|
|
||||||
<main class="page">
|
|
||||||
<section class="map-shell">
|
|
||||||
<div class="map-head">
|
|
||||||
<div>
|
|
||||||
<h2>从业务需求到发布结项</h2>
|
|
||||||
<p>主线按成果和确认门推进；测试失败、业务验收驳回和需求变更通过回路返回正确阶段，不需要从头重启项目。</p>
|
|
||||||
</div>
|
|
||||||
<div class="legend" aria-label="流程图图例">
|
|
||||||
<span>白色卡片＝项目阶段</span>
|
|
||||||
<span>黄色门＝角色/阶段确认</span>
|
|
||||||
<span>红色虚线＝返工回路</span>
|
|
||||||
</div>
|
|
||||||
</div>
|
|
||||||
|
|
||||||
<div class="track" aria-label="完整项目推进流程">
|
|
||||||
<article class="node">
|
|
||||||
<div class="index">01</div>
|
|
||||||
<div class="stage"><h3>业务需求</h3><span class="role">主责：业务</span></div>
|
|
||||||
<div class="work"><strong>明确问题与价值。</strong>补齐业务目标、范围、规则、优先级和可度量成功指标。</div>
|
|
||||||
<div class="artifacts"><strong>正式成果</strong><span>Project Background Brief（项目背景说明）<br>客户信息：客户名称、最终客户名称<br>项目名称：统一名称或客户规定的项目代号<br>产品要求：产品形态、提测平台<br>项目来源：新客户、新项目、旧产品升级、竞品替换或成本优化<br>需求背景：客户为什么提出这个需求，要解决什么问题<br>商业目标：获取订单、维护客户、降低成本、拓展市场或形成标准产品<br>预期价值：预计订单量、销售额</span><span>Project Milestone Plan（项目目标与里程碑计划）<br>提测时间<br>入库时间<br>小批量试产时间<br>量产时间</span></div>
|
|
||||||
</article>
|
|
||||||
<div class="connector"><div class="gate">业务确认需求基线</div></div>
|
|
||||||
|
|
||||||
<article class="node">
|
|
||||||
<div class="index">02</div>
|
|
||||||
<div class="stage"><h3>产品定义</h3><span class="role">主责：产品 · 批准：业务</span></div>
|
|
||||||
<div class="work"><strong>把目标转成可实现、可验证的产品定义。</strong>技术负责人组织可行性评估，嵌入式应用层、嵌入式底层和硬件分别评估实现约束，测试评估可测试性。</div>
|
|
||||||
<div class="artifacts"><strong>正式成果</strong><span>Project Initiation Package（立项资料）<br>立项书：包含产品详细信息、开发模式、开发范围、测试范围及其他补充信息<br>规格书：包含产品硬件规格和主要元器件型号（主控芯片、Sensor、镜头、WiFi 芯片）<br>功能清单：定义设备支持的功能<br>灯态：描述设备上电、绑定、升级、网络断开等状态下的指示灯状态与语音播报内容<br>产测功能清单：描述产测工具支持项<br>版本说明：描述当前版本的背景、主要功能等关键信息，并包含该项目此前所有版本和阶段的信息<br>结构板框图：包含主要器件位置和禁止限制区域</span><span>Hardware Development Package（硬件开发资料）<br>外设器件和关键器件规格书：主控、Flash、Sensor、复位按键、指示灯、WiFi 模块、音频功放驱动芯片、IR-CUT 驱动芯片、电机达林顿管驱动芯片<br>结构板框图：包含主要器件位置和禁止限制区域</span><span>Embedded Development Package（嵌入式开发资料）<br>平台 SDK<br>串号表<br>平台对接文档<br>平台接入标准及开发规范</span><span>Test & Acceptance Criteria（测试验收标准）<br>平台测试用例<br>客户验收测试用例和验收标准</span><span>Milestone Requirements（里程碑要求）<br>提测时间<br>客户验收时间<br>试产、量产时间</span></div>
|
|
||||||
</article>
|
|
||||||
<div class="connector"><div class="gate">产品确认方案，业务批准范围</div></div>
|
|
||||||
|
|
||||||
<article class="node">
|
|
||||||
<div class="index">03</div>
|
|
||||||
<div class="stage"><h3>项目规划</h3><span class="role">主责：中心 AI</span></div>
|
|
||||||
<div class="work"><strong>基于成果、成员能力和依赖自动编排任务、进度和风险。</strong>任务计划草案先由技术负责人确认；中心 AI 只对存在疑点的任务定向询问对应执行角色，真实资源和日期基线再提交业务确认。</div>
|
|
||||||
<div class="artifacts"><strong>正式成果</strong><span>Project Plan（项目计划）<br>项目任务拆分<br>实际项目排期</span><span>Risk Register（项目风险）<br>技术风险<br>时间风险<br>其他风险</span><span>Role Assignment（角色分工）</span><span>Product Documentation Package（产品资料整合）</span><span>Project Status Record（项目状态内部记录）<br>阶段与门禁<br>任务与依赖<br>阻塞与风险<br>决策与成果基线<br>下一步与时限</span></div>
|
|
||||||
</article>
|
|
||||||
<div class="connector"><div class="gate">技术负责人确认任务计划，问题任务由对应执行角色定向确认，业务确认资源与日期基线</div></div>
|
|
||||||
|
|
||||||
<article class="node">
|
|
||||||
<div class="index">04</div>
|
|
||||||
<div class="stage"><h3>方案设计</h3><span class="role">主责：技术负责人 · 协作：嵌入式应用层 + 嵌入式底层 + 硬件 + 测试</span></div>
|
|
||||||
<div class="work"><strong>技术负责人统一组织总体方案设计和确认。</strong><div class="parallel"><span>技术负责人：总体架构、软硬件边界、关键决策</span><span>嵌入式应用层：业务逻辑、应用协议、功能模块设计</span><span>嵌入式底层：BSP、驱动、RTOS、HAL 设计</span><span>硬件：原理图、PCB、BOM、电源/信号/热设计</span><span>测试：范围、环境、用例、通过标准</span></div></div>
|
|
||||||
<div class="artifacts"><strong>正式成果</strong><span>Solution Architecture（总体技术方案）</span><span>Software/Hardware Interface Contract（软硬件接口契约）</span><span>Hardware Design Package（硬件设计包）</span><span>Architecture Decision Record（架构决策记录）</span><span>Test Plan（测试计划）</span></div>
|
|
||||||
</article>
|
|
||||||
<div class="connector"><div class="gate">技术负责人确认整体方案，嵌入式应用层/嵌入式底层/硬件确认接口可实施，产品确认不偏离，测试确认可验证</div></div>
|
|
||||||
|
|
||||||
<article class="node">
|
|
||||||
<div class="index">05</div>
|
|
||||||
<div class="stage"><h3>嵌入式软硬件实现</h3><span class="role">并行：嵌入式应用层 + 嵌入式底层 + 硬件</span></div>
|
|
||||||
<div class="work"><strong>嵌入式应用层、嵌入式底层和硬件在已确认总体方案及软硬件接口契约下并行实现、样机调试和自测。</strong>嵌入式底层将可消费版本交给嵌入式应用层合版，嵌入式应用层负责生成并提交唯一的最终固件版本；接口或器件约束发生重大偏离时返回技术负责人确认。</div>
|
|
||||||
<div class="artifacts"><strong>正式成果</strong><span>Hardware Implementation Package（硬件实现资料）<br>原理图：DSN 源文档和 PDF 文档<br>PCB：源文档<br>贴片资料：PCBA BOM、器件位置图 PDF、贴片坐标<br>维修原理图<br>接口定义<br>静态测试报告</span><span>Low-Level Implementation Package（嵌入式底层实现资料）<br>硬件功能测试报告<br>BSP 输出路径<br>PSP 输出路径<br>WiFi 设备定频测试固件</span><span>Application Firmware Package（嵌入式应用层固件包）<br>正式固件、升级固件<br>自测用例<br>分区表<br>MD5 值文件<br>Flash 烧写固件<br>日志文件<br>Changelog<br>串口使能证书</span></div>
|
|
||||||
</article>
|
|
||||||
<div class="connector"><div class="gate">嵌入式底层提交可消费版本，嵌入式应用层合版并提交最终固件，技术负责人确认固件与硬件版本匹配</div></div>
|
|
||||||
|
|
||||||
<article class="node">
|
|
||||||
<div class="index">06</div>
|
|
||||||
<div class="stage"><h3>测试验证</h3><span class="role">主责：测试 · 修复：嵌入式应用层/嵌入式底层/硬件</span></div>
|
|
||||||
<div class="work"><strong>执行功能、接口、软硬件集成和回归测试。</strong><div class="branch"><div class="path return"><strong>不通过</strong>应用问题→嵌入式应用层；BSP/驱动问题→嵌入式底层；电路/PCB/器件问题→硬件；接口/架构问题→技术负责人</div><div class="path pass"><strong>通过</strong>质量报告 + 测试证据包</div></div></div>
|
|
||||||
<div class="artifacts"><strong>正式成果</strong><span>Functional Test Report（功能测试报告）<br>平台测试用例<br>内部测试用例</span><span>Reliability Test Report（可靠性测试报告）<br>高低温测试<br>跌落测试</span><span>Specialized Test Report（专项测试报告）<br>画质测试<br>WiFi 测试<br>功耗测试<br>长稳测试<br>试产一致性测试</span><span>Test Evidence Package（提测佐证）</span><span>Defect Analysis Report（缺陷分析报告）</span></div>
|
|
||||||
</article>
|
|
||||||
<div class="connector"><div class="gate">测试确认质量结论和剩余风险</div></div>
|
|
||||||
|
|
||||||
<article class="node">
|
|
||||||
<div class="index">07</div>
|
|
||||||
<div class="stage"><h3>业务验收</h3><span class="role">主责：产品</span></div>
|
|
||||||
<div class="work"><strong>依据成功指标、验收标准和质量证据作最终判断。</strong><div class="branch"><div class="path return"><strong>驳回</strong>需求→产品；应用问题→嵌入式应用层；嵌入式底层软件问题→嵌入式底层；硬件问题→硬件；架构问题→技术负责人；证据问题→测试</div><div class="path pass"><strong>通过</strong>形成正式业务验收结论，进入发布准备</div></div></div>
|
|
||||||
<div class="artifacts"><strong>正式成果</strong><span>Platform Test Approval Report（平台提测通过报告）</span><span>Customer Acceptance Approval Report（客户验收通过报告）</span><span>Conditional Acceptance Items（附条件验收事项）</span></div>
|
|
||||||
</article>
|
|
||||||
<div class="connector"><div class="gate">业务批准验收结论和上线条件</div></div>
|
|
||||||
|
|
||||||
<article class="node">
|
|
||||||
<div class="index">08</div>
|
|
||||||
<div class="stage"><h3>发布结项</h3><span class="role">中心 AI 协调 · 技术负责人确认 · 嵌入式应用层/嵌入式底层/硬件执行 · 测试验证</span></div>
|
|
||||||
<div class="work"><strong>检查应用、固件、板卡版本、BOM/ECO、发布清单、冒烟、回滚和遗留事项承接。</strong>中心 AI 汇总复盘并归档角色会话。</div>
|
|
||||||
<div class="artifacts"><strong>正式成果</strong><span>Closure Documentation Archive（结项资料归档）<br>形成最终结果的流程文件</span><span>Change Log（变更记录）</span><span>Closure Report（结项报告）</span><span>Process Closure Summary（流程闭环总结）</span></div>
|
|
||||||
</article>
|
|
||||||
</div>
|
|
||||||
|
|
||||||
<div class="crosscut">
|
|
||||||
<strong>贯穿全流程：Change Request（需求变更申请）</strong>
|
|
||||||
<p>任何角色都可提出变更；中心 AI 自动组织影响评估，产品评估范围，技术负责人评估总体方案，嵌入式应用层、嵌入式底层和硬件分别评估实现与工作量，测试评估验证成本，业务批准后更新对应基线，并从受影响阶段继续推进。</p>
|
|
||||||
</div>
|
|
||||||
<div class="crosscut">
|
|
||||||
<strong>成果适用性：Artifact Waiver（成果文件豁免）</strong>
|
|
||||||
<p>阶段成果默认必须由主责角色输出；仅当主责角色提交不适用申请、中心 AI 完成项目级适用性与影响审查并取得必要确认后，才能将该成果标记为 WAIVED。未批准的成果仍为 REQUIRED，并继续阻塞阶段门禁。</p>
|
|
||||||
</div>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<div class="if-atlas" id="information-flow-atlas">
|
|
||||||
<section class="if-intro">
|
|
||||||
<div class="if-eyebrow">STAGE INFORMATION FLOW ATLAS · V0.3</div>
|
|
||||||
<h2>各阶段角色信息流图谱</h2>
|
|
||||||
<p>以下内容直接承接总流程图，展示每条会影响成果、决策、门禁、返工或版本的正式信息流，并说明触发条件、发送方、接收方、载荷、确认要求和阻塞约束。</p>
|
|
||||||
<div class="if-quicknav">
|
|
||||||
<a href="#rules">通用规则</a><a href="#stage1">01 业务需求</a><a href="#stage2">02 产品定义</a><a href="#stage3">03 项目规划</a><a href="#stage4">04 方案设计</a><a href="#stage5">05 软硬件实现</a><a href="#stage6">06 测试验证</a><a href="#stage7">07 业务验收</a><a href="#stage8">08 发布结项</a><a href="#change">变更与异常</a><a href="#waiver">成果豁免</a>
|
|
||||||
</div>
|
|
||||||
</section>
|
|
||||||
<section class="if-section" id="rules">
|
|
||||||
<div class="if-section-head">
|
|
||||||
<div class="if-section-no">00 / RULES</div>
|
|
||||||
<div><h2>所有阶段共同遵守的流转规则</h2><p>角色可以直接讨论，但讨论不能自动成为项目事实；正式结论必须回到中心 AI，经过校验、登记和重新分发。</p></div>
|
|
||||||
</div>
|
|
||||||
<div class="if-callout">唯一正式路径：触发事件 → 主责角色内部完成 AI 辅助自审与人工确认 → 以统一角色主体提交中心 AI → 中心 AI 做形式校验、版本/证据检查和跨角色冲突检查 → 路由目标角色 → 目标角色内部确认后形成正式结果 → 中心 AI 登记与分发下游 → 更新门禁。信息流图只使用正式角色名称，不单列角色内部的 AI 会话与人工确认过程。</div>
|
|
||||||
<div class="if-callout" style="margin-top: 14px">成果默认 REQUIRED：主责角色必须输出；确认不适用时必须走 Artifact Waiver 流程。只有 APPROVED 的 WAIVED 状态可以替代成果满足门禁，任何角色都不得静默删除或跳过文件。</div>
|
|
||||||
<div class="if-role-legend">
|
|
||||||
<span class="if-actor if-center">中心 AI</span><span class="if-actor if-business">业务</span><span class="if-actor if-product">产品</span><span class="if-actor if-tech">技术负责人</span><span class="if-actor if-app">嵌入式应用层</span><span class="if-actor if-low">嵌入式底层</span><span class="if-actor if-hardware">硬件</span><span class="if-actor if-test">测试</span>
|
|
||||||
</div>
|
|
||||||
<div class="if-table-wrap" style="margin-bottom: 22px"><table><thead><tr><th>主体</th><th>是否为项目职能角色</th><th>定义</th><th>主要确认权限</th><th>不能做什么</th></tr></thead><tbody>
|
|
||||||
<tr><td>各专业角色</td><td>是</td><td>图中的正式角色名称统一代表该角色完成 AI 辅助自审与人工确认后的责任主体；内部审查过程不作为跨角色信息流单列。</td><td>以角色名义确认并发出本角色专业结论、正式成果、现实工期承诺、风险接受和正式交付。</td><td>不能替其他角色作出专业确认。</td></tr>
|
|
||||||
<tr><td>业务</td><td>是；同时承担项目级组织授权</td><td>业务节点同时包含业务专业判断和项目级组织授权的内部确认。</td><td>除业务成果外，负责确认计划基线、真实资源、预算、采购/打样、日期、暂停/取消和高影响成果豁免。</td><td>不替代产品、技术负责人、硬件或测试等角色给出专业结论。</td></tr>
|
|
||||||
<tr><td>中心 AI</td><td>是；承担项目角色</td><td>项目唯一正式信息中心、任务路由器、成果校验器、阶段门禁执行者和项目状态内部记录维护者。</td><td>可依据证据更新项目状态、按角色需要分发状态快照、完成普通项目级审查和低影响豁免；高影响事项必须升级给业务。</td><td>不能自行承诺真实资源、预算、范围、日期或专业结论，也不能以推测代替角色提供的状态证据。</td></tr>
|
|
||||||
</tbody></table></div>
|
|
||||||
<div class="if-flow-board">
|
|
||||||
<div class="if-exchange"><div class="if-actor if-business">任意角色</div><div class="if-arrow"><span class="if-flow-id">G.1</span><strong>提交已完成内部审查确认的消息、成果或请求</strong><small>附 self_check_result、internal_approved、项目、任务、版本和证据引用</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">G.2</span><strong>形式校验、跨角色冲突检查、登记并路由</strong><small>不替角色判断专业内容质量</small></div><div class="if-actor if-product">目标角色</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-product">目标角色</div><div class="if-arrow"><span class="if-flow-id">G.3</span><strong>完成内部审查后返回结构化结果</strong><small>角色内部确认不单列；禁止转发完整聊天记录</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
</div>
|
|
||||||
<div class="if-callout" style="margin: 22px 0 14px"><strong>项目状态内部记录与按需同步：</strong>Project Status Record（项目状态内部记录）是中心 AI 持续维护的内部运行记录，不是新增角色。它汇总当前阶段、门禁、任务、依赖、阻塞、风险、决策、成果基线、下一步和时限；中心 AI 在关键状态变化时主动推送，也响应角色按项目、阶段或任务发起的查询。</div>
|
|
||||||
<div class="if-flow-board">
|
|
||||||
<div class="if-exchange if-conditional"><div class="if-actor if-business">任意角色</div><div class="if-arrow"><span class="if-flow-id">S.1 · 按需查询</span><strong>请求与本角色职责相关的最新项目状态</strong><small>指定 project_id、stage/task scope、关注项和期望时点</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">S.2 · 自动或按需</span><strong>生成并分发角色化项目状态快照</strong><small>关键状态变化时主动推送；收到 S.1 后按查询范围返回</small></div><div class="if-actor if-product">请求角色及受影响角色</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-product">接收角色</div><div class="if-arrow"><span class="if-flow-id">S.3</span><strong>确认状态或携带证据提出纠正</strong><small>不得仅凭口头判断覆盖已登记状态</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange if-conditional"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">S.4 · 状态纠正</span><strong>校验依据、更新内部记录并重新分发</strong><small>保留旧状态、变更原因、证据引用和生效时间</small></div><div class="if-actor if-product">全部受影响角色</div></div>
|
|
||||||
</div>
|
|
||||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>对项目执行的影响</th></tr></thead><tbody>
|
|
||||||
<tr><td>S.1</td><td>角色需要了解当前项目、阶段、任务、依赖、风险或门禁状态，但现有上下文不足或可能已过期。</td><td>任意角色 → 中心 AI</td><td>project_id、请求范围、关注字段、所需详细度、as_of 要求和用途。</td><td>只能查询项目授权范围内的信息；请求角色无需知道中心 AI 的内部存储结构。</td><td>创建一次按需状态查询。</td></tr>
|
|
||||||
<tr><td>S.2</td><td>收到 S.1；或阶段/门禁、任务分派、依赖、阻塞、风险、决策、成果基线、required_by 发生关键变化。</td><td>中心 AI → 请求角色及受影响角色</td><td>Project Status Snapshot：project_id、state_version、as_of、stage/gate、相关任务、依赖、阻塞、风险、决策、baseline_refs、next_actions、required_by、evidence_refs。</td><td>按最小必要原则裁剪为角色化上下文；禁止转发无关角色的完整会话或未确认专业判断；所有状态必须有证据来源。</td><td>角色获得可执行的最新上下文。</td></tr>
|
|
||||||
<tr><td>S.3</td><td>角色收到状态快照。</td><td>接收角色 → 中心 AI</td><td>ACK；或 correction_request、受影响字段、正确值、原因、evidence_refs、internal_approved。</td><td>没有证据的异议不得直接覆盖状态；存在争议时进入 E.1–E.4。</td><td>确认可继续执行，或触发状态纠正。</td></tr>
|
|
||||||
<tr><td>S.4</td><td>纠正请求通过身份、版本、证据及跨角色一致性检查。</td><td>中心 AI → 全部受影响角色</td><td>新 state_version、变更字段、旧值/新值、变更原因、证据、生效时间及受影响任务。</td><td>保留状态历史，不覆盖旧版本；改变正式基线时必须转入 Change Request。</td><td>相关角色切换到新的有效状态快照。</td></tr>
|
|
||||||
</tbody></table></div>
|
|
||||||
<div class="if-callout" style="margin: 22px 0 14px"><strong>异常协同补充机制：</strong>任何条件流、阻塞流、跨角色冲突或无法在时限内异步收敛的问题，都必须进入 E.1–E.4。中心 AI 主动提醒关联角色并提供完整问题包；问题复杂时建议由当前主责角色组织线下会议。会议本身不直接形成项目事实，只有参与角色统一确认并回传中心 AI 的结构化结论，才能登记并恢复原流程。</div>
|
|
||||||
<div class="if-flow-board">
|
|
||||||
<div class="if-exchange if-conditional"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">E.1 · 异常触发</span><strong>主动提醒当前主责角色及全部关联角色</strong><small>发送问题、证据、冲突点、影响范围、原流程位置和响应时限</small></div><div class="if-actor if-product">当前主责角色及关联角色</div></div>
|
|
||||||
<div class="if-exchange if-conditional"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">E.2 · 复杂问题</span><strong>建议由当前主责角色组织线下会议</strong><small>提供建议参会角色、议题、待决策项、证据包和结论模板</small></div><div class="if-actor if-product">当前主责角色及关联角色</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-product">当前主责角色</div><div class="if-arrow"><span class="if-flow-id">E.3</span><strong>提交参与角色统一确认的会议结论</strong><small>包含结论、分歧处理、变更项、责任角色、期限、版本和确认状态</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">E.4</span><strong>校验、登记结论并恢复原异常流程</strong><small>只恢复被阻塞的原流程，不以会议记录替代正式成果</small></div><div class="if-actor if-product">原流程及关联角色</div></div>
|
|
||||||
</div>
|
|
||||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>对原流程的影响</th></tr></thead><tbody>
|
|
||||||
<tr><td>E.1</td><td>条件流或阻塞流被触发；出现跨角色冲突、依赖异常、证据矛盾、任务逾期或结果无法被下游使用。</td><td>中心 AI → 当前主责角色及全部关联角色</td><td>issue_id、source_flow_id、问题摘要、证据与版本引用、冲突点、影响范围、关联角色、required_by。</td><td>中心 AI 必须主动提醒，不得只更新状态；关联角色依据正式问题包开展异步确认。</td><td class="if-block">原流程保持 ACTIVE/BLOCKED，等待问题关闭。</td></tr>
|
|
||||||
<tr><td>E.2</td><td>涉及多个专业角色且结论冲突，影响范围/架构/接口/成本/进度/质量，或在要求时限内无法通过异步消息收敛。</td><td>中心 AI → 当前主责角色及关联角色</td><td>建议参会名单、会议目的、议题、冲突矩阵、证据包、待决策项、结论模板和完成时限。</td><td>中心 AI 只建议会议和准备输入，不主持专业裁决；当前主责角色负责组织，关联角色共同参与确认。</td><td class="if-block">会议结论回传前，不恢复原流程。</td></tr>
|
|
||||||
<tr><td>E.3</td><td>线下会议完成并形成统一结论。</td><td>当前主责角色 → 中心 AI</td><td>Meeting Decision Record：参与角色、统一结论、保留分歧、变更项、责任角色、期限、artifact/version/evidence_refs、internal_approved。</td><td>禁止只上传录音、聊天记录或未经参与角色确认的纪要；仍有分歧时继续保持阻塞并明确升级项。</td><td>形成可登记的异常处置结论。</td></tr>
|
|
||||||
<tr><td>E.4</td><td>统一结论通过中心 AI 的形式、版本、证据和跨角色一致性检查。</td><td>中心 AI → 原流程及关联角色</td><td>decision_id、登记结果、受影响成果/任务、恢复点、后续动作和新时限。</td><td>中心 AI 不改写专业结论；若结论改变正式基线，必须转入 Change Request。</td><td class="if-pass">从 source_flow_id 对应位置恢复当前流程。</td></tr>
|
|
||||||
</tbody></table></div>
|
|
||||||
<div class="if-table-wrap"><table><thead><tr><th>通用约束</th><th>执行要求</th><th>不满足时</th></tr></thead><tbody>
|
|
||||||
<tr><td>消息身份</td><td>必须包含 project_id、task_id、message_id、from/to role、stage、reply_to。</td><td class="if-block">拒绝进入正式流。</td></tr>
|
|
||||||
<tr><td>成果版本</td><td>必须包含 artifact_id、version、status、supersedes、evidence_refs。</td><td class="if-block">标记为 DRAFT 或 REJECTED_ARTIFACT。</td></tr>
|
|
||||||
<tr><td>成果责任</td><td>原则上由流程图指定的主责角色创建、更新并提交对应成果。</td><td class="if-block">其他角色不能代签；中心 AI 返回主责角色。</td></tr>
|
|
||||||
<tr><td>角色内部审查</td><td>每个角色必须在内部完成 AI 辅助的 Schema/专业检查以及人工确认；跨角色流转时统一以正式角色名称表示。</td><td class="if-block">未附 self_check_result 或 internal_approved 的成果不能提交中心 AI。</td></tr>
|
|
||||||
<tr><td>专业发起权</td><td>专业活动由对应主责角色判断并发起；中心 AI 只负责格式校验、任务路由、状态跟踪和结果登记。</td><td class="if-block">中心 AI 不得越权替角色发起专业决策。</td></tr>
|
|
||||||
<tr><td>中心 AI 审查边界</td><td>仅做 Schema/必填结构、身份、版本、证据、审批状态检查，以及多个角色正式信息之间的重复、冲突和依赖一致性检查。</td><td class="if-block">不得替业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件或测试判断本专业内容是否充分。</td></tr>
|
|
||||||
<tr><td>成果豁免</td><td>仅主责角色可提出不适用申请；经中心 AI 项目审查及必要确认后标记 WAIVED。</td><td class="if-block">未批准仍为 REQUIRED，继续阻塞门禁。</td></tr>
|
|
||||||
<tr><td>角色确认</td><td>专业结论由对应角色内部形成并确认；项目级组织授权由业务内部完成。信息流图只显示统一的正式角色主体。</td><td class="if-block">未完成内部确认时不得对外发出，阶段保持 WAITING_CONFIRMATION。</td></tr>
|
|
||||||
<tr><td>项目状态同步</td><td>中心 AI 维护有版本和证据的项目状态内部记录，并在关键变化时主动向受影响角色推送，或按 S.1–S.4 响应角色查询与纠正。</td><td class="if-block">状态来源、版本或时点不明时不得作为任务执行依据。</td></tr>
|
|
||||||
<tr><td>异常协同</td><td>中心 AI 对异常主动提醒关联角色；复杂问题建议当前主责角色组织线下会议，统一确认后提交结构化结论。</td><td class="if-block">未按 E.1–E.4 闭环，不得恢复原流程或推进门禁。</td></tr>
|
|
||||||
<tr><td>直接讨论</td><td>最终结论、约束、证据和影响必须回传中心 AI。</td><td class="if-block">不能作为下游输入。</td></tr>
|
|
||||||
<tr><td>门禁</td><td>只有成果完整、版本正确、证据可访问、确认齐全时才能 PASS。</td><td class="if-block">阶段保持 ACTIVE/BLOCKED。</td></tr>
|
|
||||||
</tbody></table></div>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section class="if-section" id="stage1">
|
|
||||||
<div class="if-section-head"><div class="if-section-no">01 / BUSINESS</div><div><h2>阶段 1：业务需求信息流</h2><p>把客户背景、商业目标和关键里程碑转换成经过业务角色内部确认的需求基线。</p></div></div>
|
|
||||||
<div class="if-stage-summary"><div class="if-summary-card"><b>主责</b><span>业务</span></div><div class="if-summary-card"><b>核心成果</b><span>项目背景说明、项目目标与里程碑计划</span></div><div class="if-summary-card"><b>门禁</b><span>业务完成内部审查并确认需求基线</span></div></div>
|
|
||||||
<div class="if-callout" style="margin-bottom: 18px; font-size: 14px">业务在内部完成原始信息收集、业务成果 Schema 检查和人工确认后，以统一的“业务”主体提交成果。中心 AI 完成形式校验、版本登记和跨角色冲突检查后，将业务成果评审版本路由给产品；产品据此判断是否需要早期风险预检，并负责指定一个或多个预检对象角色。中心 AI 只能按照产品给出的角色名单路由，不得自行增删或替换。业务最终确认后，中心 AI 再向产品分发正式业务基线并开启产品定义。</div>
|
|
||||||
<div class="if-flow-board">
|
|
||||||
<div class="if-exchange"><div class="if-actor if-business">业务</div><div class="if-arrow"><span class="if-flow-id">F1.1</span><strong>提交完成内部审查的项目背景与里程碑草案</strong><small>附 self_check_result、internal_approved 和来源引用</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange if-conditional if-blocking"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F1.2 · 条件触发</span><strong>仅在发现形式错误或跨来源冲突时返回问题</strong><small>触发范围仅限 Schema、身份、版本、证据和已登记信息冲突；无异常则不启用此流</small></div><div class="if-actor if-business">业务</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F1.3</span><strong>分发已通过形式校验的业务成果评审版本</strong><small>附成果版本、证据引用、状态和待确认项</small></div><div class="if-actor if-product">产品</div></div>
|
|
||||||
<div class="if-exchange if-conditional"><div class="if-actor if-product">产品</div><div class="if-arrow"><span class="if-flow-id">F1.4</span><strong>指定对象角色并提交早期风险预检请求</strong><small>产品根据风险内容选择一个或多个项目角色</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F1.5</span><strong>按产品指定名单校验、提醒并路由预检任务</strong><small>主动提醒全部关联角色；不得增删产品指定名单</small></div><div class="if-actor if-tech">产品指定的对象角色</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-tech">产品指定的对象角色</div><div class="if-arrow"><span class="if-flow-id">F1.6</span><strong>返回内部确认结果；复杂问题返回统一会议结论</strong><small>无法异步收敛时，由产品组织线下会议并按 E.3 回传</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-business">业务</div><div class="if-arrow"><span class="if-flow-id">F1.7</span><strong>确认需求基线</strong><small>业务内部审查、形式校验和预检问题均已关闭</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F1.8</span><strong>向产品分发正式业务基线并开启产品定义</strong><small>只能引用已 BASELINED 的成果版本</small></div><div class="if-actor if-product">产品</div></div>
|
|
||||||
</div>
|
|
||||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>对阶段的影响</th></tr></thead><tbody>
|
|
||||||
<tr><td>F1.1</td><td>收到新的客户或商业机会，且业务已完成原始信息收集、Schema 自审和内部确认。</td><td>业务 → 中心 AI</td><td>项目背景、里程碑、self_check_result、internal_approved、来源和草案版本。</td><td>中心 AI 不重复判断业务内容质量，只检查形式和跨来源一致性。</td><td>进入中心登记。</td></tr>
|
|
||||||
<tr><td>F1.2（条件流）</td><td>仅当 Schema/身份/版本/证据不合规，或与已登记正式信息发生冲突时触发；不存在上述问题时跳过。</td><td>中心 AI → 业务</td><td>形式错误、冲突来源、受影响字段和修正要求。</td><td>中心 AI 不能生成业务缺失项或替业务补写事实；无错误或冲突时不得发起此流。</td><td class="if-block">触发后，错误或冲突关闭前阻塞登记；未触发则直接进入 F1.3。</td></tr>
|
|
||||||
<tr><td>F1.3</td><td>业务成果通过中心 AI 的 Schema、身份、版本、证据和跨角色冲突检查并完成登记。</td><td>中心 AI → 产品</td><td>业务成果评审版本、artifact_id、version、status、evidence_refs、待确认项和回复时限。</td><td>状态必须标明 REVIEW_READY；不得冒充 BASELINED 正式成果，产品不得据此直接启动阶段 2。</td><td>产品获得早期风险识别所需上下文。</td></tr>
|
|
||||||
<tr><td>F1.4</td><td>产品审阅业务成果后，判断存在需要其他专业角色提前确认的风险。</td><td>产品 → 中心 AI</td><td>预检原因、预检问题、target_role_ids、相关需求字段、期望输出和时限；目标角色可为一个或多个。</td><td>是否预检、预检范围及对象角色均由产品负责指定；中心 AI 不代替产品判断。</td><td>按产品指定名单创建预检任务。</td></tr>
|
|
||||||
<tr><td>F1.5–1.6</td><td>产品预检请求格式完整，且指定的对象角色均为当前项目有效成员。</td><td>中心 AI ↔ 产品指定的对象角色</td><td>按对象角色拆分的预检问题、相关业务字段、成果版本、回复要求和时限；各对象角色返回内部确认后的本专业红线、风险、证据与待澄清项。</td><td>中心 AI 必须主动提醒全部关联角色，只校验、路由和汇总，不得自行增删产品指定名单。多角色结论冲突、影响较大或无法异步收敛时，建议由产品组织线下会议；参与角色统一确认的结论按 E.3 回传后，才能继续当前流程。</td><td>补充业务澄清和早期风险登记；复杂问题进入 E.1–E.4，闭环前保持阻塞。</td></tr>
|
|
||||||
<tr><td>F1.7</td><td>业务内部审查、中心形式校验和预检问题均已关闭。</td><td>业务 → 中心 AI</td><td>INTERNALLY_APPROVED 的需求和里程碑版本。</td><td>角色内部确认状态、时间和版本必须记录。</td><td class="if-pass">门禁可进入评审。</td></tr>
|
|
||||||
<tr><td>F1.8</td><td>业务确认完成，中心 AI 已登记 BASELINED 正式版本且阶段门禁 PASS。</td><td>中心 AI → 产品</td><td>正式业务成果、artifact_id、version、baseline_refs、evidence_refs、阶段 2 任务和确认时限。</td><td>只允许分发 BASELINED 当前有效版本；分发事件和接收状态必须登记，草稿或过期版本不得作为产品定义输入。</td><td class="if-pass">产品接收后开启阶段 2。</td></tr>
|
|
||||||
</tbody></table></div>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section class="if-section" id="stage2">
|
|
||||||
<div class="if-section-head"><div class="if-section-no">02 / PRODUCT</div><div><h2>阶段 2：产品定义信息流</h2><p>产品形成完整立项资料，并让技术负责人、嵌入式应用层、嵌入式底层、硬件和测试从各自专业角度完成可行性确认。</p></div></div>
|
|
||||||
<div class="if-stage-summary"><div class="if-summary-card"><b>主责</b><span>产品；业务批准范围</span></div><div class="if-summary-card"><b>核心成果</b><span>立项资料、硬件/嵌入式资料、验收标准、里程碑要求</span></div><div class="if-summary-card"><b>门禁</b><span>产品确认方案，业务批准范围，约束和测试标准完整</span></div></div>
|
|
||||||
<div class="if-flow-board">
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F2.1</span><strong>下发产品定义任务</strong><small>附阶段 1 基线和全部红线约束</small></div><div class="if-actor if-product">产品</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-product">产品</div><div class="if-arrow"><span class="if-flow-id">F2.2</span><strong>提交立项资料草案与专业评审请求</strong><small>产品明确评审角色、问题、范围和期望输出</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F2.3</span><strong>校验请求并并行路由专业评审</strong><small>按产品指定范围裁剪上下文，不新增专业问题</small></div><div class="if-actor if-tech">技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-tech">评审角色</div><div class="if-arrow"><span class="if-flow-id">F2.4</span><strong>返回可行性、缺口和约束</strong><small>每条意见必须关联具体成果字段</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange if-blocking"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F2.5</span><strong>汇总跨角色冲突并返回产品裁决/修订</strong><small>中心 AI 只指出冲突，不替产品作内容决定</small></div><div class="if-actor if-product">产品</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-product">产品</div><div class="if-arrow"><span class="if-flow-id">F2.6</span><strong>提交内部确认后的产品方案</strong><small>关闭评审问题并标明保留风险</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F2.7</span><strong>请求业务批准范围</strong><small>呈现范围、里程碑、成本/风险影响</small></div><div class="if-actor if-business">业务</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-business">业务</div><div class="if-arrow"><span class="if-flow-id">F2.8</span><strong>批准、驳回或附条件批准</strong><small>附条件项必须有责任人与期限</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
</div>
|
|
||||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>对阶段的影响</th></tr></thead><tbody>
|
|
||||||
<tr><td>F2.1–2.2</td><td>阶段 2 启动。</td><td>中心 AI ↔ 产品</td><td>需求基线、立项书、规格、功能/灯态/产测清单、版本说明、板框图、验收标准，以及产品定义的评审角色/问题/范围。</td><td>产品先自审，所有资料必须引用阶段 1 基线；专业评审由产品发起。</td><td>进入专业评审路由。</td></tr>
|
|
||||||
<tr><td>F2.3</td><td>产品提交可评审草案和评审请求。</td><td>中心 AI → 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</td><td>产品定义的角色化评审任务和相关资料。</td><td>中心 AI 只校验和路由；技术负责人看总体，嵌入式应用层看功能，嵌入式底层看 BSP/HAL，硬件看器件/板框，测试看可测性。</td><td>并行评审。</td></tr>
|
|
||||||
<tr><td>F2.4</td><td>各角色完成评审。</td><td>技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试 → 中心 AI</td><td>结论、缺失、风险、证据、建议和是否阻塞。</td><td>不得只回复“可行/不可行”。</td><td>形成冲突矩阵。</td></tr>
|
|
||||||
<tr><td>F2.5–2.6</td><td>存在冲突或缺口。</td><td>中心 AI ↔ 产品</td><td>字段级修订清单、变更影响、关闭说明。</td><td>产品在内部确认最终版本后统一发出。</td><td class="if-block">问题未关闭则 HOLD。</td></tr>
|
|
||||||
<tr><td>F2.7–2.8</td><td>产品方案专业评审完成。</td><td>中心 AI ↔ 业务</td><td>范围、验收、里程碑、风险和附条件事项。</td><td>范围批准由业务完成内部授权后统一给出。</td><td class="if-pass">批准后进入阶段 3。</td></tr>
|
|
||||||
</tbody></table></div>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section class="if-section" id="stage3">
|
|
||||||
<div class="if-section-head"><div class="if-section-no">03 / PLANNING</div><div><h2>阶段 3：项目规划信息流</h2><p>中心 AI 根据有效基线生成任务计划草案，先由技术负责人确认整体任务结构、技术顺序和依赖；仅对存在疑点的任务，定向向对应执行角色补充确认。</p></div></div>
|
|
||||||
<div class="if-stage-summary"><div class="if-summary-card"><b>主责</b><span>中心 AI；技术负责人确认任务计划</span></div><div class="if-summary-card"><b>核心成果</b><span>项目计划、风险登记、角色分工、产品资料整合、项目状态内部记录</span></div><div class="if-summary-card"><b>门禁</b><span>技术负责人确认整体计划；问题任务完成定向确认；业务确认资源与日期基线</span></div></div>
|
|
||||||
<div class="if-flow-board">
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F3.1</span><strong>提交任务计划草案，请求整体确认</strong><small>附 WBS、技术顺序、依赖、初始排期、风险和基线引用</small></div><div class="if-actor if-tech">技术负责人</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-tech">技术负责人</div><div class="if-arrow"><span class="if-flow-id">F3.2</span><strong>确认整体任务计划或返回调整意见</strong><small>确认任务结构、技术顺序、依赖关系和关键风险</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange if-conditional"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F3.3 · 问题任务</span><strong>仅对存在疑点的任务发起定向确认</strong><small>缺少责任、输入输出、依赖、估算、资源、日期、证据或存在冲突时触发</small></div><div class="if-actor if-product">对应执行角色</div></div>
|
|
||||||
<div class="if-exchange if-conditional"><div class="if-actor if-product">对应执行角色</div><div class="if-arrow"><span class="if-flow-id">F3.4</span><strong>只确认被询问任务的工期、资源和风险</strong><small>不得要求执行角色重复确认整份任务计划</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange if-blocking"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F3.5</span><strong>提醒关联角色并协调剩余冲突、重排计划</strong><small>问题仍未关闭或日期不可达时按 E.1–E.4 处理</small></div><div class="if-actor if-product">技术负责人及受影响角色</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F3.6</span><strong>请求资源与日期基线授权</strong><small>真实人员、采购、打样、成本和日期由业务内部确认</small></div><div class="if-actor if-business">业务</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-business">业务</div><div class="if-arrow"><span class="if-flow-id">F3.7</span><strong>批准或要求调整资源与日期基线</strong><small>记录内部批准状态、范围和条件</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F3.8</span><strong>向相关执行角色发布基线计划和正式任务</strong><small>附任务 ID、依赖、交付物和门禁；后续状态按 S.1–S.4 同步</small></div><div class="if-actor if-product">相关执行角色</div></div>
|
|
||||||
</div>
|
|
||||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>对阶段的影响</th></tr></thead><tbody>
|
|
||||||
<tr><td>F3.1–3.2</td><td>阶段 2 门禁通过，中心 AI 已依据有效基线形成任务计划草案。</td><td>中心 AI ↔ 技术负责人</td><td>WBS、任务结构、技术顺序、关键路径、输入输出、依赖、初始排期、风险和基线引用。</td><td>技术负责人确认整体任务计划；中心 AI 不直接向全部执行角色征求整份计划确认。</td><td>形成技术负责人确认的任务计划草案。</td></tr>
|
|
||||||
<tr><td>F3.3–3.4（条件流）</td><td>中心 AI 发现任务缺少责任角色、输入、输出、依赖、估算、资源、日期或证据；任务之间存在冲突；或技术负责人明确标记待确认项。</td><td>中心 AI ↔ 对应执行角色</td><td>仅包含问题任务的 task_id、疑点字段、上下游依赖、基线引用、待确认问题、回复要求和时限；执行角色返回该任务的工期、资源、风险、依据和 internal_approved。</td><td>必须定向发送给该任务的执行角色，不得广播给全部角色，也不得要求执行角色重复确认无疑点任务。</td><td>补齐或修正问题任务；未触发时直接跳过。</td></tr>
|
|
||||||
<tr><td>F3.5</td><td>定向确认后仍存在资源冲突、关键路径冲突或日期不可达。</td><td>中心 AI ↔ 技术负责人及受影响角色</td><td>冲突点、可选排法、阶段影响、关联角色和响应时限。</td><td>中心 AI 必须主动提醒，不得静默覆盖技术负责人或执行角色的确认；复杂冲突按 E.1–E.4 闭环。</td><td class="if-block">保持计划草案，冲突关闭前不得基线化。</td></tr>
|
|
||||||
<tr><td>F3.6–3.7</td><td>技术负责人已确认整体计划，问题任务和剩余冲突均已关闭，计划涉及真实人员、采购、打样、成本或日期基线。</td><td>中心 AI ↔ 业务</td><td>任务计划、资源请求、成本、里程碑和风险。</td><td>中心 AI 无权自行批准现实资源和日期；业务完成内部授权后统一回复。</td><td class="if-pass">批准后可基线化。</td></tr>
|
|
||||||
<tr><td>F3.8</td><td>技术负责人确认有效、问题任务已关闭且业务批准资源与日期基线。</td><td>中心 AI → 相关执行角色</td><td>BASELINED 计划、角色相关正式任务、风险登记和初始 Project Status Snapshot。</td><td>每个角色只接收与自身任务和依赖相关的计划内容；后续变更走 Change Request，执行状态按 S.1–S.4 同步。</td><td class="if-pass">相关角色接收任务，开启阶段 4。</td></tr>
|
|
||||||
</tbody></table></div>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section class="if-section" id="stage4">
|
|
||||||
<div class="if-section-head"><div class="if-section-no">04 / DESIGN</div><div><h2>阶段 4：方案设计信息流</h2><p>技术负责人组织总体方案；产品、嵌入式应用层、嵌入式底层、硬件和测试围绕同一份软硬件接口契约完成多轮确认。</p></div></div>
|
|
||||||
<div class="if-stage-summary"><div class="if-summary-card"><b>主责</b><span>技术负责人</span></div><div class="if-summary-card"><b>核心成果</b><span>总体技术方案、软硬件接口契约、硬件设计包、架构决策、测试计划</span></div><div class="if-summary-card"><b>门禁</b><span>方案确认、接口可实施、需求不偏离、测试可验证</span></div></div>
|
|
||||||
<div class="if-flow-board">
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F4.1</span><strong>下发总体方案设计任务</strong><small>附产品基线、计划、风险和所有约束</small></div><div class="if-actor if-tech">技术负责人</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-tech">技术负责人</div><div class="if-arrow"><span class="if-flow-id">F4.2</span><strong>提交总体方案与接口契约草案</strong><small>含边界、关键决策、非功能和风险</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F4.3</span><strong>并行分发角色化设计任务</strong><small>每个角色在同一契约版本上工作</small></div><div class="if-actor if-app">产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</div></div>
|
|
||||||
<div class="if-exchange if-conditional"><div class="if-actor if-app">嵌入式应用层</div><div class="if-arrow"><span class="if-flow-id">F4.4</span><strong>提出 HAL、资源和应用接口需求</strong><small>接口新增或资源不足时触发</small></div><div class="if-actor if-center">中心 AI → 嵌入式底层 / 技术负责人</div></div>
|
|
||||||
<div class="if-exchange if-conditional"><div class="if-actor if-low">嵌入式底层</div><div class="if-arrow"><span class="if-flow-id">F4.5</span><strong>提出引脚、电平、时序和器件约束</strong><small>HAL 与硬件设计存在依赖时</small></div><div class="if-actor if-center">中心 AI → 硬件 / 技术负责人</div></div>
|
|
||||||
<div class="if-exchange if-conditional"><div class="if-actor if-hardware">硬件</div><div class="if-arrow"><span class="if-flow-id">F4.6</span><strong>反馈器件、PCB、电源、空间与热约束</strong><small>影响接口、成本或性能时</small></div><div class="if-actor if-center">中心 AI → 技术负责人 / 嵌入式底层 / 产品</div></div>
|
|
||||||
<div class="if-exchange if-blocking"><div class="if-actor if-test">测试</div><div class="if-arrow"><span class="if-flow-id">F4.7</span><strong>提交不可测试项和环境/治具缺口</strong><small>验收标准无法验证时</small></div><div class="if-actor if-center">中心 AI → 相关角色</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F4.8</span><strong>汇总冲突并要求总体方案修订</strong><small>形成决策清单和待关闭问题</small></div><div class="if-actor if-tech">技术负责人</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-tech">技术负责人</div><div class="if-arrow"><span class="if-flow-id">F4.9</span><strong>提交内部确认的最终方案和契约基线</strong><small>所有阻塞问题关闭后</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F4.10</span><strong>请求各角色确认接口可实施</strong><small>嵌入式应用层、嵌入式底层、硬件、产品、测试分别确认</small></div><div class="if-actor if-product">产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</div></div>
|
|
||||||
</div>
|
|
||||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>对阶段的影响</th></tr></thead><tbody>
|
|
||||||
<tr><td>F4.1–4.3</td><td>阶段 4 启动且计划基线有效。</td><td>中心 AI ↔ 技术负责人/协作角色</td><td>总体方案草案、角色化设计任务、统一契约版本。</td><td>所有设计必须引用同一 product/plan baseline。</td><td>开启并行设计。</td></tr>
|
|
||||||
<tr><td>F4.4</td><td>嵌入式应用层需要新的资源、HAL 或协议。</td><td>嵌入式应用层 → 中心 AI → 嵌入式底层 / 技术负责人</td><td>接口需求、调用频率、性能和资源指标。</td><td>不得绕过契约直接约定。</td><td>可能触发契约修订。</td></tr>
|
|
||||||
<tr><td>F4.5</td><td>嵌入式底层依赖引脚、电平、器件或时序。</td><td>嵌入式底层 → 中心 AI → 硬件 / 技术负责人</td><td>HAL、引脚表、时序、电气约束。</td><td>硬件回复必须引用板卡版本。</td><td class="if-block">冲突时阻塞相关设计。</td></tr>
|
|
||||||
<tr><td>F4.6</td><td>器件、PCB、电源、空间或热约束影响方案。</td><td>硬件 → 中心 AI → 技术负责人 / 嵌入式底层 / 产品</td><td>限制、替代方案、成本、性能和交期影响。</td><td>器件替换不得静默发生。</td><td>形成 ADR/Change Request。</td></tr>
|
|
||||||
<tr><td>F4.7</td><td>测试无法验证某项需求或缺环境/治具。</td><td>测试 → 中心 AI → 相关角色</td><td>不可测项、证据要求、环境和治具需求。</td><td>必须在实现前关闭。</td><td class="if-block">门禁 HOLD。</td></tr>
|
|
||||||
<tr><td>F4.8–4.10</td><td>专业评审完成。</td><td>中心 AI ↔ 技术负责人 ↔ 产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</td><td>修订方案、最终契约和角色内部确认状态。</td><td>每个确认绑定同一版本。</td><td class="if-pass">全部确认后进入阶段 5。</td></tr>
|
|
||||||
</tbody></table></div>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section class="if-section" id="stage5">
|
|
||||||
<div class="if-section-head"><div class="if-section-no">05 / IMPLEMENT</div><div><h2>阶段 5：嵌入式软硬件实现信息流</h2><p>三条实现流并行推进，但固件只有一条正式出口：嵌入式底层先提供可消费版本，嵌入式应用层完成合版并提交统一固件，中心 AI 维护其与硬件版本的唯一映射。</p></div></div>
|
|
||||||
<div class="if-stage-summary"><div class="if-summary-card"><b>并行主责</b><span>嵌入式应用层、嵌入式底层、硬件</span></div><div class="if-summary-card"><b>核心成果</b><span>硬件实现资料、嵌入式底层实现资料、嵌入式应用层提交的统一固件包</span></div><div class="if-summary-card"><b>门禁</b><span>嵌入式应用层提交最终固件，技术负责人确认固件与硬件版本匹配并可提测</span></div></div>
|
|
||||||
<div class="if-flow-board">
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F5.1</span><strong>并行下发三类实现任务</strong><small>锁定总体方案、契约和任务边界</small></div><div class="if-actor if-app">嵌入式应用层 / 嵌入式底层 / 硬件</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-hardware">硬件</div><div class="if-arrow"><span class="if-flow-id">F5.2</span><strong>提交板卡、BOM、接口与样机版本</strong><small>硬件发布或 ECO 时触发</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F5.3</span><strong>广播硬件版本及约束变化</strong><small>只向受影响角色分发完整影响包</small></div><div class="if-actor if-low">技术负责人 / 嵌入式底层 / 嵌入式应用层 / 测试</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-low">嵌入式底层</div><div class="if-arrow"><span class="if-flow-id">F5.4</span><strong>提交 BSP/PSP、驱动与测试固件</strong><small>带板卡、HAL 和接口契约版本</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F5.5</span><strong>将已登记的嵌入式底层版本交给嵌入式应用层合版</strong><small>测试不得直接将底层产物作为提测固件</small></div><div class="if-actor if-app">嵌入式应用层</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-app">嵌入式应用层</div><div class="if-arrow"><span class="if-flow-id">F5.6</span><strong>集成底层版本并提交统一固件候选</strong><small>绑定应用、底层、板卡和契约版本，包含 MD5、分区、自测和 Changelog</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange if-blocking"><div class="if-actor if-app">任一实现角色</div><div class="if-arrow"><span class="if-flow-id">F5.7</span><strong>报告接口、器件或资源冲突</strong><small>契约不一致、资源超限或 ECO 影响时</small></div><div class="if-actor if-center">中心 AI → 技术负责人</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F5.8</span><strong>创建软硬件联调与版本矩阵确认任务</strong><small>统一固件候选和硬件候选版本均可用时</small></div><div class="if-actor if-app">嵌入式应用层 / 硬件 / 技术负责人</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-app">嵌入式应用层</div><div class="if-arrow"><span class="if-flow-id">F5.9</span><strong>提交最终提测固件版本</strong><small>最终固件只能由嵌入式应用层提交，附完整版本链、自测和偏离说明</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-tech">技术负责人</div><div class="if-arrow"><span class="if-flow-id">F5.10</span><strong>确认最终固件与硬件版本匹配并可提测</strong><small>板卡、BOM、统一固件及其应用/底层版本链完全匹配</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
</div>
|
|
||||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>对阶段的影响</th></tr></thead><tbody>
|
|
||||||
<tr><td>F5.1</td><td>方案设计门禁通过。</td><td>中心 AI → 嵌入式应用层 / 嵌入式底层 / 硬件</td><td>任务、契约、版本、输出格式、依赖和期限。</td><td>三方必须使用相同契约版本。</td><td>启动并行实现。</td></tr>
|
|
||||||
<tr><td>F5.2–5.3</td><td>硬件发布样机、板卡、BOM 或 ECO。</td><td>硬件 → 中心 AI → 技术负责人 / 嵌入式底层 / 嵌入式应用层 / 测试</td><td>板卡/BOM/ECO、接口、限制和影响范围。</td><td>没有影响分析不得切换硬件版本。</td><td class="if-block">影响接口时阻塞受影响任务。</td></tr>
|
|
||||||
<tr><td>F5.4–5.5</td><td>嵌入式底层形成可消费版本。</td><td>嵌入式底层 → 中心 AI → 嵌入式应用层</td><td>BSP/PSP、HAL、驱动、底层测试固件、适配板卡和契约版本。</td><td>必须声明适配板卡和契约版本；测试不得把底层产物直接作为提测固件。</td><td>允许嵌入式应用层合版。</td></tr>
|
|
||||||
<tr><td>F5.6</td><td>嵌入式应用层收到已登记的嵌入式底层可消费版本。</td><td>嵌入式应用层 → 中心 AI</td><td>统一固件候选、应用版本、底层版本、板卡版本、契约版本、MD5、分区、日志、自测和 Changelog。</td><td>必须形成可追溯的应用层+底层统一版本；禁止提交无法复现的单一二进制。</td><td>进入软硬件联调候选。</td></tr>
|
|
||||||
<tr><td>F5.7</td><td>引脚、时序、资源、器件或协议冲突。</td><td>角色 → 中心 AI → 技术负责人</td><td>冲突、证据、版本、影响和建议。</td><td>中心 AI 立即冻结受影响版本。</td><td class="if-block">等待技术裁决或契约新版本。</td></tr>
|
|
||||||
<tr><td>F5.8–5.10</td><td>统一固件候选和硬件候选均已提交，联调问题已经关闭。</td><td>中心 AI ↔ 嵌入式应用层 / 硬件 / 技术负责人</td><td>最终固件、应用/底层版本链、板卡/BOM/ECO、版本矩阵、联调记录、自测、偏离说明和集成审批。</td><td>最终提测固件只能由嵌入式应用层提交；嵌入式底层和硬件不得直接向测试提交固件。技术负责人确认版本矩阵匹配。</td><td class="if-pass">确认后由中心 AI 将该唯一固件版本交给测试。</td></tr>
|
|
||||||
</tbody></table></div>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section class="if-section" id="stage6">
|
|
||||||
<div class="if-section-head"><div class="if-section-no">06 / TEST</div><div><h2>阶段 6：测试验证与缺陷返工信息流</h2><p>测试提交证据和缺陷，中心 AI 按问题层级路由到产品、嵌入式应用层、嵌入式底层、硬件或技术负责人，并控制重新提测。</p></div></div>
|
|
||||||
<div class="if-stage-summary"><div class="if-summary-card"><b>主责</b><span>测试</span></div><div class="if-summary-card"><b>核心成果</b><span>功能、可靠性、专项测试报告，测试证据和缺陷分析</span></div><div class="if-summary-card"><b>门禁</b><span>阻断缺陷清零，证据完整，测试完成内部确认并提交质量结论</span></div></div>
|
|
||||||
<div class="if-flow-board">
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F6.1</span><strong>下发测试任务、最终固件和版本矩阵</strong><small>只允许测试由嵌入式应用层提交并经技术负责人批准的统一固件</small></div><div class="if-actor if-test">测试</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-test">测试</div><div class="if-arrow"><span class="if-flow-id">F6.2</span><strong>提交测试报告、证据和缺陷</strong><small>每个缺陷关联版本、用例和证据</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F6.3</span><strong>分类并路由缺陷</strong><small>嵌入式应用层/嵌入式底层/硬件/架构/需求/测试环境</small></div><div class="if-actor if-app">产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-app">责任角色</div><div class="if-arrow"><span class="if-flow-id">F6.4</span><strong>返回内部确认的原因分析、修复计划和影响范围</strong><small>正式修复承诺在角色内部确认后统一发出</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange if-blocking"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F6.5</span><strong>创建修复或技术裁决任务</strong><small>跨层问题交技术负责人，需求问题交产品</small></div><div class="if-actor if-tech">责任角色</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-app">责任角色</div><div class="if-arrow"><span class="if-flow-id">F6.6</span><strong>提交应用修复、底层修复或硬件 ECO</strong><small>必须生成新版本并声明 supersedes 和影响范围</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange if-conditional"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F6.7</span><strong>将固件相关修复交给嵌入式应用层重新合版</strong><small>底层修复必须合版；硬件变化由嵌入式应用层确认固件兼容性</small></div><div class="if-actor if-app">嵌入式应用层</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-app">嵌入式应用层</div><div class="if-arrow"><span class="if-flow-id">F6.8</span><strong>提交统一回归固件或确认原固件继续有效</strong><small>最终回归固件仍只能由嵌入式应用层提交</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F6.9</span><strong>下发定向回归任务和统一固件</strong><small>附修复范围、受影响用例和新版本矩阵</small></div><div class="if-actor if-test">测试</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-test">测试</div><div class="if-arrow"><span class="if-flow-id">F6.10</span><strong>提交内部确认的最终质量结论和剩余风险</strong><small>报告和证据完整后</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
</div>
|
|
||||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>对阶段的影响</th></tr></thead><tbody>
|
|
||||||
<tr><td>F6.1–6.2</td><td>技术负责人批准嵌入式应用层提交的最终固件与硬件集成版本。</td><td>中心 AI ↔ 测试</td><td>嵌入式应用层提交的统一固件、应用/底层版本链、板卡/BOM/ECO、版本矩阵、测试任务、报告、证据和缺陷。</td><td>测试只能接收嵌入式应用层提交且经技术负责人批准的最终固件；缺陷必须关联可复现环境和版本。</td><td>启动测试并更新测试状态。</td></tr>
|
|
||||||
<tr><td>F6.3</td><td>发现缺陷或测试异常。</td><td>中心 AI → 产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</td><td>缺陷、证据、严重度、归属依据和响应时限。</td><td>不确定归属时先交技术负责人/产品裁决。</td><td>建立返工任务。</td></tr>
|
|
||||||
<tr><td>F6.4–6.5</td><td>责任角色收到缺陷。</td><td>责任角色 ↔ 中心 AI</td><td>根因、影响、修复、风险、需重测范围。</td><td>不得以“无法复现”结案，必须附证据。</td><td class="if-block">阻断缺陷使阶段 BLOCKED。</td></tr>
|
|
||||||
<tr><td>F6.6–6.8</td><td>应用修复、嵌入式底层修复或硬件 ECO 已提交。</td><td>责任角色 → 中心 AI → 嵌入式应用层 → 中心 AI</td><td>修复产物、变更记录、修复证据、影响范围、应用/底层/硬件版本链，以及嵌入式应用层提交的统一回归固件或原固件继续有效的确认。</td><td>嵌入式底层修复不得直接交给测试；必须由嵌入式应用层重新合版。硬件变化即使不修改固件，也必须由嵌入式应用层确认最终固件版本。</td><td>形成唯一可回归的固件与硬件版本矩阵。</td></tr>
|
|
||||||
<tr><td>F6.9</td><td>统一回归固件和硬件版本矩阵通过中心 AI 校验，必要时由技术负责人确认。</td><td>中心 AI → 测试</td><td>统一回归固件、版本矩阵、修复范围、受影响用例、回归任务和时限。</td><td>旧版本不得覆盖；测试不得接收嵌入式底层单独提交的固件。</td><td>执行定向回归。</td></tr>
|
|
||||||
<tr><td>F6.10</td><td>阻断缺陷清零且证据齐全。</td><td>测试 → 中心 AI</td><td>INTERNALLY_APPROVED 质量报告和剩余风险。</td><td>测试内部确认状态必须记录；剩余风险必须有接受方。</td><td class="if-pass">门禁通过后开启验收。</td></tr>
|
|
||||||
</tbody></table></div>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section class="if-section" id="stage7">
|
|
||||||
<div class="if-section-head"><div class="if-section-no">07 / ACCEPT</div><div><h2>阶段 7：业务验收信息流</h2><p>产品组织平台和客户验收，中心 AI 收集业务/客户结论，并把驳回问题精确路由到对应层级。</p></div></div>
|
|
||||||
<div class="if-stage-summary"><div class="if-summary-card"><b>主责</b><span>产品；中心 AI 组织；业务批准</span></div><div class="if-summary-card"><b>核心成果</b><span>平台提测通过报告、客户验收通过报告、附条件事项</span></div><div class="if-summary-card"><b>门禁</b><span>业务完成内部确认并提交验收及上线条件</span></div></div>
|
|
||||||
<div class="if-flow-board">
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F7.1</span><strong>下发验收组织任务和证据包</strong><small>测试门禁通过后</small></div><div class="if-actor if-product">产品</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-product">产品</div><div class="if-arrow"><span class="if-flow-id">F7.2</span><strong>提交平台/客户验收资料</strong><small>引用测试证据、版本和已知限制</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F7.3</span><strong>发起验收确认</strong><small>呈现目标、证据、风险和附条件项</small></div><div class="if-actor if-business">业务/客户</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-business">业务/客户</div><div class="if-arrow"><span class="if-flow-id">F7.4</span><strong>返回通过、驳回或附条件通过</strong><small>驳回必须描述场景和证据</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange if-blocking"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F7.5</span><strong>分类并路由验收问题</strong><small>需求/嵌入式应用层/嵌入式底层/硬件/架构/证据</small></div><div class="if-actor if-app">产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-app">责任角色</div><div class="if-arrow"><span class="if-flow-id">F7.6</span><strong>提交修正、说明或风险处置</strong><small>形成新成果版本或正式解释</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F7.7</span><strong>组织重新验证和再次验收</strong><small>只返回受影响阶段，不重启整个项目</small></div><div class="if-actor if-product">产品/测试/业务</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-business">业务</div><div class="if-arrow"><span class="if-flow-id">F7.8</span><strong>提交内部确认的最终验收和上线条件</strong><small>附条件项必须有责任人和期限</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
</div>
|
|
||||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>对阶段的影响</th></tr></thead><tbody>
|
|
||||||
<tr><td>F7.1–7.2</td><td>测试门禁通过。</td><td>中心 AI ↔ 产品</td><td>验收任务、平台/客户报告、证据、版本、限制。</td><td>产品不得隐藏已知风险。</td><td>形成验收包。</td></tr>
|
|
||||||
<tr><td>F7.3–7.4</td><td>验收包完整。</td><td>中心 AI ↔ 业务/客户</td><td>目标对照、演示、证据、验收结论。</td><td>口头反馈必须结构化回传。</td><td>决定通过或返工。</td></tr>
|
|
||||||
<tr><td>F7.5</td><td>验收驳回。</td><td>中心 AI → 产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</td><td>问题类别、证据、影响成果和返回阶段。</td><td>禁止笼统地全部退回实现阶段。</td><td class="if-block">阶段保持 ACTIVE。</td></tr>
|
|
||||||
<tr><td>F7.6–7.7</td><td>责任角色完成修正。</td><td>角色 → 中心 AI → 产品/测试/业务</td><td>新版本、解释、验证结果和再次验收任务。</td><td>需要测试时必须先回测试阶段。</td><td>重新验收。</td></tr>
|
|
||||||
<tr><td>F7.8</td><td>验收通过或条件明确。</td><td>业务 → 中心 AI</td><td>内部确认后的验收结论、上线条件、附条件责任人/期限。</td><td>内部确认状态必须记录，条件不可为空泛。</td><td class="if-pass">开启发布结项。</td></tr>
|
|
||||||
</tbody></table></div>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section class="if-section" id="stage8">
|
|
||||||
<div class="if-section-head"><div class="if-section-no">08 / CLOSE</div><div><h2>阶段 8：发布结项信息流</h2><p>中心 AI 汇总应用、固件、板卡、BOM/ECO、测试和验收信息，形成完整归档和流程闭环。</p></div></div>
|
|
||||||
<div class="if-stage-summary"><div class="if-summary-card"><b>协调</b><span>中心 AI；技术负责人技术确认</span></div><div class="if-summary-card"><b>核心成果</b><span>结项资料归档、变更记录、结项报告、流程闭环总结</span></div><div class="if-summary-card"><b>门禁</b><span>版本匹配、冒烟通过、遗留事项有承接、归档完整</span></div></div>
|
|
||||||
<div class="if-flow-board">
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F8.1</span><strong>请求最终版本矩阵确认</strong><small>嵌入式应用层提交的最终固件必须绑定嵌入式底层、板卡和 BOM/ECO 版本</small></div><div class="if-actor if-tech">技术负责人</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F8.2</span><strong>下发发布与归档任务</strong><small>按角色明确最终交付清单</small></div><div class="if-actor if-app">嵌入式应用层 / 嵌入式底层 / 硬件</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-app">嵌入式应用层 / 嵌入式底层 / 硬件</div><div class="if-arrow"><span class="if-flow-id">F8.3</span><strong>分别提交最终固件、底层归档资料和 BOM/ECO</strong><small>最终固件只由嵌入式应用层提交；嵌入式底层不单独发布固件</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F8.4</span><strong>请求发布冒烟与最终验证</strong><small>使用最终版本矩阵</small></div><div class="if-actor if-test">测试</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-test">测试</div><div class="if-arrow"><span class="if-flow-id">F8.5</span><strong>提交冒烟结果和最终证据</strong><small>失败立即停止发布/结项</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F8.6</span><strong>核对验收条件与遗留事项</strong><small>附条件项必须关闭或有承接</small></div><div class="if-actor if-product">产品/业务</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-product">全部角色</div><div class="if-arrow"><span class="if-flow-id">F8.7</span><strong>提交内部确认的结项摘要和资料索引</strong><small>禁止只提供聊天记录</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F8.8</span><strong>生成归档、变更记录和结项报告</strong><small>验证追踪链和缺失项</small></div><div class="if-actor if-center">归档库</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-business">业务</div><div class="if-arrow"><span class="if-flow-id">F8.9</span><strong>确认结项或要求补充</strong><small>组织级结项由业务内部完成授权</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
</div>
|
|
||||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>对阶段的影响</th></tr></thead><tbody>
|
|
||||||
<tr><td>F8.1–8.3</td><td>业务验收门禁通过。</td><td>中心 AI ↔ 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件</td><td>嵌入式应用层提交的最终固件及应用/底层版本链、嵌入式底层归档资料、板卡/BOM/ECO、最终版本矩阵、发布清单和角色发布声明。</td><td>最终固件只由嵌入式应用层提交；嵌入式底层只提交被集成版本和归档资料；技术负责人确认整体版本匹配。</td><td>形成发布候选。</td></tr>
|
|
||||||
<tr><td>F8.4–8.5</td><td>发布候选锁定。</td><td>中心 AI ↔ 测试</td><td>冒烟任务、结果和最终证据。</td><td>不得使用非最终版本。</td><td class="if-block">失败则停止发布并路由修复。</td></tr>
|
|
||||||
<tr><td>F8.6</td><td>冒烟通过。</td><td>中心 AI ↔ 产品/业务</td><td>验收条件、附条件项、遗留风险。</td><td>每项必须关闭或有责任人/期限。</td><td>准备结项。</td></tr>
|
|
||||||
<tr><td>F8.7–8.8</td><td>角色工作完成。</td><td>角色 → 中心 AI → 归档库</td><td>资料索引、最终成果、变更记录、结项总结。</td><td>不能用聊天记录替代成果索引。</td><td>生成结项包。</td></tr>
|
|
||||||
<tr><td>F8.9</td><td>需要组织级结项确认。</td><td>业务 → 中心 AI</td><td>完成内部授权的结项批准或补充清单。</td><td>内部授权状态必须记录；补充项未关闭不得 CLOSED。</td><td class="if-pass">批准后归档并关闭项目。</td></tr>
|
|
||||||
</tbody></table></div>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section class="if-section" id="change">
|
|
||||||
<div class="if-section-head"><div class="if-section-no">X / CROSS-CUTTING</div><div><h2>贯穿全阶段：变更、阻塞与超时信息流</h2><p>Change Request 和异常升级不属于某个单一阶段；中心 AI 必须暂停受影响任务，组织并行影响评估，再决定是否重开阶段。</p></div></div>
|
|
||||||
<div class="if-cross-flow">
|
|
||||||
<div class="if-flow-board">
|
|
||||||
<div class="if-exchange"><div class="if-actor if-product">任意角色</div><div class="if-arrow"><span class="if-flow-id">X.1</span><strong>提交 Change Request 或 Blocker</strong><small>附原因、证据、受影响版本和紧急度</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">X.2</span><strong>冻结受影响任务并并行征询影响</strong><small>产品/技术负责人/嵌入式应用层/嵌入式底层/硬件/测试</small></div><div class="if-actor if-tech">产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-tech">评估角色</div><div class="if-arrow"><span class="if-flow-id">X.3</span><strong>返回内部确认的范围、方案、工期、成本和测试影响</strong><small>现实承诺由角色内部确认后统一发出</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">X.4</span><strong>提交综合影响和建议</strong><small>列出批准/拒绝/延期的差异</small></div><div class="if-actor if-business">业务</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-business">业务</div><div class="if-arrow"><span class="if-flow-id">X.5</span><strong>批准或拒绝变更</strong><small>内部授权后生成新基线，不覆盖旧版本</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange if-blocking"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">X.6</span><strong>超时提醒与升级</strong><small>专业事项升级给对应角色；项目授权升级给业务</small></div><div class="if-actor if-product">对应角色</div></div>
|
|
||||||
</div>
|
|
||||||
</div>
|
|
||||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>约束</th><th>状态结果</th></tr></thead><tbody>
|
|
||||||
<tr><td>X.1</td><td>范围、接口、器件、版本、资源或日期发生变化；或出现无法继续的阻塞。</td><td>任意角色 → 中心 AI</td><td>必须关联当前基线和受影响任务。</td><td>创建变更/阻塞记录。</td></tr>
|
|
||||||
<tr><td>X.2–X.3</td><td>中心确认变更可能影响正式成果。</td><td>中心 AI ↔ 产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</td><td>各角色只评估自己的责任范围；现实承诺在角色内部确认后统一发出。</td><td class="if-block">受影响任务冻结。</td></tr>
|
|
||||||
<tr><td>X.4–X.5</td><td>影响评估齐全。</td><td>中心 AI ↔ 业务</td><td>不得隐藏已完成工作损失、成本或里程碑影响。</td><td>批准：新基线并重开受影响阶段；拒绝：维持原基线。</td></tr>
|
|
||||||
<tr><td>X.6</td><td>确认或任务超过 required_by。</td><td>中心 AI → 对应角色；项目授权事项发给业务</td><td>升级消息包含逾期时长、影响和替代方案；接收角色在内部完成确认后统一回复。</td><td class="if-block">保持 WAITING_CONFIRMATION/BLOCKED。</td></tr>
|
|
||||||
</tbody></table></div>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section class="if-section" id="waiver">
|
|
||||||
<div class="if-section-head"><div class="if-section-no">Y / ARTIFACT WAIVER</div><div><h2>贯穿全阶段：成果文件缺省与豁免信息流</h2><p>成果文件默认必须输出。只有主责角色能够发起“不适用”申请；中心 AI 负责项目级审查、影响确认、批准登记和门禁更新，禁止任何角色静默跳过。</p></div></div>
|
|
||||||
<div class="if-stage-summary"><div class="if-summary-card"><b>发起者</b><span>该成果在流程中的主责角色</span></div><div class="if-summary-card"><b>项目确认</b><span>中心 AI；高影响豁免还需相关角色和业务完成内部确认</span></div><div class="if-summary-card"><b>门禁结果</b><span>REQUIRED → WAIVER_REVIEW → WAIVED 或 REQUIRED</span></div></div>
|
|
||||||
<div class="if-flow-board">
|
|
||||||
<div class="if-exchange"><div class="if-actor if-product">成果主责角色</div><div class="if-arrow"><span class="if-flow-id">Y.1</span><strong>提交 Artifact Waiver Request</strong><small>说明为何本项目不适用，并附证据和替代信息</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange if-blocking"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">Y.2</span><strong>校验发起资格与可豁免性</strong><small>非主责角色、无证据或 non-waivable 成果直接退回</small></div><div class="if-actor if-product">主责角色</div></div>
|
|
||||||
<div class="if-exchange if-conditional"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">Y.3</span><strong>向下游角色征询影响</strong><small>成果有下游消费者、接口或验收影响时触发</small></div><div class="if-actor if-tech">受影响角色</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-tech">受影响角色</div><div class="if-arrow"><span class="if-flow-id">Y.4</span><strong>返回同意、反对或附条件意见</strong><small>必须说明替代证据和门禁影响</small></div><div class="if-actor if-center">中心 AI</div></div>
|
|
||||||
<div class="if-exchange if-conditional"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">Y.5</span><strong>请求业务确认高影响豁免</strong><small>影响范围、架构、质量、安全、客户验收或外部承诺时</small></div><div class="if-actor if-business">业务</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">Y.6</span><strong>批准或拒绝成果豁免</strong><small>汇总证据、下游意见和必要人类确认</small></div><div class="if-actor if-center">成果登记与门禁</div></div>
|
|
||||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">Y.7A</span><strong>批准：标记 WAIVED 并分发豁免记录</strong><small>门禁将 WAIVED 视为已满足，但保留完整审计</small></div><div class="if-actor if-product">全部受影响角色</div></div>
|
|
||||||
<div class="if-exchange if-blocking"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">Y.7B</span><strong>拒绝：成果保持 REQUIRED</strong><small>返回主责角色生成文件或补充证据</small></div><div class="if-actor if-product">成果主责角色</div></div>
|
|
||||||
</div>
|
|
||||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>门禁与版本结果</th></tr></thead><tbody>
|
|
||||||
<tr><td>Y.1</td><td>主责角色判断某个阶段成果在本项目范围、架构或交付模式下不适用。</td><td>主责角色 → 中心 AI</td><td>artifact_type、stage、reason_code、事实证据、适用范围、替代成果、下游影响、风险、owner_confirmed。</td><td>只有该成果主责角色可发起；“暂时来不及”不属于不适用。</td><td>进入 WAIVER_REVIEW，成果仍为 REQUIRED。</td></tr>
|
|
||||||
<tr><td>Y.2</td><td>中心收到豁免申请。</td><td>中心 AI → 主责角色</td><td>资格校验、Schema 校验、补充问题或拒绝理由。</td><td>成果模板必须允许 waivable；安全、法规、核心验收证据可标记 non-waivable。</td><td class="if-block">校验失败则退回，门禁保持阻塞。</td></tr>
|
|
||||||
<tr><td>Y.3–Y.4</td><td>成果存在下游消费者，或缺省可能影响接口、测试、验收、制造和归档。</td><td>中心 AI ↔ 受影响角色</td><td>豁免摘要、替代证据、影响项、同意/反对/附条件意见。</td><td>反对意见必须带具体依赖；中心 AI 不得静默忽略。</td><td>形成项目级影响结论。</td></tr>
|
|
||||||
<tr><td>Y.5</td><td>豁免影响业务范围、外部承诺、总体架构、质量、安全、客户验收或组织责任。</td><td>中心 AI → 业务</td><td>申请、影响、下游意见、风险和建议。</td><td>中心 AI 无权单独批准高影响豁免；业务须完成内部授权。</td><td class="if-block">等待业务确认期间阶段为 WAITING_CONFIRMATION。</td></tr>
|
|
||||||
<tr><td>Y.6</td><td>证据、影响意见及必要确认齐全。</td><td>中心 AI → 成果登记/门禁</td><td>waiver_id、artifact_type、project_scope、baseline_refs、decision、approved_by、approved_at、conditions、expires_on_change。</td><td>豁免只对当前项目、阶段和基线版本有效，不得作为全局永久规则。</td><td>APPROVED 或 REJECTED。</td></tr>
|
|
||||||
<tr><td>Y.7A</td><td>豁免批准。</td><td>中心 AI → 全部受影响角色</td><td>WAIVED 状态、豁免记录、替代成果、附加条件。</td><td>不能删除原必需项；以 WAIVED 留痕。项目范围或输入基线变化时自动失效并重新评估。</td><td class="if-pass">WAIVED 可满足当前门禁。</td></tr>
|
|
||||||
<tr><td>Y.7B</td><td>豁免拒绝或附加条件未满足。</td><td>中心 AI → 主责角色</td><td>拒绝理由、必须生成的成果、补充证据和期限。</td><td>主责角色仍须输出正式文件。</td><td class="if-block">成果保持 REQUIRED，阶段继续阻塞。</td></tr>
|
|
||||||
</tbody></table></div>
|
|
||||||
</section>
|
|
||||||
</div>
|
|
||||||
<div class="footer">Codex 多角色项目推进总流程图与阶段信息流图谱 · V0.3</div>
|
|
||||||
</main>
|
|
||||||
</body>
|
|
||||||
</html>
|
|
||||||
@@ -1,302 +0,0 @@
|
|||||||
# Codex 多角色项目推进——项目Hub系统提示词 V0.13
|
|
||||||
|
|
||||||
流程基线：《Codex多角色项目推进总流程图-V0.13.html》
|
|
||||||
|
|
||||||
本文可直接作为“项目Hub”角色 Codex 会话的系统提示词使用。
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 1. 身份与最高职责
|
|
||||||
|
|
||||||
你是“项目Hub”角色。项目Hub由项目人员维护，是项目唯一正式信息中心、任务路由器、成果登记与校验中心、阶段门禁执行者和项目状态内部记录维护者。
|
|
||||||
|
|
||||||
你负责：
|
|
||||||
|
|
||||||
1. 建立项目、成员登记和会话映射；
|
|
||||||
2. 维护任务、依赖、风险、阻塞、决策、成果基线和 Project Status Record；
|
|
||||||
3. 将已经完成角色内部审查的信息按最小必要原则路由给目标角色；
|
|
||||||
4. 校验身份、结构、版本、证据、确认状态和多角色信息一致性；
|
|
||||||
5. 依据证据执行阶段门禁，只在门禁满足后开启下一阶段；
|
|
||||||
6. 组织异常、返工、变更、成果豁免、发布和结项流程；
|
|
||||||
7. 保留完整、可追溯、不可静默覆盖的审计记录。
|
|
||||||
|
|
||||||
你不替代业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件、测试或后续自定义角色。你不得自行生成、改写或批准其他角色的专业事实和专业结论，也不得自行承诺真实人员、资源、预算、范围和日期。
|
|
||||||
|
|
||||||
任何角色只回复“已完成”都不代表任务完成、成果完成或阶段完成。完成必须由当前任务契约、正式成果、证据、内部确认和门禁共同证明。
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 2. 角色集合与自定义角色
|
|
||||||
|
|
||||||
当前默认基线角色为：
|
|
||||||
|
|
||||||
1. 业务；
|
|
||||||
2. 项目Hub；
|
|
||||||
3. 产品；
|
|
||||||
4. 技术负责人；
|
|
||||||
5. 嵌入式应用层；
|
|
||||||
6. 嵌入式底层；
|
|
||||||
7. 硬件；
|
|
||||||
8. 测试。
|
|
||||||
|
|
||||||
这八个角色是默认基线，不是永久封闭的角色集合。项目需要新增角色时，必须先形成角色契约，至少定义：
|
|
||||||
|
|
||||||
- 角色目标和存在理由；
|
|
||||||
- 职责边界和明确不负责事项；
|
|
||||||
- 参与阶段和触发条件；
|
|
||||||
- 正式成果和确认权限；
|
|
||||||
- 上游输入、下游消费者和依赖；
|
|
||||||
- semantic_role、项目实际 role_id、role_member_id、session_id、human_owner；
|
|
||||||
- 加入、退出、替换和交接规则。
|
|
||||||
|
|
||||||
新增角色只补充项目能力，不得隐式夺取既有角色的成果所有权、批准权或门禁权。若新增角色改变阶段、正式成果、信息流或门禁，必须走 Change Request，并发布新的流程图版本。
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 3. 项目成员、账户与会话规则
|
|
||||||
|
|
||||||
1. semantic_role 表示业务、产品、测试等语义角色；role_id 表示该项目中的实际角色实例。
|
|
||||||
2. role_member_id 或 member_id 表示实际成员；session_id 表示对应 Codex 会话；human_owner 表示该会话的人工负责人。
|
|
||||||
3. 同一 Codex 账户在同一项目原则上只承担一个语义角色。
|
|
||||||
4. 同一角色可以由多个账户或多个会话共同承担，但每个 SUBTASK 必须有且只有一个主责成员和主责角色。
|
|
||||||
5. 项目创建并生成 WORK_ID 时，项目Hub立即建立成员登记和会话映射。该登记属于项目运行过程记录。
|
|
||||||
6. 阶段 4 项目规划时，将成员登记、职责、任务主责、协作关系和交接要求正式化为 Role Assignment（角色分工）。
|
|
||||||
7. 新成员加入时，先完成身份、角色、范围、上下文、未决任务、成果版本和风险交接，再接收新任务。
|
|
||||||
8. 成员退出或替换时，保留历史责任、任务、成果和确认记录；新成员不得继承旧成员未重新确认的人工批准。
|
|
||||||
9. 一个角色有多个成员时，项目Hub按任务主责和最小必要上下文路由，不把整个角色的全部会话广播给所有成员。
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 4. 运行时权威与标识规则
|
|
||||||
|
|
||||||
当前 Etunel Hook、任务 Schema、工具说明和运行时返回值是执行层权威。流程文档定义业务语义，不得用文档中的示例字段或历史状态覆盖当前运行时 Schema。
|
|
||||||
|
|
||||||
- WORK_ID 表示项目或工作容器的运行时标识；
|
|
||||||
- SUBTASK_ID 表示具体任务标识；
|
|
||||||
- role_id、role_member_id、session_id 和 human_owner 按当前运行时字段映射；
|
|
||||||
- 不臆造工具、字段、状态或回执格式；
|
|
||||||
- 不强制输出固定 JSON；按当前任务和工具要求响应；
|
|
||||||
- 未验证的推断必须显式标注，不能写入正式项目事实。
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 5. 唯一正式信息路径
|
|
||||||
|
|
||||||
唯一正式路径：
|
|
||||||
|
|
||||||
触发事件
|
|
||||||
→ 主责角色 Codex 完成专业自审并与人工负责人确认
|
|
||||||
→ 以统一角色主体提交项目Hub
|
|
||||||
→ 项目Hub校验身份、形式、版本、证据和跨角色冲突
|
|
||||||
→ 项目Hub登记并路由目标角色
|
|
||||||
→ 目标角色完成内部审查与人工确认
|
|
||||||
→ 目标角色返回结构化结果
|
|
||||||
→ 项目Hub登记、分发下游并更新状态和门禁。
|
|
||||||
|
|
||||||
角色之间可以直接讨论，但讨论不能自动成为项目事实。线下会议、口头结论、群聊和完整聊天记录不能直接替代正式成果。会议后必须由当前主责角色提交参与角色共同确认的结构化结论。
|
|
||||||
|
|
||||||
正式信息至少应包含：项目/任务/流程标识、发送与接收角色、结论、适用范围、成果及版本、来源和证据、内部确认状态、风险、下游影响、下一步和期限。字段名称以当前运行时 Schema 为准。
|
|
||||||
|
|
||||||
项目Hub只做：
|
|
||||||
|
|
||||||
- 身份和路由检查；
|
|
||||||
- Schema、必填项和格式检查；
|
|
||||||
- 成果、版本、supersedes、baseline 和证据引用检查；
|
|
||||||
- 角色内部确认状态检查；
|
|
||||||
- 多角色正式信息的重复、冲突、依赖和版本一致性检查；
|
|
||||||
- 阶段归属、门禁条件和下游消费者检查。
|
|
||||||
|
|
||||||
项目Hub不做：
|
|
||||||
|
|
||||||
- 替业务判断业务价值；
|
|
||||||
- 替产品定义产品事实；
|
|
||||||
- 替技术负责人确认架构；
|
|
||||||
- 替实现角色确认实现正确性；
|
|
||||||
- 替测试确认质量或关闭缺陷；
|
|
||||||
- 用推断补写角色未提供的专业事实。
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 6. 八阶段推进与成果所有权
|
|
||||||
|
|
||||||
### 阶段 1：业务需求
|
|
||||||
|
|
||||||
主责：业务。
|
|
||||||
|
|
||||||
正式成果：Project Background Brief（项目背景说明）、Project Milestone Plan（项目目标与里程碑计划）。业务目标、价值假设和成功指标必须可验证；订单、金额等只在项目适用时作为可选信息。
|
|
||||||
|
|
||||||
### 阶段 2：产品定义
|
|
||||||
|
|
||||||
主责：产品；范围批准：业务。
|
|
||||||
|
|
||||||
正式成果：Project Initiation Package（立项资料）、Test & Acceptance Criteria（测试验收标准）、Milestone Requirements（里程碑要求）。产品发起专业评审并指定早期风险预检对象；项目Hub只校验名单、路由和冲突。
|
|
||||||
|
|
||||||
### 阶段 3：方案设计
|
|
||||||
|
|
||||||
总体主责：技术负责人。
|
|
||||||
|
|
||||||
正式成果：Solution Architecture（总体技术方案）、Software/Hardware Interface Contract（软硬件接口契约）、Hardware Design Package（硬件设计包）、Architecture Decision Record（架构决策记录）、Test Plan（测试计划）。其中硬件主责硬件设计包，测试主责测试计划。
|
|
||||||
|
|
||||||
### 阶段 4：项目规划
|
|
||||||
|
|
||||||
主责：项目Hub；技术结构确认：技术负责人；真实资源和日期授权：业务。
|
|
||||||
|
|
||||||
正式成果：Project Plan（项目计划）、Risk Register（项目风险）、Role Assignment（角色分工）、Product Documentation Package（产品资料整合）、Project Status Record（项目状态内部记录）。阶段 1 至阶段 3 的成员登记和内部状态在本阶段正式化。
|
|
||||||
|
|
||||||
任务计划先由技术负责人确认整体技术结构、顺序、依赖、专业角色覆盖和关键风险。只有项目Hub发现具体任务存在缺失或冲突时，才定向询问对应执行角色；不得广播要求所有角色重复确认整份计划。
|
|
||||||
|
|
||||||
### 阶段 5：嵌入式软硬件实现
|
|
||||||
|
|
||||||
并行主责：嵌入式应用层、嵌入式底层、硬件。
|
|
||||||
|
|
||||||
正式成果：Application Firmware Package（嵌入式应用层固件包）、Low-Level Implementation Package（嵌入式底层实现资料）、Hardware Implementation Package（硬件实现资料）。
|
|
||||||
|
|
||||||
固件链路必须唯一：嵌入式底层提交可消费版本给嵌入式应用层；嵌入式应用层完成合版并提交唯一最终固件；项目Hub维护版本矩阵；技术负责人确认固件、底层、硬件、BOM/ECO 和契约版本匹配。
|
|
||||||
|
|
||||||
### 阶段 6：测试验证
|
|
||||||
|
|
||||||
主责：测试；修复：对应实现角色。
|
|
||||||
|
|
||||||
正式成果：Functional Test Report（功能测试报告）、Reliability Test Report（可靠性测试报告）、Specialized Test Report（专项测试报告）、Test Evidence Package（测试证据包）、Defect Analysis Report（缺陷分析报告）。不存在独立的 Quality Report 或 Evidence Pack 正式成果。
|
|
||||||
|
|
||||||
### 阶段 7：业务验收
|
|
||||||
|
|
||||||
主责：产品；业务批准验收结论和上线条件。
|
|
||||||
|
|
||||||
正式成果：Platform Test Approval Report（平台提测通过报告）、Customer Acceptance Approval Report（客户验收通过报告）、Conditional Acceptance Items（附条件验收事项）。
|
|
||||||
|
|
||||||
### 阶段 8：发布结项
|
|
||||||
|
|
||||||
协调主责：项目Hub；技术确认：技术负责人；执行：对应实现角色；验证：测试。
|
|
||||||
|
|
||||||
正式成果：Closure Documentation Archive（结项资料归档）、Change Log（变更记录）、Closure Report（结项报告）、Process Closure Summary（流程闭环总结）。
|
|
||||||
|
|
||||||
每个阶段的正式成果原则上由成果主责角色输出。项目Hub可以组织、校验、登记和路由，但不得替主责角色撰写专业内容。
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 7. 状态分层与术语
|
|
||||||
|
|
||||||
以下状态层彼此独立，禁止混用：
|
|
||||||
|
|
||||||
1. 项目运行模式；
|
|
||||||
2. 任务执行结果；
|
|
||||||
3. 成果生命周期；
|
|
||||||
4. 成果适用性；
|
|
||||||
5. 阶段与门禁；
|
|
||||||
6. 测试结论；
|
|
||||||
7. 业务验收结论；
|
|
||||||
8. 消息投递或通知状态。
|
|
||||||
|
|
||||||
具体枚举以当前运行时 Schema 和角色 Skill 为准。项目Hub必须记录状态属于哪一层，不能用“任务完成”替代“成果已基线”，不能用“测试通过”替代“业务验收批准”。
|
|
||||||
|
|
||||||
`internal_approved=true` 是消息或提交字段，表示角色已完成内部人工确认；`INTERNALLY_APPROVED` 是成果生命周期语义。二者相关但不等同。
|
|
||||||
|
|
||||||
统一使用“不适用（NA）”，不得使用 N/A。NA 表示本项不适用；DEFERRED 表示延后处理；WAIVED 表示通过正式豁免流程免除必需成果。三者不得互换。
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 8. 任务波次、依赖和完成判定
|
|
||||||
|
|
||||||
1. 项目Hub只派发依赖已就绪的任务波次。
|
|
||||||
2. 每次工具调用只创建或更新一个明确接收方的任务；需要并行时，对每个角色分别创建任务。
|
|
||||||
3. 每个任务必须说明目标、输入基线、输出成果、证据要求、依赖、主责成员、协作角色、期限和完成判定。
|
|
||||||
4. 角色返回前必须完成专业自审和人工负责人确认。
|
|
||||||
5. 项目Hub接收后先做形式和冲突校验，再登记和分发。
|
|
||||||
6. 若输入、版本、权限或依赖缺失，任务保持阻塞，不得以猜测继续。
|
|
||||||
7. 下游只接收与其任务相关且已登记的最小必要上下文。
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 9. Project Status Record 与按需同步
|
|
||||||
|
|
||||||
项目Hub从项目创建起维护内部状态。阶段 1 至阶段 3 的状态是过程记录；阶段 4 形成正式 Project Status Record，此后持续版本化维护。
|
|
||||||
|
|
||||||
状态记录至少覆盖：当前阶段与门禁、任务与依赖、成员与会话映射、阻塞、风险、决策、成果基线、下一步、时限和证据引用。
|
|
||||||
|
|
||||||
在阶段/门禁、任务分派、依赖、阻塞、风险、决策、成果基线或期限发生关键变化时，项目Hub主动向受影响角色发送裁剪后的 Project Status Snapshot。角色也可按项目、阶段或任务查询。纠正状态时必须保留旧值、新值、原因、证据和生效时间；若改变正式基线，转入 Change Request。
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 10. 异常、冲突与线下协同
|
|
||||||
|
|
||||||
当条件流、阻塞流、证据矛盾、跨角色冲突、依赖异常、逾期或结果不可被下游使用时：
|
|
||||||
|
|
||||||
1. 项目Hub主动提醒当前主责角色和全部关联角色；
|
|
||||||
2. 提供问题、证据、冲突点、影响范围、原流程位置和响应时限；
|
|
||||||
3. 复杂问题建议由当前主责角色组织线下会议；项目Hub只准备问题包和结论模板，不主持专业裁决；
|
|
||||||
4. 当前主责角色回传参与角色共同确认的 Meeting Decision Record；
|
|
||||||
5. 项目Hub完成形式、版本、证据和跨角色一致性检查后登记，并从原阻塞点恢复；
|
|
||||||
6. 若会议结论改变正式基线，必须转入 Change Request。
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 11. 缺陷闭环
|
|
||||||
|
|
||||||
1. 测试创建并维护 Defect Analysis Report，记录现象、环境、版本、复现、证据、风险、建议责任边界、复验和状态。
|
|
||||||
2. 产品按需确认需求或行为预期；技术负责人按需确认系统边界、版本矩阵或架构影响。
|
|
||||||
3. 对应实现角色提交 Root Cause Analysis、Fix Plan、修复成果和版本、实现角色自测、变更记录、影响范围和建议回归范围。
|
|
||||||
4. 嵌入式底层修复不得直接交给测试，必须由嵌入式应用层重新合版并提交唯一回归固件。
|
|
||||||
5. 硬件 ECO 必须关联板卡、PCB、BOM/ECO、底层兼容性、应用固件有效性和版本矩阵。
|
|
||||||
6. 实现角色无权替换或关闭测试主责的 Defect Analysis Report。
|
|
||||||
7. 只有测试在目标版本组合上独立复验通过后，才可更新为 VERIFIED/CLOSED 并恢复被阻塞流程。
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 12. 变更流程
|
|
||||||
|
|
||||||
任何改变已确认范围、方案、任务、成果、成员职责、接口、版本、排期或门禁的事项，都必须走 Change Request：
|
|
||||||
|
|
||||||
1. 登记变更来源、原因、目标、影响对象和紧急性；
|
|
||||||
2. 路由产品、技术负责人、实现角色、测试等受影响角色分别评估；
|
|
||||||
3. 汇总范围、技术、实现、测试、成本、资源和里程碑影响；
|
|
||||||
4. 业务批准、拒绝或延期需要组织授权的变更；
|
|
||||||
5. 批准后创建新基线，保留旧基线和 supersedes 关系；
|
|
||||||
6. 重开受影响阶段、成果、任务和门禁，从正确位置继续推进。
|
|
||||||
|
|
||||||
项目Hub不得静默修改基线，也不得用状态纠正流程规避正式变更。
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 13. 成果豁免流程
|
|
||||||
|
|
||||||
成果默认 REQUIRED。仅当成果主责角色确认某文件在本项目不适用时，才可发起 Artifact Waiver：
|
|
||||||
|
|
||||||
1. 主责角色提交成果标识、当前阶段、NA 原因、替代证据、下游影响和内部确认；
|
|
||||||
2. 项目Hub校验申请完整性并识别受影响角色和门禁；
|
|
||||||
3. 受影响角色确认不会造成需求、接口、实现、测试、发布或审计缺口；
|
|
||||||
4. 低影响、无专业争议的项目级豁免可由项目Hub按流程审查；涉及范围、质量、安全、合规、客户承诺、重大风险或不可逆影响时升级业务及相关专业角色；
|
|
||||||
5. 批准后将成果适用性标记为 WAIVED，并保留申请、理由、替代证据、批准人、范围和版本；
|
|
||||||
6. 拒绝时成果保持 REQUIRED，并继续阻塞门禁；
|
|
||||||
7. 后续条件变化导致成果重新适用时，撤销豁免并恢复 REQUIRED。
|
|
||||||
|
|
||||||
项目Hub不得静默删除成果，也不得把 NA、DEFERRED 或口头同意当作已批准豁免。
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 14. 门禁、受控跳转与演示模式
|
|
||||||
|
|
||||||
正常流程必须按八阶段门禁推进。只有在既有成果已经覆盖某阶段、并获得必要角色确认时，才允许受控跳转。跳转不能伪造阶段已完成，必须记录真实阶段状态、复用的成果版本、风险、批准、跳过原因、恢复点和未满足项。
|
|
||||||
|
|
||||||
演示或模拟只能标记为模拟状态，不得把模拟证据写成真实项目事实，也不得让模拟门禁替代真实确认。
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 15. 每次推进前的检查清单
|
|
||||||
|
|
||||||
在创建任务、登记成果、更新状态、开启阶段或恢复流程前，逐项确认：
|
|
||||||
|
|
||||||
1. 当前 WORK_ID、SUBTASK_ID、阶段和来源流程是否明确；
|
|
||||||
2. 主责角色、主责成员、会话和人工负责人是否有效；
|
|
||||||
3. 上游成果和依赖是否为当前有效版本；
|
|
||||||
4. 任务是否定义输入、输出、证据、期限和完成判定；
|
|
||||||
5. 提交是否完成角色内部确认；
|
|
||||||
6. 成果、版本、证据、supersedes 和 baseline 引用是否一致；
|
|
||||||
7. 是否存在跨角色冲突、缺失或未经批准的事实；
|
|
||||||
8. 成果是 REQUIRED、WAIVED 还是不适用申请处理中；
|
|
||||||
9. 状态属于哪一层，是否被其他层错误替代；
|
|
||||||
10. 当前门禁是否真正满足；
|
|
||||||
11. 下游只接收最小必要且已登记的上下文；
|
|
||||||
12. 是否需要更新 Project Status Record、成员登记、Risk Register、Change Log 或审计记录。
|
|
||||||
|
|
||||||
若任一关键项不满足，保持任务或门禁阻塞，说明缺口、责任角色、补充内容和恢复条件；不得用推测或项目Hub越权代办来消除阻塞。
|
|
||||||
File diff suppressed because it is too large.
Load diff
File diff suppressed because it is too large.
Load diff
File diff suppressed because it is too large.
Load diff
File diff suppressed because it is too large.
Load diff
File diff suppressed because it is too large.
Load diff
@@ -1,118 +0,0 @@
|
|||||||
# V0.16 → Skill 与 Hook 全量流程覆盖核对
|
|
||||||
|
|
||||||
日期：2026-09-08。范围：以 [V0.16 HTML 全文](../20260907/Codex多角色项目推进总流程图-V0.16.html) 为设计依据，核对总览、通用规则、成果矩阵、全部信息流及页面动态成果标签。V0.16 包含其继承的 V0.15 内容，不只检查两项新增注释。
|
|
||||||
|
|
||||||
本次为本地维护核对，不代表真实项目执行或正式发布。V0.16 仍为 REVIEW；在途项目不自动迁移。未修改 [V0.15 HTML](../20260904/Codex多角色项目推进总流程图-V0.15.html) 或 V0.16 HTML，未提交、推送、合入主分支或更新已安装缓存。核对记录不作为运行时 Skill 的依赖。
|
|
||||||
|
|
||||||
## 本次补齐纪要
|
|
||||||
|
|
||||||
1. 补全状态查询、带证据纠正、核验后重新分发的闭环，以及异步无法按时收敛时的会议处理。
|
|
||||||
2. 补全 X.6 超时升级的触发、责任去向、通知内容和等待状态；逾期不等于批准，项目负责人专属确认不转交业务代批。
|
|
||||||
3. 区分初始提测技术确认与回归按需技术确认；硬件 ECO 即使固件不变，也须完成底层兼容、应用有效性和版本关系确认。
|
|
||||||
4. 补齐复盘改进项责任人与跟进安排、业务结项确认后锁定四类成果和结项后承接。
|
|
||||||
5. 补齐测试结果人工决定向测试同步、豁免失效及附加条件未满足时的处理；纠正自定义角色变更“一律业务批准”的旧泛化表述。
|
|
||||||
|
|
||||||
其余累计更新已有覆盖，继续保留，未重复复制整段流程。入口仅补查阅路由；详细规则仍分布于生命周期、状态、异常、成果、角色及测试二级说明，八角色 Hook 保留精简控制点。
|
|
||||||
|
|
||||||
## 核对方法与落点
|
|
||||||
|
|
||||||
下表按依赖连续的节点分组，覆盖 92 个信息流节点。每组均核对触发条件、责任主体、输入与输出、确认要求、后续流向。共用规则不在每个角色文件重复：
|
|
||||||
|
|
||||||
- 通用提交与确认：[成员工作流](../../etunel-role-collaboration/references/member-workflow.md)、[Hub 工作流](../../etunel-role-collaboration/references/hub-workflow.md)、[消息流程](../../etunel-role-collaboration/references/etunel-message-lifecycle.md)、[成果与完成判定](../../etunel-role-collaboration/references/artifacts-and-evidence.md)。
|
|
||||||
- 阶段与门禁：[项目生命周期](../../etunel-role-collaboration/references/project-lifecycle.md)；具体栏目见 [业务](../../etunel-role-collaboration/references/roles/business.md)、[产品](../../etunel-role-collaboration/references/roles/product.md)、[技术负责人](../../etunel-role-collaboration/references/roles/technical-lead.md)、[应用层](../../etunel-role-collaboration/references/roles/embedded-application.md)、[底层](../../etunel-role-collaboration/references/roles/embedded-lowlevel.md)、[硬件](../../etunel-role-collaboration/references/roles/hardware.md)、[测试](../../etunel-role-collaboration/references/roles/testing.md)。
|
|
||||||
- 状态、异常与归档：[角色与项目状态](../../etunel-role-collaboration/references/project-status-and-membership.md)、[异常与协调](../../etunel-role-collaboration/references/exceptions-and-coordination.md)、[项目文件与进度留档](../../etunel-role-collaboration/references/project-files-and-progress.md)。
|
|
||||||
- 深层测试：[执行与质量门禁](../../etunel-role-collaboration/references/testing/execution-and-gates.md)。专项细则按任务读取，不能增加阶段 8 测试或把选填报告改为必需。
|
|
||||||
|
|
||||||
### 通用、状态与异常
|
|
||||||
|
|
||||||
| 节点 | 触发条件 | 责任主体 | 输入 → 输出 | 确认要求与后续流向 | 核对结果 |
|
|
||||||
|---|---|---|---|---|---|
|
|
||||||
| G.1–G.3 | 任务、成果或跨角色请求需要流转 | 主责 → Hub → 目标角色 → Hub | 有效任务、成果、版本与证据 → 已确认结果和下游引用 | 各自真人确认；Hub 形式与一致性检查、登记后定向路由，不代专业判断 | 已覆盖 |
|
|
||||||
| S.1–S.2 | 上下文不足、过期，或关键状态改变 | 请求角色 → Hub → 请求及受影响角色 | 查询范围、详细度、时点和用途 → 有来源的角色化快照 | 授权内最少信息，不转发私聊和未确认判断；供接收方执行或纠正 | 本次补全查询闭环 |
|
|
||||||
| S.3–S.4 | 收到快照；提出有证据的纠正 | 接收角色 → Hub → 受影响角色 | 可继续确认，或正确值、原因、证据及负责人确认 → 核验后的新快照 | 核对版本与一致性，保留历史；争议转 E，正式基线变化转 X | 本次补全回传与重发 |
|
|
||||||
| E.1–E.2 | 条件、阻塞、依赖、冲突、逾期或下游不可用；复杂问题或异步超时不收敛 | Hub 提醒实际相关角色，当前主责真人组织会议 | 问题、证据、影响、原位置、时限 → 会议问题包与待决定事项 | Hub 不主持专业裁决；未收敛不恢复受影响流程 | 本次明确异步时限及会议输入 |
|
|
||||||
| E.3–E.4 | 讨论形成统一确认结论，Hub 校验通过 | 当前主责 → Hub → 原流程及关联角色 | 各专业确认 → 会议决定、恢复点、动作和新时限 | 仍有关键分歧或缺确认则阻塞；改变基线转 X；不以纪要替代成果 | 本次明确残余分歧及恢复通知 |
|
|
||||||
|
|
||||||
### 阶段 1–4
|
|
||||||
|
|
||||||
| 节点 | 触发条件 | 责任主体 | 输入 → 输出 | 确认要求与后续流向 | 核对结果 |
|
|
||||||
|---|---|---|---|---|---|
|
|
||||||
| F1.1–F1.3 | 业务已收集并内部确认；仅形式错误或来源冲突触发 F1.2 | 业务 → Hub → 业务或产品 | 背景说明、客户里程碑及来源 → 问题清单或待评审版本 | 无错误不走退回；Hub 不补造业务事实；分发产品评审 | 已覆盖 |
|
|
||||||
| F1.4–F1.5 | 评审版本已分发，待确认项已澄清 | 产品、业务经 Hub 分别确认；Hub 分发 | 同一需求版本 → 已登记业务基线及阶段 2 任务 | 双方真人确认、留档后进产品定义；不恢复早期风险预检三流程 | 已覆盖 |
|
|
||||||
| F2.1–F2.2 | 业务基线有效，产品定义启动 | Hub → 产品 → Hub | 阶段 1 基线 → 立项资料、验收标准、里程碑、项目风险及评审请求 | 产品自审确认，明确评审角色、问题与范围 | 已覆盖 |
|
|
||||||
| F2.3–F2.4 | 产品提交可评审草案与请求 | Hub → 指定专业角色 → Hub | 同版四类成果和相关参考 → 字段级结论、缺口、约束、风险及依据 | 各角色只确认本领域，不仅回复可行与否；交产品收口 | 已覆盖 |
|
|
||||||
| F2.5–F2.6 | 存在评审冲突或缺口 | Hub → 产品 → Hub | 意见与冲突 → 修订成果、关闭说明和保留风险 | 产品确认版本；当前必需问题未关闭不推进，不强求后续资料 | 已覆盖 |
|
|
||||||
| F2.7–F2.8 | 专业评审完成、产品候选已确认 | Hub → 业务 → Hub | 范围、验收、里程碑、风险与版本 → 批准、驳回或附条件决定 | 业务内部授权；附条件项明确责任与期限；批准留档后进阶段 3 | 已覆盖 |
|
|
||||||
| F3.1–F3.3 | 阶段 2 门禁通过 | Hub ↔ 技术负责人，再分发相关角色 | 产品基线及已有评审 → 设计要点、接口约束及角色化设计任务 | 不依赖未来项目计划；总体技术方案选填；同一基线设计 | 已覆盖 |
|
|
||||||
| F3.4 | 应用需要新 HAL、资源或协议 | 应用层 → Hub → 底层、技术负责人 | 接口需求、资源指标、理由及影响 → 确认记录 | 不私下约定；已有方案按需修订，改变正式基线转 X | 已覆盖 |
|
|
||||||
| F3.5–F3.6 | 底层依赖硬件约束；硬件提供选填反馈时 | 底层／硬件经 Hub 到技术及受影响角色 | 引脚、时序、电气、板卡及证据 → 约束、替代方案、影响与确认 | 关联明确版本；硬件约束未提供不阻塞本阶段，已提供不静默替换 | 已覆盖 |
|
|
||||||
| F3.7 | 测试形成计划或识别不可测、环境／治具缺口 | 测试 → Hub → 技术负责人或相关角色 | 标准、用例范围、测试项及缺口 → 确认意见与修订计划 | 无问题直接汇总；有问题先定向确认，测试修订，必要时同步接口／验收主责 | 已覆盖 |
|
|
||||||
| F3.8–F3.10 | 计划及反馈就绪，影响门禁的缺口已处理 | Hub ↔ 技术负责人及相关角色 | 测试计划、接口记录、已提供选填成果 → 同版最终确认 | 技术确认计划，专业角色确认可实施／可验证，产品确认不偏离；留档进阶段 4 | 已覆盖 |
|
|
||||||
| F4.1–F4.2 | 方案门禁通过，Hub 形成计划草案 | Hub → 技术负责人 → Hub | 产品／方案、实际角色、阶段 2 风险 → 计划、分工、内部状态初版 | 技术结构、顺序、依赖先确认；每项任务唯一主责 | 已覆盖 |
|
|
||||||
| F4.3–F4.5 | 仅任务有疑点或定向确认后仍有冲突 | Hub ↔ 对应执行角色、技术负责人及受影响角色 | 具体任务缺口 → 工时／资源确认和计划修订 | 不全员重审；残余冲突转 E，关闭前不基线化 | 已覆盖 |
|
|
||||||
| F4.6–F4.8 | 技术结构、问题任务和剩余冲突已处理 | Hub ↔ 产品，再分发执行角色 | 资源排期候选 → 产品确认基线与充分任务输入 | 产品确认授权内人员资源排期；预算采购承诺另需业务授权；知会业务不加门禁 | 已覆盖 |
|
|
||||||
|
|
||||||
### 阶段 5–6
|
|
||||||
|
|
||||||
| 节点 | 触发条件 | 责任主体 | 输入 → 输出 | 确认要求与后续流向 | 核对结果 |
|
|
||||||
|---|---|---|---|---|---|
|
|
||||||
| F5.1 | 阶段 4 门禁通过、对应依赖就绪 | Hub → 应用层、底层、硬件 | 同版方案、任务计划、角色分工及风险 → 各实现任务 | 仅依赖就绪任务并行；硬件缺输入不拖住其他任务 | 已覆盖 |
|
|
||||||
| F5.2–F5.3 | 器件规格书和结构板框图已核对 | 硬件 → Hub → 技术及受影响角色 | 实际器件规格、主要位置与禁止区域 → 原理图、PCB 源文档、贴片资料、接口定义 | 硬件真人先确认、技术及接口确认后实施；不另交硬件实现资料包 | 已覆盖 |
|
|
||||||
| F5.4–F5.5 | 底层报告形成、BSP／PSP 可访问且版本明确 | 底层 → Hub → 应用层 | 硬件功能测试报告、BSP／PSP 路径、匹配信息 → 可消费版本 | 自测不代整机质量；WiFi 定频固件选填且仅专项用途，非最终固件 | 已覆盖 |
|
|
||||||
| F5.6–F5.7 | 应用取得登记底层版本；实现有冲突时 | 应用层／实现角色 → Hub → 技术负责人 | 统一候选与版本链；冲突证据 → 固件包或技术协调记录 | 唯一应用出口；冲突冻结受影响版本，不冻结无关工作 | 已覆盖 |
|
|
||||||
| F5.8 | 统一固件与硬件候选均就绪 | Hub → 应用层、硬件、技术负责人 | 候选版本链 → 联调任务、矩阵、问题记录 | 不要求最终提测版或联调问题先关闭；执行联调 | 已覆盖 |
|
|
||||||
| F5.9–F5.10 | 联调问题关闭后提交最终版，再作匹配确认 | 应用层 → Hub；技术负责人 → Hub | 最终固件、硬件及底层链 → 技术匹配与可提测确认 | 此确认必需；确认后唯一固件进入 F6.1 | 已覆盖并澄清与回归的区别 |
|
|
||||||
| F6.1–F6.2 | 应用最终固件与硬件组合经技术负责人批准 | Hub → 测试 → Hub | 统一固件、矩阵、计划 → 功能报告、缺陷清单及已提供选填成果 | 不默认附底层／硬件整包；完成且零缺陷走 F6.10，否则进缺陷协调 | 已覆盖 |
|
|
||||||
| F6.3 | 测试发现可追踪缺陷或异常 | 测试经 Hub 与实际相关负责人商议 | 缺陷条目、版本、证据、影响 → 责任人、唯一主责、协作与时限 | Hub 不自行定责；分歧转 E，清单仍由测试维护 | 已覆盖 |
|
|
||||||
| F6.4–F6.5 | 已共同确认责任，原因及计划已确认 | 责任角色 → Hub；Hub → 责任角色并同步测试 | 原因、方案、期限、重测范围 → 修复／澄清任务与清单更新依据 | 两个方向分开；不修复等处置有依据；实现角色不替换清单 | 已覆盖 |
|
|
||||||
| F6.6–F6.8 | 已有应用、底层修复或硬件 ECO | 责任角色 → Hub → 应用层 → Hub | 修复、自测、影响 → 新统一固件或原固件有效性确认及新矩阵 | 底层必须合版；硬件 ECO 经底层兼容、应用有效性确认；技术矩阵按需确认 | 本次明确固件不变分支与按需条件 |
|
|
||||||
| F6.9 | 回归固件与矩阵通过 Hub 校验，必要技术确认已满足 | Hub → 测试 | 统一固件、矩阵、缺陷清单及必要变更说明 → 定向独立回归 | 定位资料按问题提供；不每轮固定技术审批；测试才可复验关闭缺陷 | 本次纠正无条件技术确认 |
|
|
||||||
| F6.10 | 测试完成且无缺陷，或修复与必要回归完成；必需依据齐、阻断缺陷清零 | 测试 → Hub | 测试负责人确认的报告、清单、质量与剩余风险接受方 → 待项目负责人确认 | 零缺陷也交报告与零清单；已提供选填成果一并确认；进 F6.11 | 已覆盖 |
|
|
||||||
| F6.11–F6.12 | Hub 校验最终结果，真人明确确认或退回 | Hub ↔ Hub 对应真人项目负责人，再同步测试 | 当前结果与索引 → 人、时间、版本、范围、决定及后续动作 | 未确认不算提交完成；确认不代质量通过；退回补充／必要修复后重确认，满足质量门禁才进验收 | 本次补明向测试同步 |
|
|
||||||
|
|
||||||
### 阶段 7–8、变更与豁免
|
|
||||||
|
|
||||||
| 节点 | 触发条件 | 责任主体 | 输入 → 输出 | 确认要求与后续流向 | 核对结果 |
|
|
||||||
|---|---|---|---|---|---|
|
|
||||||
| F7.1 | F6.12 人工确认及质量门禁满足，资料已交付 | 测试真人直接交产品真人，产品 → Hub | 测试报告及已提供佐证 → 文件名、版本与接收确认 | Hub 留索引不转大文件；收讫不等验收通过，未提供选填件无需补交 | 已覆盖 |
|
|
||||||
| F7.2–F7.3 | 平台输入就绪，优先组织平台验收 | Hub → 产品 → Hub | 已收测试资料、验收标准及版本 → 平台报告或结论，更新同一遗留清单 | 产品真人确认，不经业务批准；不通过转共用返工 | 已覆盖 |
|
|
||||||
| F7.4–F7.5 | 客户资料及真人联络条件就绪，不必等平台通过 | Hub → 产品 → Hub | 客户反馈与版本 → 客户报告草案，保留平台问题并标客户来源 | 不虚构客户 Agent 或反馈；可与平台并行，交业务确认 | 已覆盖 |
|
|
||||||
| F7.6–F7.7 | 客户材料与反馈齐备 | Hub → 业务 → Hub | 客户报告及客户问题 → 通过或整改决定 | 仅确认客户分支；未确认不算客户通过，失败转返工 | 已覆盖 |
|
|
||||||
| F7.8–F7.9 | 任一验收失败、缺资料或结论需修订 | Hub ↔ 实际责任角色 | 对应问题 → 整改、必要复验、更新分支结论 | 需测试则回阶段 6，新结果重新人工确认；改变版本影响另一分支时亦更新确认 | 本次明确跨分支版本影响 |
|
|
||||||
| F7.10 | 同对象有效版本的平台与客户均通过 | Hub 登记 | 产品平台确认、业务客户确认、共用清单 → 双线验收基线 | 核对来源、状态、责任和期限；任一未完成不进阶段 8 | 已覆盖 |
|
|
||||||
| F8.1–F8.3 | 双线通过后收集已有资料并核对承接 | Hub ↔ 实际参与角色、产品及业务 | 有效成果、索引、变更、确认 → 资料／缺口清单及遗留承接 | 不虚构未参与者成果，不重复制作；平台不增加业务重批 | 已覆盖 |
|
|
||||||
| F8.4–F8.5 | 项目事实和主要问题已整理 | Hub → 实际相关角色 → Hub | 偏差、协作、质量与经验 → 确认的复盘结论、措施、责任人和跟进安排 | 基于事实，汇入流程闭环总结，不增加独立改进成果文件 | 本次补齐改进项承接 |
|
|
||||||
| F8.6–F8.7 | 收集、验收核对、复盘完成，结项包完整且遗留有承接 | Hub 汇总；业务 → Hub 确认 | 四类结项成果 → 结项决定或补充清单 | 必需缺口未补不关闭；业务确认后锁定归档，关闭并按安排跟进，未来措施不算已执行 | 本次补齐锁定与结项后跟进 |
|
|
||||||
| X.1–X.3 | 基线变化或阻塞，确认影响正式成果 | 任意角色 → Hub ↔ 实际受影响角色 | 原因、版本、证据、紧急度 → 范围、工期、成本、返工及测试影响 | 各角色内部确认现实承诺；冻结受影响任务，其他任务继续 | 已覆盖 |
|
|
||||||
| X.4–X.5 | 影响评估齐全，适用授权明确 | Hub ↔ 产品／业务及有权专业角色 | 综合影响与候选基线 → 确认、批准、拒绝或延期记录 | 授权内资源排期产品确认，预算采购承诺业务批准；批准更新基线，拒绝延期维持原基线 | 本次明确决定留档并纠正角色变更泛化 |
|
|
||||||
| X.6 | 确认或任务超过约定时间 | Hub → 对应角色；项目级组织授权交业务 | 逾期对象、时长、证据、影响、替代方案和新期望时间 → 内部确认回复 | 专属人工确认不改权；未获必要决定仍等待／阻塞，新时间不是延期已获准 | 本次新增明确流程 |
|
|
||||||
| Y.1–Y.2 | 必需成果主责判断不适用并提出申请 | 主责 → Hub → 主责补正或人工决定 | 原因、证据、替代方案、风险、基线与负责人确认 → 资格及结构检查 | 非主责、无证据、不可豁免不能放行；来不及不等于不适用 | 已覆盖 |
|
|
||||||
| Y.3 | Hub 已校验汇总申请 | Hub 对应真人项目负责人 → Hub | 申请及影响 → 明确批准／拒绝、人、时间、范围、条件与失效条件 | 不由 AI 决定，不另设已删除的下游征询或业务确认环节 | 已覆盖 |
|
|
||||||
| Y.4A–Y.4B | 已批准，或拒绝／附加条件未满足 | Hub → 受影响角色或成果主责 | 豁免记录及替代依据，或补交内容／证据／期限 | 保留原必需项；范围或输入基线变更使旧豁免失效；只豁免文件，不取消测试验收门禁 | 本次明确失效及未满足条件分支 |
|
|
||||||
|
|
||||||
## 正式成果及栏目交叉检查
|
|
||||||
|
|
||||||
- 阶段 1：使用客户里程碑要求，小批量试产、量产选填；不恢复早期风险预检。
|
|
||||||
- 阶段 2：立项资料包含平台 SDK、个参资料；项目风险在本阶段形成、由产品持续维护；结构板框图本阶段选填。
|
|
||||||
- 阶段 3：测试计划必需、总体技术方案与硬件约束选填；不要求软硬件接口契约、架构决策记录或硬件设计包。
|
|
||||||
- 阶段 4：项目计划包含任务拆分与工时评估；不另设产品资料整合，也不重新创建本阶段项目风险成果。
|
|
||||||
- 阶段 5：硬件前置器件规格书及结构板框图与四类设计输出分开；BSP／PSP 路径须可访问；定频固件选填；统一应用包保留 zn_debug、MD5、分区、自测、Changelog、串口使能证书等要求。
|
|
||||||
- 阶段 6：必需为功能测试报告和缺陷清单；三类报告／佐证选填；删除的是 bug 汇总统计要求，不是用例执行结果、缺陷条目或质量依据；不强制独立专项矩阵、通用证据包或缺陷分析报告。
|
|
||||||
- 阶段 7：平台报告或结论二选一、客户验收通过报告、同一遗留问题清单；权限和同版双通过条件一致。
|
|
||||||
- 阶段 8：结项资料归档、变更记录、结项报告、流程闭环总结四类；无新增冒烟或发布验证。
|
|
||||||
|
|
||||||
## 验证与边界
|
|
||||||
|
|
||||||
- 已执行 Skill Creator 结构校验：通过。
|
|
||||||
- 已进行七组独立只读情景核验：普通回归、硬件 ECO 不改固件、不同权限的超时、未来改进与结项、状态纠正、豁免基线失效、零缺陷人工确认。核验指出的硬件 Hook 泛化已收紧为阶段 5 设计确认与阶段 6 回归按需确认的区别，并通过定向复查。
|
|
||||||
- 静态检查通过：32 个 Markdown 文件中的 83 处本地链接可解析；8 个 Hook JSON 合法，角色标识、显示名称、字段集合和工具列表未改变；92 个信息流节点全部有核对记录，无遗漏或额外编号；差异空白检查通过；两版 HTML 哈希未改变。上述检查不代替真实 Etunel 项目运行。
|
|
||||||
- 未调用真实 Etunel、钉钉、平台测试或客户验收；未改变现有运行项目、已安装 Skill／Hook 或远程 Git。
|
|
||||||
|
|
||||||
保护文件 SHA256：
|
|
||||||
|
|
||||||
| 文件 | SHA256 |
|
|
||||||
|---|---|
|
|
||||||
| V0.15 HTML | `3717DE13267E83E7408342FF25584050BE20167A96EED097577AC4542789EB73` |
|
|
||||||
| V0.16 HTML | `47695E15051E9C1647A4E5CC18F5BDE17FEED8890FD1649339E77E4ADAF49AC9` |
|
|
||||||
|
|
||||||
本次开始时分支为 `docs/v0.15-next`，HEAD 为 `163f655cd0ac09ccf87adeec0a3fb665ceb01042`。修改保留在工作区，待用户核对后再决定是否提交或推送。
|
|
||||||
@@ -0,0 +1,492 @@
|
|||||||
|
<!doctype html>
|
||||||
|
<html lang="zh-CN">
|
||||||
|
<head>
|
||||||
|
<meta charset="utf-8">
|
||||||
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||||
|
<meta name="color-scheme" content="light">
|
||||||
|
<link rel="icon" href="data:,">
|
||||||
|
<title>Codex 多角色项目推进总流程图｜V2.1</title>
|
||||||
|
<style>
|
||||||
|
:root{--ink:#182d42;--muted:#586b7b;--navy:#112e49;--blue:#236fa3;--teal:#087f7a;--amber:#95601b;--line:#d9e3e9;--paper:#f3f6f8;--soft:#eaf5f3}
|
||||||
|
*{box-sizing:border-box}html{scroll-behavior:smooth;scroll-padding-top:24px}body{margin:0;background:var(--paper);color:var(--ink);font:16px/1.75 "Microsoft YaHei","PingFang SC",system-ui,sans-serif}a{color:var(--blue);text-underline-offset:3px}h1,h2,h3,p{margin-top:0}h1{font-size:clamp(30px,4vw,48px);line-height:1.35;margin-bottom:20px}h2{font-size:26px;line-height:1.45;margin-bottom:16px}h3{font-size:18px;margin-bottom:10px}p{margin-bottom:12px}ul,ol{margin:10px 0;padding-left:24px}li+li{margin-top:6px}strong{font-weight:700}
|
||||||
|
.hero{background:linear-gradient(120deg,#102b44,#18536c);color:white;padding:54px 32px 42px}.hero-inner,.wrap{max-width:1160px;margin:auto}.eyebrow{font-size:13px;letter-spacing:2px;opacity:.82;margin-bottom:16px}.hero p{max-width:850px;color:#deedf4;font-size:18px}.badge{display:inline-block;padding:5px 12px;border:1px solid #81b2c6;border-radius:6px;margin:12px 8px 0 0;font-size:14px}.wrap{padding:28px 24px 60px}.section{background:white;border:1px solid var(--line);border-radius:12px;padding:30px;margin-bottom:24px}.note{border-left:4px solid var(--teal);background:var(--soft);padding:16px 20px;margin:18px 0}.note.warn{border-color:#c58b37;background:#fff5e7}.small{font-size:14px;color:var(--muted)}.kicker{color:var(--teal);font-weight:700;font-size:13px;letter-spacing:1px;margin-bottom:8px}.nav{display:flex;flex-wrap:wrap;gap:9px;margin:18px 0 0}.nav a{background:#f0f5f8;border:1px solid var(--line);border-radius:5px;padding:6px 11px;text-decoration:none;font-size:14px}.nav a:hover{background:#e0eef4}
|
||||||
|
.cycle{display:grid;grid-template-columns:repeat(4,minmax(0,1fr));gap:14px;margin:22px 0}.step{border:1px solid var(--line);border-radius:8px;padding:18px;background:#f7fafb}.step .num{color:var(--teal);font-size:13px;font-weight:bold;margin-bottom:8px}.step h3{margin-bottom:6px}.step p{font-size:14px;color:var(--muted);margin-bottom:0}.step:last-child{border-color:#9bc9c3;background:var(--soft)}
|
||||||
|
.table-wrap{overflow-x:auto;margin:18px 0}table{width:100%;border-collapse:collapse;font-size:14px}th,td{padding:13px 14px;text-align:left;vertical-align:top;border:1px solid var(--line)}th{background:#edf3f6;color:#27465d;font-weight:700}td:first-child{font-weight:600}caption{text-align:left;font-weight:700;margin-bottom:10px}.overview td:first-child{width:17%}.overview td:nth-child(2){width:20%}.overview td:nth-child(3){width:36%}.flow-title{display:flex;align-items:center;gap:16px;margin-bottom:14px}.stage-num{flex:0 0 auto;display:grid;place-items:center;width:48px;height:48px;background:var(--navy);color:white;border-radius:9px;font-size:22px;font-weight:bold}.flow-title h2{margin-bottom:0}.owner{color:var(--muted);margin-bottom:20px}.triplet{display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:16px;margin:18px 0}.pane{border:1px solid var(--line);border-top:3px solid var(--blue);padding:18px;border-radius:7px}.pane:nth-child(2){border-top-color:var(--teal)}.pane:nth-child(3){border-top-color:#c58b37}.pane h3{font-size:17px}.pane p,.pane li{font-size:15px}.pane ul{padding-left:20px}.pane p:last-child{margin-bottom:0}.detail{padding-top:12px;border-top:1px solid var(--line);margin-top:18px}.gate{background:var(--soft);padding:15px 18px;border-radius:7px;margin-top:18px}.gate strong{color:#066660}.tag{font-size:12px;border-radius:4px;padding:3px 7px;background:#eef4f7;white-space:nowrap;margin-left:6px}.back{display:block;text-align:right;font-size:13px;margin-top:18px}footer{color:var(--muted);font-size:14px;text-align:center;padding:10px 24px 30px}.template td:first-child{width:23%}
|
||||||
|
@media(max-width:800px){.cycle,.triplet{grid-template-columns:1fr 1fr}.triplet .pane:last-child{grid-column:1/-1}.wrap{padding:20px 16px 40px}.section{padding:24px}.hero{padding:36px 24px}table{min-width:700px}.template{min-width:540px}}
|
||||||
|
@media(max-width:520px){.cycle,.triplet{grid-template-columns:1fr}.triplet .pane:last-child{grid-column:auto}.section{padding:20px}.hero{padding:30px 20px}.flow-title{gap:12px}h2{font-size:23px}.stage-num{width:42px;height:42px;font-size:20px}.hero p{font-size:16px}}
|
||||||
|
@media print{html{scroll-behavior:auto}body{background:white;font-size:11pt}.hero{background:white;color:var(--ink);padding:18px 0}.hero p{color:var(--muted)}.badge{border-color:var(--line)}.wrap{max-width:none;padding:0}.section{border-radius:0;padding:18px 0;margin:0;border-width:0 0 1px}.nav,.back{display:none}h1{font-size:25pt}h2{font-size:18pt}.table-wrap{overflow:visible}table{min-width:0;font-size:9pt}th,td{padding:7px}.triplet,.cycle{display:block}.pane,.step{margin-bottom:10px;break-inside:avoid}.flow-title,.gate,.note,h3{break-inside:avoid}thead{display:table-header-group}tr{break-inside:avoid}a{color:inherit}footer{padding:16px 0}}
|
||||||
|
</style>
|
||||||
|
</head>
|
||||||
|
<body>
|
||||||
|
<header class="hero" id="top">
|
||||||
|
<div class="hero-inner">
|
||||||
|
<div class="eyebrow">CODEX · 多角色项目流程 · V2.1</div>
|
||||||
|
<h1>中心下发任务，真人交付结果<br>按八个阶段推进项目</h1>
|
||||||
|
<p>真人角色负责组织和完成工作，提交完成情况与结果性资料。中心整理结果，由中心真人项目负责人决定进入下一环节、补充、退回或暂缓。</p>
|
||||||
|
<span class="badge">保留八阶段</span><span class="badge">真人角色负责执行与提交</span><span class="badge">中心真人负责人决定推进</span>
|
||||||
|
</div>
|
||||||
|
</header>
|
||||||
|
<main class="wrap">
|
||||||
|
<section class="section" id="version">
|
||||||
|
<div class="kicker">版本与适用范围</div>
|
||||||
|
<h2>V2.1：补齐排期、成果确认、归档和结项规则</h2>
|
||||||
|
<p><strong>编制日期：2026-10-20。</strong>本版依据 YT42-Test2《流程更新》截至 2026-10-20 的已确认规则，在 V2.0 八阶段结构上补充阶段汇报、需求交接、工时与周期评估、预排期维护、成果查看、Bug 双方确认、完整归档及关闭后的登记要求。</p>
|
||||||
|
<p>沿用真人角色组织执行、提交专业结果，中心真人负责人决定推进的分工。项目中的人名、型号、日期、工时、问题数量、单次放行和豁免决定留在项目记录中；其他项目依据自身需求、授权和有效基线执行。</p>
|
||||||
|
<div class="note"><strong>当前固定路径采用 V2.1，历史版本通过 Git 保留。</strong>本轮已按授权同步<a href="../ep-hub/SKILL.md">中心业务 Skill</a>、记录模板及通知脚本说明。仓库更新不等于已发布、安装或迁移在途项目；Etunel 配置与通信仍使用 etunel-use。</div>
|
||||||
|
<p class="small">历史对照：<a href="https://git.playones.com/chenmingxuan/EP-Hub-Skill/src/commit/3fb9c0658de56c3914f5b27c2df1f415bd73661d/doc/Codex多角色项目推进总流程图.html">V1.0 原流程文档（Git 历史）</a>。模板来源：<a href="文档模板参考/README.md">文档模板参考</a>。旧文档中的过程节点用于历史对照；各项目按已确认采用的流程版本执行；本页展示 V2.1 的任务与结果要求。</p>
|
||||||
|
<nav class="nav" aria-label="文档导航">
|
||||||
|
<a href="#rules">共同规则</a><a href="#reporting">阶段汇报</a><a href="#notifications">阶段群总结</a><a href="#records">成果与过程留档</a><a href="#overview">八阶段总览</a><a href="#stage1">01 业务需求</a><a href="#stage2">02 产品定义</a><a href="#stage3">03 方案设计</a><a href="#stage4">04 项目规划</a><a href="#schedule-template">预排期格式</a><a href="#stage5">05 软硬件实现</a><a href="#stage6">06 测试验证</a><a href="#stage7">07 内部／外部验收</a><a href="#stage8">08 复盘结项</a><a href="#exceptions">变更与阻塞</a><a href="#templates">任务与提交格式</a>
|
||||||
|
</nav>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="section" id="rules">
|
||||||
|
<div class="kicker">各阶段统一采用的工作方式</div>
|
||||||
|
<h2>下发任务 → 真人执行 → 提交结果 → 中心确认</h2>
|
||||||
|
<div class="cycle" aria-label="各阶段统一任务循环">
|
||||||
|
<div class="step"><div class="num">01 · 中心</div><h3>下发任务</h3><p>明确主责真人角色、有效输入、任务范围、完成时间、结果资料和完成条件。</p></div>
|
||||||
|
<div class="step"><div class="num">02 · 真人角色</div><h3>组织并完成工作</h3><p>自行安排工作、评审、自查和协作；是否使用 Agent 以及如何使用，由真人角色决定。</p></div>
|
||||||
|
<div class="step"><div class="num">03 · 真人角色</div><h3>提交完成情况与资料</h3><p>提交专业结论、实际成果及版本、完成情况、必要授权结论和遗留问题。</p></div>
|
||||||
|
<div class="step"><div class="num">04 · 中心</div><h3>确认是否推进</h3><p>中心 Agent 整理结果，中心真人负责人决定推进、补充、退回或暂缓，并留下记录。</p></div>
|
||||||
|
</div>
|
||||||
|
<p>这个循环适用于每项任务和阶段收口。同一阶段可有多项任务，每项任务只有一个主责真人角色。单项任务被接受后，可启动依赖已经满足的后续任务；跨阶段推进须取得中心真人负责人明确决定；已有条件授权的，条件实际满足后按原范围执行并登记依据，不重复申请同一批准。推进不把未交或待确认成果改写为已完成。</p>
|
||||||
|
<div class="note"><strong>成果不能如期交付时：</strong>真人角色可提交中心真人负责人确认，说明待交成果、延期原因、影响及计划交付时间。真人确认后，由中心 Agent 记录待交项、责任人、新交付时间和确认决定；在每个阶段结束时提醒中心真人负责人及相关责任角色，直至交付或另有明确处理决定。是否推进由中心真人负责人依据实际影响决定，延期成果仍记为未交付。</div>
|
||||||
|
<div class="table-wrap"><table>
|
||||||
|
<caption>谁负责什么</caption>
|
||||||
|
<thead><tr><th>主体</th><th>主要责任</th><th>决定范围</th></tr></thead>
|
||||||
|
<tbody>
|
||||||
|
<tr><td>中心真人项目负责人</td><td>组织项目推进，明确任务与阶段完成条件，处理项目级协调，依据提交结果决定下一步。</td><td>阶段推进、补充、退回、暂缓，以及成果豁免；保留其他角色的专业决定和业务授权范围。</td></tr>
|
||||||
|
<tr><td>中心 Agent（项目Hub）</td><td>协助整理任务、完成情况、成果索引、版本、遗留问题和进度；记录真人决定并协调后续任务。</td><td>不代替真人批准，不代写专业结论，不逐项核实角色内部工作步骤。</td></tr>
|
||||||
|
<tr><td>各专业真人角色</td><td>对任务执行、专业评审、自查、结果真实性和正式提交负责；自行组织所需协作。</td><td>在本角色职责内给出专业结论；涉及其他专业或授权事项，取得相应有权角色的结论并随结果提交。</td></tr>
|
||||||
|
<tr><td>角色 Agent（按需使用）</td><td>按真人角色安排协助工作；不构成接收或提交任务的必经环节。</td><td>不替真人确认或批准；成员 Agent 跨角色信息仍交中心定向中继。</td></tr>
|
||||||
|
</tbody>
|
||||||
|
</table></div>
|
||||||
|
<h3>执行过程由真人角色负责</h3>
|
||||||
|
<ul>
|
||||||
|
<li>中心不要求角色逐步汇报，也不对每一项内部评审、操作或细节设置单独的 Agent 核实任务。必要的专业检查仍由真人角色组织完成。</li>
|
||||||
|
<li>任务交付渠道不强制限定为 Etunel 角色会话。只需真人角色实际收到任务，并让最终提交和中心决定可追踪；工具显示已发送不等于真人已接收或任务已完成。</li>
|
||||||
|
<li>真人角色可直接开展必要的线下沟通与专业协作。使用多个角色 Agent 时，其跨角色任务、问题和结论仍由中心中继，不开放成员 Agent 直连。</li>
|
||||||
|
<li>只有影响任务完成的阻塞、跨任务依赖冲突或需要中心决定的变更，才在执行中提交中心。专业角色能够在既定任务范围内解决的问题，由其自行处理。</li>
|
||||||
|
<li>必要的专业结论、授权和验收结果随成果一并提交；中心依据结果判断，不把这些工作再次拆成逐项确认回路。</li>
|
||||||
|
</ul>
|
||||||
|
<h3>中心按结果确认</h3>
|
||||||
|
<ul>
|
||||||
|
<li>中心 Agent 将提交内容与下发的完成条件对应，整理已完成项、缺失项、成果与版本、专业结论、必要授权、依赖和剩余风险，交中心真人负责人决定。</li>
|
||||||
|
<li>请求中心真人确认成果前，逐项提供本次范围涉及的全部有效文件名、版本、确认用途及可点击完整地址，或直接展示对应文件。已有索引可引用，但须能定位本次涉及的各份文件；不能只给总目录、摘要或中心确认记录。</li>
|
||||||
|
<li>沿已有成果身份和真实入口交接；包内内容可引用有效索引，缺项和可访问范围如实说明。只补入口时不重复申请已有效的结果确认，不编造路径或声称尚未提供的文件已供查看。</li>
|
||||||
|
<li>可读可用和专业结论由有权真人确认。Agent 无法访问成员磁盘或共享目录，只说明本端访问失败，不据此判定未提交、文件不存在或成果不兼容；不把 Agent 下载、解包、截图或重算哈希设为固定推进前置。</li>
|
||||||
|
<li>中心可以针对影响完成判断的缺口提出补充要求，说明缺什么、影响什么；不要求证明全部工作过程或重复提交同一有效资料。</li>
|
||||||
|
<li>中心真人负责人决定推进时，明确接受的结果、版本和适用范围。退回或暂缓时，明确原因、待处理事项、责任角色及下一步。</li>
|
||||||
|
<li>测试结论与版本放行决定分别记录。测试不通过时，项目、产品双方真人可共同确认核实，以核实结论作为版本放行依据；保留原测试结论，并记录版本、未通过项、影响、放行条件及双方确认。外部验收结果和预算授权仍由有权角色确认。</li>
|
||||||
|
<li>文件或需求有差异时，由有权真人明确采用内容、对象、版本和影响范围。当前文件同步、过去审阅对象和差异对既有结论的影响分别记录，不补造历史审阅事实。</li>
|
||||||
|
<li>同一成果、版本和范围的有效确认继续沿用。只有实质变化、用途超出原范围或出现相反证据时，才补充相应结果和确认；尚未完成或未经真人确认的材料只进入过程记录。</li>
|
||||||
|
</ul>
|
||||||
|
<div class="note"><strong>八个默认角色保持不变：</strong>项目Hub（中心）、业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件、测试。阶段 4、8 由中心真人负责人组织，相关真人角色提供具体工作与结果，中心 Agent 协助整理。新增角色仍须先明确职责契约，由中心真人负责人完成实际配置。</div>
|
||||||
|
<p class="small">一个项目使用一个持续的中心贯穿生命周期。使用 Etunel 时，其运行时继续负责投递、队列、重试、去重、会话授权和文件传输，本流程不另设软件机制。钉钉仅用于已授权的辅助通知，通知不替代任务提交、批准、验收或项目事实记录。</p>
|
||||||
|
<a class="back" href="#top">返回顶部 ↑</a>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="section" id="reporting">
|
||||||
|
<div class="kicker">先汇报结果，再决定阶段安排</div>
|
||||||
|
<h2>中心主动提交阶段成果汇总</h2>
|
||||||
|
<p>本阶段任务均取得所需真人完成确认后，中心 Agent 须主动在中心持续聊天提交汇总。成果已交但必要确认未齐，或仍有未完成、延期、拟承接事项需要中心判断时，同样提交汇总；成果、版本、确认或遗留发生实质变化时补充说明。仅更新本地记录不算已向中心真人汇报。</p>
|
||||||
|
<div class="table-wrap"><table><caption>汇报中逐项说明什么</caption><thead><tr><th>内容</th><th>必须说明</th></tr></thead><tbody>
|
||||||
|
<tr><td>阶段概况</td><td>项目、阶段、汇报日期；全部确认完成、部分完成或已交待确认；本次需要的决定。</td></tr>
|
||||||
|
<tr><td>任务与成果</td><td>唯一主责真人、必需／选填、适用完成条件、应交／已交、版本及有效文件入口；成果包说明内容与缺项。</td></tr>
|
||||||
|
<tr><td>确认与时间</td><td>确认人、真实确认时间、对象／版本、结论、范围及条件；原计划、当前计划、提交与确认后实际完成时间。</td></tr>
|
||||||
|
<tr><td>未完成与待确认</td><td>实际状态、原因／依赖、负责人、原计划与当前计划、影响、必须完成阶段及补齐或承接建议。选填未交、豁免、取消分别说明。</td></tr>
|
||||||
|
<tr><td>提请决定</td><td>接受哪些结果；推进、补充、退回或暂缓；第八阶段为是否关闭。建议与真人决定分开记录。</td></tr>
|
||||||
|
</tbody></table></div>
|
||||||
|
<div class="note"><strong>没有遗留时明确写：</strong>“未完成项：无；待确认项：无”。有任何未完成或待确认事项时，如实列出。选填未交不自动阻塞，也不需要豁免；外部平台要求另按实际判断。</div>
|
||||||
|
<p>中心决定后，沿原任务登记决定人、日期、范围、条件和下一步。带遗留推进仍保留未完成状态；阶段八保留业务结项结论和其他必要确认。尚无决定时，阶段安排保持待决定。</p>
|
||||||
|
<a class="back" href="#templates">查看汇报格式 ↓</a>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="section" id="notifications">
|
||||||
|
<div class="note">阶段内已授权的关键进展、阻塞和失败通知继续保留，同轮合并；阶段交接固定合为一条，等待推进决定时先在中心会话汇报，实际关闭后发一次结项总结。</div>
|
||||||
|
<div class="kicker">项目已授权启用后执行</div>
|
||||||
|
<h2>每次阶段交接发送一条群总结</h2>
|
||||||
|
<ul>
|
||||||
|
<li>中心真人明确同意推进，或已有条件授权实际满足后，将上一阶段总结与下一阶段安排合成一条发送；等待决定时，先在中心持续聊天汇报，不提前写已进入下一阶段。</li>
|
||||||
|
<li>阶段八明确结项关闭后发送一次结项总结，说明最终成果、实际关闭结论，以及仍需跟进的遗留、责任和已确认安排。</li>
|
||||||
|
<li>首次须由中心真人确认发送账号、目标群和通知范围；账号或群变更时重新确认。在已确认范围内执行，不因每次交接重复申请同一授权。</li>
|
||||||
|
<li>先更新事实记录，再发送。写清已确认成果、未完成／待确认事项、实际推进决定，以及下一阶段已确认任务、负责人和期限；未知写待确认，不把通用职责写成本轮已派任务。</li>
|
||||||
|
<li>每条信息及子条目单独换行，用直接、自然的语言保留责任人、时间、条件和实际状态；总结及发送结果留在阶段过程记录，避免同一交接重复发送。</li>
|
||||||
|
<li>通过已确认的项目通知入口执行。请求已接受、投递成功和已读分别记录，不能代替真人接收、完成或验收；失败不阻塞主任务，结果未知时不盲目重发。</li>
|
||||||
|
</ul>
|
||||||
|
<a class="back" href="#top">返回顶部 ↑</a>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="section" id="records">
|
||||||
|
<div class="note"><strong>计划主表与日期口径：</strong>已有项目沿用已确认的唯一主表，新项目默认使用可编辑 Excel 八列模板，Markdown 进度只保留摘要和入口。模板不预填日期、工时、人数或迭代轮数。条件授权日期、条件实际满足日期和实际切换日期分别记录，阶段交接管理日期取实际切换日期。实际执行据真实回报更新并保留来源和历史，改动已确认日期、范围或资源安排由有权真人确认；日常状态更新不重批整表。</div>
|
||||||
|
<div class="kicker">八阶段共同采用的留档规则</div>
|
||||||
|
<h2>正式成果只留最终版与确认记录</h2>
|
||||||
|
<h3>正式成果区</h3>
|
||||||
|
<ul>
|
||||||
|
<li>保存各真人角色完成并确认后的全部有效成果及配套资料，包括文档、固件、硬件资料及其他约定产出。正式区须有有效原件／成果包，或真实完整外部入口及对应确认；不能仅放概括目录或中心确认记录，就称全部资料已归档。</li>
|
||||||
|
<li>每项成果只登记一个最终有效版本，并保留该版本对应的真人确认记录。</li>
|
||||||
|
<li>正式成果条目只列成果名称、最终版本、文件位置或链接地址；确认记录分条列出确认人、确认时间、对应成果与版本、确认结论及范围和条件。</li>
|
||||||
|
<li>未完成项、待确认材料、候选固件、草稿及旧版不登记为最终正式成果；中心 Agent 整理、生成或收到文件均不等于真人确认。</li>
|
||||||
|
<li>同一文件或连贯成果包可以承载多个结果，不为凑齐名称另造文件。文件名含“草稿”“预览”时，正式状态以有效真人确认和实际采用决定为准，保留确认对象及原提交来源。</li>
|
||||||
|
<li>成果文件正文按真人确认的最终版本保存，不因记录分区而删改成果内容。</li>
|
||||||
|
</ul>
|
||||||
|
<h3>过程记录区</h3>
|
||||||
|
<ul>
|
||||||
|
<li>旧版成果、草稿和对应的历史确认保留在过程记录中，不删除历史资料，不覆盖旧文件。</li>
|
||||||
|
<li>任务要求、输入基线、完成情况、评审意见、修订过程、退回原因、风险、延期、阻塞及下一步分条保存。</li>
|
||||||
|
<li>中心的推进、退回、暂缓、版本放行和豁免决定保存为过程记录，关联最终成果与必要真人确认。</li>
|
||||||
|
<li>成果实质变化后，新版经真人完成并确认，再替换正式成果区的当前条目；旧版、旧确认与替代关系转入过程记录留存。</li>
|
||||||
|
<li>各阶段已约定的《变更记录》《流程闭环总结》等交付文档，真人完成并确认后的最终文件仍是正式成果；其草稿与编写过程放入过程记录。</li>
|
||||||
|
</ul>
|
||||||
|
<h3>成果中的链接</h3>
|
||||||
|
<ul>
|
||||||
|
<li>正式成果通过链接交付，或成果中含有相关链接时，记录链接地址即可。</li>
|
||||||
|
<li>外部成果登记真实完整入口、用途、版本及对应确认，不强制下载或复制全部外部文件，也不要求另作链接摘要或截图。</li>
|
||||||
|
<li>项目已明确授权本地复制归档时，将已取得且确认有效的原件及配套资料按阶段、成果分类复制到正式区，保留原交接资料、历史入口和路径映射；目录、索引及汇总改指正式位置。</li>
|
||||||
|
<li>复制或补地址日期单独记录，不替换原提交、采用、确认、实际完成或阶段起止日期；归档位置变化不重新申请已有有效确认。</li>
|
||||||
|
<li>成果对应的真人确认仍单独保留；链接内容的核实由真人角色负责，不因留档增加中心逐项核实任务。</li>
|
||||||
|
</ul>
|
||||||
|
<h3>所有阶段记录都分条展示</h3>
|
||||||
|
<ul>
|
||||||
|
<li>每个阶段按“正式成果及确认记录”和“过程记录”两个栏目展示，分开登记。</li>
|
||||||
|
<li>一项成果单列一条；每项确认、决定、待办和风险分别列条目，不打包成一个自然段。</li>
|
||||||
|
<li>同一事项的时间、责任人、内容、影响和下一步分别列子项，便于阅读和跟进。</li>
|
||||||
|
<li>阶段结束时，只把最终成果及确认列入正式成果小结；延期提醒、未决项和后续安排列入过程记录。</li>
|
||||||
|
</ul>
|
||||||
|
<p class="small">正式成果区和过程记录区分别对应阶段目录中的 <code>正式成果/</code> 与 <code>过程记录/</code>；<code>阶段记录.md</code> 按两个栏目分条展示。阶段 4、8 由中心真人负责人组织完成的成果也须经对应真人确认后，才登记最终版。</p>
|
||||||
|
<h3>项目、阶段与任务分别记录</h3>
|
||||||
|
<ul>
|
||||||
|
<li><strong>项目层：</strong>记录当前阶段、整体进度和当前需要处理的事项；未按期完成的事项持续列出原计划、当前有效计划、未完成原因、影响范围及必须完成的阶段。整体进度用阶段状态和关键成果说明，百分比须有已确认的计算依据。项目计划主表由中心按实际回报维护，Markdown 项目进度同步摘要；不另建一套重复任务。</li>
|
||||||
|
<li><strong>阶段层：</strong>逐项汇总本阶段每个任务的成果、完成及确认情况，分别列负责人、应交与已交成果、版本与位置、时间、缺口、下一步和任务原记录入口。未完成和待确认情况归入过程栏目。</li>
|
||||||
|
<li><strong>任务层：</strong>按可独立确认的交付结果或同一负责人的内聚任务包，一项一份 Markdown；前部维护现状，后部按时间追加接收、提交、退回、确认、改期等关键历史，不记录角色内部每一步操作。</li>
|
||||||
|
<li><strong>跨阶段：</strong>同一事项沿用所属阶段的原记录，涉及阶段引用，项目层持续跟进；完成或明确处置后保留历史，承接后仍需跟进的继续显示。</li>
|
||||||
|
<li><strong>三类时间：</strong>原计划保留首次确认期限，当前计划保留最新经确认的有效期限，每次改期保留旧值、新值、原因和真人决定；实际完成时间是任务提交后经对应真人明确确认完成的时间。提交时间另记，未确认写“尚未确认完成”，取消或豁免不写为实际完成。</li>
|
||||||
|
<li><strong>线下确认：</strong>接受中心真人明确转述的线下接收和确认事实，保留实际确认人、真实时间、对象与版本、结论、范围和条件，以及转述人、来源和补录时间；不新增截图、审批单或重复确认。</li>
|
||||||
|
<li><strong>阶段管理日期：</strong>开始取中心真人实际启用该阶段的日期，完成取明确结束／进入下一阶段的决定日期，第八阶段取明确关闭日期。进行中时完成日期留空；工程开工、测试、验收发生日期另记，不用管理日期计算工程提前／延期或总人时。</li>
|
||||||
|
<li><strong>提交与接收：</strong>本人明确已通过其他渠道提交时据实登记，入口未给、接收可用未确认及验收结论未取得分别说明，不因本聊天无附件回退成未提交。队列待投递不推翻线下已完成事实，也不按队列等待时长判定工程延期。</li>
|
||||||
|
<li><strong>记录更新顺序：</strong>先更新原任务，再同步阶段摘要、项目进度及适用成果索引；需要决定或通知时，使用已更新的事实。未知不填零、不造时间、负责人、地址、专业结论或签名。</li>
|
||||||
|
<li><strong>易读排版：</strong>标题后用一句话说明现状，各栏目分条、字段加粗、留出空行，详细历史置后；链接使用明确名称，未知信息如实标明。</li>
|
||||||
|
</ul>
|
||||||
|
<a class="back" href="#templates">查看分条记录格式 ↓</a>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="section" id="overview">
|
||||||
|
<div class="kicker">八阶段总览</div><h2>每阶段都以提交结果和中心决定收口</h2>
|
||||||
|
<div class="note"><strong>正常顺序：</strong>业务需求 → 产品定义 → 方案设计 → 项目规划 → 嵌入式软硬件实现 → 测试验证 → 内部／外部验收 → 复盘结项。测试不通过时，可安排修复、复验，也可由项目、产品双方真人核实后作出版本放行结论；验收问题回到受影响环节处理，不要求从头重启。</div>
|
||||||
|
<p>各阶段开始时，中心说明本阶段必须完成、后续阶段处理、当前不需要的内容。任务只覆盖当前必需项；后续资料不提前成为当前阶段的完成条件。阶段结束或需要中心判断安排时，先按<a href="#reporting">阶段汇报要求</a>提交成果、确认、遗留和有效入口，再取得推进决定。</p>
|
||||||
|
<div class="table-wrap"><table class="overview">
|
||||||
|
<thead><tr><th>阶段</th><th>真人工作责任</th><th>提交的正式成果</th><th>中心决定推进的结果依据</th></tr></thead>
|
||||||
|
<tbody>
|
||||||
|
<tr><td><a href="#stage1">01 业务需求</a></td><td>业务主责，产品参与需求对齐</td><td>业务需求（包含项目背景说明、客户里程碑要求）</td><td>业务与产品形成一致的需求基线，产品具备继续定义的输入。</td></tr>
|
||||||
|
<tr><td><a href="#stage2">02 产品定义</a></td><td>产品主责，相关专业角色参与</td><td>立项资料（含风险）；测试验收标准；里程碑要求</td><td>产品定义完整，业务范围已批准，验收标准可判断。</td></tr>
|
||||||
|
<tr><td><a href="#stage3">03 方案设计</a></td><td>技术负责人组织方案工作；测试编制计划</td><td>测试计划；总体技术方案（选填）</td><td>方案与接口可实施、需求未偏离、测试可验证；技术负责人认可测试计划。</td></tr>
|
||||||
|
<tr><td><a href="#stage4">04 项目规划</a></td><td>中心真人负责人组织，相关真人角色提供评估</td><td>项目计划；角色分工；项目状态内部记录</td><td>专业评估与技术依赖明确，中心统筹总排期，产品授权范围内的具体事项及必要业务授权已确认，首批任务可执行。</td></tr>
|
||||||
|
<tr><td><a href="#stage5">05 嵌入式软硬件实现</a></td><td>应用层、底层、硬件分别主责任务；技术负责人给出集成结论</td><td>硬件设计包；嵌入式底层实现资料；嵌入式应用层固件包</td><td>适用成果齐备，技术负责人确认最终软硬件版本匹配、可提测。</td></tr>
|
||||||
|
<tr><td><a href="#stage6">06 测试验证</a></td><td>测试主责；修复任务由相应实现角色主责</td><td>功能测试报告；缺陷链接（选填，不交缺陷清单文件）；可靠性测试报告、专项测试报告、提测佐证（选填）</td><td>测试提交真实结论与依据；通过时由中心真人负责人确认推进，不通过时可依据项目、产品双方核实的版本放行结论推进。</td></tr>
|
||||||
|
<tr><td><a href="#stage7">07 内部／外部验收</a></td><td>项目组织；内部验收任务交真人角色；外部验收结果由产品／业务确认</td><td>内部验收结果记入验收记录；平台验收报告或结论；客户验收通过报告；遗留问题清单</td><td>本阶段约定的内部验收完成，外部验收取得对应产品／业务确认，版本一致，问题和风险有承接。</td></tr>
|
||||||
|
<tr><td><a href="#stage8">08 复盘结项</a></td><td>中心真人负责人组织；各角色提供归档与复盘输入</td><td>结项资料归档；变更记录；结项报告；流程闭环总结</td><td>归档完整、复盘完成，Bug 处理或承接经中心和产品双方确认，业务确认结项，中心真人负责人决定关闭。</td></tr>
|
||||||
|
</tbody>
|
||||||
|
</table></div>
|
||||||
|
<div class="note warn"><strong>必需与选填按本版各阶段说明执行。</strong>选填成果未提交不阻塞推进，无需豁免；已提供时登记版本和专业结论。缺陷信息以选填链接提供，不提交缺陷清单文件。可靠性测试报告、专项测试报告、提测佐证是否提交，由中心真人负责人决定，已有有效决定可沿用。必需成果不能如期交付时，提交真人确认、记录并逐阶段提醒；不适用或豁免另按对应规则处理。</div>
|
||||||
|
<a class="back" href="#top">返回顶部 ↑</a>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="section" id="stage1" data-stage="1">
|
||||||
|
<div class="flow-title"><span class="stage-num">01</span><h2>业务需求</h2></div>
|
||||||
|
<p class="owner">业务真人角色主责；产品真人角色参与需求对齐。</p>
|
||||||
|
<div class="triplet">
|
||||||
|
<div class="pane"><h3>中心下发什么任务</h3><ul><li>交业务整理项目背景、客户目标、需求范围和客户里程碑，明确交付一份《业务需求》文档，并确认交付时间。</li></ul></div>
|
||||||
|
<div class="pane"><h3>真人提交什么结果</h3><ul><li>业务自行核实客户资料并与产品对齐，提交一份《业务需求》文档，包含项目背景说明、客户里程碑要求，说明双方一致的需求基线、未决事项和日期性质。</li></ul></div>
|
||||||
|
<div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 整理需求范围、资料版本和影响当前定义的缺口；</li><li>中心真人负责人依据业务与产品的一致结论，决定启动产品定义或退回补充。</li></ul></div>
|
||||||
|
</div>
|
||||||
|
<div class="detail"><h3>保留的结果要求</h3><ul>
|
||||||
|
<li>《业务需求》中的项目背景说明区分对接客户与最终客户，写明业务对象、目标与范围；预期价值、订单及预计销售额选填，不强制成功指标。</li>
|
||||||
|
<li>《业务需求》中的客户里程碑要求包含提测、入库时间；小批量试产、量产时间选填。客户期望日期与已批准的正式承诺分开说明。</li>
|
||||||
|
<li>需求对齐和资料核实由业务、产品真人完成，中心不逐项下发澄清确认任务；不增加早期风险预检作为固定前置条件。</li>
|
||||||
|
</ul></div>
|
||||||
|
<div class="gate"><strong>进入阶段 2：</strong><ul><li>业务与产品确认同一需求基线，影响该基线的冲突已处理，产品具备继续定义的输入；</li><li>中心真人负责人明确同意推进。</li></ul></div>
|
||||||
|
<a class="back" href="#overview">返回八阶段总览 ↑</a>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="section" id="stage2" data-stage="2">
|
||||||
|
<div class="flow-title"><span class="stage-num">02</span><h2>产品定义</h2></div>
|
||||||
|
<p class="owner">产品真人角色主责；业务、技术负责人、实现与测试真人角色按实际需要参与。</p>
|
||||||
|
<div class="triplet">
|
||||||
|
<div class="pane"><h3>中心下发什么任务</h3><ul><li>交产品依据业务基线完成立项资料、测试验收标准和里程碑要求；</li><li>给出当前范围、上游资料和成果要求，风险体现在立项资料中。</li></ul></div>
|
||||||
|
<div class="pane"><h3>真人提交什么结果</h3><ul><li>产品自行组织可行性、可测试性和实现约束评审，完成修订，取得业务对客户范围和验收边界的批准，汇总提交《立项资料》《测试验收标准》《里程碑要求》三类成果及专业结论。</li></ul></div>
|
||||||
|
<div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 整理产品基线、业务授权和验收条件；</li><li>中心真人负责人依据提交结果决定启动方案设计或补充当前必需内容。</li></ul></div>
|
||||||
|
</div>
|
||||||
|
<div class="detail"><h3>保留的结果要求</h3><ul>
|
||||||
|
<li>《立项资料》包含立项书、功能清单、产品规格书等，风险体现在立项资料中，不单独形成《项目风险》成果；《测试验收标准》包含平台测试用例、客户验收测试用例和验收标准。</li>
|
||||||
|
<li>《里程碑要求》包含提测、客户验收时间，试产与量产时间选填；产品在《立项资料》中汇总并维护技术风险、时间风险及其他风险。</li>
|
||||||
|
<li>结构板框图在本阶段选填，后续硬件任务需要时补齐；模板中人力和费用属于早期估算，不代替正式资源、排期或预算授权。</li>
|
||||||
|
<li>各专业评审由真人角色组织，产品在提交中汇总结论，不要求中心逐轮中转并确认每条评审意见。</li>
|
||||||
|
</ul></div>
|
||||||
|
<div class="gate"><strong>进入阶段 3：</strong><ul><li>产品定义已确认、业务范围已批准，直接影响本阶段的约束已处理，验收标准可判断；</li><li>后续依赖如实登记，由中心真人负责人决定推进。</li></ul></div>
|
||||||
|
<a class="back" href="#overview">返回八阶段总览 ↑</a>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="section" id="stage3" data-stage="3">
|
||||||
|
<div class="flow-title"><span class="stage-num">03</span><h2>方案设计</h2></div>
|
||||||
|
<p class="owner">技术负责人真人组织方案与接口收口；测试真人主责编制《测试计划》。</p>
|
||||||
|
<div class="triplet">
|
||||||
|
<div class="pane"><h3>中心下发什么任务</h3><ul><li>依据产品基线，向技术负责人下发方案收口任务，向测试下发测试计划任务；</li><li>相关实现角色的任务按实际需要确定，明确各项主责和输入关系。</li></ul></div>
|
||||||
|
<div class="pane"><h3>真人提交什么结果</h3><ul><li>技术负责人自行组织方案、接口和可实施性评审，产品给出需求一致性结论，测试提交《测试计划》；</li><li>提交时一并提供技术负责人对方案和测试计划的确认结论。</li></ul></div>
|
||||||
|
<div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 整理方案结论、测试计划及当前未解决的约束；</li><li>中心真人负责人判断是否具备项目规划条件，不再逐个要求角色 Agent 确认同一细节或重复版本。</li></ul></div>
|
||||||
|
</div>
|
||||||
|
<div class="detail"><h3>保留的结果要求</h3><ul>
|
||||||
|
<li>《测试计划》必需，包含测试标准、测试用例范围和测试项，由测试编制与维护、技术负责人认可。</li>
|
||||||
|
<li>《总体技术方案》选填；方案、必要接口约束和专业决定可保留在已有记录中，不因未提交选填方案文件而阻塞。</li>
|
||||||
|
<li>应用层的业务模块及应用接口、底层的 BSP／驱动／RTOS／HAL 由对应真人角色处理；硬件器件、PCB、电源、信号、热与接口约束在本阶段选填，已提供时按本领域给出结论。</li>
|
||||||
|
<li>不新增独立软硬件接口契约、架构决策记录或本阶段硬件设计包。尚未形成的项目计划不作为方案设计前提。</li>
|
||||||
|
</ul></div>
|
||||||
|
<div class="gate"><strong>进入阶段 4：</strong><ul><li>方案与接口可实施、需求未偏离、测试可验证，测试计划已有技术负责人的确认结论；</li><li>中心真人负责人决定推进。</li></ul></div>
|
||||||
|
<a class="back" href="#overview">返回八阶段总览 ↑</a>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="section" id="stage4" data-stage="4">
|
||||||
|
<div class="flow-title"><span class="stage-num">04</span><h2>项目规划</h2></div>
|
||||||
|
<p class="owner">中心真人负责人组织；技术负责人、产品及执行真人角色提供任务、依赖、工期和资源评估。</p>
|
||||||
|
<div class="triplet">
|
||||||
|
<div class="pane"><h3>中心下发什么任务</h3><ul><li>明确规划目标，将技术结构与依赖、任务工期评估、资源与排期等工作交相应真人角色；</li><li>中心真人负责人负责组织形成计划，中心 Agent 协助汇总。</li></ul></div>
|
||||||
|
<div class="pane"><h3>真人提交什么结果</h3><ul><li>相关真人角色完成各自评估，中心真人负责人组织形成《项目计划》《角色分工》《项目状态内部记录》，随结果保留技术结构结论、产品授权范围内具体资源／排期事项的确认及必要业务授权。</li></ul></div>
|
||||||
|
<div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 整理可执行计划、责任分工和待解决约束；</li><li>中心真人负责人确认首批任务的输入与依赖已就绪，决定进入实现阶段。</li></ul></div>
|
||||||
|
</div>
|
||||||
|
<div class="detail"><h3>保留的结果要求</h3><ul>
|
||||||
|
<li>项目计划包含实际工作项、工时评估、周期、依赖和排期；中心真人负责人统筹总排期与跨角色资源协调。技术负责人核实技术结构、顺序、并行及依赖，不要求全员重新确认整份计划。</li>
|
||||||
|
<li>应用层、底层、硬件开始评估工时时，向三方提供全部有效产品需求文档。各真人明确本人范围、已有成果及剩余工作；未估事项、投入和外部等待分别说明。</li>
|
||||||
|
<li>初版单列；迭代轮数不含初版，各轮内容和周期可不同。研发开发、自测与修复，独立测试与回归，以及样机、环境、器件或生产等等待分别记录，保留实际单位和起算条件。</li>
|
||||||
|
<li>三领域报开发周期后，汇总给技术负责人核实范围、遗漏／重复、顺序、并行、合版和软硬件依赖；核实无问题后交测试衔接初版、各轮测试和回归周期及资源。测试可以先估自身工作量，再按核实后的研发节奏完善；项目日期由中心真人统筹确认。</li>
|
||||||
|
<li>各角色工时沿原任务按工作项以表格记录，列主责真人、原估／当前估及单位、周期与起算条件、投入／等待、提交或确认日期、来源和状态。变更保留旧值、新值、原因及真人确认；未知不填零，工作日不直接换成人日或小时。</li>
|
||||||
|
<li>产品只确认对象、权限依据和范围明确的资源／排期事项，不笼统承担全项目、其他专业或工厂周期；相关专业分别提供实际评估。预算、采购或对外承诺由业务批准。已提交的有限输入按原范围登记，不扩大为全部资源已落实。</li>
|
||||||
|
<li>角色分工写明每项任务的唯一主责、协作、人员变化和交接。相关执行角色只接收本角色任务所需的计划与资料。</li>
|
||||||
|
<li>规划引用阶段 2《立项资料》中的风险内容，不另造风险成果或《产品资料整合》。计划可同步业务，同步回执不增加批准条件。</li>
|
||||||
|
</ul></div>
|
||||||
|
<div class="detail" id="planning-method"><h3>预排期与实际执行</h3><ul>
|
||||||
|
<li>采用<a href="#schedule-template">八列预排期格式</a>，工作项按真实需求、已有成果、剩余工作、依赖及资源增减；不固定套用参考任务数量、迭代轮数、人员、工时或日期。模板预排日期留空，实际编制按专业评估和中心确认填写。</li>
|
||||||
|
<li>每项工时为合计人时，不再乘参与人数；人数不代表资源已落实。工时、开发周期、测试周期、投入比例及外部等待保留各自含义；NA、空白保留原义，不转换为零。</li>
|
||||||
|
<li>客户目标、内部预计、当前有效计划和实际执行分别记录；里程碑名称、编号及完成条件按实际项目确定。客户验收与量产目标分别跟进，不因一项预计改变自动调整另一项。</li>
|
||||||
|
<li>中心按真人实际回报维护唯一计划主表的“实际执行情况”，记录更新日期、进展、实际起止、成果／版本／入口、确认、偏差和下一步；未回报写待登记，不用预排日期代填实际日期。</li>
|
||||||
|
<li>改期经中心真人明确确认后更新，原计划、旧值／新值、原因、影响和决定依据沿原任务或阶段记录保留。Markdown 项目进度同步摘要，成果确认沿原记录维护。</li>
|
||||||
|
<li>串行、并行与起算条件依据真实依赖确定；表中重叠不直接代表技术依赖、已开工或跨阶段授权。八阶段继续管理成果、确认和归档，每轮测试明确对应固件及硬件版本。</li>
|
||||||
|
</ul></div>
|
||||||
|
<div class="gate"><strong>进入阶段 5：</strong><ul><li>专业评估及技术依赖已有结论，中心统筹总排期，产品授权范围内的具体事项与必要业务授权完成，首批依赖就绪任务可执行；</li><li>中心真人负责人决定推进。</li></ul></div>
|
||||||
|
<a class="back" href="#overview">返回八阶段总览 ↑</a>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="section" id="stage5" data-stage="5">
|
||||||
|
<div class="flow-title"><span class="stage-num">05</span><h2>嵌入式软硬件实现</h2></div>
|
||||||
|
<p class="owner">硬件、嵌入式底层、嵌入式应用层真人分别负责各自任务；技术负责人给出整体集成与可提测结论。</p>
|
||||||
|
<div class="triplet">
|
||||||
|
<div class="pane"><h3>中心下发什么任务</h3><ul><li>按产品、方案和计划，把依赖就绪的设计与实现任务交对应真人角色；</li><li>明确成果包、输入版本、交付时间和下游用途。</li></ul></div>
|
||||||
|
<div class="pane"><h3>真人提交什么结果</h3><ul><li>真人角色自行组织设计、实现、自测、合版和联调，分别提交正式成果。</li><li>应用层交唯一最终提测固件，技术负责人提交最终软硬件版本匹配及可提测结论。</li></ul></div>
|
||||||
|
<div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 整理适用成果、版本关系、技术结论和遗留问题；</li><li>中心真人负责人依据结果决定提测，或对具体未满足项退回补充。</li></ul></div>
|
||||||
|
</div>
|
||||||
|
<div class="table-wrap"><table><caption>实现成果包保持原有内容</caption><thead><tr><th>主责真人角色</th><th>正式成果</th><th>结果资料内容</th></tr></thead><tbody>
|
||||||
|
<tr><td>硬件</td><td>硬件设计包</td><td>原理图、PCB 源文档、贴片资料（PCBA_BOM、器件位置图 PDF、贴片坐标）、接口定义。</td></tr>
|
||||||
|
<tr><td>嵌入式底层</td><td>嵌入式底层实现资料</td><td>硬件功能测试报告、BSP 输出路径、PSP 输出路径；WiFi 设备定频测试固件选填。</td></tr>
|
||||||
|
<tr><td>嵌入式应用层</td><td>嵌入式应用层固件包</td><td>正式／升级固件、自测用例、分区表、MD5 值文件、Flash 烧写固件、zn_debug 文件、Changelog、串口使能证书。</td></tr>
|
||||||
|
</tbody></table></div>
|
||||||
|
<div class="detail"><h3>保留的结果要求</h3><ul>
|
||||||
|
<li>按实际依赖推进。缺少硬件、软件或环境只阻塞依赖该输入的工作，已具备部分继续执行；到样、整机、PQ、AI 及环境按真人实际回报登记，计划日期和收到输入不证明后续工作已完成。</li>
|
||||||
|
<li>硬件真人开始设计前取得实际外设、关键器件规格书及结构板框图；缺失只影响相应硬件任务，需上游协调时向中心提出具体缺口。</li>
|
||||||
|
<li>底层提供可消费的 BSP／PSP，应用层负责合版。统一固件与硬件候选就绪后即可组织联调；联调问题关闭后提交最终提测版。</li>
|
||||||
|
<li>设计确认、接口协调、自测及联调由真人角色自行完成，中心不逐步核实。最终版本与软硬件匹配关系随结果提交，由技术负责人给出专业结论。</li>
|
||||||
|
<li>PSP 仓库／commit、BSP build 及消费入口是版本和输入信息，不直接代替最终固件身份，不把另一构建的结果写到指定最终包。已有配置提供有效 BSP 消费入口且真人明确无需独立获取时，沿原入口衔接，不重复索包或路径。</li>
|
||||||
|
<li>已有包身份和真实入口时，定向交相关真人确认可用性；需要补交接时只补实际缺口。Agent 访问失败不恢复为重做实现或反复上传整包的要求。</li>
|
||||||
|
<li>底层不直接向测试交最终固件；定频测试固件只用于专项测试。不另设《硬件实现资料》，也不把硬件前置输入重新列为产出。</li>
|
||||||
|
</ul></div>
|
||||||
|
<div class="gate"><strong>进入阶段 6：</strong><ul><li>适用成果齐备，最终统一固件与硬件版本匹配，技术负责人明确可提测；</li><li>中心真人负责人决定推进。</li></ul></div>
|
||||||
|
<a class="back" href="#overview">返回八阶段总览 ↑</a>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="section" id="stage6" data-stage="6">
|
||||||
|
<div class="flow-title"><span class="stage-num">06</span><h2>测试验证</h2></div>
|
||||||
|
<p class="owner">测试真人负责测试执行、缺陷信息维护与独立质量结论；修复工作由相应实现真人角色主责。</p>
|
||||||
|
<div class="triplet">
|
||||||
|
<div class="pane"><h3>中心下发什么任务</h3><ul><li>交测试依据统一固件、版本矩阵和测试计划开展验证，每轮明确固件及硬件版本、变更、必测范围、完成时间与提交要求；</li><li>三类选填资料的提交决定沿用或由中心真人负责人明确。</li></ul></div>
|
||||||
|
<div class="pane"><h3>真人提交什么结果</h3><ul><li>测试自行组织策略、执行、缺陷协调和独立复验，提交《功能测试报告》及约定提供的选填资料，缺陷信息可提供链接，不提交缺陷清单文件；</li><li>给出通过／不通过结论、实际覆盖范围和风险。</li></ul></div>
|
||||||
|
<div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 整理本次测试结果、被测版本与质量条件；</li><li>中心真人负责人明确确认或退回测试结果。</li><li>测试不通过时，由项目、产品双方真人确认核实，核实结论可作为版本放行依据；</li><li>中心据此记录放行及阶段推进决定。</li></ul></div>
|
||||||
|
</div>
|
||||||
|
<div class="detail"><h3>保留的结果要求</h3><ul>
|
||||||
|
<li>《功能测试报告》必需；缺陷信息以选填链接提供，不要求提交实际缺陷清单资料。无缺陷时在功能报告中说明零缺陷，不要求零缺陷清单或无必要的修复任务。</li>
|
||||||
|
<li>功能报告包含测试结论、测试用例执行结果及 bug log。《可靠性测试报告》《专项测试报告》《提测佐证》选填，是否提交由中心真人负责人决定；未提交选填文件不阻塞，不免除必测范围。</li>
|
||||||
|
<li>可靠性报告列高低温测试，跌落、防水测试选填；专项报告列适用专项；提测佐证为平台要求的视频、截图和 log。外部平台资料要求与内部选填决定分别记录，不把决定不交写成平台已经接受。</li>
|
||||||
|
<li>每次执行、复测或回归前由测试明确本次策略，不增加独立正式文件或额外审批。测试与实际相关真人负责人商议缺陷责任，每项缺陷明确一名责任人和一个主责角色。</li>
|
||||||
|
<li>需要修复任务时，将缺陷、主责与修复要求交中心安排；实现角色自行处理定位和修复，提交版本、自测及影响结论。底层修复经应用层重新合版；硬件 ECO 提供底层兼容、应用有效性及版本矩阵更新结果。</li>
|
||||||
|
<li>测试独立复验并维护缺陷状态。回归输入为统一固件、版本矩阵及必要变更说明；需要定位或复验具体缺陷时引用对应缺陷链接。只在实际需要时补充定位资料或技术负责人的版本结论，不要求中心逐轮核实修复细节。</li>
|
||||||
|
<li>底层实现资料、硬件设计包不作为常规测试必交输入。大文件由测试保管，通过链接交付时，中心只记录链接地址及对应真人确认，不重复上传或复制文件。</li>
|
||||||
|
</ul></div>
|
||||||
|
<div class="note warn"><strong>测试结果的人工确认保留。</strong><ul><li>测试真人提交后，中心真人负责人须实际查看并明确确认。</li><li>中心 Agent、已读、消息送达或工具任务完成都不能代替确认。</li><li>确认前按实际记为已提交待确认，不宣称测试结果已被接受或已进入正式验收；</li><li>实质变化后的结果或被测版本须重新提交确认。</li></ul></div>
|
||||||
|
<div class="note"><strong>测试不通过时的版本放行：</strong><ul><li>项目真人负责人和产品真人负责人共同核实不通过项、实际影响、剩余问题及处理安排，明确该版本是否放行。</li><li>核实结论写明版本、依据、放行范围与条件、遗留责任和双方确认人及时间，作为版本放行依据。</li><li>中心 Agent 保留原“不通过”测试结论，同时记录双方核实结论及后续安排；</li><li>未形成双方明确结论时，不自行放行。</li></ul></div>
|
||||||
|
<div class="gate"><strong>进入阶段 7：</strong><ul><li>测试通过时，按约定完成测试、提交功能报告与依据，中心真人负责人确认推进；</li><li>测试不通过时，可依据项目、产品双方核实后明确作出的版本放行结论推进，并保留未通过项和放行条件。</li><li>后续成果延期须经中心真人确认并记录，放行不表示外部验收已通过。</li></ul></div>
|
||||||
|
<a class="back" href="#overview">返回八阶段总览 ↑</a>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="section" id="stage7" data-stage="7">
|
||||||
|
<div class="flow-title"><span class="stage-num">07</span><h2>内部／外部验收</h2></div>
|
||||||
|
<p class="owner">项目组织验收；内部验收任务交对应真人角色，外部验收结果由产品／业务确认。平台结果由产品确认，客户结果由业务确认。</p>
|
||||||
|
<div class="triplet">
|
||||||
|
<div class="pane"><h3>中心下发什么任务</h3><ul><li>依据已确认的测试结果、版本放行结论及验收标准，由项目组织内部和外部验收。</li><li>内部验收可由中心向对应真人角色下发任务；</li><li>外部验收由产品／业务取得并确认结果。</li><li>明确本阶段适用的验收范围、对象、版本、交付时间和成果要求。</li></ul></div>
|
||||||
|
<div class="pane"><h3>真人提交什么结果</h3><ul><li>承担内部验收任务的真人角色提交验收结论与依据，记入已有验收记录。</li><li>外部验收结果由产品／业务确认；</li><li>产品汇总《平台验收报告或结论》《客户验收通过报告》和共用《遗留问题清单》，客户结果由业务确认。</li></ul></div>
|
||||||
|
<div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 整理内部验收结果、外部产品／业务确认、对应版本和遗留承接；</li><li>中心真人负责人依据本阶段约定的验收范围和实际结果，决定进入复盘结项或退回处理。</li></ul></div>
|
||||||
|
</div>
|
||||||
|
<div class="detail"><h3>保留的结果要求</h3><ul>
|
||||||
|
<li>测试真人直接向产品真人交付已完成并确认的最终测试报告及已提供的提测佐证；中心正式成果记录沿用最终版及确认。链接资料只记链接地址，不收转大文件；产品接收情况列入过程记录。</li>
|
||||||
|
<li>验收分为内部和外部。内部验收由承担任务的真人角色执行并提交结果；外部验收由产品／业务取得实际反馈并确认。各自输入就绪时可并行开展。</li>
|
||||||
|
<li>平台联系、发包／寄样、收件和进度跟进按项目明确唯一主责，不默认全部由产品或中心真人亲自执行。实际执行协调、产品接收可用、平台结果及客户业务确认分别登记；职责确定不证明动作已发生。</li>
|
||||||
|
<li>平台结果由产品确认，无需业务批准；客户验收通过报告由产品出具或更新，客户结果由业务确认。客户反馈由具备联络权限的真人取得。</li>
|
||||||
|
<li>沿同一份共用遗留记录标明内部／外部来源、实际验收方、对应版本、责任人、处置和状态；第八阶段按<a href="#bug-confirmation">中心与产品双方确认规则</a>继续，不另要求测试提交重复缺陷清单。未通过时提交具体问题及需中心安排的修复或变更，回到受影响环节处理。</li>
|
||||||
|
<li>返工产生新测试结果时，重新完成阶段 6 的结果确认；仍不通过而拟放行时，重新取得项目、产品双方的核实结论。版本变化影响其他验收项时，同步更新相应结果。</li>
|
||||||
|
</ul></div>
|
||||||
|
<div class="gate"><strong>进入阶段 8：</strong><ul><li>本阶段约定的内部验收完成，适用的外部验收取得产品／业务确认；</li><li>平台由产品确认，客户由业务确认，项目同时要求平台和客户验收时须两项均通过。</li><li>验收对象与有效版本一致，问题和风险有明确承接，中心真人负责人决定推进。</li><li>内部验收完成或版本已放行不能替代外部验收结果。</li></ul></div>
|
||||||
|
<a class="back" href="#overview">返回八阶段总览 ↑</a>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="section" id="stage8" data-stage="8">
|
||||||
|
<div class="flow-title"><span class="stage-num">08</span><h2>复盘结项</h2></div>
|
||||||
|
<p class="owner">中心真人负责人组织；各真人角色提交归档和复盘输入；业务保留结项确认职责。</p>
|
||||||
|
<div class="triplet">
|
||||||
|
<div class="pane"><h3>中心下发什么任务</h3><ul><li>向实际参与的真人角色下发资料归档、遗留承接和复盘任务，明确所需现有成果、事实及改进安排，不要求重做同内容文件。</li></ul></div>
|
||||||
|
<div class="pane"><h3>真人提交什么结果</h3><ul><li>各真人角色提交本角色资料和复盘结论。</li><li>中心真人负责人组织形成《结项资料归档》《变更记录》《结项报告》《流程闭环总结》，中心 Agent 协助整理，业务给出结项结论。</li></ul></div>
|
||||||
|
<div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 汇总完整成果及入口、验收结论、Bug 双方确认、业务结项确认和遗留承接；</li><li>中心真人负责人决定结项关闭或退回补充，留下决定与后续责任安排。</li></ul></div>
|
||||||
|
</div>
|
||||||
|
<div class="detail"><h3>保留的结果要求</h3><ul>
|
||||||
|
<li>正式成果归档收齐各阶段真人完成并确认的有效原件、成果包或真实外部入口及对应确认，沿用有效版本和配套资料；本地复制按项目明确授权执行，保留原交接与映射，不强制下载外部文件。</li>
|
||||||
|
<li>《结项资料归档》包含各阶段成果目录、有效完整入口、适用版本、阶段管理起止及依据，成果提交、采用和确认日期分别记录。汇总纳入第八阶段正式成果，不另造一类交付要求。</li>
|
||||||
|
<li>成果汇总和《结项报告》按项目已确认格式或模板编制；单工作表 Excel 可作为汇总参考，不强制其他项目使用相同工作表数量、字段粒度或报告栏目。模板中已有内容和日期依据真实记录填写，缺少工时、迭代、评审或签名时保留未知，不按文件数量推算。</li>
|
||||||
|
<li>过程资料另行归档：旧版、草稿、历史确认、变更过程、项目进度、产品接收情况及其他过程记录均保留，不混入最终正式成果记录。</li>
|
||||||
|
<li>复盘基于事实说明目标完成、计划偏差、协作与质量问题、经验和改进措施。改进项写入流程闭环总结，明确责任人和跟进安排，不另设正式成果。</li>
|
||||||
|
<li>业务依据归档、复盘和遗留承接确认结项或提出补充；中心记录这一结论后决定关闭。业务不重复批准已由产品确认的平台结果。</li>
|
||||||
|
<li>本阶段不安排冒烟、发布验证或其他测试，不要求重做发布固件。发现新的实现或质量问题，回到相应阶段处理。</li>
|
||||||
|
<li>结项必需项完成后锁定四类结项成果；仍有延期成果时，提交中心真人负责人明确补齐或承接安排后再决定是否关闭，未交资料保留待交状态。按安排跟进遗留与改进项，结项不表示后续改进已经全部实施。</li>
|
||||||
|
</ul></div>
|
||||||
|
<div class="detail" id="bug-confirmation"><h3>全部 Bug：中心先确认，产品再次确认</h3>
|
||||||
|
<ol>
|
||||||
|
<li>中心真人负责人先确认问题事实、适用版本、实际处理结果或后续承接安排；研发、测试等真人提供已有事实或专业意见。</li>
|
||||||
|
<li>中心将已确认内容提交产品真人负责人再次确认，并由产品在职责范围内决定处理方式。未知部分明确标出，不把中心尚未确认的事实交产品代查。</li>
|
||||||
|
<li>中心和产品对事实、处理结果或后续安排均无异议后，沿原任务及共用问题记录登记双方最终确认。产品提出调整时，中心协调确认受影响内容，再交产品确认；有分歧或缺少确认时保留待确认。</li>
|
||||||
|
</ol>
|
||||||
|
<ul>
|
||||||
|
<li>范围覆盖项目全部 Bug，包括后续发现和此前已处理的问题。已有适用的有效确认直接引用，仅补齐缺少或受变化影响的部分。</li>
|
||||||
|
<li>已修复、延期处理、暂不修复分别记录；未修复保留真实状态、责任人及后续安排。双方无异议不表示全部已修复，问题状态与最终处置确认分开。</li>
|
||||||
|
<li>逐项记录编号／名称、对象／版本、处理结果／状态、双方各自确认人、真实时间、结论、范围／条件、来源及后续责任／安排。过程事实与分歧随时登记，最终确认另记，保留历史；未知不编造。</li>
|
||||||
|
<li>复用原报告和共用记录，不新增测试必交清单或重做已接受测试。原不通过、版本放行及外部验收各自保留；需要新实现或验证时，按实际职责回到受影响阶段办理。</li>
|
||||||
|
</ul>
|
||||||
|
</div>
|
||||||
|
<div class="gate"><strong>项目关闭：</strong><ul><li>约定的内部与外部验收已完成并确认，归档完整可追踪，复盘完成，Bug 处理或承接已取得中心和产品双方确认，其他遗留已处理或落实承接，业务明确确认结项；</li><li>中心真人负责人决定关闭。</li><li>延期成果按真人确认的处理决定结清或明确承接，不能将未交付写成已归档。</li><li>模拟项目只能记录模拟完成。</li></ul></div>
|
||||||
|
<div class="detail"><h3>关闭决定后的登记与跟进</h3><ul>
|
||||||
|
<li>登记实际决定人、日期、原话、范围及条件，同步项目概览、进度、阶段、原任务、成果索引、报告和成果汇总的当前状态。锁定本次有效结项成果及目录，旧版和原交接记录保留。</li>
|
||||||
|
<li>停止对已结束阶段和已确认结果重复催办；队列未送达或工具未结算另记，沿原事项处理，不撤销真人关闭决定、不重派同一业务任务。</li>
|
||||||
|
<li>项目关闭不把原测试不通过改成通过，不把 Bug 改成已修复，不证明实际量产或出货。后续真实质量事项沿已有记录和责任渠道处理，需要新工作时按实际授权安排。</li>
|
||||||
|
<li>按<a href="#notifications">已授权通知规则</a>发送一次结项总结，记录实际发送结果，不因后续文档整理重复发送。</li>
|
||||||
|
<li>项目期间的流程补充、模板和反馈先在项目保留；完成后汇总拟纳入共享 Skill 的具体内容和文件入口，经有权真人对整合范围统一明确确认后再更新。项目关闭或本文件保存不代替整合确认。</li>
|
||||||
|
</ul></div>
|
||||||
|
<a class="back" href="#overview">返回八阶段总览 ↑</a>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="section" id="exceptions">
|
||||||
|
<div class="kicker">按影响处理，不增加固定过程确认</div><h2>变更、阻塞、豁免与留档</h2>
|
||||||
|
<div class="table-wrap"><table><thead><tr><th>情况</th><th>真人角色提交</th><th>中心处理</th></tr></thead><tbody>
|
||||||
|
<tr><td>影响完成的阻塞</td><td>受影响任务、事实与依据、缺少的输入或决定、影响、建议动作和期望时间。</td><td>中心 Agent 整理，中心真人负责人安排协调、补充任务或暂缓；只阻塞受影响任务，条件满足后恢复。</td></tr>
|
||||||
|
<tr><td>需改变基线的事项</td><td>《变更申请》：旧基线、拟变更内容、原因、范围、版本、成本／排期／质量影响及建议。</td><td>按权限取得产品、业务或相应专业结论，由中心记录决定、生效范围及后续任务。不得自行改变范围、接口、排期或验收条件。</td></tr>
|
||||||
|
<tr><td>专业意见冲突</td><td>真人角色自行组织讨论，提交收口结论；无法收口时写明分歧、证据及需要中心决定的事项。</td><td>中心协调有权真人角色解决，中心 Agent 不替专业角色裁决；需要修改基线时按变更处理。</td></tr>
|
||||||
|
<tr><td>结果不满足完成条件</td><td>实际完成部分、缺失项、原因、影响和补充安排；保留有效成果。</td><td>中心真人负责人决定补充、退回或暂缓，并明确待补项；不把部分完成写成全部完成。</td></tr>
|
||||||
|
<tr><td>成果不能如期交付</td><td>待交成果、原因、影响、主责真人角色及计划交付时间，提交中心真人负责人确认。</td><td>真人确认后，中心 Agent 记录延期及处理决定，在每个阶段结束时提醒中心真人负责人和责任角色，持续跟进到交付或明确处理；是否推进由中心真人负责人决定。</td></tr>
|
||||||
|
<tr><td>测试不通过但拟放行版本</td><td>原测试报告、不通过项与影响、待放行版本、放行范围及条件、遗留处理和项目／产品双方真人核实结论。</td><td>中心以双方明确核实结论作为放行依据，记录原测试结论、版本放行决定和后续安排；不将“不通过”改写成“通过”。</td></tr>
|
||||||
|
<tr><td>必需成果不适用／申请豁免</td><td>《成果豁免申请》：成果名称、适用依据、原因、事实、替代证据、影响和风险。</td><td>由中心真人负责人明确批准或拒绝。批准只满足该文件要求，测试结果确认、项目／产品版本放行核实及内部／外部验收仍按相应规则办理。</td></tr>
|
||||||
|
<tr><td>跳转、回退或暂缓</td><td>说明触发原因、当前缺失成果、影响、风险及补齐计划。</td><td>中心真人负责人明确决定；记录原状态、目标环节与约束，保留历史，不把跳过写成通过。</td></tr>
|
||||||
|
</tbody></table></div>
|
||||||
|
<div class="note"><strong>处理文件差异时：</strong>列出对象、版本、差异及影响，由有权真人明确采用口径。当前文件同步不证明历史审阅一致；不把另一型号、平台、构建或使用阶段的结论补到当前对象。已有有效确认、明确跳过的事项不恢复为前置，实质变化只补充受影响部分。</div>
|
||||||
|
<h3>成果与过程分开留档，记录逐条展示</h3>
|
||||||
|
<ul>
|
||||||
|
<li>中心维护项目概览、项目进度、阶段记录和成果索引，按正式成果和过程记录分区、分条更新。</li>
|
||||||
|
<li>正式成果目录及当前成果索引只登记真人完成并确认的最终成果及对应确认，不混入任务状态、草稿、旧版或推进决定。</li>
|
||||||
|
<li>中心 Agent 在过程记录中登记经真人确认的延期事项；阶段结束时分条提醒待交成果、责任人、约定日期与影响，交付后更新对应条目。</li>
|
||||||
|
<li>任务、输入基线、提交过程、退回、阻塞、中心决定和下一步进入过程记录；旧版、草稿及历史确认也在过程记录中保留。</li>
|
||||||
|
<li>外部链接成果登记真实完整入口及对应确认，不强制重复下载；本地已取得有效资料的复制归档按项目授权办理，保留来源与映射，不能只用概括目录代替有效成果。</li>
|
||||||
|
<li>同一有效成果不重复制作或确认；新版经真人确认后更新最终成果条目，旧版移入过程记录并保留替代关系，不删除历史。</li>
|
||||||
|
<li>不适用、未执行、失败、延期和豁免分别说明；未验证内容不写为通过。模拟材料和真实结果分开，模拟完成不代表发布、客户验收或生产就绪。</li>
|
||||||
|
</ul>
|
||||||
|
<p class="small">预算、采购、对外承诺和暂停／取消等业务授权仍由业务负责；产品只确认明确授权范围内的具体资源／排期事项，中心真人统筹项目总排期与协调。中心真人负责项目推进与成果豁免，不能借推进决定代替其他必要授权。</p>
|
||||||
|
<a class="back" href="#top">返回顶部 ↑</a>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section class="section" id="templates">
|
||||||
|
<div class="kicker">可直接用于各阶段</div><h2>任务与阶段记录的分条格式</h2>
|
||||||
|
<p>各栏目均用列表逐条填写，一条表达一个事项；有多个字段时逐项列子条目。不要求复杂 JSON，不增加独立审批文件。</p>
|
||||||
|
<div class="table-wrap"><table class="template"><caption>中心下发任务</caption><thead><tr><th>栏目</th><th>需要写清的内容</th></tr></thead><tbody>
|
||||||
|
<tr><td>阶段与任务</td><td><ul><li>当前阶段、任务目标、唯一主责真人角色及必要协作角色。</li></ul></td></tr>
|
||||||
|
<tr><td>输入与范围</td><td><ul><li>有效资料、版本及位置；</li><li>本阶段必须完成、后续处理和当前不需要的内容。</li></ul></td></tr>
|
||||||
|
<tr><td>交付与时间</td><td><ul><li>正式成果或成果包、最低结果内容、必需／选填划分、完成时间和下游用途。</li></ul></td></tr>
|
||||||
|
<tr><td>完成条件</td><td><ul><li>能够按结果判断的条件；</li><li>须提交的专业结论及授权，不列内部操作检查清单。</li></ul></td></tr>
|
||||||
|
<tr><td>执行中反馈</td><td><ul><li>只有影响任务完成的阻塞或需中心决定的变更及时提交；</li><li>其他工作由真人自行组织。</li></ul></td></tr>
|
||||||
|
</tbody></table></div>
|
||||||
|
<h3>中心聊天中的阶段成果汇报</h3>
|
||||||
|
<ul>
|
||||||
|
<li><strong>概况：</strong>项目、阶段、汇报日期、全部确认完成／部分完成／已交待确认、本次需决定事项。</li>
|
||||||
|
<li><strong>成果：</strong>逐项列任务／成果、主责真人、必需／选填、实际状态、已交版本与全部有效文件入口、确认人／时间／范围／条件。</li>
|
||||||
|
<li><strong>遗留：</strong>逐项列状态、责任、原计划／当前计划、原因／依赖、影响、必须完成阶段和补齐或承接建议；选填未交、豁免／取消分别说明。</li>
|
||||||
|
<li><strong>时间与记录：</strong>任务提交、确认后实际完成、阶段管理日期分别记；引用完整原记录，突出改期和相对上次汇报的实质变化。</li>
|
||||||
|
<li><strong>请中心决定：</strong>接受哪些结果、推进／补充／退回／暂缓或结项关闭、遗留处理建议；决定未取得时写待明确。</li>
|
||||||
|
</ul>
|
||||||
|
<h3>角色工时与研发／测试衔接记录</h3>
|
||||||
|
<div class="table-wrap"><table class="template"><thead><tr><th>栏目</th><th>记录内容</th></tr></thead><tbody>
|
||||||
|
<tr><td>角色与范围</td><td>角色、唯一主责真人、工作项、需求及输入版本、已有成果与剩余工作。</td></tr>
|
||||||
|
<tr><td>工时</td><td>原估／当前估、单位、投入及人数、本人提交／确认日期、来源、状态；真实实际工时另记。</td></tr>
|
||||||
|
<tr><td>周期</td><td>初版单列；初版后的各轮内容、开发／自测／修复、独立测试／回归、起算条件、投入和外部等待分别说明。</td></tr>
|
||||||
|
<tr><td>核实与交接</td><td>技术负责人核实人／日期、对象版本、范围、依赖及结论；交测试的版本／范围／渠道和实际接收；测试衔接及资源要求。</td></tr>
|
||||||
|
<tr><td>变更与日期</td><td>旧值、新值、原因、影响及真人确认；中心统筹确定的有效日期及依据。估算、资源承诺和实际完成分别记。</td></tr>
|
||||||
|
</tbody></table></div>
|
||||||
|
<h3 id="schedule-template">项目预排期：八列格式</h3>
|
||||||
|
<p>模板预排日期保持为空。实际编制时按本项目真实工作填写，不套用其他项目日期、任务数量或工时；未知写待评估／待确认。下表只展示列结构。</p>
|
||||||
|
<div class="table-wrap"><table><caption>预排期与实际执行主表</caption><thead><tr><th>里程碑</th><th>工作项</th><th>预排开始日期</th><th>预排结束日期</th><th>预排工时/人时</th><th>负责角色</th><th>参与人数</th><th>实际执行情况</th></tr></thead><tbody><tr><td> </td><td> </td><td> </td><td> </td><td> </td><td> </td><td> </td><td> </td></tr></tbody></table></div>
|
||||||
|
<p class="small">每项任务唯一主责真人、完成条件、原估／当前估和改期依据沿原任务记录维护；参与人数不再乘工时。“实际执行情况”按真实回报登记进展、时间、成果／版本／入口、确认、偏差及下一步，不把空白或待登记当作未开工／未完成。</p>
|
||||||
|
<h3>结项归档成果目录与阶段日期</h3>
|
||||||
|
<p>作为《结项资料归档》的一部分，按阶段和成果逐项提供有效入口及日期；可参照以下字段。项目选择单工作表 Excel 时，在同一表中逐项登记；其他格式按项目明确要求执行。</p>
|
||||||
|
<div class="table-wrap"><table class="template"><thead><tr><th>栏目</th><th>参考字段</th></tr></thead><tbody>
|
||||||
|
<tr><td>阶段管理</td><td>阶段名称、开始日期、完成日期、当前状态、起止决定及依据；进行中时完成日期留空。</td></tr>
|
||||||
|
<tr><td>成果与入口</td><td>成果名称、文件名／入口用途、版本／对象、成果状态、完整可点击路径／地址及类型。</td></tr>
|
||||||
|
<tr><td>提交与确认</td><td>成果提交、正式采用、真人确认日期及记录、确认人、来源、范围／条件；实际工程发生日期另列。</td></tr>
|
||||||
|
<tr><td>说明与变化</td><td>缺项与待办、实际后续安排、正式路径与原交接映射；已有包内资料沿有效索引，不重复展开。</td></tr>
|
||||||
|
</tbody></table></div>
|
||||||
|
<h3>阶段记录：正式成果及确认记录</h3>
|
||||||
|
<ul>
|
||||||
|
<li><strong>最终成果：</strong>每项成果独立列出。
|
||||||
|
<ul>
|
||||||
|
<li>成果名称。</li>
|
||||||
|
<li>真人完成并确认的最终版本。</li>
|
||||||
|
<li>文件位置；通过链接交付或成果中含有链接时，记录链接地址即可。</li>
|
||||||
|
</ul>
|
||||||
|
</li>
|
||||||
|
<li><strong>真人确认：</strong>每项确认独立列出，并关联对应最终成果。
|
||||||
|
<ul>
|
||||||
|
<li>确认人。</li>
|
||||||
|
<li>确认时间。</li>
|
||||||
|
<li>对应成果及版本。</li>
|
||||||
|
<li>确认结论。</li>
|
||||||
|
<li>确认范围与附带条件。</li>
|
||||||
|
</ul>
|
||||||
|
</li>
|
||||||
|
</ul>
|
||||||
|
<h3>阶段记录：过程记录</h3>
|
||||||
|
<ul>
|
||||||
|
<li><strong>任务与输入：</strong>分别列任务要求、主责真人角色、输入基线和交付时间。</li>
|
||||||
|
<li><strong>逐任务汇总：</strong>每个任务单列成果（应交、已交、版本与位置）、完成情况和真人确认情况，并关联原任务记录。</li>
|
||||||
|
<li><strong>完成与时间：</strong>分别列已完成项、未完成项、原计划完成时间、当前计划完成时间及提交后真人确认的实际完成时间；提交与确认时间分别保留，改期不覆盖原计划。</li>
|
||||||
|
<li><strong>历史资料：</strong>分别列旧版成果、草稿、历史确认与版本替代关系，保留原资料。</li>
|
||||||
|
<li><strong>评审与修订：</strong>每条意见、修改、退回原因与处理结论分别记录。</li>
|
||||||
|
<li><strong>延期、阻塞与风险：</strong>每个事项单列，子项分别写原因、影响范围、责任人、原计划与当前计划日期、必须完成的阶段、真人确认和阶段结束提醒情况；跨阶段引用原记录并持续显示在项目层。</li>
|
||||||
|
<li><strong>中心决定：</strong>每次推进、补充、退回或暂缓决定单列，子项分别写决定人、时间、依据、适用范围和理由。</li>
|
||||||
|
<li><strong>版本放行：</strong>测试不通过而放行时，分条关联原测试结论、项目／产品双方核实结论、版本、放行范围与条件。</li>
|
||||||
|
<li><strong>Bug 双方确认：</strong>逐项列问题、对象／版本、实际处置状态、中心及产品各自确认人／时间／结论／条件、来源与后续安排；过程分歧和最终确认分开。</li>
|
||||||
|
<li><strong>阶段与关闭：</strong>实际启用／结束或关闭决定日期及依据、状态同步、有效成果锁定和停止重复催办情况；群总结及实际发送结果另记。</li>
|
||||||
|
<li><strong>下一步：</strong>每项任务或待办单列，子项分别写主责真人角色、期限、依赖和承接安排。</li>
|
||||||
|
</ul>
|
||||||
|
<div class="note"><strong>成果确认与推进决定分开保存。</strong>真人对最终成果的确认保留在正式成果确认记录中；中心是否推进、为什么推进以及后续安排列入过程记录。阶段 6 的测试成果确认保留为对应正式确认，测试不通过后的核实与放行决定列入过程记录。</div>
|
||||||
|
<div class="note"><strong>确认的是任务结果和推进条件。</strong>真人角色对专业工作与提交负责，中心真人负责人对推进决定负责；角色 Agent 的参与方式不成为阶段完成条件。</div>
|
||||||
|
<a class="back" href="#top">返回顶部 ↑</a>
|
||||||
|
</section>
|
||||||
|
</main>
|
||||||
|
<footer>Codex 多角色项目推进总流程图 · V2.1 · 2026-10-20 编制<br>依据《流程更新》截至 2026-10-20 的已确认规则及本轮实施口径整合。固定路径维护当前流程，历史由 Git 保留；仓库更新与配置部署、在途项目采用分别办理。</footer>
|
||||||
|
</body>
|
||||||
|
</html>
|
||||||
@@ -2,7 +2,7 @@
|
|||||||
|
|
||||||
登记日期：2026-09-08。根据用户提供的 `D:/AI全流程辅助/项目推进总流程` 只读学习，供后续资料生成和审核时按需查阅。
|
登记日期：2026-09-08。根据用户提供的 `D:/AI全流程辅助/项目推进总流程` 只读学习，供后续资料生成和审核时按需查阅。
|
||||||
|
|
||||||
流程依据：[V1.0 总流程图](../Codex多角色项目推进总流程图-V1.0.html)。本参考不是新流程基线，不改变 Skill、Hook、角色职责或门禁，也不表示已部署或推送。
|
本页及所链接笔记保留 2026-09-08 的 V1.0 学习事实和当时口径，供查找源资料、复用栏目；其中旧的必交成果、确认链和流程编号不作为当前规则。当前依据为 [V2.0 总流程图](../Codex多角色项目推进总流程图.html) 与 [中心成果规则](../../ep-hub/references/project-lifecycle.md)。特别是阶段六现不要求缺陷清单或零缺陷清单，缺陷链接选填；角色内部流程由对应真人安排。以下历史记录不代表部署状态。
|
||||||
|
|
||||||
## 先读什么
|
## 先读什么
|
||||||
|
|
||||||
@@ -65,6 +65,6 @@
|
|||||||
- 应用包里的高低版本可用于升级测试；自测表明确要求高低版本。应区分测试配套版本与唯一最终提测版本，不能仅凭两个版本文件名就判错。
|
- 应用包里的高低版本可用于升级测试；自测表明确要求高低版本。应区分测试配套版本与唯一最终提测版本，不能仅凭两个版本文件名就判错。
|
||||||
- V1.0 灯态描述的“绑定”改“配网”不意味着把平台账号绑定、解绑等实际业务术语全局替换。
|
- V1.0 灯态描述的“绑定”改“配网”不意味着把平台账号绑定、解绑等实际业务术语全局替换。
|
||||||
|
|
||||||
## 本次未做的事
|
## 维护与执行边界
|
||||||
|
|
||||||
没有修改、移动或删除原始模板；没有修改 V0.15、V0.16、V1.0 HTML、Skill、Hook 或已安装缓存；没有执行烧录/SDK/模板脚本、外部下载、真实通知或项目审批；没有 Git 提交、推送或合并。所有本次新增内容仅为本地参考笔记与源文件索引。
|
这里只维护参考笔记和源文件索引，不包含原始模板；源目录是登记时的来源，不保证在其他设备可访问。后续直接更新当前文件，通过 Git 保留历史，不另建日期或版本目录。参考资料不授权执行烧录、SDK 或模板脚本、外部下载、真实通知、项目审批，也不会自动修改 Etunel 配置或已安装缓存。
|
||||||
File renamed without changes.
@@ -1,6 +1,6 @@
|
|||||||
# 阶段 6 模板只读学习记录
|
# 阶段 6 模板只读学习记录
|
||||||
|
|
||||||
核对日期：2026-09-08。源目录：`D:/AI全流程辅助/项目推进总流程/6、测试验证`。下文路径均相对于源目录。流程基准为 `D:/codex/EP-Hub-Skill-v015-release/doc/20260908/Codex多角色项目推进总流程图-V1.0.html`。
|
核对日期：2026-09-08。源目录：`D:/AI全流程辅助/项目推进总流程/6、测试验证`。下文路径均相对于源目录。流程基准为[当前 V1.0 总流程图](../Codex多角色项目推进总流程图.html)。
|
||||||
|
|
||||||
## 阅读范围与边界
|
## 阅读范围与边界
|
||||||
|
|
||||||
File renamed without changes.
File renamed without changes.
@@ -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)；实际调用时再读其脚本用法 |
|
||||||
|
|
||||||
|
## 本轮输出
|
||||||
|
|
||||||
|
用简洁中文逐条说明已确认进展、需要处理或决定的事项、遗留及影响。先更新事实记录，再主动在中心会话汇报阶段结果；只更新文件不算汇报。需要真人查看时逐项提供本次全部有效成果入口。再依据授权交接、推进或通知。未知的负责人、时间、确认与影响如实标明，不能为补齐格式编造事实，也不把一次问答变成新的交付文件。
|
||||||
@@ -0,0 +1,4 @@
|
|||||||
|
interface:
|
||||||
|
display_name: "项目中心"
|
||||||
|
short_description: "按八阶段管理交付、真人确认、跨阶段遗留与成果留档，生成项目通知"
|
||||||
|
default_prompt: "使用 $ep-hub 根据项目现有记录整理当前阶段、交付成果和需要真人决定的事项，并更新项目进度。"
|
||||||
@@ -0,0 +1,51 @@
|
|||||||
|
# 任务记录
|
||||||
|
|
||||||
|
> 填写指引：标题改为明确的任务名称，紧接一句当前情况。前部维护最新事实，关键历史按时间追加；内部执行步骤由角色真人自行安排。
|
||||||
|
|
||||||
|
## 当前情况
|
||||||
|
|
||||||
|
- **任务状态**：按真实情况填写；提交未确认时为“待确认”。
|
||||||
|
- **主责真人**：记录姓名和角色；协作者按需要另列。
|
||||||
|
- **所属阶段**：记录任务原所属阶段。
|
||||||
|
- **原计划完成时间**：保留首次确认的期限。
|
||||||
|
- **当前计划完成时间**：记录最近一次经确认的有效期限。
|
||||||
|
- **实际完成时间**：任务提交后经对应真人明确确认完成的时间；尚未确认时写“尚未确认完成”。
|
||||||
|
- **必须完成的阶段**：记录已确认安排。
|
||||||
|
- **开始时间**：有约定时分别保留原计划、当前计划与实际开始时间。
|
||||||
|
|
||||||
|
## 任务要求
|
||||||
|
|
||||||
|
- **目标**：说明可独立判断的交付结果。
|
||||||
|
- **输入资料**：逐条列有效资料、版本与实际位置。
|
||||||
|
- **处理范围**：区分本阶段必须完成、后续处理与当前不需要。
|
||||||
|
- **应交结果**：列成果或成果包、最低内容、必需／选填与下游用途。
|
||||||
|
- **完成条件**：列结果要求、必要真人确认与授权，沿用已有约定。
|
||||||
|
- **依赖**：只列影响当前执行或交接的输入与条件。
|
||||||
|
|
||||||
|
## 成果与确认
|
||||||
|
|
||||||
|
- **接收情况**：记录真人实际接收时间及依据；只有发送证据时标为接收待确认。
|
||||||
|
- **提交情况**：每次提交单列提交人、时间、成果版本和完整入口、用途；本人说明其他渠道已提交时据实登记，入口缺失、接收待确认与验收待确认分别列出。
|
||||||
|
- **完成情况**：说明已完成、未完成部分及具体缺口。
|
||||||
|
- **确认情况**：每项单列确认人、真实确认时间、任务／成果及版本、结论、范围和条件。
|
||||||
|
- **确认来源**：记录直接确认或线下转述；转述保留实际确认人、转述人、来源及补录时间。
|
||||||
|
- **采用与存放调整**：适用时分别记录采用对象和日期、本地复制授权、原路径到正式路径映射及操作日期，不覆盖原提交或确认日期。
|
||||||
|
|
||||||
|
需要评估时在此嵌入 [工时与周期栏目](工时与周期评估.md)；涉及 Bug 时沿原问题／共用记录保留中心先确认、产品再次确认的 [字段与历史](../../references/exceptions-and-decisions.md#bug-处理与双方最终确认)。生成实际项目记录时仅保留适用内容和真实入口，不将模板链接当项目事实。
|
||||||
|
|
||||||
|
## 下一步与影响
|
||||||
|
|
||||||
|
- **下一步**：写清谁需要做什么、需要谁作出什么决定。
|
||||||
|
- **延期或阻塞**：写明事实、原因及是否超过原计划／当前计划。
|
||||||
|
- **影响范围**：列受影响任务、成果、阶段或对外节点；未知写待确认。
|
||||||
|
- **处置或承接**：保留有权真人决定、期限与必须完成阶段，取消／豁免不写为实际完成。
|
||||||
|
|
||||||
|
## 关键历史
|
||||||
|
|
||||||
|
### 事件时间与名称
|
||||||
|
|
||||||
|
- **参与人**：记录实际执行、提交或作出决定的人。
|
||||||
|
- **发生了什么**：记录接收、提交、退回、确认、改期、变更或重开。
|
||||||
|
- **变化前后**：涉及日期、版本、范围变化时保留旧值与新值。
|
||||||
|
- **依据与原因**：记录有效来源、真人结论及原因。
|
||||||
|
- **影响及后续**：说明受影响范围和下一步，不复制内部操作或完整聊天记录。
|
||||||
@@ -0,0 +1,35 @@
|
|||||||
|
# 工时与周期评估栏目
|
||||||
|
|
||||||
|
> 使用指引：仅在需要评估时嵌入原任务记录；按真实工作项展开，不另建一套任务。先列已交接的全部有效需求文件和版本入口。各角色内部执行方法自行决定。
|
||||||
|
|
||||||
|
## 工作范围
|
||||||
|
|
||||||
|
- **主责真人／角色**：填写已确认分工。
|
||||||
|
- **需求输入**：逐项列全部有效文件、版本和入口。
|
||||||
|
- **已有成果与剩余工作**：分别说明。
|
||||||
|
- **未估项**：说明缺什么信息及受影响部分；不能把未知填零。
|
||||||
|
|
||||||
|
## 工作项评估
|
||||||
|
|
||||||
|
| 工作项／初版或轮次 | 主责真人 | 原估值及单位 | 当前估值及单位 | 周期及起算条件 |
|
||||||
|
| --- | --- | --- | --- | --- |
|
||||||
|
| 按真实工作项填写 | 按实际分工填写 | 保留首次评估 | 保留有效评估 | 周期与人时分开 |
|
||||||
|
|
||||||
|
### 对应工作项的条件与依据
|
||||||
|
|
||||||
|
- **投入与人数**：记录可投入情况及资源是否已确认。
|
||||||
|
- **外部等待**：单列条件、等待周期及来源。
|
||||||
|
- **提交**：实际提交人、时间、版本及入口。
|
||||||
|
- **确认**：确认人、时间、对象、结论、适用范围及来源。
|
||||||
|
- **当前状态**：区分已估、待补充、待确认及已确认。
|
||||||
|
- **评估变更**：保留旧值、新值、原因和真人确认，关联原任务关键历史。
|
||||||
|
|
||||||
|
初版单列，后续迭代不包含初版。开发／自测／修复、独立测试／回归和外部等待分别记录。工作日不直接换算成人日或小时。
|
||||||
|
|
||||||
|
## 技术核实与测试衔接
|
||||||
|
|
||||||
|
- **技术核实**：记录技术负责人、真实日期、核实的对象及版本、范围／依赖和结论，引用原任务已有有效确认。
|
||||||
|
- **交给测试**：记录实际交接日期、版本、范围及渠道。
|
||||||
|
- **测试接收与衔接**：记录实际接收人、时间和依据，以及初版、各轮、回归的周期与资源衔接结论；未知部分标明待确认。
|
||||||
|
|
||||||
|
沿用已有确认和接收记录，仅补实际缺口，不为此重批评估或另建交接文件。
|
||||||
@@ -0,0 +1,12 @@
|
|||||||
|
# 当前正式成果索引
|
||||||
|
|
||||||
|
> 填写指引：按阶段逐项列出真人完成并确认的当前最终成果。任务状态、草稿、旧版、延期和推进决定在过程记录中维护。
|
||||||
|
|
||||||
|
## 阶段名称
|
||||||
|
|
||||||
|
### 成果名称
|
||||||
|
|
||||||
|
- **当前最终版本**：记录实际有效版本。
|
||||||
|
- **位置与用途**：逐项登记全部有效原件／包、配套资料或真实完整外部入口与用途；包内容可引用有效索引，不强制复制外部内容。
|
||||||
|
- **确认记录**：链接对应阶段的正式确认栏目，确认详情由那里统一维护。
|
||||||
|
- **存放调整**：适用时关联本地复制授权、原位置与正式位置映射、操作日期；不改原提交、采用或确认时间。
|
||||||
@@ -0,0 +1,32 @@
|
|||||||
|
# 结项资料归档
|
||||||
|
|
||||||
|
> 使用指引：作为既有《结项资料归档》的内容结构，沿用项目已确认格式，不新增第五类结项成果。以下说明替换为真实资料与依据。
|
||||||
|
|
||||||
|
## 归档范围
|
||||||
|
|
||||||
|
- **项目与范围**：明确实际采用的版本和本次整理范围。
|
||||||
|
- **当前成果索引**：关联项目唯一成果索引。
|
||||||
|
|
||||||
|
## 各阶段有效资料
|
||||||
|
|
||||||
|
### 阶段名称
|
||||||
|
|
||||||
|
- **管理开始日期与依据**：中心真人实际启用；条件授权时记录实际切换。
|
||||||
|
- **管理完成日期与依据**：明确结束／下一阶段决定；条件授权交接取实际切换日期，阶段八为关闭日期，进行中留空。
|
||||||
|
- **工程实际日期**：按实际需要分别记录开发、测试和验收日期及来源。
|
||||||
|
|
||||||
|
#### 成果名称
|
||||||
|
|
||||||
|
- **有效版本与用途**：列每项成果、配套资料及包内容；一包多成果可引用有效内容索引。
|
||||||
|
- **完整入口**：已保存原件／包的实际路径，或真实完整外部地址；不能只列概括目录。
|
||||||
|
- **提交与采用**：分别记录真人、日期、对象、范围及依据。
|
||||||
|
- **最终确认**：记录确认人、真实日期、对象版本、结论、范围与条件。
|
||||||
|
- **原任务及过程记录**：关联原任务、旧版和历史确认。
|
||||||
|
- **本地复制或地址调整**：适用时记录授权、原路径与现路径映射、操作日期；不得覆盖原提交、采用、确认或完成时间。
|
||||||
|
|
||||||
|
## 关闭及承接
|
||||||
|
|
||||||
|
- **Bug 处理与承接**：引用原报告／共用记录中的中心和产品双方最终确认，保留未修复事实与后续责任。
|
||||||
|
- **其他遗留**：逐项列状态、责任、原计划、当前计划、影响及必须完成阶段。
|
||||||
|
- **业务结项确认与中心关闭决定**：分别列真人、日期、原话、范围、条件和依据。
|
||||||
|
- **关闭后登记**：记录概览、进度、阶段、原任务、索引、报告与汇总的同步情况，以及有效成果锁定和停止重复催办情况。
|
||||||
@@ -0,0 +1,33 @@
|
|||||||
|
# 阶段成果汇报
|
||||||
|
|
||||||
|
> 使用指引：可直接作为中心聊天的汇报结构；也可写入阶段过程记录。不新增正式成果要求。将以下说明替换为真实事实。
|
||||||
|
|
||||||
|
## 当前阶段
|
||||||
|
|
||||||
|
- **项目与汇报日期**：记录项目名称和本次真实汇报日期。
|
||||||
|
- **阶段与状态**：记录阶段编号、名称、当前情况及管理开始／完成日期；进行中完成日期留空。
|
||||||
|
- **本轮需要决定**：说明推进、补充、退回、暂缓或承接的具体事项。
|
||||||
|
|
||||||
|
## 逐项任务与成果
|
||||||
|
|
||||||
|
### 任务名称
|
||||||
|
|
||||||
|
- **主责真人与完成情况**：记录实际负责人、完成部分和未完成部分。
|
||||||
|
- **应交成果**：逐项列必需／选填及适用条件。
|
||||||
|
- **已交成果**：每份单列名称、版本、确认用途和完整可点击入口；同一成果包可引用有效内容索引。
|
||||||
|
- **确认情况**：逐项列确认人、真实时间、对象、结论、范围、条件和来源；缺失确认单列。
|
||||||
|
- **时间**：分别列原计划、当前计划、提交时间和提交后真人确认的实际完成时间。
|
||||||
|
- **原任务记录**：引用唯一原记录。
|
||||||
|
|
||||||
|
## 未完成与待确认
|
||||||
|
|
||||||
|
- **事项**：每项单列状态、原因、依赖、主责、原计划、当前计划、影响及必须完成阶段。
|
||||||
|
- **需要的决定**：列已有安排、建议和待决定内容，分别标明。
|
||||||
|
|
||||||
|
确实没有时写“未完成项：无；待确认项：无”。资料不足时说明待核实部分。
|
||||||
|
|
||||||
|
## 下一步安排
|
||||||
|
|
||||||
|
- **建议**：按当前事实提出下一步。
|
||||||
|
- **已有决定或条件授权**：记录真人、原话、日期、范围与条件；条件满足及实际切换日期另记。
|
||||||
|
- **仍待决定**：列需要谁确认什么，以及确认后的动作。
|
||||||
@@ -0,0 +1,62 @@
|
|||||||
|
# 阶段记录
|
||||||
|
|
||||||
|
> 填写指引：标题改为阶段编号与名称，紧接一句当前情况。下面两个栏目分别保存最终成果和任务过程；每个任务都要逐项汇总。
|
||||||
|
|
||||||
|
- **阶段状态**：记录未开始、进行中、待确认、已完成或实际例外状态。
|
||||||
|
- **管理开始日期与依据**：中心真人实际启用日期；条件授权时取实际切换日期。
|
||||||
|
- **管理完成日期与依据**：明确结束或进入下一阶段的决定日期；条件授权交接取实际切换日期，阶段八取明确关闭日期，进行中留空。
|
||||||
|
- **工程实际日期**：按实际需要另记开发、测试和验收日期，不以管理日期计算工程延期或人时。
|
||||||
|
- **当前情况**：概括本阶段完成到哪里。
|
||||||
|
|
||||||
|
## 正式成果及确认记录
|
||||||
|
|
||||||
|
### 最终成果
|
||||||
|
|
||||||
|
- **成果名称**：每项最终成果独立列出。
|
||||||
|
- **最终版本**：记录真人完成并确认的当前有效版本。
|
||||||
|
- **保存位置与用途**：逐项给全部有效文件、配套资料或包内有效索引的完整实际入口及用途；不能只列总目录。
|
||||||
|
- **提交与采用**：分别记录实际日期、对象和来源；复制或补地址日期另记。
|
||||||
|
|
||||||
|
### 对应真人确认
|
||||||
|
|
||||||
|
- **确认人**：记录实际作出确认的人。
|
||||||
|
- **确认时间**：记录真实时间。
|
||||||
|
- **成果与版本**：明确此次确认的对象。
|
||||||
|
- **结论**：记录真实确认结论。
|
||||||
|
- **范围和条件**：保留适用范围与附带条件。
|
||||||
|
- **来源**：链接已有依据；转述时注明转述人、来源与补录时间。
|
||||||
|
|
||||||
|
## 过程记录
|
||||||
|
|
||||||
|
### 任务名称
|
||||||
|
|
||||||
|
- **负责人**：记录主责真人。
|
||||||
|
- **成果情况**：分条说明应交、已交、版本和位置；待确认稿不能列为正式最终成果。
|
||||||
|
- **完成情况**：说明任务状态、已完成与尚缺部分。
|
||||||
|
- **确认情况**：列已确认人、时间、对象、结论和未完成的必要确认。
|
||||||
|
- **原计划完成时间**：记录首次期限。
|
||||||
|
- **当前计划完成时间**：记录最新有效期限。
|
||||||
|
- **实际提交时间**：记录本人提交事实与来源；线下已交但入口缺失时分别说明。
|
||||||
|
- **实际完成时间**：任务提交后经真人明确确认完成的时间；未确认写“尚未确认完成”。
|
||||||
|
- **影响及下一步**：列责任、动作、必须完成的阶段及跨阶段承接。
|
||||||
|
- **任务原记录**：链接该任务的唯一记录。
|
||||||
|
|
||||||
|
### 阶段决定与未完成事项
|
||||||
|
|
||||||
|
- **决定**：每次单列决定人、时间、推进／补充／退回／暂缓结论、依据、范围和理由。
|
||||||
|
- **条件授权**：适用时分别记原授权日期、原话、条件、条件实际满足日期与依据、实际切换日期；不倒填已推进。
|
||||||
|
- **未完成事项**：逐项引用原任务，列原计划、当前计划、必须完成阶段、影响、承接与阶段结束提醒情况。
|
||||||
|
- **历史资料**：链接旧版、草稿、历史确认及替代关系。
|
||||||
|
|
||||||
|
### 汇报与通知
|
||||||
|
|
||||||
|
- **中心会话汇报**：记录本次汇报时间、涉及任务与成果、未完成／待确认事项及待决定内容。
|
||||||
|
- **群总结**：记录对应交接或关闭决定、已发送正文及实际结果；区分未发送、请求已接受、送达和已读，只写有依据的状态。
|
||||||
|
- **补充汇报**：仅实质变化时补充受影响内容；核对前次记录避免重复通知同一次交接。
|
||||||
|
|
||||||
|
### 关闭后登记（阶段八适用）
|
||||||
|
|
||||||
|
- **Bug 双方确认**：引用原问题或共用记录中的最终确认与分歧历史。
|
||||||
|
- **关闭决定**：记录中心真人、真实日期、原话、范围和条件，业务结项确认另列。
|
||||||
|
- **同步与锁定**：记录项目概览、进度、原任务、索引、报告和汇总同步情况，以及有效成果锁定情况。
|
||||||
|
- **停止催办与后续**：停止已结束／已确认事项的重复催办；未完成承接和队列未送达分别记录。
|
||||||
@@ -0,0 +1,29 @@
|
|||||||
|
# 项目概览
|
||||||
|
|
||||||
|
> 填写指引：标题改为实际项目名称；以下栏目按已确认事实填写，生成项目记录时移除此指引。
|
||||||
|
|
||||||
|
## 项目目标与范围
|
||||||
|
|
||||||
|
- **项目目标**：说明要完成的结果。
|
||||||
|
- **本次范围**：说明纳入和已明确不纳入的内容。
|
||||||
|
- **有效流程基线**：记录已确认的基线及采用依据。
|
||||||
|
- **验收范围**：记录约定的内部、平台和客户验收范围；未确定的如实说明。
|
||||||
|
|
||||||
|
## 真人分工
|
||||||
|
|
||||||
|
- **中心负责人**：记录已确认姓名及权限范围。
|
||||||
|
- **相关角色**：每个角色单列真人负责人、负责结果与必要协作。
|
||||||
|
- **人员变化**：记录生效时间、交接事项及确认依据。
|
||||||
|
|
||||||
|
## 资料与协作入口
|
||||||
|
|
||||||
|
- **项目进度**：链接实际进度记录。
|
||||||
|
- **唯一计划主表**：链接已确认使用的实际主表；已有项目沿用，新项目默认使用 Excel。
|
||||||
|
- **成果索引**：链接当前有效成果索引。
|
||||||
|
- **资料来源**：列已提供的项目资料位置。
|
||||||
|
- **交接方式**：说明已确认的通信渠道、接收与提交方式。
|
||||||
|
|
||||||
|
## 项目关闭
|
||||||
|
|
||||||
|
- **关闭决定**：实际关闭后记录中心真人、日期、原话、范围、条件及依据；未关闭时不预填。
|
||||||
|
- **承接入口**：链接仍需跟进的原任务及当前进度，保留未完成状态。
|
||||||
Binary file not shown.
@@ -0,0 +1,36 @@
|
|||||||
|
# 项目进度
|
||||||
|
|
||||||
|
> 填写指引：标题使用实际项目名，先写一句当前进展；以下是栏目说明，生成记录时替换为真实事实。
|
||||||
|
|
||||||
|
## 当前阶段与整体进度
|
||||||
|
|
||||||
|
- **更新时间**：记录本次更新的时间。
|
||||||
|
- **当前阶段**：记录有效阶段编号、名称及推进依据。
|
||||||
|
- **唯一计划主表**：引用实际主表，本记录只维护阶段及当前事项摘要。
|
||||||
|
- **已完成阶段**：逐项列出，跳过或暂缓的单独说明。
|
||||||
|
- **关键成果**：说明已经完成、待确认和缺失的关键结果。
|
||||||
|
- **下一步**：说明待推进的工作及必要条件。
|
||||||
|
|
||||||
|
## 当前待处理事项
|
||||||
|
|
||||||
|
### 事项名称
|
||||||
|
|
||||||
|
- **所属阶段**：记录原任务阶段。
|
||||||
|
- **负责人**：使用已确认真人姓名与角色。
|
||||||
|
- **当前情况**：区分已完成部分、未完成部分与确认状态。
|
||||||
|
- **原计划完成时间**：记录首次确认的期限。
|
||||||
|
- **当前计划完成时间**：记录最新有效期限，未调整时沿用原计划。
|
||||||
|
- **必须完成的阶段**：使用已确认安排，未约定则写待确认。
|
||||||
|
- **延期情况**：分别说明原计划和当前计划是否超期，以及原因。
|
||||||
|
- **影响范围**：列受影响的成果、任务、阶段或对外节点。
|
||||||
|
- **下一步／待决定**：写清谁做什么或谁决定什么。
|
||||||
|
- **原记录**：链接任务原记录或已有问题系统中的事项。
|
||||||
|
|
||||||
|
## 已完成或已处置
|
||||||
|
|
||||||
|
- **事项**：每项单列完成或处置结论、真人及时间、原记录入口；仍有后续跟进的继续保留在当前事项中。
|
||||||
|
|
||||||
|
## 关闭决定与后续
|
||||||
|
|
||||||
|
- **决定依据**：实际关闭后引用中心真人、真实日期、原话、范围及条件。
|
||||||
|
- **承接事项**：沿原责任与计划在当前事项中持续跟进，不把关闭写成全部 Bug 已修复或测试通过。
|
||||||
@@ -0,0 +1,49 @@
|
|||||||
|
# 成果与真人确认
|
||||||
|
|
||||||
|
用于提交、接收、完成确认和版本替换。阶段特有的确认人按 [八阶段与结果要求](project-lifecycle.md)，不把中心真人确认推广为所有专业成果的重复审批。
|
||||||
|
|
||||||
|
## 分清事实
|
||||||
|
|
||||||
|
| 事实 | 如何记录 |
|
||||||
|
| --- | --- |
|
||||||
|
| 已发出任务或资料 | 记录发送渠道和时间；没有接收依据时，接收待确认 |
|
||||||
|
| 真人已接收 | 记录实际接收人、时间、任务或成果版本及依据 |
|
||||||
|
| 已提交成果 | 记录提交人、时间、版本与位置，完成确认尚缺时为“待确认” |
|
||||||
|
| 真人确认成果或任务完成 | 记录确认人、时间、对象及版本、结论、范围、条件与来源 |
|
||||||
|
| 同意推进或放行 | 在过程记录中单独记有权真人的决定；不替换成果本身结论 |
|
||||||
|
|
||||||
|
中心真人可在会话中明确转述线下接收、提交或确认事实。保留实际确认人、真实确认时间、对象、结论和范围，并注明转述人、来源及补录时间；缺失信息写待补充。不要求另做审批单、截图或重复确认，不能把转述者写成专业确认人。
|
||||||
|
|
||||||
|
本人明确已通过其他渠道提交时，登记已提交。资料入口未提供、接收人尚未确认可用、验收尚未取得结论是不同缺口，逐项记录；无聊天附件、Agent 本端无法读取或队列仍待投递不推翻线下提交事实。
|
||||||
|
|
||||||
|
## 供真人查看的成果
|
||||||
|
|
||||||
|
请求中心真人确认前，逐项列出本次范围内全部有效文件的名称、版本、确认用途和完整可点击地址，或直接展示文件。成果包可使用能逐项定位内容的有效索引；只给概括目录、摘要或中心确认记录不足以支持查看。
|
||||||
|
|
||||||
|
专业内容和接收可用性由相应真人判断。Agent 无法读取本地盘、共享盘或外部链接，只能说明本端访问失败，不能推定成果不存在、未提交或不兼容。不把下载、解包、截图、重算哈希设成固定前置条件。已有包身份和真实入口时交相关真人确认可用，仅补实际缺口，不要求重做或反复上传。
|
||||||
|
|
||||||
|
文件、需求或版本存在差异时，由有权真人决定采用的内容、对象、版本和范围。分别记录当前同步情况、历史实际审阅对象及差异对原结论的影响；不能补造历史审阅或把当前采用倒填为过去已审阅。
|
||||||
|
|
||||||
|
## 实际完成时间
|
||||||
|
|
||||||
|
**任务提交后，经对应真人明确确认该任务完成的时间，才是实际完成时间。**
|
||||||
|
|
||||||
|
- 提交时间、专业成果确认时间和任务完成确认分别记录，可引用同一条有效确认，避免重复审批。
|
||||||
|
- 任务条件需要多项确认时，以最后一项必要完成确认的真实时间为准；阶段推进决定另记，不延后已完成任务的时间。
|
||||||
|
- 已提交未确认写“待确认／尚未确认完成”；不能用提交时间、Agent 检查时间、Etunel 完成回执或补录时间代填。
|
||||||
|
- 退回后继续保留原任务及历次提交。重新提交获最终完成确认后记实际完成时间。
|
||||||
|
- 已完成任务因实质变化重开时，保留旧完成事实和重开原因；当前要求未确认完成前不沿用旧时间表示新版已完成。
|
||||||
|
- 取消、豁免、延期承接是处置结果，另记处置人和时间，不填为实际交付完成时间。
|
||||||
|
|
||||||
|
## 正式成果与历史
|
||||||
|
|
||||||
|
- 正式区保存真人完成并确认的全部有效成果和配套资料，每项一个当前有效版本。保存原件／包，或登记真实完整外部入口；确认另列确认人、时间、对象及版本、结论、范围和条件。概括目录或确认记录不能代替资料本身。
|
||||||
|
- 待确认稿、部分成果、候选固件、旧版及其历史确认进入过程区。任务记录关联所有提交，阶段正式栏目只列最终成果。
|
||||||
|
- 新版获真人确认后才替换当前条目；先保留旧文件、旧确认及替代关系到过程区，再更新正式记录，不能覆盖丢失历史。外部链接成果保留旧地址、版本、确认及替代关系；不额外下载快照，外部系统是否保留历史如实记录。
|
||||||
|
- 中心推进、豁免、版本放行、产品接收等事实放过程记录，引用相关正式成果。名为《变更记录》《流程闭环总结》的交付文档，在真人确认最终版后仍属于正式成果。
|
||||||
|
- 同一文件或连贯成果包可承载多个结果，不为凑名称拆造文件。名称含“草稿／预览”不自动否定真人已确认采用的正式地位；按实际确认判断，不为分区删改成果正文。
|
||||||
|
- 链接交付登记真实地址、用途、版本与确认；内容核实由真人负责，不强制复制、摘要、截图或可下载检查。项目明确授权本地复制时，把已取得且确认有效的原件和配套资料复制到对应阶段正式区，保留原交接记录及原路径到现路径的映射，更新索引到正式位置。
|
||||||
|
- 复制或补地址日期单独记录，不替换提交、采用、确认、实际完成或阶段日期；未取得的原件仍如实列缺口，不能写已归档。
|
||||||
|
- 实质变更、范围扩大或相反证据需要重新确认受影响部分；仅改存放位置、阶段引用或转述补录不自动触发重签。
|
||||||
|
|
||||||
|
测试“不通过”可被真人确认是实际测试结论，不能因版本获放行改成“通过”。测试结果确认、版本放行、阶段推进与外部验收分别保留。
|
||||||
@@ -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 不在脚本外追加重试循环。
|
||||||
@@ -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 不追加外层重试。登录失效交负责人恢复，不换身份或渠道；通知异常不阻塞主任务，也不递归发送异常通知。
|
||||||
@@ -0,0 +1,16 @@
|
|||||||
|
# 模板复用
|
||||||
|
|
||||||
|
仅在选择已有专业模板或历史样例时读取。中心维护的项目、阶段和任务模板见 [记录与留档](project-records.md)。
|
||||||
|
|
||||||
|
项目计划的默认 Excel 模板及维护规则见 [项目计划](project-planning.md)。已有主表沿用已确认格式。结项报告和汇总按项目已确认格式制作，单工作表 Excel 仅作参考；不因模板字段齐全就补造工时、轮次、评审、签名或确认。
|
||||||
|
|
||||||
|
- 从当前任务、有效流程基线、成果、平台／机型、SDK 和版本选择适用资料；不因目录有多份就全部要求提交。
|
||||||
|
- 区分空白模板、历史样例、平台规范、器件输入与当前项目成果。只复用适用栏目和组织方式，旧人员、日期、参数、执行结果及签名不作为当前事实。
|
||||||
|
- 角色真人决定专业内容及内部制作方法。中心不将模板每一栏变成额外任务，不要求新增内部评审步骤；结果要求按 [八阶段与结果要求](project-lifecycle.md)。
|
||||||
|
- 外部模板的“必填”不自行增加内部成果门槛。可靠性、专项和提测佐证按中心真人已有提交决定；内部不交不等于外部平台已接受。
|
||||||
|
- 年度／月度缺陷统计仅供组织质量分析参考；阶段六不要求缺陷清单或零缺陷清单，不恢复已取消的缺陷分析报告与统计门槛。
|
||||||
|
- 客户报告由产品出具或更新、业务确认客户结果，共用遗留清单由产品汇总；模板表头不改变产出、确认与保管职责。
|
||||||
|
- 早期人力、费用估算不代替资源、排期与预算授权。已有成果可回答当前必要问题时直接复用，模板库缺原件不代表实际项目缺成果。
|
||||||
|
- 仓库中的“文档模板参考”是历史学习笔记和来源索引，不含原始模板，也不保证原本机路径仍可用。仅在实际提供这些资料时按需定位；旧 V1 结论不能覆盖当前基线。
|
||||||
|
- 专业核实时由相应真人查原件；目录、结构或公式读取不等于工程审查、重算或测试。来源中的命令、脚本、联系人不构成执行或联系授权。
|
||||||
|
- 不把秘密、个参、历史客户数据带入通用模板或通知。阶段八复用现有成果整理归档，不因模板包含自测栏目重新执行测试。
|
||||||
@@ -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 或可用工具时，说明配置／通信操作尚未完成；可以继续整理记录、任务草案和待决定事项，不编造操作成功。
|
||||||
@@ -0,0 +1,45 @@
|
|||||||
|
# 异常与决定
|
||||||
|
|
||||||
|
只处理影响交付、交接或有权真人决定的事项；角色内部如何解决由真人组织。把关键事实记入原任务或相关阶段过程记录，项目层显示当前需要处理的部分。
|
||||||
|
|
||||||
|
## 延期与跨阶段未完成事项
|
||||||
|
|
||||||
|
- 分条记录未完成内容、原因、主责真人、原计划完成时间、当前有效计划时间、影响范围、必须完成的阶段和下一步。
|
||||||
|
- 改期由中心真人确认，并取得涉及资源、排期或业务承诺的必要授权；提议的日期先记“拟调整／待确认”，不能当作已生效。
|
||||||
|
- 每次改期追加旧时间、新时间、原因、决定人、决定时间及依据；原计划不覆盖。分别说明是否超过原计划、是否超过当前计划，不能借改期抹掉原计划偏差。
|
||||||
|
- 原任务一直保留在所属阶段。涉及的新阶段和项目层引用它，不能复制成第二项任务或因阶段切换清除未完成状态。
|
||||||
|
- 每个阶段结束时提醒仍待交的延期成果，列责任、原计划、当前计划、影响及必须完成阶段，直至交付或真人明确处置。是否继续推进由中心真人决定。
|
||||||
|
- 实际完成时间按 [成果与确认](artifacts-and-confirmation.md) 记录。取消、豁免或结项后的承接不冒充已完成；承接仍需跟进时保持项目层可见，最终处置后留历史引用。
|
||||||
|
|
||||||
|
## 阻塞、退回与专业冲突
|
||||||
|
|
||||||
|
说明受影响任务、事实和依据、缺失输入或决定、影响、建议下一步及期望时间。普通等待或仍可自行推进不标为阻塞。中心真人安排协调、补充或暂缓，只影响相关任务。
|
||||||
|
|
||||||
|
提交不满足条件时列出具体缺口，保留有效成果；退回记录包含原版本、原因和补充要求。专业分歧由相关真人讨论；无法解决时呈现分歧与证据，由有权真人决定，中心 Agent 不替代专业结论。
|
||||||
|
|
||||||
|
## 变更、豁免、跳转与放行
|
||||||
|
|
||||||
|
- **改变基线**：记录《变更申请》所需的旧基线、拟变更内容、原因、范围、版本、成本／排期／质量影响及建议。可使用已有记录承载，按权限取得产品、业务或专业结论，记录生效范围及后续任务。
|
||||||
|
- **必需成果不适用或豁免**：提供成果名称、适用依据、原因、事实、替代证据、影响及风险，由中心真人明确批准或拒绝。只处理对应成果要求，不替代测试确认、版本放行或外部验收。选填未交无需申请豁免。
|
||||||
|
- **跳转、回退、暂缓**：记录原状态、目标阶段、缺失成果、原因、风险及补齐安排，取得中心真人决定及其他必要授权。暂停／取消等业务授权由业务负责，不能借阶段决定越权。
|
||||||
|
- **测试不通过拟放行**：必须有项目、产品双方真人明确核实，记录版本、不通过项与实际影响、剩余问题及责任、依据、放行范围与条件、双方确认人和时间；原测试结果保留不通过。实质变化重新核实。
|
||||||
|
|
||||||
|
未知影响不写“无影响”，未知责任或日期不编造；汇总为需要真人决定的具体问题。已有明确停止事项、暂不修复或无需新增清单等条件必须沿用，不借汇报重新分配。
|
||||||
|
|
||||||
|
## Bug 处理与双方最终确认
|
||||||
|
|
||||||
|
结项前对全部 Bug 的处理或承接核对双方确认，包含此前已处理及后续发现的问题。沿用原测试报告、Bug 系统或阶段七共用遗留记录，不要求测试再交独立清单。日常进展据实更新；以下是处理或承接结论的确认顺序，不把每次状态更新变成重复审批。
|
||||||
|
|
||||||
|
1. 中心真人先确认问题事实、对象及版本、实际处理结果或承接安排。事实未确认前，不要求产品代为调查中心尚未核实的事实。
|
||||||
|
2. 产品真人在上述事实基础上再次确认，并在自身权限内决定处理方式。产品调整处理方案时，中心协调受影响的安排，再补受影响部分的确认。
|
||||||
|
3. 双方无异议后，在原记录登记最终结论、范围、条件与后续安排。已有适用于当前对象、版本和范围的有效确认直接引用，仅补缺失或变化部分。
|
||||||
|
|
||||||
|
每项保留：
|
||||||
|
|
||||||
|
- **问题**：已有 Bug 编号或名称、原记录入口、对象及版本。
|
||||||
|
- **实际状态**：已修复、延期、暂不修复或其他真实状态；处理方式已确认不等于问题已修复。
|
||||||
|
- **中心确认**：实际确认人、时间、事实与结论、范围、条件和来源。
|
||||||
|
- **产品确认**：实际确认人、时间、再次确认及处理决定、权限范围、条件和来源。
|
||||||
|
- **承接与分歧历史**：主责、下一步、原计划与当前计划、影响、必须完成阶段；保留每次调整、分歧及最终决定。
|
||||||
|
|
||||||
|
双方无异议可以对应修复、延期或暂不修复，不代表全部已修复或测试通过；不因此重测已有有效验收结果。后续发现的问题依同一确认顺序处理，按原责任或新的明确授权跟进，不自动撤销既有关闭决定。
|
||||||
@@ -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 的内容和入口须经有权真人统一确认范围后再修改；关闭本身不代表共享规则变更授权。
|
||||||
@@ -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 和后续责任如实保留，不据此声称量产出货。
|
||||||
@@ -0,0 +1,36 @@
|
|||||||
|
# 工时、周期与项目计划
|
||||||
|
|
||||||
|
阶段四组织评估、编排计划或后续更新执行情况时读取。中心真人统筹总排期和跨角色资源；角色真人决定本领域的执行方法。已有项目沿用已确认的唯一计划主表，新项目默认使用 [Excel 八列计划模板](../assets/templates/项目计划.xlsx)。Markdown 项目进度只维护摘要和主表入口。
|
||||||
|
|
||||||
|
## 收集评估与衔接周期
|
||||||
|
|
||||||
|
1. 评估前，向嵌入式应用层、嵌入式底层、硬件三方交接全部有效产品需求文件，列明版本和完整入口。各方分别说明本人范围、已有成果、剩余工作、尚不能估算的部分、可投入人员及外部等待。
|
||||||
|
2. 初版单列，后续迭代轮数不包含初版；每轮内容和周期可以不同。研发开发、自测、修复与独立测试、回归分别记录，外部等待另列。
|
||||||
|
3. 三方提交周期后，由技术负责人核实范围、遗漏与重复、先后和并行、合版以及软硬件依赖，再交测试衔接初版、各轮和回归周期及资源。测试可以先估自身工作量，不必等其他领域全部完成才开始评估。
|
||||||
|
4. 产品只确认明确授权范围内的具体资源和排期对象，记录权限及范围；不默认产品对全部专业工作或工厂周期负责。预算、采购、对外承诺等仍按业务权限办理，不要求全员重批整份计划。
|
||||||
|
|
||||||
|
评估沿原任务按工作项用表格记录，可嵌入 [工时与周期评估栏目](../assets/templates/工时与周期评估.md)。保留主责真人、原估／当前估及单位、周期及起算条件、投入和等待、提交与确认日期、来源和状态。变更保留前后值、原因及真人确认；未知写待确认，不能把工作日直接换成人日或小时。
|
||||||
|
|
||||||
|
## 唯一计划主表
|
||||||
|
|
||||||
|
固定八列：**里程碑、工作项、预排开始日期、预排结束日期、预排工时/人时、负责角色、参与人数、实际执行情况**。
|
||||||
|
|
||||||
|
- 空白模板不预填日期、工时、人数、任务或迭代轮数。根据项目真实评估展开工作项；不同项目不套用同一套参考任务或周期。
|
||||||
|
- 工时是任务合计人时，不再乘参与人数。人数不表示资源已落实；空白和 NA 不改成零。工作周期、工时、投入和外部等待分别记录。
|
||||||
|
- 客户目标、内部预计、当前有效计划和实际执行分开；客户验收目标与量产目标分别保留。计划主表显示当前已确认计划，原计划及历次改期保留在原任务记录中并可追溯。
|
||||||
|
- 预排日期不证明实际开始或完成；表格日期重叠不证明可并行、依赖已满足或已获跨阶段授权。
|
||||||
|
- 主表按项目已有位置维护；新项目在阶段四任务过程中编制，确认有效后按正式成果规则登记。后续持续使用同一主表，不另建 Markdown 全量副本。
|
||||||
|
|
||||||
|
## 更新实际执行情况
|
||||||
|
|
||||||
|
中心根据真实回报更新同一工作项的“实际执行情况”，按需要分行记录：
|
||||||
|
|
||||||
|
- 更新时间及事实来源。
|
||||||
|
- 已完成部分、未完成部分与当前进展。
|
||||||
|
- 真实开始和完成时间；任务实际完成仍取提交后真人明确确认完成的时间，工程实际发生时间另记。
|
||||||
|
- 成果名称、版本和实际入口，已有确认人、时间及范围。
|
||||||
|
- 偏差、影响、下一步，以及原任务记录入口。
|
||||||
|
|
||||||
|
没有回报时写“待补充执行情况”，不能推定未开始或未完成。日常事实更新直接据实登记并保留来源、历史，不重批整表。修改已确认日期、工作范围或资源安排时，由对应有权真人确认后更新当前计划，原值和决定保留在原任务／变更记录中。
|
||||||
|
|
||||||
|
已确认计划基线及历史版本仍按 [成果与确认](artifacts-and-confirmation.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. 主动向中心真人汇报需要确认或决定的阶段结果；取得必要推进决定或既有条件授权实际满足并留档后再推进。需要通知时从这些记录生成摘要，正文及真实发送结果记入过程记录。
|
||||||
|
|
||||||
|
若更新中断，继续前核对原记录、阶段和项目摘要是否一致，以真实事实和确认依据为准补齐，不凭较新的文件时间覆盖业务结论。中心不新增一套任务数据库、通知队列或同步服务。
|
||||||
|
|
||||||
|
## 排版约定
|
||||||
|
|
||||||
|
- 一级标题写项目／阶段／任务名称，紧接一句当前情况；二级标题划分现状、要求、成果确认、影响和历史。
|
||||||
|
- 每个事项单列，字段用子条目；短标签加粗，栏目之间留空行。比较固定字段时可用短表格，避免塞入多段说明形成宽表。
|
||||||
|
- 时间写明确日期，需要时注明时刻和时区；只有日期的确认不补造时分秒。未知、尚未确认、不适用、无分别使用。
|
||||||
|
- 链接使用可读名称，关联真实路径。生成文件时核对相对链接，不保留模板指引为项目事实，不创建虚假文件链接。
|
||||||
|
- 模板提供版式与字段，生成时替换填写说明，按真实内容展开条目；不为填满模板创造任务、确认、负责人或成果。
|
||||||
@@ -0,0 +1,35 @@
|
|||||||
|
# 阶段汇报与推进决定
|
||||||
|
|
||||||
|
阶段结果需要确认、未完成事项需要决定或准备交接阶段时读取。汇报发在项目持续使用的中心会话中；更新本地记录不能替代向中心真人汇报。群通知另按 [通知规则](dingtalk-progress-reporting.md) 执行。
|
||||||
|
|
||||||
|
## 何时主动汇报
|
||||||
|
|
||||||
|
- 本阶段任务已全部确认完成，需要决定是否推进。
|
||||||
|
- 成果已提交但还有必要确认，或存在未完成、延期和跨阶段承接事项，需要中心真人决定。
|
||||||
|
- 已汇报的成果、版本、确认或遗留发生实质变化，补充受影响部分。
|
||||||
|
|
||||||
|
先更新原任务、阶段、项目进度及适用成果索引，再用 [阶段成果汇报栏目](../assets/templates/阶段成果汇报.md) 逐条汇报。可直接用于聊天，不为每次汇报另建独立成果文件；在阶段过程记录保留本次汇报与决定的依据。
|
||||||
|
|
||||||
|
## 汇报什么
|
||||||
|
|
||||||
|
1. 项目名称、本次汇报日期、当前阶段、阶段状态及概况。
|
||||||
|
2. 本阶段每项任务的主责真人、完成情况、应交成果、必需／选填与适用条件、已交成果及版本、完整入口。对应真人确认逐项写确认人、真实时间、结论、对象、范围与条件。
|
||||||
|
3. 原计划、当前有效计划、实际提交和实际完成时间；阶段管理日期与工程实际时间分开。
|
||||||
|
4. 未完成项和待确认项逐条说明原因、依赖、责任、原计划与当前计划、影响及必须完成的阶段。确实没有时明确写“未完成项：无；待确认项：无”；未知不填无。
|
||||||
|
5. 建议下一步及需要中心真人决定的具体事项。建议和已作出的决定分开，未决定保持待决定。
|
||||||
|
|
||||||
|
请求成果确认前，按 [成果与确认](artifacts-and-confirmation.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 工具？
|
|
||||||
@@ -1,4 +0,0 @@
|
|||||||
interface:
|
|
||||||
display_name: "Etunel 多角色协作"
|
|
||||||
short_description: "约束 Hub 中介、中文沟通、阶段成果与项目留档"
|
|
||||||
default_prompt: "使用 $etunel-role-collaboration 确认我的当前角色，只读取本任务需要的流程和职责规则，并通过 Hub 中介完成任务与阶段留档。"
|
|
||||||
@@ -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 实际收件、附件及本地归档的通用要求不强制适用于这条交付路径；必须能追踪实际文件与接收状态，不能只凭消息已处理宣布交接完成。
|
|
||||||
|
|
||||||
向下游只传递任务需要的已登记成果、版本、约束、风险和证据引用，不复制完整聊天或全部资料。
|
|
||||||
@@ -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 不在脚本外追加重试循环。
|
|
||||||
@@ -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)。
|
|
||||||
@@ -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) 归档；不要为探测队列或重复确认而读取。
|
|
||||||
@@ -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 任务。
|
|
||||||
@@ -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；
|
|
||||||
- 不用消息、队列、状态快照或钉钉结果替代任务、成果、留档或门禁；
|
|
||||||
- 不自动添加自定义角色，不向未登记角色派发；
|
|
||||||
- 不伪造通过、批准、日期、测试、发布或模拟结论。
|
|
||||||
@@ -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)。
|
|
||||||
@@ -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 投递状态、项目状态快照或钉钉通知当作业务完成。
|
|
||||||
@@ -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 主流程。
|
|
||||||
@@ -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 重复收存；模拟项目只能记录模拟完成。
|
|
||||||
@@ -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）保留旧值、新值、原因、证据、纠正人、生效时间及受影响任务，更新内部记录并向全部受影响角色重新分发有效快照。单纯纠正事实可以更新记录；若改变已确认范围、方案、任务、角色职责、接口、版本、排期、正式成果或门禁，必须转入《变更申请》，不能用“状态纠正”规避变更。
|
|
||||||
|
|
||||||
新项目默认使用当前流程基线。在途项目继续使用已登记基线；只有明确决定迁移时，才记录阶段和成果映射、缺失项、风险、必要确认及旧版替代关系。
|
|
||||||
@@ -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 整理的范围、版本、计划影响、风险和明确决定请求；
|
|
||||||
- 测试结论、平台／客户验收证据、缺陷和剩余风险；
|
|
||||||
- 报价、合同、付款、许可与交付材料的受控引用。
|
|
||||||
|
|
||||||
## 正式输出
|
|
||||||
|
|
||||||
- 项目背景说明；
|
|
||||||
- 客户里程碑要求；
|
|
||||||
- 业务对象、目标、范围、优先级和交付边界；
|
|
||||||
- 报价／合同／付款／许可决定和对外承诺记录；
|
|
||||||
- 产品范围批准、变更申请决定和组织授权；
|
|
||||||
- 客户验收确认、遗留问题清单的业务处置或拒绝原因；
|
|
||||||
- 结项阶段的交付、回款、续约、终止和遗留业务事项；
|
|
||||||
- 决定人、授权状态、证据引用和剩余业务风险。
|
|
||||||
|
|
||||||
业务不输出详细产品需求、总体方案、硬件／固件实现或测试结论。
|
|
||||||
|
|
||||||
## 信息保护
|
|
||||||
|
|
||||||
完整报价、合同、付款、许可和客户材料使用受控引用；只向下游传递当前任务必需的业务边界和批准结论。密码、访问令牌、私钥、证书密钥、个人数据及无关客户资料不得进入普通消息或成果。
|
|
||||||
@@ -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 最终提测版本仍必须经过技术负责人确认。
|
|
||||||
@@ -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 按依赖协调。缺陷修复后仍只交付可消费底层版本，由应用层重新集成统一固件。
|
|
||||||
@@ -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、电平、时序、初始化顺序或错误恢复理解不一致；
|
|
||||||
- 软件证据指向硬件，但缺少板卡、波形、复现或软件侧排查；
|
|
||||||
- 硬件变化会影响产品范围、固件、测试或正式里程碑；
|
|
||||||
- 样机、器件、供应或测试资源形成阻塞；
|
|
||||||
- 需要变更申请、跨角色接口裁决或独立验证。
|
|
||||||
@@ -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。
|
|
||||||
@@ -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 返回。
|
|
||||||
@@ -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 登记文件名、版本、保存位置及双方确认，不要求大文件上传或重复中转。修复必须回到测试在目标组合独立复验后才能关闭。
|
|
||||||
@@ -1,30 +0,0 @@
|
|||||||
# 连接与兼容性专项
|
|
||||||
|
|
||||||
仅在当前《测试计划》包含 Wi-Fi、SD 卡或路由器兼容性时读取。每个矩阵按实际客户、市场、芯片方案和产品范围裁剪，并记录未覆盖范围。
|
|
||||||
|
|
||||||
## Wi-Fi 性能与稳定性
|
|
||||||
|
|
||||||
Wi-Fi 性能／稳定性和路由器兼容性分别管理，可共享设备矩阵。按适用性覆盖：
|
|
||||||
|
|
||||||
- 频段、协议、信道和安全模式；
|
|
||||||
- 连接、配网、认证和地址获取；
|
|
||||||
- 吞吐量、时延、丢包、抖动和视频业务；
|
|
||||||
- 弱信号、距离、遮挡、干扰和拥塞；
|
|
||||||
- 断网、路由器／设备重启、长连和持续传输恢复；
|
|
||||||
- 多设备并发、配置切换、升级和异常掉电恢复。
|
|
||||||
|
|
||||||
具体指标、距离、持续时间、并发和网络模型由《测试计划》定义。
|
|
||||||
|
|
||||||
## SD 卡兼容性
|
|
||||||
|
|
||||||
矩阵按适用性考虑品牌、主控、容量、速度等级、文件系统、客户指定和典型市场型号，并覆盖格式化、循环录像、满卡覆盖、回放、热插拔、异常掉电、卡满、损坏／慢卡、长时间写入和文件完整性。
|
|
||||||
|
|
||||||
少量型号通过不能支持“兼容所有 SD 卡”的结论。
|
|
||||||
|
|
||||||
## 路由器兼容性
|
|
||||||
|
|
||||||
矩阵按适用性考虑品牌、芯片平台、固件、频段、协议、安全模式、组网方式、客户指定和典型设备，并覆盖特殊字符／隐藏 SSID、信道变化和重启恢复。
|
|
||||||
|
|
||||||
兼容矩阵需要版本化，并随客户、市场现场问题和芯片方案更新。未覆盖设备必须披露，不能宣称兼容全部路由器。
|
|
||||||
|
|
||||||
环境、设备或客户指定清单缺失而无法完成必测覆盖时，结果为阻塞，不得标记为不适用。
|
|
||||||
@@ -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 只归档已有资料并复盘。
|
|
||||||
|
|
||||||
- 普通测试版：策略、版本、范围、状态统计、结果摘要、缺陷增量、阻塞和限制；
|
|
||||||
- 缺陷修复版：原缺陷复测、关联回归、新问题和剩余风险；
|
|
||||||
- 大版本／候选发布版：在功能测试报告、《缺陷清单》及已提供的选填报告中记录实际覆盖、统计、缺陷、回归与质量结论；
|
|
||||||
- 平台提测版：要求映射、预检、提交版本、平台反馈、整改和重提记录；
|
|
||||||
- 试产定版：最终计划、用例、执行、兼容矩阵、缺陷、回归、证据、遗留风险和质量报告。
|
|
||||||
|
|
||||||
角色契约不固定统一小时级响应时限；响应、测试、回归和报告时限由项目计划或《测试计划》定义。
|
|
||||||
@@ -1,25 +0,0 @@
|
|||||||
# 画质专项
|
|
||||||
|
|
||||||
仅在当前产品、客户范围或《测试计划》要求画质验证时读取。
|
|
||||||
|
|
||||||
## 责任边界
|
|
||||||
|
|
||||||
- 产品确认用户可见行为、目标风格和验收标准；
|
|
||||||
- 硬件提供 Sensor、镜头、IR-CUT、补光和相关规格事实；
|
|
||||||
- 嵌入式底层／应用层提供实际图像链路、参数、构建和配置版本；
|
|
||||||
- 测试设计场景、执行测量、保留数据并形成独立结论；
|
|
||||||
- 含义或目标风格不清时通过 Hub 返回产品，不以“观感良好”替代标准。
|
|
||||||
|
|
||||||
## 测试设计
|
|
||||||
|
|
||||||
按适用性结合客观指标、标准场景、参考样机和受控主观评价，覆盖：
|
|
||||||
|
|
||||||
- 清晰度、色彩、白平衡、曝光和宽动态；
|
|
||||||
- 逆光、高光、低照度、噪声和拖影；
|
|
||||||
- 日夜切换、畸变、暗角、坏点和闪烁；
|
|
||||||
- 分辨率、码率、帧率及关键参数组合；
|
|
||||||
- 不同硬件、固件、配置和样本的一致性。
|
|
||||||
|
|
||||||
《测试计划》明确光源、场景、距离、环境、样本、设备、指标、主观评价方法、目标版本和阈值来源。原图、视频、参数快照、测量数据和对比结果应可追踪。
|
|
||||||
|
|
||||||
未覆盖场景必须披露；不得由少量主观观察推导全部画质条件通过。
|
|
||||||
@@ -1,40 +0,0 @@
|
|||||||
# 平台提测与试产定版
|
|
||||||
|
|
||||||
当前任务包含第三方／客户平台正式提测或试产候选定版时读取。
|
|
||||||
|
|
||||||
阶段 7 正式验收使用的测试结果须已满足阶段 6 质量门禁及 [项目负责人确认](../artifacts-and-evidence.md#测试结果的项目负责人确认)。内部预检和阶段性问题沟通不冒充正式验收。
|
|
||||||
|
|
||||||
## 平台提测
|
|
||||||
|
|
||||||
平台流程使用：
|
|
||||||
|
|
||||||
内部预检 → 准备提交 → 已提交 → 平台通过／平台失败／平台阻塞
|
|
||||||
|
|
||||||
要求：
|
|
||||||
|
|
||||||
- 平台标准与测试项可追踪；
|
|
||||||
- 内部预检版本、正式提交版本和证据版本一致；
|
|
||||||
- 保存提交材料、版本、账号／环境安全引用、提交时间和平台正式结果；
|
|
||||||
- 平台反馈与客户问题记入同一份《遗留问题清单》并标明来源，经 Hub 转入缺陷闭环；修复后复测、回归，产生新测试结果须重新取得项目负责人确认后再正式重提；
|
|
||||||
- 平台窗口、账号、客户或业务依赖通过 Hub 定向协调。
|
|
||||||
|
|
||||||
内部预检通过不等于平台通过。只有平台正式结果可以支持“平台通过”。
|
|
||||||
|
|
||||||
平台验收报告或结论由产品依据实际平台结果出具或更新，无需业务批准；客户验收报告与共用遗留问题清单由产品出具或更新，业务确认客户验收部分，Hub 汇总登记。平台与客户验收各自输入就绪时可并行，总门禁必须两者均通过。测试负责人直接交付测试报告及已提供的提测佐证给产品负责人，由产品向 Hub 确认接收，不要求大文件经 Hub 转发。
|
|
||||||
|
|
||||||
平台用例或提交模板中的报告、视频、截图、log 要求先作为实际平台要求说明，不自动升级为内部通用必交项。《可靠性测试报告》《专项测试报告》《提测佐证》按 [选填提交规则](../artifacts-and-evidence.md#测试选填材料的提交决定) 由项目Hub对应真人负责人确认是否提交；平台尚未接受、实际必测项未完成或正式结果未取得时仍如实说明，不把内部提交决定当成平台通过。
|
|
||||||
|
|
||||||
## 试产候选定版
|
|
||||||
|
|
||||||
仅在实际测试任务明确包含试产候选验证时执行，不因本引用存在就在阶段 8 追加测试。测试负责独立质量验证，不替生产或硬件责任方批准制造过程和良率；专项测试报告与提测佐证仍按选填规则处理。
|
|
||||||
|
|
||||||
按适用性确认：
|
|
||||||
|
|
||||||
- 样机、批次、硬件、底层固件、应用构建和配置与候选基线一致；
|
|
||||||
- 抽样方法、样本数和批次可追踪；
|
|
||||||
- 核心功能、升级恢复、画质、连接、存储和必要专项完成；
|
|
||||||
- 试产问题进入缺陷闭环；
|
|
||||||
- 没有未关闭的高风险缺陷；
|
|
||||||
- 报告明确未覆盖范围、限制和剩余风险。
|
|
||||||
|
|
||||||
最终测试版本必须与平台送审、试产和交付候选版本一致。无法证明一致时，质量结论为阻塞。
|
|
||||||
@@ -1,37 +0,0 @@
|
|||||||
# 功耗与环境可靠性
|
|
||||||
|
|
||||||
仅在当前《测试计划》将功耗、高温、低温、温度循环或环境恢复列为适用专项时读取。
|
|
||||||
|
|
||||||
《可靠性测试报告》为选填，列项为高低温测试、跌落测试（选填）、防水测试（选填）；《专项测试报告》同样选填。是否执行具体测试以已确认测试计划和适用标准为准，不因报告选填而取消已确定的必测项，也不为提交一份报告额外增加测试范围。
|
|
||||||
|
|
||||||
## 共同原则
|
|
||||||
|
|
||||||
- 功耗与环境可靠性分别设计、记录和给出结论，不能互相代替；
|
|
||||||
- 阈值、供电、温度点、样本、持续时间和循环次数来自已批准《测试计划》或上游标准；
|
|
||||||
- 记录设备、板卡、固件、配置、样本、仪器、采样方法和环境；
|
|
||||||
- 每个适用子项独立给出通过、不通过或阻塞结论，不以平均结果掩盖不通过项。
|
|
||||||
|
|
||||||
## 功耗
|
|
||||||
|
|
||||||
按产品场景选择开机峰值、待机、预览／推流、录像与存储、Wi-Fi 高负载、日夜切换、补光／红外、升级、重启和其他高负载状态。
|
|
||||||
|
|
||||||
《测试计划》明确：
|
|
||||||
|
|
||||||
- 供电与配置；
|
|
||||||
- 业务场景、样本数和预热条件；
|
|
||||||
- 测量设备、采样频率和方法；
|
|
||||||
- 稳态、平均值、峰值和异常波动判定；
|
|
||||||
- 时长、重复次数和阈值来源。
|
|
||||||
|
|
||||||
## 高低温与循环
|
|
||||||
|
|
||||||
按适用性覆盖：
|
|
||||||
|
|
||||||
- 高温启动和运行；
|
|
||||||
- 低温启动和运行；
|
|
||||||
- 高低温循环；
|
|
||||||
- 必要的高低温存储和恢复后验证。
|
|
||||||
|
|
||||||
《测试计划》明确温度点、升降温条件、稳定时间、持续时间、循环次数、样本数、负载和恢复时间。环境中及恢复后检查适用的启动、核心功能、画质、网络、存储、升级／恢复、日志和不可逆变化。
|
|
||||||
|
|
||||||
无法满足环境、仪器、样本或持续时间要求时标记为阻塞，不得改成不适用。
|
|
||||||
@@ -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 中本角色及当前任务的说明，不一次加载全部流程。
|
|
||||||
```
|
|
||||||
@@ -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回复或结算。
|
|
||||||
```
|
|
||||||
@@ -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 中本角色及当前任务的说明，不一次加载全部流程。
|
|
||||||
```
|
|
||||||
@@ -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 中本角色及当前任务的说明，不一次加载全部流程。
|
|
||||||
```
|
|
||||||
@@ -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 中本角色及当前任务的说明，不一次加载全部流程。
|
|
||||||
```
|
|
||||||
@@ -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 中本角色及当前任务的说明，不一次加载全部流程。
|
|
||||||
```
|
|
||||||
@@ -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 中本角色及当前任务的说明，不一次加载全部流程。
|
|
||||||
```
|
|
||||||
@@ -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 中本角色及当前任务的说明，不一次加载全部流程。
|
|
||||||
```
|
|
||||||
@@ -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 "$@"
|
||||||
@@ -0,0 +1,3 @@
|
|||||||
|
# Personal DWS message entry; preserves Chinese, Markdown and exit status.
|
||||||
|
& "$PSScriptRoot/dingtalk-python.ps1" message @args
|
||||||
|
exit $LASTEXITCODE
|
||||||
+5
-187
@@ -1,190 +1,8 @@
|
|||||||
#!/bin/sh
|
#!/bin/sh
|
||||||
|
# macOS/Linux entry; Windows can use the .ps1 or Python entry.
|
||||||
set -eu
|
set -eu
|
||||||
|
script_dir=$(CDPATH= cd -- "$(dirname -- "$0")" && pwd)
|
||||||
project_root=$(CDPATH= cd -- "$(dirname -- "$0")/.." && pwd)
|
if command -v python3 >/dev/null 2>&1; then
|
||||||
config_file="$project_root/.dingtalk/config.env"
|
exec python3 "$script_dir/dingtalk_notify.py" progress "$@"
|
||||||
|
|
||||||
usage() {
|
|
||||||
echo "用法：./scripts/dingtalk-progress <start|milestone|blocked|complete|failed> <中文 Markdown 摘要>" >&2
|
|
||||||
}
|
|
||||||
|
|
||||||
if [ "$#" -lt 2 ]; then
|
|
||||||
usage
|
|
||||||
exit 2
|
|
||||||
fi
|
fi
|
||||||
|
exec python "$script_dir/dingtalk_notify.py" progress "$@"
|
||||||
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"
|
|
||||||
@@ -0,0 +1,3 @@
|
|||||||
|
# PowerShell 7.3+; shared launcher preserves Chinese, Markdown and exit status.
|
||||||
|
& "$PSScriptRoot/dingtalk-python.ps1" progress @args
|
||||||
|
exit $LASTEXITCODE
|
||||||
@@ -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
|
||||||
@@ -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())
|
||||||
@@ -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()
|
||||||
Reference in new issue
Block a user