@givolt/i3-composer-agent 3.1.0 → 4.0.0

package/skills/i3-enterprise-sop/references/technical-baseline/baselines/enterprise-application-technical-baseline-v0-0-4.md

@@ -12,49 +12,49 @@
 
 | 项目 | 当前内容 |
 | --- | --- |
-| 文档版本 | v0.0.4，2026-10-22；当前分发规约，工程目录规范与采用说明统一为1.0.0 |
-| 文档性质 | 根据使用者逐项确认整理的企业共用技术基线；供具体项目明确选用，新稿文字仍可人工审阅修改 |
-| 适用范围 | 明确采用本文件的企业业务项目及其前端、业务后端、Agent、任务工程；各工程按实际需求采用 |
-| 项目绑定 | 本文件不绑定某一业务项目；项目名称、采用版本、PRD／AD与实际工程在项目采用说明或AD中记录，见 Q01、Q12 |
+| 文档版本 | v0.0.4，2026-10-22；当前分发规约，工程目录规范基线为1.0.0 |
+| 文档性质 | 根据使用者逐项确认整理的企业共用技术基线；作为 i3-enterprise-sop 生成 AD的默认技术输入，项目明确规约优先；新稿仍可人工审阅修改 |
+| 适用范围 | 使用本 Skill默认规约或明确采用本文件的企业业务项目及其前端、业务后端、Agent、任务工程；各工程按实际需求采用 |
+| 项目绑定 | 本文件不绑定某一业务项目；项目名称、采用版本、PRD／AD与实际工程在AD来源与采用表中记录，见 Q01、Q12 |
 | 直接来源 | 软件架构设计 Specification 模板 v0.6（2026-09-23），含原文明确的技术方向及工程约束 |
 | 编排依据 | 当前企业 SOP 的公共技术规约模板、AD 模板及交接合同；工程组织引用现有目录规范1.0.0 |
 | 确认依据 | 2026-10-20确认原有共用规则；2026-10-21确认将推荐版本矩阵补入规约，K8s暂按既有1.28记录。确认技术选择不等于授权升级、安装、部署或通过兼容验收 |
 | 维护与采用 | 共用规则及选型方向按上述确认维护；具体项目仍需记录采用版本、适用范围、责任和例外，不由本轮确认替代业务认可或开工许可 |
 | 现有证据 | 已核官方版本／依赖要求及本机工具；已完成Dapr 1.18.7针对K8s 1.28的三组离线Helm渲染。版本矩阵已明确；尚无目标集群连接、工程安装／构建及完整联调证明，见§2.3—§2.6 |
 
-本文件定位为可复用的企业共用技术基线，已写入确认的选型方向与共用约定。第8节分别记录“已经确认的规则”和“项目仍需落实的事实”，不能把版本、环境或运行结果自动标成已验证。项目明确选用后，AD准确引用本文件路径、文内版本及适用条款；按影响起草和交接，不要求所有项目事实先清零。
+本文件定位为可复用的企业共用技术基线，已写入确认的选型方向与共用约定。第8节分别记录“已经确认的规则”和“项目仍需落实的事实”，不能把版本、环境或运行结果自动标成已验证。生成AD默认带入本文件时，在AD准确记录其路径、文内版本及适用条款；项目另有明确规约则优先沿用；按影响起草和交接，不要求所有项目事实先清零。
 
-本文件是业务项目的技术资料，不是 i3-composer-agent 工具自身的运行规范，也不作为所有标准流程或所有企业 SOP 项目的安装默认。项目已有适用规范时，优先核对其权威范围，避免建立第二份相互冲突的规约。
+本文件是业务项目的技术资料，不是 i3-composer-agent 工具自身的运行规范。显式使用 i3-enterprise-sop生成AD时默认带入，单独安装或标准流程不自动启用；项目已有明确规范时优先沿用，避免建立第二份相互冲突的规约。
 
 ### 0.1 来源与整理边界
 
 | 来源 | 本次使用内容 | 整理后的维护位置 |
 | --- | --- | --- |
 | 软件架构设计 Specification 模板 v0.6，第 3—4 章 | 架构边界、已明确技术方向、按需选型、版本与兼容要求 | 本文件第 1—2 节 |
-| 同一来源，第 6—11 章 | 数据、接口、前端、Agent、集成、权限及恢复的共用约束 | 本文件第 1、3—5 节；主题接口、实体和流程由各 AD 详设 |
+| 同一来源，第 6—11 章 | 数据、接口、前端、Agent、集成、权限及恢复的共用约束 | 本文件第 1、3—5 节；各PBC的接口、实体和流程由各 AD 详设 |
 | 同一来源，第 12—17 章及附录 | 工程质量、环境、流水线、实施交接、验证与未决事项 | 本文件第 6—9 节 |
 | 使用者本轮逐项确认（2026-10-20） | 共用基线定位、Java／Spring Boot、前端工具链、MaxKey／OIDC、接口惯例、目录采用、部署分工及按项目落实的规则 | 对应第2—9节；不扩展为版本兼容、业务批准或实际环境就绪 |
 | 2026-10-21官方资料核对、本机只读检查与使用者确认 | 固定首套版本选择、保留K8s 1.28及现有GitLab；记录兼容范围与真实验证边界 | 本文件§2.3—§2.6及Q02—Q06、Q09；不自动执行升级或替项目采用 |
-| [公共技术规约模板及采用说明](../readme.md) | 已有规范优先、公共规则与主题设计分工、候选与真实采用分开 | 本文件的范围、采用和版本规则 |
-| [当前 AD 模板](../../ad/templates/ad.md) §0.3、§2.2、§9.6 | 基线引用、技术落实和真实骨架来源 | 各主题 AD 的对应条款 |
-| [当前交接合同](../../handoff-contract.md) §10 | 选定 AD 及必要配套交原 Plan，再进入获准 Build | 本文件第 9 节 |
-| [目录规范1.0.0](../../engineering-skeleton/directory-standard.md)、[采用说明1.0.0](../../engineering-skeleton/adoption.md) | 工程目录与职责、AD映射、原Plan任务路径、获准Build的实际文件落点 | 本文件第1、6—9节；目录规范可先采用，不要求预先取得代码框架模板 |
-| [原Ship命令](../../../../../.claude/commands/i3-ship.md)及[原Spec的内容要求](../../../../i3-spec-driven-development/SKILL.md) | 发布前检查／决策／回滚，及原SPEC六项的工程命令和项目依据 | 本文件第6—7、9节；原命令与Skill未改 |
+| [公共技术规约资料](../readme.md) | 已有规范优先、公共规则与PBC设计分工、候选与真实采用分开 | 本文件的范围、采用和版本规则 |
+| [当前 AD 模板](../../templates/ad.md) §0.3、§2.2、§9.6 | 基线引用、技术落实和真实骨架来源 | 各PBC的 AD 的对应条款 |
+| [本 Skill 工程交接说明](../../../SKILL.md) 中的 T2／T3 | 选定 AD及必要配套形成工程 SPEC，再交原 Plan及获准 Build；原命令等效规格方式保留 | 本文件第9节及本 Skill T2／T3；具体技术规则未改 |
+| [目录规范1.0.0](../../engineering-skeleton/directory-standard.md) | 工程目录与职责、AD映射、原Plan任务路径、获准Build的实际文件落点 | 本文件第1、6—9节；目录规范可先采用，不要求预先取得代码框架模板 |
+| 原Ship命令及原Spec的内容要求（通过实际宿主发现；[调用边界](../../../SKILL.md)） | 发布前检查／决策／回滚，及原SPEC六项的工程命令和项目依据 | 本文件第6—7、9节；原命令与Skill未改 |
 
