@givolt/i3-composer-agent 3.0.0 → 3.2.1

package/references/enterprise-sop-resources/technical-baseline/README.md

@@ -1,132 +0,0 @@
-# 公共技术规约：采用说明
-
-<!-- i3:zh-guide:start -->
-## 中文使用说明
-
-按下文完整工程步骤、检查项与验证条件执行。根据任务选择适用步骤，保留证据、风险和退出条件；正文示例中的英文标签在面向用户输出时译为中文。
-
-默认使用简体中文解释、追问及生成报告；用户明确要求其他语言时可切换。原方法正文、引用、阈值和审批条件完整保留。代码标识、路径、命令、工具参数、JSON 键/枚举与原文引用保持原样。
-<!-- i3:zh-guide:end -->
-
-资源版本：0.2.0；通用模板内容版本：v0.0.1；可选企业应用技术规约：v0.0.2。状态：自有分发资源本地候选，尚未发布。实际打包、安装和宿主使用以对应轮次证据为准。
-
-本资源帮助项目固定共用工程约束及其来源。已有规范优先，新项目缺少规范时才起草最小候选。它不是第五个业务阶段、总AD、项目配置或批准记录；不新增Skill、命令、路由和执行器。
-
-## 0. 模板与可选技术规约
-
-| 资料 | 用途与采用边界 |
-| --- | --- |
-| [公共技术规约模板](templates/TECHNICAL-BASELINE.md) v0.0.1 | 根据项目真实资料起草规约，或核对已有规范的覆盖；不默认技术栈 |
-| [企业应用公共技术规约](baselines/企业应用-技术规约_v0.0.2.md) v0.0.2 | 包含已确认的Java／Spring Boot、Vue／TypeScript／Antdv Next、MaxKey／OIDC等技术方向及按需工程约定；项目明确选择后才生效 |
-| [来源与固定依赖说明](baselines/PROVENANCE.md) | 区分来源追溯与运行时资料；附带该规约引用的目录规范／采用说明0.2.0，不自动采用其他会话的新版本 |
-
-随包提供不等于所有项目默认采用。项目已有适用规范时先复用；选择本规约时记录准确路径、文内版本、适用范围及必要差异。多个版本或来源并存且未明确选择时先确认，不按目录最大版本猜选。
-
-项目需要调整时，沿用项目现有规范位置或明确维护项目副本；发行原件与项目规范分别定位。项目自改副本优先，不用发行摘要恢复它，不在升级时覆盖项目规范；不可读或存在冲突时如实报告，不静默切换。
-
-最短任务示例：
-
-```text
-/i3-sop ad
-为当前选定的PRD生成AD，采用随包提供的《企业应用公共技术规约 v0.0.2》。先核项目已有规范和适用范围，按索引定位并完整读取规约及必要目录资料；保留项目自改内容和未决项，生成后交我审阅，暂不进入Plan或Build。
-```
-
-资料由现有入口按阶段索引的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. 资源范围与后续接入
-
-本子目录包含采用说明、通用模板、可选企业技术基线、其必要的定版目录依赖及局部清单。辅助manifest的entry、template、baselines[].path和files[].path均相对该manifest；基线requiredSources的path也相对同一manifest。来源追溯页不是额外业务阶段或统一必读业务输入。
-
-上层stages.json登记辅助资源根与清单，局部baselines条目列出可选规约的身份、版本和必要来源；不设置默认采用，不增加配置系统、审批字段或自动调度。清单的文件摘要固定发行资料，本轮变化检查不用于恢复或覆盖项目副本。
-
-B01—B05和原S10记录保留各自版本与验证范围。本次只整理分发资源及引用，打包／安装可读性另取新证据；静态、安装、真实模型行为、项目采用与正式发布分别判断。原型仍按需，TestCase不作为Plan统一必需输入，原Spec及Plan／Build停点不变。

package/references/enterprise-sop-resources/technical-baseline/assets-manifest.json

