Files
EP-Hub-Skill/doc/20260908/V0.16-Skill全量流程覆盖核对.md

20 KiB
Raw Permalink Blame History

V0.16 → Skill 与 Hook 全量流程覆盖核对

日期:2026-09-08。范围:以 V0.16 HTML 全文 为设计依据,核对总览、通用规则、成果矩阵、全部信息流及页面动态成果标签。V0.16 包含其继承的 V0.15 内容,不只检查两项新增注释。

本次为本地维护核对,不代表真实项目执行或正式发布。V0.16 仍为 REVIEW;在途项目不自动迁移。未修改 V0.15 HTML 或 V0.16 HTML,未提交、推送、合入主分支或更新已安装缓存。核对记录不作为运行时 Skill 的依赖。

本次补齐纪要

  1. 补全状态查询、带证据纠正、核验后重新分发的闭环,以及异步无法按时收敛时的会议处理。
  2. 补全 X.6 超时升级的触发、责任去向、通知内容和等待状态;逾期不等于批准,项目负责人专属确认不转交业务代批。
  3. 区分初始提测技术确认与回归按需技术确认;硬件 ECO 即使固件不变,也须完成底层兼容、应用有效性和版本关系确认。
  4. 补齐复盘改进项责任人与跟进安排、业务结项确认后锁定四类成果和结项后承接。
  5. 补齐测试结果人工决定向测试同步、豁免失效及附加条件未满足时的处理;纠正自定义角色变更“一律业务批准”的旧泛化表述。

其余累计更新已有覆盖,继续保留,未重复复制整段流程。入口仅补查阅路由;详细规则仍分布于生命周期、状态、异常、成果、角色及测试二级说明,八角色 Hook 保留精简控制点。

核对方法与落点

下表按依赖连续的节点分组,覆盖 92 个信息流节点。每组均核对触发条件、责任主体、输入与输出、确认要求、后续流向。共用规则不在每个角色文件重复:

通用、状态与异常

节点 触发条件 责任主体 输入 → 输出 确认要求与后续流向 核对结果
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。修改保留在工作区,待用户核对后再决定是否提交或推送。