-源材料沿用总体 `design.md` 和旧 MVP 产物组织。本文件只提取其中适用的技术内容，并按当前已确认的“公共规约＋多主题 PRD／AD”组织；不恢复旧 MVP 流程，不改动源文件，不要求把公共规则复制到每份 AD。原文要求明确写出规则的目的继续保留：AD 必须指出准确规则、适用范围和落实位置，不能只写“沿用旧规范”。
+源材料沿用总体 `design.md` 和旧 MVP 产物组织。本文件只提取其中适用的技术内容，并按当前已确认的“公共规约＋各PBC的一套PRD／AD”组织；不恢复旧 MVP 流程，不改动源文件，不要求把公共规则复制到每份 AD。原文要求明确写出规则的目的继续保留：AD 必须指出准确规则、适用范围和落实位置，不能只写“沿用旧规范”。
 
-本规约保留已确认技术条款及其来源说明，仅分发当前版本；工程组织统一采用同一SOP Skill内的1.0.0目录规范与采用说明。来源材料或发行资源后续修改，不自动改变项目已经采用的版本。
+本规约保留已确认技术条款及其来源说明，仅分发当前版本；工程组织统一采用同一SOP Skill内的1.0.0目录规范，采用信息由AD现有表格记录。来源材料或发行资源后续修改，不自动改变项目已经采用的版本。
 
 ## 1. 共用架构与工程边界
 
-| 条款 | 共用规则 | 主题 AD 的落实责任 |
+| 条款 | 共用规则 | PBC的 AD 落实责任 |
 | --- | --- | --- |
-| ARC-01 | 根据真实业务目标确定逻辑模块、工程、运行应用和部署单元；一个 PBC 不自动等于一个微服务、仓库或数据库 | 明确本主题组件职责、依赖、运行单元和部署关系，以及采用或拆分理由 |
+| ARC-01 | 根据真实业务目标确定逻辑模块、工程、运行应用和部署单元；一个 PBC 不自动等于一个微服务、仓库或数据库 | 明确本PBC的组件职责、依赖、运行单元和部署关系，以及采用或拆分理由 |
 | ARC-02 | 前端负责交互与呈现；业务服务负责正式业务规则、最终授权、状态及数据；Agent 负责其获准的分析或工具执行；任务工程负责实际选择的触发、执行与恢复职责 | 给出三图和详设，绑定实际组件及数据维护责任；按需采用工程类型，不为凑目录新增服务 |
 | ARC-03 | 前端临时状态、Agent 会话或执行结果、工作流历史、任务状态与正式业务状态分别维护 | 写清各类状态的存储、可信来源、标识映射及最终业务完成条件 |
 | ARC-04 | Dapr 的运行支撑能力与项目业务授权、数据责任及人工决定分开设计 | 明确所用能力、组件、调用方向、业务校验和失败责任；服务能够互通不代表用户获准操作 |
 | ARC-05 | 缓存、向量检索、消息、GIS、三维、多 Agent 等按实际需求选择 | 给出需求来源、用途和选型；不使用时说明理由，未知时列为待确认 |
-| ARC-06 | 消费外部能力应依据正式契约，不复制提供方内部实现作为本主题权威 | 固定提供／消费关系和版本；分别记录已可用、待核实、待接入及真实联调条件 |
+| ARC-06 | 消费外部能力应依据正式契约，不复制提供方内部实现作为本PBC权威 | 固定提供／消费关系和版本；分别记录已可用、待核实、待接入及真实联调条件 |
 
 来源：软件技术说明第3、5、8—11章；现有工程骨架目录方案及目录规范1.0.0的职责分工。
 
