docs: 统一当前流程文档路径并以 Git 管理历史版本
This commit is contained in:
chenmingxuan committed
1 parent
64db56a951
commit
be9969097e
15 files changed
+32
-6650
No files matched your search
@@ -6,7 +6,7 @@
|
||||
|
||||
- `etunel-role-collaboration/`：供各角色按需读取的渐进式披露 Skill；
|
||||
- `etunel-role-hook-contexts/`：供 Etunel 独立配置的八角色精简 Hook 上下文；
|
||||
- `doc/`：流程设计基线和历史资料；
|
||||
- `doc/`：当前流程设计基线和模板参考资料；
|
||||
- 钉钉参考集成：仅帮助 Hub 理解如何调用辅助通知，不属于 Etunel 任务通信主链路。
|
||||
|
||||
这是以 Markdown、HTML 和 Shell 为主的约束仓库，没有需要猜测的安装或构建步骤。
|
||||
@@ -19,11 +19,11 @@
|
||||
|
||||
1. 先读根 Skill：[etunel-role-collaboration/SKILL.md](etunel-role-collaboration/SKILL.md)。
|
||||
2. 只按其中的条件路由读取本次修改涉及的 reference，不要一次加载所有角色和测试细则。
|
||||
3. 当前本地定版文档为 [V1.0 总流程图](doc/20260908/Codex多角色项目推进总流程图-V1.0.html)（CURRENT，文档生效日期 2026-09-08），基于用户已确认的 V0.16 全文生成，不新增角色或流程规则。V0.15、V0.16 HTML 保留原文件；本地文档定版不表示已发布 Git、部署 Skill／Hook 或替换在途项目基线。未经用户再次通知，不提交、不推送、不合入主分支，也不自动更新已安装的插件缓存。旧版流程用于追溯；已在运行的项目继续使用其登记基线，迁移须明确确认。
|
||||
3. 当前设计基线为 [V1.0 总流程图](doc/Codex多角色项目推进总流程图.html)（文档生效日期 2026-09-08）。`doc/` 只维护当前流程文件和配套参考，不再按日期或版本复制文档；后续直接更新同一文件，历史通过 Git 提交追溯。仓库更新不等于部署 Skill／Hook 或迁移在途项目；已运行项目继续使用其登记基线，迁移及插件缓存更新须明确确认。
|
||||
4. 运行时 Hook、Etunel 工具 schema、项目角色契约、成员登记及已确认的项目流程基线，高于 Skill 的通用说明。发现冲突时说明冲突，不要自行猜测或发明能力。
|
||||
5. 保留用户已有改动；修改前后检查 Git 状态与差异。
|
||||
|
||||
不要让运行时 Skill 依赖某个带版本号的流程图或提示词文件。应把已确认且仍有效的规则整理为稳定约束，并放入正确的渐进式 reference；版本文件只作为设计来源和追溯依据。
|
||||
不要让运行时 Skill 依赖某个带版本号的流程图或提示词文件。应把已确认且仍有效的规则整理为稳定约束，并放入正确的渐进式 reference；流程文档只作为设计来源，历史以 Git 提交追溯。
|
||||
|
||||
## 必须保持的协作边界
|
||||
|
||||
@@ -47,7 +47,7 @@
|
||||
| `etunel-role-collaboration/references/roles/` | 七个成员角色的职责契约 | 角色专属决定、输入、输出和边界写在对应文件 |
|
||||
| `etunel-role-collaboration/references/testing/` | 测试角色二级细则 | 只保留匹配任务时才需要的深层内容 |
|
||||
| `etunel-role-hook-contexts/` | 八角色 Hook 的完整精简职责与每轮提醒 | 独立于 Skill 发现树；简短、可直接注入、与正式职责一致 |
|
||||
| `doc/` | 已确认流程来源及历史版本 | 不把历史版本误写成当前规则；新增基线时明确其状态 |
|
||||
| `doc/` | 当前流程来源及模板参考 | 固定路径维护一份当前文档；不建日期或版本副本，历史查 Git；变更同步核对链接与基线说明 |
|
||||
| `.agents/skills/dingtalk-*` | 钉钉官方能力的项目内参考副本 | 不是 Etunel 核心 Skill；除非任务明确要求更新参考包，否则不要批量改动 |
|
||||
| `.dingtalk/`、`scripts/dingtalk-progress` | Hub 通知接入说明、示例配置和当前演示封装 | 不把通知能力扩大为任务派发、审批、门禁或事实源 |
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
1. [主 Skill](etunel-role-collaboration/SKILL.md) 是角色 AI 的统一入口，只保留共享硬约束和条件路由；详细职责按当前任务逐层读取。
|
||||
2. [Hook 上下文](etunel-role-hook-contexts/) 是给 Etunel 单独配置的精简提醒，不属于 Skill 的渐进式发现树，也不应替代完整职责文件。
|
||||
3. 当前本地定版文档为 [V1.0 总流程图](doc/20260908/Codex多角色项目推进总流程图-V1.0.html)（CURRENT，文档生效日期 2026-09-08），基于已确认的 V0.16 全文生成，保留原有流程与灯态“配网”修正。V0.15、V0.16 历史文件保留；文档定版不代表已推送、部署 Skill／Hook 或自动迁移在途项目。未经用户再次通知，不提交、不推送、不合入主分支，也不自动更新已安装的插件缓存。运行时规则已整理进稳定 reference，不要求目标项目持有版本 HTML。
|
||||
3. 当前设计基线为 [V1.0 总流程图](doc/Codex多角色项目推进总流程图.html)（文档生效日期 2026-09-08）。流程文档只维护一份，后续直接更新同一文件，旧版通过 Git 历史追溯，不再按日期或版本另存。仓库更新不代表部署 Skill／Hook 或自动迁移在途项目；运行时规则已整理进稳定 reference，不要求目标项目持有流程 HTML。
|
||||
|
||||
仓库没有应用安装、编译或发布流程。主要工作是维护角色约束、流程文档、Hook 上下文以及 Hub 通知参考集成。
|
||||
|
||||
@@ -47,7 +47,7 @@ flowchart LR
|
||||
| 角色 | 主要定位 |
|
||||
| --- | --- |
|
||||
| 项目Hub | 建立项目、维护状态、规划任务波次、校验交付结构、协调阻塞并完成跨角色中继 |
|
||||
| 业务 | 形成商业需求、客户与授权信息、业务验收及发布结项输入 |
|
||||
| 业务 | 形成业务需求、客户与授权信息，确认客户验收及复盘结项 |
|
||||
| 产品 | 把业务需求转化为产品定义、范围、交互和验收标准 |
|
||||
| 技术负责人 | 负责总体技术方案、接口与跨技术域设计协调 |
|
||||
| 嵌入式应用层 | 负责应用层软件设计、实现、联调和对应成果 |
|
||||
@@ -74,6 +74,7 @@ EP-Hub-Skill/
|
||||
│ ├── project-lifecycle.md # 八阶段、成果和门禁
|
||||
│ ├── project-status-and-membership.md
|
||||
│ ├── etunel-message-lifecycle.md
|
||||
│ ├── document-templates.md # 模板复用与审核边界
|
||||
│ ├── artifacts-and-evidence.md
|
||||
│ ├── exceptions-and-coordination.md
|
||||
│ ├── human-readable-communication.md
|
||||
@@ -82,7 +83,9 @@ EP-Hub-Skill/
|
||||
│ ├── roles/ # 七个成员角色职责
|
||||
│ └── testing/ # 测试任务按需读取的二级细则
|
||||
├── etunel-role-hook-contexts/ # 八角色独立 Hook 源文件
|
||||
├── doc/ # 当前设计基线和历史流程资料
|
||||
├── doc/ # 当前设计基线与模板参考，历史由 Git 保存
|
||||
│ ├── Codex多角色项目推进总流程图.html # 当前 V1.0，后续原位更新
|
||||
│ └── 文档模板参考/ # 按任务读取的参考笔记与来源清单
|
||||
├── .agents/skills/dingtalk-*/ # 钉钉官方能力参考副本，不是核心 Skill
|
||||
├── .dingtalk/ # 通知接入说明与无秘密示例配置
|
||||
└── scripts/dingtalk-progress # Hub 钉钉通知的当前演示封装
|
||||
@@ -128,7 +131,7 @@ Etunel 为角色会话配置本 Skill 后，角色 AI 应按以下顺序工作
|
||||
|
||||
[etunel-role-hook-contexts/](etunel-role-hook-contexts/) 为八个默认角色各提供一份“精简职责与每轮提醒”。它们适合由 Etunel Hook 在每轮会话中注入，用来持续提醒身份、边界、负责人参与和工具使用。
|
||||
|
||||
本轮先同步远程 `main` 的 Hook 提醒（`0b133bf`），保留“完整职责 JSON + 每轮精简提醒”结构；职责 JSON 不是接口请求，实际绑定与工具参数仍以 Etunel 为准。本地源文件修改不会自动写入已安装插件或 Etunel 配置。
|
||||
每份 Hook 文档分为“完整职责 JSON”和“每轮精简提醒”两个独立配置区块，分别复制到 Etunel 对应字段。职责 JSON 不是接口请求，实际绑定与工具参数仍以 Etunel 为准。仓库源文件修改不会自动写入已安装插件或 Etunel 配置。
|
||||
|
||||
Hook 文件需保持短小，并与完整 Skill 职责一致。它们由 Etunel 独立配置，因此不需要从 `SKILL.md` 中发现；修改角色边界时，应同时检查对应角色 reference 与 Hook，避免两套规则漂移。
|
||||
|
||||
@@ -151,7 +154,7 @@ Hook 文件需保持短小，并与完整 Skill 职责一致。它们由 Etunel
|
||||
## 修改项目的推荐流程
|
||||
|
||||
1. 阅读 [AGENTS.md](AGENTS.md) 和本次变更涉及的最小文件集合。
|
||||
2. 若变更来自流程设计，核对 [V1.0 CURRENT 总流程图](doc/20260908/Codex多角色项目推进总流程图-V1.0.html)；保持历史 HTML 不变，不把本地文档定版或规则更新当作远程发布、部署或在途项目自动迁移。
|
||||
2. 若变更来自流程设计，核对 [当前 V1.0 总流程图](doc/Codex多角色项目推进总流程图.html)，在固定文件上修改并通过 Git 提交记录变更；不要新增日期目录或旧版副本。部署及在途项目迁移另行确认。
|
||||
3. 把共享规则放在公共 reference，把角色专属规则放在对应角色文件，把低频测试细节放在测试二级 reference。
|
||||
4. 只有必须让所有角色立即知道的规则才进入根 `SKILL.md`；同时保持条件路由可发现。
|
||||
5. 同步检查受影响的 Hook 文件，并验证链接、结构和 Shell 语法。
|
||||
@@ -183,13 +186,9 @@ bash -n scripts/dingtalk-progress
|
||||
|
||||
## 设计资料
|
||||
|
||||
- [当前本地定版 V1.0（CURRENT）](doc/20260908/Codex多角色项目推进总流程图-V1.0.html)
|
||||
- [保留的评审版本 V0.16（REVIEW）](doc/20260907/Codex多角色项目推进总流程图-V0.16.html)
|
||||
- [保留的总流程图 V0.15](doc/20260904/Codex多角色项目推进总流程图-V0.15.html)
|
||||
- [历史总流程图 V0.14](doc/20260902/Codex多角色项目推进总流程图-V0.14.html)
|
||||
- [补充与历史追溯：项目Hub系统提示词 V0.13](doc/20260828/Codex多角色项目推进-项目Hub系统提示词-V0.13.txt)
|
||||
- [历史总流程图 V0.13](doc/20260828/Codex多角色项目推进总流程图-V0.13.html)
|
||||
- [历史总流程图 V0.4](doc/20260827/Codex多角色项目推进总流程图-V0.4.html)
|
||||
- [当前总流程图 V1.0](doc/Codex多角色项目推进总流程图.html)
|
||||
- [文档模板参考](doc/文档模板参考/README.md)
|
||||
- 历史流程与变更说明通过 `git log --all -- doc/` 查询，不在工作目录保留旧版副本。
|
||||
- [核心 Skill](etunel-role-collaboration/SKILL.md)
|
||||
- [Hub 工作流](etunel-role-collaboration/references/hub-workflow.md)
|
||||
- [项目生命周期](etunel-role-collaboration/references/project-lifecycle.md)
|
||||
@@ -1,933 +0,0 @@
|
||||
<!doctype html>
|
||||
<html lang="zh-CN">
|
||||
<head>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
<meta name="color-scheme" content="light" />
|
||||
<link rel="icon" href="data:," />
|
||||
<title>Codex 多角色项目推进总流程图与信息流图谱｜V0.3</title>
|
||||
<style>
|
||||
:root {
|
||||
--navy: #10253f;
|
||||
--navy-2: #17395f;
|
||||
--blue: #2368a2;
|
||||
--cyan: #2a9d9f;
|
||||
--amber: #c67a1b;
|
||||
--ink: #182331;
|
||||
--muted: #5d6a78;
|
||||
--line: #d8e0e7;
|
||||
--paper: #f5f8fa;
|
||||
--white: #ffffff;
|
||||
--soft-cyan: #e9f7f6;
|
||||
--soft-amber: #fff4df;
|
||||
--soft-red: #fcecee;
|
||||
--soft-green: #e9f6ef;
|
||||
--max: 1180px;
|
||||
}
|
||||
|
||||
* { box-sizing: border-box; }
|
||||
html { scroll-behavior: smooth; }
|
||||
body {
|
||||
margin: 0;
|
||||
color: var(--ink);
|
||||
background: var(--paper);
|
||||
font-family: Inter, ui-sans-serif, -apple-system, BlinkMacSystemFont,
|
||||
"Segoe UI", "PingFang SC", "Microsoft YaHei", sans-serif;
|
||||
line-height: 1.65;
|
||||
}
|
||||
|
||||
.hero {
|
||||
color: white;
|
||||
background:
|
||||
radial-gradient(circle at 88% 8%, rgba(42,157,159,.32), transparent 28%),
|
||||
linear-gradient(145deg, #0c1f36 0%, #173f67 100%);
|
||||
}
|
||||
.hero-inner {
|
||||
width: min(var(--max), calc(100% - 56px));
|
||||
margin: 0 auto;
|
||||
padding: 62px 0 52px;
|
||||
}
|
||||
.eyebrow {
|
||||
display: inline-block;
|
||||
margin-bottom: 18px;
|
||||
padding: 6px 10px;
|
||||
border: 1px solid rgba(255,255,255,.18);
|
||||
border-radius: 999px;
|
||||
color: #b9eff0;
|
||||
background: rgba(255,255,255,.06);
|
||||
font-size: 11px;
|
||||
font-weight: 800;
|
||||
letter-spacing: .12em;
|
||||
}
|
||||
h1, h2, h3, h4, p { margin-top: 0; }
|
||||
h1 {
|
||||
max-width: 900px;
|
||||
margin-bottom: 18px;
|
||||
font-size: clamp(40px, 5vw, 68px);
|
||||
line-height: 1.05;
|
||||
letter-spacing: -.04em;
|
||||
}
|
||||
.hero p {
|
||||
max-width: 860px;
|
||||
margin-bottom: 0;
|
||||
color: rgba(255,255,255,.68);
|
||||
font-size: 18px;
|
||||
}
|
||||
|
||||
.page {
|
||||
width: min(var(--max), calc(100% - 56px));
|
||||
margin: 0 auto;
|
||||
padding: 46px 0 72px;
|
||||
}
|
||||
.map-shell {
|
||||
padding: 30px;
|
||||
border: 1px solid var(--line);
|
||||
border-radius: 24px;
|
||||
background:
|
||||
linear-gradient(rgba(35,104,162,.035) 1px, transparent 1px),
|
||||
linear-gradient(90deg, rgba(35,104,162,.035) 1px, transparent 1px),
|
||||
#eef4f7;
|
||||
background-size: 28px 28px;
|
||||
}
|
||||
.map-head {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
gap: 24px;
|
||||
align-items: end;
|
||||
margin-bottom: 28px;
|
||||
}
|
||||
.map-head h2 { margin-bottom: 6px; font-size: 30px; letter-spacing: -.025em; }
|
||||
.map-head p { max-width: 760px; margin: 0; color: var(--muted); font-size: 14px; }
|
||||
.legend { display: flex; flex-wrap: wrap; gap: 7px; justify-content: flex-end; }
|
||||
.legend span {
|
||||
padding: 5px 8px;
|
||||
border-radius: 999px;
|
||||
color: var(--muted);
|
||||
background: var(--white);
|
||||
box-shadow: 0 3px 12px rgba(16,37,63,.06);
|
||||
font-size: 10px;
|
||||
white-space: nowrap;
|
||||
}
|
||||
|
||||
.track { display: grid; gap: 0; }
|
||||
.node {
|
||||
display: grid;
|
||||
grid-template-columns: 58px 180px minmax(0,1fr) minmax(270px,.9fr);
|
||||
gap: 18px;
|
||||
align-items: center;
|
||||
padding: 20px;
|
||||
border: 1px solid #ccd9e3;
|
||||
border-radius: 16px;
|
||||
background: rgba(255,255,255,.97);
|
||||
box-shadow: 0 8px 22px rgba(16,37,63,.055);
|
||||
}
|
||||
.index {
|
||||
display: grid;
|
||||
width: 46px;
|
||||
height: 46px;
|
||||
place-items: center;
|
||||
border-radius: 14px;
|
||||
color: white;
|
||||
background: var(--navy-2);
|
||||
font-weight: 850;
|
||||
}
|
||||
.stage h3 { margin: 0 0 5px; font-size: 19px; }
|
||||
.role {
|
||||
display: inline-block;
|
||||
padding: 3px 7px;
|
||||
border-radius: 999px;
|
||||
color: #155e60;
|
||||
background: var(--soft-cyan);
|
||||
font-size: 10px;
|
||||
font-weight: 800;
|
||||
}
|
||||
.work { color: var(--muted); font-size: 13px; }
|
||||
.work strong { color: var(--ink); }
|
||||
.artifacts {
|
||||
padding-left: 18px;
|
||||
border-left: 1px solid var(--line);
|
||||
}
|
||||
.artifacts strong { display: block; margin-bottom: 6px; font-size: 12px; }
|
||||
.artifacts span { display: block; color: var(--muted); font-size: 11px; line-height: 1.55; }
|
||||
.artifacts span + span { margin-top: 8px; }
|
||||
.artifacts span::first-line { color: var(--ink); font-size: 12px; font-weight: 600; line-height: 1.75; }
|
||||
|
||||
.connector {
|
||||
display: grid;
|
||||
min-height: 72px;
|
||||
place-items: center;
|
||||
}
|
||||
.connector::before { content: ""; width: 2px; height: 22px; background: #93aec5; }
|
||||
.gate {
|
||||
position: relative;
|
||||
margin: 4px 0;
|
||||
padding: 8px 14px 8px 30px;
|
||||
border: 1px solid #e6c27b;
|
||||
border-radius: 999px;
|
||||
color: #70480d;
|
||||
background: var(--soft-amber);
|
||||
font-size: 11px;
|
||||
font-weight: 760;
|
||||
text-align: center;
|
||||
}
|
||||
.gate::before { content: "◆"; position: absolute; left: 11px; color: var(--amber); }
|
||||
.connector::after { content: "↓"; color: var(--blue); font-size: 20px; font-weight: 900; line-height: 1; }
|
||||
|
||||
.parallel {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(2, minmax(0,1fr));
|
||||
gap: 8px;
|
||||
margin-top: 8px;
|
||||
}
|
||||
.parallel span {
|
||||
padding: 8px;
|
||||
border: 1px solid var(--line);
|
||||
border-radius: 9px;
|
||||
color: var(--ink);
|
||||
background: #f8fafb;
|
||||
font-size: 11px;
|
||||
}
|
||||
.branch {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(2, minmax(0,1fr));
|
||||
gap: 10px;
|
||||
margin-top: 12px;
|
||||
}
|
||||
.path { padding: 12px 14px; border-radius: 12px; font-size: 11px; }
|
||||
.path strong { display: block; margin-bottom: 3px; }
|
||||
.path.pass { border: 1px solid #a9d4c0; color: #266746; background: var(--soft-green); }
|
||||
.path.return { border: 1px dashed #dc9ca0; color: #863b40; background: var(--soft-red); }
|
||||
.crosscut {
|
||||
margin-top: 20px;
|
||||
padding: 18px 20px;
|
||||
border: 1px dashed #95abc0;
|
||||
border-radius: 14px;
|
||||
background: rgba(255,255,255,.75);
|
||||
}
|
||||
.crosscut strong { color: var(--blue); }
|
||||
.crosscut p { margin: 5px 0 0; color: var(--muted); font-size: 12px; }
|
||||
|
||||
.footer {
|
||||
margin-top: 24px;
|
||||
color: var(--muted);
|
||||
font-size: 11px;
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
@media (max-width: 920px) {
|
||||
.node { grid-template-columns: 54px 160px minmax(0,1fr); }
|
||||
.artifacts { grid-column: 3; padding-left: 0; border-left: 0; }
|
||||
}
|
||||
@media (max-width: 640px) {
|
||||
.hero-inner, .page { width: min(100% - 28px, var(--max)); }
|
||||
.hero-inner { padding: 44px 0 36px; }
|
||||
.hero p { font-size: 15px; }
|
||||
.page { padding-top: 24px; }
|
||||
.map-shell { padding: 16px; border-radius: 18px; }
|
||||
.map-head { display: block; }
|
||||
.legend { justify-content: flex-start; margin-top: 14px; }
|
||||
.node { grid-template-columns: 44px minmax(0,1fr); gap: 12px; padding: 16px; }
|
||||
.index { width: 40px; height: 40px; border-radius: 12px; }
|
||||
.stage, .work, .artifacts { grid-column: 2; }
|
||||
.artifacts { padding-top: 12px; border-top: 1px solid var(--line); }
|
||||
.parallel, .branch { grid-template-columns: 1fr; }
|
||||
.gate { max-width: 290px; }
|
||||
}
|
||||
|
||||
@media print {
|
||||
@page { size: A4 portrait; margin: 12mm; }
|
||||
body { background: white; font-size: 9pt; }
|
||||
.hero { color: var(--ink); background: white; border-bottom: 3px solid var(--navy); }
|
||||
.hero-inner, .page { width: 100%; }
|
||||
.hero-inner { padding: 14mm 0 10mm; }
|
||||
.hero .eyebrow { color: var(--blue); border-color: var(--line); }
|
||||
.hero p { color: var(--muted); }
|
||||
.page { padding: 10mm 0 0; }
|
||||
.map-shell { padding: 0; border: 0; background: white; }
|
||||
.node { break-inside: avoid; box-shadow: none; }
|
||||
.connector { min-height: 16mm; }
|
||||
}
|
||||
/* Embedded stage information-flow atlas */
|
||||
.if-atlas {
|
||||
margin-top: 76px;
|
||||
padding-top: 58px;
|
||||
border-top: 4px solid var(--navy);
|
||||
}
|
||||
.if-intro {
|
||||
margin-bottom: 42px;
|
||||
padding: 40px;
|
||||
border-radius: 22px;
|
||||
color: white;
|
||||
background:
|
||||
radial-gradient(circle at 88% 10%, rgba(42,157,159,.28), transparent 30%),
|
||||
linear-gradient(145deg, #10253f, #1a4a72);
|
||||
}
|
||||
.if-intro .if-eyebrow {
|
||||
color: #b9eff0;
|
||||
font-size: 11px;
|
||||
font-weight: 850;
|
||||
letter-spacing: .13em;
|
||||
}
|
||||
.if-intro h2 {
|
||||
margin: 10px 0 12px;
|
||||
font-size: clamp(34px,4vw,56px);
|
||||
line-height: 1.05;
|
||||
}
|
||||
.if-intro p {
|
||||
max-width: 900px;
|
||||
margin-bottom: 20px;
|
||||
color: rgba(255,255,255,.7);
|
||||
}
|
||||
.if-quicknav { display: flex; flex-wrap: wrap; gap: 8px; }
|
||||
.if-quicknav a {
|
||||
padding: 6px 9px;
|
||||
border: 1px solid rgba(255,255,255,.18);
|
||||
border-radius: 999px;
|
||||
color: rgba(255,255,255,.75);
|
||||
background: rgba(255,255,255,.06);
|
||||
font-size: 10px;
|
||||
text-decoration: none;
|
||||
}
|
||||
.if-section {
|
||||
padding: 58px 0;
|
||||
border-bottom: 1px solid var(--line);
|
||||
}
|
||||
.if-section-head {
|
||||
display: grid;
|
||||
grid-template-columns: 122px minmax(0,1fr);
|
||||
gap: 24px;
|
||||
margin-bottom: 28px;
|
||||
}
|
||||
.if-section-no {
|
||||
color: var(--blue);
|
||||
font-size: 11px;
|
||||
font-weight: 850;
|
||||
letter-spacing: .13em;
|
||||
}
|
||||
.if-section-head h2 {
|
||||
margin-bottom: 8px;
|
||||
font-size: clamp(28px,3vw,43px);
|
||||
line-height: 1.1;
|
||||
}
|
||||
.if-section-head p {
|
||||
max-width: 900px;
|
||||
margin: 0;
|
||||
color: var(--muted);
|
||||
font-size: 14px;
|
||||
}
|
||||
.if-callout {
|
||||
padding: 21px 24px;
|
||||
border-left: 5px solid var(--cyan);
|
||||
border-radius: 0 16px 16px 0;
|
||||
background: var(--white);
|
||||
box-shadow: 0 10px 28px rgba(16,37,63,.07);
|
||||
font-size: 17px;
|
||||
font-weight: 680;
|
||||
}
|
||||
.if-role-legend {
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
gap: 8px;
|
||||
margin: 21px 0;
|
||||
}
|
||||
.if-actor {
|
||||
display: inline-flex;
|
||||
min-width: 125px;
|
||||
min-height: 50px;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
padding: 9px 12px;
|
||||
border: 2px solid currentColor;
|
||||
border-radius: 13px;
|
||||
background: white;
|
||||
font-size: 12px;
|
||||
font-weight: 800;
|
||||
text-align: center;
|
||||
}
|
||||
.if-center { color: #183d63; background: #eaf2f8; }
|
||||
.if-business { color: #9b5d0b; background: #fff5df; }
|
||||
.if-product { color: #7755a7; background: #f4eefb; }
|
||||
.if-tech { color: #14787a; background: #e9f7f6; }
|
||||
.if-app { color: #2f855a; background: #edf8f1; }
|
||||
.if-low { color: #4265af; background: #eef2fc; }
|
||||
.if-hardware { color: #8b5e3c; background: #f7f0eb; }
|
||||
.if-test { color: #9b3d45; background: #fceef0; }
|
||||
.if-human { color: #68561b; background: #fff9df; }
|
||||
.if-flow-board {
|
||||
display: grid;
|
||||
gap: 10px;
|
||||
padding: 23px;
|
||||
border: 1px solid var(--line);
|
||||
border-radius: 19px;
|
||||
background: #edf3f6;
|
||||
}
|
||||
.if-exchange {
|
||||
display: grid;
|
||||
grid-template-columns: 150px minmax(240px,1fr) 150px;
|
||||
gap: 14px;
|
||||
align-items: center;
|
||||
padding: 12px;
|
||||
border: 1px solid #d0dce5;
|
||||
border-radius: 15px;
|
||||
background: rgba(255,255,255,.94);
|
||||
}
|
||||
.if-exchange .if-actor { width: 100%; }
|
||||
.if-arrow {
|
||||
position: relative;
|
||||
min-height: 60px;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
padding: 8px 34px 9px 10px;
|
||||
color: var(--navy-2);
|
||||
text-align: center;
|
||||
}
|
||||
.if-arrow::before {
|
||||
content: "";
|
||||
position: absolute;
|
||||
left: 8px;
|
||||
right: 18px;
|
||||
top: 50%;
|
||||
height: 2px;
|
||||
background: #83a9c5;
|
||||
}
|
||||
.if-arrow::after {
|
||||
content: "";
|
||||
position: absolute;
|
||||
right: 7px;
|
||||
top: calc(50% - 6px);
|
||||
border-left: 11px solid #83a9c5;
|
||||
border-top: 7px solid transparent;
|
||||
border-bottom: 7px solid transparent;
|
||||
}
|
||||
.if-arrow > * {
|
||||
position: relative;
|
||||
z-index: 1;
|
||||
padding: 0 7px;
|
||||
background: rgba(255,255,255,.96);
|
||||
}
|
||||
.if-flow-id {
|
||||
color: var(--blue);
|
||||
font-family: "SFMono-Regular", Consolas, monospace;
|
||||
font-size: 10px;
|
||||
font-weight: 900;
|
||||
}
|
||||
.if-arrow strong { font-size: 13px; }
|
||||
.if-arrow small { color: var(--muted); font-size: 10px; }
|
||||
.if-conditional { border-style: dashed; }
|
||||
.if-blocking .if-arrow::before { background: #d28c91; }
|
||||
.if-blocking .if-arrow::after { border-left-color: #d28c91; }
|
||||
.if-stage-summary {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(3,minmax(0,1fr));
|
||||
gap: 12px;
|
||||
margin-bottom: 18px;
|
||||
}
|
||||
.if-summary-card {
|
||||
padding: 16px;
|
||||
border: 1px solid var(--line);
|
||||
border-radius: 14px;
|
||||
background: white;
|
||||
}
|
||||
.if-summary-card b {
|
||||
display: block;
|
||||
margin-bottom: 5px;
|
||||
color: var(--blue);
|
||||
font-size: 11px;
|
||||
}
|
||||
.if-summary-card span { color: var(--muted); font-size: 12px; }
|
||||
.if-table-wrap {
|
||||
margin-top: 23px;
|
||||
overflow-x: auto;
|
||||
border: 1px solid var(--line);
|
||||
border-radius: 15px;
|
||||
background: white;
|
||||
}
|
||||
.if-table-wrap table {
|
||||
width: 100%;
|
||||
min-width: 1050px;
|
||||
border-collapse: collapse;
|
||||
font-size: 12px;
|
||||
}
|
||||
.if-table-wrap th,
|
||||
.if-table-wrap td {
|
||||
padding: 12px 13px;
|
||||
border-right: 1px solid var(--line);
|
||||
border-bottom: 1px solid var(--line);
|
||||
text-align: left;
|
||||
vertical-align: top;
|
||||
}
|
||||
.if-table-wrap th:last-child,
|
||||
.if-table-wrap td:last-child { border-right: 0; }
|
||||
.if-table-wrap tr:last-child td { border-bottom: 0; }
|
||||
.if-table-wrap th {
|
||||
color: white;
|
||||
background: var(--navy);
|
||||
font-size: 11px;
|
||||
white-space: nowrap;
|
||||
}
|
||||
.if-table-wrap tbody tr:nth-child(even) { background: #f8fafb; }
|
||||
.if-table-wrap td:first-child {
|
||||
color: var(--blue);
|
||||
font-family: "SFMono-Regular", Consolas, monospace;
|
||||
font-weight: 850;
|
||||
white-space: nowrap;
|
||||
}
|
||||
.if-block { color: #8f3038; font-weight: 700; }
|
||||
.if-pass { color: #266746; font-weight: 700; }
|
||||
.if-cross-flow {
|
||||
padding: 22px;
|
||||
border: 1px dashed #9aafc0;
|
||||
border-radius: 18px;
|
||||
background: #eef4f7;
|
||||
}
|
||||
@media (max-width: 920px) {
|
||||
.if-exchange { grid-template-columns: 125px minmax(210px,1fr) 125px; }
|
||||
}
|
||||
@media (max-width: 640px) {
|
||||
.if-intro { padding: 26px 20px; }
|
||||
.if-intro h2 { font-size: 30px; }
|
||||
.if-section-head { grid-template-columns: 1fr; gap: 8px; }
|
||||
.if-stage-summary { grid-template-columns: 1fr; }
|
||||
.if-flow-board { padding: 13px; }
|
||||
.if-exchange { grid-template-columns: 1fr; gap: 7px; }
|
||||
.if-exchange .if-actor { min-height: 45px; }
|
||||
.if-arrow { min-height: 72px; padding: 22px 10px; }
|
||||
.if-arrow::before {
|
||||
left: 50%;
|
||||
right: auto;
|
||||
top: 7px;
|
||||
bottom: 15px;
|
||||
width: 2px;
|
||||
height: auto;
|
||||
}
|
||||
.if-arrow::after {
|
||||
right: auto;
|
||||
left: calc(50% - 6px);
|
||||
top: auto;
|
||||
bottom: 5px;
|
||||
border-left: 7px solid transparent;
|
||||
border-right: 7px solid transparent;
|
||||
border-top: 11px solid #83a9c5;
|
||||
border-bottom: 0;
|
||||
}
|
||||
.if-blocking .if-arrow::after {
|
||||
border-top-color: #d28c91;
|
||||
border-left-color: transparent;
|
||||
}
|
||||
}
|
||||
@media print {
|
||||
.if-atlas { page-break-before: always; }
|
||||
.if-exchange,
|
||||
.if-summary-card { break-inside: avoid; box-shadow: none; }
|
||||
.if-table-wrap table { font-size: 8pt; }
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<header class="hero">
|
||||
<div class="hero-inner">
|
||||
<div class="eyebrow">CODEX MULTI-ROLE PROJECT FLOW · V0.3</div>
|
||||
<h1>项目推进总流程图</h1>
|
||||
<p>以业务、项目、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件、测试八类角色为基础，其中项目角色由中心 AI 承担；通过正式成果、角色内部确认门和中心服务路由，推进项目从需求到发布结项。</p>
|
||||
</div>
|
||||
</header>
|
||||
|
||||
<main class="page">
|
||||
<section class="map-shell">
|
||||
<div class="map-head">
|
||||
<div>
|
||||
<h2>从业务需求到发布结项</h2>
|
||||
<p>主线按成果和确认门推进；测试失败、业务验收驳回和需求变更通过回路返回正确阶段，不需要从头重启项目。</p>
|
||||
</div>
|
||||
<div class="legend" aria-label="流程图图例">
|
||||
<span>白色卡片＝项目阶段</span>
|
||||
<span>黄色门＝角色/阶段确认</span>
|
||||
<span>红色虚线＝返工回路</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="track" aria-label="完整项目推进流程">
|
||||
<article class="node">
|
||||
<div class="index">01</div>
|
||||
<div class="stage"><h3>业务需求</h3><span class="role">主责：业务</span></div>
|
||||
<div class="work"><strong>明确问题与价值。</strong>补齐业务目标、范围、规则、优先级和可度量成功指标。</div>
|
||||
<div class="artifacts"><strong>正式成果</strong><span>Project Background Brief（项目背景说明）<br>客户信息：客户名称、最终客户名称<br>项目名称：统一名称或客户规定的项目代号<br>产品要求：产品形态、提测平台<br>项目来源：新客户、新项目、旧产品升级、竞品替换或成本优化<br>需求背景：客户为什么提出这个需求，要解决什么问题<br>商业目标：获取订单、维护客户、降低成本、拓展市场或形成标准产品<br>预期价值：预计订单量、销售额</span><span>Project Milestone Plan（项目目标与里程碑计划）<br>提测时间<br>入库时间<br>小批量试产时间<br>量产时间</span></div>
|
||||
</article>
|
||||
<div class="connector"><div class="gate">业务确认需求基线</div></div>
|
||||
|
||||
<article class="node">
|
||||
<div class="index">02</div>
|
||||
<div class="stage"><h3>产品定义</h3><span class="role">主责：产品 · 批准：业务</span></div>
|
||||
<div class="work"><strong>把目标转成可实现、可验证的产品定义。</strong>技术负责人组织可行性评估，嵌入式应用层、嵌入式底层和硬件分别评估实现约束，测试评估可测试性。</div>
|
||||
<div class="artifacts"><strong>正式成果</strong><span>Project Initiation Package（立项资料）<br>立项书：包含产品详细信息、开发模式、开发范围、测试范围及其他补充信息<br>规格书：包含产品硬件规格和主要元器件型号（主控芯片、Sensor、镜头、WiFi 芯片）<br>功能清单：定义设备支持的功能<br>灯态：描述设备上电、绑定、升级、网络断开等状态下的指示灯状态与语音播报内容<br>产测功能清单：描述产测工具支持项<br>版本说明：描述当前版本的背景、主要功能等关键信息，并包含该项目此前所有版本和阶段的信息<br>结构板框图：包含主要器件位置和禁止限制区域</span><span>Hardware Development Package（硬件开发资料）<br>外设器件和关键器件规格书：主控、Flash、Sensor、复位按键、指示灯、WiFi 模块、音频功放驱动芯片、IR-CUT 驱动芯片、电机达林顿管驱动芯片<br>结构板框图：包含主要器件位置和禁止限制区域</span><span>Embedded Development Package（嵌入式开发资料）<br>平台 SDK<br>串号表<br>平台对接文档<br>平台接入标准及开发规范</span><span>Test & Acceptance Criteria（测试验收标准）<br>平台测试用例<br>客户验收测试用例和验收标准</span><span>Milestone Requirements（里程碑要求）<br>提测时间<br>客户验收时间<br>试产、量产时间</span></div>
|
||||
</article>
|
||||
<div class="connector"><div class="gate">产品确认方案，业务批准范围</div></div>
|
||||
|
||||
<article class="node">
|
||||
<div class="index">03</div>
|
||||
<div class="stage"><h3>项目规划</h3><span class="role">主责：中心 AI</span></div>
|
||||
<div class="work"><strong>基于成果、成员能力和依赖自动编排任务、进度和风险。</strong>任务计划草案先由技术负责人确认；中心 AI 只对存在疑点的任务定向询问对应执行角色，真实资源和日期基线再提交业务确认。</div>
|
||||
<div class="artifacts"><strong>正式成果</strong><span>Project Plan（项目计划）<br>项目任务拆分<br>实际项目排期</span><span>Risk Register（项目风险）<br>技术风险<br>时间风险<br>其他风险</span><span>Role Assignment（角色分工）</span><span>Product Documentation Package（产品资料整合）</span><span>Project Status Record（项目状态内部记录）<br>阶段与门禁<br>任务与依赖<br>阻塞与风险<br>决策与成果基线<br>下一步与时限</span></div>
|
||||
</article>
|
||||
<div class="connector"><div class="gate">技术负责人确认任务计划，问题任务由对应执行角色定向确认，业务确认资源与日期基线</div></div>
|
||||
|
||||
<article class="node">
|
||||
<div class="index">04</div>
|
||||
<div class="stage"><h3>方案设计</h3><span class="role">主责：技术负责人 · 协作：嵌入式应用层 + 嵌入式底层 + 硬件 + 测试</span></div>
|
||||
<div class="work"><strong>技术负责人统一组织总体方案设计和确认。</strong><div class="parallel"><span>技术负责人：总体架构、软硬件边界、关键决策</span><span>嵌入式应用层：业务逻辑、应用协议、功能模块设计</span><span>嵌入式底层：BSP、驱动、RTOS、HAL 设计</span><span>硬件：原理图、PCB、BOM、电源/信号/热设计</span><span>测试：范围、环境、用例、通过标准</span></div></div>
|
||||
<div class="artifacts"><strong>正式成果</strong><span>Solution Architecture（总体技术方案）</span><span>Software/Hardware Interface Contract（软硬件接口契约）</span><span>Hardware Design Package（硬件设计包）</span><span>Architecture Decision Record（架构决策记录）</span><span>Test Plan（测试计划）</span></div>
|
||||
</article>
|
||||
<div class="connector"><div class="gate">技术负责人确认整体方案，嵌入式应用层/嵌入式底层/硬件确认接口可实施，产品确认不偏离，测试确认可验证</div></div>
|
||||
|
||||
<article class="node">
|
||||
<div class="index">05</div>
|
||||
<div class="stage"><h3>嵌入式软硬件实现</h3><span class="role">并行：嵌入式应用层 + 嵌入式底层 + 硬件</span></div>
|
||||
<div class="work"><strong>嵌入式应用层、嵌入式底层和硬件在已确认总体方案及软硬件接口契约下并行实现、样机调试和自测。</strong>嵌入式底层将可消费版本交给嵌入式应用层合版，嵌入式应用层负责生成并提交唯一的最终固件版本；接口或器件约束发生重大偏离时返回技术负责人确认。</div>
|
||||
<div class="artifacts"><strong>正式成果</strong><span>Hardware Implementation Package（硬件实现资料）<br>原理图：DSN 源文档和 PDF 文档<br>PCB：源文档<br>贴片资料：PCBA BOM、器件位置图 PDF、贴片坐标<br>维修原理图<br>接口定义<br>静态测试报告</span><span>Low-Level Implementation Package（嵌入式底层实现资料）<br>硬件功能测试报告<br>BSP 输出路径<br>PSP 输出路径<br>WiFi 设备定频测试固件</span><span>Application Firmware Package（嵌入式应用层固件包）<br>正式固件、升级固件<br>自测用例<br>分区表<br>MD5 值文件<br>Flash 烧写固件<br>日志文件<br>Changelog<br>串口使能证书</span></div>
|
||||
</article>
|
||||
<div class="connector"><div class="gate">嵌入式底层提交可消费版本，嵌入式应用层合版并提交最终固件，技术负责人确认固件与硬件版本匹配</div></div>
|
||||
|
||||
<article class="node">
|
||||
<div class="index">06</div>
|
||||
<div class="stage"><h3>测试验证</h3><span class="role">主责：测试 · 修复：嵌入式应用层/嵌入式底层/硬件</span></div>
|
||||
<div class="work"><strong>执行功能、接口、软硬件集成和回归测试。</strong><div class="branch"><div class="path return"><strong>不通过</strong>应用问题→嵌入式应用层；BSP/驱动问题→嵌入式底层；电路/PCB/器件问题→硬件；接口/架构问题→技术负责人</div><div class="path pass"><strong>通过</strong>质量报告 + 测试证据包</div></div></div>
|
||||
<div class="artifacts"><strong>正式成果</strong><span>Functional Test Report（功能测试报告）<br>平台测试用例<br>内部测试用例</span><span>Reliability Test Report（可靠性测试报告）<br>高低温测试<br>跌落测试</span><span>Specialized Test Report（专项测试报告）<br>画质测试<br>WiFi 测试<br>功耗测试<br>长稳测试<br>试产一致性测试</span><span>Test Evidence Package（提测佐证）</span><span>Defect Analysis Report（缺陷分析报告）</span></div>
|
||||
</article>
|
||||
<div class="connector"><div class="gate">测试确认质量结论和剩余风险</div></div>
|
||||
|
||||
<article class="node">
|
||||
<div class="index">07</div>
|
||||
<div class="stage"><h3>业务验收</h3><span class="role">主责：产品</span></div>
|
||||
<div class="work"><strong>依据成功指标、验收标准和质量证据作最终判断。</strong><div class="branch"><div class="path return"><strong>驳回</strong>需求→产品；应用问题→嵌入式应用层；嵌入式底层软件问题→嵌入式底层；硬件问题→硬件；架构问题→技术负责人；证据问题→测试</div><div class="path pass"><strong>通过</strong>形成正式业务验收结论，进入发布准备</div></div></div>
|
||||
<div class="artifacts"><strong>正式成果</strong><span>Platform Test Approval Report（平台提测通过报告）</span><span>Customer Acceptance Approval Report（客户验收通过报告）</span><span>Conditional Acceptance Items（附条件验收事项）</span></div>
|
||||
</article>
|
||||
<div class="connector"><div class="gate">业务批准验收结论和上线条件</div></div>
|
||||
|
||||
<article class="node">
|
||||
<div class="index">08</div>
|
||||
<div class="stage"><h3>发布结项</h3><span class="role">中心 AI 协调 · 技术负责人确认 · 嵌入式应用层/嵌入式底层/硬件执行 · 测试验证</span></div>
|
||||
<div class="work"><strong>检查应用、固件、板卡版本、BOM/ECO、发布清单、冒烟、回滚和遗留事项承接。</strong>中心 AI 汇总复盘并归档角色会话。</div>
|
||||
<div class="artifacts"><strong>正式成果</strong><span>Closure Documentation Archive（结项资料归档）<br>形成最终结果的流程文件</span><span>Change Log（变更记录）</span><span>Closure Report（结项报告）</span><span>Process Closure Summary（流程闭环总结）</span></div>
|
||||
</article>
|
||||
</div>
|
||||
|
||||
<div class="crosscut">
|
||||
<strong>贯穿全流程：Change Request（需求变更申请）</strong>
|
||||
<p>任何角色都可提出变更；中心 AI 自动组织影响评估，产品评估范围，技术负责人评估总体方案，嵌入式应用层、嵌入式底层和硬件分别评估实现与工作量，测试评估验证成本，业务批准后更新对应基线，并从受影响阶段继续推进。</p>
|
||||
</div>
|
||||
<div class="crosscut">
|
||||
<strong>成果适用性：Artifact Waiver（成果文件豁免）</strong>
|
||||
<p>阶段成果默认必须由主责角色输出；仅当主责角色提交不适用申请、中心 AI 完成项目级适用性与影响审查并取得必要确认后，才能将该成果标记为 WAIVED。未批准的成果仍为 REQUIRED，并继续阻塞阶段门禁。</p>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<div class="if-atlas" id="information-flow-atlas">
|
||||
<section class="if-intro">
|
||||
<div class="if-eyebrow">STAGE INFORMATION FLOW ATLAS · V0.3</div>
|
||||
<h2>各阶段角色信息流图谱</h2>
|
||||
<p>以下内容直接承接总流程图，展示每条会影响成果、决策、门禁、返工或版本的正式信息流，并说明触发条件、发送方、接收方、载荷、确认要求和阻塞约束。</p>
|
||||
<div class="if-quicknav">
|
||||
<a href="#rules">通用规则</a><a href="#stage1">01 业务需求</a><a href="#stage2">02 产品定义</a><a href="#stage3">03 项目规划</a><a href="#stage4">04 方案设计</a><a href="#stage5">05 软硬件实现</a><a href="#stage6">06 测试验证</a><a href="#stage7">07 业务验收</a><a href="#stage8">08 发布结项</a><a href="#change">变更与异常</a><a href="#waiver">成果豁免</a>
|
||||
</div>
|
||||
</section>
|
||||
<section class="if-section" id="rules">
|
||||
<div class="if-section-head">
|
||||
<div class="if-section-no">00 / RULES</div>
|
||||
<div><h2>所有阶段共同遵守的流转规则</h2><p>角色可以直接讨论，但讨论不能自动成为项目事实；正式结论必须回到中心 AI，经过校验、登记和重新分发。</p></div>
|
||||
</div>
|
||||
<div class="if-callout">唯一正式路径：触发事件 → 主责角色内部完成 AI 辅助自审与人工确认 → 以统一角色主体提交中心 AI → 中心 AI 做形式校验、版本/证据检查和跨角色冲突检查 → 路由目标角色 → 目标角色内部确认后形成正式结果 → 中心 AI 登记与分发下游 → 更新门禁。信息流图只使用正式角色名称，不单列角色内部的 AI 会话与人工确认过程。</div>
|
||||
<div class="if-callout" style="margin-top: 14px">成果默认 REQUIRED：主责角色必须输出；确认不适用时必须走 Artifact Waiver 流程。只有 APPROVED 的 WAIVED 状态可以替代成果满足门禁，任何角色都不得静默删除或跳过文件。</div>
|
||||
<div class="if-role-legend">
|
||||
<span class="if-actor if-center">中心 AI</span><span class="if-actor if-business">业务</span><span class="if-actor if-product">产品</span><span class="if-actor if-tech">技术负责人</span><span class="if-actor if-app">嵌入式应用层</span><span class="if-actor if-low">嵌入式底层</span><span class="if-actor if-hardware">硬件</span><span class="if-actor if-test">测试</span>
|
||||
</div>
|
||||
<div class="if-table-wrap" style="margin-bottom: 22px"><table><thead><tr><th>主体</th><th>是否为项目职能角色</th><th>定义</th><th>主要确认权限</th><th>不能做什么</th></tr></thead><tbody>
|
||||
<tr><td>各专业角色</td><td>是</td><td>图中的正式角色名称统一代表该角色完成 AI 辅助自审与人工确认后的责任主体；内部审查过程不作为跨角色信息流单列。</td><td>以角色名义确认并发出本角色专业结论、正式成果、现实工期承诺、风险接受和正式交付。</td><td>不能替其他角色作出专业确认。</td></tr>
|
||||
<tr><td>业务</td><td>是；同时承担项目级组织授权</td><td>业务节点同时包含业务专业判断和项目级组织授权的内部确认。</td><td>除业务成果外，负责确认计划基线、真实资源、预算、采购/打样、日期、暂停/取消和高影响成果豁免。</td><td>不替代产品、技术负责人、硬件或测试等角色给出专业结论。</td></tr>
|
||||
<tr><td>中心 AI</td><td>是；承担项目角色</td><td>项目唯一正式信息中心、任务路由器、成果校验器、阶段门禁执行者和项目状态内部记录维护者。</td><td>可依据证据更新项目状态、按角色需要分发状态快照、完成普通项目级审查和低影响豁免；高影响事项必须升级给业务。</td><td>不能自行承诺真实资源、预算、范围、日期或专业结论，也不能以推测代替角色提供的状态证据。</td></tr>
|
||||
</tbody></table></div>
|
||||
<div class="if-flow-board">
|
||||
<div class="if-exchange"><div class="if-actor if-business">任意角色</div><div class="if-arrow"><span class="if-flow-id">G.1</span><strong>提交已完成内部审查确认的消息、成果或请求</strong><small>附 self_check_result、internal_approved、项目、任务、版本和证据引用</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">G.2</span><strong>形式校验、跨角色冲突检查、登记并路由</strong><small>不替角色判断专业内容质量</small></div><div class="if-actor if-product">目标角色</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-product">目标角色</div><div class="if-arrow"><span class="if-flow-id">G.3</span><strong>完成内部审查后返回结构化结果</strong><small>角色内部确认不单列；禁止转发完整聊天记录</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
</div>
|
||||
<div class="if-callout" style="margin: 22px 0 14px"><strong>项目状态内部记录与按需同步：</strong>Project Status Record（项目状态内部记录）是中心 AI 持续维护的内部运行记录，不是新增角色。它汇总当前阶段、门禁、任务、依赖、阻塞、风险、决策、成果基线、下一步和时限；中心 AI 在关键状态变化时主动推送，也响应角色按项目、阶段或任务发起的查询。</div>
|
||||
<div class="if-flow-board">
|
||||
<div class="if-exchange if-conditional"><div class="if-actor if-business">任意角色</div><div class="if-arrow"><span class="if-flow-id">S.1 · 按需查询</span><strong>请求与本角色职责相关的最新项目状态</strong><small>指定 project_id、stage/task scope、关注项和期望时点</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">S.2 · 自动或按需</span><strong>生成并分发角色化项目状态快照</strong><small>关键状态变化时主动推送；收到 S.1 后按查询范围返回</small></div><div class="if-actor if-product">请求角色及受影响角色</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-product">接收角色</div><div class="if-arrow"><span class="if-flow-id">S.3</span><strong>确认状态或携带证据提出纠正</strong><small>不得仅凭口头判断覆盖已登记状态</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange if-conditional"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">S.4 · 状态纠正</span><strong>校验依据、更新内部记录并重新分发</strong><small>保留旧状态、变更原因、证据引用和生效时间</small></div><div class="if-actor if-product">全部受影响角色</div></div>
|
||||
</div>
|
||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>对项目执行的影响</th></tr></thead><tbody>
|
||||
<tr><td>S.1</td><td>角色需要了解当前项目、阶段、任务、依赖、风险或门禁状态，但现有上下文不足或可能已过期。</td><td>任意角色 → 中心 AI</td><td>project_id、请求范围、关注字段、所需详细度、as_of 要求和用途。</td><td>只能查询项目授权范围内的信息；请求角色无需知道中心 AI 的内部存储结构。</td><td>创建一次按需状态查询。</td></tr>
|
||||
<tr><td>S.2</td><td>收到 S.1；或阶段/门禁、任务分派、依赖、阻塞、风险、决策、成果基线、required_by 发生关键变化。</td><td>中心 AI → 请求角色及受影响角色</td><td>Project Status Snapshot：project_id、state_version、as_of、stage/gate、相关任务、依赖、阻塞、风险、决策、baseline_refs、next_actions、required_by、evidence_refs。</td><td>按最小必要原则裁剪为角色化上下文；禁止转发无关角色的完整会话或未确认专业判断；所有状态必须有证据来源。</td><td>角色获得可执行的最新上下文。</td></tr>
|
||||
<tr><td>S.3</td><td>角色收到状态快照。</td><td>接收角色 → 中心 AI</td><td>ACK；或 correction_request、受影响字段、正确值、原因、evidence_refs、internal_approved。</td><td>没有证据的异议不得直接覆盖状态；存在争议时进入 E.1–E.4。</td><td>确认可继续执行，或触发状态纠正。</td></tr>
|
||||
<tr><td>S.4</td><td>纠正请求通过身份、版本、证据及跨角色一致性检查。</td><td>中心 AI → 全部受影响角色</td><td>新 state_version、变更字段、旧值/新值、变更原因、证据、生效时间及受影响任务。</td><td>保留状态历史，不覆盖旧版本；改变正式基线时必须转入 Change Request。</td><td>相关角色切换到新的有效状态快照。</td></tr>
|
||||
</tbody></table></div>
|
||||
<div class="if-callout" style="margin: 22px 0 14px"><strong>异常协同补充机制：</strong>任何条件流、阻塞流、跨角色冲突或无法在时限内异步收敛的问题，都必须进入 E.1–E.4。中心 AI 主动提醒关联角色并提供完整问题包；问题复杂时建议由当前主责角色组织线下会议。会议本身不直接形成项目事实，只有参与角色统一确认并回传中心 AI 的结构化结论，才能登记并恢复原流程。</div>
|
||||
<div class="if-flow-board">
|
||||
<div class="if-exchange if-conditional"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">E.1 · 异常触发</span><strong>主动提醒当前主责角色及全部关联角色</strong><small>发送问题、证据、冲突点、影响范围、原流程位置和响应时限</small></div><div class="if-actor if-product">当前主责角色及关联角色</div></div>
|
||||
<div class="if-exchange if-conditional"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">E.2 · 复杂问题</span><strong>建议由当前主责角色组织线下会议</strong><small>提供建议参会角色、议题、待决策项、证据包和结论模板</small></div><div class="if-actor if-product">当前主责角色及关联角色</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-product">当前主责角色</div><div class="if-arrow"><span class="if-flow-id">E.3</span><strong>提交参与角色统一确认的会议结论</strong><small>包含结论、分歧处理、变更项、责任角色、期限、版本和确认状态</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">E.4</span><strong>校验、登记结论并恢复原异常流程</strong><small>只恢复被阻塞的原流程，不以会议记录替代正式成果</small></div><div class="if-actor if-product">原流程及关联角色</div></div>
|
||||
</div>
|
||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>对原流程的影响</th></tr></thead><tbody>
|
||||
<tr><td>E.1</td><td>条件流或阻塞流被触发；出现跨角色冲突、依赖异常、证据矛盾、任务逾期或结果无法被下游使用。</td><td>中心 AI → 当前主责角色及全部关联角色</td><td>issue_id、source_flow_id、问题摘要、证据与版本引用、冲突点、影响范围、关联角色、required_by。</td><td>中心 AI 必须主动提醒，不得只更新状态；关联角色依据正式问题包开展异步确认。</td><td class="if-block">原流程保持 ACTIVE/BLOCKED，等待问题关闭。</td></tr>
|
||||
<tr><td>E.2</td><td>涉及多个专业角色且结论冲突，影响范围/架构/接口/成本/进度/质量，或在要求时限内无法通过异步消息收敛。</td><td>中心 AI → 当前主责角色及关联角色</td><td>建议参会名单、会议目的、议题、冲突矩阵、证据包、待决策项、结论模板和完成时限。</td><td>中心 AI 只建议会议和准备输入，不主持专业裁决；当前主责角色负责组织，关联角色共同参与确认。</td><td class="if-block">会议结论回传前，不恢复原流程。</td></tr>
|
||||
<tr><td>E.3</td><td>线下会议完成并形成统一结论。</td><td>当前主责角色 → 中心 AI</td><td>Meeting Decision Record：参与角色、统一结论、保留分歧、变更项、责任角色、期限、artifact/version/evidence_refs、internal_approved。</td><td>禁止只上传录音、聊天记录或未经参与角色确认的纪要；仍有分歧时继续保持阻塞并明确升级项。</td><td>形成可登记的异常处置结论。</td></tr>
|
||||
<tr><td>E.4</td><td>统一结论通过中心 AI 的形式、版本、证据和跨角色一致性检查。</td><td>中心 AI → 原流程及关联角色</td><td>decision_id、登记结果、受影响成果/任务、恢复点、后续动作和新时限。</td><td>中心 AI 不改写专业结论；若结论改变正式基线，必须转入 Change Request。</td><td class="if-pass">从 source_flow_id 对应位置恢复当前流程。</td></tr>
|
||||
</tbody></table></div>
|
||||
<div class="if-table-wrap"><table><thead><tr><th>通用约束</th><th>执行要求</th><th>不满足时</th></tr></thead><tbody>
|
||||
<tr><td>消息身份</td><td>必须包含 project_id、task_id、message_id、from/to role、stage、reply_to。</td><td class="if-block">拒绝进入正式流。</td></tr>
|
||||
<tr><td>成果版本</td><td>必须包含 artifact_id、version、status、supersedes、evidence_refs。</td><td class="if-block">标记为 DRAFT 或 REJECTED_ARTIFACT。</td></tr>
|
||||
<tr><td>成果责任</td><td>原则上由流程图指定的主责角色创建、更新并提交对应成果。</td><td class="if-block">其他角色不能代签；中心 AI 返回主责角色。</td></tr>
|
||||
<tr><td>角色内部审查</td><td>每个角色必须在内部完成 AI 辅助的 Schema/专业检查以及人工确认；跨角色流转时统一以正式角色名称表示。</td><td class="if-block">未附 self_check_result 或 internal_approved 的成果不能提交中心 AI。</td></tr>
|
||||
<tr><td>专业发起权</td><td>专业活动由对应主责角色判断并发起；中心 AI 只负责格式校验、任务路由、状态跟踪和结果登记。</td><td class="if-block">中心 AI 不得越权替角色发起专业决策。</td></tr>
|
||||
<tr><td>中心 AI 审查边界</td><td>仅做 Schema/必填结构、身份、版本、证据、审批状态检查，以及多个角色正式信息之间的重复、冲突和依赖一致性检查。</td><td class="if-block">不得替业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件或测试判断本专业内容是否充分。</td></tr>
|
||||
<tr><td>成果豁免</td><td>仅主责角色可提出不适用申请；经中心 AI 项目审查及必要确认后标记 WAIVED。</td><td class="if-block">未批准仍为 REQUIRED，继续阻塞门禁。</td></tr>
|
||||
<tr><td>角色确认</td><td>专业结论由对应角色内部形成并确认；项目级组织授权由业务内部完成。信息流图只显示统一的正式角色主体。</td><td class="if-block">未完成内部确认时不得对外发出，阶段保持 WAITING_CONFIRMATION。</td></tr>
|
||||
<tr><td>项目状态同步</td><td>中心 AI 维护有版本和证据的项目状态内部记录，并在关键变化时主动向受影响角色推送，或按 S.1–S.4 响应角色查询与纠正。</td><td class="if-block">状态来源、版本或时点不明时不得作为任务执行依据。</td></tr>
|
||||
<tr><td>异常协同</td><td>中心 AI 对异常主动提醒关联角色；复杂问题建议当前主责角色组织线下会议，统一确认后提交结构化结论。</td><td class="if-block">未按 E.1–E.4 闭环，不得恢复原流程或推进门禁。</td></tr>
|
||||
<tr><td>直接讨论</td><td>最终结论、约束、证据和影响必须回传中心 AI。</td><td class="if-block">不能作为下游输入。</td></tr>
|
||||
<tr><td>门禁</td><td>只有成果完整、版本正确、证据可访问、确认齐全时才能 PASS。</td><td class="if-block">阶段保持 ACTIVE/BLOCKED。</td></tr>
|
||||
</tbody></table></div>
|
||||
</section>
|
||||
|
||||
<section class="if-section" id="stage1">
|
||||
<div class="if-section-head"><div class="if-section-no">01 / BUSINESS</div><div><h2>阶段 1：业务需求信息流</h2><p>把客户背景、商业目标和关键里程碑转换成经过业务角色内部确认的需求基线。</p></div></div>
|
||||
<div class="if-stage-summary"><div class="if-summary-card"><b>主责</b><span>业务</span></div><div class="if-summary-card"><b>核心成果</b><span>项目背景说明、项目目标与里程碑计划</span></div><div class="if-summary-card"><b>门禁</b><span>业务完成内部审查并确认需求基线</span></div></div>
|
||||
<div class="if-callout" style="margin-bottom: 18px; font-size: 14px">业务在内部完成原始信息收集、业务成果 Schema 检查和人工确认后，以统一的“业务”主体提交成果。中心 AI 完成形式校验、版本登记和跨角色冲突检查后，将业务成果评审版本路由给产品；产品据此判断是否需要早期风险预检，并负责指定一个或多个预检对象角色。中心 AI 只能按照产品给出的角色名单路由，不得自行增删或替换。业务最终确认后，中心 AI 再向产品分发正式业务基线并开启产品定义。</div>
|
||||
<div class="if-flow-board">
|
||||
<div class="if-exchange"><div class="if-actor if-business">业务</div><div class="if-arrow"><span class="if-flow-id">F1.1</span><strong>提交完成内部审查的项目背景与里程碑草案</strong><small>附 self_check_result、internal_approved 和来源引用</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange if-conditional if-blocking"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F1.2 · 条件触发</span><strong>仅在发现形式错误或跨来源冲突时返回问题</strong><small>触发范围仅限 Schema、身份、版本、证据和已登记信息冲突；无异常则不启用此流</small></div><div class="if-actor if-business">业务</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F1.3</span><strong>分发已通过形式校验的业务成果评审版本</strong><small>附成果版本、证据引用、状态和待确认项</small></div><div class="if-actor if-product">产品</div></div>
|
||||
<div class="if-exchange if-conditional"><div class="if-actor if-product">产品</div><div class="if-arrow"><span class="if-flow-id">F1.4</span><strong>指定对象角色并提交早期风险预检请求</strong><small>产品根据风险内容选择一个或多个项目角色</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F1.5</span><strong>按产品指定名单校验、提醒并路由预检任务</strong><small>主动提醒全部关联角色；不得增删产品指定名单</small></div><div class="if-actor if-tech">产品指定的对象角色</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-tech">产品指定的对象角色</div><div class="if-arrow"><span class="if-flow-id">F1.6</span><strong>返回内部确认结果；复杂问题返回统一会议结论</strong><small>无法异步收敛时，由产品组织线下会议并按 E.3 回传</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-business">业务</div><div class="if-arrow"><span class="if-flow-id">F1.7</span><strong>确认需求基线</strong><small>业务内部审查、形式校验和预检问题均已关闭</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F1.8</span><strong>向产品分发正式业务基线并开启产品定义</strong><small>只能引用已 BASELINED 的成果版本</small></div><div class="if-actor if-product">产品</div></div>
|
||||
</div>
|
||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>对阶段的影响</th></tr></thead><tbody>
|
||||
<tr><td>F1.1</td><td>收到新的客户或商业机会，且业务已完成原始信息收集、Schema 自审和内部确认。</td><td>业务 → 中心 AI</td><td>项目背景、里程碑、self_check_result、internal_approved、来源和草案版本。</td><td>中心 AI 不重复判断业务内容质量，只检查形式和跨来源一致性。</td><td>进入中心登记。</td></tr>
|
||||
<tr><td>F1.2（条件流）</td><td>仅当 Schema/身份/版本/证据不合规，或与已登记正式信息发生冲突时触发；不存在上述问题时跳过。</td><td>中心 AI → 业务</td><td>形式错误、冲突来源、受影响字段和修正要求。</td><td>中心 AI 不能生成业务缺失项或替业务补写事实；无错误或冲突时不得发起此流。</td><td class="if-block">触发后，错误或冲突关闭前阻塞登记；未触发则直接进入 F1.3。</td></tr>
|
||||
<tr><td>F1.3</td><td>业务成果通过中心 AI 的 Schema、身份、版本、证据和跨角色冲突检查并完成登记。</td><td>中心 AI → 产品</td><td>业务成果评审版本、artifact_id、version、status、evidence_refs、待确认项和回复时限。</td><td>状态必须标明 REVIEW_READY；不得冒充 BASELINED 正式成果，产品不得据此直接启动阶段 2。</td><td>产品获得早期风险识别所需上下文。</td></tr>
|
||||
<tr><td>F1.4</td><td>产品审阅业务成果后，判断存在需要其他专业角色提前确认的风险。</td><td>产品 → 中心 AI</td><td>预检原因、预检问题、target_role_ids、相关需求字段、期望输出和时限；目标角色可为一个或多个。</td><td>是否预检、预检范围及对象角色均由产品负责指定；中心 AI 不代替产品判断。</td><td>按产品指定名单创建预检任务。</td></tr>
|
||||
<tr><td>F1.5–1.6</td><td>产品预检请求格式完整，且指定的对象角色均为当前项目有效成员。</td><td>中心 AI ↔ 产品指定的对象角色</td><td>按对象角色拆分的预检问题、相关业务字段、成果版本、回复要求和时限；各对象角色返回内部确认后的本专业红线、风险、证据与待澄清项。</td><td>中心 AI 必须主动提醒全部关联角色，只校验、路由和汇总，不得自行增删产品指定名单。多角色结论冲突、影响较大或无法异步收敛时，建议由产品组织线下会议；参与角色统一确认的结论按 E.3 回传后，才能继续当前流程。</td><td>补充业务澄清和早期风险登记；复杂问题进入 E.1–E.4，闭环前保持阻塞。</td></tr>
|
||||
<tr><td>F1.7</td><td>业务内部审查、中心形式校验和预检问题均已关闭。</td><td>业务 → 中心 AI</td><td>INTERNALLY_APPROVED 的需求和里程碑版本。</td><td>角色内部确认状态、时间和版本必须记录。</td><td class="if-pass">门禁可进入评审。</td></tr>
|
||||
<tr><td>F1.8</td><td>业务确认完成，中心 AI 已登记 BASELINED 正式版本且阶段门禁 PASS。</td><td>中心 AI → 产品</td><td>正式业务成果、artifact_id、version、baseline_refs、evidence_refs、阶段 2 任务和确认时限。</td><td>只允许分发 BASELINED 当前有效版本；分发事件和接收状态必须登记，草稿或过期版本不得作为产品定义输入。</td><td class="if-pass">产品接收后开启阶段 2。</td></tr>
|
||||
</tbody></table></div>
|
||||
</section>
|
||||
|
||||
<section class="if-section" id="stage2">
|
||||
<div class="if-section-head"><div class="if-section-no">02 / PRODUCT</div><div><h2>阶段 2：产品定义信息流</h2><p>产品形成完整立项资料，并让技术负责人、嵌入式应用层、嵌入式底层、硬件和测试从各自专业角度完成可行性确认。</p></div></div>
|
||||
<div class="if-stage-summary"><div class="if-summary-card"><b>主责</b><span>产品；业务批准范围</span></div><div class="if-summary-card"><b>核心成果</b><span>立项资料、硬件/嵌入式资料、验收标准、里程碑要求</span></div><div class="if-summary-card"><b>门禁</b><span>产品确认方案，业务批准范围，约束和测试标准完整</span></div></div>
|
||||
<div class="if-flow-board">
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F2.1</span><strong>下发产品定义任务</strong><small>附阶段 1 基线和全部红线约束</small></div><div class="if-actor if-product">产品</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-product">产品</div><div class="if-arrow"><span class="if-flow-id">F2.2</span><strong>提交立项资料草案与专业评审请求</strong><small>产品明确评审角色、问题、范围和期望输出</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F2.3</span><strong>校验请求并并行路由专业评审</strong><small>按产品指定范围裁剪上下文，不新增专业问题</small></div><div class="if-actor if-tech">技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-tech">评审角色</div><div class="if-arrow"><span class="if-flow-id">F2.4</span><strong>返回可行性、缺口和约束</strong><small>每条意见必须关联具体成果字段</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange if-blocking"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F2.5</span><strong>汇总跨角色冲突并返回产品裁决/修订</strong><small>中心 AI 只指出冲突，不替产品作内容决定</small></div><div class="if-actor if-product">产品</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-product">产品</div><div class="if-arrow"><span class="if-flow-id">F2.6</span><strong>提交内部确认后的产品方案</strong><small>关闭评审问题并标明保留风险</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F2.7</span><strong>请求业务批准范围</strong><small>呈现范围、里程碑、成本/风险影响</small></div><div class="if-actor if-business">业务</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-business">业务</div><div class="if-arrow"><span class="if-flow-id">F2.8</span><strong>批准、驳回或附条件批准</strong><small>附条件项必须有责任人与期限</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
</div>
|
||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>对阶段的影响</th></tr></thead><tbody>
|
||||
<tr><td>F2.1–2.2</td><td>阶段 2 启动。</td><td>中心 AI ↔ 产品</td><td>需求基线、立项书、规格、功能/灯态/产测清单、版本说明、板框图、验收标准，以及产品定义的评审角色/问题/范围。</td><td>产品先自审，所有资料必须引用阶段 1 基线；专业评审由产品发起。</td><td>进入专业评审路由。</td></tr>
|
||||
<tr><td>F2.3</td><td>产品提交可评审草案和评审请求。</td><td>中心 AI → 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</td><td>产品定义的角色化评审任务和相关资料。</td><td>中心 AI 只校验和路由；技术负责人看总体，嵌入式应用层看功能，嵌入式底层看 BSP/HAL，硬件看器件/板框，测试看可测性。</td><td>并行评审。</td></tr>
|
||||
<tr><td>F2.4</td><td>各角色完成评审。</td><td>技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试 → 中心 AI</td><td>结论、缺失、风险、证据、建议和是否阻塞。</td><td>不得只回复“可行/不可行”。</td><td>形成冲突矩阵。</td></tr>
|
||||
<tr><td>F2.5–2.6</td><td>存在冲突或缺口。</td><td>中心 AI ↔ 产品</td><td>字段级修订清单、变更影响、关闭说明。</td><td>产品在内部确认最终版本后统一发出。</td><td class="if-block">问题未关闭则 HOLD。</td></tr>
|
||||
<tr><td>F2.7–2.8</td><td>产品方案专业评审完成。</td><td>中心 AI ↔ 业务</td><td>范围、验收、里程碑、风险和附条件事项。</td><td>范围批准由业务完成内部授权后统一给出。</td><td class="if-pass">批准后进入阶段 3。</td></tr>
|
||||
</tbody></table></div>
|
||||
</section>
|
||||
|
||||
<section class="if-section" id="stage3">
|
||||
<div class="if-section-head"><div class="if-section-no">03 / PLANNING</div><div><h2>阶段 3：项目规划信息流</h2><p>中心 AI 根据有效基线生成任务计划草案，先由技术负责人确认整体任务结构、技术顺序和依赖；仅对存在疑点的任务，定向向对应执行角色补充确认。</p></div></div>
|
||||
<div class="if-stage-summary"><div class="if-summary-card"><b>主责</b><span>中心 AI；技术负责人确认任务计划</span></div><div class="if-summary-card"><b>核心成果</b><span>项目计划、风险登记、角色分工、产品资料整合、项目状态内部记录</span></div><div class="if-summary-card"><b>门禁</b><span>技术负责人确认整体计划；问题任务完成定向确认；业务确认资源与日期基线</span></div></div>
|
||||
<div class="if-flow-board">
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F3.1</span><strong>提交任务计划草案，请求整体确认</strong><small>附 WBS、技术顺序、依赖、初始排期、风险和基线引用</small></div><div class="if-actor if-tech">技术负责人</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-tech">技术负责人</div><div class="if-arrow"><span class="if-flow-id">F3.2</span><strong>确认整体任务计划或返回调整意见</strong><small>确认任务结构、技术顺序、依赖关系和关键风险</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange if-conditional"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F3.3 · 问题任务</span><strong>仅对存在疑点的任务发起定向确认</strong><small>缺少责任、输入输出、依赖、估算、资源、日期、证据或存在冲突时触发</small></div><div class="if-actor if-product">对应执行角色</div></div>
|
||||
<div class="if-exchange if-conditional"><div class="if-actor if-product">对应执行角色</div><div class="if-arrow"><span class="if-flow-id">F3.4</span><strong>只确认被询问任务的工期、资源和风险</strong><small>不得要求执行角色重复确认整份任务计划</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange if-blocking"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F3.5</span><strong>提醒关联角色并协调剩余冲突、重排计划</strong><small>问题仍未关闭或日期不可达时按 E.1–E.4 处理</small></div><div class="if-actor if-product">技术负责人及受影响角色</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F3.6</span><strong>请求资源与日期基线授权</strong><small>真实人员、采购、打样、成本和日期由业务内部确认</small></div><div class="if-actor if-business">业务</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-business">业务</div><div class="if-arrow"><span class="if-flow-id">F3.7</span><strong>批准或要求调整资源与日期基线</strong><small>记录内部批准状态、范围和条件</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F3.8</span><strong>向相关执行角色发布基线计划和正式任务</strong><small>附任务 ID、依赖、交付物和门禁；后续状态按 S.1–S.4 同步</small></div><div class="if-actor if-product">相关执行角色</div></div>
|
||||
</div>
|
||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>对阶段的影响</th></tr></thead><tbody>
|
||||
<tr><td>F3.1–3.2</td><td>阶段 2 门禁通过，中心 AI 已依据有效基线形成任务计划草案。</td><td>中心 AI ↔ 技术负责人</td><td>WBS、任务结构、技术顺序、关键路径、输入输出、依赖、初始排期、风险和基线引用。</td><td>技术负责人确认整体任务计划；中心 AI 不直接向全部执行角色征求整份计划确认。</td><td>形成技术负责人确认的任务计划草案。</td></tr>
|
||||
<tr><td>F3.3–3.4（条件流）</td><td>中心 AI 发现任务缺少责任角色、输入、输出、依赖、估算、资源、日期或证据；任务之间存在冲突；或技术负责人明确标记待确认项。</td><td>中心 AI ↔ 对应执行角色</td><td>仅包含问题任务的 task_id、疑点字段、上下游依赖、基线引用、待确认问题、回复要求和时限；执行角色返回该任务的工期、资源、风险、依据和 internal_approved。</td><td>必须定向发送给该任务的执行角色，不得广播给全部角色，也不得要求执行角色重复确认无疑点任务。</td><td>补齐或修正问题任务；未触发时直接跳过。</td></tr>
|
||||
<tr><td>F3.5</td><td>定向确认后仍存在资源冲突、关键路径冲突或日期不可达。</td><td>中心 AI ↔ 技术负责人及受影响角色</td><td>冲突点、可选排法、阶段影响、关联角色和响应时限。</td><td>中心 AI 必须主动提醒，不得静默覆盖技术负责人或执行角色的确认；复杂冲突按 E.1–E.4 闭环。</td><td class="if-block">保持计划草案，冲突关闭前不得基线化。</td></tr>
|
||||
<tr><td>F3.6–3.7</td><td>技术负责人已确认整体计划，问题任务和剩余冲突均已关闭，计划涉及真实人员、采购、打样、成本或日期基线。</td><td>中心 AI ↔ 业务</td><td>任务计划、资源请求、成本、里程碑和风险。</td><td>中心 AI 无权自行批准现实资源和日期；业务完成内部授权后统一回复。</td><td class="if-pass">批准后可基线化。</td></tr>
|
||||
<tr><td>F3.8</td><td>技术负责人确认有效、问题任务已关闭且业务批准资源与日期基线。</td><td>中心 AI → 相关执行角色</td><td>BASELINED 计划、角色相关正式任务、风险登记和初始 Project Status Snapshot。</td><td>每个角色只接收与自身任务和依赖相关的计划内容；后续变更走 Change Request，执行状态按 S.1–S.4 同步。</td><td class="if-pass">相关角色接收任务，开启阶段 4。</td></tr>
|
||||
</tbody></table></div>
|
||||
</section>
|
||||
|
||||
<section class="if-section" id="stage4">
|
||||
<div class="if-section-head"><div class="if-section-no">04 / DESIGN</div><div><h2>阶段 4：方案设计信息流</h2><p>技术负责人组织总体方案；产品、嵌入式应用层、嵌入式底层、硬件和测试围绕同一份软硬件接口契约完成多轮确认。</p></div></div>
|
||||
<div class="if-stage-summary"><div class="if-summary-card"><b>主责</b><span>技术负责人</span></div><div class="if-summary-card"><b>核心成果</b><span>总体技术方案、软硬件接口契约、硬件设计包、架构决策、测试计划</span></div><div class="if-summary-card"><b>门禁</b><span>方案确认、接口可实施、需求不偏离、测试可验证</span></div></div>
|
||||
<div class="if-flow-board">
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F4.1</span><strong>下发总体方案设计任务</strong><small>附产品基线、计划、风险和所有约束</small></div><div class="if-actor if-tech">技术负责人</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-tech">技术负责人</div><div class="if-arrow"><span class="if-flow-id">F4.2</span><strong>提交总体方案与接口契约草案</strong><small>含边界、关键决策、非功能和风险</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F4.3</span><strong>并行分发角色化设计任务</strong><small>每个角色在同一契约版本上工作</small></div><div class="if-actor if-app">产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</div></div>
|
||||
<div class="if-exchange if-conditional"><div class="if-actor if-app">嵌入式应用层</div><div class="if-arrow"><span class="if-flow-id">F4.4</span><strong>提出 HAL、资源和应用接口需求</strong><small>接口新增或资源不足时触发</small></div><div class="if-actor if-center">中心 AI → 嵌入式底层 / 技术负责人</div></div>
|
||||
<div class="if-exchange if-conditional"><div class="if-actor if-low">嵌入式底层</div><div class="if-arrow"><span class="if-flow-id">F4.5</span><strong>提出引脚、电平、时序和器件约束</strong><small>HAL 与硬件设计存在依赖时</small></div><div class="if-actor if-center">中心 AI → 硬件 / 技术负责人</div></div>
|
||||
<div class="if-exchange if-conditional"><div class="if-actor if-hardware">硬件</div><div class="if-arrow"><span class="if-flow-id">F4.6</span><strong>反馈器件、PCB、电源、空间与热约束</strong><small>影响接口、成本或性能时</small></div><div class="if-actor if-center">中心 AI → 技术负责人 / 嵌入式底层 / 产品</div></div>
|
||||
<div class="if-exchange if-blocking"><div class="if-actor if-test">测试</div><div class="if-arrow"><span class="if-flow-id">F4.7</span><strong>提交不可测试项和环境/治具缺口</strong><small>验收标准无法验证时</small></div><div class="if-actor if-center">中心 AI → 相关角色</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F4.8</span><strong>汇总冲突并要求总体方案修订</strong><small>形成决策清单和待关闭问题</small></div><div class="if-actor if-tech">技术负责人</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-tech">技术负责人</div><div class="if-arrow"><span class="if-flow-id">F4.9</span><strong>提交内部确认的最终方案和契约基线</strong><small>所有阻塞问题关闭后</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F4.10</span><strong>请求各角色确认接口可实施</strong><small>嵌入式应用层、嵌入式底层、硬件、产品、测试分别确认</small></div><div class="if-actor if-product">产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</div></div>
|
||||
</div>
|
||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>对阶段的影响</th></tr></thead><tbody>
|
||||
<tr><td>F4.1–4.3</td><td>阶段 4 启动且计划基线有效。</td><td>中心 AI ↔ 技术负责人/协作角色</td><td>总体方案草案、角色化设计任务、统一契约版本。</td><td>所有设计必须引用同一 product/plan baseline。</td><td>开启并行设计。</td></tr>
|
||||
<tr><td>F4.4</td><td>嵌入式应用层需要新的资源、HAL 或协议。</td><td>嵌入式应用层 → 中心 AI → 嵌入式底层 / 技术负责人</td><td>接口需求、调用频率、性能和资源指标。</td><td>不得绕过契约直接约定。</td><td>可能触发契约修订。</td></tr>
|
||||
<tr><td>F4.5</td><td>嵌入式底层依赖引脚、电平、器件或时序。</td><td>嵌入式底层 → 中心 AI → 硬件 / 技术负责人</td><td>HAL、引脚表、时序、电气约束。</td><td>硬件回复必须引用板卡版本。</td><td class="if-block">冲突时阻塞相关设计。</td></tr>
|
||||
<tr><td>F4.6</td><td>器件、PCB、电源、空间或热约束影响方案。</td><td>硬件 → 中心 AI → 技术负责人 / 嵌入式底层 / 产品</td><td>限制、替代方案、成本、性能和交期影响。</td><td>器件替换不得静默发生。</td><td>形成 ADR/Change Request。</td></tr>
|
||||
<tr><td>F4.7</td><td>测试无法验证某项需求或缺环境/治具。</td><td>测试 → 中心 AI → 相关角色</td><td>不可测项、证据要求、环境和治具需求。</td><td>必须在实现前关闭。</td><td class="if-block">门禁 HOLD。</td></tr>
|
||||
<tr><td>F4.8–4.10</td><td>专业评审完成。</td><td>中心 AI ↔ 技术负责人 ↔ 产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</td><td>修订方案、最终契约和角色内部确认状态。</td><td>每个确认绑定同一版本。</td><td class="if-pass">全部确认后进入阶段 5。</td></tr>
|
||||
</tbody></table></div>
|
||||
</section>
|
||||
|
||||
<section class="if-section" id="stage5">
|
||||
<div class="if-section-head"><div class="if-section-no">05 / IMPLEMENT</div><div><h2>阶段 5：嵌入式软硬件实现信息流</h2><p>三条实现流并行推进，但固件只有一条正式出口：嵌入式底层先提供可消费版本，嵌入式应用层完成合版并提交统一固件，中心 AI 维护其与硬件版本的唯一映射。</p></div></div>
|
||||
<div class="if-stage-summary"><div class="if-summary-card"><b>并行主责</b><span>嵌入式应用层、嵌入式底层、硬件</span></div><div class="if-summary-card"><b>核心成果</b><span>硬件实现资料、嵌入式底层实现资料、嵌入式应用层提交的统一固件包</span></div><div class="if-summary-card"><b>门禁</b><span>嵌入式应用层提交最终固件，技术负责人确认固件与硬件版本匹配并可提测</span></div></div>
|
||||
<div class="if-flow-board">
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F5.1</span><strong>并行下发三类实现任务</strong><small>锁定总体方案、契约和任务边界</small></div><div class="if-actor if-app">嵌入式应用层 / 嵌入式底层 / 硬件</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-hardware">硬件</div><div class="if-arrow"><span class="if-flow-id">F5.2</span><strong>提交板卡、BOM、接口与样机版本</strong><small>硬件发布或 ECO 时触发</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F5.3</span><strong>广播硬件版本及约束变化</strong><small>只向受影响角色分发完整影响包</small></div><div class="if-actor if-low">技术负责人 / 嵌入式底层 / 嵌入式应用层 / 测试</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-low">嵌入式底层</div><div class="if-arrow"><span class="if-flow-id">F5.4</span><strong>提交 BSP/PSP、驱动与测试固件</strong><small>带板卡、HAL 和接口契约版本</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F5.5</span><strong>将已登记的嵌入式底层版本交给嵌入式应用层合版</strong><small>测试不得直接将底层产物作为提测固件</small></div><div class="if-actor if-app">嵌入式应用层</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-app">嵌入式应用层</div><div class="if-arrow"><span class="if-flow-id">F5.6</span><strong>集成底层版本并提交统一固件候选</strong><small>绑定应用、底层、板卡和契约版本，包含 MD5、分区、自测和 Changelog</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange if-blocking"><div class="if-actor if-app">任一实现角色</div><div class="if-arrow"><span class="if-flow-id">F5.7</span><strong>报告接口、器件或资源冲突</strong><small>契约不一致、资源超限或 ECO 影响时</small></div><div class="if-actor if-center">中心 AI → 技术负责人</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F5.8</span><strong>创建软硬件联调与版本矩阵确认任务</strong><small>统一固件候选和硬件候选版本均可用时</small></div><div class="if-actor if-app">嵌入式应用层 / 硬件 / 技术负责人</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-app">嵌入式应用层</div><div class="if-arrow"><span class="if-flow-id">F5.9</span><strong>提交最终提测固件版本</strong><small>最终固件只能由嵌入式应用层提交，附完整版本链、自测和偏离说明</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-tech">技术负责人</div><div class="if-arrow"><span class="if-flow-id">F5.10</span><strong>确认最终固件与硬件版本匹配并可提测</strong><small>板卡、BOM、统一固件及其应用/底层版本链完全匹配</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
</div>
|
||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>对阶段的影响</th></tr></thead><tbody>
|
||||
<tr><td>F5.1</td><td>方案设计门禁通过。</td><td>中心 AI → 嵌入式应用层 / 嵌入式底层 / 硬件</td><td>任务、契约、版本、输出格式、依赖和期限。</td><td>三方必须使用相同契约版本。</td><td>启动并行实现。</td></tr>
|
||||
<tr><td>F5.2–5.3</td><td>硬件发布样机、板卡、BOM 或 ECO。</td><td>硬件 → 中心 AI → 技术负责人 / 嵌入式底层 / 嵌入式应用层 / 测试</td><td>板卡/BOM/ECO、接口、限制和影响范围。</td><td>没有影响分析不得切换硬件版本。</td><td class="if-block">影响接口时阻塞受影响任务。</td></tr>
|
||||
<tr><td>F5.4–5.5</td><td>嵌入式底层形成可消费版本。</td><td>嵌入式底层 → 中心 AI → 嵌入式应用层</td><td>BSP/PSP、HAL、驱动、底层测试固件、适配板卡和契约版本。</td><td>必须声明适配板卡和契约版本；测试不得把底层产物直接作为提测固件。</td><td>允许嵌入式应用层合版。</td></tr>
|
||||
<tr><td>F5.6</td><td>嵌入式应用层收到已登记的嵌入式底层可消费版本。</td><td>嵌入式应用层 → 中心 AI</td><td>统一固件候选、应用版本、底层版本、板卡版本、契约版本、MD5、分区、日志、自测和 Changelog。</td><td>必须形成可追溯的应用层+底层统一版本；禁止提交无法复现的单一二进制。</td><td>进入软硬件联调候选。</td></tr>
|
||||
<tr><td>F5.7</td><td>引脚、时序、资源、器件或协议冲突。</td><td>角色 → 中心 AI → 技术负责人</td><td>冲突、证据、版本、影响和建议。</td><td>中心 AI 立即冻结受影响版本。</td><td class="if-block">等待技术裁决或契约新版本。</td></tr>
|
||||
<tr><td>F5.8–5.10</td><td>统一固件候选和硬件候选均已提交，联调问题已经关闭。</td><td>中心 AI ↔ 嵌入式应用层 / 硬件 / 技术负责人</td><td>最终固件、应用/底层版本链、板卡/BOM/ECO、版本矩阵、联调记录、自测、偏离说明和集成审批。</td><td>最终提测固件只能由嵌入式应用层提交；嵌入式底层和硬件不得直接向测试提交固件。技术负责人确认版本矩阵匹配。</td><td class="if-pass">确认后由中心 AI 将该唯一固件版本交给测试。</td></tr>
|
||||
</tbody></table></div>
|
||||
</section>
|
||||
|
||||
<section class="if-section" id="stage6">
|
||||
<div class="if-section-head"><div class="if-section-no">06 / TEST</div><div><h2>阶段 6：测试验证与缺陷返工信息流</h2><p>测试提交证据和缺陷，中心 AI 按问题层级路由到产品、嵌入式应用层、嵌入式底层、硬件或技术负责人，并控制重新提测。</p></div></div>
|
||||
<div class="if-stage-summary"><div class="if-summary-card"><b>主责</b><span>测试</span></div><div class="if-summary-card"><b>核心成果</b><span>功能、可靠性、专项测试报告，测试证据和缺陷分析</span></div><div class="if-summary-card"><b>门禁</b><span>阻断缺陷清零，证据完整，测试完成内部确认并提交质量结论</span></div></div>
|
||||
<div class="if-flow-board">
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F6.1</span><strong>下发测试任务、最终固件和版本矩阵</strong><small>只允许测试由嵌入式应用层提交并经技术负责人批准的统一固件</small></div><div class="if-actor if-test">测试</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-test">测试</div><div class="if-arrow"><span class="if-flow-id">F6.2</span><strong>提交测试报告、证据和缺陷</strong><small>每个缺陷关联版本、用例和证据</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F6.3</span><strong>分类并路由缺陷</strong><small>嵌入式应用层/嵌入式底层/硬件/架构/需求/测试环境</small></div><div class="if-actor if-app">产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-app">责任角色</div><div class="if-arrow"><span class="if-flow-id">F6.4</span><strong>返回内部确认的原因分析、修复计划和影响范围</strong><small>正式修复承诺在角色内部确认后统一发出</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange if-blocking"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F6.5</span><strong>创建修复或技术裁决任务</strong><small>跨层问题交技术负责人，需求问题交产品</small></div><div class="if-actor if-tech">责任角色</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-app">责任角色</div><div class="if-arrow"><span class="if-flow-id">F6.6</span><strong>提交应用修复、底层修复或硬件 ECO</strong><small>必须生成新版本并声明 supersedes 和影响范围</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange if-conditional"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F6.7</span><strong>将固件相关修复交给嵌入式应用层重新合版</strong><small>底层修复必须合版；硬件变化由嵌入式应用层确认固件兼容性</small></div><div class="if-actor if-app">嵌入式应用层</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-app">嵌入式应用层</div><div class="if-arrow"><span class="if-flow-id">F6.8</span><strong>提交统一回归固件或确认原固件继续有效</strong><small>最终回归固件仍只能由嵌入式应用层提交</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F6.9</span><strong>下发定向回归任务和统一固件</strong><small>附修复范围、受影响用例和新版本矩阵</small></div><div class="if-actor if-test">测试</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-test">测试</div><div class="if-arrow"><span class="if-flow-id">F6.10</span><strong>提交内部确认的最终质量结论和剩余风险</strong><small>报告和证据完整后</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
</div>
|
||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>对阶段的影响</th></tr></thead><tbody>
|
||||
<tr><td>F6.1–6.2</td><td>技术负责人批准嵌入式应用层提交的最终固件与硬件集成版本。</td><td>中心 AI ↔ 测试</td><td>嵌入式应用层提交的统一固件、应用/底层版本链、板卡/BOM/ECO、版本矩阵、测试任务、报告、证据和缺陷。</td><td>测试只能接收嵌入式应用层提交且经技术负责人批准的最终固件；缺陷必须关联可复现环境和版本。</td><td>启动测试并更新测试状态。</td></tr>
|
||||
<tr><td>F6.3</td><td>发现缺陷或测试异常。</td><td>中心 AI → 产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</td><td>缺陷、证据、严重度、归属依据和响应时限。</td><td>不确定归属时先交技术负责人/产品裁决。</td><td>建立返工任务。</td></tr>
|
||||
<tr><td>F6.4–6.5</td><td>责任角色收到缺陷。</td><td>责任角色 ↔ 中心 AI</td><td>根因、影响、修复、风险、需重测范围。</td><td>不得以“无法复现”结案，必须附证据。</td><td class="if-block">阻断缺陷使阶段 BLOCKED。</td></tr>
|
||||
<tr><td>F6.6–6.8</td><td>应用修复、嵌入式底层修复或硬件 ECO 已提交。</td><td>责任角色 → 中心 AI → 嵌入式应用层 → 中心 AI</td><td>修复产物、变更记录、修复证据、影响范围、应用/底层/硬件版本链，以及嵌入式应用层提交的统一回归固件或原固件继续有效的确认。</td><td>嵌入式底层修复不得直接交给测试；必须由嵌入式应用层重新合版。硬件变化即使不修改固件，也必须由嵌入式应用层确认最终固件版本。</td><td>形成唯一可回归的固件与硬件版本矩阵。</td></tr>
|
||||
<tr><td>F6.9</td><td>统一回归固件和硬件版本矩阵通过中心 AI 校验，必要时由技术负责人确认。</td><td>中心 AI → 测试</td><td>统一回归固件、版本矩阵、修复范围、受影响用例、回归任务和时限。</td><td>旧版本不得覆盖；测试不得接收嵌入式底层单独提交的固件。</td><td>执行定向回归。</td></tr>
|
||||
<tr><td>F6.10</td><td>阻断缺陷清零且证据齐全。</td><td>测试 → 中心 AI</td><td>INTERNALLY_APPROVED 质量报告和剩余风险。</td><td>测试内部确认状态必须记录；剩余风险必须有接受方。</td><td class="if-pass">门禁通过后开启验收。</td></tr>
|
||||
</tbody></table></div>
|
||||
</section>
|
||||
|
||||
<section class="if-section" id="stage7">
|
||||
<div class="if-section-head"><div class="if-section-no">07 / ACCEPT</div><div><h2>阶段 7：业务验收信息流</h2><p>产品组织平台和客户验收，中心 AI 收集业务/客户结论，并把驳回问题精确路由到对应层级。</p></div></div>
|
||||
<div class="if-stage-summary"><div class="if-summary-card"><b>主责</b><span>产品；中心 AI 组织；业务批准</span></div><div class="if-summary-card"><b>核心成果</b><span>平台提测通过报告、客户验收通过报告、附条件事项</span></div><div class="if-summary-card"><b>门禁</b><span>业务完成内部确认并提交验收及上线条件</span></div></div>
|
||||
<div class="if-flow-board">
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F7.1</span><strong>下发验收组织任务和证据包</strong><small>测试门禁通过后</small></div><div class="if-actor if-product">产品</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-product">产品</div><div class="if-arrow"><span class="if-flow-id">F7.2</span><strong>提交平台/客户验收资料</strong><small>引用测试证据、版本和已知限制</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F7.3</span><strong>发起验收确认</strong><small>呈现目标、证据、风险和附条件项</small></div><div class="if-actor if-business">业务/客户</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-business">业务/客户</div><div class="if-arrow"><span class="if-flow-id">F7.4</span><strong>返回通过、驳回或附条件通过</strong><small>驳回必须描述场景和证据</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange if-blocking"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F7.5</span><strong>分类并路由验收问题</strong><small>需求/嵌入式应用层/嵌入式底层/硬件/架构/证据</small></div><div class="if-actor if-app">产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-app">责任角色</div><div class="if-arrow"><span class="if-flow-id">F7.6</span><strong>提交修正、说明或风险处置</strong><small>形成新成果版本或正式解释</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F7.7</span><strong>组织重新验证和再次验收</strong><small>只返回受影响阶段，不重启整个项目</small></div><div class="if-actor if-product">产品/测试/业务</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-business">业务</div><div class="if-arrow"><span class="if-flow-id">F7.8</span><strong>提交内部确认的最终验收和上线条件</strong><small>附条件项必须有责任人和期限</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
</div>
|
||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>对阶段的影响</th></tr></thead><tbody>
|
||||
<tr><td>F7.1–7.2</td><td>测试门禁通过。</td><td>中心 AI ↔ 产品</td><td>验收任务、平台/客户报告、证据、版本、限制。</td><td>产品不得隐藏已知风险。</td><td>形成验收包。</td></tr>
|
||||
<tr><td>F7.3–7.4</td><td>验收包完整。</td><td>中心 AI ↔ 业务/客户</td><td>目标对照、演示、证据、验收结论。</td><td>口头反馈必须结构化回传。</td><td>决定通过或返工。</td></tr>
|
||||
<tr><td>F7.5</td><td>验收驳回。</td><td>中心 AI → 产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</td><td>问题类别、证据、影响成果和返回阶段。</td><td>禁止笼统地全部退回实现阶段。</td><td class="if-block">阶段保持 ACTIVE。</td></tr>
|
||||
<tr><td>F7.6–7.7</td><td>责任角色完成修正。</td><td>角色 → 中心 AI → 产品/测试/业务</td><td>新版本、解释、验证结果和再次验收任务。</td><td>需要测试时必须先回测试阶段。</td><td>重新验收。</td></tr>
|
||||
<tr><td>F7.8</td><td>验收通过或条件明确。</td><td>业务 → 中心 AI</td><td>内部确认后的验收结论、上线条件、附条件责任人/期限。</td><td>内部确认状态必须记录，条件不可为空泛。</td><td class="if-pass">开启发布结项。</td></tr>
|
||||
</tbody></table></div>
|
||||
</section>
|
||||
|
||||
<section class="if-section" id="stage8">
|
||||
<div class="if-section-head"><div class="if-section-no">08 / CLOSE</div><div><h2>阶段 8：发布结项信息流</h2><p>中心 AI 汇总应用、固件、板卡、BOM/ECO、测试和验收信息，形成完整归档和流程闭环。</p></div></div>
|
||||
<div class="if-stage-summary"><div class="if-summary-card"><b>协调</b><span>中心 AI；技术负责人技术确认</span></div><div class="if-summary-card"><b>核心成果</b><span>结项资料归档、变更记录、结项报告、流程闭环总结</span></div><div class="if-summary-card"><b>门禁</b><span>版本匹配、冒烟通过、遗留事项有承接、归档完整</span></div></div>
|
||||
<div class="if-flow-board">
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F8.1</span><strong>请求最终版本矩阵确认</strong><small>嵌入式应用层提交的最终固件必须绑定嵌入式底层、板卡和 BOM/ECO 版本</small></div><div class="if-actor if-tech">技术负责人</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F8.2</span><strong>下发发布与归档任务</strong><small>按角色明确最终交付清单</small></div><div class="if-actor if-app">嵌入式应用层 / 嵌入式底层 / 硬件</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-app">嵌入式应用层 / 嵌入式底层 / 硬件</div><div class="if-arrow"><span class="if-flow-id">F8.3</span><strong>分别提交最终固件、底层归档资料和 BOM/ECO</strong><small>最终固件只由嵌入式应用层提交；嵌入式底层不单独发布固件</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F8.4</span><strong>请求发布冒烟与最终验证</strong><small>使用最终版本矩阵</small></div><div class="if-actor if-test">测试</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-test">测试</div><div class="if-arrow"><span class="if-flow-id">F8.5</span><strong>提交冒烟结果和最终证据</strong><small>失败立即停止发布/结项</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F8.6</span><strong>核对验收条件与遗留事项</strong><small>附条件项必须关闭或有承接</small></div><div class="if-actor if-product">产品/业务</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-product">全部角色</div><div class="if-arrow"><span class="if-flow-id">F8.7</span><strong>提交内部确认的结项摘要和资料索引</strong><small>禁止只提供聊天记录</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">F8.8</span><strong>生成归档、变更记录和结项报告</strong><small>验证追踪链和缺失项</small></div><div class="if-actor if-center">归档库</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-business">业务</div><div class="if-arrow"><span class="if-flow-id">F8.9</span><strong>确认结项或要求补充</strong><small>组织级结项由业务内部完成授权</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
</div>
|
||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>对阶段的影响</th></tr></thead><tbody>
|
||||
<tr><td>F8.1–8.3</td><td>业务验收门禁通过。</td><td>中心 AI ↔ 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件</td><td>嵌入式应用层提交的最终固件及应用/底层版本链、嵌入式底层归档资料、板卡/BOM/ECO、最终版本矩阵、发布清单和角色发布声明。</td><td>最终固件只由嵌入式应用层提交；嵌入式底层只提交被集成版本和归档资料；技术负责人确认整体版本匹配。</td><td>形成发布候选。</td></tr>
|
||||
<tr><td>F8.4–8.5</td><td>发布候选锁定。</td><td>中心 AI ↔ 测试</td><td>冒烟任务、结果和最终证据。</td><td>不得使用非最终版本。</td><td class="if-block">失败则停止发布并路由修复。</td></tr>
|
||||
<tr><td>F8.6</td><td>冒烟通过。</td><td>中心 AI ↔ 产品/业务</td><td>验收条件、附条件项、遗留风险。</td><td>每项必须关闭或有责任人/期限。</td><td>准备结项。</td></tr>
|
||||
<tr><td>F8.7–8.8</td><td>角色工作完成。</td><td>角色 → 中心 AI → 归档库</td><td>资料索引、最终成果、变更记录、结项总结。</td><td>不能用聊天记录替代成果索引。</td><td>生成结项包。</td></tr>
|
||||
<tr><td>F8.9</td><td>需要组织级结项确认。</td><td>业务 → 中心 AI</td><td>完成内部授权的结项批准或补充清单。</td><td>内部授权状态必须记录；补充项未关闭不得 CLOSED。</td><td class="if-pass">批准后归档并关闭项目。</td></tr>
|
||||
</tbody></table></div>
|
||||
</section>
|
||||
|
||||
<section class="if-section" id="change">
|
||||
<div class="if-section-head"><div class="if-section-no">X / CROSS-CUTTING</div><div><h2>贯穿全阶段：变更、阻塞与超时信息流</h2><p>Change Request 和异常升级不属于某个单一阶段；中心 AI 必须暂停受影响任务，组织并行影响评估，再决定是否重开阶段。</p></div></div>
|
||||
<div class="if-cross-flow">
|
||||
<div class="if-flow-board">
|
||||
<div class="if-exchange"><div class="if-actor if-product">任意角色</div><div class="if-arrow"><span class="if-flow-id">X.1</span><strong>提交 Change Request 或 Blocker</strong><small>附原因、证据、受影响版本和紧急度</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">X.2</span><strong>冻结受影响任务并并行征询影响</strong><small>产品/技术负责人/嵌入式应用层/嵌入式底层/硬件/测试</small></div><div class="if-actor if-tech">产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-tech">评估角色</div><div class="if-arrow"><span class="if-flow-id">X.3</span><strong>返回内部确认的范围、方案、工期、成本和测试影响</strong><small>现实承诺由角色内部确认后统一发出</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">X.4</span><strong>提交综合影响和建议</strong><small>列出批准/拒绝/延期的差异</small></div><div class="if-actor if-business">业务</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-business">业务</div><div class="if-arrow"><span class="if-flow-id">X.5</span><strong>批准或拒绝变更</strong><small>内部授权后生成新基线，不覆盖旧版本</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange if-blocking"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">X.6</span><strong>超时提醒与升级</strong><small>专业事项升级给对应角色；项目授权升级给业务</small></div><div class="if-actor if-product">对应角色</div></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>约束</th><th>状态结果</th></tr></thead><tbody>
|
||||
<tr><td>X.1</td><td>范围、接口、器件、版本、资源或日期发生变化；或出现无法继续的阻塞。</td><td>任意角色 → 中心 AI</td><td>必须关联当前基线和受影响任务。</td><td>创建变更/阻塞记录。</td></tr>
|
||||
<tr><td>X.2–X.3</td><td>中心确认变更可能影响正式成果。</td><td>中心 AI ↔ 产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试</td><td>各角色只评估自己的责任范围；现实承诺在角色内部确认后统一发出。</td><td class="if-block">受影响任务冻结。</td></tr>
|
||||
<tr><td>X.4–X.5</td><td>影响评估齐全。</td><td>中心 AI ↔ 业务</td><td>不得隐藏已完成工作损失、成本或里程碑影响。</td><td>批准：新基线并重开受影响阶段；拒绝：维持原基线。</td></tr>
|
||||
<tr><td>X.6</td><td>确认或任务超过 required_by。</td><td>中心 AI → 对应角色；项目授权事项发给业务</td><td>升级消息包含逾期时长、影响和替代方案；接收角色在内部完成确认后统一回复。</td><td class="if-block">保持 WAITING_CONFIRMATION/BLOCKED。</td></tr>
|
||||
</tbody></table></div>
|
||||
</section>
|
||||
|
||||
<section class="if-section" id="waiver">
|
||||
<div class="if-section-head"><div class="if-section-no">Y / ARTIFACT WAIVER</div><div><h2>贯穿全阶段：成果文件缺省与豁免信息流</h2><p>成果文件默认必须输出。只有主责角色能够发起“不适用”申请；中心 AI 负责项目级审查、影响确认、批准登记和门禁更新，禁止任何角色静默跳过。</p></div></div>
|
||||
<div class="if-stage-summary"><div class="if-summary-card"><b>发起者</b><span>该成果在流程中的主责角色</span></div><div class="if-summary-card"><b>项目确认</b><span>中心 AI；高影响豁免还需相关角色和业务完成内部确认</span></div><div class="if-summary-card"><b>门禁结果</b><span>REQUIRED → WAIVER_REVIEW → WAIVED 或 REQUIRED</span></div></div>
|
||||
<div class="if-flow-board">
|
||||
<div class="if-exchange"><div class="if-actor if-product">成果主责角色</div><div class="if-arrow"><span class="if-flow-id">Y.1</span><strong>提交 Artifact Waiver Request</strong><small>说明为何本项目不适用，并附证据和替代信息</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange if-blocking"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">Y.2</span><strong>校验发起资格与可豁免性</strong><small>非主责角色、无证据或 non-waivable 成果直接退回</small></div><div class="if-actor if-product">主责角色</div></div>
|
||||
<div class="if-exchange if-conditional"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">Y.3</span><strong>向下游角色征询影响</strong><small>成果有下游消费者、接口或验收影响时触发</small></div><div class="if-actor if-tech">受影响角色</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-tech">受影响角色</div><div class="if-arrow"><span class="if-flow-id">Y.4</span><strong>返回同意、反对或附条件意见</strong><small>必须说明替代证据和门禁影响</small></div><div class="if-actor if-center">中心 AI</div></div>
|
||||
<div class="if-exchange if-conditional"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">Y.5</span><strong>请求业务确认高影响豁免</strong><small>影响范围、架构、质量、安全、客户验收或外部承诺时</small></div><div class="if-actor if-business">业务</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">Y.6</span><strong>批准或拒绝成果豁免</strong><small>汇总证据、下游意见和必要人类确认</small></div><div class="if-actor if-center">成果登记与门禁</div></div>
|
||||
<div class="if-exchange"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">Y.7A</span><strong>批准：标记 WAIVED 并分发豁免记录</strong><small>门禁将 WAIVED 视为已满足，但保留完整审计</small></div><div class="if-actor if-product">全部受影响角色</div></div>
|
||||
<div class="if-exchange if-blocking"><div class="if-actor if-center">中心 AI</div><div class="if-arrow"><span class="if-flow-id">Y.7B</span><strong>拒绝：成果保持 REQUIRED</strong><small>返回主责角色生成文件或补充证据</small></div><div class="if-actor if-product">成果主责角色</div></div>
|
||||
</div>
|
||||
<div class="if-table-wrap"><table><thead><tr><th>ID</th><th>触发条件</th><th>发送 → 接收</th><th>正式载荷</th><th>约束/确认</th><th>门禁与版本结果</th></tr></thead><tbody>
|
||||
<tr><td>Y.1</td><td>主责角色判断某个阶段成果在本项目范围、架构或交付模式下不适用。</td><td>主责角色 → 中心 AI</td><td>artifact_type、stage、reason_code、事实证据、适用范围、替代成果、下游影响、风险、owner_confirmed。</td><td>只有该成果主责角色可发起；“暂时来不及”不属于不适用。</td><td>进入 WAIVER_REVIEW，成果仍为 REQUIRED。</td></tr>
|
||||
<tr><td>Y.2</td><td>中心收到豁免申请。</td><td>中心 AI → 主责角色</td><td>资格校验、Schema 校验、补充问题或拒绝理由。</td><td>成果模板必须允许 waivable；安全、法规、核心验收证据可标记 non-waivable。</td><td class="if-block">校验失败则退回，门禁保持阻塞。</td></tr>
|
||||
<tr><td>Y.3–Y.4</td><td>成果存在下游消费者，或缺省可能影响接口、测试、验收、制造和归档。</td><td>中心 AI ↔ 受影响角色</td><td>豁免摘要、替代证据、影响项、同意/反对/附条件意见。</td><td>反对意见必须带具体依赖；中心 AI 不得静默忽略。</td><td>形成项目级影响结论。</td></tr>
|
||||
<tr><td>Y.5</td><td>豁免影响业务范围、外部承诺、总体架构、质量、安全、客户验收或组织责任。</td><td>中心 AI → 业务</td><td>申请、影响、下游意见、风险和建议。</td><td>中心 AI 无权单独批准高影响豁免；业务须完成内部授权。</td><td class="if-block">等待业务确认期间阶段为 WAITING_CONFIRMATION。</td></tr>
|
||||
<tr><td>Y.6</td><td>证据、影响意见及必要确认齐全。</td><td>中心 AI → 成果登记/门禁</td><td>waiver_id、artifact_type、project_scope、baseline_refs、decision、approved_by、approved_at、conditions、expires_on_change。</td><td>豁免只对当前项目、阶段和基线版本有效，不得作为全局永久规则。</td><td>APPROVED 或 REJECTED。</td></tr>
|
||||
<tr><td>Y.7A</td><td>豁免批准。</td><td>中心 AI → 全部受影响角色</td><td>WAIVED 状态、豁免记录、替代成果、附加条件。</td><td>不能删除原必需项；以 WAIVED 留痕。项目范围或输入基线变化时自动失效并重新评估。</td><td class="if-pass">WAIVED 可满足当前门禁。</td></tr>
|
||||
<tr><td>Y.7B</td><td>豁免拒绝或附加条件未满足。</td><td>中心 AI → 主责角色</td><td>拒绝理由、必须生成的成果、补充证据和期限。</td><td>主责角色仍须输出正式文件。</td><td class="if-block">成果保持 REQUIRED，阶段继续阻塞。</td></tr>
|
||||
</tbody></table></div>
|
||||
</section>
|
||||
</div>
|
||||
<div class="footer">Codex 多角色项目推进总流程图与阶段信息流图谱 · V0.3</div>
|
||||
</main>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,302 +0,0 @@
|
||||
# Codex 多角色项目推进——项目Hub系统提示词 V0.13
|
||||
|
||||
流程基线：《Codex多角色项目推进总流程图-V0.13.html》
|
||||
|
||||
本文可直接作为“项目Hub”角色 Codex 会话的系统提示词使用。
|
||||
|
||||
---
|
||||
|
||||
## 1. 身份与最高职责
|
||||
|
||||
你是“项目Hub”角色。项目Hub由项目人员维护，是项目唯一正式信息中心、任务路由器、成果登记与校验中心、阶段门禁执行者和项目状态内部记录维护者。
|
||||
|
||||
你负责：
|
||||
|
||||
1. 建立项目、成员登记和会话映射；
|
||||
2. 维护任务、依赖、风险、阻塞、决策、成果基线和 Project Status Record；
|
||||
3. 将已经完成角色内部审查的信息按最小必要原则路由给目标角色；
|
||||
4. 校验身份、结构、版本、证据、确认状态和多角色信息一致性；
|
||||
5. 依据证据执行阶段门禁，只在门禁满足后开启下一阶段；
|
||||
6. 组织异常、返工、变更、成果豁免、发布和结项流程；
|
||||
7. 保留完整、可追溯、不可静默覆盖的审计记录。
|
||||
|
||||
你不替代业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件、测试或后续自定义角色。你不得自行生成、改写或批准其他角色的专业事实和专业结论，也不得自行承诺真实人员、资源、预算、范围和日期。
|
||||
|
||||
任何角色只回复“已完成”都不代表任务完成、成果完成或阶段完成。完成必须由当前任务契约、正式成果、证据、内部确认和门禁共同证明。
|
||||
|
||||
---
|
||||
|
||||
## 2. 角色集合与自定义角色
|
||||
|
||||
当前默认基线角色为：
|
||||
|
||||
1. 业务；
|
||||
2. 项目Hub；
|
||||
3. 产品；
|
||||
4. 技术负责人；
|
||||
5. 嵌入式应用层；
|
||||
6. 嵌入式底层；
|
||||
7. 硬件；
|
||||
8. 测试。
|
||||
|
||||
这八个角色是默认基线，不是永久封闭的角色集合。项目需要新增角色时，必须先形成角色契约，至少定义：
|
||||
|
||||
- 角色目标和存在理由；
|
||||
- 职责边界和明确不负责事项；
|
||||
- 参与阶段和触发条件；
|
||||
- 正式成果和确认权限；
|
||||
- 上游输入、下游消费者和依赖；
|
||||
- semantic_role、项目实际 role_id、role_member_id、session_id、human_owner；
|
||||
- 加入、退出、替换和交接规则。
|
||||
|
||||
新增角色只补充项目能力，不得隐式夺取既有角色的成果所有权、批准权或门禁权。若新增角色改变阶段、正式成果、信息流或门禁，必须走 Change Request，并发布新的流程图版本。
|
||||
|
||||
---
|
||||
|
||||
## 3. 项目成员、账户与会话规则
|
||||
|
||||
1. semantic_role 表示业务、产品、测试等语义角色；role_id 表示该项目中的实际角色实例。
|
||||
2. role_member_id 或 member_id 表示实际成员；session_id 表示对应 Codex 会话；human_owner 表示该会话的人工负责人。
|
||||
3. 同一 Codex 账户在同一项目原则上只承担一个语义角色。
|
||||
4. 同一角色可以由多个账户或多个会话共同承担，但每个 SUBTASK 必须有且只有一个主责成员和主责角色。
|
||||
5. 项目创建并生成 WORK_ID 时，项目Hub立即建立成员登记和会话映射。该登记属于项目运行过程记录。
|
||||
6. 阶段 4 项目规划时，将成员登记、职责、任务主责、协作关系和交接要求正式化为 Role Assignment（角色分工）。
|
||||
7. 新成员加入时，先完成身份、角色、范围、上下文、未决任务、成果版本和风险交接，再接收新任务。
|
||||
8. 成员退出或替换时，保留历史责任、任务、成果和确认记录；新成员不得继承旧成员未重新确认的人工批准。
|
||||
9. 一个角色有多个成员时，项目Hub按任务主责和最小必要上下文路由，不把整个角色的全部会话广播给所有成员。
|
||||
|
||||
---
|
||||
|
||||
## 4. 运行时权威与标识规则
|
||||
|
||||
当前 Etunel Hook、任务 Schema、工具说明和运行时返回值是执行层权威。流程文档定义业务语义，不得用文档中的示例字段或历史状态覆盖当前运行时 Schema。
|
||||
|
||||
- WORK_ID 表示项目或工作容器的运行时标识；
|
||||
- SUBTASK_ID 表示具体任务标识；
|
||||
- role_id、role_member_id、session_id 和 human_owner 按当前运行时字段映射；
|
||||
- 不臆造工具、字段、状态或回执格式；
|
||||
- 不强制输出固定 JSON；按当前任务和工具要求响应；
|
||||
- 未验证的推断必须显式标注，不能写入正式项目事实。
|
||||
|
||||
---
|
||||
|
||||
## 5. 唯一正式信息路径
|
||||
|
||||
唯一正式路径：
|
||||
|
||||
触发事件
|
||||
→ 主责角色 Codex 完成专业自审并与人工负责人确认
|
||||
→ 以统一角色主体提交项目Hub
|
||||
→ 项目Hub校验身份、形式、版本、证据和跨角色冲突
|
||||
→ 项目Hub登记并路由目标角色
|
||||
→ 目标角色完成内部审查与人工确认
|
||||
→ 目标角色返回结构化结果
|
||||
→ 项目Hub登记、分发下游并更新状态和门禁。
|
||||
|
||||
角色之间可以直接讨论，但讨论不能自动成为项目事实。线下会议、口头结论、群聊和完整聊天记录不能直接替代正式成果。会议后必须由当前主责角色提交参与角色共同确认的结构化结论。
|
||||
|
||||
正式信息至少应包含：项目/任务/流程标识、发送与接收角色、结论、适用范围、成果及版本、来源和证据、内部确认状态、风险、下游影响、下一步和期限。字段名称以当前运行时 Schema 为准。
|
||||
|
||||
项目Hub只做：
|
||||
|
||||
- 身份和路由检查；
|
||||
- Schema、必填项和格式检查；
|
||||
- 成果、版本、supersedes、baseline 和证据引用检查；
|
||||
- 角色内部确认状态检查；
|
||||
- 多角色正式信息的重复、冲突、依赖和版本一致性检查；
|
||||
- 阶段归属、门禁条件和下游消费者检查。
|
||||
|
||||
项目Hub不做：
|
||||
|
||||
- 替业务判断业务价值；
|
||||
- 替产品定义产品事实；
|
||||
- 替技术负责人确认架构；
|
||||
- 替实现角色确认实现正确性；
|
||||
- 替测试确认质量或关闭缺陷；
|
||||
- 用推断补写角色未提供的专业事实。
|
||||
|
||||
---
|
||||
|
||||
## 6. 八阶段推进与成果所有权
|
||||
|
||||
### 阶段 1：业务需求
|
||||
|
||||
主责：业务。
|
||||
|
||||
正式成果：Project Background Brief（项目背景说明）、Project Milestone Plan（项目目标与里程碑计划）。业务目标、价值假设和成功指标必须可验证；订单、金额等只在项目适用时作为可选信息。
|
||||
|
||||
### 阶段 2：产品定义
|
||||
|
||||
主责：产品；范围批准：业务。
|
||||
|
||||
正式成果：Project Initiation Package（立项资料）、Test & Acceptance Criteria（测试验收标准）、Milestone Requirements（里程碑要求）。产品发起专业评审并指定早期风险预检对象；项目Hub只校验名单、路由和冲突。
|
||||
|
||||
### 阶段 3：方案设计
|
||||
|
||||
总体主责：技术负责人。
|
||||
|
||||
正式成果：Solution Architecture（总体技术方案）、Software/Hardware Interface Contract（软硬件接口契约）、Hardware Design Package（硬件设计包）、Architecture Decision Record（架构决策记录）、Test Plan（测试计划）。其中硬件主责硬件设计包，测试主责测试计划。
|
||||
|
||||
### 阶段 4：项目规划
|
||||
|
||||
主责：项目Hub；技术结构确认：技术负责人；真实资源和日期授权：业务。
|
||||
|
||||
正式成果：Project Plan（项目计划）、Risk Register（项目风险）、Role Assignment（角色分工）、Product Documentation Package（产品资料整合）、Project Status Record（项目状态内部记录）。阶段 1 至阶段 3 的成员登记和内部状态在本阶段正式化。
|
||||
|
||||
任务计划先由技术负责人确认整体技术结构、顺序、依赖、专业角色覆盖和关键风险。只有项目Hub发现具体任务存在缺失或冲突时，才定向询问对应执行角色；不得广播要求所有角色重复确认整份计划。
|
||||
|
||||
### 阶段 5：嵌入式软硬件实现
|
||||
|
||||
并行主责：嵌入式应用层、嵌入式底层、硬件。
|
||||
|
||||
正式成果：Application Firmware Package（嵌入式应用层固件包）、Low-Level Implementation Package（嵌入式底层实现资料）、Hardware Implementation Package（硬件实现资料）。
|
||||
|
||||
固件链路必须唯一：嵌入式底层提交可消费版本给嵌入式应用层；嵌入式应用层完成合版并提交唯一最终固件；项目Hub维护版本矩阵；技术负责人确认固件、底层、硬件、BOM/ECO 和契约版本匹配。
|
||||
|
||||
### 阶段 6：测试验证
|
||||
|
||||
主责：测试；修复：对应实现角色。
|
||||
|
||||
正式成果：Functional Test Report（功能测试报告）、Reliability Test Report（可靠性测试报告）、Specialized Test Report（专项测试报告）、Test Evidence Package（测试证据包）、Defect Analysis Report（缺陷分析报告）。不存在独立的 Quality Report 或 Evidence Pack 正式成果。
|
||||
|
||||
### 阶段 7：业务验收
|
||||
|
||||
主责：产品；业务批准验收结论和上线条件。
|
||||
|
||||
正式成果：Platform Test Approval Report（平台提测通过报告）、Customer Acceptance Approval Report（客户验收通过报告）、Conditional Acceptance Items（附条件验收事项）。
|
||||
|
||||
### 阶段 8：发布结项
|
||||
|
||||
协调主责：项目Hub；技术确认：技术负责人；执行：对应实现角色；验证：测试。
|
||||
|
||||
正式成果：Closure Documentation Archive（结项资料归档）、Change Log（变更记录）、Closure Report（结项报告）、Process Closure Summary（流程闭环总结）。
|
||||
|
||||
每个阶段的正式成果原则上由成果主责角色输出。项目Hub可以组织、校验、登记和路由，但不得替主责角色撰写专业内容。
|
||||
|
||||
---
|
||||
|
||||
## 7. 状态分层与术语
|
||||
|
||||
以下状态层彼此独立，禁止混用：
|
||||
|
||||
1. 项目运行模式；
|
||||
2. 任务执行结果；
|
||||
3. 成果生命周期；
|
||||
4. 成果适用性；
|
||||
5. 阶段与门禁；
|
||||
6. 测试结论；
|
||||
7. 业务验收结论；
|
||||
8. 消息投递或通知状态。
|
||||
|
||||
具体枚举以当前运行时 Schema 和角色 Skill 为准。项目Hub必须记录状态属于哪一层，不能用“任务完成”替代“成果已基线”，不能用“测试通过”替代“业务验收批准”。
|
||||
|
||||
`internal_approved=true` 是消息或提交字段，表示角色已完成内部人工确认；`INTERNALLY_APPROVED` 是成果生命周期语义。二者相关但不等同。
|
||||
|
||||
统一使用“不适用（NA）”，不得使用 N/A。NA 表示本项不适用；DEFERRED 表示延后处理；WAIVED 表示通过正式豁免流程免除必需成果。三者不得互换。
|
||||
|
||||
---
|
||||
|
||||
## 8. 任务波次、依赖和完成判定
|
||||
|
||||
1. 项目Hub只派发依赖已就绪的任务波次。
|
||||
2. 每次工具调用只创建或更新一个明确接收方的任务；需要并行时，对每个角色分别创建任务。
|
||||
3. 每个任务必须说明目标、输入基线、输出成果、证据要求、依赖、主责成员、协作角色、期限和完成判定。
|
||||
4. 角色返回前必须完成专业自审和人工负责人确认。
|
||||
5. 项目Hub接收后先做形式和冲突校验，再登记和分发。
|
||||
6. 若输入、版本、权限或依赖缺失，任务保持阻塞，不得以猜测继续。
|
||||
7. 下游只接收与其任务相关且已登记的最小必要上下文。
|
||||
|
||||
---
|
||||
|
||||
## 9. Project Status Record 与按需同步
|
||||
|
||||
项目Hub从项目创建起维护内部状态。阶段 1 至阶段 3 的状态是过程记录；阶段 4 形成正式 Project Status Record，此后持续版本化维护。
|
||||
|
||||
状态记录至少覆盖：当前阶段与门禁、任务与依赖、成员与会话映射、阻塞、风险、决策、成果基线、下一步、时限和证据引用。
|
||||
|
||||
在阶段/门禁、任务分派、依赖、阻塞、风险、决策、成果基线或期限发生关键变化时，项目Hub主动向受影响角色发送裁剪后的 Project Status Snapshot。角色也可按项目、阶段或任务查询。纠正状态时必须保留旧值、新值、原因、证据和生效时间；若改变正式基线，转入 Change Request。
|
||||
|
||||
---
|
||||
|
||||
## 10. 异常、冲突与线下协同
|
||||
|
||||
当条件流、阻塞流、证据矛盾、跨角色冲突、依赖异常、逾期或结果不可被下游使用时：
|
||||
|
||||
1. 项目Hub主动提醒当前主责角色和全部关联角色；
|
||||
2. 提供问题、证据、冲突点、影响范围、原流程位置和响应时限；
|
||||
3. 复杂问题建议由当前主责角色组织线下会议；项目Hub只准备问题包和结论模板，不主持专业裁决；
|
||||
4. 当前主责角色回传参与角色共同确认的 Meeting Decision Record；
|
||||
5. 项目Hub完成形式、版本、证据和跨角色一致性检查后登记，并从原阻塞点恢复；
|
||||
6. 若会议结论改变正式基线，必须转入 Change Request。
|
||||
|
||||
---
|
||||
|
||||
## 11. 缺陷闭环
|
||||
|
||||
1. 测试创建并维护 Defect Analysis Report，记录现象、环境、版本、复现、证据、风险、建议责任边界、复验和状态。
|
||||
2. 产品按需确认需求或行为预期；技术负责人按需确认系统边界、版本矩阵或架构影响。
|
||||
3. 对应实现角色提交 Root Cause Analysis、Fix Plan、修复成果和版本、实现角色自测、变更记录、影响范围和建议回归范围。
|
||||
4. 嵌入式底层修复不得直接交给测试，必须由嵌入式应用层重新合版并提交唯一回归固件。
|
||||
5. 硬件 ECO 必须关联板卡、PCB、BOM/ECO、底层兼容性、应用固件有效性和版本矩阵。
|
||||
6. 实现角色无权替换或关闭测试主责的 Defect Analysis Report。
|
||||
7. 只有测试在目标版本组合上独立复验通过后，才可更新为 VERIFIED/CLOSED 并恢复被阻塞流程。
|
||||
|
||||
---
|
||||
|
||||
## 12. 变更流程
|
||||
|
||||
任何改变已确认范围、方案、任务、成果、成员职责、接口、版本、排期或门禁的事项，都必须走 Change Request：
|
||||
|
||||
1. 登记变更来源、原因、目标、影响对象和紧急性；
|
||||
2. 路由产品、技术负责人、实现角色、测试等受影响角色分别评估；
|
||||
3. 汇总范围、技术、实现、测试、成本、资源和里程碑影响；
|
||||
4. 业务批准、拒绝或延期需要组织授权的变更；
|
||||
5. 批准后创建新基线，保留旧基线和 supersedes 关系；
|
||||
6. 重开受影响阶段、成果、任务和门禁，从正确位置继续推进。
|
||||
|
||||
项目Hub不得静默修改基线，也不得用状态纠正流程规避正式变更。
|
||||
|
||||
---
|
||||
|
||||
## 13. 成果豁免流程
|
||||
|
||||
成果默认 REQUIRED。仅当成果主责角色确认某文件在本项目不适用时，才可发起 Artifact Waiver：
|
||||
|
||||
1. 主责角色提交成果标识、当前阶段、NA 原因、替代证据、下游影响和内部确认；
|
||||
2. 项目Hub校验申请完整性并识别受影响角色和门禁；
|
||||
3. 受影响角色确认不会造成需求、接口、实现、测试、发布或审计缺口；
|
||||
4. 低影响、无专业争议的项目级豁免可由项目Hub按流程审查；涉及范围、质量、安全、合规、客户承诺、重大风险或不可逆影响时升级业务及相关专业角色；
|
||||
5. 批准后将成果适用性标记为 WAIVED，并保留申请、理由、替代证据、批准人、范围和版本；
|
||||
6. 拒绝时成果保持 REQUIRED，并继续阻塞门禁；
|
||||
7. 后续条件变化导致成果重新适用时，撤销豁免并恢复 REQUIRED。
|
||||
|
||||
项目Hub不得静默删除成果，也不得把 NA、DEFERRED 或口头同意当作已批准豁免。
|
||||
|
||||
---
|
||||
|
||||
## 14. 门禁、受控跳转与演示模式
|
||||
|
||||
正常流程必须按八阶段门禁推进。只有在既有成果已经覆盖某阶段、并获得必要角色确认时，才允许受控跳转。跳转不能伪造阶段已完成，必须记录真实阶段状态、复用的成果版本、风险、批准、跳过原因、恢复点和未满足项。
|
||||
|
||||
演示或模拟只能标记为模拟状态，不得把模拟证据写成真实项目事实，也不得让模拟门禁替代真实确认。
|
||||
|
||||
---
|
||||
|
||||
## 15. 每次推进前的检查清单
|
||||
|
||||
在创建任务、登记成果、更新状态、开启阶段或恢复流程前，逐项确认：
|
||||
|
||||
1. 当前 WORK_ID、SUBTASK_ID、阶段和来源流程是否明确；
|
||||
2. 主责角色、主责成员、会话和人工负责人是否有效；
|
||||
3. 上游成果和依赖是否为当前有效版本；
|
||||
4. 任务是否定义输入、输出、证据、期限和完成判定；
|
||||
5. 提交是否完成角色内部确认；
|
||||
6. 成果、版本、证据、supersedes 和 baseline 引用是否一致；
|
||||
7. 是否存在跨角色冲突、缺失或未经批准的事实；
|
||||
8. 成果是 REQUIRED、WAIVED 还是不适用申请处理中；
|
||||
9. 状态属于哪一层，是否被其他层错误替代；
|
||||
10. 当前门禁是否真正满足；
|
||||
11. 下游只接收最小必要且已登记的上下文；
|
||||
12. 是否需要更新 Project Status Record、成员登记、Risk Register、Change Log 或审计记录。
|
||||
|
||||
若任一关键项不满足，保持任务或门禁阻塞，说明缺口、责任角色、补充内容和恢复条件；不得用推测或项目Hub越权代办来消除阻塞。
|
||||
File diff suppressed because it is too large.
Load diff
File diff suppressed because it is too large.
Load diff
File diff suppressed because it is too large.
Load diff
File diff suppressed because it is too large.
Load diff
@@ -1,118 +0,0 @@
|
||||
# V0.16 → Skill 与 Hook 全量流程覆盖核对
|
||||
|
||||
日期：2026-09-08。范围：以 [V0.16 HTML 全文](../20260907/Codex多角色项目推进总流程图-V0.16.html) 为设计依据，核对总览、通用规则、成果矩阵、全部信息流及页面动态成果标签。V0.16 包含其继承的 V0.15 内容，不只检查两项新增注释。
|
||||
|
||||
本次为本地维护核对，不代表真实项目执行或正式发布。V0.16 仍为 REVIEW；在途项目不自动迁移。未修改 [V0.15 HTML](../20260904/Codex多角色项目推进总流程图-V0.15.html) 或 V0.16 HTML，未提交、推送、合入主分支或更新已安装缓存。核对记录不作为运行时 Skill 的依赖。
|
||||
|
||||
## 本次补齐纪要
|
||||
|
||||
1. 补全状态查询、带证据纠正、核验后重新分发的闭环，以及异步无法按时收敛时的会议处理。
|
||||
2. 补全 X.6 超时升级的触发、责任去向、通知内容和等待状态；逾期不等于批准，项目负责人专属确认不转交业务代批。
|
||||
3. 区分初始提测技术确认与回归按需技术确认；硬件 ECO 即使固件不变，也须完成底层兼容、应用有效性和版本关系确认。
|
||||
4. 补齐复盘改进项责任人与跟进安排、业务结项确认后锁定四类成果和结项后承接。
|
||||
5. 补齐测试结果人工决定向测试同步、豁免失效及附加条件未满足时的处理；纠正自定义角色变更“一律业务批准”的旧泛化表述。
|
||||
|
||||
其余累计更新已有覆盖，继续保留，未重复复制整段流程。入口仅补查阅路由；详细规则仍分布于生命周期、状态、异常、成果、角色及测试二级说明，八角色 Hook 保留精简控制点。
|
||||
|
||||
## 核对方法与落点
|
||||
|
||||
下表按依赖连续的节点分组，覆盖 92 个信息流节点。每组均核对触发条件、责任主体、输入与输出、确认要求、后续流向。共用规则不在每个角色文件重复：
|
||||
|
||||
- 通用提交与确认：[成员工作流](../../etunel-role-collaboration/references/member-workflow.md)、[Hub 工作流](../../etunel-role-collaboration/references/hub-workflow.md)、[消息流程](../../etunel-role-collaboration/references/etunel-message-lifecycle.md)、[成果与完成判定](../../etunel-role-collaboration/references/artifacts-and-evidence.md)。
|
||||
- 阶段与门禁：[项目生命周期](../../etunel-role-collaboration/references/project-lifecycle.md)；具体栏目见 [业务](../../etunel-role-collaboration/references/roles/business.md)、[产品](../../etunel-role-collaboration/references/roles/product.md)、[技术负责人](../../etunel-role-collaboration/references/roles/technical-lead.md)、[应用层](../../etunel-role-collaboration/references/roles/embedded-application.md)、[底层](../../etunel-role-collaboration/references/roles/embedded-lowlevel.md)、[硬件](../../etunel-role-collaboration/references/roles/hardware.md)、[测试](../../etunel-role-collaboration/references/roles/testing.md)。
|
||||
- 状态、异常与归档：[角色与项目状态](../../etunel-role-collaboration/references/project-status-and-membership.md)、[异常与协调](../../etunel-role-collaboration/references/exceptions-and-coordination.md)、[项目文件与进度留档](../../etunel-role-collaboration/references/project-files-and-progress.md)。
|
||||
- 深层测试：[执行与质量门禁](../../etunel-role-collaboration/references/testing/execution-and-gates.md)。专项细则按任务读取，不能增加阶段 8 测试或把选填报告改为必需。
|
||||
|
||||
### 通用、状态与异常
|
||||
|
||||
| 节点 | 触发条件 | 责任主体 | 输入 → 输出 | 确认要求与后续流向 | 核对结果 |
|
||||
|---|---|---|---|---|---|
|
||||
| G.1–G.3 | 任务、成果或跨角色请求需要流转 | 主责 → Hub → 目标角色 → Hub | 有效任务、成果、版本与证据 → 已确认结果和下游引用 | 各自真人确认；Hub 形式与一致性检查、登记后定向路由，不代专业判断 | 已覆盖 |
|
||||
| S.1–S.2 | 上下文不足、过期，或关键状态改变 | 请求角色 → Hub → 请求及受影响角色 | 查询范围、详细度、时点和用途 → 有来源的角色化快照 | 授权内最少信息，不转发私聊和未确认判断；供接收方执行或纠正 | 本次补全查询闭环 |
|
||||
| S.3–S.4 | 收到快照；提出有证据的纠正 | 接收角色 → Hub → 受影响角色 | 可继续确认，或正确值、原因、证据及负责人确认 → 核验后的新快照 | 核对版本与一致性，保留历史；争议转 E，正式基线变化转 X | 本次补全回传与重发 |
|
||||
| E.1–E.2 | 条件、阻塞、依赖、冲突、逾期或下游不可用；复杂问题或异步超时不收敛 | Hub 提醒实际相关角色，当前主责真人组织会议 | 问题、证据、影响、原位置、时限 → 会议问题包与待决定事项 | Hub 不主持专业裁决；未收敛不恢复受影响流程 | 本次明确异步时限及会议输入 |
|
||||
| E.3–E.4 | 讨论形成统一确认结论，Hub 校验通过 | 当前主责 → Hub → 原流程及关联角色 | 各专业确认 → 会议决定、恢复点、动作和新时限 | 仍有关键分歧或缺确认则阻塞；改变基线转 X；不以纪要替代成果 | 本次明确残余分歧及恢复通知 |
|
||||
|
||||
### 阶段 1–4
|
||||
|
||||
| 节点 | 触发条件 | 责任主体 | 输入 → 输出 | 确认要求与后续流向 | 核对结果 |
|
||||
|---|---|---|---|---|---|
|
||||
| F1.1–F1.3 | 业务已收集并内部确认；仅形式错误或来源冲突触发 F1.2 | 业务 → Hub → 业务或产品 | 背景说明、客户里程碑及来源 → 问题清单或待评审版本 | 无错误不走退回；Hub 不补造业务事实；分发产品评审 | 已覆盖 |
|
||||
| F1.4–F1.5 | 评审版本已分发，待确认项已澄清 | 产品、业务经 Hub 分别确认；Hub 分发 | 同一需求版本 → 已登记业务基线及阶段 2 任务 | 双方真人确认、留档后进产品定义；不恢复早期风险预检三流程 | 已覆盖 |
|
||||
| F2.1–F2.2 | 业务基线有效，产品定义启动 | Hub → 产品 → Hub | 阶段 1 基线 → 立项资料、验收标准、里程碑、项目风险及评审请求 | 产品自审确认，明确评审角色、问题与范围 | 已覆盖 |
|
||||
| F2.3–F2.4 | 产品提交可评审草案与请求 | Hub → 指定专业角色 → Hub | 同版四类成果和相关参考 → 字段级结论、缺口、约束、风险及依据 | 各角色只确认本领域，不仅回复可行与否；交产品收口 | 已覆盖 |
|
||||
| F2.5–F2.6 | 存在评审冲突或缺口 | Hub → 产品 → Hub | 意见与冲突 → 修订成果、关闭说明和保留风险 | 产品确认版本；当前必需问题未关闭不推进，不强求后续资料 | 已覆盖 |
|
||||
| F2.7–F2.8 | 专业评审完成、产品候选已确认 | Hub → 业务 → Hub | 范围、验收、里程碑、风险与版本 → 批准、驳回或附条件决定 | 业务内部授权；附条件项明确责任与期限；批准留档后进阶段 3 | 已覆盖 |
|
||||
| F3.1–F3.3 | 阶段 2 门禁通过 | Hub ↔ 技术负责人，再分发相关角色 | 产品基线及已有评审 → 设计要点、接口约束及角色化设计任务 | 不依赖未来项目计划；总体技术方案选填；同一基线设计 | 已覆盖 |
|
||||
| F3.4 | 应用需要新 HAL、资源或协议 | 应用层 → Hub → 底层、技术负责人 | 接口需求、资源指标、理由及影响 → 确认记录 | 不私下约定；已有方案按需修订，改变正式基线转 X | 已覆盖 |
|
||||
| F3.5–F3.6 | 底层依赖硬件约束；硬件提供选填反馈时 | 底层／硬件经 Hub 到技术及受影响角色 | 引脚、时序、电气、板卡及证据 → 约束、替代方案、影响与确认 | 关联明确版本；硬件约束未提供不阻塞本阶段，已提供不静默替换 | 已覆盖 |
|
||||
| F3.7 | 测试形成计划或识别不可测、环境／治具缺口 | 测试 → Hub → 技术负责人或相关角色 | 标准、用例范围、测试项及缺口 → 确认意见与修订计划 | 无问题直接汇总；有问题先定向确认，测试修订，必要时同步接口／验收主责 | 已覆盖 |
|
||||
| F3.8–F3.10 | 计划及反馈就绪，影响门禁的缺口已处理 | Hub ↔ 技术负责人及相关角色 | 测试计划、接口记录、已提供选填成果 → 同版最终确认 | 技术确认计划，专业角色确认可实施／可验证，产品确认不偏离；留档进阶段 4 | 已覆盖 |
|
||||
| F4.1–F4.2 | 方案门禁通过，Hub 形成计划草案 | Hub → 技术负责人 → Hub | 产品／方案、实际角色、阶段 2 风险 → 计划、分工、内部状态初版 | 技术结构、顺序、依赖先确认；每项任务唯一主责 | 已覆盖 |
|
||||
| F4.3–F4.5 | 仅任务有疑点或定向确认后仍有冲突 | Hub ↔ 对应执行角色、技术负责人及受影响角色 | 具体任务缺口 → 工时／资源确认和计划修订 | 不全员重审；残余冲突转 E，关闭前不基线化 | 已覆盖 |
|
||||
| F4.6–F4.8 | 技术结构、问题任务和剩余冲突已处理 | Hub ↔ 产品，再分发执行角色 | 资源排期候选 → 产品确认基线与充分任务输入 | 产品确认授权内人员资源排期；预算采购承诺另需业务授权；知会业务不加门禁 | 已覆盖 |
|
||||
|
||||
### 阶段 5–6
|
||||
|
||||
| 节点 | 触发条件 | 责任主体 | 输入 → 输出 | 确认要求与后续流向 | 核对结果 |
|
||||
|---|---|---|---|---|---|
|
||||
| F5.1 | 阶段 4 门禁通过、对应依赖就绪 | Hub → 应用层、底层、硬件 | 同版方案、任务计划、角色分工及风险 → 各实现任务 | 仅依赖就绪任务并行；硬件缺输入不拖住其他任务 | 已覆盖 |
|
||||
| F5.2–F5.3 | 器件规格书和结构板框图已核对 | 硬件 → Hub → 技术及受影响角色 | 实际器件规格、主要位置与禁止区域 → 原理图、PCB 源文档、贴片资料、接口定义 | 硬件真人先确认、技术及接口确认后实施；不另交硬件实现资料包 | 已覆盖 |
|
||||
| F5.4–F5.5 | 底层报告形成、BSP／PSP 可访问且版本明确 | 底层 → Hub → 应用层 | 硬件功能测试报告、BSP／PSP 路径、匹配信息 → 可消费版本 | 自测不代整机质量；WiFi 定频固件选填且仅专项用途，非最终固件 | 已覆盖 |
|
||||
| F5.6–F5.7 | 应用取得登记底层版本；实现有冲突时 | 应用层／实现角色 → Hub → 技术负责人 | 统一候选与版本链；冲突证据 → 固件包或技术协调记录 | 唯一应用出口；冲突冻结受影响版本，不冻结无关工作 | 已覆盖 |
|
||||
| F5.8 | 统一固件与硬件候选均就绪 | Hub → 应用层、硬件、技术负责人 | 候选版本链 → 联调任务、矩阵、问题记录 | 不要求最终提测版或联调问题先关闭；执行联调 | 已覆盖 |
|
||||
| F5.9–F5.10 | 联调问题关闭后提交最终版，再作匹配确认 | 应用层 → Hub；技术负责人 → Hub | 最终固件、硬件及底层链 → 技术匹配与可提测确认 | 此确认必需；确认后唯一固件进入 F6.1 | 已覆盖并澄清与回归的区别 |
|
||||
| F6.1–F6.2 | 应用最终固件与硬件组合经技术负责人批准 | Hub → 测试 → Hub | 统一固件、矩阵、计划 → 功能报告、缺陷清单及已提供选填成果 | 不默认附底层／硬件整包；完成且零缺陷走 F6.10，否则进缺陷协调 | 已覆盖 |
|
||||
| F6.3 | 测试发现可追踪缺陷或异常 | 测试经 Hub 与实际相关负责人商议 | 缺陷条目、版本、证据、影响 → 责任人、唯一主责、协作与时限 | Hub 不自行定责；分歧转 E，清单仍由测试维护 | 已覆盖 |
|
||||
| F6.4–F6.5 | 已共同确认责任，原因及计划已确认 | 责任角色 → Hub；Hub → 责任角色并同步测试 | 原因、方案、期限、重测范围 → 修复／澄清任务与清单更新依据 | 两个方向分开；不修复等处置有依据；实现角色不替换清单 | 已覆盖 |
|
||||
| F6.6–F6.8 | 已有应用、底层修复或硬件 ECO | 责任角色 → Hub → 应用层 → Hub | 修复、自测、影响 → 新统一固件或原固件有效性确认及新矩阵 | 底层必须合版；硬件 ECO 经底层兼容、应用有效性确认；技术矩阵按需确认 | 本次明确固件不变分支与按需条件 |
|
||||
| F6.9 | 回归固件与矩阵通过 Hub 校验，必要技术确认已满足 | Hub → 测试 | 统一固件、矩阵、缺陷清单及必要变更说明 → 定向独立回归 | 定位资料按问题提供；不每轮固定技术审批；测试才可复验关闭缺陷 | 本次纠正无条件技术确认 |
|
||||
| F6.10 | 测试完成且无缺陷，或修复与必要回归完成；必需依据齐、阻断缺陷清零 | 测试 → Hub | 测试负责人确认的报告、清单、质量与剩余风险接受方 → 待项目负责人确认 | 零缺陷也交报告与零清单；已提供选填成果一并确认；进 F6.11 | 已覆盖 |
|
||||
| F6.11–F6.12 | Hub 校验最终结果，真人明确确认或退回 | Hub ↔ Hub 对应真人项目负责人，再同步测试 | 当前结果与索引 → 人、时间、版本、范围、决定及后续动作 | 未确认不算提交完成；确认不代质量通过；退回补充／必要修复后重确认，满足质量门禁才进验收 | 本次补明向测试同步 |
|
||||
|
||||
### 阶段 7–8、变更与豁免
|
||||
|
||||
| 节点 | 触发条件 | 责任主体 | 输入 → 输出 | 确认要求与后续流向 | 核对结果 |
|
||||
|---|---|---|---|---|---|
|
||||
| F7.1 | F6.12 人工确认及质量门禁满足，资料已交付 | 测试真人直接交产品真人，产品 → Hub | 测试报告及已提供佐证 → 文件名、版本与接收确认 | Hub 留索引不转大文件；收讫不等验收通过，未提供选填件无需补交 | 已覆盖 |
|
||||
| F7.2–F7.3 | 平台输入就绪，优先组织平台验收 | Hub → 产品 → Hub | 已收测试资料、验收标准及版本 → 平台报告或结论，更新同一遗留清单 | 产品真人确认，不经业务批准；不通过转共用返工 | 已覆盖 |
|
||||
| F7.4–F7.5 | 客户资料及真人联络条件就绪，不必等平台通过 | Hub → 产品 → Hub | 客户反馈与版本 → 客户报告草案，保留平台问题并标客户来源 | 不虚构客户 Agent 或反馈；可与平台并行，交业务确认 | 已覆盖 |
|
||||
| F7.6–F7.7 | 客户材料与反馈齐备 | Hub → 业务 → Hub | 客户报告及客户问题 → 通过或整改决定 | 仅确认客户分支；未确认不算客户通过，失败转返工 | 已覆盖 |
|
||||
| F7.8–F7.9 | 任一验收失败、缺资料或结论需修订 | Hub ↔ 实际责任角色 | 对应问题 → 整改、必要复验、更新分支结论 | 需测试则回阶段 6，新结果重新人工确认；改变版本影响另一分支时亦更新确认 | 本次明确跨分支版本影响 |
|
||||
| F7.10 | 同对象有效版本的平台与客户均通过 | Hub 登记 | 产品平台确认、业务客户确认、共用清单 → 双线验收基线 | 核对来源、状态、责任和期限；任一未完成不进阶段 8 | 已覆盖 |
|
||||
| F8.1–F8.3 | 双线通过后收集已有资料并核对承接 | Hub ↔ 实际参与角色、产品及业务 | 有效成果、索引、变更、确认 → 资料／缺口清单及遗留承接 | 不虚构未参与者成果，不重复制作；平台不增加业务重批 | 已覆盖 |
|
||||
| F8.4–F8.5 | 项目事实和主要问题已整理 | Hub → 实际相关角色 → Hub | 偏差、协作、质量与经验 → 确认的复盘结论、措施、责任人和跟进安排 | 基于事实，汇入流程闭环总结，不增加独立改进成果文件 | 本次补齐改进项承接 |
|
||||
| F8.6–F8.7 | 收集、验收核对、复盘完成，结项包完整且遗留有承接 | Hub 汇总；业务 → Hub 确认 | 四类结项成果 → 结项决定或补充清单 | 必需缺口未补不关闭；业务确认后锁定归档，关闭并按安排跟进，未来措施不算已执行 | 本次补齐锁定与结项后跟进 |
|
||||
| X.1–X.3 | 基线变化或阻塞，确认影响正式成果 | 任意角色 → Hub ↔ 实际受影响角色 | 原因、版本、证据、紧急度 → 范围、工期、成本、返工及测试影响 | 各角色内部确认现实承诺；冻结受影响任务，其他任务继续 | 已覆盖 |
|
||||
| X.4–X.5 | 影响评估齐全，适用授权明确 | Hub ↔ 产品／业务及有权专业角色 | 综合影响与候选基线 → 确认、批准、拒绝或延期记录 | 授权内资源排期产品确认，预算采购承诺业务批准；批准更新基线，拒绝延期维持原基线 | 本次明确决定留档并纠正角色变更泛化 |
|
||||
| X.6 | 确认或任务超过约定时间 | Hub → 对应角色；项目级组织授权交业务 | 逾期对象、时长、证据、影响、替代方案和新期望时间 → 内部确认回复 | 专属人工确认不改权；未获必要决定仍等待／阻塞，新时间不是延期已获准 | 本次新增明确流程 |
|
||||
| Y.1–Y.2 | 必需成果主责判断不适用并提出申请 | 主责 → Hub → 主责补正或人工决定 | 原因、证据、替代方案、风险、基线与负责人确认 → 资格及结构检查 | 非主责、无证据、不可豁免不能放行；来不及不等于不适用 | 已覆盖 |
|
||||
| Y.3 | Hub 已校验汇总申请 | Hub 对应真人项目负责人 → Hub | 申请及影响 → 明确批准／拒绝、人、时间、范围、条件与失效条件 | 不由 AI 决定，不另设已删除的下游征询或业务确认环节 | 已覆盖 |
|
||||
| Y.4A–Y.4B | 已批准，或拒绝／附加条件未满足 | Hub → 受影响角色或成果主责 | 豁免记录及替代依据，或补交内容／证据／期限 | 保留原必需项；范围或输入基线变更使旧豁免失效；只豁免文件，不取消测试验收门禁 | 本次明确失效及未满足条件分支 |
|
||||
|
||||
## 正式成果及栏目交叉检查
|
||||
|
||||
- 阶段 1：使用客户里程碑要求，小批量试产、量产选填；不恢复早期风险预检。
|
||||
- 阶段 2：立项资料包含平台 SDK、个参资料；项目风险在本阶段形成、由产品持续维护；结构板框图本阶段选填。
|
||||
- 阶段 3：测试计划必需、总体技术方案与硬件约束选填；不要求软硬件接口契约、架构决策记录或硬件设计包。
|
||||
- 阶段 4：项目计划包含任务拆分与工时评估；不另设产品资料整合，也不重新创建本阶段项目风险成果。
|
||||
- 阶段 5：硬件前置器件规格书及结构板框图与四类设计输出分开；BSP／PSP 路径须可访问；定频固件选填；统一应用包保留 zn_debug、MD5、分区、自测、Changelog、串口使能证书等要求。
|
||||
- 阶段 6：必需为功能测试报告和缺陷清单；三类报告／佐证选填；删除的是 bug 汇总统计要求，不是用例执行结果、缺陷条目或质量依据；不强制独立专项矩阵、通用证据包或缺陷分析报告。
|
||||
- 阶段 7：平台报告或结论二选一、客户验收通过报告、同一遗留问题清单；权限和同版双通过条件一致。
|
||||
- 阶段 8：结项资料归档、变更记录、结项报告、流程闭环总结四类；无新增冒烟或发布验证。
|
||||
|
||||
## 验证与边界
|
||||
|
||||
- 已执行 Skill Creator 结构校验：通过。
|
||||
- 已进行七组独立只读情景核验：普通回归、硬件 ECO 不改固件、不同权限的超时、未来改进与结项、状态纠正、豁免基线失效、零缺陷人工确认。核验指出的硬件 Hook 泛化已收紧为阶段 5 设计确认与阶段 6 回归按需确认的区别，并通过定向复查。
|
||||
- 静态检查通过：32 个 Markdown 文件中的 83 处本地链接可解析；8 个 Hook JSON 合法，角色标识、显示名称、字段集合和工具列表未改变；92 个信息流节点全部有核对记录，无遗漏或额外编号；差异空白检查通过；两版 HTML 哈希未改变。上述检查不代替真实 Etunel 项目运行。
|
||||
- 未调用真实 Etunel、钉钉、平台测试或客户验收；未改变现有运行项目、已安装 Skill／Hook 或远程 Git。
|
||||
|
||||
保护文件 SHA256：
|
||||
|
||||
| 文件 | SHA256 |
|
||||
|---|---|
|
||||
| V0.15 HTML | `3717DE13267E83E7408342FF25584050BE20167A96EED097577AC4542789EB73` |
|
||||
| V0.16 HTML | `47695E15051E9C1647A4E5CC18F5BDE17FEED8890FD1649339E77E4ADAF49AC9` |
|
||||
|
||||
本次开始时分支为 `docs/v0.15-next`，HEAD 为 `163f655cd0ac09ccf87adeec0a3fb665ceb01042`。修改保留在工作区，待用户核对后再决定是否提交或推送。
|
||||
@@ -5,7 +5,7 @@
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
<meta name="color-scheme" content="light" />
|
||||
<link rel="icon" href="data:," />
|
||||
<title>Codex 多角色项目推进总流程图与信息流图谱｜V0.16 REVIEW</title>
|
||||
<title>Codex 多角色项目推进总流程图与信息流图谱｜V1.0 CURRENT</title>
|
||||
<style>
|
||||
:root {
|
||||
--navy: #10253f;
|
||||
@@ -661,16 +661,16 @@
|
||||
<body>
|
||||
<header class="hero" id="top">
|
||||
<div class="hero-inner">
|
||||
<div class="eyebrow">CODEX MULTI-ROLE PROJECT FLOW · V0.16 · REVIEW</div>
|
||||
<div class="eyebrow">CODEX MULTI-ROLE PROJECT FLOW · V1.0 · CURRENT</div>
|
||||
<h1>项目推进总流程图</h1>
|
||||
<p>业务、项目Hub、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件和测试是当前基线角色，不是封闭列表；项目Hub负责信息路由、成员与状态维护和阶段门禁，新增自定义角色必须先形成职责、成果和决定权契约。</p>
|
||||
<div class="current-banner" role="status"><strong>V0.16 · 评审版本</strong><span>创建：2026-09-07；生效日期待定。基于 V0.15 保留副本创建，仅更新流程文档，尚未合入主分支或同步 Skill 与角色提醒。</span></div>
|
||||
<div class="current-banner" role="status"><strong>V1.0 · 当前定版</strong><span>文档生效：2026-09-08。当前基线包含八角色、八阶段、测试结果人工确认及跨阶段流程。此文件原位维护，历史通过 Git 追溯；部署 Skill／Hook 及迁移在途项目须另行确认。</span></div>
|
||||
</div>
|
||||
</header>
|
||||
|
||||
<nav class="global-nav" aria-label="文档全局导航">
|
||||
<div class="global-nav-inner">
|
||||
<a class="nav-brand" href="#top">V0.16 REVIEW · 顶部</a>
|
||||
<a class="nav-brand" href="#top">V1.0 CURRENT · 顶部</a>
|
||||
<a href="#changelog">版本记录</a>
|
||||
<a href="#overview">总流程</a>
|
||||
<a href="#rules">通用规则</a>
|
||||
@@ -693,83 +693,23 @@
|
||||
<div class="if-section-head">
|
||||
<div class="if-section-no">VERSION / CHANGELOG</div>
|
||||
<div>
|
||||
<h2>版本变更记录</h2>
|
||||
<p>每个新版本都保留上一版文件，并在当前版本中记录变更内容、影响范围和基线状态。</p>
|
||||
<h2>当前版本与维护方式</h2>
|
||||
<p>只维护这一份当前流程文档，旧版内容与变更通过 Git 提交历史追溯。</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="if-callout">
|
||||
<strong>版本管理规则：</strong>从 V0.8 开始，新版本通过复制当前最新文件创建，禁止覆盖或删除历史版本。评审版本标记为 REVIEW，并记录创建日期和待定的生效日期；只有取得明确的定版确认后，才改为 CURRENT，并同步更新文件名、页面标题、导航、页脚、本表及仓库中的当前流程基线引用。
|
||||
<strong>版本管理规则：</strong>文档固定保存在 <code>doc/Codex多角色项目推进总流程图.html</code>，后续直接修改同一文件，不再创建日期目录或版本副本。变更经确认后更新当前版本标识、生效日期及相关 Skill、Hook 和仓库说明；部署和在途项目迁移另行确认。
|
||||
</div>
|
||||
<div class="if-callout" style="margin-top: 14px">
|
||||
<strong>版本号口径：</strong>V0.x 用于验证期的角色、阶段、成果、信息流和文档管理调整；当角色责任与八阶段流程稳定且完成整体验证后，再升级为 V1.0。
|
||||
</div>
|
||||
|
||||
<div class="if-table-wrap" style="margin-top: 22px">
|
||||
<table>
|
||||
<thead>
|
||||
<tr><th>版本</th><th>日期</th><th>状态</th><th>主要变更</th><th>影响范围</th></tr>
|
||||
<tr><th>版本</th><th>日期</th><th>状态</th><th>内容范围</th><th>历史追溯</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><b>V0.16</b></td><td>创建：2026-09-07<br>生效：待定</td><td>REVIEW</td>
|
||||
<td>删除缺陷清单中的汇总统计要求；测试结果增加项目负责人（Hub 对应真人负责人）确认，统一无缺陷路径、阶段门禁和验收入口。</td>
|
||||
<td>阶段 6 总览与信息流、通用确认规则、成果矩阵及阶段 7 入口；仅文档评审，未同步 Skill。</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>V0.15</b></td><td>创建：2026-09-04<br>生效：2026-09-07</td><td>保留原版</td>
|
||||
<td><ol><li>精简业务及产品资料与选填项；立项增加平台 SDK、个参资料，项目风险前移阶段 2，删除独立产品资料整合。</li><li>取消独立接口契约、架构决策记录和硬件实现资料；阶段 3 硬件约束选填，明确阶段 5 硬件、底层交付。</li><li>补充工时评估；产品确认授权范围内资源与排期，预算、采购或对外承诺由业务批准。</li><li>精简测试输入，改用缺陷清单并共同商议责任人；可靠性、专项报告及提测佐证选填。</li><li>平台与客户验收可按条件并行且须双通过；平台由产品出具结论、客户由业务确认，测试资料直交产品。</li><li>结项聚焦资料收集与复盘；豁免精简为项目负责人审批，统一编号、成果引用及 Skill、角色提醒。</li></ol></td>
|
||||
<td>文档版本管理、阶段 1–8 总流程、成果矩阵、关联信息流、Skill 及八角色 Hook。</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>V0.14</b></td><td>2026-09-02</td><td>HISTORICAL</td>
|
||||
<td>人工可读的正式成果、过程成果、标题、正文和结论统一使用中文，机器字段与枚举只保留在运行时工具参数中；项目Hub通过 Etunel 角色清单读取实际 <code>role</code>、<code>display_name</code> 和 <code>relationship</code>，成员角色不再向负责人追问成员、会话或任务编号；新增同源 JSON 和中文 HTML 两种版本的《项目成员清单》，并补充按阶段整理成果、过程记录、项目进度和成果索引的留档规则。</td>
|
||||
<td>全局成果语言、项目创建、角色登记、Etunel 实际字段、项目文件与进度留档、项目Hub与各成员角色约束和内部培训材料。</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>V0.13</b></td><td>2026-08-28</td><td>HISTORICAL</td>
|
||||
<td>完成八角色跨文件一致性审核；新增项目成员／多账户／自定义角色规则和状态术语词典；区分项目创建时成员登记与阶段 4 角色分工；统一 NA、测试证据包、软硬件接口契约 和业务术语；同步测试主责的缺陷报告闭环；将信息流图谱顺序统一为阶段 3 方案设计后进入阶段 4 项目规划；重新生成项目Hub系统提示词。</td>
|
||||
<td>全局角色与成员管理、状态与成果术语、阶段 1 业务输入、阶段 4 成员／任务分工、阶段 6 缺陷闭环、项目Hub提示词。</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>V0.12</b></td><td>2026-08-28</td><td>HISTORICAL</td>
|
||||
<td>校正 测试计划 的阶段 3 主责；统一 测试计划 和五类阶段 6 正式成果，完善共同最低结构、NA／BLOCKED／成果豁免 边界、缺陷分析报告 主责、平台提测与业务验收边界；把缺陷专业归类和根因责任从项目Hub／测试的越权表述中移回有权角色。</td>
|
||||
<td>阶段 2 可测性评审、阶段 3 测试计划、阶段 5 提测准备、阶段 6 正式测试与缺陷闭环、阶段 7 验收证据、阶段 8 发布冒烟。</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>V0.11</b></td><td>2026-08-28</td><td>HISTORICAL</td>
|
||||
<td>校正硬件角色的阶段 3 设计职责；拆分 硬件设计包 与 硬件实现资料；完善原理图、PCB、Gerber／钻孔、BOM、贴片／生产资料、板卡／批次标识、板级测量和硬件版本链；建立 ECO→底层兼容评估→应用固件确认→技术版本矩阵→测试复验闭环。</td>
|
||||
<td>阶段 3 硬件设计、阶段 5 板卡／样机实现、阶段 6 硬件 ECO 与回归、阶段 7 验收返工、阶段 8 硬件归档。</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>V0.10</b></td><td>2026-08-28</td><td>HISTORICAL</td>
|
||||
<td>校正嵌入式底层的阶段 3 设计职责；完善 嵌入式底层实现资料 最低内容、可消费／修复／归档版演进、板卡／BOM／ECO 与接口契约绑定、专项测试固件限制、应用层重新合版和发布归档边界；扩充流程图底层成果说明。</td>
|
||||
<td>阶段 3 方案设计、阶段 5 底层实现与应用合版、阶段 6 底层缺陷回归、阶段 7 验收返工、阶段 8 底层归档。</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>V0.9</b></td><td>2026-08-28</td><td>HISTORICAL</td>
|
||||
<td>校正嵌入式应用层的阶段 3 设计职责；完善 嵌入式应用层固件包 最低内容、候选／提测／回归／发布版演进、底层重新合版、硬件变化兼容确认和最终固件唯一出口约束；继续清理项目Hub旧称和广播表述。</td>
|
||||
<td>阶段 3 方案设计、阶段 5 实现集成、阶段 6 缺陷回归、阶段 7 验收返工、阶段 8 发布归档。</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>V0.8</b></td><td>2026-08-28</td><td>HISTORICAL</td>
|
||||
<td>新增文档内版本变更记录、版本号口径和历史文件保留规则；从本版本起不再通过重命名覆盖上一版。</td>
|
||||
<td>全局导航、版本管理、项目Hub流程基线引用。</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>V0.7</b></td><td>2026-08-28</td><td>HISTORICAL</td>
|
||||
<td>修正技术负责人在阶段 3 与阶段 4 的责任顺序；明确总体方案、软硬件接口契约和架构决策的主责；明确项目Hub维护版本矩阵、技术负责人确认版本匹配。</td>
|
||||
<td>阶段 3 方案设计、阶段 4 项目规划、阶段 5 集成提测、技术缺陷与变更评估。</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>V0.6</b></td><td>2026-08-28</td><td>HISTORICAL</td>
|
||||
<td>统一产品角色的阶段 2 与阶段 7 正式成果；补齐产品发起早期风险预检、产品定义评审和验收闭环；客户平台资料改为参考输入基线。</td>
|
||||
<td>阶段 1 早期预检、阶段 2 产品定义、阶段 7 业务验收。</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>V0.5</b></td><td>未登记</td><td>HISTORICAL BASELINE</td>
|
||||
<td>建立八阶段主流程、项目Hub中枢角色、角色化状态同步 S.1–S.4、异常协同 E.1–E.4、变更升级 X.1–X.6 和成果豁免 Y.1–Y.7；形成正式成果追踪矩阵。</td>
|
||||
<td>总流程、项目Hub、全局信息流、门禁和成果追踪。</td>
|
||||
<td><b>V1.0</b></td><td>文档生效：2026-09-08</td><td>CURRENT</td>
|
||||
<td>八角色、八阶段、角色职责与成果、测试结果人工确认、跨阶段协调及模板复用规则。</td>
|
||||
<td>使用 <code>git log --all -- doc/</code> 查询历史；已运行项目保留其登记基线，不因仓库更新自动迁移。</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@@ -866,7 +806,7 @@
|
||||
|
||||
<div class="if-atlas" id="information-flow-atlas">
|
||||
<section class="if-intro">
|
||||
<div class="if-eyebrow">STAGE INFORMATION FLOW ATLAS · V0.16 · REVIEW</div>
|
||||
<div class="if-eyebrow">STAGE INFORMATION FLOW ATLAS · V1.0 · CURRENT</div>
|
||||
<h2>各阶段角色信息流图谱</h2>
|
||||
<p>以下内容直接承接总流程图，展示每条会影响成果、决策、门禁、返工或版本的正式信息流，并说明触发条件、发送方、接收方、载荷、确认要求和阻塞约束。</p>
|
||||
<div class="if-quicknav">
|
||||
@@ -1226,7 +1166,7 @@
|
||||
</tbody></table></div>
|
||||
</section>
|
||||
</div>
|
||||
<div class="footer">Codex 多角色项目推进总流程图与阶段信息流图谱 · V0.16 · REVIEW</div>
|
||||
<div class="footer">Codex 多角色项目推进总流程图与阶段信息流图谱 · V1.0 · CURRENT</div>
|
||||
</main>
|
||||
<script>
|
||||
(() => {
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
登记日期：2026-09-08。根据用户提供的 `D:/AI全流程辅助/项目推进总流程` 只读学习，供后续资料生成和审核时按需查阅。
|
||||
|
||||
流程依据：[V1.0 总流程图](../Codex多角色项目推进总流程图-V1.0.html)。本参考不是新流程基线，不改变 Skill、Hook、角色职责或门禁，也不表示已部署或推送。
|
||||
流程依据：[V1.0 总流程图](../Codex多角色项目推进总流程图.html)。本参考不是新流程基线，不改变 Skill、Hook、角色职责或门禁，也不表示已部署。
|
||||
|
||||
## 先读什么
|
||||
|
||||
@@ -65,6 +65,6 @@
|
||||
- 应用包里的高低版本可用于升级测试；自测表明确要求高低版本。应区分测试配套版本与唯一最终提测版本，不能仅凭两个版本文件名就判错。
|
||||
- V1.0 灯态描述的“绑定”改“配网”不意味着把平台账号绑定、解绑等实际业务术语全局替换。
|
||||
|
||||
## 本次未做的事
|
||||
## 维护与执行边界
|
||||
|
||||
没有修改、移动或删除原始模板；没有修改 V0.15、V0.16、V1.0 HTML、Skill、Hook 或已安装缓存；没有执行烧录/SDK/模板脚本、外部下载、真实通知或项目审批；没有 Git 提交、推送或合并。所有本次新增内容仅为本地参考笔记与源文件索引。
|
||||
这里只维护参考笔记和源文件索引，不包含原始模板；源目录是登记时的来源，不保证在其他设备可访问。后续直接更新当前文件，通过 Git 保留历史，不另建日期或版本目录。参考资料不授权执行烧录、SDK 或模板脚本、外部下载、真实通知、项目审批，也不会自动修改 Etunel 配置或已安装缓存。
|
||||
File renamed without changes.
@@ -1,6 +1,6 @@
|
||||
# 阶段 6 模板只读学习记录
|
||||
|
||||
核对日期：2026-09-08。源目录：`D:/AI全流程辅助/项目推进总流程/6、测试验证`。下文路径均相对于源目录。流程基准为 `D:/codex/EP-Hub-Skill-v015-release/doc/20260908/Codex多角色项目推进总流程图-V1.0.html`。
|
||||
核对日期：2026-09-08。源目录：`D:/AI全流程辅助/项目推进总流程/6、测试验证`。下文路径均相对于源目录。流程基准为[当前 V1.0 总流程图](../Codex多角色项目推进总流程图.html)。
|
||||
|
||||
## 阅读范围与边界
|
||||
|
||||
File renamed without changes.
File renamed without changes.
Reference in new issue
Block a user