@lark-apaas/coding-miaoda-sandbox-skills 0.1.24 → 0.1.26

package/miaoda/creative-to-fullstack/SKILL.md

@@ -8,250 +8,57 @@ workspace-contains:
 
 # 把创意设计稿实现为全栈应用
 
-`source_package/creative/` 是创意模式设计稿，是本次开发的唯一视觉规格。交付标准：
+以 `source_package/creative/` 中的原创意设计应用为依据，在当前工程中交付真实可运行的全栈应用，而不是静态原型。源稿是只读的视觉与业务意图权威，不能作为交付应用的运行时依赖。目标是在保证以下结果的前提下尽快完成。
 
-1. **视觉与源稿一致**：每个页面的文案、数值、色值、条目与顺序与设计稿逐字段一致。
-2. **可见功能真实可用**：设计稿上每个可交互组件（可点、可输入、可筛选）都产生真实、闭环的结果。
-3. **数据动态可变**：会随业务数据而变的内容一律由业务事实现场算出——禁止前端写死常量、接口返回字面量、库内预置统计字段或独立统计快照。业务事实变化后，所有相关页面重新查询都得到一致的新结果；算出的值与源稿数字不一致是预期结果，只对齐单位与格式。
+## 工程规范与最小规划
 
-两条核心规则：**一切视觉内容直接从源稿代码照抄，不经过任何文字转述**；**动手实现前先完成业务设计并写入 `docs/business-design.md`，后续每个阶段以该文件为执行依据**。
+- **开发前必读 `coding-guide`**：使用当前技术栈的工程、共享类型、平台能力及规范。开发 Worker 同样必读，只按需加载专项 skill；不另发明行数/目录规则或限定文件数。在独占页面/模块目录内，首次编码即可按该规范拆私有组件与逻辑文件；必要的后置重构须基于完整源码局部移动，不能依据截断读取整体重写。
+- **先写 `docs/business-design.md` 再编码**：只写支持实现与验收的决策，不誊写源稿视觉细节、实际种子值或逐控件功能全集。正文需覆盖下表，短列表或合并表格均可；同一事实只定义一次。
+- **契约先行**：当前并行批次所需的最小 shared 类型、路由参数、ID/状态/单位口径、实际 schema 与接口落盘可引用后即可开工，不等全部业务契约或公共组件实现完成；代码契约不与文档维护两份字段定义。执行期主 Agent 与 Worker 均不得擅改契约；阻断核心链路时暂停受影响任务，统一修订设计与契约，只通知受影响消费者并调整其任务。
+- 用 TodoWrite 记录实现、验收及未完成项，每批完成或提交前按事实更新。实际阻塞在设计文档中登记，交付时如实披露。
 
-### 第 1 步：通读源稿
+### 业务设计必须回答的问题
 
-读取 `source_package/creative/` 下全部页面源文件（index.html、pages/、components/ 等）。该目录只读，是实现期间反复对照的唯一视觉权威；工程代码不得引用它，也不要修改它。
+| 内容 | 最小产出 |
+| --- | --- |
+| 核心链路 | 按用户目标识别核心链路，每条链路定义：真实可见入口与目标对象 → 输入/动作 → 必要中间态 → 真实结果 → 回读位置。链路内各步骤作用于同一目标对象，每一步写入产生的对象、状态及其关联记录须满足下一步操作与回读页所需的数据条件，任一条件不满足即视为链路未闭环。 |
+| 非核心功能 | 不属于任何核心链路的功能点逐项列出，全部保留源稿视觉；其展示数据来自数据库中的真实记录，不实现业务写入、状态流转与外部能力接入。对应控件保持外观并呈现不可用语义，不显示虚假成功，不删除页面或区块。该清单与核心链路清单共同构成本次交付范围，收尾时按同一清单如实说明。 |
+| 页面与视觉来源 | 记录全部源稿页面对应的目标路由/目录、对象参数、源文件/区块，以及用户可见的到达路径；核心结果页明确其上游操作入口。记录全局 Layout 和真正跨页组件的归属，以及素材来源与迁移/复用方案。 |
+| 最小业务模型 | 核心实体、稳定 ID/关联、关键状态及前置条件、必要唯一性与可空规则；初始事实的源稿位置与字段映射，缺失事实按空态展示。 |
+| 接口与结果口径 | 核心动作的必要用户输入、前置条件、状态变化与回读结果在接口契约中一一对应。记录方法/路径、请求/响应类型及 shared 路径、错误/空态语义；动态结果明确事实来源、计算/筛选口径与变化触发。前后端共同引用对象 ID、状态、单位/取整、时间及可空字段口径。平台/插件能力按实际需要选型并确认可用契约。 |
+| 验收与阻塞 | 按源事实定义每条核心链路的可见操作路径、目标对象/状态、可判定的结果与刷新/跨页回读；覆盖相关中间态及动态变化，合并共享链路，另列全页面视觉检查。记录影响核心交付的外部依赖、资源缺失及实际阻塞。 |
 
-### 第 2 步：业务设计（主 Agent 的核心职责）
+设计以能开工、能判定结果为止；不扩成全产品设计、字段血缘大全或多层门禁。遇到新事实只改受影响条目，不反复读写整份文档。视觉实现者直接读取对应源稿，不凭主 Agent 转述实现。
 
-从源稿可见信息推断应用的业务模型。完成以下四项设计并通过门禁，**写入工程文件 `docs/business-design.md`**，作为第 3/4/5 步的执行依据：
+## 交付目标
 
-**2.1 业务域划分**。按「业务模块闭环拆解规则」（见下方规则章节）从源稿划分业务域，产出各域的名称、覆盖的源稿页面与功能、服务端模块归属。候选业务域包含多个可独立闭环的子业务，或预计单个 Worker 难以一次完整实现时，继续拆为更小的业务域；每个子域仍包含完整的前后端闭环。
+### 1. 页面视觉效果 100% 还原
 
-同时单列「全局 Layout 与跨页面公共组件」清单：登记导航、侧栏、页眉、页脚等全局框架，以及被两个以上页面共同使用或重复出现的组件，并记录源稿文件和使用页面。该清单是共享视觉资产，不是业务域，不纳入任何域任务，在公共视觉层统一实现。
+保留所有源稿页面、导航、布局、层级、尺寸、间距、字体、颜色、固定文案、素材主体与图表形态。素材优先复用/迁移；不可复用时替代图须保持原用途、主体、色调和裁切。以源稿中的实际业务页面为还原对象。
 
-**2.2 数据模型**。以 2.1 划定的业务域为单位，先设计合理的业务数据模型，再单独规划初始数据。表结构设计不承担视觉内容分流职责，不得为了复刻某个页面或某组展示值而增删实体和字段。
+动态数字来自当前业务事实，保持与源稿一致的单位、格式和排布。视觉验收关注整体呈现效果，允许动态数值和无影响的小图标差异。
 