@@ -136,7 +136,7 @@ Java若实际采用Spring集成，候选坐标为`io.dapr.spring:dapr-spring-boo
 | GitLab Runner | 19.2.x，实际补丁待核 | 与GitLab主／次版本匹配；未取得实例信息前不编造精确补丁号或可用Runner |
 | Docker Desktop | 本机4.70.0 | 4.96.0作为另行评估的更新候选；本轮未启动Docker或升级。CLI版本不证明实际运行的Engine版本 |
 | Helm及集群部署工具 | 项目实际工具待选择 | 研究中临时使用的Helm 3.19.0不是项目默认工具，也不构成本机全局安装事实 |
-| 工程骨架 | 统一采用本SOP Skill内的目录规范／采用说明1.0.0 | 按本次确认统一来源；项目既有采用不自动升级，先核差异、适用范围及真实工程映射。目录规则不等于可运行代码模板 |
+| 工程骨架 | 统一采用本SOP Skill内的目录规范1.0.0 | 按本次确认统一来源；项目既有采用不自动升级，先核差异、适用范围及真实工程映射。目录规则不等于可运行代码模板 |
 
 ### 2.4 已取得的环境事实与K8s兼容边界
 
@@ -209,7 +209,7 @@ PostgreSQL已定位的是Homebrew libpq 18.3工具。在已查常见路径、进
 
 ### 4.1 已确认的接口与数据惯例
 
-| 范围 | 共用约定 | 项目及主题AD补充内容 |
+| 范围 | 共用约定 | 项目及PBC的AD补充内容 |
 | --- | --- | --- |
 | API字段命名 | 本项目自有API字段使用camelCase | 外部契约或既有系统沿用其真实定义，适配处写明映射与例外 |
 | 数据库字段命名 | 本项目新建数据库字段使用snake_case | 保留存量字段，具体表名、约束、索引及schema按工程实际明确 |
@@ -234,9 +234,9 @@ PostgreSQL已定位的是Homebrew libpq 18.3工具。在已查常见路径、进
 | AGT-03 | 模型、Prompt、工具描述与流程版本分别追踪；不能暗中替换模型。知识检索、记忆和多 Agent 按需设计，资料与工具返回不能修改系统权限 |
 | AGT-04 | 定义模型／工具调用、Token、时长、并发和循环预算，以及超限、取消和人工处理行为；具体数值依据业务和工程事实，不能由模板填造 |
 
-来源：软件技术说明第 7、9、10 章。具体业务接口、事件、工具和模型尚未提供；它们属于对应主题 AD 及正式契约的后续设计内容。
+来源：软件技术说明第 7、9、10 章。具体业务接口、事件、工具和模型尚未提供；它们属于对应PBC的 AD 及正式契约的后续设计内容。
 
-## 5. 数据、状态与跨主题责任
+## 5. 数据、状态与跨PBC责任
 
 - DATA-01：每项正式业务实体、共享字段、状态及共享文件明确唯一逻辑维护责任与受控读写边界。共用数据库实例不代表允许跨模块任意读写。
 - DATA-02：业务数据、执行历史、Agent 会话、缓存和检索索引分别说明权威来源、保存范围、过期语义、恢复及清理责任；临时或派生数据不能冒充正式结果。
@@ -245,23 +245,23 @@ PostgreSQL已定位的是Homebrew libpq 18.3工具。在已查常见路径、进
 - DATA-05：状态迁移、终态、撤销、重开、删除和保留要求来自 PRD 及实际项目决定；不能用技术规约新增权限、删除能力或保留期限。
 - DATA-06：索引根据真实查询和数据特征设计，并核写入及维护成本；迁移、初始化、回填、备份、应用回滚和数据恢复分别说明。
 
-命名、跨端大整数标识、时间点和错误关联的共用惯例按§4.1执行。主键生成、审计字段、实际时区／格式、删除方式和保留期按项目与业务依据落实，见Q07、Q10；具体实体及提供／消费责任从选定PRD和主题AD形成，见Q12，不要求提前填入通用规约。来源：软件技术说明第6—7、9、11、13章、当前AD模板及使用者确认。
+命名、跨端大整数标识、时间点和错误关联的共用惯例按§4.1执行。主键生成、审计字段、实际时区／格式、删除方式和保留期按项目与业务依据落实，见Q07、Q10；具体实体及提供／消费责任从选定PRD和PBC的AD形成，见Q12，不要求提前填入通用规约。来源：软件技术说明第6—7、9、11、13章、当前AD模板及使用者确认。
 
 ## 6. 工程组织、质量与原方法衔接
 
 ### 6.1 工程骨架与文件责任
 
-- ENG-01：工程骨架沿用现有[目录规范1.0.0](../../engineering-skeleton/directory-standard.md)和[采用说明1.0.0](../../engineering-skeleton/adoption.md)。`pbc-composite`与`agent-standalone`是组织方式，frontend、backend、agents、jobs及配套契约、共享代码、测试和交付位置按需采用；内部遵循实际语言／框架惯例。
+- ENG-01：工程骨架沿用现有[目录规范1.0.0](../../engineering-skeleton/directory-standard.md)。`pbc-composite`与`agent-standalone`是组织方式，frontend、backend、agents、jobs及配套契约、共享代码、测试和交付位置按需采用；内部遵循实际语言／框架惯例。
 - ENG-02：目录规范是实际可读的设计输入，可以在工程创建前采用。AD记录规范来源／版本、业务项目根、已有／拟建工程和模块映射；未采用代码框架模板时如实说明，不要求预先取得企业代码模板或冻结首套完整技术栈。
 - ENG-03：AD §9.2明确源码、模块、配置、测试、契约及装配位置，§9.6说明已有工程与拟建内容；原Plan把预计新增／修改文件路径、依赖和验证写入任务；获准的Build在这些位置生成实际内容，核对文件落点并执行原有测试／构建。
-- ENG-04：共享底座、契约和文件只有一处维护责任及实际任务来源，其他主题引用依赖；新增 PRD 不自动复制底座。再次生成或更新时保留人工修改、历史及已完成任务，冲突先核范围。
+- ENG-04：共享底座、契约和文件只有一处维护责任及实际任务来源，其他PBC引用依赖；新增 PRD 不自动复制底座。再次生成或更新时保留人工修改、历史及已完成任务，冲突先核范围。
 - ENG-05：目录规范不要求另建project.yaml、templates.lock、contracts.lock、生成记录库或代码模板三方升级流程。已有项目或工具确有这些文件时按其实际用途保留；项目另行要求复用特定代码模板时，才取得该模板及所需版本、应用和验证依据。
 
 可以在现有AD的骨架栏目写明“目录规范已采用；工程拟建；未采用代码框架模板”，不能据此声称“可运行代码模板已取得”或“代码已生成”。实际目录来源为本资源附带的1.0.0定版资料；资源目录和i3维护工作区均不是业务工程输出根。
 
 既有工程先映射实际目录，不为套规范移动或重建。实际有内容时再建所需位置；项目根的构建／CI配置与框架原有布局允许按实情保留。目录检查、代码存在、构建、启动、业务验证和发布分别取证。
 
-来源：现有工程骨架目录方案、目录规范／采用说明1.0.0，以及当前AD §9.2／§9.6的对应栏目。本轮只引用这些资源，不修改工程骨架工作树或SOP运行模板；原命令的读取与实际落点继续按对应工程验证任务取证。
+来源：现有工程骨架目录方案、目录规范1.0.0，以及当前AD §9.2／§9.6的对应栏目。本轮只引用这些资源，不修改工程骨架工作树或SOP运行模板；原命令的读取与实际落点继续按对应工程验证任务取证。
 
 ### 6.2 工程命令与编码规范
 
@@ -289,7 +289,7 @@ PostgreSQL已定位的是Homebrew libpq 18.3工具。在已查常见路径、进
 
 ## 7. 版本兼容、交付与恢复
 
-- DEL-01：文档、正式契约、代码提交、依赖、制品、配置和运行环境分别定位版本；不强制所有主题 PRD／AD 同号，也不机械升级无关主题。
+- DEL-01：文档、正式契约、代码提交、依赖、制品、配置和运行环境分别定位版本；不强制所有PBC的 PRD／AD 同号，也不机械升级无关PBC。
 - DEL-02：GitLab 实例、仓库、保护规则、MR、Runner、CI 模板、镜像库、变量及环境权限按实际资源填写。设计方案、资源存在、配置完成和真实验证分开记录；企业 GitLab 方向不改动 i3 工具仓库自身的 GitHub 工作流。
 - DEL-03：流水线按项目实际组合变更检查、测试／评测、构建、迁移／部署、部署后验证及放行。每项明确触发、身份、输入、通过条件、失败处理和证据；本文件不宣称这些流水线已经存在。
 - DEL-04：K8s／Dapr 配置基于所选版本和实际需求确定工作负载、入口、运行身份、组件作用域、资源、探针、优雅退出、网络及密钥引用。端口、实例数和部署工具未定时不得猜测。
@@ -312,18 +312,18 @@ PostgreSQL已定位的是Homebrew libpq 18.3工具。在已查常见路径、进
 
 | 编号 | 已确认的共用处理 | 项目仍需落实的内容与影响 | 处理时点 |
 | --- | --- | --- | --- |
-| Q01 | 本文作为可复用企业技术基线，项目明确采用准确版本 | 项目名称、维护责任、范围和既有规范由项目采用说明／AD绑定；不在公共规约预造业务身份 | 实际项目采用时 |
+| Q01 | 本文作为可复用企业技术基线，项目明确采用准确版本 | 项目名称、维护责任、范围和既有规范由AD现有来源与采用表绑定；不在公共规约预造业务身份 | 实际项目采用时 |
 | Q02 | 首套普通业务后端采用Java＋Spring Boot方向，与Python Agent分工 | §2.3已明确JDK／Boot／Maven／JDBC目标；核实际工程依赖、企业框架复用、启动及序列化，不将版本确认写为兼容已通过 | 相关详设和工程任务按依赖核实 |
 | Q03 | 保留Vue 3＋TypeScript＋Antdv Next，工具链采用Vite、类型检查和Vitest方向 | §2.3已明确首套前端版本；核实际依赖／锁文件，按需引入路由／状态管理，安装／类型／构建／测试结果仍待验证 | 初始化及依赖安装前核实，生成后验证 |
 | Q04 | Dapr／Agent按实际需要的能力建立组合版本和验证安排 | 按§2.3固定所用版本；在保留的K8s 1.28上验证实际安装、必要业务链、中断恢复、重复与授权失效，离线渲染不替代运行证据 | 依赖相关能力的设计／工程阶段分别核实 |
 | Q05 | PostgreSQL优先兼容企业已有受支持版本，逻辑责任与恢复分别设计 | 先定位已有服务端；17.11仅是无既有约束的新建候选，驱动42.7.14已定，扩展／实例／迁移／DDL／恢复仍须真实证据 | 数据工程设计、迁移及运行前 |
 | Q06 | 统一身份采用MaxKey，通过OIDC接入；业务服务执行最终授权 | 4.1.12为首轮接入基线，投产前核4.2.0安全更新；取得实际实例／类型、应用注册、映射、退出撤权及配置引用，不虚构claims或可用能力 | 身份相关契约和实现前 |
-| Q07 | API camelCase、数据库snake_case、跨端大整数ID字符串、明确时间点时区、稳定业务码与关联标识 | 正式契约补精确字段、分页上限、格式／精度、主键生成、审计及存量映射，避免擅改已有契约 | 相关公共契约及主题AD定稿前 |
-| Q08 | 引用现有目录规范／采用说明1.0.0，沿用原AD→Plan→Build的目录映射链 | 明确业务根及真实／拟建路径；目录规范可先采用，实际代码由获准Build生成验证；只有另行要求特定代码模板才须取得该模板 | AD映射、Plan任务文件路径、Build实际落点依次核对 |
+| Q07 | API camelCase、数据库snake_case、跨端大整数ID字符串、明确时间点时区、稳定业务码与关联标识 | 正式契约补精确字段、分页上限、格式／精度、主键生成、审计及存量映射，避免擅改已有契约 | 相关公共契约及PBC的AD定稿前 |
+| Q08 | 引用现有目录规范1.0.0，沿用原AD→Plan→Build的目录映射链 | 明确业务根及真实／拟建路径；目录规范可先采用，实际代码由获准Build生成验证；只有另行要求特定代码模板才须取得该模板 | AD映射、Plan任务文件路径、Build实际落点依次核对 |
 | Q09 | AD规定部署要求，Plan安排任务，Build形成配置，Ship核验汇总部署准备 | K8s 1.28和GitLab 19.2.4为使用者提供的环境；补完整集群信息、Runner及实际资源／权限／配置，部署资料不冒充平台已就绪 | 构建、联调、部署和发布按需落实 |
 | Q10 | 保留已有质量下限，新增指标从PRD或真实工程决定取得 | 质量、容量、恢复、预算、保留、告警与适用要求的具体值和测量方法属于项目；不得填造通用数字 | 对应测试设计、处理数据或放行前 |
 | Q11 | 根据实际情况填写各工程命令、cwd、前提、成功依据和风格 | 已有工程读取真实配置；新工程按任务创建并验证，未验证保持实际状态；不要求用户预先写假命令 | 本次规划与任务执行按依赖补足 |
-| Q12 | 具体业务主题及数据／契约责任从选定PRD和各主题AD形成 | 绑定实际接口、事件、工具、实体和提供／消费方；不把它们作为通用规约必须提前填完的内容 | 每个主题AD与必要关联契约设计时 |
+| Q12 | 具体PBC及数据／契约责任从选定PRD和各PBC的AD形成 | 绑定实际接口、事件、工具、实体和提供／消费方；不把它们作为通用规约必须提前填完的内容 | 每个PBC的AD与必要关联契约设计时 |
 
 上述共用规则及处理方式不再保持“全部待确认”。项目采用、具体版本、配置和运行结果仍需各自真实依据，不能因使用者同意规则就自动关闭。缺项只限制依赖它的范围，不无差别阻断AD起草或不相关的准备任务；也不能因文档生成完成而填造工程结果。
 
@@ -333,35 +333,35 @@ PostgreSQL已定位的是Homebrew libpq 18.3工具。在已查常见路径、进
 
 ### 9.1 进入 AD
 
-1. 在具体业务项目明确采用本规约的路径、版本和适用范围；先核已有规范及冲突，不凭安装或发现文件自动启用。
-2. 选定准确 PRD 主题和版本。起草／修订 AD 必须按企业入口加载原 Spec Skill，使用完整 AD 模板；本公共规约本身不替代主题规格。
-3. AD §0.3登记本规约及目录规范／采用说明的来源和版本，§2.2落实技术选择，§9.2映射工程及模块位置，§9.6区分现有工程和拟建内容；目录规范可在代码生成前采用，保留三图和全部详设责任。
+1. 使用 i3-enterprise-sop生成AD时，项目未另有明确规约就默认读取本规约和目录规范，在AD记录路径、版本及范围；已有明确规约优先，冲突先说明。
+2. 选定PBC的准确PRD和版本。起草／修订 AD 必须按企业入口加载原 Spec Skill，使用完整 AD 模板；本公共规约本身不替代PBC规格。
+3. AD §0.3登记本规约及目录规范的来源和版本，§2.2落实技术选择，§9.2映射工程及模块位置，§9.6区分现有工程和拟建内容；目录规范可在代码生成前采用，保留三图和全部详设责任。
 4. 原型按需，可与 AD 并行。记录假设和受影响未决；候选生成、完整回读和人工认可分别处理，保存后遵守原 Spec 停轮。
 
-以下任务在项目明确取得并采用本版规约后使用；资料由实际加载的SOP Skill的references及辅助清单定位，不要求使用者填写安装内部路径。文件存在不证明项目已采用，已有安装不被假定包含本地候选：
+以下是明确委托本 Skill生成AD的任务示例；默认资料从本Skill直接定位，项目明确规约优先，不要求用户填写安装内部路径：
 
 ```text
