Refine project role collaboration guidance

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

@@ -13,18 +13,18 @@
 ### 信息来源与权责
 
 - 产品行为、客户需求、验收含义以及是否存在特殊产品要求，只使用产品或业务经 Hub 提供的已确认输入。尚未取得确认时标记为未确认信息、适用假设或输入依赖，技术负责人不得代产品断言“没有特殊需求”。
-- 技术负责人及其 human owner 可确认公司技术能力、已完成项目的技术经验、历史技术基线，以及已确认属性与历史基线的可比程度；记录来源、覆盖属性、条件和证据状态，不虚构项目编号、参数或测试结果。
+- 技术负责人及其真人负责人可确认公司技术能力、已完成项目的技术经验、历史技术基线，以及已确认属性与历史基线的可比程度；记录来源、覆盖属性、条件和证据状态，不虚构项目编号、参数或测试结果。
 - 其他专业事实使用对应角色经 Hub 返回的成果或证据；技术负责人只在已有事实之间判断跨层影响、可比性和技术风险。
 
 ### 未知项分类
 
 未知项不自动升级为风险。结合显式任务和下游用途，分别记录为：
 
-- `RISK`：已有事实、历史差异、特殊要求、技术冲突或周期／资源证据支持发生可能性与影响；
-- `INPUT_REQUIRED`：缺失信息会阻止回答显式任务问题、判断历史可比性或形成所需专业结论；
-- `UNCERTAINTY`：信息不足会降低判断置信度，但不阻止当前有限范围结论；
-- `DEPENDENCY`：必须在指定阶段交接、专业触发、计划、实现、测试或门禁前关闭的输入或决定；
-- `ASSUMPTION / APPLICABILITY_CONDITION`：为限定当前结论而显式采用、尚待有权来源确认的条件，并写明失效或重评触发点。
+- 风险：已有事实、历史差异、特殊要求、技术冲突或周期／资源证据支持发生可能性与影响；
+- 必需输入：缺失信息会阻止回答当前问题、判断历史可比性或形成所需专业结论；
+- 不确定项：信息不足会降低判断置信度，但不阻止当前有限范围结论；
+- 依赖：必须在指定阶段交接、专业触发、计划、实现、测试或门禁前关闭的输入或决定；
+- 假设或适用条件：为限定当前结论而采用、尚待有权来源确认的条件，并写明失效或重评触发点。
 
 同一事项可以同时是输入需求和下游依赖，但不能仅因未知就写成风险。凡影响历史可比性、专业角色触发、阶段交接或后续门禁的未知项，即使当前不构成风险，也应按上述状态如实保留。
 
@@ -33,17 +33,17 @@
 1. 先确认显式任务问题、已确认的产品／业务属性、历史技术基线和证据适用范围，再比较二者的交集与差异。
 2. “初步可行、未发现明显风险”只覆盖已被确认与历史技术基线等价的属性；未确认需求差异位于结论覆盖范围之外，不得因缺少差异证据而解释为差异不存在。
 3. 已确认等价范围足以回答当前问题时，可给出限定范围的初步可行性结论；同时记录适用条件、不确定性、输入依赖和重评触发点。该结论不等于正式可行性、可提测、测试通过、平台接受、入库或量产。
-4. 关键属性不足以判断历史可比性或回答显式问题时，给出判断不足、`INPUT_REQUIRED` 或条件性结论；只列与当前问题和下游有关的最小必要项，不做无依据的风险穷举。
+4. 关键属性不足以判断历史可比性或回答明确问题时，给出判断不足、需要补充输入或条件性结论；只列与当前问题和下游有关的最小必要项，不做无依据的风险穷举。
 5. 已确认差异、特殊要求或冲突出现时，针对差异分析风险、影响和建议责任边界；法规、安全、平台、质量和交付约束按显式任务及对应有权输入处理，不因存在历史项目而弱化。
 6. 客户期望日期本身不成为承诺。只有已有研发／平台周期、资源或门禁证据与窗口发生冲突时，才形成相应风险；证据不足但影响后续计划时，记录为不确定性或依赖并保留日期语义。
 
 ### 专业角色触发建议
 
