@givolt/i3-composer-agent 3.0.0 → 3.1.0

package/docs/ui-prototype-native/MAIN-SESSION-REPORT.md

@@ -1,66 +0,0 @@
-# 主会话原型改造验证报告
-
-<!-- i3:zh-guide:start -->
-## 中文使用说明
-
-按下文完整工程步骤、检查项与验证条件执行。根据任务选择适用步骤，保留证据、风险和退出条件；正文示例中的英文标签在面向用户输出时译为中文。
-
-默认使用简体中文解释、追问及生成报告；用户明确要求其他语言时可切换。原方法正文、引用、阈值和审批条件完整保留。代码标识、路径、命令、工具参数、JSON 键/枚举与原文引用保持原样。
-<!-- i3:zh-guide:end -->
-
-日期：2026-10-17。源码分支：feature/prototype-native-pilot。首期为CodeBuddy＋admin-list小模板＋Vue 3/antDv-next设备流程。实施及样例技术验收完成，补充复核后的当前收据已完成；用户视觉/业务评审仍为pending-review。正式main与上游保全基线未变，未合并或发布。
-
-## 已完成改造
-
-取消prototype-specialist专责Agent、常驻分派规则及父子JSON强制；自然语言、using、/i3-prototype、直接Skill均由主会话执行。using以原版aeac41d4为基线，只增加普通原型分支和Quick Reference行；移除两行后SHA256为30787ef2c77bf1a4729fffed0f6523ba6fcbe81bdc436b36371b78c21394d3c3。三宿主命令格式仍是薄入口，不承担企业调度。
-
-企业SOP在外层组织PRD、设计取舍、制作、技术验证、人工认可与工程交接；原型Skill按需复用前端、官方框架、UIUX和浏览器方法。业务/技术规格、任务tracker及正式发布仍依上游方法，不增加企业审批库或专属Agent。
-
-HTML继续可离线修改，是内容和能力输入。生成原型采用真实ConfigProvider/Table/Form/Drawer等组件；本次需求明确绑定“明亮、暗黑、清新、科技”，首次默认明亮，页面内切换，不重挂应用或丢失筛选/页码/选择/未保存输入。旧HTML及未绑定主题的固定实例不自动加入主题、不重写摘要。模板内容和最终框架效果分别验证。
-
-已有安装按清单归属＋已审原字节指纹安全退出旧角色/规则；修改过、来源不明的受管退出资产会阻断，force不绕过；用户文件保留。维护宿主工具不自动成为上游/全局Hook。
-
-## 主要实证
-
-证据根：工作区artifacts/verification/prototype-main-session-20261017/。
-
-| 范围 | 实际结果 | 证据 |
-|---|---|---|
-| 源码与分发 | 全回归528/528、零跳过；实际打包/安装各340/340；最终冻结复验以相邻JSON/log为准 | source-final-guidance.*、source-delivery-final.*、candidate-3-*-test.*、delivery-package/ |
-| 退出与升级 | 真实旧tgz→新tgz项目/global角色5→4，用户规则保留；16项迁移保护通过 | installation/real-upgrade-RESULT.json |
-| 离线HTML | 实际断网file://修改、展示、同步提取，3本地请求、0外部请求/console错误，未起服务 | offline-html-check/ |
-| CLI四入口 | 真实Skill调用、完整分析回传，无Agent；734文件前后同一，SDK/工具/缓存未变 | ENTRY-MATRIX.json、probe-*/ |
-| CodeBuddy IDE入口 | 实际识别/展开命令、UseSkill及主会话中文回传，732安装文件比较无异常差异 | ide-command/ |
-| 全新业务冷生成 | 100工具/22MCP，无Agent，processComplete=true；官方/前端/browser Skill及真实UIUX查询/设计/构建；7/7单测、类型与构建通过 | cold-main-session-v2/、cold-v2-preflight.json |
-| 完整原型专项 | 23/23、零console错误/警告，同一candidate/build，含四主题/状态/偏好/隔离、Drawer动效/毛玻璃/焦点、窄屏/键盘和故障对照 | cold-project-v2/prototypes/main-devices/qa/runs/chrome-1792253902290/ |
-| UIUX实际Skill复查 | Skill(ui-ux-pro-max)真实加载，31工具，零文件/缓存变更；采纳/拒绝与效果分别核对，无阻断 | uiux-final-review/ |
-| 真实交互DevTools补录 | 实际browser Skill，44次MCP/51工具，trace含13 click/1 input，六类观测与操作后console/network已保存；48轮上限后无最终模型回复，未算该轮自动完成 | devtools-interaction-supplement/ |
-| 独立输入/焦点诊断 | 实际固定MCP原生Backspace恢复21；空名保存拒绝、错误/焦点/抽屉/列表均正确，console0 | mcp-empty-fill-diagnostic/run-006/ |
-| 审定与交付 | 原始事件审计、修正登记后build/browser/devtoolsReview/delivery均current，nextAction=return-result；passed、pending-review | FINAL-COLD-AUDIT.json、audited-state-final.json、实例qa/delivery.json |
-| 兼容保护 | 337摘要/模式未变、原先REPORT/TASKS字节前缀保留；旧v1/v2固定合同不追随新模板 | protected-current.json |
-
-当前原型：main-devices/r001，candidateDigest=793e0a1eee86bad6e9a081548840cc6408aded05347fa8485f050611f71f1954；buildId=b-193a4dfa2f1be867ceb1，buildDigest=193a4dfa2f1be867ceb103690bdc451ceabcbee0ef29875d388fc420c88f637c。
-
-## 发现、修复与证据纠正
-
-真实冷运行发现原生分页内部隐藏链接仍能获得焦点。中央starter只将page项渲染为不可聚焦span，保留外层LI及鼠标/键盘；新固定快照启用paginationFocusGuard，旧快照缺字段维持原合同。AX普通鼠标可复现、故障负例能失败、修复后的23项与零候选warning均有实证。
-
-CodeBuddy2.168.2初层fill参数scalar与后层完整对象换ID格式，维护宿主已做极窄兼容（固定managed1.11.0、非只读、精确PreToolUse和fill），19/19及独立审查通过，实际新补录也无auditDenied。不能据此建立通用跨层deny绑定保证；实际文件边界另由OS策略及差异证明，不扩大写目录，不改上游Hook/全局配置。
-
-独立审计发现初版模型报告的时区错误、调用ID占位、MCP网络摘要和冷缓存措辞不实，性能trace只覆盖reload。原始字节与原最终回复保留，未接受其自评结论。当前报告从真实UTC/call_*生成；MCP仅确认URL/状态，真实响应字节SHA来自独立Playwright观测。UIUX原生成有provider查询但没有Skill调用，真实Skill复查由后续只读阶段完成，不改写历史。
-
-补录的完整五分钟交互trace解压70,406,491字节，登记器64MiB边界正确拒绝。原件未改；以明确标注来源、摘要和窗口的前120秒连续原事件导出登记（34,338,470字节、7 click/1 input），不改上限、不筛事件类别、不宣称该片段就是完整录制。索引在实例qa/devtools/audited/trace-excerpt-index.json。
-
-另独立复现固定MCP1.11.0的空fill直接清DOM而未发input/change：查询/校验仍读旧绑定。正常键盘/Playwright为空可正确工作。真实MCP以当前文本和末尾光标为准逐次Backspace验证通过；Meta+A/Control+A未全选、空格可能追加旧值等失败保留。自有Skill已补实测指引，上游浏览器Skill/MCP/组件库不改。该工具事件问题与宿主scalar参数兼容分别记录。诊断run-004在抛弃的独立profile中误做一次非空保存已披露；通过run-006无成功保存，应用文件、共享模型profile、旧QA均未变。
-
-第一次源码/机械浏览器失败、第一次冷生成120轮未完、维护者误期待revise自动刷新快照而停止的阶段、补录48轮上限、客户端参数/解析错误、64MiB拒绝均保留。revise只接受已整理输入摘要，不自动迁移framework；旧实例未手补新字段。
-
-## 结论边界
-
-首期样例经过实际主会话制作、专项回归及补充复核后具备待评审交付条件。不能扩展为所有模型/宿主/页面或单轮无人复核都可靠。短种子未触发长文本ellipsis的专门视觉用例，未声称该效果已经实测。技术验证不代替人类认可，不执行confirm-baseline。
-
-四CLI入口和IDE入口来自C1；C2的using/三命令字节相同，C2完成新业务冷生成。其后仅自有输入事件指引与维护文档修订；最终包与C2实现/模板/框架/浏览器执行器/入口的字节比较、精确包摘要和最终打包/安装结果以delivery-package/及FINAL-PACKAGE.json为准，不冒认最终说明版本另跑了一次完整冷生成。
-
-只读CLI的工具限制、OS写保护及零缓存结论不外推到任意IDE/全工具配置；IDE实际界面请求保留无害残留前缀，项目根重定位只归一确切安装路径，不对用户级会话日志宣称零写入。可写冷生成使用独立npm缓存产生正常依赖缓存/日志；SDK与固定工具未改。
-
-本次改造提交保留在试点分支，未安装覆盖用户现有全局环境、未合并、未发布。最终可预览当前候选，仍需用户针对明确revision/digest进行业务和视觉评审。