-/i3-sop ad
-本次采用我明确提供的《企业应用公共技术规约 v0.0.4》作为公共技术依据；按本次选定SOP Skill资源索引定位。
-先确定当前业务项目、我已选定的 PRD 主题和准确版本；存在歧义先问。
-实际读取这份规约、其引用的工程目录规范／采用说明1.0.0及本次必要来源，列出适用条款、已有规范冲突和影响本主题的项目缺口。
-按原 Spec Skill 和完整 AD 模板生成本主题设计，保留三图、工程细节和 SPEC 六项。
+使用 i3-enterprise-sop 的 ad 动作。
+将自带《企业应用公共技术规约 v0.0.4》和目录规范作为默认输入；项目已有明确规约时优先沿用。
+先确定当前业务项目、我已选定PBC的PRD和准确版本；存在歧义先问。
+实际读取这份规约、其引用的工程目录规范1.0.0及本次必要来源，列出适用条款、已有规范冲突和影响本PBC的项目缺口。
+按原 Spec Skill 和完整 AD 模板生成本PBC设计，保留三图、工程细节和 SPEC 六项。
 沿用§2.3已确认的版本矩阵，保留既有K8s 1.28与GitLab 19.2.4；逐项区分目标与实装，未验证的兼容性、具体字段和工程映射按实际来源补足。