-1. **设计表结构**：从业务对象、行为和生命周期识别实体，产出表名、业务含义、字段（含类型与语义）、主键与业务唯一键、表间关系及基数、状态与时间字段、必要约束。按以下不变量建模：
-   - 一个实体具有可解释的业务身份或生命周期；页面、卡片、图表不是实体边界，禁止按页面或展示区块机械建表；
-   - 字段保存原子业务事实，关系通过稳定标识表达；多值关系、历史记录和状态流转按其业务语义建关系表或历史表，不用展示字符串代替关联；
-   - 对业务唯一性、引用完整性、必填、合法枚举、数值范围和不允许重复的关系设置相应约束；索引服务于 2.3 的查询、筛选、排序和关联；
-   - 表结构与 2.3 相互校验：每个持久化写操作有承载实体，每个查询条件有明确事实字段，需持久化的插件结果归属到对应业务实体；平台内置服务已管理的数据不重复建表；
-   - **派生数据不作为独立真源**：会随业务事实变化的统计值、汇总值、进度、余额、排名、趋势和状态概览，不设冗余字段，不为展示单独建立统计或快照记录，由 2.3 的接口基于事实现场计算。同一业务概念跨页面复用同一事实来源和计算口径；
-   - 只有当汇总或快照本身具有独立业务身份、生命周期，并且 2.3 定义了它的真实生成、更新和消费链路时，才作为业务实体建模；“页面需要展示”不构成建表理由。
+### 2. 核心功能完整，操作链路与数据闭环
 
-2. **确定建表顺序**：存在引用关系的表，被引用的表先建；该顺序只服务于后续建表和初始数据写入，不改变实体边界。
+- **承诺与结果一致**：核心动作必须真实完成其业务含义，写入后可按对象 ID 重新查询，成功页刷新/重进仍能显示该结果；仅 toast、跳页、接口 200 或数据库有记录不足以证明闭环。中间态与终态区分，不能提前显示全部完成或过早清空后续页面所需状态。
+- **对象身份一致**：入口、路由参数、详情、子记录和结果内容属于同一对象。已存在的合法对象不能仅因未出现在最近/摘要列表中就不可访问。无效 ID、无关联记录返回明确空态/错误，不能默认第一条记录来掩盖问题；新对象的可空字段不得使详情崩溃，空链接不渲染可点击目标。
+- **事实与状态来源**：初始数据从源稿明确的既有事实映射、去重并建立有依据的关联，保留各对象所处的业务状态。核心操作按业务规则生成必要关联记录，状态、时间与用户输入随实际执行更新；结果页读取执行后的事实。缺失事实如实展示空态，业务完成依据实际状态判定。
+- **动态数据同一口径**：会随业务变化的展示从事实实时计算，不用预置统计字段/常数替代。写入后的计数、进度、余额与聚合联动；周期选择一致作用于标题、明细和统计；分子分母、过程/结算/历史、时钟与取整口径统一。只为本身具有独立业务生命周期的快照保留持久化，不为展示另造真源。
+- **真实能力与明确边界**：核心 AI、媒体和外部能力取得真实结果或明确失败；检索计数/字符串模板不是 AI 回答，动画计时不是播放。按需读取 `plugin-guide` 并确认运行时 schema，不把普通数据库、定位/导航/扫码或内部演示支付机械判成插件。已明确采用内部演示的能力标识模拟边界，并使用一致、可复核的状态/计算，不能伪称外部执行成功；缺少核心资源则报告阻塞。
 
-3. **规划初始数据**：表结构确定后，再为需要种子数据的表标注源稿中的业务事实记录位置和字段映射。该部分与表结构分开书写：
-   - 只标注源稿文件、区块和字段到表字段的映射；同一实体散落在多个页面时列全位置并按稳定业务标识合并；
-   - 源稿展示格式与存储类型不同时，写明格式解析和单位、枚举、时间的转换规则；初始数据写入严格按该规则执行，不自行改变语义；
-   - 只使用源稿明确给出的业务事实，不补充源稿没有的字段值、记录或关系；源稿只有汇总数字而没有对应事实时，不将汇总数字作为初始数据，也不编造明细凑数；
-   - `docs/business-design.md` 只写来源位置和映射规则，**禁止写实际初始值、示例记录或数据摘要**；实际值由负责初始数据写入的 CodeAct 重新读取源稿后写入。
+## 提效时的执行约束
 
-**2.3 可见功能业务模型与 API 设计**。按 2.1 的业务域逐域进行，为每个域产出核心功能清单与接口设计。
+- 共享层只准备当前批次必要结构与接口，复用已有模板；不批量造空 API/DTO，主 Agent 不先写完所有服务和 SQL 才派发业务任务。
+- 以独占写入范围拆任务。优先按页面拆前端、按 server module 拆后端，让独立页面、后端模块与种子任务同批开始；不要把多页与整个后端塞进一个长任务。公共层一个写入者；公共组件有稳定接口即可并行消费，不等其实现完成。仅消费必要插件/素材的任务等待其结果，不让无关任务一起等待。
+- 种子数据：CodeAct 写种子数据与业务任务并行，按实际 schema 写入源稿已有对象及必要关联，写入成功即完成。统计数据基于实际数据计算，允许与源稿数值不同；运行时验证统一由主 Agent 完成。
+- 开发任务只检查自己改动的类型/契约等静态问题，达标即返回。不运行接口冒烟、启动服务联调、读运行时日志、读库验收或执行 E2E；运行时验证交由主 Agent 组织，避免开发与测试同时改同一资源。
+- 任务单引用所属核心链路、契约路径和独占写入范围，仅补充本任务特有的实现信息。前后端沿用同一结果、状态与统计口径；契约缺口由主 Agent 定点协调修订。回传改动文件、检查结果、实际阻塞和未完成项。
 
-对每个业务域依次完成：
+## 验收准则
 
-1. **识别核心功能**。以源稿的可点控件为识别依据：每个可点控件必须归入一条核心功能，功能内容取该控件的预期结果。识别前先读 `.agent/skills/creative-to-fullstack/references/ui-to-function.md`，按其中「UI→功能映射表」与「UI→capability 常见信号示例」对照组件类型与功能信号。
+**验收前必读 `testing-guide`**，使用设计阶段已确定的清单，不在验收阶段重新扩展业务或以实际弱化实现改写通过标准。
 