@@ -1,101 +0,0 @@
-{
-  "schemaVersion": 1,
-  "resourceId": "i3-enterprise-sop-technical-baseline",
-  "resourceVersion": "0.2.0",
-  "resourceRole": "auxiliary-shared-engineering-guidance",
-  "status": "local-technical-baseline-distribution-candidate",
-  "businessStage": false,
-  "templateContentVersion": "v0.0.1",
-  "entry": "README.md",
-  "template": "templates/TECHNICAL-BASELINE.md",
-  "files": [
-    {
-      "path": "README.md",
-      "sourceSha256": "9fd3b21cc2f45722d289c7dab3cb75e082865f49ddf1b16d3b2595116dbbcc46",
-      "sha256": "dfcbe6868a29cb99b6a26e779301bebf5c0b53658039a9eb6301553aea143f6c",
-      "role": "adoption-guidance"
-    },
-    {
-      "path": "templates/TECHNICAL-BASELINE.md",
-      "sourceSha256": "f14db13050b97abc3b1bbe253a12218316127df2b3f96b4593e598aadf90b6f1",
-      "sha256": "83f425b2333a5dd10b79a89007a0732b4d273cdc694fd9a7b93bc6527fd5c2f1",
-      "role": "auxiliary-engineering-template"
-    },
-    {
-      "path": "baselines/企业应用-技术规约_v0.0.2.md",
-      "role": "optional-project-technical-baseline",
-      "sourceSha256": "04d42104f4e08ec1150e57930c785e22e8518c735627f5784df255e07cb367f6",
-      "sha256": "c355a720526616f70cc9498452883ca577920f239718905950cdaad7b40709cd"
-    },
-    {
-      "path": "baselines/PROVENANCE.md",
-      "role": "baseline-distribution-provenance",
-      "sourceSha256": "ffbdd653c682cddc3bddcc0a06314c12165919ab0ce4193c5e672edda14632cb",
-      "sha256": "70f400e695813ff310b2f02402520ab19f0a884fb7c2e6c5ddbd8ea7a4262668"
-    },
-    {
-      "path": "references/engineering-directory-v0.2.0/directory-standard.md",
-      "role": "fixed-baseline-directory-dependency",
-      "sourceSha256": "3e9445d35e6ee5cf90bf2ba7de07dc26c82c7103ffe2ac50f32e5e99af660570",
-      "sha256": "08160c392465eb727cdd4e62aadd0ed024d0d578643e5015b4b71534836739b4"
-    },
-    {
-      "path": "references/engineering-directory-v0.2.0/adoption.md",
-      "role": "fixed-baseline-adoption-dependency",
-      "sourceSha256": "2ce821e718007ee2bf259e67db456183846a30b92da72a39982bf2f136631afa",
-      "sha256": "dd99b39c6a2e3f69592f8566455c5d73f35decb4b6ad61c797ba92038edbaf0a"
-    }
-  ],
-  "sha256Scope": "source-and-pure-brand-reference-mapping-not-npm-install-proof",
-  "dependencies": [
-    {
-      "path": "../ad/templates/AD.md",
-      "role": "ad-linkage-reference"
-    },
-    {
-      "path": "../handoff-contract.md",
-      "role": "native-plan-handoff-reference"
-    }
-  ],
-  "provenance": [
-    {
-      "path": "history/sop-design/20261018-before-b01-technical-baseline/technical-baseline-design.md",
-      "sha256": "30ce6f20516321ac651b2c443ae0007d1e3ee1c9dc8ea021552ac920367c97eb",
-      "included": false,
-      "role": "immutable-maintenance-design-provenance-not-runtime-dependency"
-    }
-  ],
-  "integration": {
-    "registeredInParentStageIndex": true,
-    "registeredInCustomRuntimeFiles": true,
-    "includedInParentResourceBundle": true,
-    "packagePolicy": "included-reference-assets-with-per-artifact-verification",
-    "automaticWorkflowActivation": false,
-    "newSkillOrCommand": false,
-    "proofBoundary": "File presence, pack, installation, model reads and project adoption are distinct."
-  },
-  "publication": {
-    "published": false,
-    "businessCandidateApproved": false
-  },
-  "baselines": [
-    {
-      "id": "enterprise-application",
-      "title": "企业应用公共技术规约",
-      "documentVersion": "v0.0.2",
-      "path": "baselines/企业应用-技术规约_v0.0.2.md",
-      "explicitAdoptionRequired": true,
-      "provenance": "baselines/PROVENANCE.md",
-      "requiredSources": [
-        {
-          "path": "references/engineering-directory-v0.2.0/directory-standard.md",
-          "contentVersion": "0.2.0"
-        },
-        {
-          "path": "references/engineering-directory-v0.2.0/adoption.md",
-          "contentVersion": "0.2.0"
-        }
-      ]
-    }
-  ]
-}