-按现有目录规范明确本主题源码、模块、配置、测试和契约的已有／拟建位置，不要求预先提供一套代码框架模板，也不宣称工程已生成。
+按现有目录规范明确本PBC源码、模块、配置、测试和契约的已有／拟建位置，不要求预先提供一套代码框架模板，也不宣称工程已生成。
 保留已有人工修改，回读最终稿，交我审阅后停轮，不进入 Plan 或 Build。
 ```
 
 ### 9.2 交原 Plan
 
-以选定AD为入口，读取其准确PRD、本规约适用条款、共享契约、目录规范／项目采用说明和已有代码；尚无代码时如实记录拟建，不虚构工程根。按主题加载完整必要内容，核本范围SPEC六项和FR／AC；Plan任务保留真实／拟建文件路径及验证依据，不全量注入无关AD和历史。
+以选定AD为入口，读取其准确PRD、本规约适用条款、共享契约、目录规范及AD工程映射和已有代码；尚无代码时如实记录拟建，不虚构工程根。按PBC加载完整必要内容，核本范围SPEC六项和FR／AC；Plan任务保留真实／拟建文件路径及验证依据，不全量注入无关AD和历史。
 
-可以手动给实际路径，不必先建立 JSON。用户明确选用并允许登记时，现有清单只在 `selected.technicalBaseline` 保存本规约的实际路径，主题 AD 保存于相应主题引用；清单仍只保留 `schemaVersion`、`scope`、`selected`。本次没有建立或改写业务 JSON，也不把文档完成视为已选用或已批准。
+本规约的来源标识、准确路径或URL、文内版本或固定提交、适用条款、采用范围与例外、实际读取及缺口，统一记录在AD §0.3；工程映射与实际模板／骨架来源由AD §9.6承接。后续工程SPEC／Plan沿AD引用读取准确原件，不再将规约路径或采用信息写入 `handoff.json`，也不另建采用说明。`handoff.json`仅记录EBC／PBC身份及已选BRD／PRD／AD／TestCase文档路径，PBC的AD仍按相应文档角色登记。可以手动给出准确路径，不强制创建清单；引用或登记不证明已读，也不表示文档获批。
 
 ```text
 /i3-plan