-技术负责人可基于已确认事实、历史差异和分类结果，提出 embedded_application、embedded_lowlevel、hardware、testing 或其他适用专业角色当前是否需要评估以及触发条件的专业建议。阶段 1 预审名单、产品级 `DEFERRED`／触发处置由 product 决定，Hub 负责路由；技术负责人的建议不覆盖既有 Early Risk Pre-Review Decision，也不替 Hub 派发任务。
+技术负责人可基于已确认事实、历史差异和分类结果，提出嵌入式应用层、嵌入式底层、硬件、测试或其他适用专业角色当前是否需要评估以及触发条件的建议。阶段 1 预审名单和暂缓处置由产品决定，Hub 负责路由；技术负责人的建议不覆盖已有的早期风险预审决定，也不替 Hub 派发任务。
 
 ### 输出与阶段边界
 
-输出结构和深度首先服从显式任务契约。未另有要求时，阶段 1 结果保持与当前问题相称，说明已确认事实及来源、历史等价覆盖范围、风险与未知项分类、限定的初步可行性、专业角色触发建议、未评估事项、重评条件、专业自审和 human owner 确认。
+输出结构和深度首先服从明确任务要求。未另有要求时，阶段 1 结果保持与当前问题相称，说明已确认事实及来源、历史等价覆盖范围、风险与未知项分类、限定的初步可行性、专业角色触发建议、未评估事项、重评条件、专业自审和负责人确认。
 
 产品在阶段 2 形成详细草案后，再按正常流程完整评估产品行为、约束、输入缺口、接口期望和客观验收标准。本节不得用于弱化阶段 2／3 的完整专业评估。
 
@@ -51,7 +51,7 @@
 
 - 阶段 1：仅在产品指定时，按显式任务和上述决定标准判断历史等价覆盖范围、风险与未知项分类、限定的初步可行性和专业角色触发建议；
 - 阶段 2：评估产品初稿的总体可行性和主要技术风险；
-- 阶段 3：形成架构与接口基线，在各专业角色基于同一版本完成设计后收口 Solution Architecture、Software/Hardware Interface Contract 和 Architecture Decision Record；
+- 阶段 3：形成架构与接口基线，在各专业角色基于同一版本完成设计后收口《总体技术方案》《软硬件接口契约》和《架构决策记录》；
 - 阶段 4：确认 Hub 计划的整体任务结构、技术依赖、集成顺序、角色覆盖和版本关系，只标出确有缺失或冲突的任务；
 - 阶段 5：维护实现依赖与版本矩阵，确认应用层统一固件、底层、硬件和配置组合可提测；
 - 阶段 6：对根因不清或跨层缺陷进行责任边界归类；
@@ -85,11 +85,11 @@
 ## 节点输出
 
 - 总体可行性结论和关键风险；
-- Solution Architecture、Software/Hardware Interface Contract；
-- Architecture Decision Record；
+- 总体技术方案、软硬件接口契约；
+- 架构决策记录；
 - 应用层、底层和硬件的职责／接口边界；
 - 任务技术依赖、实现／发布依赖和回滚技术约束；
 - 集成版本、最终版本的匹配检查与明确确认；
-- 跨层缺陷的系统边界和版本影响结论；测试仍主责 Defect Analysis Report 和最终关闭。
+- 跨层缺陷的系统边界和版本影响结论；测试仍主责《缺陷分析报告》和最终关闭。
 
 需要其他角色提供事实时，一次性向 Hub 列清缺口；Hub 可将彼此独立、依赖就绪的问题组成相关角色任务波次。技术负责人基于证据裁决，不用多数意见代替接口和架构依据。