package/references/enterprise-sop-resources/technical-baseline/baselines/PROVENANCE.md

@@ -1,40 +0,0 @@
-# 企业应用技术规约来源与分发说明
-
-<!-- i3:zh-guide:start -->
-## 中文使用说明
-
-按下文完整工程步骤、检查项与验证条件执行。根据任务选择适用步骤，保留证据、风险和退出条件；正文示例中的英文标签在面向用户输出时译为中文。
-
-默认使用简体中文解释、追问及生成报告；用户明确要求其他语言时可切换。原方法正文、引用、阈值和审批条件完整保留。代码标识、路径、命令、工具参数、JSON 键/枚举与原文引用保持原样。
-<!-- i3:zh-guide:end -->
-
-## 来源资料
-
-本目录的[企业应用公共技术规约 v0.0.2](企业应用-技术规约_v0.0.2.md)是明确确认过的可复用技术基线。其直接来源为《软件架构设计 Specification 模板》v0.6（2026-09-23），并结合公共技术规约模板和2026-10-20逐项确认结果整理。原架构模板含历史总体设计／MVP组织说明，仅作来源追溯，不是当前SOP的第二套生成入口或项目必读依赖。
-
-| 来源 | 固定内容摘要（SHA-256） | 用途 |
-| --- | --- | --- |
-| 整理前的企业应用技术规约v0.0.2 | `989763c95dcccd6c79198b3d68b1669be52b399a523492219f8b3fbe236d49de` | 保存确认过的正文；本次仅整理位置、链接和示例中的资源定位方式 |
-| 软件架构设计Specification模板v0.6 | `0e3d73df26a10bb741f1f46e55161240b741f8afca5a61b9e87b35abeeb64364` | 原始技术来源；完整原稿保存在维护历史，未作为运行时资料分发 |
-| 公共技术规约模板v0.0.1 | `f14db13050b97abc3b1bbe253a12218316127df2b3f96b4593e598aadf90b6f1` | [通用模板](../templates/TECHNICAL-BASELINE.md)；模板正文未改 |
-
-摘要用于识别本次来源内容，不要求业务JSON新增摘要、审批或任务字段，也不阻止项目人工修改已采用副本。
-
-## 工程目录依赖
-
-技术规约v0.0.2已经确认引用目录规范／采用说明0.2.0，因此附带该版本的必要正文快照。来源为2026-10-20规约确认时保存的原件；不从正在调整的工程骨架工作树选取较新内容，不把0.3.0标成0.2.0。
-
-| 必要资料 | 内容版本 | 固定内容摘要（SHA-256） |
-| --- | --- | --- |
-| [工程目录规范](../references/engineering-directory-v0.2.0/directory-standard.md) | 0.2.0 | `3e9445d35e6ee5cf90bf2ba7de07dc26c82c7103ffe2ac50f32e5e99af660570` |
-| [采用说明](../references/engineering-directory-v0.2.0/adoption.md) | 0.2.0 | `2ce821e718007ee2bf259e67db456183846a30b92da72a39982bf2f136631afa` |
-
-两个正文逐字保留。目录说明是设计依据，不是已经生成的代码框架或工程验收证明。以后采用新版目录规范，需要明确核对变更与适用范围；本次没有升级其技术约定。
-
-## 维护历史
-
-规约v0.0.1、v0.0.2整理前全文、原HTML阅读页、来源模板及既有来源记录均保存在维护工作区的history；原S10候选、执行轨迹、失败和报告完整保留。它们不是同事安装后的运行时依赖。
-
-维护记录标识：`20261020-before-enterprise-technical-baseline`、`20261020-before-technical-baseline-confirmation`、`20261020-before-technical-baseline-distribution`。分发正文使用包内相对引用；具体安装路径以当前宿主的安装清单为准。
-
-模板内容版本v0.0.1、基线文档版本v0.0.2、辅助资源版本0.2.0和上层资料组合版本0.14.0各自管理，不等同于i3软件发行版本。此整理仍是本地候选，不表示已经发布或被某个项目采用。

