@givolt/i3-composer-agent 3.0.0 → 3.2.1

package/{references/enterprise-sop-resources/technical-baseline/baselines//344/274/201/344/270/232/345/272/224/347/224/250-/346/212/200/346/234/257/350/247/204/347/272/246_v0.0.2.md → skills/i3-enterprise-sop/references/technical-baseline/baselines/enterprise-application-technical-baseline-v0-0-4.md}

@@ -12,19 +12,19 @@
 
 | 项目 | 当前内容 |
 | --- | --- |
-| 文档版本 | v0.0.2，2026-10-20；保留 [v0.0.1 的历史记录](PROVENANCE.md#维护历史) |
-| 文档性质 | 根据使用者逐项确认整理的企业共用技术基线；供具体项目明确选用，新稿文字仍可人工审阅修改 |
-| 适用范围 | 明确采用本文件的企业业务项目及其前端、业务后端、Agent、任务工程；各工程按实际需求采用 |
-| 项目绑定 | 本文件不绑定某一业务项目；项目名称、采用版本、PRD／AD与实际工程在项目采用说明或AD中记录，见 Q01、Q12 |
-| 直接来源 | [软件架构设计 Specification 模板 v0.6 的来源说明](PROVENANCE.md#来源资料)，含原文明确的技术方向及工程约束 |
-| 编排依据 | 当前企业 SOP 的公共技术规约模板、AD 模板及交接合同；工程组织引用现有目录规范0.2.0 |
-| 确认依据 | 2026-10-20，使用者确认Q01—Q05、Q07、Q10、Q12的建议方向，随后确认Q06采用MaxKey／OIDC、Q09职责分工、Q11据实填写；Q08按现有工程骨架目录方案衔接 |
+| 文档版本 | 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记录。确认技术选择不等于授权升级、安装、部署或通过兼容验收 |
 | 维护与采用 | 共用规则及选型方向按上述确认维护；具体项目仍需记录采用版本、适用范围、责任和例外，不由本轮确认替代业务认可或开工许可 |
-| 现有证据 | 已读取来源、现有目录规范及相关原命令，核对MaxKey／Vue官方说明；尚未固定并验证完整软件版本组合，未生成业务工程，未执行安装、构建、测试、部署或发布 |
+| 现有证据 | 已核官方版本／依赖要求及本机工具；已完成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 来源与整理边界
 
@@ -34,15 +34,16 @@
 | 同一来源，第 6—11 章 | 数据、接口、前端、Agent、集成、权限及恢复的共用约束 | 本文件第 1、3—5 节；主题接口、实体和流程由各 AD 详设 |
 | 同一来源，第 12—17 章及附录 | 工程质量、环境、流水线、实施交接、验证与未决事项 | 本文件第 6—9 节 |
 | 使用者本轮逐项确认（2026-10-20） | 共用基线定位、Java／Spring Boot、前端工具链、MaxKey／OIDC、接口惯例、目录采用、部署分工及按项目落实的规则 | 对应第2—9节；不扩展为版本兼容、业务批准或实际环境就绪 |
-| [公共技术规约模板及采用说明](../README.md) | 已有规范优先、公共规则与主题设计分工、候选与真实采用分开 | 本文件的范围、采用和版本规则 |
-| [当前 AD 模板](../../ad/templates/AD.md) §0.3、§2.2、§9.6 | 基线引用、技术落实和真实骨架来源 | 各主题 AD 的对应条款 |
-| [当前交接合同](../../handoff-contract.md) §10 | 选定 AD 及必要配套交原 Plan，再进入获准 Build | 本文件第 9 节 |
-| [现有工程骨架方案的来源说明](PROVENANCE.md#工程目录依赖)、[目录规范0.2.0](../references/engineering-directory-v0.2.0/directory-standard.md)、[采用说明0.2.0](../references/engineering-directory-v0.2.0/adoption.md) | 工程目录与职责、AD映射、原Plan任务路径、获准Build的实际文件落点 | 本文件第1、6—9节；目录规范可先采用，不要求预先取得代码框架模板 |
-| [原Ship命令](../../../../.claude/commands/i3-ship.md)及[原Spec的内容要求](../../../../skills/i3-spec-driven-development/SKILL.md) | 发布前检查／决策／回滚，及原SPEC六项的工程命令和项目依据 | 本文件第6—7、9节；原命令与Skill未改 |
+| 2026-10-21官方资料核对、本机只读检查与使用者确认 | 固定首套版本选择、保留K8s 1.28及现有GitLab；记录兼容范围与真实验证边界 | 本文件§2.3—§2.6及Q02—Q06、Q09；不自动执行升级或替项目采用 |
+| [公共技术规约资料](../readme.md) | 已有规范优先、公共规则与主题设计分工、候选与真实采用分开 | 本文件的范围、采用和版本规则 |
+| [当前 AD 模板](../../templates/ad.md) §0.3、§2.2、§9.6 | 基线引用、技术落实和真实骨架来源 | 各主题 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 必须指出准确规则、适用范围和落实位置，不能只写“沿用旧规范”。
 
-初稿来源快照保存在 [首次历史目录的追溯信息](PROVENANCE.md#维护历史)；本版修改前材料与保护范围保存在 [本版来源追溯信息](PROVENANCE.md#维护历史)。来源文件以后修改，不自动改变本规约或项目已经采用的版本。
+本规约保留已确认技术条款及其来源说明，仅分发当前版本；工程组织统一采用同一SOP Skill内的1.0.0目录规范，采用信息由AD现有表格记录。来源材料或发行资源后续修改，不自动改变项目已经采用的版本。
 
 ## 1. 共用架构与工程边界
 
@@ -55,7 +56,7 @@
 | ARC-05 | 缓存、向量检索、消息、GIS、三维、多 Agent 等按实际需求选择 | 给出需求来源、用途和选型；不使用时说明理由，未知时列为待确认 |
 | ARC-06 | 消费外部能力应依据正式契约，不复制提供方内部实现作为本主题权威 | 固定提供／消费关系和版本；分别记录已可用、待核实、待接入及真实联调条件 |
 
-来源：软件技术说明第3、5、8—11章；现有工程骨架目录方案及目录规范0.2.0的职责分工。
+来源：软件技术说明第3、5、8—11章；现有工程骨架目录方案及目录规范1.0.0的职责分工。
 
 前端共用规则：
 
@@ -74,16 +75,16 @@
 
 | 技术领域 | 已确认的选型方向 | 适用范围 | 当前版本及落实状态 |
 | --- | --- | --- | --- |
-| 正式 Web 前端 | Vue 3＋TypeScript＋Antdv Next | 实际需要 Web 界面的业务工程；具体页面由 PRD 及适用原型确定 | Vue大版本为3；框架、组件库与工具链的精确兼容版本待核，见Q03 |
-| 前端工程工具链 | Vite＋TypeScript类型检查＋Vitest | 首套Web工程的构建、类型检查和单元／组件测试；路由和共享状态管理按需选择 | 工具链方向已确认；Node、包管理器及各依赖的实际版本组合待核，见Q03 |
-| 分布式运行时 | Dapr | 项目实际采用的服务调用、状态、事件或其他运行能力 | Runtime、SDK、组件与后端版本组合待核，见 Q04 |
-| 业务 Agent | Python＋Dapr Agents | 项目包含业务 Agent 时适用；未采用 Agent 的项目不生成 Agent 工程 | Python、框架、SDK及模型接入组合待核，见 Q04 |
-| 持久工作流 | Dapr Workflow | 经具体设计确定需要持久编排或恢复的场景 | 所用 SDK、Runtime、存储支持及版本策略待核，见 Q04 |
-| 目标运行平台 | Kubernetes（K8s） | 采用此企业基线的产品目标部署环境 | 集群版本、部署入口、命名空间与访问条件未提供，见 Q09 |
-| 主数据库 | PostgreSQL | 权威业务数据；执行历史、会话、缓存等用途另行明确 | 版本、扩展、驱动、实例和迁移工具待核，见 Q05 |
-| 代码与流水线 | 企业 GitLab＋GitLab CI | 业务项目的代码协作、构建和交付 | 实例、可用能力、Runner、仓库及产物服务待核，见 Q09 |
-| 普通业务后端 | Java＋Spring Boot | 首套普通业务后端选型方向，与Python Agent的职责和工程分别明确；可用的企业框架先核对复用条件 | 方向经使用者确认；JDK、Spring Boot、构建工具及依赖兼容组合由项目核实，见Q02 |
-| 统一身份与单点登录 | MaxKey＋OIDC | 企业统一账号与认证入口；角色和权限按实际采用能力映射，业务服务执行最终业务授权 | 方向已确认；实例、版本／类型、应用注册、用户／租户映射和失效行为在项目落实，见Q06 |
+| 正式 Web 前端 | Vue 3＋TypeScript＋Antdv Next | 实际需要 Web 界面的业务工程；具体页面由 PRD 及适用原型确定 | 采用§2.3的Vue 3.5.44、TypeScript 5.9.3及Antdv Next 1.6.0；实际安装／构建待验证，见Q03 |
+| 前端工程工具链 | Vite＋TypeScript类型检查＋Vitest | 首套Web工程的构建、类型检查和单元／组件测试；路由和共享状态管理按需选择 | 采用§2.3固定工具链；按需增加路由与状态管理，运行验证见§2.5、Q03 |
+| 分布式运行时 | Dapr | 项目实际采用的服务调用、状态、事件或其他运行能力 | Runtime 1.18.7，所需SDK／组件按§2.3选用；K8s 1.28实际联调待验证，见Q04 |
+| 业务 Agent | Python＋Dapr Agents | 项目包含业务 Agent 时适用；未采用 Agent 的项目不生成 Agent 工程 | 项目环境采用Python 3.12.15、Dapr Agents 1.0.9；保留宿主系统Python，模型接入仍按需验证 |
+| 持久工作流 | Dapr Workflow | 经具体设计确定需要持久编排或恢复的场景 | Python Workflow包1.18.3，按需使用PostgreSQL状态组件v2；恢复与跨版本行为待验证 |
+| 目标运行平台 | Kubernetes（K8s） | 采用此企业基线的产品目标部署环境 | 沿用使用者提供的K8s 1.28，完整补丁／发行版／访问条件待取得；本轮不升级 |
+| 主数据库 | PostgreSQL | 权威业务数据；执行历史、会话、缓存等用途另行明确 | 无既有约束时采用17.11候选；优先核现有服务端，Java驱动42.7.14，实例／扩展／迁移待落实 |
+| 代码与流水线 | 企业 GitLab＋GitLab CI | 业务项目的代码协作、构建和交付 | 现有GitLab 19.2.4；Runner按19.2.x匹配，补丁与平台能力待核；安全更新另行安排 |
+| 普通业务后端 | Java＋Spring Boot | 首套普通业务后端选型方向，与Python Agent的职责和工程分别明确；可用的企业框架先核对复用条件 | 采用OpenJDK 21.0.13、Spring Boot 4.1.1、Maven 3.10.0；依赖与启动验证见Q02 |
+| 统一身份与单点登录 | MaxKey＋OIDC | 企业统一账号与认证入口；角色和权限按实际采用能力映射，业务服务执行最终业务授权 | MaxKey 4.1.12为首轮OIDC接入基线；实例与生产安全更新仍需核实，见§2.3、Q06 |
 
 缓存、消息设施、对象存储、检索、网关、ORM、迁移工具、状态管理、GIS及三维引擎尚未统一指定产品。AD按需说明来源、用途和方案，不默认为全部引入。MaxKey是已确认的统一身份方向，其实际接入信息由项目取得。
 
@@ -97,6 +98,90 @@
 
 来源：软件技术说明第4章及使用者对Q02—Q05的确认。实际版本选择分别核对[Spring Boot系统要求](https://docs.spring.io/spring-boot/system-requirements.html)、[Vue工具说明](https://vuejs.org/guide/scaling-up/tooling)、[Dapr Agents入门条件](https://docs.dapr.io/developing-ai/dapr-agents/dapr-agents-getting-started/)和[PostgreSQL支持政策](https://www.postgresql.org/support/versioning/)。官方说明用于核对方向与条件，不代替本项目完整版本矩阵和运行验证。
 
+### 2.3 首套版本矩阵（2026-10-21确认）
+
+本节记录已确认的首套技术选择及有条件候选，不把“推荐目标”写成“已经安装”或“集成已通过”。实际项目先核已有平台与规范，明确采用本版后再落实所需组件。新增工程在实际依赖文件及锁文件中固定准确版本；可选组件不因列在本表就一律引入。
+
+| 类别 | 组件 | 推荐目标／既有版本 | 选择理由及适用限制 |
+| --- | --- | --- | --- |
+| 前端运行工具 | Node.js | 24.22.0 LTS | 沿用本机24系列，满足Vite和Vue工具链要求；本机当前24.15.0，本轮未升级 |
+| 前端包管理 | pnpm | 12.9.1 | 复用本机已安装版本；项目采用时固定`packageManager`及锁文件，不自动跟随最新版本 |
+| 前端框架 | `vue`、`@vue/compiler-sfc` | 均为3.5.44 | 运行时与编译器保持同版；采用Vue 3稳定线 |
+| 组件库 | Antdv Next | 1.6.0 | 采用正式发布且已有完整工程依赖依据的版本；新发布1.7.0留作后续评估，不自动替换 |
+| 类型检查 | TypeScript／`vue-tsc` | 5.9.3／3.3.13 | 以Antdv Next 1.6.0的TS工具链为依据，保留类型检查；不因TS出现新大版就自动切换 |
+| 构建 | Vite／`@vitejs/plugin-vue` | 8.3.5／6.0.10 | 插件声明支持Vite 8；Vite要求Node `^20.19.0`或`>=22.12.0`，所选Node满足 |
+| 前端测试 | Vitest及所需coverage插件 | 均为4.1.12 | 此版本依赖声明包含Vite 8；作为本规约的保守选择，不宣称与组件库仓库的Vitest版本相同 |
+| 按需前端依赖 | Vue Router／Pinia | 4.6.4／3.0.4 | 沿用Antdv Next 1.6.0工程所用版本线；仅在页面路由或共享状态确有需要时引入 |
+| Java环境 | OpenJDK | 21.0.13 LTS | 延续现有OpenJDK 21系列；本机当前Homebrew OpenJDK 21.0.12.1，升级另行执行 |
+| Java构建 | Maven | 3.10.0 | 复用已安装版本，满足Spring Boot的Maven 3.6.3以上要求 |
+| 普通业务后端 | Spring Boot | 4.1.1 | 所选Java 21在官方兼容范围内；其余Spring依赖由该版BOM管理，不逐项随意混配 |
+| Java数据库驱动 | PostgreSQL JDBC | 42.7.14 | 对Boot 4.1.1 BOM中的42.7.13作明确安全补丁覆盖；需验证连接认证与读写，不以BOM存在替代安全核对 |
+| Agent项目环境 | Python | 3.12.15 | Dapr Agents 1.0.9要求Python `>=3.11,<3.14`；使用独立项目环境，保留本机系统默认3.14.4 |
+| 分布式运行时 | Dapr Runtime | 1.18.7 | 普通sidecar方式；K8s 1.28离线渲染已通过，实际运行与支持边界见§2.4—§2.5 |
+| Dapr管理工具 | Dapr CLI | 1.18.2 | CLI与Runtime分别记录真实发行号；本机尚未安装，不把补丁号强行设成Runtime相同 |
+| 按需Java集成 | Dapr Java SDK | 1.18.1 | 要求Java 17以上；仅采用相应能力时引入。若使用Spring集成，选择专用Boot 4 starter并单独验证，不能误用Boot 3 starter |
+| Python运行能力 | `dapr`／`dapr-ext-workflow` | 均为1.18.3 | 与所选Agents要求的Dapr 1.18包范围一致；工作流包仅用于相应工程 |
+| Agent框架 | `dapr-agents` | 1.0.9 | 已核Python和Dapr依赖范围；框架成熟度与实际模型／工具链仍需项目验证，版本1.x不等于生产验收 |
+| 业务数据库 | PostgreSQL服务端 | 17.11（无既有约束时的候选） | 优先复用已有受支持服务端；本机只确认libpq／psql客户端18.3，不能据此假定服务端也是18.3或自动新建17.11 |
+| Dapr存储 | PostgreSQL state组件 | `v2` | 这是组件协议版本，与数据库17.11分别管理；按需用于Actor／Workflow，业务数据与运行历史分别明确责任、隔离和恢复 |
+| 统一身份 | MaxKey＋OIDC | 4.1.12（首轮接入基线） | 作为独立身份服务通过协议对接，无需与业务服务的Boot主版相同；4.2.0为新发布候选，投产前核其安全修复及迁移影响，不将4.1.12直接认定为生产安全验收通过 |
+
+Java若实际采用Spring集成，候选坐标为`io.dapr.spring:dapr-spring-boot-4-starter:1.18.1`。官方该专用starter存在不等于Boot 4.1.1组合已经联调；仍需核依赖收敛、Jackson序列化和启动行为。只采用Dapr HTTP／gRPC接口时也需明确接口与认证边界，不在本规约里提前替项目改变集成方式。
+
+| 平台／工具 | 本次保留的环境／选择 | 采用与后续处理 |
+| --- | --- | --- |
+| Kubernetes | 1.28，完整1.28.x补丁与发行版待取得 | 按使用者要求保留，不预设升级。该系列已结束上游维护，亦不在本次Dapr官方支持／发布测试范围内；不由此推导为必然无法运行 |
+| kubectl | 集群操作时使用与1.28匹配的专用客户端，准确补丁待核 | 本机Docker附带kubectl 1.34.1，与1.28超出官方±1小版本范围；保留现有工具，后续按需隔离使用匹配客户端 |
+| GitLab | 19.2.4，使用者提供 | 延续既有19.2分支；19.2.8作为同分支安全更新建议，需单独确认与执行，不把它写成已经升级 |
+| 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 | 按本次确认统一来源；项目既有采用不自动升级，先核差异、适用范围及真实工程映射。目录规则不等于可运行代码模板 |
+
+### 2.4 已取得的环境事实与K8s兼容边界
+
+2026-10-21在本机只读检查：macOS 26.3、Apple Silicon、64GB内存；Node 24.15.0、pnpm 12.9.1、Homebrew OpenJDK 21.0.12.1、Maven 3.10.0；系统默认Python 3.14.4，另有3.12.13和3.13.13环境。Python目标3.12.15尚未建立项目环境，不替换系统Python。
+
+PostgreSQL已定位的是Homebrew libpq 18.3工具。在已查常见路径、进程、服务及本机5432端口中未找到正在运行的服务端；仍可能存在停止的容器、其他路径或远端实例。项目应先取得服务端的真实版本、位置和访问方式，再决定是否采用17.11新建候选。
+
+本机Docker daemon未运行，当前没有Kubernetes context或可访问集群配置；Dapr CLI和Helm不在当前PATH中。K8s 1.28及GitLab 19.2.4来自使用者说明，尚未通过目标平台查询核实。
+
+对官方Dapr 1.18.7 chart所做的离线检查仅包括：针对`--kube-version 1.28.0`和`1.28.15`的默认渲染，以及1.28.15的HA渲染，三组退出码均为0。该chart没有`kubeVersion`硬性排除1.28；渲染出的内置API未见明显要求高于1.28的版本。首轮校验文件下载超时与后续成功记录分别保留，没有把失败转算通过。
+
+这些结果不包含服务端Schema接收、server-side dry-run、实际安装、Pod启动、网络／存储、Workflow或Agent验收。Dapr 1.18.7该发布的kind矩阵覆盖K8s 1.32.8、1.33.4、1.34.0，没有1.28。因此本规约的结论是“既有1.28保留，普通sidecar有静态兼容依据，真实兼容待验证”，不能写成“官方支持1.28”或“已证明必然不能运行”。
+
+保持`dapr_sidecar_injector.nativeSidecar=false`，不主动设置Pod注解`dapr.io/enable-native-sidecar=true`。K8s 1.28的原生sidecar依赖默认关闭的Alpha功能，普通Dapr sidecar不要求启用它。Job／CronJob若使用普通sidecar，AD须按所选版本说明结束和退出方式，避免业务容器结束后sidecar阻碍Job完成。
+
+### 2.5 实施前后的验证安排
+
+| 编号 | 需取得的结果 | 通过依据及影响范围 |
+| --- | --- | --- |
+| V01 前端 | 选定版本的安装、类型检查、构建及适用测试 | 依据真实`package.json`、锁文件和命令输出验证Vue／Antdv／Vite／TS／Vitest组合；缺项仅限制相关前端实现／交付 |
+| V02 Java | Boot 4.1.1的依赖收敛、启动、序列化与JDBC行为 | 核所选JDK、Maven、PG JDBC安全补丁覆盖；实际用到Dapr starter时再核Boot 4专用starter及Jackson组合，不预判联调通过 |
+| V03 Agent／Workflow | Python 3.12.15环境及完整依赖解析；真实模型、工具和持久执行 | 核Agents／SDK约束、中断恢复、重复执行与授权失效；替身范围与真实服务联调分开，未采用能力不要求凭空搭建 |
+| V04 K8s／Dapr | 目标1.28集群中的实际安装与必要业务链 | 取得准确补丁、发行版、匹配客户端和合法访问条件；核CRD／webhook／权限、Pod、DNS／网络、持久卷、Placement／Scheduler及业务实际所用能力，保留失败和回滚说明 |
+| V05 数据与身份 | 真实PostgreSQL／MaxKey实例信息及联调 | 优先核既有实例；验证认证、角色／租户映射、退出撤权、读写／迁移／恢复及版本安全更新，不能用客户端号或产品名代替服务端事实 |
+| V06 交付平台 | GitLab／Runner／镜像与部署所需实际能力 | 据实补Runner补丁、仓库、环境和权限引用；GitLab／Docker更新另行安排，不因版本矩阵已写入就宣称平台已准备好 |
+
+验证按对应AD、Plan任务及实际阶段执行，继续区分设计审查、工程执行、集成、业务认可和发布授权。未验证项可以保留并明确其影响，不要求在AD起草前先搭出所有环境；依赖它们的实施或放行也不能凭文档确认自动通过。
+
+### 2.6 官方依据与核对日期
+
+以下资料用于2026-10-21的版本选择和兼容条件核对。滚动文档可能变化；实际实施时以本节明确版本、相应发布说明及真实解析结果复核，不跟随链接自动更新本规约。
+
+| 范围 | 官方依据 | 本次核对点 |
+| --- | --- | --- |
+| Node／包管理 | [Node 24.22.0](https://nodejs.org/en/blog/release/v24.22.0)、[pnpm安装要求](https://pnpm.io/installation) | 24系列LTS及所选工具环境要求；pnpm复用实际12.9.1 |
+| Vue／Antdv | [Vue 3.5.44包](https://registry.npmjs.org/vue/3.5.44)、[Antdv Next 1.6.0](https://github.com/antdv-next/antdv-next/releases/tag/antdv-next%401.6.0)、[对应工程依赖](https://github.com/antdv-next/antdv-next/blob/antdv-next%401.6.0/pnpm-workspace.yaml) | 组件库发布、Vue／TS／Router／Pinia工程范围；不把组件库仓库所有测试版本照搬成项目义务 |
+| TS／构建／测试 | [TypeScript 5.9.3](https://registry.npmjs.org/typescript/5.9.3)、[vue-tsc 3.3.13](https://registry.npmjs.org/vue-tsc/3.3.13)、[Vite 8.3.5](https://registry.npmjs.org/vite/8.3.5)、[Vue插件6.0.10](https://registry.npmjs.org/@vitejs/plugin-vue/6.0.10)、[Vitest 4.1.12](https://registry.npmjs.org/vitest/4.1.12) | Node engines及peer／依赖约束；包元数据满足不代替项目构建 |
+| Java／Boot | [Homebrew OpenJDK 21](https://formulae.brew.sh/formula/openjdk@21)、[Maven历史](https://maven.apache.org/docs/history.html)、[Boot要求](https://docs.spring.io/spring-boot/system-requirements.html)、[Boot 4.1.1 BOM](https://repo.maven.apache.org/maven2/org/springframework/boot/spring-boot-dependencies/4.1.1/spring-boot-dependencies-4.1.1.pom) | JDK／Maven兼容、BOM依赖管理；Homebrew OpenJDK发行与其他JDK发行包分别判断 |
+| PostgreSQL驱动 | [JDBC 42.7.14说明](https://jdbc.postgresql.org/changelogs/2026-10-07-42.7.14-release/) | 针对BOM的42.7.13明确采用安全补丁，保留项目认证和读写验证 |
+| Python／Agent | [Python 3.12.15](https://www.python.org/downloads/release/python-31215/)、[Agents 1.0.9依赖](https://github.com/dapr/dapr-agents/blob/v1.0.9/pyproject.toml)、[Dapr 1.18.3](https://pypi.org/pypi/dapr/1.18.3/json)、[Workflow 1.18.3](https://pypi.org/pypi/dapr-ext-workflow/1.18.3/json) | Python范围及Dapr SDK范围，不采用系统3.14为Agent项目环境 |
+| Dapr版本／Java集成 | [Runtime 1.18.7](https://github.com/dapr/dapr/releases/tag/v1.18.7)、[CLI 1.18.2](https://github.com/dapr/cli/releases/tag/v1.18.2)、[Boot 4 starter 1.18.1 POM](https://repo.maven.apache.org/maven2/io/dapr/spring/dapr-spring-boot-4-starter/1.18.1/dapr-spring-boot-4-starter-1.18.1.pom)、[Spring集成说明](https://docs.dapr.io/developing-applications/sdks/java/spring-boot/) | 组件分别定版；专用starter可用性与完整组合验证分开 |
+| K8s兼容 | [Dapr支持政策](https://docs.dapr.io/operations/support/support-release-policy/)、[1.18.7 chart](https://github.com/dapr/dapr/blob/v1.18.7/charts/dapr/Chart.yaml)、[sidecar配置](https://github.com/dapr/dapr/blob/v1.18.7/charts/dapr/charts/dapr_sidecar_injector/values.yaml)、[该版kind测试](https://github.com/dapr/dapr/blob/v1.18.7/.github/workflows/kind-e2e.yaml)、[K8s版本](https://kubernetes.io/releases/)、[kubectl偏差规则](https://kubernetes.io/releases/version-skew-policy/) | 支持范围、发布测试、离线模板与真实运行分别取证；保留既有1.28 |
+| 数据／身份 | [PostgreSQL支持](https://www.postgresql.org/support/versioning/)、[Dapr PostgreSQL v2](https://docs.dapr.io/reference/components-reference/supported-state-stores/setup-postgresql-v2/)、[MaxKey 4.1.12](https://github.com/dromara/MaxKey/releases/tag/4.1.12)、[MaxKey 4.2.0](https://github.com/dromara/MaxKey/releases/tag/4.2.0) | 新建候选、已有实例及生产安全选择分别处理 |
+| 交付工具 | [GitLab安全补丁](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/)、[Runner版本](https://docs.gitlab.com/runner/#gitlab-runner-versions)、[Docker Desktop说明](https://docs.docker.com/desktop/release-notes/) | 保留19.2.4及本机4.70.0；更新建议不写成已执行 |
+
 ## 3. 身份、安全与业务权限
 
 统一身份和单点登录采用MaxKey，通过OIDC对接。MaxKey作为独立的公共身份服务，业务工程不再自行复制一套账号密码体系；如需适配现有账号系统，先明确来源、映射和生命周期责任。
@@ -166,17 +251,17 @@
 
 ### 6.1 工程骨架与文件责任
 
-- ENG-01：工程骨架沿用现有[目录规范0.2.0](../references/engineering-directory-v0.2.0/directory-standard.md)和[采用说明0.2.0](../references/engineering-directory-v0.2.0/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-05：目录规范不要求另建project.yaml、templates.lock、contracts.lock、生成记录库或代码模板三方升级流程。已有项目或工具确有这些文件时按其实际用途保留；项目另行要求复用特定代码模板时，才取得该模板及所需版本、应用和验证依据。
 
-可以在现有AD的骨架栏目写明“目录规范已采用；工程拟建；未采用代码框架模板”，不能据此声称“可运行代码模板已取得”或“代码已生成”。实际目录来源为本资源附带的0.2.0定版资料；资源目录和i3维护工作区均不是业务工程输出根。
+可以在现有AD的骨架栏目写明“目录规范已采用；工程拟建；未采用代码框架模板”，不能据此声称“可运行代码模板已取得”或“代码已生成”。实际目录来源为本资源附带的1.0.0定版资料；资源目录和i3维护工作区均不是业务工程输出根。
 
 既有工程先映射实际目录，不为套规范移动或重建。实际有内容时再建所需位置；项目根的构建／CI配置与框架原有布局允许按实情保留。目录检查、代码存在、构建、启动、业务验证和发布分别取证。
 
-来源：现有工程骨架目录方案、目录规范／采用说明0.2.0，以及当前AD §9.2／§9.6的对应栏目。本轮只引用这些资源，不修改工程骨架工作树或SOP运行模板；原命令的读取与实际落点继续按对应工程验证任务取证。
+来源：现有工程骨架目录方案、目录规范1.0.0，以及当前AD §9.2／§9.6的对应栏目。本轮只引用这些资源，不修改工程骨架工作树或SOP运行模板；原命令的读取与实际落点继续按对应工程验证任务取证。
 
 ### 6.2 工程命令与编码规范
 
@@ -227,15 +312,15 @@
 
 | 编号 | 已确认的共用处理 | 项目仍需落实的内容与影响 | 处理时点 |
 | --- | --- | --- | --- |
-| Q01 | 本文作为可复用企业技术基线，项目明确采用准确版本 | 项目名称、维护责任、范围和既有规范由项目采用说明／AD绑定；不在公共规约预造业务身份 | 实际项目采用时 |
-| Q02 | 首套普通业务后端采用Java＋Spring Boot方向，与Python Agent分工 | 取得JDK、框架、构建及企业框架复用条件的实际版本；不能将方向确认写为兼容已通过 | 相关详设和工程任务按依赖核实 |
-| Q03 | 保留Vue 3＋TypeScript＋Antdv Next，工具链采用Vite、类型检查和Vitest方向 | Node、包管理器、各依赖版本、路由和状态管理需求及安装／构建结果待项目落实 | 初始化及依赖安装前核实，生成后验证 |
-| Q04 | Dapr／Agent按实际需要的能力建立组合版本和验证安排 | 固定Runtime、SDK、Python、Agents、Workflow及底层组件，验证必要业务链、中断恢复、重复与授权失效 | 依赖相关能力的设计／工程阶段分别核实 |
-| Q05 | PostgreSQL优先兼容企业已有受支持版本，逻辑责任与恢复分别设计 | 版本、驱动、扩展、实例、迁移工具、DDL和恢复方案仍须真实来源及执行证据 | 数据工程设计、迁移及运行前 |
-| Q06 | 统一身份采用MaxKey，通过OIDC接入；业务服务执行最终授权 | 取得实例、版本／类型、应用注册、用户／租户／角色映射、退出撤权及配置引用；不虚构claims或可用能力 | 身份相关契约和实现前 |
+| 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 | 引用现有目录规范／采用说明0.2.0，沿用原AD→Plan→Build的目录映射链 | 明确业务根及真实／拟建路径；目录规范可先采用，实际代码由获准Build生成验证；只有另行要求特定代码模板才须取得该模板 | AD映射、Plan任务文件路径、Build实际落点依次核对 |
-| Q09 | AD规定部署要求，Plan安排任务，Build形成配置，Ship核验汇总部署准备 | 实际环境、资源、权限及配置按依赖取得；部署清单和运行配置不冒充平台已就绪 | 构建、联调、部署和发布按需落实 |
+| 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与必要关联契约设计时 |
@@ -248,34 +333,34 @@
 
 ### 9.1 进入 AD
 
-1. 在具体业务项目明确采用本规约的路径、版本和适用范围；先核已有规范及冲突，不凭安装或发现文件自动启用。
+1. 使用 i3-enterprise-sop生成AD时，项目未另有明确规约就默认读取本规约和目录规范，在AD记录路径、版本及范围；已有明确规约优先，冲突先说明。
 2. 选定准确 PRD 主题和版本。起草／修订 AD 必须按企业入口加载原 Spec Skill，使用完整 AD 模板；本公共规约本身不替代主题规格。
-3. AD §0.3登记本规约及目录规范／采用说明的来源和版本，§2.2落实技术选择，§9.2映射工程及模块位置，§9.6区分现有工程和拟建内容；目录规范可在代码生成前采用，保留三图和全部详设责任。
+3. AD §0.3登记本规约及目录规范的来源和版本，§2.2落实技术选择，§9.2映射工程及模块位置，§9.6区分现有工程和拟建内容；目录规范可在代码生成前采用，保留三图和全部详设责任。
 4. 原型按需，可与 AD 并行。记录假设和受影响未决；候选生成、完整回读和人工认可分别处理，保存后遵守原 Spec 停轮。
 
-以下提示词供将来明确采用时使用，当前未执行此作业；`/i3-sop` 属于尚未发布的本地候选入口：
+以下是明确委托本 Skill生成AD的任务示例；默认资料从本Skill直接定位，项目明确规约优先，不要求用户填写安装内部路径：
 
 ```text
-/i3-sop ad
-本次采用 随包提供的《企业应用公共技术规约 v0.0.2》（按所选资源索引定位） 作为公共技术依据。
+使用 i3-enterprise-sop 的 ad 动作。
+将自带《企业应用公共技术规约 v0.0.4》和目录规范作为默认输入；项目已有明确规约时优先沿用。
 先确定当前业务项目、我已选定的 PRD 主题和准确版本；存在歧义先问。
-实际读取这份规约、其引用的工程目录规范／采用说明0.2.0及本次必要来源，列出适用条款、已有规范冲突和影响本主题的项目缺口。
+实际读取这份规约、其引用的工程目录规范1.0.0及本次必要来源，列出适用条款、已有规范冲突和影响本主题的项目缺口。
 按原 Spec Skill 和完整 AD 模板生成本主题设计，保留三图、工程细节和 SPEC 六项。
-沿用已确认的后端、前端工具链和MaxKey／OIDC方向，不重复猜选型；未确定的版本、具体字段和工程映射按实际来源补足。
+沿用§2.3已确认的版本矩阵，保留既有K8s 1.28与GitLab 19.2.4；逐项区分目标与实装，未验证的兼容性、具体字段和工程映射按实际来源补足。
 按现有目录规范明确本主题源码、模块、配置、测试和契约的已有／拟建位置，不要求预先提供一套代码框架模板，也不宣称工程已生成。
 保留已有人工修改，回读最终稿，交我审阅后停轮，不进入 Plan 或 Build。
 ```
 
 ### 9.2 交原 Plan
 
-以选定AD为入口，读取其准确PRD、本规约适用条款、共享契约、目录规范／项目采用说明和已有代码；尚无代码时如实记录拟建，不虚构工程根。按主题加载完整必要内容，核本范围SPEC六项和FR／AC；Plan任务保留真实／拟建文件路径及验证依据，不全量注入无关AD和历史。
+以选定AD为入口，读取其准确PRD、本规约适用条款、共享契约、目录规范及AD工程映射和已有代码；尚无代码时如实记录拟建，不虚构工程根。按主题加载完整必要内容，核本范围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文档路径，主题AD仍按相应文档角色登记。可以手动给出准确路径，不强制创建清单；引用或登记不证明已读，也不表示文档获批。
 
 ```text
 /i3-plan
-以我本轮明确选定的AD为规划入口，实际读取它引用的PRD、公共技术规约适用条款、共享契约、工程目录规范／采用说明及已有代码。
-公共技术规约使用本次明确采用的准确路径和版本，不仅凭清单存在判断已读。
+以我本轮明确选定的AD为规划入口，实际读取它引用的PRD、公共技术规约适用条款、共享契约、工程目录规范及已有代码。
+公共技术规约按AD §0.3采用记录中的准确路径、文内版本及适用条款回读，不以AD引用或清单存在代替正文读取；规约采用信息不写入handoff.json。
 核对本主题需求、验收条件、SPEC 六项、共享依赖和未决影响；TestCase 按需引用。
 按AD的工程／模块映射，将每项任务预计新增或修改的文件路径、真实来源、初始化或增量内容及验证依据保留在原计划和唯一任务目标中，交我审阅，暂不实施。
 ```
@@ -288,8 +373,8 @@
 
 ### 9.4 本次交付结论
 
-本版已根据使用者确认补齐公共基线定位、普通业务后端、前端工具链、MaxKey／OIDC、接口惯例、目录规范采用、部署分工及按实情填写的规则。Q01—Q12现在区分已确认内容和项目待落实事项；实际项目采用、精确版本兼容和工程实施结果仍各自核验。
+本版保留2026-10-20／21确认的共用规则、技术版本矩阵、本机及既有平台事实、官方依据与V01—V06验证安排，并按2026-10-22确认采用工程目录规范1.0.0，本副本的采用信息直接由AD记录。Q02—Q06、Q09区分已选择版本与仍待取得的环境／运行证据；其他已确认规则保留。K8s 1.28继续保留，三组Dapr离线渲染不作为真实集群通过证明。
 
 本文件可供人工审阅，并可在明确选用后作为 AD 的公共输入。它不证明某项目的整体技术设计已经批准，也不证明所有主题可交 Plan、可直接 Build 或已通过运行验收。
 
-版本记录：v0.0.1（2026-10-20）为首次来源整理，原文完整保留。v0.0.2（2026-10-20）落实本轮确认，并引用当前工程目录规范0.2.0；不再把旧代码模板／工程锁方案作为统一前置。原说明、公共模板、AD模板、Skill、命令、SOP与工程骨架运行资源、业务稿保持原状，未提交或发布。
+版本记录：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

@@ -0,0 +1,23 @@
+# 公共技术规约资料
+
+<!-- i3:zh-guide:start -->
+## 中文使用说明
+
+按下文完整工程步骤、检查项与验证条件执行。根据任务选择适用步骤，保留证据、风险和退出条件；正文示例中的英文标签在面向用户输出时译为中文。
+
+默认使用简体中文解释、追问及生成报告；用户明确要求其他语言时可切换。原方法正文、引用、阈值和审批条件完整保留。代码标识、路径、命令、工具参数、JSON 键/枚举与原文引用保持原样。
+<!-- i3:zh-guide:end -->
+
+生成 AD 时，默认完整读取本目录的企业应用具体规约和工程目录规范，作为技术与结构输入；项目已明确采用自己的规约或目录约定时优先沿用其实际版本。来源、版本、适用范围和工程映射直接记在 AD §0.3、§9.6，不要求另写采用说明。
+
+| 文件 | 用途 |
+| --- | --- |
+| [企业应用具体规约](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 | 没有可用具体规约时，根据项目真实资料起草规约候选 |
+
+具体规约缺失、不可读或不适用时，先提示用户按通用模板生成，说明已有材料、缺口和建议目标。取得技术文档写入委托后起草并交审，用户确认后继续 AD；不用空模板充当技术规约，不编选型、版本、权限或运行结果，不要求用户另启一个入口。
+
+项目自改资料先读取并保留；已选来源失效或冲突时说明影响，不静默回退发行副本。默认作为 AD输入不等于已获业务批准、工程可运行或兼容验证通过，也不授权更改项目环境和代码。
+
+本轮不重新核实原规约的官方版本、安装环境和兼容运行；原未验证条件继续保留，具体技术条款和版本矩阵不因目录整理改变。资源模板、具体规约和业务文档版本分别维护。

package/{references/enterprise-sop-resources/technical-baseline/templates/TECHNICAL-BASELINE.md → skills/i3-enterprise-sop/references/technical-baseline/templates/technical-baseline.md}

@@ -8,7 +8,7 @@
 默认使用简体中文解释、追问及生成报告；用户明确要求其他语言时可切换。原方法正文、引用、阈值和审批条件完整保留。代码标识、路径、命令、工具参数、JSON 键/枚举与原文引用保持原样。
 <!-- i3:zh-guide:end -->
 
-模板内容版本：v0.0.1。用于项目共用工程约束及其采用引用；不增加BRD／PRD／AD／TestCase之外的业务阶段。采用方式见[采用说明](../README.md)。
+模板内容版本：v0.0.1。用于项目共用工程约束及其采用引用；不增加BRD／PRD／AD／TestCase之外的业务阶段。采用方式见[采用说明](../readme.md)。
 
 **先复用已有规范。** 项目、集团或平台已有适用规范时，本模板只用于核对覆盖和补充真实缺口，不要求复制全文、搬迁文件或再建一份同内容规范。已有采用说明足够时，沿用其位置及格式即可。缺少规范时，才按下列结构起草项目最小候选；可用固定引用代替重复正文，不适用项说明理由。
 

package/{references/enterprise-sop-resources/ad/templates/AD.md → skills/i3-enterprise-sop/references/templates/ad.md}

@@ -8,17 +8,18 @@
 默认使用简体中文解释、追问及生成报告；用户明确要求其他语言时可切换。原方法正文、引用、阈值和审批条件完整保留。代码标识、路径、命令、工具参数、JSON 键/枚举与原文引用保持原样。
 <!-- i3:zh-guide:end -->
 
-**原型按需，AD 可并行。**AD 的直接产品依据是本次选定的 PRD；原型不是进入 AD 的统一前置。无界面时可说明不适用；有界面且页面、行为和交互定义已充分明确时，也不强制另做原型。需要原型时，可与架构、数据、接口等 AD 设计并行；关键交互未定，只限制依赖它的具体设计与交接范围。项目明确要求的原型认可仍在相应范围交接前满足，不把“可起草 AD”写成“全部设计已可实施”。
+模板版本：v0.1.6。模板版本与业务文档版本分别维护。
 
-**审查只标注，使用者决定处理。**文档审查者只读标注问题、准确位置、来源、影响和修改建议，不直接修改候选。使用者可以人工修改、明确委托模型修订、有依据地不采纳建议，或将业务问题保持待确认；审查意见不自动触发改写。保留旧稿、人工修改、原报告和逐项处理依据，按项目既有约束进行必要复查；缺少真实答复不为清零而补造规则，人工编辑也不自动等于审查通过或业务批准。
+## 使用说明（不复制为业务正文）
 
-模板版本：v0.0.4。日期：2026-10-18。状态：自有资源候选；模板可供明确采用，业务内容与认可另行记录。
+- **输入：**准确选定的 PRD，或外部 AD及需求依据；默认带入本 Skill 自带的企业应用具体规约与目录规范，项目已有明确规约或目录约定时优先沿用，并读取必要契约与工程事实。
+- **输出：**对应一个准确 PRD 版本的主题 AD；默认保存到业务项目的本PBC目录，路径为`spec/{PBC名称}/{PBC名称}-{主题名称}-AD_v{业务版本}.md`，不强制与PRD同号。已有明确采用位置或外部原件保留实际路径，不自动迁移。
+- **阶段职责：**整体技术架构图、功能架构图、ER 图为必需视图；保留字段、接口、数据责任、权限、状态、事务、并发、恢复及完整工程定义。原型按需，可与 AD 并行，不作为统一前置。默认具体规约与目录规范是生成输入，项目明确资料优先；缺少可用具体规约时先提示按通用模板生成并交审，再继续 AD。目录约定与真实源码分别表达，采用信息直接记本 AD。
+- **写作：**主会话按本 Skill 显式使用原 Spec；来源、假设、真实答复与 Q 分开。新建、外部稿整理与授权修订均保护业务原件、人工编辑和历史，不预填批准或运行结果。
+- **交付：**按下文完整填写适用内容，不以标题或数量代替语义覆盖；新增规范性要求逐条回查来源、权限与状态跨处一致、表格逐行核列义。生成或修订稿保存后检查落盘完整性，分段写入或报错时核对相关内容，保留内容自查；检查完成后按本Skill自动登记本次文档路径，再交人工审阅并停轮。登记不表示批准，只读审查只标注问题，不改稿或登记。
+- **工程衔接：**T1形成企业文档并交审；T2显式使用原 Spec，结合选定依据落实六项、形成工程 SPEC并交审；T3读取选定工程 SPEC调用原规划。每阶段保留人工审阅停点，不自动推进。工程事实缺失如实说明，不编造命令、代码或技术选型。用户另行明确选择原生等效规格方式时，沿原方法处理。
 
-采用[模板与交接合同](../../template-contracts.md)。AD 同时承载技术架构和完整工程设计，实例文件名为 `{PBC}-{需求主题}-AD_v0.0.1.md`。本次采用一个明确 PRD 版本，不强制两份文档同号；相关主题和公共基线固定引用，不让本 AD 隐式承担另一 PRD 的全部设计。
-
-AD §9 明确保留原 SPEC 的完整命令、项目目录、代码风格和工程边界；测试策略与 TestCase §3.1 固定衔接。四类模板是外部规格表示，不另造第五核心规格、不强制复制 SPEC，也不改变继承 Skill 的触发、输出、工具、验证或认可要求。所填状态和字段不构成原方法所需的人类决定。
-
-**整体技术架构图、功能架构图、ER 图均为必需视图。** 下列图是填写骨架，占位实体、关系、基数和箭头不代表已经确认的架构。实例必须按真实输入替换，正文表格补全工程定义；图形齐全不等于可以实施。缺口只阻断依赖它的范围，不能为补齐图而虚构组件、表或业务规则。
+未知项写明 Q及具体影响，不适用项说明依据；缺少工程条件只限制依赖它的范围。
 
 ---
 
@@ -28,9 +29,11 @@ AD §9 明确保留原 SPEC 的完整命令、项目目录、代码风格和工
 
 | 项目 | 本次实际值 |
 | --- | --- |
-| 能力与需求主题 | `{PBC capabilityId/名称；稳定prdId/主题；已知EBC引用}` |
-| 文档身份/版本/位置 | `{documentId；实际版本；可回读路径；摘要可选}` |
-| 直接产品依据 | `{唯一选定PRD身份、版本和实际路径；回读正文，摘要可选，不自动取最新}` |
+| 所属 EBC | `{ebcId；ebcName；已确认或候选边界}` |
+| 所属 PBC | `{pbcId；pbcName；已确认或候选边界}` |
+| 产品需求主题 | `{稳定prdId；主题名称；改名不换身份}` |
+| 文档身份/版本/位置 | `{documentId；类型AD；实际业务版本；可回读路径；摘要可选}` |
+| 直接产品依据 | `{唯一选定PRD的documentId、文内版本、实际路径及条款；EBC／PBC／主题与本稿一致；回读正文，不自动取最新}` |
 | 原型/组件/公共基线 | `{适用版本与认可范围；没有或不适用则说明影响}` |
 | 当前设计范围 | `{全部有效目标、变化/保留/替代及仅比较材料}` |
 | 现有工程基准 | `{代码、数据、接口、实际运行/部署状态；未实现/未读取分别说明}` |
@@ -38,12 +41,14 @@ AD §9 明确保留原 SPEC 的完整命令、项目目录、代码风格和工
 
 ### 0.1 固定输入与权威定义
 
-| 输入/附件 | 实际身份/路径/文内版本（摘要可选） | 定义权威范围 | 本 AD 使用位置 | 已读/可用/认可与缺口 |
+| 引用 ID／输入或附件类型 | 来源身份／实际路径或URL／文内版本或固定提交／条款（摘要可选） | 定义权威范围 | 本 AD 使用位置 | 已读/可用/认可与缺口 |
 | --- | --- | --- | --- | --- |
-| `{PRD/原型/已有代码/外部规范/Schema等}` | `{能回读的固定内容}` | `{产品/交互/API/数据/公共规则等}` | `{章节/条目}` | `{文档存在不代表真实服务可用}` |
+| `{IN别名；直接PRD／原型／已有代码／外部规范／Schema等}` | `{documentId或资料标识及适用ebcId／pbcId／prdId；能回读的准确位置、版本和条款}` | `{产品/交互/API/数据/公共规则等}` | `{章节/条目}` | `{实际采用、仅参考或缺项；文档存在不代表真实服务可用}` |
 
 精确 OpenAPI、Schema、DDL、数据字典可以在受控附件维护，正文声明权威范围并固定引用，不能各自保存不同答案。没有附件时在正文完整定义；不能虚构附件已存在。
 
+直接PRD与本稿的EBC／PBC编号名称和prdId须一致，名称变化不换编号；本文documentId与版本独立维护。跨PBC契约或关联设计明确提供方／消费方的来源身份、准确路径／版本、采用范围与本AD落实位置，不要求参考对象属于本主题，也不允许其替代直接产品依据。原型、规约、目录规范、实际模板／骨架和契约在现有输入／采用表固定引用，不依赖handoff.json的扩展字段，不另建平行清单；必要来源缺失或冲突时说明受限范围。
+
 ### 0.2 决定、未决与变化
 
 | ID | 事项/方案 | 已定规则/项目决定/待核实 | 来源、备选及理由 | 影响范围 | 实际认可或关闭依据 |
@@ -54,17 +59,17 @@ AD §9 明确保留原 SPEC 的完整命令、项目目录、代码风格和工
 
 ### 0.3 公共技术规约、契约与骨架的本次采用
 
-AD准备先读取项目明确采用的公共规范、CONSTRAINTS、ADR及工程事实，已有资料适用时直接引用，不复制平行技术规约。没有取得规范时，列出已查范围和缺口，引导选择已有规范或起草最小候选；技术栈、版本、工程骨架与例外由真实来源及使用者决定。若要另写公共技术规约候选，先明确该辅助目标及写入范围；本次只授权AD时，保留Q并起草独立部分，不静默多写文件。
+AD准备默认读取本 Skill自带的企业应用具体规约与目录规范；项目已有明确规约、目录约定时优先沿用，不复制平行规范。再读取 CONSTRAINTS、ADR、正式契约和实际工程事实，在下表记录默认或项目选定来源、准确版本、适用条款及例外，不另要求采用说明文件。没有可读、适用的具体规约时，先提示根据通用技术规约模板生成，明确技术文档目标与写入委托后起草交审；用户确认后继续 AD。通用模板本身不是实际约束，不能填造选型或静默多写文件。
 
-| 采用ID／类型 | 权威位置／文内版本／条款 | 本次角色与适用范围 | 本AD落实位置／例外 | 实际读取与缺口／决定依据 |
+| 采用ID／类型 | 来源身份／准确路径或URL／文内版本或固定提交／条款 | 本次角色与适用范围 | 本AD落实位置／例外 | 实际读取与缺口／决定依据 |
 | --- | --- | --- | --- | --- |
-| `{BASE：公共规范}` | `{项目已采用规范的实际路径与条款}` | `{本主题适用部分，不以规范代产品规则}` | `{具体章节或明确偏差}` | `{已读内容；未取得或冲突保留Q}` |
-| `{CONTRACT／DATA：共享定义}` | `{唯一Schema、契约正文或提供方AD固定章节}` | `{提供／消费／只读；精确行为范围}` | `{§5、§6、§8及精确条目}` | `{选用依据不等于服务就绪}` |
-| `{SKELETON：工程骨架}` | `{真实模板／源码或采用说明及其实际指向}` | `{工程类型、适用目录和责任}` | `{§9.6；与规范兼容或例外}` | `{已取得／拟采用／未应用／未验证分别记录}` |
+| `{BASE：公共规范}` | `{项目明确规约，或默认企业应用规约的标识、实际路径、文内版本与条款；固定提交或摘要按需}` | `{本主题适用部分，不以规范代产品规则}` | `{具体章节或明确偏差}` | `{已读内容；未取得或冲突保留Q}` |
+| `{CONTRACT／DATA：共享定义}` | `{唯一Schema、契约正文或提供方AD的身份、准确路径、版本与固定章节；标明来源EBC／PBC／主题}` | `{提供／消费／只读；精确行为范围}` | `{§5、§6、§8及精确条目}` | `{选用依据不等于服务就绪}` |
+| `{SKELETON：工程骨架}` | `{本Skill目录规范或项目既有规范的路径、版本及条款；实际模板／源码有则另记来源标识、仓库／路径和固定版本／提交}` | `{工程类型、适用目录和责任}` | `{§9.6；与规范兼容或例外}` | `{已取得／拟采用／未应用／未验证分别记录}` |
 
-本表只组织引用，详细权威仍在来源文件，字段定义不在多表重复维护。单独提供模板时说明配套提示词和兼容范围；实际读取选定资料根的README、阶段索引、阶段清单、模板及本次提示词，不以安装根的索引替代项目已采用副本。已选来源失效或冲突时报告实际差异，不跨宿主、历史样例或最大版本兜底。
+本表只组织引用，详细权威仍在来源文件，字段定义不在多表重复维护。实际读取本模板、选定具体技术规约、目录规范及必要业务原件，由本 Skill直接定位；项目明确采用的副本优先。已选来源失效或冲突时报告实际差异，不按最大版本猜选，也不要求另行准备索引、清单或提示词。
 
-基本交接按路径、正文及文内版本核对，不强制SHA256；同路径人工修改需要回读并判断影响，旧认可不自动转移。正式发布规范或契约已有的不可变版本／摘要要求按其原用途保留。本模板不实现JSON登记、自动选择或项目配置写入。
+基本交接按路径、正文及文内版本核对，不强制SHA256；同路径人工修改需要回读并判断影响，旧认可不自动转移。正式发布规范或契约已有的不可变版本／摘要要求按其原用途保留。交稿路径登记由本Skill处理，本模板不自行选择资料或写入项目配置。
 
 ## 1. 需求覆盖与工程驱动
 
@@ -104,7 +109,7 @@ flowchart LR
 | --- | --- | --- | --- | --- | --- |
 | `{本主题及必要关联范围}` | `{独立主题、独立版本；未形成如实说明}` | `{引用§0.3与唯一权威，不重写正文}` | `{未产生不填已部署或已测试}` | `{设计相容／未知／冲突；实际证据位置}` | `{并存窗口、发布顺序、恢复限制及责任；未知列Q}` |
 
-分别核调用类型、序列化与严格消费者，行为／权限／默认值／状态，数据迁移及并存写入，运行时和装配条件。新增字段、枚举或默认值也可能不兼容；文档同号、SemVer主版本相同或Schema校验通过都不能替代实际语义与消费者核对。设计核对、可交Plan、获准Build和真实集成结果分别表达，不要求所有AD机械升级到最新规范。
+分别核调用类型、序列化与严格消费者，行为／权限／默认值／状态，数据迁移及并存写入，运行时和装配条件。新增字段、枚举或默认值也可能不兼容；文档同号、SemVer主版本相同或Schema校验通过都不能替代实际语义与消费者核对。设计核对、T2工程SPEC交审、T3规划、获准Build和真实集成结果分别表达，不要求所有AD机械升级到最新规范。
 
 ## 3. 功能架构与实现链路
 
@@ -224,6 +229,8 @@ erDiagram
 
 ## 8. 状态、服务规则与恢复
 
+**EARS 使用：**适用的技术行为写清条件、触发事件、执行组件和可观察响应，以及拒绝、失败、结果未知时的处理和副作用。依据 PRD／AC细化并关联本 AD的接口、数据或状态条款；架构图、接口和数据定义仍按相应章节完整说明。
+
 | 规则/状态 ID | 前置条件与触发者 | 确定分支/后置状态 | 权限、责任与事务 | 拒绝/异常/重复/未知 | 恢复与可观察证据 |
 | --- | --- | --- | --- | --- | --- |
 | `{PRD引用与技术细化}` | `{条件}` | `{允许/禁止转换}` | `{契约/数据引用}` | `{错误码及副作用边界}` | `{查询、补偿、审计、人工介入}` |
@@ -291,21 +298,21 @@ erDiagram
 
 | 工程/仓库/模块范围 | 实际骨架或拟采用模板及固定来源 | 初始化/增量内容 | 构建/启动/配置/依赖 | 测试与恢复前提 | 当前事实 |
 | --- | --- | --- | --- | --- | --- |
-| `{一能力不强制一工程}` | `{实际取得或待提供}` | `{只写有依据的工程任务}` | `{精确规则或缺口}` | `{必要条件}` | `{已存在/拟建/待核实}` |
+| `{一能力不强制一工程}` | `{引用第0.3节采用ID；实际取得的模板／源码标识、仓库／路径、版本或固定提交及本地差异；未取得明确待提供}` | `{只写有依据的工程任务}` | `{精确规则或缺口}` | `{必要条件}` | `{已存在/拟建/待核实}` |
 
 固定引用 §9.1–9.4 的命令、目录、代码风格和工程边界，不手工维护第二套不同答案。补充依赖与锁文件、构建制品、环境和密钥引用、部署顺序、特性开关、迁移兼容、回滚和运行交接；测试框架、测试目录、层级及适用覆盖要求由 TestCase §3.1 承接。不给真实凭据，不把配置计划当实际就绪，不代替生产授权；CONSTRAINTS、ADR 等辅助产物仍按原方法和项目约定维护。
 
-骨架引用必须最终落到真实模板／源码、明确版本或来源记录及所选目录；只有目录图或本模板占位行时记录“工程资产未取得”，不能写成可应用工程。优先保留现有仓库及人工代码，采用说明可引用源码及差异，不要求复制另一份平行骨架。适用的pbc-composite／agent-standalone与frontend／backend／agents／jobs按实际选择说明，contracts／shared／tests／delivery的责任不能遗漏；不需要的工程说明依据，不默认一PBC一仓库或一服务。
+目录规范是 AD 的结构输入，真实模板／源码不是 AD起草的统一前置。将规范映射到项目的工程与模块位置，已有、拟建、未取得和未验证分别记录；如另用实际代码模板，再注明真实来源、版本和本地差异，目录图不代表工程已经应用。优先保留现有仓库与人工代码，采用信息直接记本 AD，不另建说明或复制平行骨架。适用的pbc-composite／agent-standalone与frontend／backend／agents／jobs按实际选择说明，contracts／shared／tests／delivery的责任不能遗漏；不需要的工程说明依据，不默认一PBC一仓库或一服务。
 
-AD只选择并定义落实与例外；原Plan据此安排初始化或增量任务、文件责任、验证和恢复；获准Build才实际应用模板或改动工程。现有工程根可记录真实路径，新工程未创建时只写拟建位置和缺口。contracts.lock在正式采用外部契约时形成；templates.lock及生成基线在实际应用并完成相应验证后形成；本次AD写作不创建锁、工程、运行报告或第二套任务tracker。更新须保护人工修改，实际应用失败不能覆盖旧有效基线，细节交I4／I5工程验证。
+AD定义采用、工程落位与例外，T2承接到工程SPEC，T3由原Plan安排初始化或增量任务、文件责任、验证和恢复；获准Build才实际应用模板或改动工程。现有工程根记录真实路径，新工程未创建时只写拟建位置和缺口。锁文件按已采用工具和项目规则处理，不因目录规范另建templates.lock、contracts.lock或生成记录库；已有文件保留其实际用途。本次AD写作不创建锁、工程、运行报告或第二套任务tracker。更新须保护人工修改，实际应用失败不能覆盖旧有效基线，应用和验证结果由对应工程任务记录。
 
-## 10. TestCase 与实施计划交接
+## 10. TestCase、T2工程SPEC与T3实施计划交接
 
 | PRD需求/AC或工程条款 | AD精确落点 | 可观察成功/失败/副作用 | TestCase用例或待形成 | 实施前提与依赖 |
 | --- | --- | --- | --- | --- |
 | `{固定条目}` | `{图/字段/契约/事务/规则}` | `{可断言结果}` | `{固定引用或缺口}` | `{环境/契约/数据/工具/认可}` |
 
-先判断设计能否据以制定 Plan，再由 Plan 获得范围/执行模式认可并核实任务条件；不能把获批 Plan 写成形成 Plan 的前置要求。共享底座或独立技术准备可形成有依据的任务，不借初始化提前生成未定业务字段/权限/接口。
+本AD作为T2工程SPEC的设计依据；T2结合选定PRD及采用资料落实六项并交审，T3再依据选定工程SPEC调用原Plan。Plan形成后取得范围/执行模式认可，执行前核实任务条件；不能把获批Plan写成形成Plan的前置要求。共享底座或独立技术准备可形成有依据的任务，不借初始化提前生成未定业务字段/权限/接口。
 
 ### 10.1 公共变更、例外与影响范围
 
@@ -315,7 +322,7 @@ AD只选择并定义落实与例外；原Plan据此安排初始化或增量任
 
 先确定变化及来源，再定位直接和必要传递消费者，核行为、权限、数据、迁移和运行组合，提出最小处理及恢复。公共定义改变需在其权威位置处理；本主题AD只记录建议和影响，不自行修改公共规范、契约或另一主题。保留原有有效需求及已交付行为的回归，范围降级或移出须有来源和真实决定；不机械重写无关AD、强制升版或重新询问未受影响的已有授权。
 
-独立审查只读标注，使用者可人工处理、明确委托修订、有据不采纳或保留Q；按改动影响复查，零问题不等于业务批准。若JSON清单尚未接入，直接手动传递准确路径仍有效。交原Plan时任务须保留实际PRD、AD、规范、契约、骨架来源及验证依据；Build按获准任务回读，输入变化先核与计划的影响，不靠可变清单链接或旧会话摘要代替正文。
+独立审查只读标注，使用者可人工处理、明确委托修订、有据不采纳或保留Q；按改动影响复查，零问题不等于业务批准。若JSON清单尚未接入，手动传递准确路径仍可作为T2输入。T2工程SPEC保留实际PRD、AD、规范、契约、骨架来源及关键设计；T3原Plan将其落实到任务、结构与行为验收及验证步骤。Build按获准任务回读所需正文，输入变化先核与计划的影响，不靠可变清单链接或旧会话摘要代替正文。
 
 ## 11. 完成核对、问题与版本记录