@givolt/i3-composer-agent 3.2.1 → 4.0.0

package/skills/i3-ui-prototype/SKILL.md

@@ -1,256 +0,0 @@
----
-name: i3-ui-prototype
-description: "将 HTML 内容模板、业务需求与目标组件框架组合为可操作 UI 原型。适用于原型分析、原型候选生成、原型交互验证和已确认原型基线维护；生产页面实现使用工程流程。"
-# i3-description-source: "description: Creates, analyzes, inspects and iterates reviewable interactive UI prototypes from content templates, business requirements and a selected component framework. Use when creating prototype review candidates, inspecting prototype fidelity, reviewing interactions or maintaining approved prototype baselines; production frontend implementation uses the engineering workflow."
----
-
-<!-- i3:zh-CN:start -->
-## 中文交互与输出
-
-默认使用简体中文回复，包括追问、选项说明、阶段进度、分析、规格、计划、验收、代码审查与发布报告。只有用户明确要求其他语言时才切换；输入中出现英文术语、代码或引用不构成切换语言的要求。
-下文的工程步骤、审批要求、退出条件和工具约束完整有效。英文示例中的人类可读标题、说明和占位内容在实际输出时应译为中文；保留原有信息与验证标准，不删减方法。
-Skill/Command/Agent 标识、文件路径、命令参数、代码/API 名称、工具调用参数、JSON 键/类型/枚举、机器状态、测试期望字面量及引用原文保持原样。生成文档正文用中文，SPEC.md、tasks/plan.md、tasks/todo.md、CONSTRAINTS.md 等约定路径不改名。
-严重程度按原规则判断，面向用户可写“严重（Critical）”“必须修复（Required）”“小问题（Nit）”“可选（Optional）”“建议考虑（Consider）”“仅供参考（FYI）”；High/Medium/Low、APPROVE/REQUEST CHANGES 和 GO/NO-GO 保留其原始语义与机器值。不得因翻译降低门槛，角色不能互相委派。
-
-适用说明：将 HTML 内容模板、业务需求与目标组件框架组合为可操作 UI 原型。适用于原型分析、原型候选生成、原型交互验证和已确认原型基线维护；生产页面实现使用工程流程。
-<!-- i3:zh-CN:end -->
-
-# UI Prototype
-
-## Overview
-
-将业务需求、HTML 内容参考、通用能力合同和目标框架组合为可操作、可评审的原型，保留设计决策、业务映射、证据和已确认基线。主会话使用本 Skill 完成原型工作；自然语言、命令、元技能和直接 Skill 进入同一公共前置，不要求专责 Agent 或额外分派。入口与交付边界见 [entry-contract.md](references/entry-contract.md)。默认专业增强；明确选择基础生成时使用 template，两者功能验收一致。
-
-默认使用完整 enterprise-admin HTML 内容模板，目标框架首期为 Vue 3／antDv-next。小列表 HTML 只留在回归测试夹具，不作为正式模板。既有 HTML 原型、来源快照和基线继续采用原运行合同，不隐式迁移。原型认可、正式规格、生产开发与发布分别处理。
-
-## When to Use
-
-- 分析需求、选择内容模板和技术框架，按业务需求生成交互原型。
-- 根据评审意见修改原型，检查与既有基线的一致性。
-- 确认具体原型版本，维护后续迭代使用的设计基线。
-
-仅实现已有设计的生产组件时 use the `i3-frontend-ui-engineering` skill。普通排错、纯后端工作和不涉及原型的代码评审继续使用对应工程技能。
-
-按当前操作复用能力：实现或修改界面时使用 `i3-frontend-ui-engineering`；框架适配时查对应版本的官方 Skill／文档；专业模式按 UI/UX Pro Max 接入合同查询、取舍和验证；真实浏览器验收时使用 `i3-browser-testing-with-devtools`。分析只加载影响结论的资料，不预跑制作或验收。原型 Skill 维护原型范围与证据，各工程 Skill 保留原有方法。
-
-## Process
-
-### 1. 公共前置：上下文、操作与副作用
-
-所有入口，包括直接 Skill 调用，先读取用户原始要求与最新限制、项目规则、实际文件、技术栈、`prototypes/index.json` 指向的原型和交接；仅有旧 `.i3-ui-prototypes.json` 时兼容读取，不创建第二份活动索引。没有正式规格时整理最小范围和待确认项，不补造审批权限或把演示规则写成已确认需求。共享资料与宿主缓存按 [project-layout.md](references/project-layout.md) 管理。
-
-选择 `analyze`、`create`、`revise`、`inspect` 或 `confirm-baseline`；无参数默认 create，明确分析或只读限制优先。analyze 不初始化、不安装升级、不持久化设计、不更新项目／执行状态，也不为记录分析而写文件。允许经过核对的只读查询；用户明确要求保存分析文档时只执行该项写入授权。inspect 是否落盘服从本次范围。规则见 [workflow-contract.md](references/workflow-contract.md)。
-
-analyze 的交付是需求／能力覆盖、模板与框架选型、交互验收计划和缺口；信息足以形成这些结论后即回传。选型可使用已有来源的固定 profile、component-map、acceptance 与需求／内容模板，不等于逐组件逐 Prop 的实施核验。仅对影响选型的具体疑点定向查本地 API；完整目标版本包／源码验证留给 create，不遍历 starter、node_modules、全套 CLI 帮助或组件清单来证明分析。必要读取仍可进行；尚未核实的点留在 openItems，不执行 create 阶段的 provider 准入、逐项 UIUX 采纳门禁、构建或浏览器验收，不把计划写成已完成验收。
-
-覆盖判断核对能力语义与当前绑定参数，不能只看组件名。PRD 与固定参数冲突时明确标为部分覆盖和需要适配，将需求原文、绑定值、适配与验收计划列入 openItems；完整交付了分析仍可 status=complete，资料不足导致分析未完成时才用 partial／blocked。分析完成不等于原型需求全部满足，也不因此额外要求用户批准。`fixedPageSize: 10` 是固定每页 10 条，不能改口解释为默认值来声称支持调整；只读分析不修改绑定或删除需求。
-
-分析直接在会话交付结论、覆盖、选型、验收计划和缺口，不为结果格式写文件。制作或修订交付当前原型身份、范围、检查结果、证据位置和待评审状态；原生流程仍须核对当前 state／delivery。自然语言回复足以交付，不强制父子回传 JSON、标记或校验器；维护工具的结构校验不证明业务或 QA。严格只读期间不写传输文件、创建临时文件或探测可写目录。
-
-查询前按实际 `--host` 和 `--scope` 只读检测，优先使用返回的 antDv 实际 Node 入口。新工具在对应宿主基址的 `tools/i3-prototype/`；兼容既有项目 `.prototype-tools/antdv-cli` 和 `.prototype-tools/node_modules` 布局或宿主明确提供的绝对路径及固定版本，不反复搜索 node_modules。只读分析禁止 npm／npx 自动安装，包括可能下载私有缓存的 npm exec；入口缺失或不能执行时报告未决项，使用已有只读资料，不自行补工具。可写模式也优先使用已准备的本地固定 CLI；只有已获工具准备授权才在指定工具目录安装固定版本。工具准备的写范围不包含业务项目文件或已安装 SDK，细则见框架合同。
-
-主会话核对实际可用的技能与浏览器能力；Skill 文件存在、安装成功或词法排序不证明宿主实际调用。文件承担连续性，恢复写操作前核对 revision／digest。保留用户手改，只有一个源码与合同修改负责人；若任务另有授权的协作，记录各项实际执行与证据，不能冒认其他执行者的工作。
-
-原型 create／revise 不包含用户级长期记忆、宿主 auto-memory 或其他项目的写入授权；只有用户明确要求记忆时才保存。文件续接使用本实例合同与交接。验证只读或纯文件冷启动时，另核对宿主的自动记忆／计划输出及写入权限，不能把“不保存会话”当作不写长期记忆；不要擅自修改全局配置。
-
-先按实际 metadata 选择运行合同：schemaVersion=2、artifactKind=framework-prototype、runtime.kind=vue-antdv-next 使用下节原生流程；v1／旧 HTML 进入下文 HTML 合同流程并使用原摘要。未知形态拒绝，不回退其他模板。详见 [artifact-contract.md](references/artifact-contract.md)。
-
-已有 v2 实例先运行一次 `node <skill-root>/scripts/native-pilot.cjs state <prototype-root>`，从聚合结果恢复身份、固定需求、设计／构建／实际QA、负责人和下一步的精确命令。不要为寻找参数反复遍历全仓库、node_modules或阅读控制器内部实现。这里只读检查，不安装、启动浏览器或更新状态。
-
-制作前实际调用所需的前端／框架／设计 Skill，真实浏览器验收使用浏览器 Skill；不能以读取 SKILL.md 代替调用。缺少必要 Skill 时先补调并等待成功，再继续原操作。同一有效上下文内的成功加载可复用，普通追问后继续原任务，不重新绑定或重复加载全部 Skill；基础设施异常只简要报告未验收项，由独立维护入口处理，不在原型任务中排查。
-
-新 create 使用实际 `--host <codebuddy|workbuddy>`。按 PRD 和固定能力制定交互验收场景，使用 `native-pilot.cjs execution-assertions-template --scope <scope-file>` 取得场景骨架，填充预期 JSON 事实并传 `--execution-assertions <assertions-file>`。这是原型交互验收，不要求手动绑定会话或填写 Hook 调用记录。旧 HTML 和既有 execution-* 入口保持兼容。
-
-### 2. 完整内容模板与需求能力
-
-正式内容模板位于 `assets/templates/enterprise-admin/`；双击其 `index.html` 或上层 `assets/templates/index.html` 可离线预览。完整模板是内容、通用布局和交互参考，不是最终框架效果。`reference/` 保留原始来源；可编辑页面片段内嵌在离线 `index.html` 的 `template[data-source]` 中，本地样式修改后刷新生效，不需要服务、依赖安装或重建。小列表 HTML 已退出正式资产和默认生成入口。
-
-```sh
-node <skill-root>/scripts/native-pilot.cjs analyze --project <project-root> --execution inline
-node <skill-root>/scripts/native-pilot.cjs template-page --page models-page
-```
-
-默认只读使用本 Skill 随版本发布的模板及能力定义，在内存中计算当前内容索引，不在业务项目创建 `ui-templates`，也不修改安装目录。模板由维护者在 Skill 源码中修改、校验并随包发布；业务修改直接作用于 `prototypes/<id>/app/`，生成依据及索引固定在 inputs。只按本次页面读取内容，避免把整套模板加载到上下文。完整模板的索引是参考清单，不声称已自动理解全部原始交互。既有模板工作副本和 prepare-template／sync-template 命令仅保留兼容；只有用户明确要求复用某个已有副本时指定 --template-root，不自动选择、覆盖或清理它。
-
-生成前依据 PRD 整理范围文件：已有需求文件只读引用；本次新文件放在允许写入的 `prototypes/.preparation/<id>/scope.json`，不提前占用原型目标目录。新 scope 使用 schemaVersion=3，逐个声明实际业务页面、参考页面、区域类型、需求原文及来源；moduleIds 填实际 PRD／项目已明确的稳定业务模块 ID，不填文档名、需求全文或代码路径，未明确时填 []。多个 PRD 的模块取本原型范围内并集，需求逐条保留来源与版本、使用唯一 ID；不编造模块或把未关联解释为适用全项目。创建及明确接受输入的修订会从固定 scope.moduleIds 去重生成索引 appliesTo，不手填两份。旧 scope 按原合同保留。管理列表由固定定义要求查询、复选、多页分页、批量操作和状态反馈；编辑区域要求校验、失败保留与重试。参数按实际需求记录；默认列表分页可调为 10／20／50，默认 10。豁免必须指向明确需求及原因，不能通过漏报区域逃避本页真实能力。人工／浏览器复核区域与需求是否一致。
-
-新生成原型默认包含“明亮、暗黑、清新、科技”，默认“明亮”，菜单不加编号。由 application-shell 的固定主题能力和原生 ConfigProvider 实现，主题偏好按实例隔离；不把 HTML 参考样式当成最终主题。旧实例的固定分页、可选主题与 20／23 场景合同仍按原输入检查，不追溯修改。完整字段和示例见 [content-template.md](references/content-template.md)。
-
-先运行 `generation-options` 查看本模板真实支持的风格／布局／密度和页面模式，向客户展示中文名称；已有明确选择直接沿用，未指定时说明模板默认值。风格与四主题分开：风格／布局／密度在生成前固定，四主题在成品上切换。离线选择页的“选择风格、布局与密度”只预览结构，不替代框架效果验收。
-
-```sh
-node <skill-root>/scripts/native-pilot.cjs inventory --template enterprise-admin
-node <skill-root>/scripts/native-pilot.cjs generation-options --template enterprise-admin
-node <skill-root>/scripts/native-pilot.cjs generation-plan --template enterprise-admin --scope <scope.json>
-```
-
-逐页读 `template-page` 返回的真实 HTML 和 `generation-plan` 的参考清单；依据本次业务选择 management-list／tree-list／tree-table／edit-form／form-page／detail／wizard／workflow／permissions／content。模式选定后，其能力不能通过删绑定、关开关或 N/A 删除。普通列表不强加树；分类筛选树和树表须分别声明，导航分组也单独声明。列设置、删除、未保存保护、向导、画布、角色状态等均按合同处理，不能只补树。
-
-每个真实字段和操作填入区域的 fields／actions，保留唯一 ID、类型、需求来源及操作预期；页面上的新按钮不能只给反馈文字冒充业务结果。`pendingDecisions` 中的参考能力须明确采用或附需求依据排除；`pendingReferenceElements` 中每个功能节点（包括已被通用能力涵盖的按钮／字段／事件）须用 referenceDecisions 显式关联生成绑定或附来源排除，允许同类节点以明确 nodeIds 分组。不得用“已采用 interaction”批量视为全部节点已处理。检查真实页面与 PRD，工具只验证已声明内容的一致性，不能自动发现 PRD 中从未声明的遗漏。使用 replan 显式统一更新固定输入，避免手改多份合同不一致。完整格式与取舍、重新固定方法见 [generation-contract.md](references/generation-contract.md)。
-
-### 3. 原生组件首期：设计与实现
-
-UIUX 和框架官方 Skill 独立可选安装，不随本技能默认复制。create／revise 需要这些能力前，运行 `node <skill-root>/scripts/prototype-dependencies.cjs check --host <host-id> --scope project --project <project-root>` 只读检测当前宿主项目及同宿主全局依赖；仅检查全局时用 `--scope global`；不缓存“跳过安装”，后续补装后重新检测，无需重装本技能。宿主未发现新 Skill 时刷新／新建会话。安装须明确选择，不在 analyze 自动下载安装；命令、固定版本和使用边界见 [optional-skills.md](references/optional-skills.md)。已有实例的模式、源码和验收不因安装依赖而自动变更。
-
-按下文专业接入规则检测 UIUX，professional 不静默降级，template 必须明确选择。只读约束贯穿 provider；查询、采用和效果分别有依据。详细接入见 [expert-adapter.md](references/expert-adapter.md)。
-
-初始化前的 probe／查询不得先占用 `prototypes/<id>`。先 probe，再用下列 create 命令原子初始化，然后在已创建实例的 qa 下保存查询、取舍与验证。如果必须在初始化前保存查询文件，使用独立准备目录（如项目内 `prototypes/.preparation/<id>`），初始化后再归入本实例 QA；不要预先创建目标的 qa 目录。
-
-加载框架官方 Skill 或对应版本官方文档、类型和源码，先查 API、读示例、再实现。先完成上文工具预检，使用已准备的固定本地 CLI；缺项不因官方 Skill 的安装建议而扩大权限。固定项目依赖锁，记录请求与实际知识版本。映射与官方来源见 [framework-contract.md](references/framework-contract.md)。
-
-antDv Skill 成功加载后，优先使用只读命令 `node <skill-root>/scripts/prototype-dependencies.cjs query --host <host> --scope project --project <project-root> --kind info --component <Component> --version <knowledge-version>`，它解析当前宿主本地 Node／CLI 入口，不依赖全局 `antdv` PATH。也可使用检测返回的绝对 Node 和 CLI 入口执行官方只读查询。query 返回不代表 Skill 调用；组件版本与知识版本分别记录，不足时核对目标包类型／源码。官方 Skill 的 allowed-tools／原生权限若不允许实际入口，按原生权限流程处理，不编辑官方正文绕过。
-
-宿主已发现可调用的官方框架 Skill 时，先通过真实 Skill 工具加载它；读取 SKILL.md 或运行 CLI 查询不能冒充宿主 Skill 调用。只有该 Skill 在当前执行者中不可调用时，才使用版本匹配的官方文档／类型／源码等效渠道，并明确记录官方 Skill 未唤醒及实际资料来源。UIUX 的 Skill 调用、真实查询、建议采纳与效果验证也分别记录，查询成功不自动记 used。
-
-```sh
-node <skill-root>/scripts/native-pilot.cjs create --project <project-root> --id business-demo --scope <project-root>/prototypes/.preparation/business-demo/scope.json --expert-mode professional --provider <uiux-root>
-# 仅在用户已明确选择基础生成后：
-node <skill-root>/scripts/native-pilot.cjs create --project <project-root> --id business-demo --scope <project-root>/prototypes/.preparation/business-demo/scope.json --expert-mode template
-```
-
-目标存在则 revise，不重新初始化。首次业务 UI 写入前必须通过宿主 Skill 工具成功调用 `i3-frontend-ui-engineering`；不得仅凭当前 Skill 中的摘要直接实现。收到门禁反馈时立即补调、等待成功返回并重试原操作，失败则报告具体阻塞，不能推迟到下次修订。Follow the `i3-frontend-ui-engineering` skill，使用真实 Table／Form／Drawer／反馈组件及 ConfigProvider。初始化只产生需求对应的框架骨架和四主题，business.status 为 needs-adaptation；这不是已完成业务。实现固定输入中的实际字段、列表和流程，逐个填写 `design-system/implementation.json` 的实际组件、源文件／定位符和固定场景，再核对需求映射、模拟数据并更新 business.status 为 adapted。UIUX 采用规则落实到 design-system、主题和页面；模板样式不锁定生成外观。
-
-目标存在但没有 prototype.json 时属于未识别的准备目录，不能当作有效实例执行 revise。先核对来源并保留文件；只有从本次工具记录确认整个目标目录均由当前任务的准备操作产生，才可将该整个目录移到独立准备位置，确保目标路径不存在后重试原子 create。仅移动查询文件仍会留下空目录并阻止 create。来源不明或包含用户已有文件时保留原目录并报告冲突，不得覆盖或清空。
-
-新流程按实际业务定义模拟数据，默认容量下至少覆盖首、中、末页，不再固定为设备或 21 条。按 inputs 的分页参数验收容量切换和恢复。筛选、翻页和更换页大小清空选择，当前页多选与批量变更作用于正确记录。加载、空、失败、恢复可主动触发；校验和提交失败保留输入，重试保存更新列表。模拟数据按实例隔离，可重置。演示规则不得当作已确认权限。
-
-### 4. 原生组件首期：构建、验收与迭代
-
-```sh
-node <skill-root>/scripts/native-pilot.cjs state <prototype-root>
-# 首次且本次允许安装项目依赖时：
-node <skill-root>/scripts/native-pilot.cjs build <prototype-root> --install
-# 后续源码变化重新构建，已有依赖时不加 --install：
-node <skill-root>/scripts/native-pilot.cjs build <prototype-root>
-# 先实际加载 i3-browser-testing-with-devtools Skill，用 Chrome DevTools MCP 完成固定能力检查；
-# 完整内容模板的新业务：按 inputs/acceptance.json 实测后，导入真实业务报告：
-node <skill-root>/scripts/native-pilot.cjs record-run <prototype-root> --report <actual-browser-report.json>
-# browser <root> 只服务已有的设备列表固定合同，不能用于新业务。
-```
-
-先完成真实官方／UIUX查询、业务适配与设计取舍，再构建；state.design为pending时由执行者复核并整理正式决定，工具不会代替设计判断。设计记录使用 expert-adapter 的原生 v2 格式；verificationScenario 直接取本实例 inputs/acceptance.json 的 requiredScenarios／frameworkScenarios，不从控制器或浏览器执行器反推。使用state返回的精确commands，首次构建按本次授权加--install。输入、候选和实际构建产物分别有摘要；进度、QA、依赖目录和缓存不进入候选身份。构建失败不能沿用旧产物声称通过。
-
-本轮 CodeBuddy 原生验收由实际执行者通过宿主 Skill 工具加载 `i3-browser-testing-with-devtools`，再使用该 Skill 要求的 Chrome DevTools MCP 按固定能力与 PRD 验证。必须实际取得 DOM／计算样式、截图、console、network、可访问性和性能观测；只加载挂名、读 SKILL.md 或 Bash 调用脚本不算 Skill 执行。该 Skill 没有 Playwright 替代路径；缺 Skill 调用能力、MCP 连接或必需观测时，整链不报 complete。analyze 仅列验收计划，不启动浏览器或安装 MCP。执行与证据边界见 [interaction-acceptance.md](references/interaction-acceptance.md)。
-
-安装内历史 browser 工具实际调用 Playwright，是同一候选／构建的专项补充回归，自动启停固定构建服务并记录场景、截图与 trace。该工具仅覆盖历史设备列表的 20／23 场景，不适用于完整内容模板的新业务；它不证明宿主调用了浏览器 Skill 或 DevTools。运行库优先发现所选宿主 `tools/i3-prototype/playwright/node_modules` 或 `tools/i3-prototype/node_modules`，保留项目 `.prototype-tools/node_modules/playwright`，也可用 app／项目模块或显式 `--playwright-module <已存在包>`；发现不等于启动成功。缺运行库或 Chrome 时报告缺项，不自动全局安装或手填报告。其他宿主的等效真实浏览器结果如实单列，不能冒充指定 Skill／MCP 链通过；旧 v1／已有 v2 继续核对原固定合同，不追溯追加新验收要求。
-
-仅迭代历史设备列表且需要专项证明时，browser 传`--expected-categories '<JSON数组>'`、`--verify-blur-validation`、`--verify-atomic-status`或`--expected-description '<精确文案>'`；仅采用相应规则时启用，不能为了工具预设强迫采用UIUX建议。
-
-按选定模式覆盖实际流程；列表与编辑覆盖筛选→多选→分页→抽屉→校验失败→提交失败→重试保存→列表同步，树／树表、列设置、删除、向导、画布等逐项按固定场景验证。新 v3 报告还须逐场景填写 generationObservations，附实际动作／目标／结果、工具调用定位及证据摘要，不能只填写场景 passed。另查状态、窄屏、键盘、焦点和控制台。进入与退出使用正常动画；退出结束后再销毁；毛玻璃核对配置、计算样式及真实效果，静态截图不证明动效。
-
-清空文本后要核对查询／校验实际结果。本轮固定 Chrome DevTools MCP 1.11.0 的空字符串 fill 可仅清 DOM 值而未发送输入事件；遇到此现象记录工具限制。实测替代操作是原生 fill 单个空格后，只读取得实际文本长度与光标位置，确认光标在末尾再按该长度逐次 press_key Backspace，最后核对空值及查询／校验结果。空格可能追加到恢复的旧文本；本轮 headless 的 Meta+A／Control+A 也未全选，不能假定快捷键成功。不要用 evaluate_script 补发事件或修改状态。输入事件问题与宿主参数回调兼容分别记录，fill 返回成功不证明页面状态已更新；版本不同按实际观测判断，详见交互验收合同。
-
-DevTools 检查使用已核对构建的 preview URL，预览进程采用宿主支持的受管服务方式，不用持续前台进程阻塞后续工具；专项 browser 自行管理服务。preview 默认 last-build，可传 --build-id。实际检查后运行 `record-devtools-review <prototype-root> --report <actual-report.json>` 登记六类证据；新 create 的固定 browserReview policy 要求 state.devtoolsReview 为 current，缺失／过期或文件变化会阻止 finalize。旧 inputs 无 policy 时保留原合同。报告导入、字段与限制见交互验收合同。
-
-浏览器两层证据保存后重新 state，按 commands.finalize 传当前 expected revision／digest；只有本次适用的实际验收全部通过才回传 complete。脚本核对报告结构、证据字节和身份，仍明确 invocationVerified=false；CodeBuddy 另核原始宿主 stream 的真实 Skill／MCP 调用及观测。state 的 current 和交付收据均不能代替这一层证明。
-
-QA 引用当前candidateDigest／buildDigest，记录真实执行者和实际证据。测试前后候选一致，变化则本轮证据失效。未运行保持未验证，不能手填passed代替执行。state.nextAction=return-result时停止探索，最后工具之后用自然语言交付范围、revision、实际模式、检查结果、当前收据和HANDOFF；通过仍是pending-review。工具状态或进度文本不能代替最终交付。
-
-原生迭代先state恢复真实源码、固定输入及手改差异。完成本次授权编辑后重新state，取得实际当前摘要，再执行其commands.revise；不要复用编辑前的摘要或命令：
-
-```sh
-node <skill-root>/scripts/native-pilot.cjs revise <prototype-root> --revision r002 --expected-revision r001 --expected-digest <candidate-digest>
-```
-
-需要持续占用修改权时用 `claim <root> --owner <owner> --expected-revision <current> --expected-digest <digest>`，revise 传同一 --owner；编辑结束 `release <root> --owner <owner>`，再执行验收与确认。版本检查仍须匹配实际当前状态，不共享锁冒充新版本。短操作可以由脚本取得临时修改权。
-
-中断或更换执行者从文件恢复，过期执行者不得覆盖。只重验受影响场景；实例改进不会自动回写模板。confirm-baseline 仅依据用户对明确 revision／digest 的认可和当前验收：
-
-```sh
-node <skill-root>/scripts/native-pilot.cjs compare-baseline <prototype-root>
-node <skill-root>/scripts/native-pilot.cjs confirm-baseline <prototype-root> --confirmation <human-confirmation.json>
-```
-
-确认文件使用 revision、digest、reviewer、statement、source；source 指向真实人类确认。不要用测试夹具、代理自我认可或 legacy 写命令冻结 v2。
-
-### HTML 审查与既有 v1：专业能力与模板预览
-
-以下步骤适用于完整 HTML 模板审查及已有 HTML 合同；公共前置和只读限制同样适用。
-
-新增原型默认 `professional`（专业增强模式）。优先使用当前宿主暴露的 UI/UX Pro Max 技能位置，运行 `scripts/check-design-provider.cjs --provider <实际技能根>`；也可传入明确的 `--host` 和 `--project` 自动检测项目、全局 Skill 和已启用插件。项目安装的本技能可直接复用同一宿主的全局 UI/UX Pro Max，无需再复制到项目。不能硬编码缓存版本、借用另一宿主安装，或仅凭目录存在判断可执行。明确指定的 provider 失败时报告该路径，不自动换成别的副本。
-
-检测不阻断模板预览，先继续展示模板并记录选择。自动检测遇到不可用项目副本时继续检测全局副本；运行探测通过后使用。缺少宿主信息时补充宿主或实际技能路径；已安装但停用、资源不全、查询失败、发现信息不完整时分别提示启用、修复或定位，不能一律要求重新安装。确认当前宿主未安装时提供安装入口；始终允许明确选择“模板模式继续”或“先整理需求和模板选择”，默认不降级。用户选择安装后按该宿主的官方方法安装并验证；已有授权或已选择模板模式时不重复确认。安装系统运行环境需根据实际缺项处理，不能静默改动操作系统。
-
-模板模式使用 `template`，仍使用同一套业务和浏览器验收标准。不得静默切换，交付记录必须说明实际模式。专业接入的查询与建议适配见 [expert-adapter.md](references/expert-adapter.md)。
-
-### HTML 审查与既有 v1：选择模板并固定版本
-
-运行 `node <skill-root>/scripts/init-prototype.cjs templates` 查看四类：企业管理后台、AI 工作台、数字孪生大屏、移动端应用。按 availability 区分可操作模板与 planned；不能把待建设类型生成成其他类型。双击 `<skill-root>/assets/templates/index.html` 打开离线选择页；静态预览服务仅为可选方式。企业后台使用 i3-Composer 品牌的完整 HTML 审查版，当前可供人工测试，其余三类待后续实施。已有模板选择时沿用。
-
-选择页只切换预览，不创建或确认业务实例。可生成模板使用 catalog/manifest 显式指定运行层；未知或缺失 adapter 不回退到 common。资源组织、独立模板扩展与旧实例兼容见 [template-adapters.md](references/template-adapters.md)。
-
-企业后台保留原 EASEL 的全部页面、样式、控件和交互；预览及新实例的页面标题、导航、示例项目和相关说明统一使用 i3-Composer，来源快照与内部兼容标识保留。审查整套模板时显式使用 `--purpose template-review`；为新业务生成时沿用默认 business-prototype，替换项目菜单、字段、状态、角色、数据和需求映射，完成后才将 business.status 标为 adapted。旧 classic-admin、modern-workspace、data-operations 仅保留兼容和历史样例迭代，不再作为新项目首选。框架工程保持既有设计规则，交接包含真实组件映射，HTML 审查版不等于真实 Vue/React 组件工程。
-
-创建示例：
-
-```sh
-node <skill-root>/scripts/init-prototype.cjs --project <project-root> --id enterprise-review --template enterprise-admin --purpose template-review --provider <uiux-skill-root>
-# 仅在用户明确选择模板模式后：
-node <skill-root>/scripts/init-prototype.cjs --project <project-root> --id enterprise-review --template enterprise-admin --purpose template-review --expert-mode template
-```
-
-企业后台初始化保留完整 i3-Composer 示例。template-review 用于本次模板人工审查；business-prototype 初始为 needs-adaptation，未完成实际业务适配时验收守卫拒绝通过。复制的 app/qa 是历史来源材料，本次验收使用原型根 qa/。目标已存在时使用迭代流程，不覆盖。完整复用、来源核对与响应式规则见 [enterprise-admin.md](references/enterprise-admin.md)。
-
-### HTML 审查与既有 v1：专业设计与业务实现
-
-将需求编号映射到页面、字段、操作、角色、可见范围、状态与验收场景。专业增强模式加载已发现的 UI/UX Pro Max 指令，运行真实查询并核对匹配；建议不能覆盖选定模板、需求或已认可的规则。查询失配时缩小问题重试一次，仍失配则拒绝并记录依据。
-
-专业建议的采用/拒绝写入 `qa/design-advice.json`，包括查询、结果身份、原因和验证条件。被采用规则写入 `design-system/MASTER.md`、token 或页面规则。基础工程与业务映射始终由 i3 维护。
-
-真实查询、建议处理、实际采用和效果验证分别记录；采用后可记录 used，没有适用结果记录 no-match，有依据的零采用同样可完成复核。冻结不把状态自动改成 used，不修改已冻结旧快照。HANDOFF.md 同步实际情况，不能保留初始化待办描述冒充完成。
-
-Follow the `i3-frontend-ui-engineering` skill 实现原型。固定模板版本和 token，新增页面复用组件约定。演示数据、状态切换和本地权限模拟必须可复现；普通按钮反馈不能代替完整的业务流程。修改 token 后同步 `app/tokens.css`。
-
-### HTML 审查与既有 v1：验证并交付候选
-
-运行 `node <skill-root>/scripts/check-prototype.cjs <prototype-root>`，新完整模板实例双击 `app/index.html` 即可预览；旧 v1 模块入口仍可使用 `node app/serve.cjs`。Follow the `i3-browser-testing-with-devtools` skill 或当前宿主可用的等效真实浏览器能力，检查需求映射中的主流程、校验、权限演示、失败反馈、窄屏、键盘焦点和控制台。
-
-先取 `manage-baseline.cjs manifest <prototype-root>` 的版本与内容摘要，将实际浏览器结果、场景 ID、视口和截图保存到 `qa/browser.json`，绑定同一摘要。运行 `check-prototype.cjs <prototype-root> --acceptance` 核对证据与覆盖；有修改则旧证据失效。
-
-没有实际浏览器证据时交付待验证候选，不能填写 `passed`。本地通过仍是 `pending-review`。提供可打开的预览、模式、范围、待确认问题、检查结果和 `HANDOFF.md`；关键检查失败时明确阻断项。
-
-实际验收通过后，将 prototype.json 的 verification 更新为 passed 并记录对应 digest；review 保持 pending-review。文件再变化时重新验证，不能只修改状态字段。
-
-### HTML 审查与既有 v1：迭代与确认
-
-`revise` 先运行 `manage-baseline.cjs revise <prototype-root> --revision r002`，读取当前设计契约和旧基线，按反馈产生新候选并重新验证受影响场景。保留旧基线和其确认记录；修改全局设计或业务状态规则必须说明差异。
-
-`confirm-baseline` 只能依据用户对明确版本的认可。确认 JSON 含 `revision`、`digest`、`reviewer`、`statement`、`source`，记录用户原意和来源，不能由代理自我认可。先通过当前验收，再运行 `manage-baseline.cjs confirm-baseline <prototype-root> --confirmation <record.json>`。版本或摘要不符、必需证据缺失、旧基线已存在时脚本拒绝。
-
-后续 UI 实现读取项目清单、适用基线及页面规则，运行差异检查。`check-prototype.cjs --enforce-baseline` 可作为设计契约变更检查；它检查原型及其契约，不自动证明任意生产代码的视觉一致性。需要强制合并门禁时由项目实际 Hook/CI 接入并验证。
-
-## Common Rationalizations
-
-| 想法 | 要求 |
-| --- | --- |
-| 原型任务必须先分派专责 Agent | 主会话使用工作 Skill，各入口共用前置与验收 |
-| Skill 文件存在就是已经执行 | 宿主调用和实际行为分别出证据 |
-| HTML 删除分页就可以任意不适用 | 固定规则重算，豁免须有需求来源 |
-| 分析时顺手初始化和升级工具 | 只读限制贯穿下游技能和脚本 |
-| 专业技能缺失就直接换成模板模式 | 先提示安装或修复，用户明确选择后才切换 |
-| 搜索返回了配色和首页结构就全部采用 | 核对产品与页面匹配，业务界面不能被营销结构替换 |
-| 通用演示生成成功就是完成用户业务 | 按实际需求实现并更新业务映射与验收 |
-| 测试通过可以标记用户已批准 | 本地验证与具体版本的用户认可分别记录 |
-| 更新参考截图即可消除设计差异 | 先解释变更并评审，再更新对应基线 |
-
-## Red Flags
-
-- 未说明模式变化，声称使用了未查询的专业技能，或混淆查询、采用和验证。
-- 将原型入口变成强制角色分派、绕回命令／元技能，或把结果 JSON 当作实际完成证据。
-- 覆盖工作副本、手改或旧基线，检查时追随全局新模板。
-- 保留通用演示数据却报告真实业务完成，或把演示授权当服务端权限。
-- 文件变化后继续使用旧的浏览器报告或用户确认。
-- 覆盖已认可的快照、随意更换模板，或为了检查通过降低原有门槛。
-- 用结构校验、词法路由或截图文件存在冒充浏览器和宿主执行证据。
-- 把 Playwright 专项回归或读取 Skill 文件写成浏览器 Skill／Chrome DevTools MCP 已实际执行。
-
-## Verification
-
-- [ ] 操作副作用、执行方式、模板、版本、运行形态及实际能力有记录。
-- [ ] 固定能力与区域绑定完整，豁免有来源，各入口在主会话进入同一工作流程。
-- [ ] 业务映射完整，原型行为与本次范围一致；待确认项可见。
-- [ ] 专业查询、采用和验证分别记录；零采用有依据，template 明确未使用。
-- [ ] 结构校验通过，实际浏览器覆盖必要场景并绑定当前内容摘要。
-- [ ] 本次适用的 CodeBuddy 浏览器 Skill、DevTools 实际观测与专项回归分别有证据；旧固定合同未被隐式扩展。
-- [ ] 候选交付待评审；冻结仅依据同一版本的人类确认。
-- [ ] 迭代读取适用基线，设计变更和工程交接保持可追溯。