package/references/enterprise-sop-resources/technical-baseline/references/engineering-directory-v0.2.0/adoption.md

@@ -1,112 +0,0 @@
-# 工程目录规范的采用与原 Plan／Build 交接
-
-<!-- i3:zh-guide:start -->
-## 中文使用说明
-
-按下文完整工程步骤、检查项与验证条件执行。根据任务选择适用步骤，保留证据、风险和退出条件；正文示例中的英文标签在面向用户输出时译为中文。
-
-默认使用简体中文解释、追问及生成报告；用户明确要求其他语言时可切换。原方法正文、引用、阈值和审批条件完整保留。代码标识、路径、命令、工具参数、JSON 键/枚举与原文引用保持原样。
-<!-- i3:zh-guide:end -->
-
-版本：0.2.0。配套：[工程目录规范](directory-standard.md)。适用于明确选择该规范的新项目或现有项目，不随安装自动启用。
-
-## 1. 采用时明确什么
-
-先确定真实业务项目根、当前能力／需求主题、所选 AD 及已有代码位置。项目已有工程规范时优先复用；本资源补充目录职责或映射，不重选技术栈，也不把维护 i3 Skill 的仓库当成业务工程根。
-
-目录规范可以在 AD 准备时选定，无需另外调用一个工程骨架命令。技术栈、工程内部布局及构建命令仍由公共技术规约、实际配置和 AD 明确。目录规范能够先采用；尚未确定的技术决策只限制依赖它的设计或实施任务。
-
-将采用结果写入项目已有工程说明；没有合适位置时，可使用 docs/engineering/engineering-layout.md，或直接写在 AD 的相应章节。以下是填写要点，实际路径和状态据实填写，不为每个项目重复建立全部文档：
-
-| 项目 | 填写内容 |
-| --- | --- |
-| 采用来源 | 本目录规范的真实可读路径和内容版本 0.2.0；使用项目副本时保留其来源及本项目修改说明 |
-| 组织方式 | pbc-composite 或 agent-standalone；选择理由与项目根 |
-| 实际工程映射 | 工程稳定标识、类别、实际根、已有／拟建、业务模块、共享维护方与消费者 |
-| 配套依据 | 当前 AD 的身份／版本／路径、公共技术规约、必要契约及已有代码 |
-| 目录例外 | 现有结构或框架惯例与规范示例的差异、理由、影响及明确采用情况 |
-| 验证要求 | 本次文件落点核对及实际构建／测试方法；尚无代码时写待实施，不预填通过 |
-
-使用项目已采用副本后，以该副本为本次输入；发行资源更新不覆盖它。原路径失效、版本含糊或映射冲突时先说明准确缺项，不静默改读另一个来源。
-
-## 2. AD 如何引用
-
-沿用现有 AD 模板的栏目，不修改模板或原 Spec：
-
-| 现有 AD 位置 | 本次承接内容 |
-| --- | --- |
-| §0.3 公共技术规约、契约与骨架的本次采用 | 引用目录规范或项目采用说明的准确路径／版本，说明适用工程 |
-| §9.2 项目目录与维护位置 | 工程根、模块／源码、配置、测试、契约和运行装配的真实或拟建路径及 owner |
-| §9.6 工程骨架采用与落地 | 区分现有工程事实与拟建内容；落实当前技术选择、构建／启动／验证／恢复条件及依赖缺口 |
-
-其他版本的 AD 使用同义栏目。AD 的整体技术架构图、功能架构图、数据实体关系及必要详细设计仍完整保留，不能以目录规范替代。
-
-目录标准是实际可读的规范输入，不能据此把“可运行代码模板已取得”或“工程已生成”填为成功。未采用代码框架模板时可据实写“目录规范已采用；工程拟建；未采用代码框架模板”；语言／框架代码由后续获准任务实现。已有代码则引用真实代码／配置。若本项目另行要求复用特定代码模板，仍需取得它，不由本规范替代。
-
-一个 PBC 多份主题 PRD 的各自 AD 引用同一项目规范，并分别映射相关模块；不因 PRD 数量或版本变化重复创建工程。
-
-## 3. 交给原 Plan 的方式
-
-原 Plan 读取 SPEC.md 或等效规格。选定 AD 与其准确 PRD、公共技术规约、契约及目录采用说明共同提供本次等效规格；原 SPEC 六项内容须足够明确。独立 TestCase 为可选输入，已有且适用就引用；原型按需，可与 AD 并行。
-
-手动方式直接提供上述实际路径。已有三字段 JSON 时，可让本次任务先解析 selected 中当前主题的 engineeringSkeleton 及配套路径，再实际读取正文；选择路径不等于读取成功、认可或实施许可。无需为了目录规范新建 JSON，也不把工程说明写入新的顶层字段。
-
-先按当前主题读采用说明和必要规范条款，再读该主题 AD／PRD、所涉代码和共享消费者；不一次加载全部历史、所有主题或所有工程源码。跨主题共用约束及直接依赖仍须读齐。
-
-在项目根使用以下提示；替换方括号中的实际路径。它是原命令的明确任务上下文，不是新增命令参数：
-
-```text
-/i3-plan
-为本次已明确的需求范围制定计划：
-AD：[实际 AD 路径]；准确 PRD：[实际 PRD 路径]。
-公共技术规约：[已采用规范路径]；工程目录采用说明：[实际路径]。
-必要共享契约及已有代码：[实际路径；没有则说明不适用]。
-请实际读取这些来源；缺项或冲突先列出，不猜技术版本。
-按 AD 的工程／模块映射拆任务，明确新增或修改文件相对项目根的位置、
-工程负责人／共享依赖、验收条件及实际验证方法。
-将源码、配置和测试放入已采用位置；已有结构的例外明确写在计划里。
-保留原 Plan 的默认产物、唯一任务目标和审阅停点，不改业务稿。
-```
-
-计划沿用 tasks/plan.md 和原方法确定的唯一任务目标；默认文件目标为 tasks/todo.md，采用其他 tracker 时不复制竞争状态。不同未完成工作不覆盖。工程落点不是把模块名写入任务即可：任务的 Files likely touched 应包含预计路径，验收条件要核对真实新增／修改文件；实施中合理新增文件也须按映射核对。
-
-## 4. 原 Build 如何执行
-
-计划满足原有认可及执行条件后，原 Build 从计划取任务。任务必须指向当前 AD、目录采用说明和所需规范，使执行时能实际回读，而非只相信计划摘要或 JSON 的存在。
-
-```text
-/i3-build
-执行当前计划的下一项获准任务。
-先回读该任务引用的 AD、目录采用说明及所需规范／代码。
-按已采用工程根和模块路径实现；出现目录冲突先说明位置、原因和建议，
-不自行另建同名工程或把源码放进 spec、tasks、文档模板目录。
-完成原有验证后，对照任务及目录映射列出实际变更文件和落点差异。
-业务稿、人工代码和已完成任务按原规则保留。
-```
-
-原 /i3-build auto 使用同一份获准 Plan 和目录映射，保持原有 spec/ 识别、Git、计划认可、TDD／构建及逐任务执行条件。它不会因为本资源存在而自动读取规范；需要时在本次任务上下文明确引用。企业跨阶段 auto／调度不在本资源范围。
-
-规范期望目录约束被设计、任务和验收共同落实，不提供拦截一切写入的 Hook。未实际读取、任务没有落点或实际文件越界时，不声称目录验收通过。
-
-## 5. Build 后如何核目录
-
-在实际业务项目中核对本次任务新增、修改和必要删除的文件。可用 git status --short、针对任务的 git diff／文件清单及实际配置获取事实；不把其他人的未提交文件混作本次结果，也不只看空目录树。
-
-| 核对项 | 通过条件 |
-| --- | --- |
-| 来源与范围 | 当前 AD、目录采用说明及任务可回读，采用版本和实际工程根一致 |
-| 文件落点 | 每个变更文件都能映射到工程／模块、共用资产或原有管理文档位置；例外有明确依据 |
-| 工程边界 | 同一工程标识未重复创建，未按每份 PRD 再造底座；没有未经采用的顶层代码目录 |
-| 共享责任 | 契约、共用代码及跨工程测试各有实际维护位置与相关消费者，未复制其他主题的共享权威 |
-| 构建与测试 | 实际配置的源码、资源、测试和产物路径与采用映射一致；完成本次要求的原有验证 |
-| 人工内容 | 既有目录、项目自改规范、人工代码和已完成任务保留；无整仓覆盖或未经说明的移动／删除 |
-
-结果沿用原工程验证记录或本次任务总结，至少列出“文件／实际位置／采用依据／差异处理／验证结果”。不另建任务完成率或审批状态文件。构建产物、依赖、缓存按实际工具配置和忽略规则处理，不因出现 dist、target、node_modules 等就判源码越界。
-
-落点有偏差时先标注准确位置、影响、推荐和可选处理（按规范调整，或明确采用例外后同步 AD／Plan），不自动移动人工代码或改业务稿。目录核对通过与构建、业务测试、独立审查、Ship 就绪及发布分别记录。
-
-## 6. 现有工程与后续变更
-
-现有项目先映射当前目录及实际命令。已有人采用 services/api、web 等布局时，在采用说明中映射到 backend、frontend 的逻辑职责；不为统一外观改名搬迁。真正的目录迁移另列任务，核导入、构建、CI、部署及消费者影响并保留历史。
-
-规范版本更新只提供新的参考；先比较采用版本与项目修改，明确受影响工程、AD 和未完任务，再决定是否采用。该资源不覆盖项目副本、不生成成功锁、不实现代码模板三方自动升级。I5 的进一步更新／存量辅助另行确认，原先较重的代码模板方案保留在历史中。