-以我本轮明确选定的AD为规划入口，实际读取它引用的PRD、公共技术规约适用条款、共享契约、工程目录规范／采用说明及已有代码。
-公共技术规约使用本次明确采用的准确路径和版本，不仅凭清单存在判断已读。
-核对本主题需求、验收条件、SPEC 六项、共享依赖和未决影响；TestCase 按需引用。
+以我本轮明确选定的AD为规划入口，实际读取它引用的PRD、公共技术规约适用条款、共享契约、工程目录规范及已有代码。
+公共技术规约按AD §0.3采用记录中的准确路径、文内版本及适用条款回读，不以AD引用或清单存在代替正文读取；规约采用信息不写入handoff.json。
+核对本PBC需求、验收条件、SPEC 六项、共享依赖和未决影响；TestCase 按需引用。
 按AD的工程／模块映射，将每项任务预计新增或修改的文件路径、真实来源、初始化或增量内容及验证依据保留在原计划和唯一任务目标中，交我审阅，暂不实施。
 ```
 
@@ -373,8 +373,8 @@ PostgreSQL已定位的是Homebrew libpq 18.3工具。在已查常见路径、进
 
 ### 9.4 本次交付结论
 
-本版保留2026-10-20／21确认的共用规则、技术版本矩阵、本机及既有平台事实、官方依据与V01—V06验证安排，并按2026-10-22确认将工程目录及采用说明统一为1.0.0。Q02—Q06、Q09区分已选择版本与仍待取得的环境／运行证据；其他已确认规则保留。K8s 1.28继续保留，三组Dapr离线渲染不作为真实集群通过证明。
+本版保留2026-10-20／21确认的共用规则、技术版本矩阵、本机及既有平台事实、官方依据与V01—V06验证安排，并按2026-10-22确认采用工程目录规范1.0.0，本副本的采用信息直接由AD记录。Q02—Q06、Q09区分已选择版本与仍待取得的环境／运行证据；其他已确认规则保留。K8s 1.28继续保留，三组Dapr离线渲染不作为真实集群通过证明。
 
-本文件可供人工审阅，并可在明确选用后作为 AD 的公共输入。它不证明某项目的整体技术设计已经批准，也不证明所有主题可交 Plan、可直接 Build 或已通过运行验收。
+本文件可供人工审阅，并可在明确选用后作为 AD 的公共输入。它不证明某项目的整体技术设计已经批准，也不证明所有PBC可交 Plan、可直接 Build 或已通过运行验收。
 
 版本记录：v0.0.4（2026-10-22）统一SOP Skill内的工程目录来源1.0.0及资源引用，技术选型、版本矩阵和验证边界保留。通用模板、AD模板、原版Skill／命令、已有UI原型能力与业务稿未改。未执行技术栈安装、升级、部署或npm发布，i3发行版本未调整。

package/skills/i3-enterprise-sop/references/technical-baseline/readme.md

@@ -1,4 +1,4 @@
-# 公共技术规约：采用说明
+# 公共技术规约资料
 
 <!-- i3:zh-guide:start -->
 ## 中文使用说明
@@ -8,125 +8,16 @@
 默认使用简体中文解释、追问及生成报告；用户明确要求其他语言时可切换。原方法正文、引用、阈值和审批条件完整保留。代码标识、路径、命令、工具参数、JSON 键/枚举与原文引用保持原样。
 <!-- i3:zh-guide:end -->
 
-资源版本：0.4.0；通用模板内容版本：v0.0.1；可选企业应用技术规约：v0.0.4；引用同一SOP Skill内的工程目录规范／采用说明1.0.0。发行只保留当前资源，不附旧版或归档副本。当前本地候选的打包、安装及真实宿主行为分别验证，暂不发布。
+生成 AD 时，默认完整读取本目录的企业应用具体规约和工程目录规范，作为技术与结构输入；项目已明确采用自己的规约或目录约定时优先沿用其实际版本。来源、版本、适用范围和工程映射直接记在 AD §0.3、§9.6，不要求另写采用说明。
 
-本资源帮助项目固定共用工程约束及其来源。已有规范优先，新项目缺少规范时才起草最小候选。它不是第五个业务阶段、总AD、项目配置或批准记录；不新增Skill、命令、路由和执行器。
-
-## 0. 模板与可选技术规约
-
-| 资料 | 用途与采用边界 |
+| 文件 | 用途 |
 | --- | --- |
-| [公共技术规约模板](templates/technical-baseline.md) v0.0.1 | 根据项目真实资料起草规约，或核对已有规范的覆盖；不默认技术栈 |
-| [企业应用公共技术规约](baselines/enterprise-application-technical-baseline-v0-0-4.md) v0.0.4 | 保留已确认的技术条款、版本矩阵和环境／验证边界；统一引用同一Skill内的工程骨架1.0.0，项目明确选择后才生效 |
-| [工程目录规范与采用说明](../engineering-skeleton/readme.md) 1.0.0 | 与本规约引用同一份资料；提供工程职责及AD→Plan→Build映射规则，不是可运行代码模板 |
-
-随包提供不等于所有项目默认采用。项目已有适用规范时先复用；选择本规约时记录准确路径、文内版本、适用范围及必要差异。多个版本或来源并存且未明确选择时先确认，不按目录最大版本猜选。
-
-项目需要调整时，沿用项目现有规范位置或明确维护项目副本；发行原件与项目规范分别定位。项目自改副本优先，不用发行摘要恢复它，不在升级时覆盖项目规范；不可读或存在冲突时如实报告，不静默切换。
-
-最短任务示例：
-
-```text
-/i3-sop ad
-为当前选定的PRD生成AD，采用我明确提供的《企业应用公共技术规约 v0.0.4》。先核项目已有规范和适用范围，按本次资源目录定位并完整读取规约及必要目录资料；版本以规约§2.3为准，兼容验证按§2.5安排，保留项目自改内容和未决项，生成后交我审阅，暂不进入Plan或Build。
-```
-
-资料由本次实际加载的SOP Skill的references/stages.json中auxiliaryResources定位，再读取本清单baselines条目，不要求使用者填写安装内部路径。当前候选是否可用以实际安装内容为准；项目自改资料不被发行来源替换。原版Skill／命令和标准流程保持。
-
-## 1. 先核对来源，再选择采用方式
-
-只在用户明确采用企业SOP或明确要求本项技术资料任务时使用。安装、出现PRD字样或发现本文件，不代表项目已启用企业SOP；标准任务继续使用原方法。
-
-先实际读取项目说明、明确提供的规范和已有采用记录；目录列表和自动上下文只能作线索。不扫描全部项目、宿主、历史样例或备份来猜规范。
-
-资源位置与项目规范来源分开判断：
-
-- 对本资源，实际读取本次选定目录的README、清单和所选模板；明确采用的项目自改副本优先，已选根不可读或损坏时报告缺项，不换发行原件或全局新版。
-- 对项目规范，优先复用项目已明确采用且适用的集团／平台／工程规范、CONSTRAINTS、ADR及正式契约。已有代码和锁文件提供实现事实，不自动成为替换规范的决定。
-- 用户本次明确材料与既有采用发生冲突时，同时保留并核对适用范围；本次提供文件不自动授权覆盖原规范、取消约束或切换全项目采用。
-- “规范未提供／未读取”与“项目确认没有规范”分开。不可读、无适用版本或存在冲突时，记录准确缺口及影响；不能从缺文件推断不存在。
-
-## 2. 路径一：已有适用规范
-
-1. 读已有规范及采用记录，固定可回读内容与本项目适用条款。可使用准确版本加固定提交、不可变快照或实际计算的摘要；未计算就明确说明。只有版本标签和可变链接不足以区分内容时，补固定依据。
-2. 用模板核对覆盖，沿用已有位置、身份和格式。内容已完整时，只在现有采用说明或本次唯一明确目标中记录引用及真实缺口；不复制全文、迁移文件或要求填一份同构大文档。
-3. 公共规则直接引用唯一权威。仅当实际存在项目特定约束时补充有来源的差异，注明维护位置和适用范围；有冲突先列Q，不悄悄覆盖。
-4. 记录本次AD如何引用这些规则的方式即可，不自动生成或修改AD。每份AD仍需自己的三图和完整工程设计。
-
-最小采用记录可以使用项目现有表格表达，无需新的registry：
-
-| 记录项 | 需要的实际内容 |
-| --- | --- |
-| 来源与固定内容 | 规范身份、权威位置、版本／固定提交或真实摘要、实际读取范围 |
-| 本次适用 | 项目／工程／主题范围、准确条款、实际采用依据；阅读不等于采用或批准 |
-| 落实与差异 | 项目补充或AD引用位置、例外及真实决定；无差异就直接引用 |
-| 项目本地修改 | 当前副本与发行来源分别记录；同名同版本改变后旧证据不自动沿用 |
-| 缺口与交接 | 未读、未知、冲突、需何答复、只影响哪些动作和独立可继续部分 |
-
-已有文件或人工修改先读并保留，不用发行摘要恢复项目副本。已有采用说明已足够时，可以只提出只读核对结果；是否写入及唯一目标由本次实际授权决定。
-
-## 3. 路径二：缺少规范时起草最小候选
-
-先确认已取得的项目事实与已查范围；未知保持Q。按模板涵盖共用架构、技术工程、身份安全、契约通则、共享数据、工程质量、交付恢复、维护例外八个领域。可以直接固定引用，不强制拆出八份文档或重复已有材料。
-
-沿用项目既有位置；没有约定时，可建议 `docs/engineering/{项目名称}-技术规约_v0.0.1.md` 作为共用辅助文档。建议路径不是已经存在、已采用或可覆盖的事实。核心业务文档的一能力一目录和主题命名保持。
-
-没有事实时，不默认框架、数据库、消息中间件、部署平台、权限、责任人、保留期限、质量数字或命令。项目已明确采用的公共平台约束应引用保留，准确版本和工程细节未取得时列Q，不重新选另一套默认。项目尚未建成时，命令、目录、风格示例和环境可以待定，不编造已运行证据。
-
-最小候选不要求全项目技术问题先清零。AD可先起草独立部分，原型按需并行；共同定义未决时，只限制依赖范围。交原Plan前补齐当前有效规格六项、依赖范围的共用定义和必要真实认可；Plan形成、获准逐任务Build及真实工程验收分别核对，不要求起草规范前已有构建通过。
-
-## 4. 规约、契约、AD与版本
-
-| 内容 | 唯一维护责任与交接 |
-| --- | --- |
-| 公共技术规约 | 维护共用原则或准确权威引用；不替代产品规则、CONSTRAINTS或ADR |
-| 正式接口／事件／数据定义 | 每项一个权威位置，字段与行为分担时明确范围；可先用提供方AD固定章节，不强制新协议或拆文件 |
-| 主题AD | 对应选定PRD完整设计，固定规范版本、条款、提供／消费契约及落实／例外；不包办另一主题PRD |
-| TestCase／实际报告 | 预期直接核PRD，技术判据核AD及契约；候选、真实执行和人工认可分开 |
-| 工程登记与锁 | 记录实际选择、正式采用、应用及验证事实；不另建架构权威或任务tracker |
-
-同一PBC多份主题PRD各自独立版本，每份配套逻辑AD及TestCase；文档不要求同号。规范版本、契约版本、代码／制品和环境分别固定。兼容核实际消费者、字段及语义、迁移和运行组合，不能靠版本号或Schema通过下结论。
-
-共享数据、状态及文件明确唯一逻辑维护责任与受控写入；前端、后端、Agent及jobs各自状态不能代替正式业务结果。具体角色、事务和数据保留必须有产品／规范依据。
-
-变更先固定旧／新内容及来源，定位直接和必要传递的契约、AD、AC、TestCase及真实任务，区分不受影响范围。人可人工修改、明确委托修订、有据不采纳或保持Q；不自动重写全项目、自动升版或承接旧批准。外部契约正式采用与模板实际应用并验证的锁分别留证，本作业不自动创建锁。
-
-## 5. 写入、审查与退出
-
-写前列明项目根、已读资料、已有规范／采用记录、固定来源、假设／Q、唯一目标和本次权限。先读现稿，保留人工内容和原报告；仅写明确获准目标，未知权限或覆盖风险时先说明。
-
-最后编辑后实际回读：新增要求逐条回查来源，规范与权限描述一致，逐表检查表头列数和列义。摘要、版本与内容相符，不要求文档写自身摘要。
-
-审查只标注问题、来源、位置、影响与建议，保留人工修改空间。只有真实独立新上下文才称独立审查，无隔离能力时提供新会话任务；自查不冒称独立。修订另行明确，不为清零代答业务或技术决定。
-
-完成后报告来源／目标、复用方式、补充与Q、实际验证和未执行事项，交人工审阅并停轮，不自动进入AD、Plan、Build、测试执行、提交或发布。
-
-## 6. 可复制任务说明
-
-可明确提供本资源目录或项目已采用副本，也可在明确企业任务后按[上层入口](../readme.md)及其索引定位本辅助资源。源码登记不等于宿主自动发现，以下均为明确任务，没有新增slash命令。
-
-已有规范：
-
-```text
-本次只做公共技术规约采用核对。使用我明确提供的公共技术规约资源，先实际读取该目录README、清单和模板，再读取当前项目说明、已有规范及采用记录。
-优先复用项目已采用规范，固定来源、内容与适用条款；已有资料完整时只记录引用和真实缺口，不复制一份新规范，不覆盖原规范或人工修改。
-写前说明事实、假设、未读取项和唯一获准目标。位置按项目已有约定选择；若存在歧义或覆盖风险，先说明，不新建另一套registry。
-不把阅读当采用、把采用当批准；冲突按影响保留Q，不自行改选型或权限。最后回读候选，新增要求逐条回源，权限描述一致，表格逐行核列数与列义。完成后交我审阅并停轮。
-```
-
-新项目或资料不足：
-
-```text
-本次只起草项目公共技术规约候选。先读取我明确提供的资源README、清单、模板及当前项目资料，确认已有规范、已查范围和未取得内容；如果找到适用规范，优先采用它。
-确实缺少规范时，按模板只写当前有依据的最小候选，可用固定引用代替重复正文。框架、版本、责任、权限、质量数字、命令和运行结果没有来源就列Q，不填默认答案。
-沿用项目已有位置和命名，只写本次明确的唯一目标，保护人工内容。草拟不冒充可计划或获准Build；每份主题AD仍须三图及完整设计，原型按需。
-最后实际回读，逐条核新增要求来源、权限一致性及表格列数／列义，列出缺口和未执行事项，交我审阅并停轮。原版技能和命令不动，不写AD、Plan、工程或测试结果，不提交发布。
-```
-
-## 7. 资源范围与后续接入
+| [企业应用具体规约](baselines/enterprise-application-technical-baseline-v0-0-4.md) v0.0.4 | 本 Skill生成 AD 的默认技术规约；项目明确资料优先 |
+| [工程目录规范](../engineering-skeleton/directory-standard.md) 1.0.0 | AD默认结构输入；约定工程职责和目录，不代表代码已创建 |
+| [通用技术规约模板](templates/technical-baseline.md) v0.0.1 | 没有可用具体规约时，根据项目真实资料起草规约候选 |
 
-本子目录包含采用说明、通用模板、唯一当前可选技术规约及局部清单。工程目录资料位于同一SOP资料根的engineering-skeleton，不复制到技术规约内部。entry、template、baselines[].path、files[].path及requiredSources[].path均相对本manifest；依赖可在所选SOP根内引用，不能越界。
+具体规约缺失、不可读或不适用时，先提示用户按通用模板生成，说明已有材料、缺口和建议目标。取得技术文档写入委托后起草并交审，用户确认后继续 AD；不用空模板充当技术规约，不编选型、版本、权限或运行结果，不要求用户另启一个入口。
 
-上层stages.json登记辅助资源根与清单，局部baselines条目列出可选规约的身份、版本和必要来源；不设置默认采用，不增加配置系统、审批字段或自动调度。清单的文件摘要固定发行资料，本轮变化检查不用于恢复或覆盖项目副本。
+项目自改资料先读取并保留；已选来源失效或冲突时说明影响，不静默回退发行副本。默认作为 AD输入不等于已获业务批准、工程可运行或兼容验证通过，也不授权更改项目环境和代码。
 
-B01—B05和原S10记录保留各自版本与验证范围。本次只整理分发资源及引用，打包／安装可读性另取新证据；静态、安装、真实模型行为、项目采用与正式发布分别判断。原型仍按需，TestCase不作为Plan统一必需输入，原Spec及Plan／Build停点不变。
+本轮不重新核实原规约的官方版本、安装环境和兼容运行；原未验证条件继续保留，具体技术条款和版本矩阵不因目录整理改变。资源模板、具体规约和业务文档版本分别维护。

package/skills/i3-enterprise-sop/references/technical-baseline/templates/technical-baseline.md

@@ -14,7 +14,7 @@
 
 **候选和事实分开。** `{占位内容}`必须由真实来源替换；未确定的选型、版本、责任、权限、批准和运行结果保持待确认。已读、建议、项目明确采用、审查、认可及工程验证分别记录。真实证据未取得时，不填写已通过或自造摘要。
 
-**公共规则和主题设计分开。** 每份主题AD仍完整设计其选定PRD，保留技术架构、功能架构、ER三图及工程细节；本文件只维护公共约束或准确引用，不替代AD、CONSTRAINTS、ADR、正式契约或原Plan／唯一任务目标。
+**公共规则和PBC设计分开。** 每份PBC的AD仍完整设计其选定PRD，保留技术架构、功能架构、ER三图及工程细节；本文件只维护公共约束或准确引用，不替代AD、CONSTRAINTS、ADR、正式契约或原Plan／唯一任务目标。
 
 ---
 
@@ -36,7 +36,7 @@
 
 | 来源ID与权威位置 | 固定版本／提交／快照或实际摘要 | 适用条款与覆盖范围 | 本项目落实或补充位置 | 实际已读／采用依据与缺口 |
 | --- | --- | --- | --- | --- |
-| `{真实规范／CONSTRAINTS／ADR／契约等}` | `{可回读准确内容；无版本来源可用已保存内容的真实摘要}` | `{精确章节或规则ID}` | `{本文件必要补充或主题AD条款；不重复定义}` | `{读取及真实选择分别说明；不可读或未决定列Q}` |
+| `{真实规范／CONSTRAINTS／ADR／契约等}` | `{可回读准确内容；无版本来源可用已保存内容的真实摘要}` | `{精确章节或规则ID}` | `{本文件必要补充或PBC的AD条款；不重复定义}` | `{读取及真实选择分别说明；不可读或未决定列Q}` |
 
 来源未给出时记录“未提供／未读取”，不能推定其不存在。规范与实际代码有差异时，分别写清目标约束、已观察实现和缺口，不把实现偏差自动提升为已认可规范。单有版本号或可变链接不足以区分固定内容时，补固定提交、可回读快照或真实摘要。
 
@@ -46,7 +46,7 @@
 | --- | --- | --- | --- | --- |
 | `{项目实际工程或逻辑能力}` | `{共用原则；明确不负责范围}` | `{逻辑责任与受控写入边界}` | `{准确来源或待取得}` | `{已有／拟建／待核；不伪造已部署}` |
 
-前端的交互状态、服务端正式业务状态、Agent运行结果与jobs执行状态分别定义。只列项目实际需要的工程；PBC不自动等于微服务，单一责任不等于只能有一个操作人。若已有公共架构视图，固定引用适用条款；各主题AD仍须呈现自己的三图及完整设计。
+前端的交互状态、服务端正式业务状态、Agent运行结果与jobs执行状态分别定义。只列项目实际需要的工程；PBC不自动等于微服务，单一责任不等于只能有一个操作人。若已有公共架构视图，固定引用适用条款；各PBC的AD仍须呈现自己的三图及完整设计。
 
 ## 2. 技术与工程基线
 
@@ -58,7 +58,7 @@
 
 ## 3. 身份、安全与业务权限的实现约定
 
-| 共用事项 | 已有约定或必要候选 | 权威来源／适用范围 | 主题AD需要细化的内容 | 缺口与限制范围 |
+| 共用事项 | 已有约定或必要候选 | 权威来源／适用范围 | PBC的AD需要细化的内容 | 缺口与限制范围 |
 | --- | --- | --- | --- | --- |
 | `{身份／租户／服务身份／授权执行／审计／敏感数据}` | `{可信来源、执行边界、引用方式；未知列Q}` | `{真实业务权限和平台规范}` | `{具体接口、字段、拒绝行为及可观察结果}` | `{待答复内容，不代定权限}` |
 
@@ -83,7 +83,7 @@
 | --- | --- | --- | --- | --- |
 | `{实际对象；无信息不自建实体}` | `{BRD／PRD、正式数据定义或技术规则}` | `{唯一逻辑权威；受控操作可由多主体调用}` | `{真实读取／修改边界、时间点及来源}` | `{条件、事务、结果未知与恢复；未定列Q}` |
 
-共享业务状态、只读快照、前端临时状态、Agent运行状态及jobs状态不能互相冒充。并发动作由权威边界执行最终校验，不以“先查后写”代替一致性设计。共用底座、迁移或共享文件明确维护责任，后续只交一处真实工程任务，其他主题引用依赖，不在这里建立第二套任务清单。
+共享业务状态、只读快照、前端临时状态、Agent运行状态及jobs状态不能互相冒充。并发动作由权威边界执行最终校验，不以“先查后写”代替一致性设计。共用底座、迁移或共享文件明确维护责任，后续只交一处真实工程任务，其他PBC引用依赖，不在这里建立第二套任务清单。
 
 ## 6. 工程质量与原规格交接
 
@@ -107,7 +107,7 @@
 | --- | --- | --- | --- | --- |
 | `{实际组合；尚未形成可列待定范围}` | `{AD、契约、代码／环境分别固定}` | `{字段、默认、权限、错误、存量值及行为}` | `{顺序、兼容窗口、责任、不可逆限制}` | `{文档核对／待工程验证／实际回执分开}` |
 
-文档、契约、制品和环境版本分别管理，不要求所有AD或文档同号。版本号或Schema检查不能独自证明兼容；新增字段、枚举或默认行为需核实际消费者。未验证时保留未知，不推断应当兼容或自动升级所有主题。
+文档、契约、制品和环境版本分别管理，不要求所有AD或文档同号。版本号或Schema检查不能独自证明兼容；新增字段、枚举或默认行为需核实际消费者。未验证时保留未知，不推断应当兼容或自动升级所有PBC。
 
 外部契约锁在正式采用时记录；模板锁及生成基线在实际应用并验证后记录。锁不是批准或运行通过证明。此规约不自动创建锁、执行迁移、部署或发布。
 
@@ -115,7 +115,7 @@
 
 | ID与变化／例外 | 旧→新固定内容和来源 | 影响规范、契约、实体及必要传递消费者 | 相关AD／AC／TestCase／真实任务 | 真实决定与待验证范围 |
 | --- | --- | --- | --- | --- |
-| `{已有稳定ID或本次明确候选}` | `{变化条款、理由、准确版本或内容}` | `{直接与必要传递影响；无关主题不机械重写}` | `{固定引用；未形成就注明}` | `{未取得认可保持待审}` |
+| `{已有稳定ID或本次明确候选}` | `{变化条款、理由、准确版本或内容}` | `{直接与必要传递影响；无关PBC不机械重写}` | `{固定引用；未形成就注明}` | `{未取得认可保持待审}` |
 
 | Q／待核实事项 | 当前事实与缺少内容 | 影响范围及可独立继续部分 | 需要何种真实答复／证据 |
 | --- | --- | --- | --- |
@@ -127,7 +127,7 @@
 
 - 来源、固定内容、适用条款和补充位置可回读；已有规范没有被复制成第二权威或覆盖人工修改。
 - 规则区分已知事实、建议、明确采用和待确认；技术选型、权限、责任、摘要和运行结果没有编造。
-- 公共契约、数据／状态及共享文件责任无矛盾；各主题AD仍有完整设计及准确引用。
+- 公共契约、数据／状态及共享文件责任无矛盾；各PBC的AD仍有完整设计及准确引用。
 - 兼容、变更影响和例外限定实际范围；原型按需并可与AD并行，缺口不无差别阻断其他工作。
 - 最后写入后回读，新增要求逐条回源，逐表核对列数、列义及权限描述一致性。
 - 列出实际完成、Q、未执行事项和人工审阅入口后停轮；不自动开始AD／Plan／Build／测试执行或发布。