-   **按功能族登记，不做逐控件矩阵**：触发语义、输入、结果和状态变化相同，仅作用对象不同的重复控件合并为一条功能；不同页面复用同一能力时也只登记一次，并列出覆盖页面。不同结果、不同状态变化或不同目标页面的控件不得因文案相近而合并。源稿未展示也未暗示的功能不补造。
-
-   每条功能记录为：「功能名称 + 覆盖页面 + 触发方式与输入 + 用户可见结果 + 状态变化或目标页面」。操作结果需要跳转到另一个页面时一并写明目标页面，目标页面不在源稿里时标注为新增页面，在共享结构骨架中补齐路由与页面壳。业务设计只写功能族；逐个控件的覆盖关系在 2.5 通过源稿反查校验，只有漏项才展开记录。
-
-   **源稿未画出点击后的页面不构成豁免**：该控件仍识别为核心功能，目标页面按新增页面登记。可点控件是否构成核心功能存疑时，按构成处理。
-
-2. **能力选型**。对每条核心功能按以下顺序判定实现方式：
-  - 预期结果仅为同一页面内的呈现变化，不涉及库内数据与外部能力 → 随页面视觉还原实现，不设接口，不进第 3 条；
-  - 平台内置服务（用户、文件、权限、消息、自动化/定时）可满足 → 直接使用，标注「使用平台内置服务：[服务名]」，禁止自建同等能力；
-  - 功能涉及 AI、智能、自动生成、大模型、文本生成、图片生成、飞书、消息通知、群组、机器人等能力 → 判定为插件能力，登记进 2.4 做插件设计；普通前后端能可靠实现的不硬凑插件；
-  - 以上都不满足 → 自建服务端 API，进入第 3 条。
-
-   判定时对照源稿补漏，两种都登记进 2.4：以假逻辑模拟、未以可交互组件呈现的（定时提醒、自动通知）；把智能产出画成已完成结果的（已生成的摘要、已提取的条目、带 AI 标记的内容块）。判据是这段内容真实使用中由谁产生——由模型产生就不能当初始数据誊写入库。
-
-3. **API 设计**。为自建 API 的功能设计接口：
-  - 同一数据实体的操作合并设计：列表查询一个接口，入参覆盖该页全部筛选维度、搜索关键词与分页参数；新建、更新、删除、详情各一个接口；
-  - 随业务数据而变的出参必须在接口条目内就地写明「事实来源 + 计算/筛选口径 + 哪类事实写入会使它变化」；共用同一口径的多个出参可合并说明，不另建全量数据血缘矩阵；
-  - 派生出参只能从事实表或真实外部能力结果计算，禁止读取为展示而单独预置的统计/快照记录；事实写入成功后，相关查询不得依赖人工同步第二套数据；
-  - 每个接口写明：方法与路径、入参与出参、读写的表、支撑的功能；字段类型、业务语义和必要的格式转换与 2.2 保持一致，不另起一套。
-
-本节产出是第 4 步各域任务服务端子步骤的实现范围（域任务的 Service/Controller 按 API 清单逐接口实现），也是第 5 步验收目标的选取来源。
-
-**2.4 插件设计（条件步骤，仅当 2.3 判定出插件能力时执行）**。先读取 `plugin-guide` skill 了解插件目录与调用规范，然后对 2.3 登记的插件需求逐项设计。
-
-设计原则：
-
-- **原子化拆分**：一个插件实例只做一件事——不同输出类型（文本/图片/消息）建独立实例，不同业务语义（如标题与正文）建独立实例；
-- **链路完整性**：从用户输入到展示/落库，每一步都有对应插件——链式场景如文档解析→结构化提取需要两个插件；
-- **调用方式选择**：默认前端 capabilityClient 直接调用；以下情形改为服务端调用并说明原因：调用前需验证权限、需记录调用日志、结果需先落库、定时任务或 Webhook 无前端上下文、需聚合多个插件结果。
-
-输出格式，每个插件一行：
-
-| 插件名称 | 基础插件 | 用途 | 调用方式 | 关联页面/接口 | 输入参数 | 输出类型 |
-| --- | --- | --- | --- | --- | --- | --- |
-
-**2.5 业务设计门禁（主 Agent，进入第 3 步前执行）**。门禁只检查通用不变量，不要求输出逐控件矩阵或全量血缘表。逐条检查并在 `docs/business-design.md` 末尾记录五项结论；通过项只写一句依据，失败项列出具体漏项并修正设计，全部通过前禁止建表或派发实现：
-
-1. **交互覆盖**：从全部源稿页面反查 `button`、链接、表单、筛选、Tab、行操作和其他可点外观，每个都能归入 2.3 的某个功能族；重复实例只核对是否复用同一行为，不逐项写入设计文档。不存在因“目标页没画”“接口还没有”而取消的可见功能。
-2. **闭环成立**：每个功能族都有明确输入、用户可见结果、状态变化或目标页面；写操作包含真实写入、反馈和重新读取，失败时有可理解、可恢复的反馈。
-3. **模型合理**：每张表都能说明对应业务实体及生命周期；主键、业务唯一键、关系基数、引用完整性、状态和必要约束齐全，不按页面或展示区块机械建表，不用展示字符串代替实体关系。
-4. **数据可推导**：每个动态出参都在所属接口内写清事实来源、口径和变化触发；不存在仅为页面展示而保存的派生字段、统计表或快照记录，不存在为凑源稿数字而编造的业务事实。
-5. **单一真源**：同一业务概念跨页面、接口和状态流转使用同一事实来源与口径；不存在需要人工双写、定时补齐或前端自行修正才能一致的第二套数据。
-
-`docs/business-design.md` 写完后，用 TodoWrite 建执行清单，条目至少覆盖：每个基建项、每个业务域实现任务、**验收任务**（此刻即加入清单）。
-
-### 第 3 步：基建
-
-共享结构骨架完成后，主 Agent 完成建表并生成 schema，再同批并发派发三项：公共视觉层 Worker、初始数据 CodeAct、插件实例 Worker（2.4 有产出时）。三项全部完成后，派发所有无数据依赖的业务域 Worker 并发开发，验收前必须全部完成。
-
-**3.1 共享结构骨架（主 Agent）**。先读取 coding-guide skill 了解项目规范，再依据 `docs/business-design.md` 基于现有工程一次性补齐后续任务共同依赖的最小结构：
-
-- 确定页面、业务域及 2.1 共享视觉资产的代码目录归属；为每个源稿页面和 2.3 记录的新增页面补齐语义化路由，复用已有页面壳，只为缺失页面创建最小可渲染页面壳；
-- 配置默认页，以及包含页面内容容器和路由出口的 Layout 骨架；
-- 按 2.2 和 2.3 定义 shared 实体类型及 API 请求/响应契约；
-- 按 2.1 为每个业务域注册空 Module、Service 和 Controller 骨架。
-
-完成后确认工程可编译，且每个页面都有路由和目录归属、每项共享视觉资产都有目标目录、每个业务域都有模块边界与 shared 契约。
-
-**3.2 建表（主 Agent）**。确认 2.5 五项门禁全部通过后，按 `docs/business-design.md` 2.2 确定的建表顺序逐张建表，被引用的表先建。表结构取自 2.2 设计，不涉及源稿内容誊写。只建真实业务实体和关系表；仅服务于页面展示的派生字段、统计表、排行表、趋势表或快照表不得创建，除非 2.2 已证明它本身是具有真实生成和更新链路的业务实体。建完后跑数据库 schema 代码生成刷新 `server/database/schema.ts`，后续 CodeAct 与业务域 Worker 均以该文件中的真实列名和类型为准。
-
-**3.3 全局 Layout 与跨页面公共组件（派发 Worker）**。按共享视觉资产清单读取对应源稿，写入共享结构骨架确定的目标目录，只实现全局视觉框架和跨页面复用的展示组件：
-
-- 在 Layout 骨架上实现并装配导航、侧栏、页眉、页脚等全局框架，对齐源稿的结构、固定文案、色值、字体、间距和内容区域约束；导航目标只使用已注册路由；
-- 每个跨页面公共组件只实现一份。固定文案、图标和视觉结构照源稿实现；业务实体、状态和动态值改为由 props 传入，业务操作通过事件回调暴露，不在公共组件内调用业务 API、插件或维护领域状态；
-- 页面专属组件和页面内容不在本步实现，由所属业务域任务完成。
-
-完成后确认全局 Layout 已实际挂载、所有路由页面使用同一套全局框架、公共组件可被域任务直接引用且工程可编译；只创建组件文件但未接入应用不算完成。
-
-**3.4 初始数据插入（**必须**派 `CodeAct` 执行）**。数据内容**必须**由读到源稿原文的执行者当场写入，读源与写库之间不经过任何交接——**通读阶段读过源稿不算**，隔了若干轮之后凭记忆写出的记录必然是编造的。
-
-派发对象：`CodeAct`——它同时具备读文件与执行 SQL 的能力，读完源稿即可落库，报错时源稿仍在上下文中可直接改正。
-
-**派发内容**：本次负责的表清单、每张表在 2.2 的源稿位置标注、建表顺序、`server/database/schema.ts` 的路径。
-
-**任务要求**：
-
-- 按标注打开源稿文件、定位到该区块后再写；区块落在文件后段时读到该区块为止，禁止只凭文件开头写数据；
-- 列名与类型照 `server/database/schema.ts`；`_` 前缀的系统字段与主键不写，由数据库默认值生成；
-- 字段值来自读到的源稿业务事实，**这是映射不是创作**：除 2.2 初始数据规划明确声明的格式与类型转换外，不改写语义、不增删记录、不补充源稿没有的字段值或关系；
-- 只写具有独立业务身份、能参与查询或状态变化的源稿事实记录；KPI、汇总、趋势、占比、排名、进度、余额等派生展示值不作为初始记录写入，源稿事实不足时不得编造明细使其对上；
-- 素材字段写本应用内取得到的地址：源稿的引用指向源应用运行时存储，本应用取不到时，生成替代图后写它的地址；
-- 2.2 初始数据规划标注的业务事实记录全部写入，一条不漏；同一实体在多个页面出现时按稳定业务标识去重并合并已明确的事实字段，不重复插入；
-- 子表外键用 `SELECT` 子查询按业务键（标题、名称等）关联父行，禁止硬编码 UUID。
-
-达标标准：2.2 初始数据规划中的每条业务事实均按映射写入，表间关系正确，首次查询可返回且业务语义与源稿一致。禁止把初始数据做成运行时 mock 接口或前端写死；页面视觉是否完整由页面实现与验收单独检查。
-
-**3.5 插件实例（条件步骤，2.4 有产出时执行；派发 Worker）**。整份 2.4 清单交给一个 Worker 建实例并确认契约，调用代码由所属业务域任务实现：
-
-1. 调用 `plugin_instance` 工具创建插件实例，彼此无依赖的实例在同一批次并发创建，只有输出需作为下一实例入参的链式实例才顺序建；禁止手工修改 `server/capabilities/` 目录；
-2. 获取运行时 schema，逐字段确认 inputSchema 与 outputSchema 的字段名、类型、是否必填；
-3. 回传每个实例的实例名与 schema 摘要（字段名、类型、必填）。主 Agent 把摘要写进该插件所属域的派发指令，供域任务按 schema 编写调用代码。
-
-规则：
-
-- 禁止只创建实例而不在域任务中安排调用代码——未生成调用代码的插件实例是无效的；
-- 域任务编写调用代码时，入参出参的字段名与类型以运行时 schema 为准，禁止从设计文档推测（设计可能与插件实际 schema 不一致）；入参中的动态配置值（接收人、通知模板、阈值等）禁止硬编码，从配置表或平台 API 获取；
-- 插件结果需要持久化时，优先在该域 Service 内调用插件并在同一方法内落库；保持前端调用的，成功后通过已有业务 CRUD 接口保存结果，不为此单独新建 API；
-- 后续任一阶段发现缺插件实例，主 Agent 立即用 `plugin_instance` 工具补建，禁止用 pluginKey 冒充 instanceId 调用或跳过该功能。
-
-### 第 4 步：按业务域派发实现（Worker）
-
-确认全局 Layout、跨页面公共组件、初始数据和所需插件实例全部完成后，按「业务模块闭环拆解规则」把每个业务域派发为一个 Worker 任务。派发前重读 `docs/business-design.md`，按其中的业务域划分逐域生成任务。
-
-**核心原则**
-
-- 任务范围是该域的前后端完整实现：Service、Controller、页面内容、页面专属组件与接口集成都在同一个任务内；共享结构骨架、全局 Layout 与跨页面公共组件不在域任务中重复实现；
-- 服务端代码不得摘出来由主 Agent 代写——Worker 跑不了接口测试与运行时日志是预期的，运行时验证统一在第 5 步做；
-- **派发指令不写源稿的具体内容**: 避免实现时没有按照原稿而是按照指令开发。
-
-**每个任务必须携带**：
-
-- 权威文件位置：该域相关的源稿文件、`docs/business-design.md`、该域的 shared 契约文件与既定路由文件——只给路径，禁止用文字概述替代源文件，由 Worker 自行读取；
-- 双权威声明：视觉结构、固定文案、布局与呈现格式以源稿源码为唯一权威；业务数据以真实接口返回为准；表结构、API、插件调用以 `docs/business-design.md` 该域章节为准；
-- 全局 Layout 与公共组件位置：全局框架已统一接入，域任务只填充页面内容；公共组件直接 import，**禁止在页面内重新实现同名组件**；清单之外且只属于本域的组件才在页面内实现；
-- 一句话验收标准（acceptance），落在真实能力层（如「提交后经真实接口落库且刷新后可回查」），达标即完成，禁止超出标准的冗余自查；
-- 只写任务目标、源稿位置、验收标准，源稿的具体内容由 Worker 按位置自己读；
-- 让 Worker 在开工前感知到「任务内执行顺序」以及「视觉一致性」「功能真实性」两节规则。
-
-**任务内执行顺序**
-
-1. 读取 coding-guide 及与本域相关的 skill；
-2. 读源稿该域文件，读 `docs/business-design.md` 该域章节（功能清单、表结构、API 清单）；
-3. 检查 shared 契约与该域表结构、接口设计一致；按既定目录结构落文件，不另建与之平行的目录；
-4. Service 层：业务编排、落库、插件调用聚合、内置服务调用；服务端调用的插件逐条写明「调用 [实例名]，触发条件为 [条件]」；
-5. Controller 层：REST API，按该域 API 清单逐接口实现，避免纯透传接口；
-6. 在已注册路由与页面壳内实现页面，不重新配置全局路由或 Layout；
-7. 页面与组件实现：打开源稿对应区段对照实现，固定文案、色值、条目结构与顺序照源码转写；业务实体、状态和动态值来自本域真实接口，禁止 mock 业务数据；复用公共组件，只在本域实现页面专属组件，组件不拆出独立任务；
-8. 可点元素处置：落在 2.3 功能清单里的全部接上行为。发现清单外的可点元素说明 2.5 门禁漏项，**不得自行去掉交互、补造接口或把它静默留空**；写入 `docs/design-gaps/[域名].md`（文案、页面、预期行为、需要补齐的设计项）并回报主 Agent。主 Agent 更新 2.2/2.3、路由与契约后重新派发；只有源稿本身明确为纯装饰、且不存在可点语义的元素才可保持非交互。该文件是本任务交付物，无则写「无」；
-9. 前端插件集成（2.4 设计为前端调用的插件）：获取插件运行时 schema，按 schema 调用 [实例名]，字段名与类型以运行时 schema 为准、不从设计文档推测；结果需持久化的，调用成功后通过已有业务接口保存；
-10. 代码级自查：类型一致性、契约覆盖、shared 定义对齐。禁止运行时验证——接口冒烟、起服务联调、读运行时日志、E2E 一概不做，统一在第 5 步由主 Agent 执行。
-
-指令里给出的文件路径是**必读下限，不是可读上限**：实现中需要的其他工程文件（既有组件、工具函数、全局配置、路由表）一律按需自行读取。禁止的是重新推导架构：不重新规划目录与路由结构，不反复 glob 全工程。
-
-Worker 回传后，主 Agent 至少读一个关键产物文件抽查（页面是否调真实 API、功能链路是否接通）；回传中的「已完成、已验证」不作为核验依据。
-
-`docs/design-gaps/[域名].md` 非空说明 2.3 或 2.5 漏了元素，主 Agent 逐条补齐功能、接口、页面、表或插件设计后重新派发；禁止把源稿可见功能以“无法实现”或“无目标页”为由降级掉。
-
-**自动化任务**：2.3 中选型为平台自动化内置服务的功能（定时触发、数据变更触发），作为独立任务实现，依赖其用到的表与插件：
-
-1. 读取 trigger-guide skill 了解触发器配置与代码开发规范；
-2. 创建触发器，实现任务逻辑：触发条件判断、去重、插件调用、状态更新；
-3. 完成后验证代码可编译。
-
-
-### 第 5 步：验收（清单里的任务，不是可选动作）
-
-commit 的静态检查只覆盖编译与 lint，证明不了功能可用与视觉一致。验收开始前先读取 testing-guide skill 了解 E2E 验收流程，并重读 `docs/business-design.md`，以其中的 2.3 功能与 API 清单为验收目标来源。按以下结构执行，完成前不得提交收尾：
-
-1. **架构与入口检查**：检查路由、页面归属、shared 契约和模块边界，再对照源稿检查全局 Layout 是否挂载以及导航项数、文案、顺序、主题色值和内容区域约束，发现偏离先修对应层再继续。再做三项核对：
-   - **链接目标可达**：枚举代码中全部跳转目标（导航项、按钮、卡片、搜索、面包屑）与路由表比对，任一指向未注册路由即未通过；
-   - **页面均有入口**：每个已注册页面至少有一个应用内可达入口，只能手输 URL 到达的页面即未通过；
-   - 应用入口页面可正常打开，打不开（白屏 / Page not found）则停止验收，只记录阻塞问题。
-2. **功能族覆盖验收**：从 2.3 生成验收目标，不设全应用固定数量上限。每个会写数据或改变业务状态的功能族至少实操一次；纯查询类按不同查询机制（搜索、筛选、排序、分页、切换、跳转）各选一个代表实操，行为相同的重复控件不重复测。每个目标写成「验收对象 —— 应用内点击路径 —— 可判定的通过标准」，必须从应用可见入口开始逐步点击，禁止手输内部 URL 代替可达性验证。通过标准必须包含状态更新、刷新回读、列表/详情变化、真实结果或可恢复错误之一；「页面渲染正常」「控件可见」「按钮可点击」不构成通过标准。派发 E2E agent 实际执行。
-3. **业务闭环验收**：每个独立业务域至少选一条包含起点、过程和业务结果的主链路；若多个域共享同一条跨域链路可合并执行。链路中不得从预置中间态开始来替代创建或触发步骤，源稿未画出的新增页面也必须通过应用内入口到达。
-4. **可降级范围**：AI 内容质量、真实消息送达、复杂批量数据一致性、导出文件内容正确性、低风险视觉细节可降级不阻塞；但被降级能力在应用内的触发、状态与错误反馈仍必须纳入对应功能族验收，不得完全消失。
-5. **初始事实核对**：只对 2.2 建模的业务事实表做 COUNT 与文案抽查，与源稿实体记录对照；条数或文案不符即为未通过。逐个打开源稿画了实体数据的列表与区块，看应用里是否真的渲染出行：**库里有行而页面为空即未通过**。KPI、图表、排行、趋势等派生值不与源稿数字做入库对账。
-6. **动态联动核验**：按 2.3 中不同的「事实来源 + 计算口径 + 变化触发」组合各选一个代表，不按页面或组件重复测试。先记录动态输出，通过应用内真实功能写入或变更一条可唯一识别的事实，刷新并重新查询，确认相关输出按口径变化、跨页面结果一致，且无关输出不被错误改动；再核对数据库只新增或修改事实记录，没有人工同步的统计/快照记录。没有任何可执行写入口能触发变化，说明功能或数据模型未闭环，按未通过处理。
-7. **假实现与派生快照 grep**：命中即未通过——simulate、写死结果的 setTimeout、picsum、假 toast、Math.random 业务值。再 grep 成组出现的业务数值字面量和疑似派生/统计持久化字段或表；不能证明其具有独立业务身份及真实生成更新链路的，改为基于事实的实时计算。
-8. **跨应用素材引用 grep**：在工程代码与初始数据里搜 `/spark/app/`，出现的 appid 不是本应用的即未通过——换成本应用内的地址后重跑。再逐页确认图片真的加载出来（`naturalWidth > 0`），加载失败的按未通过处理。
-9. **公共组件边界与唯一性**：grep 组件定义（`function X(`、`const X = (`、`const X: React.FC`），同名组件在两处及以上定义即未通过——合并到公共组件目录、页面改为 import 后重跑。再检查公共组件不得包含业务数据常量、业务 API 或插件调用、领域状态；命中时把业务逻辑移回所属域，公共组件只保留 props 与事件回调。
-10. **假可点对账（门禁，grep 判不了）**：逐页在浏览器里枚举「有可点外观（`button`、`a`、`role=button`、`role=tab`、`cursor:pointer`）但取不到事件绑定或 `href`」的元素，并反查 2.3 功能族与各域 `docs/design-gaps/*.md`。**存在未归属或未接通的元素即未通过**：先补业务设计，再补接口、页面、插件或行为并重跑；禁止仅为通过验收而撤掉源稿已有的交互外观。功能族数量、浏览器发现的交互实例数、未归属数写进对照表，无需输出逐控件矩阵。
-11. **验收对照表**：列出功能族覆盖、业务主链路、动态推导组合及其通过/失败结果，再列出其余门禁结论。未执行的项写明原因，不得笼统声称“验收通过”；任一必要功能族、主链路或动态推导组合未覆盖，均不得判定完整通过。
-12. **摘除注入标记**：以上各项全部通过后执行 `rm -f source_package/creative/.upgrade-manifest.json`。该文件是本指引的 SessionStart 注入门控，删除后本指引停止注入，后续迭代不再重复进入升级流程；源稿其余文件保留供以后对照。任一项未通过时不得删除——下轮修复仍需本指引在场。
-
-## 业务模块闭环拆解规则
-
-按业务域（Module）拆分实现任务，每个任务同时覆盖该域的服务端实现（Service + Controller + DTO）与对应前端页面（路由 + 页面 + 组件 + 接口集成），命名为 `[业务模块名]模块开发（含前后端）`。**同一业务域的前后端禁止拆成独立任务**。与通用全栈开发的唯一差异：拆解依据是**创意模式的源稿代码**（页面结构与可见交互组件），而非需求文档。
-
-1. **模块边界判定**：任务拆分优先服从代码所有权边界，而非仅按页面归属或功能语义拆分。若多个页面、功能最终落在同一个 server module 中实现，必须合并为同一个模块任务，不得拆成多个并行任务。
-2. **server module 判定口径**：同一个 server module 包括但不限于同一业务目录下的 Service、Controller、DTO、Repository、模块注册文件、聚合导出文件，以及需要共同修改的 shared 契约文件。
-3. **纯展示/即时场景**：若某业务功能已规划在前端使用插件实现，且不需要数据库存储，则该模块任务中无需包含服务端 Service/Controller 子步骤，仅保留前端 + 插件集成。
-4. **需持久化场景**：若插件调用的结果需要保存到数据库，优先在该模块的 Service 中调用插件并落库；或在已有业务 CRUD 接口中扩展字段接收前端传来的插件结果。禁止为"保存插件结果"单独新建模块。
-5. **平台内置服务**：模块内需使用的平台内置服务，在该模块的 Service 部分完成配置与调用。
-6. **入口模块优先**：将承载入口页（列表页/首页）的模块任务置于全部模块任务的第一项。
-7. **并行安全**：模块任务内**禁止包含运行时验证**（接口冒烟测试、启动前后端服务联调、读取服务端/前端运行时错误日志、E2E 测试），统一推迟到第 5 步验收阶段。允许保留的验证限定为代码级静态自查（类型一致性、契约覆盖、shared 定义对齐）。
-8. **启动条件**：结构骨架、schema、公共组件、初始数据和所需插件实例全部就绪后才派发模块任务；模块任务之间无数据依赖时全部可并行，禁止链式依赖。
-9. **公共组件不进域任务**：共享视觉资产清单中的全局 Layout 和跨页面公共组件统一实现，域任务只 import 和传入业务数据、事件，不重写视觉结构；发现清单漏项时先补充清单并完成公共组件实现，不在多个域中各写一份。
-10. **超大域拆分**：命中业务域划分中拆分条件的业务域不得作为单一任务，按子域分别派发；无数据依赖的子域按规则 8 并发执行。
-
-## 视觉一致性原则
-
-- 布局用 flex/grid 加 gap 直接转写源稿结构，不重新设计。
-- **数据模型与视觉承载分开处理**：不得为了复刻页面而反向增删业务实体和字段。固定文案、导航、区块标题、装饰、图标和样式直接按源稿实现；业务实体字段、状态和动态值经真实接口呈现。
-- 页面固定内容、初始业务事实的呈现、条目结构与顺序、色值、字符图标和选中状态与源稿逐项一致；动态值只对齐单位、格式和排布。
-- 动态获取的内容只对齐源稿的呈现形式（单位、格式、排布），值由真实数据决定。
-- 字符图标保持原字符；源稿已有的 SVG、CSS 渐变复用或等价转写。
-- 源稿素材在本应用内取不到时（如图片指向源应用的运行时存储），不照抄原引用——自行生成替代图并使用，同一位置的图只生成一次；生成不了的报回主 Agent，不留坏链。
-- **公共组件只有一份**：共享视觉资产清单中的全局 Layout 和跨页面公共组件只实现一份；域页面直接 import 并传入业务数据和事件，不在页面内复制视觉结构。只属于单个业务域的页面专属组件才就地实现。
-- 写任何产生页面可见内容的代码之前，重新打开源稿对应位置读取。
-- 确有必要的转换（如固定画布改响应式）需说明转换前后形态，且不改变源稿参考尺寸下的构图。
-
-## 功能真实性原则
-
-- 写操作必须走完「前端事件 → 接口 → 数据库/插件 → 界面反馈」全链路，写入结果刷新后仍能读到。
-- 搜索、筛选、排序、分页的参数必须传入真实查询；跳转、Tab、弹窗到达正确的路由或状态。
-- **链接目标必须存在**：写任何跳转前先读既定路由文件，目标只能是已注册路由；源稿有可见入口但没有承载页面时，必须先按功能设计补齐新增页面与路由，禁止以缺少目标页为由取消功能或指向未注册路由。
-- 持久化业务结果由服务端校验前提并写入，前端只展示重新读取的事实。
-- 有数据库时禁止用 mock 数据代替真实查询；插件返回值严禁 mock，前端用 capabilityClient 真实调用，或调用集成了插件的真实服务端接口。
-- 自建 HTTP API 不实现 SSE/WebSocket；插件链路的流式输出（outputMode=stream）不受此限。
-- **有可点外观就必须有行为**：行为的目标照 2.3 的功能清单与既定路由文件接；只有源稿明确为纯装饰且不存在交互语义的元素才去掉手型与悬停态，禁止因为实现成本或缺少目标页撤掉源稿已有功能。
-- **随业务数据而变的值一律算出**：在 service 内从业务事实聚合，不落成前端常量、`return` 的字面量、冗余派生字段或独立统计快照；事实变化后相关页面重新查询使用同一口径。算出的值与源稿数字不一致是预期结果，源稿事实不足时不得编造明细凑数。
-- **媒体控件绑真实媒体**：播放、进度、倍速挂在真实媒体元素上，时间由它驱动；无媒体资源时整组去掉可点外观。
-- 禁止：空链接、只切换图标不产生数据变化、写死的"成功"提示。
+1. **真实操作核心链路**：验收从应用首页或正常业务起点开始，通过用户可见的导航、按钮或业务操作到达目标页面，记录入口操作与到达结果。同一核心链路连续使用同一对象；包含创建时，将新建结果用于后续操作。一次执行核对必要输入的保存与回读、关键状态变化、真实结果及关联动态输出，并完成刷新或跨页回读。
+2. **完整视觉**：覆盖全部源稿页面，逐页确认主要布局、内容、图表、导航与图片；允许动态数值和无影响的小图标差异。
+3. **针对性修复**：先看失败步骤的请求、ID、状态及相关代码，结合源事实区分应用缺陷、测试假设错误与平台问题；只修核心功能问题或实质视觉问题，不新增身份/权限体系或源稿外业务。已有平台与 coding-guide 约束仍须满足。应用或测试修正、平台恢复后定向复测受影响链路；提交自动修复改变关键行为后也须复测。同一结果复用证据，不重复整套无关验收。不以关键词命中或同名组件一概判错，不搞全库对账。
+4. **如实交付**：清单逐项记录通过/失败/未测和证据，复测保留各核心功能的实际验收状态，披露核心阻塞。核心功能和视觉验收全部通过后宣称完成，并移除 `source_package/creative/.upgrade-manifest.json` 停止重复注入；其他源稿保留。存在失败或未测项时保留标记与证据，如实交付当前状态。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lark-apaas/coding-miaoda-sandbox-skills",
-  "version": "0.1.24",
+  "version": "0.1.26",
   "description": "Miaoda 合并沙箱 skills 包（包含原 miaoda-skills 的 miaoda / miaoda-modern / miaoda-design / shared 四条业务线）；发布公网 npm，随沙箱运行时经 update-skills 同步到 .agent/skills/",
   "type": "module",
   "files": [

package/miaoda/creative-to-fullstack/references/artifact-signals.md

@@ -1,47 +0,0 @@
-# 创意产物类型信号表与分类型拆分细则
-
-创意模式产物是 design-html 技术栈的静态工程：`index.html` 为入口，可能带 `components/` 或 `screens/` 目录（`.jsx` 经 `<script type="text/babel">` 在浏览器内编译）。先读 `index.html` 全文 + 目录清单，再按下表判类型。**支持生成的只有三类**：多屏设计稿（artboard）、移动端 mockup、可交互原型；报表 / deck / 图文卡片 / 动画为产品范围外，判中即停止并告知用户（入口层正常会拦截，此为防御兜底）。若会话上下文提供了「当前选中的设计稿文件」路径，判型与拆分优先以该文件为主入口。
-
-## 类型判定信号表
-
-| 类型 | 判定信号（任一命中） | 实现形态 |
-|------|---------------------|----------|
-| 演示稿（deck） | `<deck-stage>` / 翻页控件 / 每屏是「第 N 页」式幻灯结构 | **范围外，停止并告知** |
-| 图文卡片（social card） | `<card-stage>` / 一组固定竖版 `<section>` 卡片（1080×1440 这类上传规格）+ 每卡独立成图 | **范围外，停止并告知** |
-| 多屏设计稿（artboard） | `<DCArtboard>` / `design-canvas` 缩放壳 / 多画板平铺 + 画板 label | 每画板 → 路由页 |
-| 移动端 mockup | 设备框组件（iOS/Android 壳：`width:390` + 圆角 + 状态栏/灵动岛） + `screens/` 或 `screen-*.jsx` 多屏 | 每屏 → 路由页；框内 tab → 应用导航 |
-| 交互原型 | `useState` / 事件处理驱动页面切换，无画布壳，本身像单页应用 | 按其内部「视图状态」拆路由页 |
-| 报表看板 | echarts / 图表库 + 指标卡片布局 | **范围外，停止并告知** |
-| 纯动画/视觉演示 | 大量 keyframes/canvas 动画、无业务 UI | **范围外，停止并告知** |
-
-混合信号时以「业务 UI 占比」为准：有表单/列表/详情等业务界面 → 按设计稿/原型类正常生成（防止 deck 里嵌了真实业务界面设计被误杀）；纯展示 → 判为范围外。
-
-## 分类型拆分细则
-
-### 多屏设计稿 / 移动端 mockup
-
-1. 枚举所有屏：`data-screen-label` 属性、画板 label、`screen-*.jsx` 文件名，三者取有值的作为页面名与路由名来源。
-2. 稿内导航（底部 tab / 侧边栏 / 顶部菜单）转为工程导航结构；未出现在导航里的屏（如详情页、由弹层提级的独立页）按从属关系挂到父页面路由下。
-3. 导航项逐项承接源稿：数量、文案、顺序与源稿一致。源稿导航中没有对应画板的项不得删除，也不得添加源稿没有的导航项；这类项的点击去向在方案中写明（例如指向相关页面的对应区块，或在方案的未决事项中说明），不得静默决定。
-4. 设备框（手机壳、浏览器壳、`IOSFrame` 这类组件）是预览容器：取 `children` 内容做响应式页面；状态栏、灵动岛、Home 指示条随壳丢弃。
-5. 稿内固定尺寸（390×844、1920×1080 加 scale 缩放）改为真响应式：内容宽度用容器约束（如 `max-width` + 居中），移动优先或桌面优先取决于原稿形态。
-
-### 交互原型
-
-1. 找出所有「视图状态」：`useState` 切换的 tab/step/modal 中承载独立业务界面的 → 路由页；纯交互细节（折叠、hover）→ 保留为组件内交互。
-2. 原型里已经写了的交互逻辑（校验提示、乐观更新、步骤流转）是功能需求的最强信号，逐条纳入第 2 步的可见功能清单。
-
-### 报表看板
-
-范围外类型，不做生成。若混合产物中局部包含图表且整体被判为设计稿/原型类，图表部分按 `ui-to-function.md` 的"统计卡片/图表"映射行处理。
-
-## 稿内机制识别速查
-
-| 稿内出现 | 含义 | 处置 |
-|----------|------|------|
-| `<script type="text/babel">` + `@babel/standalone` | 浏览器内编译 JSX 的预览机制 | 内容重写为工程组件，机制丢弃 |
-| `unpkg-sdk/react@*/umd/*.js`（miaoda.feishu.cn 镜像） | CDN React 运行时 | 丢弃，用工程自带 React |
-| `Object.assign(window, { Xxx })` | 组件挂全局供跨 `<script>` 引用 | 转译为模块 import/export |
-| `data-miaoda-*` / `data-screen-label` | 创意平台标注属性 | 属性丢弃；label 值用作路由/导航命名后即弃 |
-| `miaoda.feishu.cn/fonts/css2?family=...` | 字体镜像 | 保留，生产可用 |
-| tweaks / EDITMODE 面板 | 设计期调参 | 当前参数值固化进主题 token，面板删除 |

package/miaoda/creative-to-fullstack/references/ui-to-function.md

@@ -1,70 +0,0 @@
-# UI→功能推导映射表
-
-设计稿里的每个 UI 元素都是功能需求的证据。本文件只提供对照表，供 SKILL.md 第 2 步业务设计时查表使用。产物结构、登记格式与流程口径一律以 SKILL.md 为准，本文件不重复、不改写、不另立模板。
-
-## UI→功能映射表
-
-| 稿内 UI 元素 | 数据模型 | 接口 | 页面行为 |
-|--------------|----------|------|----------|
-| 表单（输入框/选择器/提交按钮） | 表单字段 → 实体字段（含类型与必填） | 创建/更新写入接口 + 校验 | 提交、校验提示、成功/失败反馈 |
-| 列表/卡片流 | 列表项字段 → 实体查询投影 | 查询接口：排序、过滤、分页 | 空态、加载态、分页/滚动加载 |
-| 详情页 | 单实体全字段 | 按 ID 查询 | 不存在时的 404 处理 |
-| 统计卡片/图表 | 无新实体，基于既有实体聚合 | 聚合接口（count/sum/avg + group by 维度） | 时间/维度筛选联动 |
-| 头像/昵称/个人页/「我的」tab | 用户实体 + 业务数据挂 userId | 当前用户接口；业务查询按用户隔离 | 登录态展示 |
-| 状态标签（待办/进行中/已完成等） | 实体 status 字段 + 合法流转 | 状态变更接口（校验流转合法性） | 状态筛选、变更操作入口 |
-| 搜索框 | — | 查询接口加关键字参数 | 防抖、无结果态 |
-| 删除/归档按钮 | 软删或归档字段 | 删除/归档接口 | 确认交互 |
-| 日期/日历视图 | 实体时间字段 | 按时间范围查询 | 日/周/月切换 |
-| 稿内示例实体记录（列表/详情中的业务条目） | 对应业务实体与关系 | 真实查询接口 | 作为可追溯初始事实写入数据库，页面走真实查询 |
-| 稿内 KPI/图表/排行/趋势数值 | 不建展示快照实体 | 基于业务事实现场聚合 | 只对齐组件、单位和格式；事实不足时显示真实空值/零值，不誊写数值、不编造明细 |
-
-推导原则：稿内实体字段要能回答「它来自哪个业务事实字段」；动态值要能回答「它由哪些事实按什么口径计算、哪类写入会使它变化」。回答不了时先补真实业务模型；源稿没有事实依据时返回真实空值或零值，不得用硬编码、统计快照或编造明细代替。
-
-**多维组件必须逐维度登记字段绑定**：一个组件同时承载多个可见维度时（如状态标签的「显示文案」与「视觉状态/颜色」是两个维度），每个维度显式写明绑定哪个字段（如文案 ← `docType`、颜色 ← `status`），不得用同一个状态字段既当文案又当颜色，导致所有行渲染成同一个值。
-
-## 前后端接口与数据口径一致
-
-同一业务数据经过前端、API、服务端、数据库或插件时，字段名、类型、单位、取值范围、枚举、是否必填和默认值必须一致。优先在共享接口类型中定义请求与响应结构，前后端不得各自发明不同口径。
-
-只为容易产生歧义的数据建立口径清单，不要罗列所有普通字段。必须登记：金额、比例、时长、距离、时间等带单位字段，状态和类型枚举，单值/多值，可空/选填/默认值，插件结构化输出，以及展示值与存储值不同的字段。
-
-| 业务数据 | 请求/响应字段 | 类型与取值 | 单位/范围 | 服务端与 DB | 页面展示 |
-|----------|---------------|------------|-----------|-------------|----------|
-| 示例：商品价格 | `minPrice` / `maxPrice` | `number` | 分，非负整数 | DB 存分，仅在明确边界转换 | 展示时除以 100 |
-| 示例：搜索类型 | `types` | `SearchType[]` | 约定枚举，可多选 | 按数组执行 `IN` 查询 | 多选筛选器 |
-| 示例：置信度 | `confidence` | `integer` | 0–100 | DB 与插件归一化后均存 0–100 | 直接追加 `%` |
-
-## UI→capability 常见信号示例（非完整插件目录）
-
-创意稿里被 mock 的 AI/飞书类能力，生成时用**真实插件**实现。下表只帮助从 UI 语义识别插件候选并触发 `plugin-guide`，不是平台能力清单；表外疑似插件能力也要召回 `plugin-guide`。实际可用能力以其动态提供的 `available_plugin_instances`、`available_plugins` 及候选实例的 `get_plugin_ai_json` 为准。
-
-| 稿内 UI 语义 | 候选 capability（以动态目录为准） |
-|--------------|-------------------|
-| "AI 生成/智能生成/一键生成文案"、聊天对话框、智能问答 | `ai-text-generate` |
-| "AI 生图/配图/封面生成/头像生成" | `ai-text-to-image` |
-| 上传图片"识别/提取字段"（发票/名片/证件/表单） | `ai-image-to-json` |
-| 上传文档"解析/总结/提炼" | `ai-doc-parser` → `ai-text-to-json` / `ai-text-summary` |
-| "翻译" | `ai-translate` |
-| "语音转写/录音转文字" | `ai-speech-to-text` |
-| 图片"抠图/去背景" | `ai-image-matting` |
-| "发送到飞书/通知群/推送消息" | `send-feishu-message` |
-| "同步到多维表格/写入 Base/存表格" | `feishu-bitable` |
-| "建群/拉群" | `feishu-group-create` |
-
-识别出候选后**召回 `plugin-guide` skill**，由它完成实例复用或创建、运行时合同读取和真实调用。本 skill 不复述插件目录与调用规范。
-
-**边界**：数据库读写、文件上传/存储**不是插件**（内置服务 DataLoom / file-service，走对应 skill）；语义检索走 `semantic-search` skill。别把这三类误建成 capability。
-
-## mock 信号识别表（grep 创意产物定位待替换点）
-
-创意稿无「插件规划」时，AI/飞书能力都是 mock 的。规划阶段 grep 这些信号，逐个登记进方案的 capability 清单：
-
-| mock 反模式 | 典型形态 | 应替换为 |
-|-------------|----------|----------|
-| 假异步 AI | `setTimeout(() => setState(硬编码对象))`、`simulate*`/`mock*`/`fake*` 函数名 | 对应 AI capability |
-| 预置结果数组 | `MOCK_*` / `PRESET_*` 常量假装 AI 生成结果 | 对应 AI capability |
-| 外链占位图 | `picsum.photos` / `placeholder.com` / `unsplash` 替代 AI 生图 | `ai-text-to-image` |
-| 假飞书反馈 | `toast('已发送到飞书')` 无真实调用 | `send-feishu-message` |
-| 随机数假逻辑 | `Math.random()` 替代 AI 分类/评分 | 对应 AI capability |
-
-（源稿中的示例业务实体记录可作为初始事实写入数据库；KPI、图表、排行、趋势等派生展示值不属于可誊写的初始事实。二者都与需要真实插件替换的“能力 mock”区分。）