package/references/enterprise-sop-resources/technical-baseline/references/engineering-directory-v0.2.0/directory-standard.md

@@ -1,119 +0,0 @@
-# 工程目录规范
-
-<!-- i3:zh-guide:start -->
-## 中文使用说明
-
-按下文完整工程步骤、检查项与验证条件执行。根据任务选择适用步骤，保留证据、风险和退出条件；正文示例中的英文标签在面向用户输出时译为中文。
-
-默认使用简体中文解释、追问及生成报告；用户明确要求其他语言时可切换。原方法正文、引用、阈值和审批条件完整保留。代码标识、路径、命令、工具参数、JSON 键/枚举与原文引用保持原样。
-<!-- i3:zh-guide:end -->
-
-内容版本：0.2.0。适用范围：明确采用本规范的业务工程。目标是让 AD 约定的工程与模块位置，继续落实到原 Plan 的文件范围和原 Build 的真实产物。
-
-## 1. 基本规则
-
-- 先确定实际业务项目根。工程相对路径均从该根解析；安装的 Skill／资源目录及 i3 维护工作树不是业务输出根。
-- 规范约定外层职责；工程内部遵循项目已采用的语言／框架惯例，具体位置由 AD 和真实配置明确。
-- 只采用当前需要的工程类别；实际有内容时再建目录。空目录不等于已交付工程，Git 也不保存空目录。需要先说明预留位置时可写有意义的 README，无需到处添加占位文件。
-- 新建工程标识使用稳定、可区分的小写短横线名称，例如 admin-web、business-api。语言内部包名／模块名遵循其自身规则；现有项目保留原名并建立映射。
-- 工程标识与 PRD 主题、版本分开。同一工程可承接多主题；新增或修订 PRD 不自动复制工程。同一路径不得指向两个不同工程身份。
-- 目录不是进程、服务、仓库或部署边界。AD 明确源码工程、业务模块、运行应用和部署单元之间的实际关系。
-
-## 2. PBC 组合工程：pbc-composite
-
-以下是逻辑位置，按实际选择形成，不要求一次创建全部目录：
-
-```text
-project/
-├── README.md                     工程入口、工程清单与真实命令
-├── spec/{能力}/                  当前业务文档及版本历史
-├── tasks/
-│   ├── plan.md                   原 Plan 的默认计划
-│   └── todo.md                   仅在采用默认文件任务目标时维护
-├── docs/engineering/             按需：项目规范／采用说明
-├── frontend/<engineering-id>/    按需：前端源码工程
-├── backend/<engineering-id>/     按需：业务后端源码工程
-├── agents/<engineering-id>/      按需：本项目内 Agent 源码工程
-├── jobs/<engineering-id>/        按需：任务源码工程
-├── contracts/                    按需：受控接口与事件定义
-│   ├── exports/                  对外提供的契约
-│   ├── imports/                  明确采用的外部契约
-│   ├── internal/                 本项目工程间契约
-│   └── events/                   事件契约
-├── shared/                       按需：明确复用和维护边界的代码
-├── tests/cross-engine/           按需：跨工程验证
-└── delivery/                     按需：运行装配与部署资料
-    ├── local/                    本地依赖与联调配置
-    ├── dapr/                     仅在明确采用 Dapr 时使用
-    └── deploy/                   目标环境部署配置
-```
-
-使用现有 SOP JSON 时沿用其已采用位置；不要求为了目录规范再创建 .i3/project.yaml、templates.lock、contracts.lock 或生成记录库。已有项目或工具确有这些文件时按其真实用途保留。
-
-spec/ 下按业务能力组织文档。一个 EBC 的 BRD 识别相关 PBC；同一 PBC 的多个需求主题各有独立 PRD 版本及准确对应的 AD／TestCase，配套版本号可以不同。既有已采用文档目录不因本规范迁移。
-
-## 3. 独立 Agent：agent-standalone
-
-单一 Agent 应用可以把所选框架的源码与构建配置直接放在项目根下，避免无意义的 agents/<id> 包裹。按实际能力组织，不强制以下所有内容存在：
-
-```text
-agent-project/
-├── README.md
-├── spec/{能力}/
-├── tasks/                       原 Plan 和唯一任务目标
-├── docs/engineering/            按需：规范采用与工程说明
-├── <框架构建／配置入口>
-├── <源码根>/                    AD 确定的本应用源码
-├── <程序测试位置>/              采用框架的原有测试位置
-├── evals/                       按需：Agent 行为样例及评价
-├── contracts/                   按需：实际提供／消费契约
-└── delivery/                    按需：运行装配／部署
-```
-
-采用说明把主 Agent 工程映射到项目根“.”。日后确需组合多个可独立构建工程时，按 AD 明确新增位置，不能因为模板示例存在 agents/ 就把当前代码自动搬进去。
-
-此处 Agent 是业务工程；3.1.0 规划的企业研发调度 Agent 是另一项产品能力。外部 Agent 服务只引用正式契约和消费者适配，不把其源码和内部 AD 复制到本项目。
-
-## 4. 四类工程与配套目录职责
-
-| 类别或目录 | 应承接内容 | AD 需明确的实际位置与责任 |
-| --- | --- | --- |
-| frontend | 页面、路由、交互状态、客户端接口适配及适用 UI 测试 | 工程根、源码／页面模块、配置、测试、资源和构建产物；响应式／可访问性要求；业务授权仍由服务端落实 |
-| backend | 正式业务规则、授权、状态、数据及外部适配 | 工程根、包／模块、接口、配置、迁移与测试；数据 owner、事务、失败恢复及真实命令 |
-| agents | Agent 职责、模型调用、授权工具与必要运行记录 | 工程根、源码、工具、提示／配置、程序测试与行为评价；不得把分析建议冒充正式业务状态 |
-| jobs | 定时、异步、批处理等任务逻辑及必要执行记录 | 工程或模块位置、触发入口、调度配置、幂等、失败／重试与恢复；是否独立运行由 AD 决定 |
-| contracts | API、事件及必要共享数据协议 | 提供／消费方、正式来源／版本、维护位置；事件的归属位置只保留一处权威，不因分类重复拷贝 |
-| shared | 有真实复用者的共用实现 | 唯一维护方、消费者、依赖方向；不把业务归属不清的代码全放 shared |
-| tests/cross-engine | 多工程联调、共享契约及回归验证 | 需求／AC 来源、测试入口、数据、环境和结果位置；单工程测试仍跟随该工程惯例 |
-| delivery | 本地连接、运行装配及部署描述 | 运行身份、依赖、环境及部署单元映射；不保存真实密钥，目录存在不等于已部署 |
-
-jobs 可以是已有后端工程里的模块；Agent 也可以是已有工程中的组件。此时在 AD 映射真实子路径，不为凑四类顶层目录制造第二个工程。
-
-## 5. 工程内部目录与实际产物
-
-本规范不强制所有语言使用同一份 src/modules 布局。例如采用 Java 常规布局时，源码和测试可在 backend/business-api/src/main/java 与 src/test/java；采用前端框架时，其源文件可在 frontend/admin-web/src。准确目录、包名、扩展名和命令来自已采用技术规约、AD 和实际构建配置，这些例子不是技术选型。
-
-AD 至少映射本次需要的源码／业务模块、配置、测试、契约、迁移及运行装配位置；不适用项有依据说明。Plan 进一步列出每项任务预计新增／修改的文件及路径。Build 按获准任务生成有实际内容的文件，未选择工程不预建空架子。
-
-编译、打包、依赖和缓存产物遵循真实工具配置，例如 dist、target 等；在采用说明中必要时说明输出及忽略规则。不能把构建输出位置的差异等同于业务源码越界，也不通过移动编译产物掩盖源码位置错误。
-
-项目根可按工具实际需要保留构建配置、workspace／CI 等公共文件，路径在 AD 或计划中说明。不要为满足外层分类，把框架入口强行放到无法正常工作的目录。
-
-## 6. AD、原 Plan、原 Build 的约束链
-
-| 环节 | 必须明确的内容 | 如何核对 |
-| --- | --- | --- |
-| 采用说明／AD | 规范版本、项目根、所选组织方式、工程与模块映射、共享责任和例外 | 读真实来源与当前代码，区分已有、拟建及未定事项 |
-| 原 Plan | 当前 AD／采用说明引用；每项任务文件路径、依赖、验收与验证方法 | 任务可以落到真实或拟建位置，共享文件不安排互相覆盖的独立写入 |
-| 获准原 Build／Build auto | 实际回读任务所需来源，按映射生成／修改源码、配置、测试 | 对照任务和实际变更文件核落点，再完成原有测试／构建与任务处理 |
-| 原测试／Review／Ship | 实际代码、结果与本次范围 | 目录检查只是适用验收之一，不取代功能正确性、独立代码审查或发布条件 |
-
-原能力不会因为目录规范文件存在就自动消费它。显式任务或已采用项目指引负责把路径交进去；原版 Skill、命令、默认 Plan 和任务权威保持。具体可复制说明及核对步骤见 [采用与交接](adoption.md)。
-
-## 7. 存量工程、人工修改与变更
-
-已有 web、services、server 等工程组织先按现状映射到逻辑职责，不要求立即重命名。例外要写清实际路径、原因和适用范围；不能一边把旧结构认定有效，一边在新规范目录里生成第二套同名源码。
-
-新增需求优先落到原工程的相应模块。撤销未实施需求不自动删除工程或契约；功能退役通过明确的移除、迁移和回归任务处理，保留已完成历史及其他主题的共享依赖。目录规范变更不自动扩大已有任务授权。
-
-采用后的项目副本、人工源码与原始失败记录保留。升级资源不覆盖项目自改内容；实际迁移先评估导入、构建、测试、CI／部署和消费者影响，不用重建目录宣布迁移完成。