forked from arechen/EapilSkillMarket
Sync third-party and MCP marketplace plugins
Constraint: Public skills are published only by explicit administrator action unless they are tracked third-party market sources. Confidence: high Scope-risk: narrow Directive: Keep private/internal skills out of the public marketplace and preserve normal incremental market Git history. Tested: Marketplace validation passed.
This commit is contained in:
KeyInfo Bot committed
1 parent
9e74428671
commit
ebe567a174
46 files changed
+707
-2358
No files matched your search
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "etunel-role-collaboration",
|
||||
"version": "1.0.4",
|
||||
"description": "Etunel 多 Agent 项目的角色识别、Hub 中介、依赖任务波次、成果交接和消息流程协作规范。",
|
||||
"version": "2.0.0",
|
||||
"description": "EP Hub 项目中心：按八阶段管理交付任务、真人确认、项目进度、信息交接和成果留档。",
|
||||
"author": {
|
||||
"name": "chenmingxuan",
|
||||
"url": "https://git.playones.com/chenmingxuan"
|
||||
@@ -12,15 +12,16 @@
|
||||
"keywords": [
|
||||
"etunel",
|
||||
"multi-agent",
|
||||
"role-collaboration",
|
||||
"ep-hub",
|
||||
"project-hub",
|
||||
"human-confirmation",
|
||||
"workflow"
|
||||
],
|
||||
"skills": "./skills/",
|
||||
"interface": {
|
||||
"displayName": "Etunel 多角色协作",
|
||||
"shortDescription": "约束 Hub 中介、成员状态、依赖任务波次、正式成果与消息流程。",
|
||||
"longDescription": "用于 Etunel 多 Agent 项目中的角色和成员识别、Hub 唯一跨角色中介、依赖就绪任务波次、正式成果交接、异常协调及消息流程。该 skill 依赖 Etunel 运行时提供的 Hook、角色契约和任务上下文。",
|
||||
"displayName": "ep-hub",
|
||||
"shortDescription": "项目中心：八阶段交付、真人确认、进度与成果留档。",
|
||||
"longDescription": "提供 $ep-hub 项目中心 Skill，管理八阶段交付、真人确认、信息交接、项目进度和五类记录模板。Etunel 配置与通信使用目标环境已安装的 etunel-use；可选钉钉通知需单独部署同版脚本、Python 3.9+ 和已登录的原生 DWS，progress 调用必须提供 --stage。沿用 etunel-role-collaboration 安装 ID 以支持已有用户升级；更新插件不自动修改 Hook、角色契约或迁移在途项目，旧基线和完成事实须保留。",
|
||||
"developerName": "chenmingxuan",
|
||||
"category": "Business & Operations",
|
||||
"capabilities": [
|
||||
@@ -29,8 +30,8 @@
|
||||
"Write"
|
||||
],
|
||||
"defaultPrompt": [
|
||||
"使用 Etunel 多角色协作识别当前角色并推进项目任务。",
|
||||
"使用 Etunel 多角色协作检查任务依赖、成果和交接状态。"
|
||||
"使用 $ep-hub 根据现有项目记录整理当前阶段、交付成果和需要真人决定的事项。",
|
||||
"使用 $ep-hub 检查项目进度、跨阶段遗留和成果确认，不擅自迁移既有流程。"
|
||||
],
|
||||
"websiteURL": "https://git.playones.com/chenmingxuan/EP-Hub-Skill",
|
||||
"privacyPolicyURL": "https://git.playones.com/chenmingxuan/EP-Hub-Skill",
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
{
|
||||
"sourceId": "etunel-role-collaboration",
|
||||
"repo": "https://git.playones.com/chenmingxuan/EP-Hub-Skill.git",
|
||||
"ref": "v1.0.4",
|
||||
"commit": "1d85de4c7c1cd0138d94b211586c9008b28094df",
|
||||
"ref": "v2.0.0",
|
||||
"commit": "98541d682bf2ff4b4127eee19eeb76a3b66ada47",
|
||||
"adapter": "claude-skill",
|
||||
"sourcePath": "etunel-role-collaboration",
|
||||
"syncedAt": "2026-09-15T09:51:52Z"
|
||||
"sourcePath": "ep-hub",
|
||||
"syncedAt": "2026-10-12T04:59:58Z"
|
||||
}
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
name: ep-hub
|
||||
description: 作为项目中心，按八阶段管理交付任务、真人确认、信息交接、项目进度和成果留档，并生成钉钉通知。用于中心推进项目与处理延期、变更、验收和结项；成员内部工作方式由各自真人负责人设计，Etunel 配置与通信操作使用 etunel-use。
|
||||
---
|
||||
|
||||
# 项目中心
|
||||
|
||||
一个项目使用一个持续的中心会话。中心 Agent 整理事实、交接资料、维护记录并提出待决定事项；中心真人负责人依据结果决定推进、补充、退回或暂缓。成员的执行方法、内部评审和 Agent 使用方式由各自真人负责人安排。
|
||||
|
||||
## 工作边界
|
||||
|
||||
- 按可独立确认的交付结果管理任务；同一负责人承担的内聚工作可组成任务包。每项任务有一名主责真人、明确输入、范围、结果、期限与完成条件，不拆成中心监督的内部步骤。
|
||||
- 真人可以直接协作，任务接收与结果提交可以在线下完成；必须保留实际接收、提交和确认的依据。成员 Agent 之间的信息仍经中心定向中继。
|
||||
- 同一阶段内，任务确认完成后可启动依赖已经满足的后续任务；跨阶段推进须取得中心真人明确决定。中心决定不能替代专业判断、业务授权、产品资源排期确认或外部验收。
|
||||
- 正式成果只保存真人完成并确认的最终有效版本及确认记录；草稿、旧版、历史确认和中心推进决定进入过程记录。链接交付只记录地址，不要求复制、截图或重新下载。
|
||||
- 实际完成时间是任务提交后，经对应真人明确确认完成的时间。提交、送达、已读、Agent 检查或工具任务完成都不能替代这一确认。
|
||||
- 项目层持续显示当前阶段、整体进度、当前待处理事项，以及未完成事项的原计划、当前计划、影响范围和必须完成的阶段；跨阶段沿用原任务记录。
|
||||
- 不重复要求已有有效确认；成果或版本发生实质变化、适用范围扩大或出现相反证据时，仅重新确认受影响部分。
|
||||
- 遵循已确认的项目基线、真人授权和当前运行时契约。发现冲突时说明具体差异，取得有权人的处理决定；不自行改写基线、伪造工具或把部署未完成说成已生效。
|
||||
|
||||
## 按当前任务读取
|
||||
|
||||
| 要做什么 | 读取什么 |
|
||||
| --- | --- |
|
||||
| 接收请求、组织交付任务、收取结果或交接阶段 | [中心工作流](references/hub-workflow.md) |
|
||||
| 判断阶段、应交成果和推进条件 | [八阶段与结果要求](references/project-lifecycle.md)，只读当前阶段及受影响阶段 |
|
||||
| 建立目录、更新任务、阶段和项目进度 | [记录与留档](references/project-records.md)，其中链接五类 Markdown 模板 |
|
||||
| 判断成果、真人确认、版本替换或完成时间 | [成果与确认](references/artifacts-and-confirmation.md) |
|
||||
| 处理延期、阻塞、变更、退回、豁免或放行 | [异常与决定](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 根据项目现有记录整理当前阶段、交付成果和需要真人决定的事项，并更新项目进度。"
|
||||
+48
@@ -0,0 +1,48 @@
|
||||
# 任务记录
|
||||
|
||||
> 填写指引：标题改为明确的任务名称，紧接一句当前情况。前部维护最新事实，关键历史按时间追加；内部执行步骤由角色真人自行安排。
|
||||
|
||||
## 当前情况
|
||||
|
||||
- **任务状态**：按真实情况填写；提交未确认时为“待确认”。
|
||||
- **主责真人**：记录姓名和角色；协作者按需要另列。
|
||||
- **所属阶段**：记录任务原所属阶段。
|
||||
- **原计划完成时间**：保留首次确认的期限。
|
||||
- **当前计划完成时间**：记录最近一次经确认的有效期限。
|
||||
- **实际完成时间**：任务提交后经对应真人明确确认完成的时间；尚未确认时写“尚未确认完成”。
|
||||
- **必须完成的阶段**：记录已确认安排。
|
||||
- **开始时间**：有约定时分别保留原计划、当前计划与实际开始时间。
|
||||
|
||||
## 任务要求
|
||||
|
||||
- **目标**：说明可独立判断的交付结果。
|
||||
- **输入资料**：逐条列有效资料、版本与实际位置。
|
||||
- **处理范围**：区分本阶段必须完成、后续处理与当前不需要。
|
||||
- **应交结果**：列成果或成果包、最低内容、必需／选填与下游用途。
|
||||
- **完成条件**：列结果要求、必要真人确认与授权，沿用已有约定。
|
||||
- **依赖**：只列影响当前执行或交接的输入与条件。
|
||||
|
||||
## 成果与确认
|
||||
|
||||
- **接收情况**：记录真人实际接收时间及依据；只有发送证据时标为接收待确认。
|
||||
- **提交情况**：每次提交单列提交人、时间、成果版本和保存位置。
|
||||
- **完成情况**：说明已完成、未完成部分及具体缺口。
|
||||
- **确认情况**：每项单列确认人、真实确认时间、任务／成果及版本、结论、范围和条件。
|
||||
- **确认来源**：记录直接确认或线下转述；转述保留实际确认人、转述人、来源及补录时间。
|
||||
|
||||
## 下一步与影响
|
||||
|
||||
- **下一步**：写清谁需要做什么、需要谁作出什么决定。
|
||||
- **延期或阻塞**：写明事实、原因及是否超过原计划／当前计划。
|
||||
- **影响范围**：列受影响任务、成果、阶段或对外节点；未知写待确认。
|
||||
- **处置或承接**：保留有权真人决定、期限与必须完成阶段，取消／豁免不写为实际完成。
|
||||
|
||||
## 关键历史
|
||||
|
||||
### 事件时间与名称
|
||||
|
||||
- **参与人**：记录实际执行、提交或作出决定的人。
|
||||
- **发生了什么**：记录接收、提交、退回、确认、改期、变更或重开。
|
||||
- **变化前后**：涉及日期、版本、范围变化时保留旧值与新值。
|
||||
- **依据与原因**：记录有效来源、真人结论及原因。
|
||||
- **影响及后续**：说明受影响范围和下一步，不复制内部操作或完整聊天记录。
|
||||
+11
@@ -0,0 +1,11 @@
|
||||
# 当前正式成果索引
|
||||
|
||||
> 填写指引：按阶段逐项列出真人完成并确认的当前最终成果。任务状态、草稿、旧版、延期和推进决定在过程记录中维护。
|
||||
|
||||
## 阶段名称
|
||||
|
||||
### 成果名称
|
||||
|
||||
- **当前最终版本**：记录实际有效版本。
|
||||
- **位置或链接**：只填写实际文件或链接地址，不复制外部内容。
|
||||
- **确认记录**：链接对应阶段的正式确认栏目，确认详情由那里统一维护。
|
||||
+44
@@ -0,0 +1,44 @@
|
||||
# 阶段记录
|
||||
|
||||
> 填写指引：标题改为阶段编号与名称，紧接一句当前情况。下面两个栏目分别保存最终成果和任务过程；每个任务都要逐项汇总。
|
||||
|
||||
- **阶段状态**：记录未开始、进行中、待确认、已完成或实际例外状态。
|
||||
- **阶段时间**：记录已约定计划、实际进入与阶段决定时间。
|
||||
- **当前情况**：概括本阶段完成到哪里。
|
||||
|
||||
## 正式成果及确认记录
|
||||
|
||||
### 最终成果
|
||||
|
||||
- **成果名称**：每项最终成果独立列出。
|
||||
- **最终版本**：记录真人完成并确认的当前有效版本。
|
||||
- **保存位置**：使用实际文件位置或外部链接。
|
||||
|
||||
### 对应真人确认
|
||||
|
||||
- **确认人**：记录实际作出确认的人。
|
||||
- **确认时间**：记录真实时间。
|
||||
- **成果与版本**：明确此次确认的对象。
|
||||
- **结论**：记录真实确认结论。
|
||||
- **范围和条件**：保留适用范围与附带条件。
|
||||
- **来源**：链接已有依据；转述时注明转述人、来源与补录时间。
|
||||
|
||||
## 过程记录
|
||||
|
||||
### 任务名称
|
||||
|
||||
- **负责人**：记录主责真人。
|
||||
- **成果情况**：分条说明应交、已交、版本和位置；待确认稿不能列为正式最终成果。
|
||||
- **完成情况**：说明任务状态、已完成与尚缺部分。
|
||||
- **确认情况**：列已确认人、时间、对象、结论和未完成的必要确认。
|
||||
- **原计划完成时间**：记录首次期限。
|
||||
- **当前计划完成时间**：记录最新有效期限。
|
||||
- **实际完成时间**：任务提交后经真人明确确认完成的时间；未确认写“尚未确认完成”。
|
||||
- **影响及下一步**：列责任、动作、必须完成的阶段及跨阶段承接。
|
||||
- **任务原记录**：链接该任务的唯一记录。
|
||||
|
||||
### 阶段决定与未完成事项
|
||||
|
||||
- **决定**：每次单列决定人、时间、推进／补充／退回／暂缓结论、依据、范围和理由。
|
||||
- **未完成事项**：逐项引用原任务，列原计划、当前计划、必须完成阶段、影响、承接与阶段结束提醒情况。
|
||||
- **历史资料**：链接旧版、草稿、历史确认及替代关系。
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
# 项目概览
|
||||
|
||||
> 填写指引：标题改为实际项目名称；以下栏目按已确认事实填写，生成项目记录时移除此指引。
|
||||
|
||||
## 项目目标与范围
|
||||
|
||||
- **项目目标**：说明要完成的结果。
|
||||
- **本次范围**：说明纳入和已明确不纳入的内容。
|
||||
- **有效流程基线**：记录已确认的基线及采用依据。
|
||||
- **验收范围**：记录约定的内部、平台和客户验收范围；未确定的如实说明。
|
||||
|
||||
## 真人分工
|
||||
|
||||
- **中心负责人**：记录已确认姓名及权限范围。
|
||||
- **相关角色**：每个角色单列真人负责人、负责结果与必要协作。
|
||||
- **人员变化**：记录生效时间、交接事项及确认依据。
|
||||
|
||||
## 资料与协作入口
|
||||
|
||||
- **项目进度**：链接实际进度记录。
|
||||
- **成果索引**：链接当前有效成果索引。
|
||||
- **资料来源**：列已提供的项目资料位置。
|
||||
- **交接方式**：说明已确认的通信渠道、接收与提交方式。
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
# 项目进度
|
||||
|
||||
> 填写指引：标题使用实际项目名，先写一句当前进展；以下是栏目说明，生成记录时替换为真实事实。
|
||||
|
||||
## 当前阶段与整体进度
|
||||
|
||||
- **更新时间**：记录本次更新的时间。
|
||||
- **当前阶段**：记录有效阶段编号、名称及推进依据。
|
||||
- **已完成阶段**：逐项列出，跳过或暂缓的单独说明。
|
||||
- **关键成果**：说明已经完成、待确认和缺失的关键结果。
|
||||
- **下一步**：说明待推进的工作及必要条件。
|
||||
|
||||
## 当前待处理事项
|
||||
|
||||
### 事项名称
|
||||
|
||||
- **所属阶段**：记录原任务阶段。
|
||||
- **负责人**：使用已确认真人姓名与角色。
|
||||
- **当前情况**：区分已完成部分、未完成部分与确认状态。
|
||||
- **原计划完成时间**：记录首次确认的期限。
|
||||
- **当前计划完成时间**：记录最新有效期限，未调整时沿用原计划。
|
||||
- **必须完成的阶段**：使用已确认安排，未约定则写待确认。
|
||||
- **延期情况**：分别说明原计划和当前计划是否超期，以及原因。
|
||||
- **影响范围**：列受影响的成果、任务、阶段或对外节点。
|
||||
- **下一步／待决定**：写清谁做什么或谁决定什么。
|
||||
- **原记录**：链接任务原记录或已有问题系统中的事项。
|
||||
|
||||
## 已完成或已处置
|
||||
|
||||
- **事项**：每项单列完成或处置结论、真人及时间、原记录入口；仍有后续跟进的继续保留在当前事项中。
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
# 成果与真人确认
|
||||
|
||||
用于提交、接收、完成确认和版本替换。阶段特有的确认人按 [八阶段与结果要求](project-lifecycle.md)，不把中心真人确认推广为所有专业成果的重复审批。
|
||||
|
||||
## 分清事实
|
||||
|
||||
| 事实 | 如何记录 |
|
||||
| --- | --- |
|
||||
| 已发出任务或资料 | 记录发送渠道和时间；没有接收依据时，接收待确认 |
|
||||
| 真人已接收 | 记录实际接收人、时间、任务或成果版本及依据 |
|
||||
| 已提交成果 | 记录提交人、时间、版本与位置，完成确认尚缺时为“待确认” |
|
||||
| 真人确认成果或任务完成 | 记录确认人、时间、对象及版本、结论、范围、条件与来源 |
|
||||
| 同意推进或放行 | 在过程记录中单独记有权真人的决定；不替换成果本身结论 |
|
||||
|
||||
中心真人可在会话中明确转述线下接收、提交或确认事实。保留实际确认人、真实确认时间、对象、结论和范围，并注明转述人、来源及补录时间；缺失信息写待补充。不要求另做审批单、截图或重复确认，不能把转述者写成专业确认人。
|
||||
|
||||
## 实际完成时间
|
||||
|
||||
**任务提交后，经对应真人明确确认该任务完成的时间，才是实际完成时间。**
|
||||
|
||||
- 提交时间、专业成果确认时间和任务完成确认分别记录，可引用同一条有效确认，避免重复审批。
|
||||
- 任务条件需要多项确认时，以最后一项必要完成确认的真实时间为准；阶段推进决定另记，不延后已完成任务的时间。
|
||||
- 已提交未确认写“待确认／尚未确认完成”；不能用提交时间、Agent 检查时间、Etunel 完成回执或补录时间代填。
|
||||
- 退回后继续保留原任务及历次提交。重新提交获最终完成确认后记实际完成时间。
|
||||
- 已完成任务因实质变化重开时，保留旧完成事实和重开原因；当前要求未确认完成前不沿用旧时间表示新版已完成。
|
||||
- 取消、豁免、延期承接是处置结果，另记处置人和时间，不填为实际交付完成时间。
|
||||
|
||||
## 正式成果与历史
|
||||
|
||||
- 正式区只保存真人完成并确认的最终成果，每项一个当前有效版本。登记名称、版本、文件位置或链接；确认另列确认人、时间、对象及版本、结论、范围和条件。
|
||||
- 待确认稿、部分成果、候选固件、旧版及其历史确认进入过程区。任务记录关联所有提交，阶段正式栏目只列最终成果。
|
||||
- 新版获真人确认后才替换当前条目；先保留旧文件、旧确认及替代关系到过程区，再更新正式记录，不能覆盖丢失历史。外部链接成果保留旧地址、版本、确认及替代关系；不额外下载快照，外部系统是否保留历史如实记录。
|
||||
- 中心推进、豁免、版本放行、产品接收等事实放过程记录，引用相关正式成果。名为《变更记录》《流程闭环总结》的交付文档，在真人确认最终版后仍属于正式成果。
|
||||
- 链接交付只记地址与确认；内容核实由真人负责，不把复制内容、摘要、截图或可下载检查变成中心必做事项。
|
||||
- 实质变更、范围扩大或相反证据需要重新确认受影响部分；仅改存放位置、阶段引用或转述补录不自动触发重签。
|
||||
|
||||
测试“不通过”可被真人确认是实际测试结论，不能因版本获放行改成“通过”。测试结果确认、版本放行、阶段推进与外部验收分别保留。
|
||||
+117
@@ -0,0 +1,117 @@
|
||||
# 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 必须先核对真实事实，更新对应任务、阶段和项目进度记录；涉及正式成果变化时再更新成果与索引，然后发送钉钉消息。不为一次通知新增成果文件。钉钉发送失败不回滚留档，也不阻塞项目主任务。
|
||||
|
||||
## 事件判定
|
||||
|
||||
### start
|
||||
|
||||
每个项目最多一次。在第一个真实可执行任务或任务波次已经交给主责真人且已有实际接收依据后（可以通过 Etunel 或其他已授权渠道）发送。仅建立计划、等待输入或讨论想法时不发送。
|
||||
|
||||
### milestone
|
||||
|
||||
在可验证、会改变下一步的实质进展完成并已留档时发送，例如：
|
||||
|
||||
- 关键成果或版本成为当前有效版本；
|
||||
- 一个有意义的任务波次完成并触发角色或阶段交接；
|
||||
- 门禁、受控跳转、回退或豁免完成真实记录和必要确认；
|
||||
- 正式阻塞解除，项目恢复到明确下一动作；
|
||||
- 统一固件、版本矩阵、测试结论、验收或发布组合形成。
|
||||
|
||||
同一处理轮或同一波次合并成一条，不逐个小任务刷屏。没有固定时间间隔；依靠事件语义和去重控制频率。
|
||||
|
||||
### blocked
|
||||
|
||||
出现下列实际阻塞时立即发送：
|
||||
|
||||
- 已有影响交付的实际阻塞，需要中心协调、有权真人决定或外部条件才能继续；
|
||||
- 关键路径等待有权决定；
|
||||
- 当前使用的交接渠道实际中断，且没有可用的已授权替代渠道完成必要交接；不把 Etunel 异常自动等同于整个项目阻塞。
|
||||
|
||||
普通排队、正常等待、角色仍可自行推进或尚未完成产出不算阻塞。阻塞解除后用 `milestone` 汇报恢复，不修改历史消息。
|
||||
|
||||
### complete
|
||||
|
||||
整个项目或用户明确指定的整体目标最终完成时发送一次。模拟项目必须明确写“模拟完成”，不得表达真实发布、客户验收或生产就绪。
|
||||
|
||||
### failed
|
||||
|
||||
整个项目或整体目标已经最终终止、无法恢复或明确失败时发送。可返工的测试失败、单个任务失败或临时脚本异常不使用 `failed`。
|
||||
|
||||
## 消息写法
|
||||
|
||||
标题使用“项目名称｜阶段编号：阶段名称”，例如“示例项目｜阶段六：测试验证”。Hub 每次从有效项目记录取得当前阶段编号和名称，通过 `progress --stage` 整体传入；编号未登记时只写已知阶段名称，不自行编号或因通知示例改变阶段顺序。阶段变化后使用新名称，不把“阶段里程碑”等事件标签当成阶段，也不根据正文猜测阶段。提醒入口的自定义标题同样先写当前阶段，再写提醒事项。跨阶段事项在对应条目中注明所属阶段，通知标题仍写项目当前阶段。
|
||||
|
||||
进度通知采用已确认的格式：加粗项目与阶段标题、自动汇报时间、“已确认的进展”“待办事项”“遗留”三个加粗栏目，栏目间留空行。每件事单独一条，用日常说法写清谁做什么。确实没有待办或遗留时写“无”；资料不足时说明尚未核实，不把未知写成没有。本轮没有新增已确认进展时如实说明。
|
||||
|
||||
- 已确认的进展：写清完成了什么、谁已作出什么决定以及适用范围。区分“已进入阶段／开始整理”和“已完成／已关闭”；已通知交接不等于对方已经完成交接。已决定的事项直接说明结果，不再请人重复批准。
|
||||
- 待办事项：合并列出本轮需要决定、确认或处理的全部事项，用“事项名称：由谁做什么”逐条表述，例如资料整理、资料补充、旧事项停止、结果确认和本轮工作范围；按实际情况命名，不要求凑齐示例条目。标题已说明当前阶段，不必每条重复阶段名，涉及其他阶段时注明。需人工决定时写“条件具备后，由 Hub 请某负责人确认具体事项，确认后再执行后续动作”，条件只取已有约定；有可选方案时简短列明。需执行时写清已明确的处理人和动作，有已约定期限时沿用，必要时说明结果通过哪个已约定渠道返回。已明确停止的催办、需要复用的成果和不新增的工作须保留，不改写成新任务。
|
||||
- 遗留：逐条列出当前阶段及此前阶段尚未解决、需要继续跟进的事项，说明现状、已确认的后续安排及对应处理人；沿用原计划时间、当前计划时间、必须完成的阶段和影响范围，按本轮需要说明变更；跨阶段事项注明原所属阶段。列为遗留不等于获准延期、豁免、关闭问题或通过阶段；同一问题在待办里写本轮动作，在遗留里交代未解决状态，避免重复整段内容。
|
||||
- 待办和需跟进的遗留，在已明确真人处理人或决策人时，于对应条目中 @ 该人；Hub 代为请求确认时 @ 被请求确认的真人负责人，不把“Hub”或角色名称当成可查询姓名。纯 Agent 工作可直接写 Hub 或实际角色 Agent；真人姓名缺失时沿用已知角色，不猜测或编造 @ 对象，确需提醒再按项目分工与脚本用法取得已确认姓名。多人分工写清各自动作，同一人可在对应条目中重复出现，发送接收人去重。已完成且无需行动的进展不额外 @ 人。未确定的责任、期限或事实不编造，也不为填写通知重新要求分配或填表。
|
||||
- 用具体动作替代“收口”“闭环”“拉齐”等笼统表述。例如“处理方式已收口”可写成“负责人已确定处理方式”，但不得把处理方式确定写成问题已解决。原决定中的“暂不修复”“无需新增清单”等范围和限制必须保留。
|
||||
- 资料未说明交接或执行情况时，只写需要核实的事实及已有安排，不直接要求重新交付或执行；通用阶段职责不能直接变成本轮已派发的待办。补充事实不要求重做已经完成的工作。
|
||||
|
||||
以下用结项整理场景演示已确认的通知格式，项目名与人员称呼均已泛化。示例中的验收结论、成果数量、确认人及延期安排只属于该场景，不成为其他项目的默认事实、职责或放行条件；各项目仍依据自己的有效记录和流程基线生成内容。
|
||||
|
||||
```markdown
|
||||
**示例项目｜阶段八：复盘结项**
|
||||
|
||||
项目进度自动汇报 · 发送时自动生成带时区的时间
|
||||
|
||||
**已确认的进展**
|
||||
|
||||
- 相关负责人已确认：产品验收材料已在线下完成，业务已确认客户验收通过。
|
||||
- 项目已进入资料归档与复盘结项阶段，目前开始整理结项资料，项目尚未关闭。
|
||||
- 已通知相关负责人进行阶段交接，不新增审批。
|
||||
|
||||
**待办事项**
|
||||
|
||||
- 结项资料整理：由中心真人负责人组织四类结项成果，Hub 协助整理工作稿。
|
||||
- 资料补充：由产品负责人、业务负责人补充现有线下成果及确认记录，不重做验收。
|
||||
- 旧事项停止：由 Hub 停止此前的验收准备催办。
|
||||
- 结项确认：四类成果及遗留承接安排具备后，由 Hub 请 @示例业务负责人 确认结项。
|
||||
- 关闭决定：业务确认结项后，由 Hub 请 @示例中心负责人 决定是否关闭；结项必需项完成后锁定四类成果。
|
||||
- 本轮工作范围：不新增应用修复、设备测试或发布验证。
|
||||
|
||||
**遗留**
|
||||
|
||||
- 原测试不通过的结果如实保留，不因进入结项阶段改为通过。
|
||||
- 已接受延期的问题如实保留，后续沿用 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 不在脚本外追加重试循环。
|
||||
+42
-7
@@ -28,21 +28,56 @@ Windows 优先用 `.ps1`，须同时部署共用启动器 `dingtalk-python.ps1`
|
||||
## 日常发送
|
||||
|
||||
```text
|
||||
python scripts/dingtalk_notify.py progress milestone "**已完成**：阶段成果已确认并归档。下一步安排联调。"
|
||||
python scripts/dingtalk_notify.py progress blocked "缺少接口说明，请补充后回自己的角色会话同步。" --at "完整姓名"
|
||||
python scripts/dingtalk_notify.py message --title "资料补充提醒" --text "请补齐已约定资料，并回自己的角色会话确认。" --at "完整姓名"
|
||||
python scripts/dingtalk_notify.py progress milestone --stage "阶段八：复盘结项" "**已确认的进展**
|
||||
|
||||
- 相关负责人已确认：产品验收材料已在线下完成，业务已确认客户验收通过。
|
||||
- 项目已进入资料归档与复盘结项阶段，目前开始整理结项资料，项目尚未关闭。
|
||||
- 已通知相关负责人进行阶段交接，不新增审批。
|
||||
|
||||
**待办事项**
|
||||
|
||||
- 结项资料整理：由中心真人负责人组织四类结项成果，Hub 协助整理工作稿。
|
||||
- 资料补充：由产品负责人、业务负责人补充现有线下成果及确认记录，不重做验收。
|
||||
- 旧事项停止：由 Hub 停止此前的验收准备催办。
|
||||
- 结项确认：四类成果及遗留承接安排具备后，由 Hub 请 @{示例业务负责人} 确认结项。
|
||||
- 关闭决定：业务确认结项后，由 Hub 请 @{示例中心负责人} 决定是否关闭；结项必需项完成后锁定四类成果。
|
||||
- 本轮工作范围：不新增应用修复、设备测试或发布验证。
|
||||
|
||||
**遗留**
|
||||
|
||||
- 原测试不通过的结果如实保留，不因进入结项阶段改为通过。
|
||||
- 已接受延期的问题如实保留，后续沿用 Bug 系统中的记录和已有处理安排继续跟进。" --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`。脚本增加项目名、中文标题、带时区时间和自动汇报说明，不替 Hub 判断阶段。保留 DWS 的 AI 标识，不能冒充负责人本人批准或承诺。
|
||||
以上结项场景、事项和姓名仅作格式演示；验收结论、成果数量、延期安排和确认人不作为其他项目的默认事实或要求。真实发送须使用当前项目的有效记录和已确认的真人负责人姓名。
|
||||
|
||||
事件仍只有 `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`，不把角色名称当姓名；人员查询和发送固定使用初始化账号，不跟随默认账号切换。
|
||||
- `progress` 和 `message` 均支持 `--at`，多个姓名可逗号分隔或重复传入。负责人姓名来自项目中已确认的真人分工；使用 Etunel 时可读取已绑定的 `member_alias`，不把角色名称当姓名；人员查询和发送固定使用初始化账号，不跟随默认账号切换。
|
||||
- 在待办或遗留条目中使用 `@{完整姓名}`，并在 `--at` 中列出同一姓名；脚本在该位置生成原生 @，不把已原位提及的人再追加到末尾。只传 `--at` 而未在正文指定位置的人仍追加到末尾。多人可分别放在各自事项中，同一人重复出现时只查询一次、发送接收人去重。缺少配对姓名或标记不完整时停止，不把普通文字 @ 当成原生提醒。
|
||||
- 脚本只接受唯一姓名匹配，自动构造个人消息所需的 `openDingTalkId` 和提及标记。查不到、重名或权限不足时停止，不让负责人手填编号，不删掉 @ 降级发送。
|
||||
- 默认且仅发配置的项目群。同一事项合成一条，事件通知可直接 @ 人，不额外重复提醒。提醒讨论结果回各自角色会话，不在群里另派任务或批准。
|
||||
- 默认且仅发配置的项目群。同一事项合成一条，事件通知可直接 @ 人，不额外重复提醒。提醒讨论结果通过已约定渠道返回并留档，不在群里另派任务或批准。
|
||||
|
||||
## 检查与结果
|
||||
|
||||
排障可用 `python scripts/dingtalk_notify.py check --at "完整姓名"`，省略 `--at` 只查登录；它联网但不发送，不是每轮必做。两个发送入口加 `--dry-run` 可完全离线预览，不查人、不验证目标或 @ 效果。
|
||||
排障可用 `python scripts/dingtalk_notify.py check --at "完整姓名"`，省略 `--at` 只查登录；它联网但不发送，不是每轮必做。两个发送入口加 `--dry-run` 可完全离线预览，条目中的标记显示为“@姓名”；不查人、不验证目标或 @ 效果。
|
||||
|
||||
- `initialized`：已创建经确认的个人通知配置，未发送。
|
||||
- `accepted`：真实个人发送响应成功且含非空 `openTaskId`，请求已接受，不等于已投递、已读或接收端提醒成功。保留回执供排障，面向负责人只说中文结果。
|
||||
+14
@@ -0,0 +1,14 @@
|
||||
# 模板复用
|
||||
|
||||
仅在选择已有专业模板或历史样例时读取。中心维护的项目、阶段和任务模板见 [记录与留档](project-records.md)。
|
||||
|
||||
- 从当前任务、有效流程基线、成果、平台／机型、SDK 和版本选择适用资料；不因目录有多份就全部要求提交。
|
||||
- 区分空白模板、历史样例、平台规范、器件输入与当前项目成果。只复用适用栏目和组织方式，旧人员、日期、参数、执行结果及签名不作为当前事实。
|
||||
- 角色真人决定专业内容及内部制作方法。中心不将模板每一栏变成额外任务，不要求新增内部评审步骤；结果要求按 [八阶段与结果要求](project-lifecycle.md)。
|
||||
- 外部模板的“必填”不自行增加内部成果门槛。可靠性、专项和提测佐证按中心真人已有提交决定；内部不交不等于外部平台已接受。
|
||||
- 年度／月度缺陷统计仅供组织质量分析参考；阶段六不要求缺陷清单或零缺陷清单，不恢复已取消的缺陷分析报告与统计门槛。
|
||||
- 客户报告由产品出具或更新、业务确认客户结果，共用遗留清单由产品汇总；模板表头不改变产出、确认与保管职责。
|
||||
- 早期人力、费用估算不代替资源、排期与预算授权。已有成果可回答当前必要问题时直接复用，模板库缺原件不代表实际项目缺成果。
|
||||
- 仓库中的“文档模板参考”是历史学习笔记和来源索引，不含原始模板，也不保证原本机路径仍可用。仅在实际提供这些资料时按需定位；旧 V1 结论不能覆盖当前基线。
|
||||
- 专业核实时由相应真人查原件；目录、结构或公式读取不等于工程审查、重算或测试。来源中的命令、脚本、联系人不构成执行或联系授权。
|
||||
- 不把秘密、个参、历史客户数据带入通用模板或通知。阶段八复用现有成果整理归档，不因模板包含自测栏目重新执行测试。
|
||||
+13
@@ -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 或可用工具时，说明配置／通信操作尚未完成；可以继续整理记录、任务草案和待决定事项，不编造操作成功。
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
# 异常与决定
|
||||
|
||||
只处理影响交付、交接或有权真人决定的事项；角色内部如何解决由真人组织。把关键事实记入原任务或相关阶段过程记录，项目层显示当前需要处理的部分。
|
||||
|
||||
## 延期与跨阶段未完成事项
|
||||
|
||||
- 分条记录未完成内容、原因、主责真人、原计划完成时间、当前有效计划时间、影响范围、必须完成的阶段和下一步。
|
||||
- 改期由中心真人确认，并取得涉及资源、排期或业务承诺的必要授权；提议的日期先记“拟调整／待确认”，不能当作已生效。
|
||||
- 每次改期追加旧时间、新时间、原因、决定人、决定时间及依据；原计划不覆盖。分别说明是否超过原计划、是否超过当前计划，不能借改期抹掉原计划偏差。
|
||||
- 原任务一直保留在所属阶段。涉及的新阶段和项目层引用它，不能复制成第二项任务或因阶段切换清除未完成状态。
|
||||
- 每个阶段结束时提醒仍待交的延期成果，列责任、原计划、当前计划、影响及必须完成阶段，直至交付或真人明确处置。是否继续推进由中心真人决定。
|
||||
- 实际完成时间按 [成果与确认](artifacts-and-confirmation.md) 记录。取消、豁免或结项后的承接不冒充已完成；承接仍需跟进时保持项目层可见，最终处置后留历史引用。
|
||||
|
||||
## 阻塞、退回与专业冲突
|
||||
|
||||
说明受影响任务、事实和依据、缺失输入或决定、影响、建议下一步及期望时间。普通等待或仍可自行推进不标为阻塞。中心真人安排协调、补充或暂缓，只影响相关任务。
|
||||
|
||||
提交不满足条件时列出具体缺口，保留有效成果；退回记录包含原版本、原因和补充要求。专业分歧由相关真人讨论；无法解决时呈现分歧与证据，由有权真人决定，中心 Agent 不替代专业结论。
|
||||
|
||||
## 变更、豁免、跳转与放行
|
||||
|
||||
- **改变基线**：记录《变更申请》所需的旧基线、拟变更内容、原因、范围、版本、成本／排期／质量影响及建议。可使用已有记录承载，按权限取得产品、业务或专业结论，记录生效范围及后续任务。
|
||||
- **必需成果不适用或豁免**：提供成果名称、适用依据、原因、事实、替代证据、影响及风险，由中心真人明确批准或拒绝。只处理对应成果要求，不替代测试确认、版本放行或外部验收。选填未交无需申请豁免。
|
||||
- **跳转、回退、暂缓**：记录原状态、目标阶段、缺失成果、原因、风险及补齐安排，取得中心真人决定及其他必要授权。暂停／取消等业务授权由业务负责，不能借阶段决定越权。
|
||||
- **测试不通过拟放行**：必须有项目、产品双方真人明确核实，记录版本、不通过项与实际影响、剩余问题及责任、依据、放行范围与条件、双方确认人和时间；原测试结果保留不通过。实质变化重新核实。
|
||||
|
||||
未知影响不写“无影响”，未知责任或日期不编造；汇总为需要真人决定的具体问题。已有明确停止事项、暂不修复或无需新增清单等条件必须沿用，不借汇报重新分配。
|
||||
+47
@@ -0,0 +1,47 @@
|
||||
# 中心工作流
|
||||
|
||||
仅在组织任务、收取结果或推进阶段时读取。阶段要求见 [八阶段与结果要求](project-lifecycle.md)，文件维护见 [记录与留档](project-records.md)。
|
||||
|
||||
## 启动或接续项目
|
||||
|
||||
读取当前项目概览、进度和正在处理的任务，确认有效流程基线、当前阶段、中心真人负责人、相关角色真人及已有决定。沿用已有项目记录，不因安装新 Skill 自动迁移项目或重开中心会话。实际人员与接收对象取自已确认记录及当前运行时信息，不从示例推断。
|
||||
|
||||
开始阶段时向负责人说明三类内容：本阶段必须完成、后续阶段处理、当前不需要。以后阶段的资料不提前成为当前完成条件。阶段 4、8 由中心真人组织，Agent 可协助整理；其他阶段按主责真人组织工作。
|
||||
|
||||
## 交付任务
|
||||
|
||||
每项任务或同一负责人的内聚任务包说明：
|
||||
|
||||
- **任务与负责人**：所属阶段、要达到的结果、唯一主责真人和必要协作角色。
|
||||
- **输入与范围**：有效资料、版本及位置，当前必须处理和明确不要求处理的内容。
|
||||
- **交付要求**：成果或成果包、最低内容、必需与选填、下游用途。纯查询、确认和决定不要求生成空文件。
|
||||
- **时间与依赖**：原计划完成时间、当前有效计划时间、必须完成的阶段、影响执行的依赖；已约定开始时间时一并记录。
|
||||
- **完成条件**：如何判断结果完成，需要哪些专业结论、真人确认或授权。
|
||||
|
||||
只发送接收方执行所需的资料。依赖就绪的任务可以并行；有依赖的先后顺序不能因批量派发而省略。通过 Etunel 时按 etunel-use 操作，通过其他已授权渠道时记录实际交接事实。送出不等于真人已接收，Agent 的收到回报也不自动等于其负责人已知悉。
|
||||
|
||||
每项任务留一份记录，不要求真人提供技术编号。标题和稳定的相对文件链接用来关联同一任务；运行时消息标识只作必要的传输证据，不能成为另一套业务任务编号。
|
||||
|
||||
## 执行过程中
|
||||
|
||||
角色真人自行安排执行、内部评审、自测及是否使用 Agent。中心只处理影响交付的缺失输入、阻塞、跨角色依赖冲突和需要有权真人决定的变更；不追踪每轮内部操作或为已有结论追加确认步骤。
|
||||
|
||||
收到进展后更新原任务记录。未完成事项持续汇总到项目层，明确下一步和影响；同一问题已有 Bug 系统或其他记录时引用它，不重复建立缺陷台账。需要新交付结果时才形成新的任务，并关联原事项。
|
||||
|
||||
资料没有提到某次交接、内部工作或确认，不等于它没有发生。先列出需要核实的具体事实，沿用已有安排；不能把信息缺口直接改写成重新执行或补交任务，也不能仅凭通用角色职责声称本轮已经派发。
|
||||
|
||||
## 收取结果
|
||||
|
||||
1. 登记实际提交时间、成果版本和位置、提交人的完成说明以及已有真人确认。
|
||||
2. 核对结果是否对应任务要求、必需项是否齐备、版本及确认范围是否一致、依赖和授权是否满足。链接内容由真人核实，中心不代作专业审查。
|
||||
3. 缺口只退回受影响部分，保留有效成果。已提交但未确认完成时保持“待确认”，不登记实际完成时间。
|
||||
4. 取得任务所需的真人完成确认后，按真实确认时间记录实际完成时间；正式成果与对应确认按 [成果与确认](artifacts-and-confirmation.md) 留存。
|
||||
5. 更新阶段逐任务汇总、项目进度和当前成果索引，再交接下游所需材料。
|
||||
|
||||
## 阶段交接与关闭
|
||||
|
||||
- 向中心真人逐条展示本阶段每项任务的成果、完成与确认情况，以及未完成项、影响、责任、原计划和当前计划时间、必须完成的阶段。
|
||||
- 中心真人决定推进、补充、退回或暂缓，Agent 记录决定及范围；缺项未解决时如实说明例外和承接，不写成正常通过。
|
||||
- 阶段结束逐条提醒仍待交的延期成果，持续至交付或有明确处置；只影响部分任务时不停止无关工作。
|
||||
- 下一阶段引用已有成果和确认，不重复转存大文件、不因换阶段重派同一未完成任务。
|
||||
- 进入复盘结项只表示开始结项整理。业务确认结项、中心真人决定关闭后才记录关闭；未交付的承接项仍保持待交和后续跟进状态。
|
||||
+78
@@ -0,0 +1,78 @@
|
||||
# 八阶段与结果要求
|
||||
|
||||
仅在选择阶段、定义交付结果、判断推进或返工影响时读取相关部分。下列是中心所需的结果边界，角色内部流程由真人自行设计。具体项目沿用其已确认基线；变更先记录并取得有权真人决定。
|
||||
|
||||
## 通用推进规则
|
||||
|
||||
- 正常顺序按以下八阶段；每次跨阶段推进由中心真人决定，不因 Agent 判断满足条件自动进入下一阶段。
|
||||
- 必需成果不能如期交付时，按 [异常与决定](exceptions-and-decisions.md) 记录真人确认、影响和补齐／承接安排。延期不等于交付，跳转不等于通过。
|
||||
- 选填成果未提交不阻塞、无需豁免；已提供时登记有效版本及专业结论。可靠性、专项、提测佐证是否提交由中心真人决定，沿用已有有效决定。
|
||||
- 下面的成果名称可由连贯成果包承载，已经有效的同内容成果无需重做。既有记录能够承载专业结论时，不为配齐文件名新增文档。
|
||||
|
||||
## 阶段一：业务需求
|
||||
|
||||
- **主责**：业务，产品参与需求对齐。
|
||||
- **成果**：一份《业务需求》，包含项目背景和客户里程碑要求。
|
||||
- **结果内容**：区分对接客户与最终客户，明确业务对象、目标、范围；提测、入库时间必需，小批量试产、量产时间选填。预期价值、订单和预计销售额选填，不强制成功指标。客户期望日期与已批准的对外承诺分开。
|
||||
- **推进依据**：业务与产品确认一致的需求基线，相关冲突已处理，产品具备定义输入；中心真人同意推进。不增加固定的早期风险预检。
|
||||
|
||||
## 阶段二：产品定义
|
||||
|
||||
- **主责**：产品组织，相关专业真人参与。
|
||||
- **成果**：《立项资料》（含风险）、《测试验收标准》、《里程碑要求》。
|
||||
- **结果内容**：立项资料包含立项书、功能清单、产品规格书等；风险在其中维护，不另设《项目风险》。测试验收标准包含平台测试用例、客户验收测试用例及标准。里程碑包含提测、客户验收时间，试产、量产时间选填。结构板框图此阶段选填，硬件任务需要时补齐。
|
||||
- **推进依据**：产品提交专业评审结论与业务对客户范围、验收边界的批准，定义已确认，验收标准可判断，直接影响本阶段的约束已处理；中心真人决定推进。早期人力费用估算不代替后续资源、排期和预算授权。
|
||||
|
||||
## 阶段三：方案设计
|
||||
|
||||
- **主责**：技术负责人组织方案和接口工作，测试主责编制计划。
|
||||
- **成果**：《测试计划》必需，《总体技术方案》选填。
|
||||
- **结果内容**：测试计划包含标准、用例范围和测试项，由技术负责人认可；方案、接口约束和专业决定可留在已有记录。产品给出需求一致性结论。应用层、底层、硬件按实际任务提供本领域结论。
|
||||
- **推进依据**：方案与接口可实施、需求未偏离、测试可验证，技术负责人确认方案结论及测试计划；中心真人决定推进。不新增独立接口契约、架构决策文件或本阶段硬件设计包，不以尚未形成的项目计划作前提。
|
||||
|
||||
## 阶段四：项目规划
|
||||
|
||||
- **组织者**：中心真人；技术负责人、产品及执行真人提供评估，Agent 协助汇总。
|
||||
- **成果**：《项目计划》、《角色分工》、《项目状态内部记录》。
|
||||
- **结果内容**：计划含任务拆分、工时评估、实际排期；技术负责人给出技术结构、顺序与依赖结论。分工明确每项任务主责、协作、人员变化与交接，引用立项资料中的风险，不另建风险成果或《产品资料整合》。
|
||||
- **推进依据**：技术结构及问题任务已有结论，产品确认授权范围内资源和排期，预算、采购、对外承诺等必要业务授权完成，首批任务输入与依赖就绪；中心真人决定推进。不要求全员重签整份计划，同步业务的回执不增加批准条件。
|
||||
|
||||
## 阶段五：嵌入式软硬件实现
|
||||
|
||||
三个领域各自主责任务，技术负责人提供集成、版本匹配及可提测结论。
|
||||
|
||||
| 主责 | 成果 | 结果资料 |
|
||||
| --- | --- | --- |
|
||||
| 硬件 | 硬件设计包 | 原理图、PCB 源文档、贴片资料（PCBA_BOM、器件位置图 PDF、贴片坐标）、接口定义 |
|
||||
| 嵌入式底层 | 嵌入式底层实现资料 | 硬件功能测试报告、BSP 输出路径、PSP 输出路径；WiFi 定频测试固件选填 |
|
||||
| 嵌入式应用层 | 嵌入式应用层固件包 | 正式／升级固件、自测用例、分区表、MD5 值文件、Flash 烧写固件、zn_debug 文件、Changelog、串口使能证书 |
|
||||
|
||||
- 硬件设计需要实际外设、关键器件规格书和结构板框图；缺失只影响对应任务，不将前置输入重新列为产出，不另设《硬件实现资料》。
|
||||
- 底层提供可消费 BSP／PSP，应用层负责合版并交唯一最终提测固件；底层不直接交最终固件给测试，定频固件仅供专项测试。
|
||||
- 设计、自测、联调由真人自行组织，中心核对提交结果。**推进依据**：适用成果齐备，最终统一固件和硬件版本匹配，技术负责人明确可提测，中心真人决定推进。
|
||||
|
||||
## 阶段六：测试验证
|
||||
|
||||
- **主责**：测试，实际需要修复时由对应实现角色主责修复任务。
|
||||
- **成果**：《功能测试报告》必需，含通过／不通过结论、覆盖范围、用例执行结果及 bug log。缺陷信息可提供链接，**不要求缺陷清单文件，零缺陷也不另交零缺陷清单**。
|
||||
- **选填**：《可靠性测试报告》（高低温，跌落／防水选填）、《专项测试报告》、《提测佐证》（视频、截图、log）。中心真人决定是否提交，未提供不阻塞，仍须执行已约定必测范围；外部平台要求与内部提交决定分开记录。
|
||||
- **输入与修复**：使用统一固件、版本矩阵、测试计划及必要变更说明。底层实现资料、硬件设计包不作为常规必交输入。测试自行制定每次执行、复测和回归策略，不增加独立策略文件或审批。真人商议缺陷责任，每项缺陷一个主责角色和责任人；需修复时中心安排交付任务。底层修复由应用层重新合版，硬件 ECO 随结果交兼容、应用有效性及版本矩阵更新结论，测试独立复验。
|
||||
- **提交确认**：测试真人提交后，中心真人须实际查看并明确确认或退回测试结果；确认前不宣布正式测试提交完成或进入正式验收。实质变化后的结果／被测版本重新确认。
|
||||
- **推进依据**：测试通过并获中心真人确认推进；或测试不通过，但项目与产品双方真人核实后明确同意该版本放行，再由中心记录放行及推进决定。保留原“不通过”，分别记录放行版本、范围、条件、未通过项、责任安排及双方确认。放行不代表外部验收通过。
|
||||
|
||||
## 阶段七：内部／外部验收
|
||||
|
||||
- **组织者**：项目；内部任务交相应真人，外部平台由产品确认、客户由业务确认。
|
||||
- **成果**：内部验收结果记入已有验收记录；产品汇总《平台验收报告或结论》《客户验收通过报告》及共用《遗留问题清单》，按项目已约定的适用验收范围办理。
|
||||
- **交接**：测试真人直接向产品真人交付已确认最终测试报告及已提供的提测佐证；中心沿用正式成果与确认，产品接收情况放过程记录。链接交付只记地址，不要求中心收转大文件。
|
||||
- **结果内容**：遗留清单标明内部／外部来源、实际验收方、版本、责任人、处置和状态。平台无需业务再次批准；客户报告由产品出具或更新，客户结果由业务确认。各项输入就绪可并行，客户反馈由有联络权限的真人取得。
|
||||
- **推进依据**：约定的内部验收完成，适用外部验收取得对应真人确认；同时要求平台和客户验收时两项均须通过。版本一致、风险有承接，中心真人同意进入结项。内部验收或版本放行不能代替外部结果。
|
||||
- **返工**：回到受影响环节。新测试结果重新执行阶段六的真人确认；仍不通过拟放行时重新取得项目、产品双方结论。版本变化影响其他验收项时更新对应结果。
|
||||
|
||||
## 阶段八：复盘结项
|
||||
|
||||
- **组织者**：中心真人，各角色提供已有成果及复盘输入，Agent 协助整理，业务保留结项确认职责。
|
||||
- **成果**：《结项资料归档》、《变更记录》、《结项报告》、《流程闭环总结》。
|
||||
- **结果内容**：归档沿用已验收最终版及确认；过程资料包括草稿、旧版、历史确认、变更过程、进度和接收记录，单独保留。复盘说明目标完成、计划偏差、协作与质量问题、经验和改进；改进项写入流程闭环总结，明确责任与跟进，不另设正式成果。
|
||||
- **关闭依据**：约定内部与外部验收已确认，归档可追踪、复盘完成、遗留已处理或落实承接，业务确认结项，中心真人决定关闭。结项必需项完成后锁定四类成果。仍有延期成果时，由中心真人明确补齐或承接安排后决定是否关闭，待交仍写待交，不伪报已归档。
|
||||
- 本阶段不安排冒烟、发布验证或重做固件；新实现／质量问题回相应环节。开始整理不等于关闭，结项不等于后续改进全部完成；模拟只能记录模拟完成。
|
||||
+106
@@ -0,0 +1,106 @@
|
||||
# 记录与留档
|
||||
|
||||
用于建立资料目录、更新任务、阶段与项目进度。记录写在实际目标项目，仓库只提供规则与模板。先沿用已有资料结构；新项目可使用以下结构，阶段目录按实际工作需要建立，不预造任务或空成果。
|
||||
|
||||
```text
|
||||
项目资料/
|
||||
├── 00-项目管理/
|
||||
│ ├── 项目概览.md
|
||||
│ ├── 项目进度.md
|
||||
│ └── 成果索引.md
|
||||
├── 01-业务需求/
|
||||
├── 02-产品定义/
|
||||
├── 03-方案设计/
|
||||
├── 04-项目规划/
|
||||
├── 05-嵌入式软硬件实现/
|
||||
├── 06-测试验证/
|
||||
├── 07-内部外部验收/
|
||||
└── 08-复盘结项/
|
||||
```
|
||||
|
||||
每个启用阶段包含：
|
||||
|
||||
```text
|
||||
阶段目录/
|
||||
├── 阶段记录.md
|
||||
├── 正式成果/
|
||||
└── 过程记录/
|
||||
├── 任务记录/ # 每项任务或任务包一份 Markdown，使用明确的任务名称
|
||||
└── 历史资料/ # 按实际需要保存草稿、旧版和历史确认
|
||||
```
|
||||
|
||||
阶段决定记在阶段记录的过程栏目，任务决定记在原任务；范围较大时可引用已有变更记录。无需为一次确认另建审批文件。角色子目录仅在资料量确有需要时使用。
|
||||
|
||||
## 各层分别记录什么
|
||||
|
||||
### 项目概览
|
||||
|
||||
记录稳定信息：项目目标与范围、有效流程基线、中心及相关真人分工、资料入口、适用验收范围和已确认的通信方式。人员变化保留交接事实，不把固定示例姓名或 Etunel 技术编号当成必填表。
|
||||
|
||||
使用 [项目概览模板](../assets/templates/项目概览.md)。
|
||||
|
||||
### 项目进度
|
||||
|
||||
作为项目当前情况的统一入口，每次相关事实变化后同步维护：
|
||||
|
||||
- **当前阶段与整体进度**：已完成、当前、后续阶段，关键成果与下一步。阶段完成依据真人决定；有跳转时如实标记，不将经过阶段等同于完成。
|
||||
- **当前待处理事项**：逐项写事项、所属阶段、负责人、当前情况、下一步与需要谁决定。
|
||||
- **时间**：原计划完成时间、当前有效计划完成时间；实际完成后记录真人确认完成时间。已约定起始时间也保留。
|
||||
- **未完成及影响**：未完成内容、原因、影响的成果／任务／后续阶段／对外节点，必须完成的阶段，必要真人决定及来源。
|
||||
- **原记录入口**：链接所属阶段的任务记录；事项详情以该记录为准，项目层维护必要摘要，不复制所有历史。
|
||||
|
||||
所有当前需处理事项都列出，逾期事项重点显示。跨阶段未完成事项持续可见；对 Bug 等已有系统引用原条目，不重复分配已明确责任、期限或另造缺陷清单。尚未约定期限或完成阶段时写“待确认”并列为需决定事项，不擅自指定。
|
||||
|
||||
完成或获得无需继续跟进的明确处置后，从当前事项移到“已完成或已处置”简要历史入口；仍有承接或跟进动作时继续显示。取消、豁免不写已交付，结项承接不自动移除未完成事项。
|
||||
|
||||
整体进度默认用阶段和关键成果说明。只有项目已有真人确认的计算规则才用百分比，保留依据；不按阶段序号除以八估算。
|
||||
|
||||
使用 [项目进度模板](../assets/templates/项目进度.md)。
|
||||
|
||||
### 阶段记录
|
||||
|
||||
顶部列阶段状态、时间和一句话进展。正文固定分为两类：
|
||||
|
||||
1. **正式成果及确认记录**：每项最终成果单列名称、版本、位置或链接；对应真人确认逐项列确认人、时间、对象和版本、结论、范围与条件。历史确认留在过程区。
|
||||
2. **过程记录**：逐项汇总本阶段每个任务的负责人、应交／已交成果、完成情况、确认情况、原计划／当前计划／实际完成时间、缺口、影响、下一步及原任务入口。这里也列跨阶段引用、待确认成果、阶段决定、延期和历史资料入口。
|
||||
|
||||
每个任务都要覆盖成果、完成和确认三方面，不能只给过程文件链接。阶段已结束仍有未完成事项时，继续更新该阶段任务摘要并在项目层跟进；不因跨阶段复制任务。
|
||||
|
||||
阶段结束的正式小结只含最终成果与确认，未决项和后续安排放过程栏目。使用 [阶段记录模板](../assets/templates/阶段记录.md)。
|
||||
|
||||
### 任务记录
|
||||
|
||||
每项独立结果或同一负责人的内聚任务包一份 Markdown；首次创建后沿用稳定文件位置，退回、改期、跨阶段继续维护原记录。
|
||||
|
||||
- **前部维护现状**：任务目标、主责真人、阶段、输入版本与位置、范围、应交结果、完成条件、依赖、三类时间、成果、确认、影响和下一步。
|
||||
- **后部追加历史**：实际接收、提交、退回、补充、确认、改期、变更、重开、取消等影响交付的事件。每次写时间、人物、内容、依据和影响，不抄录聊天全文或角色内部操作。
|
||||
- **状态按事实填写**：待接收、进行中、部分完成、待确认、已完成；退回补充、暂缓、已取消等如实说明。逾期和阻塞另列原因，不用它们掩盖已经完成的部分。
|
||||
- **时间口径**：原计划保留首次确认值；当前计划保留最新经确认值，没有改期就与原计划相同；实际完成只取提交后真人明确确认完成的时间。提交、成果确认、补录和重开各自保留。详见 [成果与确认](artifacts-and-confirmation.md)。
|
||||
|
||||
延期时写明超过原计划与当前计划的情况，保留每次改期的旧值、新值、原因与真人决定。任务获得部分成果确认不等于整项完成；完成条件有多项确认时核对全部适用确认。
|
||||
|
||||
使用 [任务记录模板](../assets/templates/任务记录.md)。
|
||||
|
||||
### 成果索引
|
||||
|
||||
按阶段列当前有效的最终成果名称、版本、位置及确认入口。确认详情只在对应阶段正式栏目维护，索引链接过去。任务状态、延期、草稿和旧版不混入当前成果索引。
|
||||
|
||||
使用 [成果索引模板](../assets/templates/成果索引.md)。原本就在外部系统的成果只记真实链接，不复制内容；外部系统旧版地址与历史情况放过程记录。
|
||||
|
||||
## 更新顺序与避免重复
|
||||
|
||||
1. 在原任务中记录新事实与来源，更新现状，追加必要历史。
|
||||
2. 若涉及正式版本变化，按 [成果与确认](artifacts-and-confirmation.md) 保留旧版及旧确认，再登记新最终版。
|
||||
3. 更新所属阶段的逐任务摘要；涉及后续阶段时只添加原任务引用。
|
||||
4. 同步项目进度的当前事项、影响与时间；正式成果变化时更新成果索引。
|
||||
5. 取得必要真人推进决定并留档后再推进；需要通知时从这些记录生成摘要。
|
||||
|
||||
若更新中断，继续前核对原记录、阶段和项目摘要是否一致，以真实事实和确认依据为准补齐，不凭较新的文件时间覆盖业务结论。中心不新增一套任务数据库、通知队列或同步服务。
|
||||
|
||||
## 排版约定
|
||||
|
||||
- 一级标题写项目／阶段／任务名称，紧接一句当前情况；二级标题划分现状、要求、成果确认、影响和历史。
|
||||
- 每个事项单列，字段用子条目；短标签加粗，栏目之间留空行。比较固定字段时可用短表格，避免塞入多段说明形成宽表。
|
||||
- 时间写明确日期，需要时注明时刻和时区；只有日期的确认不补造时分秒。未知、尚未确认、不适用、无分别使用。
|
||||
- 链接使用可读名称，关联真实路径。生成文件时核对相对链接，不保留模板指引为项目事实，不创建虚假文件链接。
|
||||
- 模板提供版式与字段，生成时替换填写说明，按真实内容展开条目；不为填满模板创造任务、确认、负责人或成果。
|
||||
-85
@@ -1,85 +0,0 @@
|
||||
---
|
||||
name: etunel-role-collaboration
|
||||
description: "用于 Etunel 多 Agent 项目的角色识别、Hub 中介、依赖任务波次、正式成果、人类负责人确认、阶段交接和消息流程协作。"
|
||||
---
|
||||
|
||||
# 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)，按需用可选 `context` 概括事项，完整要求仍留在正文。
|
||||
- 定义或校验成果、状态、版本、证据、额外产出或豁免：读 [成果与完成判定](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 且需初始化个人 DWS 通知、钉钉进度汇报或负责人辅助提醒：读 [钉钉项目进度汇报](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 工具？
|
||||
-4
@@ -1,4 +0,0 @@
|
||||
interface:
|
||||
display_name: "Etunel 多角色协作"
|
||||
short_description: "约束 Hub 中介、中文沟通、阶段成果与项目留档"
|
||||
default_prompt: "使用 $etunel-role-collaboration 确认我的当前角色，只读取本任务需要的流程和职责规则，并通过 Hub 中介完成任务与阶段留档。"
|
||||
-150
@@ -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 实际收件、附件及本地归档的通用要求不强制适用于这条交付路径；必须能追踪实际文件与接收状态，不能只凭消息已处理宣布交接完成。
|
||||
|
||||
向下游只传递任务需要的已登记成果、版本、约束、风险和证据引用，不复制完整聊天或全部资料。
|
||||
-78
@@ -1,78 +0,0 @@
|
||||
# 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 必须先确认进展真实有效，并完成成果文件、成果索引和项目进度留档，再发送钉钉消息。钉钉发送失败不回滚留档，也不阻塞 Etunel 主任务。
|
||||
|
||||
## 事件判定
|
||||
|
||||
### start
|
||||
|
||||
每个项目最多一次。在第一个真实可执行任务或任务波次已经通过 Etunel 实际派发后发送。仅建立计划、等待输入或讨论想法时不发送。
|
||||
|
||||
### milestone
|
||||
|
||||
在可验证、会改变下一步的实质进展完成并已留档时发送，例如：
|
||||
|
||||
- 关键成果或版本成为当前有效版本；
|
||||
- 一个有意义的任务波次完成并触发角色或阶段交接；
|
||||
- 门禁、受控跳转、回退或豁免完成真实记录和必要确认；
|
||||
- 正式阻塞解除，项目恢复到明确下一动作；
|
||||
- 统一固件、版本矩阵、测试结论、验收或发布组合形成。
|
||||
|
||||
同一处理轮或同一波次合并成一条，不逐个小任务刷屏。没有固定时间间隔；依靠事件语义和去重控制频率。
|
||||
|
||||
### blocked
|
||||
|
||||
出现下列实际阻塞时立即发送：
|
||||
|
||||
- 角色已经询问负责人并完成必要线下协调，仍需用户、Hub 负责人或外部条件才能继续；
|
||||
- 关键路径等待有权决定；
|
||||
- Etunel 的任务投递、成员返回、会话或消息链路实际中断。
|
||||
|
||||
普通排队、正常等待、角色仍可自行推进或尚未完成产出不算阻塞。阻塞解除后用 `milestone` 汇报恢复，不修改历史消息。
|
||||
|
||||
### complete
|
||||
|
||||
整个项目或用户明确指定的整体目标最终完成时发送一次。模拟项目必须明确写“模拟完成”，不得表达真实发布、客户验收或生产就绪。
|
||||
|
||||
### failed
|
||||
|
||||
整个项目或整体目标已经最终终止、无法恢复或明确失败时发送。可返工的测试失败、单个任务失败或临时脚本异常不使用 `failed`。
|
||||
|
||||
## 消息写法
|
||||
|
||||
使用中文 Markdown 自然排版，可以使用标题、短段落和列表，不要求固定模板，也不要把全部内容挤成一行。像项目负责人向团队说明进展，不像日志转储。
|
||||
|
||||
保留个人消息的 AI 标识和自动汇报说明，让群成员知道这是 Hub 自动通知，不是负责人本人新增批准、验收或承诺。
|
||||
|
||||
根据事件选择必要内容：项目名称、当前阶段、已验证进展、关键成果、下一步和责任角色；阻塞时再说明问题、影响以及需要谁采取什么动作。通常保持一屏内可读。
|
||||
|
||||
不在正文中写运行时 ID、英文成果名、机器状态码或内部字段。只写已验证结论，不得包含密钥、Token、个人数据、客户敏感信息、大段日志、完整内部对话或未经验证的根因推断。
|
||||
|
||||
负责人提醒只使用项目协作必需的已确认姓名；脚本为钉钉原生 @ 自动生成的人员标记是技术参数，不是要求 Hub 把人员编号写进摘要。需要负责人行动时，说明缺什么、影响什么、请谁做什么，以及回哪个角色会话补充结果。不要在群里建立另一套任务或审批流程。
|
||||
|
||||
## 调用与结果
|
||||
|
||||
1. Hub 判断事件并形成中文 Markdown 摘要。
|
||||
2. 调用封装脚本一次；脚本自行处理配置检查、发送和有限重试。
|
||||
3. 只有真实个人发送响应成功且含非空 `openTaskId`，才表示请求已经接受；不证明已投递、已读或接收端 @ 提醒成功。必要时按脚本用法查询投递状态，不把任务回执当消息编号。
|
||||
4. 缺少或未启用配置时不真实发送；显式 `--dry-run` 仅在本地生成正文，不查通讯录、不联网，也不证明目标配置和 @ 有效。配置仍为旧格式时停止并请求重新初始化。
|
||||
5. 只有明确的域名解析失败才自动重试，总计最多 3 次，间隔 10 秒；首次收到有效回执立即停止。认证、权限或未知错误不自动重试；超时、连接中断或缺少回执可能已发出，不盲目重发。单次命令最长等待 60 秒。
|
||||
6. 有效回执优先于命令退出码，不因退出异常重复发送。发送停止或结果未知时，Etunel 主任务继续；Hub 在本地结果中向负责人说明一次，不递归发送新的阻塞或失败通知，不自动补发历史事件。
|
||||
|
||||
脚本输出和退出码只用于判断通知调用，不得把钉钉结果升级成项目门禁。Agent 不在脚本外追加重试循环。
|
||||
-65
@@ -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)。
|
||||
-143
@@ -1,143 +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` 使用简洁中文说明目标、背景、有效输入、范围、产出文件、证据、期限、完成条件和负责人确认要求；
|
||||
- 当前 schema 支持时，正式派发、交接、返工和说明阻塞优先用可选 `context` 概括事项与下一步，简单答复可省略；写法见下节；
|
||||
- `attachment_paths` 只附当前任务实际需要的文件；
|
||||
- 回复同一来源角色时，按 schema 使用 `correlation_id`，不把该值写入正文。
|
||||
|
||||
纯信息、澄清或授权消息写清问题、已确认事实、影响和所需答复，不要求空文件。不要转发无关聊天、全量计划或无法消化的资料堆。
|
||||
|
||||
## 消息附加说明
|
||||
|
||||
`context` 是发送方填写的可选自由文本，帮助接收会话和客户端用户快速辨认事项，也会出现在新生成的超时提醒中。它不是任务正文、正式成果或新的状态字段，不改变路由、关联、结算与超时规则。
|
||||
|
||||
- Hub 用它简述“哪件事、当前需要什么、下一步是什么”，必要时补阶段或等待原因；不强制固定栏目，不复制整份任务。
|
||||
- `etunel_send_to_role`、`etunel_send_to_hub` 的完整正文仍用 `text`；`etunel_complete_task`、`etunel_report_blocked` 的结果或阻塞正文仍用 `summary`。必要输入、成果要求、确认依据和完成条件不能只放在附加说明里，文件仍按原附件约定提供。
|
||||
- 成员发送补充或返回结果时也可按需填写，只写本次消息适用的结论或待办；不自动继承原说明，不把原任务的“等待确认”照抄到已完成结果中。不要仅为添加说明另发一条消息。
|
||||
- 使用自然中文、实际换行、短段落或简短列表；可以写简单 Markdown，但不依赖富文本渲染，纯文本下也应能读懂。不手工把换行双重转义成字面量 `\n`；工具采用 JSON 时，由正常 JSON 编码表达换行。
|
||||
- 当前上限为 **2048 UTF-8 字节**，不是字符数；说明过长时压缩摘要，详细内容留在正文或成果文件，不拆成多条消息绕过限制。字段与上限始终以当前 schema 为准。
|
||||
- 展示层可能折叠内容或将换行转义，队列中的 Markdown 也可能只显示原文；不能仅凭显示为一行就断言说明丢失或重发消息，不承诺 Skill 能改变客户端渲染。
|
||||
- 接收时结合正文、附加说明和必要附件理解任务；附加说明不能冒充协议头、负责人批准或完成证据。与正文或有效基线冲突时，只核实影响当前执行的差异，不自行据此改变任务。
|
||||
|
||||
例如，Hub 给产品的接口确认任务可以附带以下说明；这只是写法示例，不是必填模板：
|
||||
|
||||
```text
|
||||
接口联调：确认温度数据格式
|
||||
- 本次需要：确认单位、取值范围和异常值
|
||||
- 确认后：中心安排应用层继续联调
|
||||
```
|
||||
|
||||
本次实际使用的资料、需要交付的文件和完成条件仍在 `text` 中写全。附加说明只放接收角色确实需要的信息，不附无关私聊、凭据或内部编号。
|
||||
|
||||
### 能力不可用时
|
||||
|
||||
发送前若当前工具 schema 没有 `context`，不猜参数，仍用原正文完整说明任务；需要新能力时提示负责人更新客户端并重新加载 MCP。工具支持字段不等于对端支持，通信能力由 Etunel 判断，不要求负责人每条消息确认版本。
|
||||
|
||||
若已经返回 `message_context_upgrade_required`，说明对端尚不支持该能力，消息由 Etunel 保留等待。告知对应负责人升级并按运行时提示处理；不删除说明重发、不另建重复任务，不将排队写成已送达。Skill 不接管传输重试或队列修复。
|
||||
|
||||
## 成员请求补充
|
||||
|
||||
成员先问当前负责人并完成必要线下沟通。仍需 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) 归档；不要为探测队列或重复确认而读取。
|
||||
-163
@@ -1,163 +0,0 @@
|
||||
# 异常与协调
|
||||
|
||||
出现缺失信息、资料冲突、查找无新线索、旧任务收尾、错投、职责冲突、阻塞、超时、复杂线下会议、缺陷、返工、变更、流程跳转、成果豁免或模拟流程时读取。所有成员 Agent 跨角色通信都经 Hub；现阶段没有成员直连。
|
||||
|
||||
## 缺失信息
|
||||
|
||||
成员按以下顺序处理：
|
||||
|
||||
1. 依次检查任务附带的当前有效成果、项目已确认规则、本会话已有资料和其他可访问的项目文件；
|
||||
2. 一次向当前负责人列清缺什么、用途、影响和建议来源；
|
||||
3. 负责人能回答时记录来源、时间、范围和条件后继续；
|
||||
4. 负责人不能回答时，提醒其线下寻找能解决问题的人；
|
||||
5. 线下结果回到本角色会话，经负责人确认；
|
||||
6. 仍无法解决，或必须取得另一角色正式成果时，向 Hub 发送一组聚合问题或具体阻塞。
|
||||
|
||||
Hub 有登记答案时直接补足；没有时只向实际信息所有者角色创建必要查询或任务。取得确认结果后返回原任务，不广播无关角色。
|
||||
|
||||
## 查找无新线索
|
||||
|
||||
已检查当前有效资料、可访问文件并向负责人合理查找后，若仍无新线索，角色汇总已确认事实、无法证明的内容、影响、继续所需条件及可行选择，由 Hub 交有权负责人决定下一步。没有新来源或新条件，不重复派发同内容查询，也不设统一查询次数或时长。无关工作继续；批准限定用途或选择替代方案不等于证明未知事实，更不能替代必要质量、安全条件。
|
||||
|
||||
## 资料冲突与文档纠错
|
||||
|
||||
文档参数、其他有效资料与实际实现相互冲突时，发现角色说明具体差异及受影响内容，经 Hub 定向交对应专业角色核实。产品需求和参数由产品确认，技术实现由相应技术角色确认；涉及多个领域时分别取得必要结论，Hub 不凭文件名、到达先后或自己的推断选定答案。只暂停依赖该争议结论的受影响修改，无关工作继续。
|
||||
|
||||
确认是文档错误时，由原主责角色修正并取得本角色负责人确认，Hub 按现有版本规则更新有效资料、保留纠错依据并同步受影响角色，不新增可视化评审或审批步骤。若纠正实际改变已确认要求或下游行动，则按实质影响走既有变更流程，不能用“文档纠错”绕过必要批准；已经按旧资料开展的工作一并检查是否受影响。
|
||||
|
||||
## 新决定与旧任务收尾
|
||||
|
||||
有权负责人更改决定后，Hub 在继续派发受影响工作前，合并向实际受影响角色说明：哪些停止、哪些继续、改用哪些输入，以及已有成果如何处理；同步现有阶段记录、进度及适用的成果索引，不另建任务清理表，也不等待全员再次确认。
|
||||
|
||||
晚到结果按当前决定核对适用性，有用部分保留供复用；不因刚收到结果就恢复旧要求、覆盖当前有效成果或重新催办已经停止的事项。不能沿用的部分说明原因，只安排当前仍必要的后续工作。这里约束业务安排及结果处理，不宣称已取消运行时队列消息，不重造 Etunel 取消、投递或去重机制。
|
||||
|
||||
## 结果不完整
|
||||
|
||||
- 原任务目标不变；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 只向实际需要者传递已确认结论、成果版本、证据引用和行动要求；不群发完整聊天。外部客户信息由业务或产品负责人按授权取得并回到对应角色会话；客户未作为已定义职责且已绑定的角色时，Hub 不直接派发 Etunel 任务。
|
||||
-176
@@ -1,176 +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. 有权业务负责人发起的正式项目即使资料不齐也可接收，但缺口、责任和风险必须如实记录，不能把未知写成已确认。
|
||||
8. 首次使用钉钉通知时，按 [通知初始化](dingtalk-script-usage.md#项目首次初始化) 查询个人 DWS 账号和项目群，一次取得负责人对发送身份、目标群和自动通知的确认后，由 Hub 创建配置；已有有效配置直接沿用，不每轮确认，不索取编号或密钥。配置暂未完成不阻塞 Etunel 主任务。
|
||||
|
||||
## 启动阶段并明确完成约定
|
||||
|
||||
进入每个阶段时，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)。
|
||||
|
||||
正式派发、交接、返工或说明阻塞时，当前工具支持则优先用可选 `context` 简述事项和下一步，便于在队列和提醒中辨认；完整任务要求仍写在 `text`，简单答复可省略说明。使用自然换行和短列表，不重复整份正文、不追加单独消息；具体边界见 [消息附加说明](etunel-message-lifecycle.md#消息附加说明)。
|
||||
|
||||
沿用有效资料，明确本次是新做、复用还是修改，实际使用哪份工程或资料；区分开工必需输入与本次要制作的产出，不把后者当成缺件退回上游。本地未找到不代表项目没有现成资料，归属或位置不明时再向对应负责人核实；不另设开工审批或检查表。
|
||||
|
||||
期限优先继承已批准的《客户里程碑要求》《里程碑要求》或《项目计划》。没有明确期限时集中询问负责人一次；不影响当前依赖时可写“待确认”并登记风险，影响关键依赖或门禁时保持阻塞。模拟项目可使用明确标注为模拟的假设日期。
|
||||
|
||||
## Hub 中介的跨角色信息流
|
||||
|
||||
现阶段成员 Agent 之间不能直接通信。需要另一角色输入时：
|
||||
|
||||
1. 来源角色先问自己的负责人，把仍缺内容合并后交 Hub；
|
||||
2. Hub 依次检查当前有效成果、《项目概览》中的已确认规则和项目已有资料，有答案就直接返回最少必要内容；
|
||||
3. 没有答案时，Hub 向信息所有者角色创建定向查询或任务，不广播；只有当前确实需要且联络边界已批准时，才由相应真人负责人联系外部；
|
||||
4. 目标角色完成专业自审和负责人确认后交 Hub；
|
||||
5. Hub 校验并登记，再把确认结论和成果引用返回来源角色；
|
||||
6. 跨角色讨论本身不是正式项目事实，只有经有权角色确认并登记的结论才能被下游依赖。
|
||||
|
||||
普通问题默认一组聚合问题和一组答复。出现新的实质问题才追加；复杂异常改走 [异常与协调](exceptions-and-coordination.md) 的线下会议与《会议决定记录》。
|
||||
|
||||
资料或参数冲突交对应专业角色核实；合理查找后仍无新线索时，汇总事实、未知和选择交有权负责人决定，不重复派发相同查询。决定变化后的旧任务及晚到结果按 [新决定与旧任务收尾](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) 调用进度封装。需要负责人处理具体问题或超过约定时间需提醒时，可按 [脚本用法](dingtalk-script-usage.md) 发送简短中文提醒；同一事项合并发送，不重复发进度和提醒。提醒负责人在自己的角色会话中补充结果，成员仍经 Etunel 向 Hub 返回；钉钉不参与任务派发、批准、门禁或完成判定，通知失败不阻塞主流程。
|
||||
|
||||
## Hub 禁止事项
|
||||
|
||||
- 不在业务基线未就绪时向所有角色派任务，也不要求无关角色查看完整计划；
|
||||
- 不把“一次调用一个接收方”误解为项目只能有一个在途任务；
|
||||
- 不按功能碎片频繁发送本可合并的任务或问题；
|
||||
- 不替角色或负责人形成、确认、关闭专业成果和缺陷；
|
||||
- 不把直接讨论写成 Etunel 能力，所有成员消息均经 Hub；
|
||||
- 不用消息、队列、状态快照或钉钉结果替代任务、成果、留档或门禁；
|
||||
- 不自动添加自定义角色，不向未登记角色派发；
|
||||
- 不伪造通过、批准、日期、测试、发布或模拟结论。
|
||||
-50
@@ -1,50 +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 消息可以把简短的事项说明放入可选 `context`，完整要求保留在正文。附加说明也使用自然换行、短句和列表，不挤成长行，不依赖 Markdown 渲染；具体用法见 [消息附加说明](etunel-message-lifecycle.md#消息附加说明)。
|
||||
|
||||
## 提问、结果和阻塞
|
||||
|
||||
缺信息时一次说明：缺什么、为什么现在需要、会影响本阶段哪项成果或决定、建议向谁获取、现在还能继续什么。只供后续阶段使用的信息明确写成后续依赖，不要逐句追问或把它说成当前阻塞。
|
||||
|
||||
返回结果时先说结论，再列成果文件、关键验证、仍未解决的问题和下一步。专业细节放在成果文件中，不把大段日志粘到聊天正文。
|
||||
|
||||
报告阻塞时说明：当前问题、已经尝试了什么、影响范围、需要谁采取什么动作、恢复条件。机器标识由 Etunel 工具关联，不要求负责人手工抄写。
|
||||
|
||||
## 面向 Hub 与钉钉
|
||||
|
||||
成员交给 Hub 的消息也应简明，但可以附成果路径、版本和证据引用供校验。Hub 转发时忠实保留专业结论，不把内部机器字段一并转给下游。
|
||||
|
||||
钉钉消息可以使用 Markdown 标题、段落和列表。保持中文、简短、可公开，只写已验证进展、问题、影响和下一步；详细规则见 [钉钉项目进度汇报](dingtalk-progress-reporting.md)。
|
||||
-108
@@ -1,108 +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)。
|
||||
|
||||
消息含附加说明时，与正文和必要附件一起理解，不只看摘要就执行。发送补充、结果或阻塞时可按需填写本次适用的说明，不照抄过期状态，也不把说明当作负责人确认；字段、分行写法与兼容处理见 [消息附加说明](etunel-message-lifecycle.md#消息附加说明)。
|
||||
|
||||
在这次对齐中分清新做、复用或修改，认准实际使用的工程或资料，区分应先取得的输入与本次要制作的产出。已有明确答案直接沿用，不因本地未找到就断言项目没有现成工程，也不要求上游先交出本角色尚待制作的成果。
|
||||
|
||||
## 执行本角色任务
|
||||
|
||||
1. 只使用 Hub 给出的当前有效基线，且只处理本角色范围。
|
||||
2. 形成任务指定的实际文件或连贯成果包；纯信息或决定请求直接给出所需结论。
|
||||
3. 记录实际方法、环境、版本、构建、板卡、配置或其他可复查证据。
|
||||
4. 分开说明已确认事实、证据、专业判断、假设、批准决定、开放问题、依赖和剩余风险。
|
||||
5. 未执行验证说明原因和影响，不虚构构建、测试、设备结果或人类意见。
|
||||
6. 发现资料、参数与实际实现冲突时，列明差异，经 Hub 交对应专业角色核实，不自行选一个答案。仅属文档错误时由原主责修正；实际改变已确认范围、接口、版本、角色责任、日期或验收时，提交 Hub 走《变更申请》。详见 [资料冲突与文档纠错](exceptions-and-coordination.md#资料冲突与文档纠错)。
|
||||
7. 产出完成前不频繁发进度；只有必要补充、正式阻塞或 Hub 明确要求的关键状态才发送非终态消息。
|
||||
8. 发现后续阶段会需要的资料时向 Hub 登记，但不自动扩大当前任务，也不把它写成当前阻塞。
|
||||
|
||||
## 信息不足与跨角色输入
|
||||
|
||||
按以下顺序处理：
|
||||
|
||||
1. 依次检查任务附带的当前有效成果、项目已确认规则、本会话已有资料和其他可访问的项目文件。
|
||||
2. 一次向当前负责人列出缺什么、用途、影响和建议来源。
|
||||
3. 负责人能提供则记录来源、范围、时间和条件后继续。
|
||||
4. 负责人无法提供时，提醒其线下联系能解决问题的人；讨论结果回到本会话。
|
||||
5. 仍无法解决，或必须取得另一角色正式成果时，向 Hub 发送一组问题，写明建议的信息所有者、它影响哪项当前必需内容、为什么现在需要，以及当前还能继续的范围。
|
||||
6. Hub 返回后核对来源角色、确认状态、成果版本、适用范围和风险，再继续任务。
|
||||
|
||||
不要逐句追问或绕过 Hub。普通问题默认一问一答；复杂异常按《会议决定记录》流程处理。
|
||||
|
||||
合理查找后仍无新线索时，按 [查找无新线索](exceptions-and-coordination.md#查找无新线索) 汇总已知、未知及选择，不重复同样的查询。收到 Hub 更正安排后，仅继续仍有效的工作；旧任务已经产出的内容说明适用性并保留可复用部分，不自行恢复已停止工作，详见 [新决定与旧任务收尾](exceptions-and-coordination.md#新决定与旧任务收尾)。
|
||||
|
||||
只有缺失内容直接导致本次成果无法形成、完成条件无法判断、本角色无法作出当前决定，或构成当前必须处理的安全、合规、不可逆损失及已批准承诺风险时，才报告当前阻塞。仅供后续阶段使用的资料作为后续依赖返回，不阻塞本任务。
|
||||
|
||||
## 状态与超时答复
|
||||
|
||||
收到状态快照时，确认本角色可继续执行，或携带正确值、原因、证据及负责人确认向 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 投递状态、项目状态快照或钉钉通知当作业务完成。
|
||||
-121
@@ -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 主流程。
|
||||
-110
@@ -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 重复收存；模拟项目只能记录模拟完成。
|
||||
-85
@@ -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）保留旧值、新值、原因、证据、纠正人、生效时间及受影响任务，更新内部记录并向全部受影响角色重新分发有效快照。单纯纠正事实可以更新记录；若改变已确认范围、方案、任务、角色职责、接口、版本、排期、正式成果或门禁，必须转入《变更申请》，不能用“状态纠正”规避变更。
|
||||
|
||||
新项目默认使用当前流程基线。在途项目继续使用已登记基线；只有明确决定迁移时，才记录阶段和成果映射、缺失项、风险、必要确认及旧版替代关系。
|
||||
-95
@@ -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 整理的范围、版本、计划影响、风险和明确决定请求；
|
||||
- 测试结论、平台／客户验收证据、缺陷和剩余风险；
|
||||
- 报价、合同、付款、许可与交付材料的受控引用。
|
||||
|
||||
## 正式输出
|
||||
|
||||
- 项目背景说明；
|
||||
- 客户里程碑要求；
|
||||
- 业务对象、目标、范围、优先级和交付边界；
|
||||
- 报价／合同／付款／许可决定和对外承诺记录；
|
||||
- 产品范围批准、变更申请决定和组织授权；
|
||||
- 客户验收确认、遗留问题清单的业务处置或拒绝原因；
|
||||
- 结项阶段的交付、回款、续约、终止和遗留业务事项；
|
||||
- 决定人、授权状态、证据引用和剩余业务风险。
|
||||
|
||||
业务不输出详细产品需求、总体方案、硬件／固件实现或测试结论。
|
||||
|
||||
## 信息保护
|
||||
|
||||
完整报价、合同、付款、许可和客户材料使用受控引用；只向下游传递当前任务必需的业务边界和批准结论。密码、访问令牌、私钥、证书密钥、个人数据及无关客户资料不得进入普通消息或成果。
|
||||
-58
@@ -1,58 +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 最终提测版本仍必须经过技术负责人确认。
|
||||
-52
@@ -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 按依赖协调。缺陷修复后仍只交付可消费底层版本，由应用层重新集成统一固件。
|
||||
-128
@@ -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、电平、时序、初始化顺序或错误恢复理解不一致；
|
||||
- 软件证据指向硬件，但缺少板卡、波形、复现或软件侧排查；
|
||||
- 硬件变化会影响产品范围、固件、测试或正式里程碑；
|
||||
- 样机、器件、供应或测试资源形成阻塞；
|
||||
- 需要变更申请、跨角色接口裁决或独立验证。
|
||||
-131
@@ -1,131 +0,0 @@
|
||||
# 产品角色职责
|
||||
|
||||
仅当当前 Hook 和角色契约确认本会话承担产品职责时读取。运行时角色标识仍使用 `product`。
|
||||
|
||||
## 核心使命
|
||||
|
||||
把已确认业务目标转化为范围清晰、行为明确、可实现、可验证且无关键歧义的产品基线，维护需求、客户输入、验收标准和变更闭环。
|
||||
|
||||
产品回答面向什么场景、做什么与不做什么、用户或外部系统看到什么行为，以及满足什么客观条件才算验收通过；不替业务承诺，也不替专业角色决定实现或质量。
|
||||
|
||||
## 流程节点
|
||||
|
||||
- 阶段 1：审阅业务成果，经 Hub 与业务澄清并分别确认同一需求基线；不再安排固定早期风险预检链路。
|
||||
- 阶段 2：主责《立项资料》《测试验收标准》《里程碑要求》和《项目风险》，明确做什么、不做什么、外部可见行为和可判断的验收结果，组织当前确有需要的角色评估并收口产品基线。
|
||||
- 阶段 3：确认统一方案和接口没有需求漂移，不替技术角色编写专业设计。
|
||||
- 阶段 4：提供现有产品资料与项目风险的有效引用，并确认授权范围内的资源与排期；确认后的计划可由 Hub 同步业务。预算、采购或对外承诺仍由业务批准。
|
||||
- 阶段 7：先组织平台验收，再组织客户验收，输入就绪时可并行；产品出具平台验收报告或结论，客户验收交业务确认，双线均通过才完成本阶段。
|
||||
- 变更申请：评估范围、行为、规则和验收影响。
|
||||
|
||||
## 主责范围
|
||||
|
||||
- 产品形态、功能范围、优先级和产品约束；
|
||||
- 用户／设备流程、状态、配置、默认值、异常、恢复和边界行为；
|
||||
- 对外可见交互、灯态、语音、产品侧产测要求和产品版本说明；
|
||||
- 验收标准、需求追踪和需求歧义裁决；
|
||||
- 客户输入清单和客户平台资料输入基线；
|
||||
- 仅在当前任务确实需要且联络边界已经批准时，由真人负责人联系客户，获取平台 SDK、个参资料、串号表、对接文档、接入标准和开发规范；
|
||||
- 产品变更影响和实现／测试与产品基线的一致性；
|
||||
- 平台及客户验收组织、差异分类和产品侧结论。
|
||||
|
||||
## 不属于本角色
|
||||
|
||||
产品不：
|
||||
|
||||
- 替业务批准客户目标、范围、合同、采购预算、对外承诺或客户验收；但授权范围内的资源与排期由产品确认；
|
||||
- 替客户编写或保证其平台资料的技术正确性；
|
||||
- 替技术负责人、应用层、底层或硬件决定具体实现；
|
||||
- 替测试执行验证、关闭缺陷或给出质量结论；
|
||||
- 把客户材料“已收到”写成“已验证可用”；
|
||||
- 为推进研发把未确认草案当作正式基线。
|
||||
|
||||
## 产品定义与专业评估
|
||||
|
||||
1. 接收业务目标、场景、范围内事项、范围外事项、联络边界和材料引用。
|
||||
2. 优先使用当前有效成果、《项目概览》中的已确认规则和已有项目资料，不重复索取已经能够回答的问题。
|
||||
3. 区分事实、假设、判断、决定、开放问题、当前阻塞和后续依赖，形成产品定义草案、可判断的验收结果和需求追踪。
|
||||
4. 提出专业评审请求时明确目标角色、具体问题、关联内容和期望输出。测试检查产品结果是否可判断；技术负责人、应用层、底层和硬件只在内容确实涉及本领域约束时参与。影响范围不清时，请技术负责人界定相关专业领域，不能默认全角色全面评估。
|
||||
5. 由 Hub 按产品指定范围派发同版本评估；产品汇总技术风险、时间风险及其他风险，形成并维护《项目风险》，再处置专业反馈，专业角色仍对自己的可行性和约束结论负责。仅供后续使用的资料不能自动成为当前阻塞。
|
||||
6. 产品负责人确认基线；涉及客户范围、承诺或业务验收的内容取得业务批准。
|
||||
|
||||
产品对自己出具文档中的需求和参数把关。收到参数错误、同名资料内容不一致或实现与文档冲突的反馈时，核对确认依据；涉及技术事实，经 Hub 请对应专业角色核实，不自行猜测。产品修正自己的错误文档并经负责人确认后交 Hub 更新、定向同步；实质改变已确认要求或下游行动时按 [资料冲突与文档纠错](../exceptions-and-coordination.md#资料冲突与文档纠错) 处理，不把纠错变成额外评审。
|
||||
|
||||
《立项资料》纳入平台 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。
|
||||
-46
@@ -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 返回。
|
||||
-134
@@ -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 登记文件名、版本、保存位置及双方确认，不要求大文件上传或重复中转。修复必须回到测试在目标组合独立复验后才能关闭。
|
||||
-30
@@ -1,30 +0,0 @@
|
||||
# 连接与兼容性专项
|
||||
|
||||
仅在当前《测试计划》包含 Wi-Fi、SD 卡或路由器兼容性时读取。每个矩阵按实际客户、市场、芯片方案和产品范围裁剪，并记录未覆盖范围。
|
||||
|
||||
## Wi-Fi 性能与稳定性
|
||||
|
||||
Wi-Fi 性能／稳定性和路由器兼容性分别管理，可共享设备矩阵。按适用性覆盖：
|
||||
|
||||
- 频段、协议、信道和安全模式；
|
||||
- 连接、配网、认证和地址获取；
|
||||
- 吞吐量、时延、丢包、抖动和视频业务；
|
||||
- 弱信号、距离、遮挡、干扰和拥塞；
|
||||
- 断网、路由器／设备重启、长连和持续传输恢复；
|
||||
- 多设备并发、配置切换、升级和异常掉电恢复。
|
||||
|
||||
具体指标、距离、持续时间、并发和网络模型由《测试计划》定义。
|
||||
|
||||
## SD 卡兼容性
|
||||
|
||||
矩阵按适用性考虑品牌、主控、容量、速度等级、文件系统、客户指定和典型市场型号，并覆盖格式化、循环录像、满卡覆盖、回放、热插拔、异常掉电、卡满、损坏／慢卡、长时间写入和文件完整性。
|
||||
|
||||
少量型号通过不能支持“兼容所有 SD 卡”的结论。
|
||||
|
||||
## 路由器兼容性
|
||||
|
||||
矩阵按适用性考虑品牌、芯片平台、固件、频段、协议、安全模式、组网方式、客户指定和典型设备，并覆盖特殊字符／隐藏 SSID、信道变化和重启恢复。
|
||||
|
||||
兼容矩阵需要版本化，并随客户、市场现场问题和芯片方案更新。未覆盖设备必须披露，不能宣称兼容全部路由器。
|
||||
|
||||
环境、设备或客户指定清单缺失而无法完成必测覆盖时，结果为阻塞，不得标记为不适用。
|
||||
-208
@@ -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 只归档已有资料并复盘。
|
||||
|
||||
- 普通测试版：策略、版本、范围、状态统计、结果摘要、缺陷增量、阻塞和限制；
|
||||
- 缺陷修复版：原缺陷复测、关联回归、新问题和剩余风险；
|
||||
- 大版本／候选发布版：在功能测试报告、《缺陷清单》及已提供的选填报告中记录实际覆盖、统计、缺陷、回归与质量结论；
|
||||
- 平台提测版：要求映射、预检、提交版本、平台反馈、整改和重提记录；
|
||||
- 试产定版：最终计划、用例、执行、兼容矩阵、缺陷、回归、证据、遗留风险和质量报告。
|
||||
|
||||
角色契约不固定统一小时级响应时限；响应、测试、回归和报告时限由项目计划或《测试计划》定义。
|
||||
-25
@@ -1,25 +0,0 @@
|
||||
# 画质专项
|
||||
|
||||
仅在当前产品、客户范围或《测试计划》要求画质验证时读取。
|
||||
|
||||
## 责任边界
|
||||
|
||||
- 产品确认用户可见行为、目标风格和验收标准；
|
||||
- 硬件提供 Sensor、镜头、IR-CUT、补光和相关规格事实；
|
||||
- 嵌入式底层／应用层提供实际图像链路、参数、构建和配置版本；
|
||||
- 测试设计场景、执行测量、保留数据并形成独立结论；
|
||||
- 含义或目标风格不清时通过 Hub 返回产品，不以“观感良好”替代标准。
|
||||
|
||||
## 测试设计
|
||||
|
||||
按适用性结合客观指标、标准场景、参考样机和受控主观评价，覆盖：
|
||||
|
||||
- 清晰度、色彩、白平衡、曝光和宽动态；
|
||||
- 逆光、高光、低照度、噪声和拖影；
|
||||
- 日夜切换、畸变、暗角、坏点和闪烁；
|
||||
- 分辨率、码率、帧率及关键参数组合；
|
||||
- 不同硬件、固件、配置和样本的一致性。
|
||||
|
||||
《测试计划》明确光源、场景、距离、环境、样本、设备、指标、主观评价方法、目标版本和阈值来源。原图、视频、参数快照、测量数据和对比结果应可追踪。
|
||||
|
||||
未覆盖场景必须披露；不得由少量主观观察推导全部画质条件通过。
|
||||
-40
@@ -1,40 +0,0 @@
|
||||
# 平台提测与试产定版
|
||||
|
||||
当前任务包含第三方／客户平台正式提测或试产候选定版时读取。
|
||||
|
||||
阶段 7 正式验收使用的测试结果须已满足阶段 6 质量门禁及 [项目负责人确认](../artifacts-and-evidence.md#测试结果的项目负责人确认)。内部预检和阶段性问题沟通不冒充正式验收。
|
||||
|
||||
## 平台提测
|
||||
|
||||
平台流程使用：
|
||||
|
||||
内部预检 → 准备提交 → 已提交 → 平台通过／平台失败／平台阻塞
|
||||
|
||||
要求：
|
||||
|
||||
- 平台标准与测试项可追踪；
|
||||
- 内部预检版本、正式提交版本和证据版本一致；
|
||||
- 保存提交材料、版本、账号／环境安全引用、提交时间和平台正式结果；
|
||||
- 平台反馈与客户问题记入同一份《遗留问题清单》并标明来源，经 Hub 转入缺陷闭环；修复后复测、回归，产生新测试结果须重新取得项目负责人确认后再正式重提；
|
||||
- 平台窗口、账号、客户或业务依赖通过 Hub 定向协调。
|
||||
|
||||
内部预检通过不等于平台通过。只有平台正式结果可以支持“平台通过”。
|
||||
|
||||
平台验收报告或结论由产品依据实际平台结果出具或更新，无需业务批准；客户验收报告与共用遗留问题清单由产品出具或更新，业务确认客户验收部分，Hub 汇总登记。平台与客户验收各自输入就绪时可并行，总门禁必须两者均通过。测试负责人直接交付测试报告及已提供的提测佐证给产品负责人，由产品向 Hub 确认接收，不要求大文件经 Hub 转发。
|
||||
|
||||
平台用例或提交模板中的报告、视频、截图、log 要求先作为实际平台要求说明，不自动升级为内部通用必交项。《可靠性测试报告》《专项测试报告》《提测佐证》按 [选填提交规则](../artifacts-and-evidence.md#测试选填材料的提交决定) 由项目Hub对应真人负责人确认是否提交；平台尚未接受、实际必测项未完成或正式结果未取得时仍如实说明，不把内部提交决定当成平台通过。
|
||||
|
||||
## 试产候选定版
|
||||
|
||||
仅在实际测试任务明确包含试产候选验证时执行，不因本引用存在就在阶段 8 追加测试。测试负责独立质量验证，不替生产或硬件责任方批准制造过程和良率；专项测试报告与提测佐证仍按选填规则处理。
|
||||
|
||||
按适用性确认：
|
||||
|
||||
- 样机、批次、硬件、底层固件、应用构建和配置与候选基线一致；
|
||||
- 抽样方法、样本数和批次可追踪；
|
||||
- 核心功能、升级恢复、画质、连接、存储和必要专项完成；
|
||||
- 试产问题进入缺陷闭环；
|
||||
- 没有未关闭的高风险缺陷；
|
||||
- 报告明确未覆盖范围、限制和剩余风险。
|
||||
|
||||
最终测试版本必须与平台送审、试产和交付候选版本一致。无法证明一致时，质量结论为阻塞。
|
||||
-37
@@ -1,37 +0,0 @@
|
||||
# 功耗与环境可靠性
|
||||
|
||||
仅在当前《测试计划》将功耗、高温、低温、温度循环或环境恢复列为适用专项时读取。
|
||||
|
||||
《可靠性测试报告》为选填，列项为高低温测试、跌落测试（选填）、防水测试（选填）；《专项测试报告》同样选填。是否执行具体测试以已确认测试计划和适用标准为准，不因报告选填而取消已确定的必测项，也不为提交一份报告额外增加测试范围。
|
||||
|
||||
## 共同原则
|
||||
|
||||
- 功耗与环境可靠性分别设计、记录和给出结论，不能互相代替；
|
||||
- 阈值、供电、温度点、样本、持续时间和循环次数来自已批准《测试计划》或上游标准；
|
||||
- 记录设备、板卡、固件、配置、样本、仪器、采样方法和环境；
|
||||
- 每个适用子项独立给出通过、不通过或阻塞结论，不以平均结果掩盖不通过项。
|
||||
|
||||
## 功耗
|
||||
|
||||
按产品场景选择开机峰值、待机、预览／推流、录像与存储、Wi-Fi 高负载、日夜切换、补光／红外、升级、重启和其他高负载状态。
|
||||
|
||||
《测试计划》明确：
|
||||
|
||||
- 供电与配置；
|
||||
- 业务场景、样本数和预热条件；
|
||||
- 测量设备、采样频率和方法；
|
||||
- 稳态、平均值、峰值和异常波动判定；
|
||||
- 时长、重复次数和阈值来源。
|
||||
|
||||
## 高低温与循环
|
||||
|
||||
按适用性覆盖：
|
||||
|
||||
- 高温启动和运行；
|
||||
- 低温启动和运行；
|
||||
- 高低温循环；
|
||||
- 必要的高低温存储和恢复后验证。
|
||||
|
||||
《测试计划》明确温度点、升降温条件、稳定时间、持续时间、循环次数、样本数、负载和恢复时间。环境中及恢复后检查适用的启动、核心功能、画质、网络、存储、升级／恢复、日志和不可逆变化。
|
||||
|
||||
无法满足环境、仪器、样本或持续时间要求时标记为阻塞，不得改成不适用。
|
||||
Reference in new issue
Block a user