package/docs/ui-prototype-native/USAGE.md

@@ -1,93 +0,0 @@
-# 原型制作与续接
-
-<!-- i3:zh-guide:start -->
-## 中文使用说明
-
-按下文完整工程步骤、检查项与验证条件执行。根据任务选择适用步骤，保留证据、风险和退出条件；正文示例中的英文标签在面向用户输出时译为中文。
-
-默认使用简体中文解释、追问及生成报告；用户明确要求其他语言时可切换。原方法正文、引用、阈值和审批条件完整保留。代码标识、路径、命令、工具参数、JSON 键/枚举与原文引用保持原样。
-<!-- i3:zh-guide:end -->
-
-当前默认内容模板为完整企业管理后台，生成目标为 Vue3＋antDv-next。HTML 参考可以离线编辑；生成的框架工程需要安装依赖、构建并启动预览。安装方式见 [CodeBuddy 说明](../codebuddy-setup.md)。
-
-## 在 CodeBuddy 发起
-
-```text
-/i3-prototype analyze 根据 PRD 分析原型范围和模板适用能力，先不写入或安装
-/i3-prototype create 根据 PRD，参考完整 enterprise-admin 模板，生成 Vue3＋antDv-next 原型，ID 为 assets
-```
-
-自然语言、命令、using 选择及直接调用 Skill 均由主会话执行，无原型专责 Agent。using 按普通发现逻辑选择原型 Skill；原型流程按阶段复用前端、官方框架、UIUX 和浏览器能力，避免一次加载全部模板、依赖源码及历史日志。
-
-只读分析交付覆盖、选型、验收计划及缺口，不创建原型、安装依赖、启动浏览器或保存用户级记忆。创建／修订的写入限于本次项目与明确范围，长期记忆、全局配置及其他项目另需明确授权。
-
-## 可选官方 Skill 与后续检测
-
-从业务项目根运行：
-
-```sh
-node .codebuddy/skills/i3-ui-prototype/scripts/prototype-dependencies.cjs check --project .
-# 以下仅在明确选择安装后执行，可单独选 uiux 或 antdv：
-node .codebuddy/skills/i3-ui-prototype/scripts/prototype-dependencies.cjs install --project . --skills uiux,antdv
-```
-
-i3 默认不安装这两项依赖，跳过不永久禁用。后续补装后重新检测即可，无需重装 i3；必要时重载 CodeBuddy 窗口或新建会话让宿主发现。已有可用全局 UIUX 可复用，已有第三方技能和工具不覆盖。缺 Python 仅报告，不安装系统运行环境。官方正文、许可、版本和来源保留，详情见已安装 Skill 的 references/optional-skills.md。
-
-UIUX 专业模式为默认，缺少可用查询资源会提示，不静默降级；用户明确选择基础模板模式后仍完成同样业务功能、四主题和验收。安装依赖不会自动改变既有原型的模式、源码或证据。检测不代表真实宿主调用；CodeBuddy 仍须通过其 Skill 工具实际加载。
-
-antDv 官方 Skill 和组件库是独立部分：未安装 Skill 时可使用对应版本官方文档／类型／源码，记录实际渠道；生成工程仍需 antDv-next 库。新工具目录为对应宿主基址下的 tools/i3-prototype/antdv-cli，支持项目和全局安装；旧 .prototype-tools/antdv-cli 保留读取兼容；只读检测返回可执行的 Node 入口，也识别既有 .prototype-tools/node_modules 布局。固定 CLI 0.0.0-beta.1 的 1.5.2 知识仅作参考，目标组件库 1.5.3 仍核对实际类型／源码。不自动升级 CLI，不以 Error 文本、exit 0 或占位 lint 代替成功。
-
-## 内置模板与业务原型
-
-```sh
-node .codebuddy/skills/i3-ui-prototype/scripts/native-pilot.cjs template-page --page models-page
-```
-
-默认只读使用 Skill 安装目录 assets/templates/enterprise-admin 中随版本发布的完整模板，业务项目不生成 ui-templates。可双击内置 index.html 离线查看；模板内容由维护者在 Skill 源码中修改、校验并随包发布，业务使用期间不修改安装目录。索引在内存只读计算，随生成时的模板、范围与能力快照固定到 inputs。业务修改直接落在 prototypes/<id>/app/，Skill 升级不隐式改写已有原型。
-
-只读取本次相关页面。完整索引提供参考页面、路由和资源清单，不表示自动理解或实现全部旧业务。已有 ui-templates 副本保留，不自动读取、覆盖或删除；明确需要其手工内容时，先显式 sync-template 该副本，再在 create 时传 --template-root <已有目录>。旧 prepare-template 命令继续用于兼容，不是新流程必需步骤。
-
-## 需求范围与创建
-
-主会话根据实际 PRD 整理 schemaVersion=2 的 prototypes/.preparation/assets/scope.json，moduleIds 填实际模块 ID（未关联填 []），索引 appliesTo 自动去重生成：逐页声明业务标题、referencePage、区域类型、需求原文及来源。列表适用查询、复选、分页、批量与状态反馈；编辑区域适用校验、保存失败保留和重试。豁免须有明确需求依据。不能漏报实际区域来逃避能力。
-
-新原型默认提供明亮、暗黑、清新、科技，默认明亮，无编号。列表默认可调分页 10／20／50，默认 10；在 scope 的区域参数中明确覆盖真实需要。旧实例仍按原有固定输入，不追溯修改。
-
-```sh
-node .codebuddy/skills/i3-ui-prototype/scripts/native-pilot.cjs create --project . --id assets --scope prototypes/.preparation/assets/scope.json --host codebuddy
-# 仅在明确选择基础模板模式后，增加 --expert-mode template。
-```
-
-必须提供有来源的 scope，不再自动回退设备演示需求。目标存在时先读取 state，按修订流程保留已有手改，不重新 create。初始化仅提供需求对应的原生框架骨架和主题，business.status 为 needs-adaptation；主会话继续实现实际业务页面、字段、模拟数据和交互后才可验收。
-
-## 实现、构建与真实验收
-
-按需使用 i3-frontend-ui-engineering、可调用的 antDv 官方 Skill、UIUX 查询和取舍。官方 Skill 可调用时先实际加载；无法调用时记录官方资料等效渠道。UIUX 的加载、真实查询、建议采用与效果验证分别有依据。
-
-```sh
-node .codebuddy/skills/i3-ui-prototype/scripts/native-pilot.cjs state prototypes/assets
-node .codebuddy/skills/i3-ui-prototype/scripts/native-pilot.cjs build prototypes/assets --install
-node .codebuddy/skills/i3-ui-prototype/scripts/native-pilot.cjs preview prototypes/assets
-```
-
-首次且允许安装工程依赖时用 --install，之后复用已安装依赖。业务流程覆盖查询、多选、分页、编辑抽屉、校验失败、提交失败、重试保存及列表同步；另验抽屉进入／退出、模糊遮罩、四主题保留状态、窄屏、键盘与焦点恢复。
-
-主会话实际加载 i3-browser-testing-with-devtools，通过 Chrome DevTools MCP 对当前构建检查 DOM／计算样式、截图、console、network、可访问性及性能。缺少工具时保留未验证；读取 Skill、只有截图或运行补充脚本不能冒充该链路通过。浏览器使用项目 localhost 和隔离测试环境。
-
-按 inputs/acceptance.json 的本次业务场景实测，保存真实报告，再登记：
-
-```sh
-node .codebuddy/skills/i3-ui-prototype/scripts/native-pilot.cjs record-run prototypes/assets --report /absolute/path/actual-business-report.json
-node .codebuddy/skills/i3-ui-prototype/scripts/native-pilot.cjs record-devtools-review prototypes/assets --report /absolute/path/actual-devtools-report.json
-node .codebuddy/skills/i3-ui-prototype/scripts/native-pilot.cjs state prototypes/assets
-```
-
-从 state 取得当前准确的 finalize／revise 命令；不要复用修改前摘要。结构校验及报告导入不证明真实 Skill 调用，仍须核对原始宿主调用记录。源码或固定输入变化后重建并重验受影响场景。native-pilot 的历史 browser 子命令仅服务旧设备合同，不适用于新完整模板业务。
-
-## 续接、兼容与交付
-
-新会话先 state 恢复身份、范围、模式、构建与证据，按 nextAction 继续，不重新生成覆盖。已有 v1 HTML 与旧 v2 原生实例按原合同检查，保留原摘要、手改和认可基线；小模板仅保留测试夹具，旧设备框架起点在 legacy-starter，不作为新生成入口。
-
-最终回复给出原型路径、范围、revision、实际模式、已执行检查、证据及未决项。完成本地技术验证仍为 pending-review，人工认可具体 revision／digest 后才能冻结基线；不把骨架、安装通过或自填报告当作业务完成。
-
-共享索引为 prototypes/index.json，旧根索引保持兼容。只安装不创建业务目录；全局 Skill 仍把原型留在业务项目，缓存按宿主与项目隔离。查询、同步、显式迁移和浏览器输出命令见 Skill 的 references/project-layout.md。

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／部署和消费者影响，不用重建目录宣布迁移完成。